Factory Droid 実践ガイド：複数エージェントで挑む複雑な開発

小さなバグを直すだけなら、既存の多くのAIコーディングツールで十分に対応できます。しかし、複数サービスにまたがる認証リファクタリングや大規模な移行作業を任せると、チャット型のエージェントは途中で文脈を見失い、破綻しがちでした。

Factoryは自社の開発エージェントDroidの設計思想を改め、複数の専門サブエージェントを指揮して大規模なタスクを完遂するためのオーケストレーション基盤へと進化させました。

コードに触る前に設計書を作らせる

AIエージェントが大規模タスクで失敗する最大の要因は、リポジトリを浅く読んだだけで拙速にコードを書き換えてしまう点にあります。

Droidが備えるSpec Modeは、実装に着手する前にまず調査を行い、変更予定のファイル一覧やテスト戦略をまとめた仕様書を出力します。開発者はその計画を確認し、例外処理やロールバック手順に不備がないかを精査して承認を出します。

承認された仕様書はMarkdownとして保存できるため、人間のチームメンバーや将来稼働する別のエージェントに向けた永続的な設計記録として残せます。また、プロンプトが空の状態で感嘆符を入力すると通常のBashモードに切り替わり、Escapeキーで即座にエージェントへ戻れるなど、ターミナル操作の細かな摩擦も排除されています。

Worktreeによる並列作業とコンテキストの局所化

現場のリポジトリには、ドキュメント化されていない運用ルールが散在しています。Droidはリポジトリや各パッケージ内のAGENTS.mdで全体規約を定義し、デプロイやリリース手順といった特定タスクの知識は必要な時だけ読み込むSkillsとして分離しました。

さらにLinearやSentryといった外部ツールとMCP経由で連携できるほか、droid execコマンドを用いたCIやスクリプトからのヘッドレス実行にも対応しています。

特筆すべきはGitのWorktreeを活用した並列実行です。Missions機能によってタスクを複数のカスタムエージェントへ分散させ、互いの変更が干渉しないよう別々の作業ツリーで並行して実装と検証を進められます。

なぜ重要か

私たちは、先端フロンティアモデルがどのツールでも利用可能になった今、勝負の分かれ目はモデル単体ではなく、モデルを動かす実行環境の設計に移ったと考えます。

開発者にとって、Droidの価値は「コードの単発編集」ではなく「プロジェクト規模の改修」で発揮されます。単に関数を手直しするだけなら既存の補完ツールで足りますが、複数の検証と計画が必要なアーキテクチャ移行では、Spec Modeによる事前承認が大きな安全弁となります。

作業を急がせるのではなく、設計のレビュー機会を挟み、Git Worktreeで衝突を防ぐ設計は、実際のソフトウェア開発現場の勘所を的確に捉えています。一方で、AGENTS.mdの整理やツールの権限制限など、事前に行う環境整備の負荷が高い点は否めず、整ったテスト環境を持たないチームには導入のハードルが残ります。