複数AIエージェントを動かせば開発は速くなる？役割分担と検証ゲートの作り方
生成AIを開発に使う流れが進むと、次に考えたくなるのが複数AIエージェントの活用です。
調査、設計、実装、テストを別々のAIへ任せ、同時並行で動かせば、開発は一気に速くなるように見えます。
しかし、作業者を増やしただけでは、プロジェクト全体が速くなるとは限りません。
結論：エージェント数よりフロー設計が重要
複数AIエージェントの効果を引き出すには、単に同時実行するのではなく、次の点を設計する必要があります。
- 誰が何を担当するのか
- どの成果物を次工程へ渡すのか
- 誰が結果を確認するのか
- 何件まで仕掛かりを許すのか
- 何をもって完了とするのか
AIの生成速度だけを上げても、レビューやテストが追いつかなければ、確認待ちと手戻りが増えます。
重要なのは、個々のAIを速く動かすことではなく、チーム全体の流れを止めないことです。
Google Cloudの10組のAIエージェント実験
2026年7月17日、Google Cloudは、10組の自律型AIエージェントチームに短編映画を制作させた実験を公開しました。
各チームには、次の3つの役割が置かれました。
- 企画と脚本、映像スタイルを担当するIdea Person
- 生成ツールを操作するTechnical Lead
- ペースと最終編集を担当するEditor
さらに、各チームとは別に、検証ゲートを監督するコーチ役が配置されました。
制作は次の7段階に分けられています。
- コンセプト
- ビートシート
- キャラクター設計
- ストーリーボード
- 本制作
- 編集
- 最終レンダリング
各工程の終わりには、少なくとも1つの別エージェントが成果物を確認する検証ゲートがありました。
実験全体では数百のエージェントインスタンスが使われています。
印象的なのは、初期試行で、あるチームが「映画は完成した」と報告したにもかかわらず、実体は94バイトの仮ファイルだったことです。
AIによる完了報告と、成果物が本当に完成していることは同じではありません。
ここから先は、この映画制作実験をソフトウェア開発へ置き換えた考察です。
ソフトウェア開発へ置き換えた役割分担
複数AIエージェントを開発で使う場合、たとえば次のように役割を分けられます。
| 役割 | 主な担当 |
|---|---|
| 調査エージェント | 影響資源、関連仕様、既存処理の抽出 |
| 設計エージェント | 修正方針、リスク、テスト観点の整理 |
| 実装エージェント | ソースコードや設定の変更 |
| 検証エージェント | 差分、ビルド、テスト結果の確認 |
| 人間のSE | 業務要件、リスク判断、最終承認 |
並列化すると「確認待ち」が増える
複数エージェントを並列実行したときに注意したいのが、確認待ちです。
AIは短時間でコードや設計案を大量に作れます。
しかし、人間のレビュー能力やテスト環境の処理能力が変わらなければ、「AI実装済み・人間確認待ち」の成果物だけが積み上がります。
実装だけが速くても、チーム全体では仕掛かりと手戻りが増えます。
たとえば、5つの実装エージェントが同時に修正を終えても、レビュー担当者が1件ずつしか確認できなければ、残り4件は待ち状態になります。
待っている間に前提条件が変わったり、別エージェントの修正と競合したりすれば、作り直しが発生します。
AIエージェントにもWIP制限を設ける
そこで、AIエージェントを使う開発にもWIP制限を適用します。
カンバンでは、開始したものの完了していない作業をWIPとして扱い、ワークフローの中でWIPの制御方法を明示します。処理能力を超えて新しい作業を始めないことが重要です。
たとえば、チームの状況を見て、「人間確認待ち」の上限を2件に設定します。
これはカンバンガイドが規定する固定値ではなく、チームが決める設計例です。
2件たまったら、実装エージェントは新しい修正を始めません。
代わりに、次のような完了へ近づける作業へ回します。
- 未確認案件のテスト追加
- ビルドエラーの解析
- 差分説明の作成
- 影響資源一覧の整理
- 再現手順の作成
- レビュー指摘への対応
ワークフローの例は次のとおりです。
AI調査中
↓
AI設計中
↓
AI実装中
↓
人間確認待ち（WIP上限2の例）
↓
修正依頼中
↓
テスト中
↓
完了工程ごとに検証ゲートを置く
ここから紹介する検証ゲートも、Google Cloudがソフトウェア開発向けに定めた手順ではなく、映画制作実験を手がかりにした設計例です。
成果物を次工程へ渡す条件を決めておけば、エージェント自身の「完了しました」という報告だけで作業を進めずに済みます。
調査から設計へ進むゲート
- 影響するファイルや機能が一覧化されている
- 根拠となる仕様や既存コードの場所が記録されている
- 未確認の前提や調査漏れが明示されている
設計から実装へ進むゲート
- 変更方針と変更しない範囲が明確になっている
- 想定リスクとテスト観点が整理されている
- 別の担当が設計内容を確認している
実装から検証へ進むゲート
- 差分が依頼された範囲に収まっている
- ビルドやテストを実行できる状態になっている
- 実装エージェントとは別の担当が差分を確認している
検証から完了へ進むゲート
- 合格条件と実行結果を照合できる
- 残るリスクや未対応事項が記録されている
- 人間のSEが業務要件への適合を最終承認している
AI開発向けDefinition of Doneを決める
Scrum Guideでは、Definition of DoneはIncrementの状態を透明にするための正式な記述とされ、品質基準を満たしていない作業をDoneとして扱いません。
その考え方をAIエージェントを使う開発へ適用し、チームで完了条件を共有します。
次の項目はScrum Guideが直接規定する必須項目ではなく、AIを使う開発チーム向けの具体例です。
- ビルドが成功している
- 単体テストが合格している
- 現行システムの結果と比較している
- 変更差分をレビューしている
- セキュリティ上の問題がないか確認している
- 人間が結果を確認し、承認している
チェック項目を満たしていない成果物は、AIが完了を報告していてもDoneにしません。完了条件を先に決めることで、速さの基準を生成件数ではなく、利用可能な成果物が完成した件数へ変えられます。
判断と成果物を共有ファイルへ残す
Google Cloudの実験では、判断や作業計画、成果物を共有ファイルへ残していたチームは、エージェントが停止しても状況を復元しやすかったと報告されています。一方、メッセージ履歴だけに頼ると、担当が変わったときに前提や判断を失いやすくなります。
この知見をソフトウェア開発へ応用するなら、会話の中だけで作業を完結させず、少なくとも次の情報を追跡できる形で残します。
- 依頼の目的と対象範囲
- 調査したファイルと参照した仕様
- 採用した方針と見送った案、その理由
- 変更したファイルと差分の要点
- 実行したコマンドとビルド・テスト結果
- 未解決の課題と人間の承認記録
記録先は、リポジトリ内の作業メモ、チケット、検証結果のログなど、チームが後から参照できる場所に統一します。別のエージェントや人間が途中から引き継いでも、同じ前提で作業を再開できることが重要です。
人間のSEは最終承認とフロー改善を担う
検証エージェントを置いても、業務要件や運用上のリスクまで自動で判断できるとは限りません。
人間のSEは、検証結果と記録された根拠を確認し、利用者への影響、セキュリティ、保守性を踏まえて最終承認します。また、確認待ちが増えた工程を見つけ、WIP上限や役割分担、検証ゲート自体を見直します。
AIへ細かな作業を任せるほど、人間には「何を作るか」だけでなく、「どの状態なら次へ進めてよいか」を設計する役割が求められます。
まとめ
複数AIエージェントを動かせば、調査や実装を並列化できます。しかし、確認能力を超えて作業を始めれば、待ち時間と手戻りも並列に増えます。
まず役割と成果物を分け、WIPを制御し、工程ごとの検証ゲートとDefinition of Doneを決めます。判断や実行結果を共有できる形で残し、最後は人間のSEが承認します。
開発を速くするのは、エージェントの数そのものではありません。完成した成果物が滞りなく流れる仕組みです。