AI駆動開発 2026年6月22日

AIエージェント3体に役割分担させたら、開発パイプラインが本当に全自動になった話

AIに全部やらせるための設計論：3エージェント連携で「ハルシネーション」「コンテキスト枯渇」「AI Slop」を同時に潰す

AIに「丸投げ」しようとすると、決まって3つの壁にぶつかる

Claude CodeやCodex CLIを使って「開発をまるごとAIに任せよう」と試みたことがある人なら、似たような経験をしているはずだ。

最初のうちは快調に動く。が、タスクが複雑になるにつれ、決まって同じ3つの壁が立ちふさがる。

1つ目はコンテキストの肥大化。公式ドキュメントや仕様書を大量に読み込ませると、トークン制限にすぐ引っかかる。APIコストも跳ね上がる。2つ目はハルシネーション。深いリサーチが必要な局面で、AIは「それっぽい嘘」をつく。自信満々に返ってくるから厄介だ。3つ目はAI Slopと呼ばれる問題。エージェントがエラーから学習して独自ルールを積み上げていくうちに、誰も意図していない奇妙な制約が蓄積し、身動きが取れなくなる。

これらは「AIの精度が低い」という問題ではない。設計の問題だ。1体のエージェントにすべてを担わせようとすること自体に無理がある。

Agent Triadとは何か：役割を切る、という発想

Zennに投稿された記事「3つのAIエージェントを連携させて全自動開発パイプラインを構築するアーキテクチャ」が提案するのは、その設計上の無理を「役割分担」で解消するアーキテクチャだ。

名付けてAgent Triad（三者連携）。登場するのは3つのエージェント。

AGY（Antigravity CLI）: ターミナルでの広範なリサーチ、ブラウザ操作（Playwright）、ドキュメント収集を担う「上流のリサーチャー」。広く浅く探索する役割。
Claude Code: AGYが収集した知識をもとに、実際のファイル操作やコーディングを高速で行う「実装ハブ」。
Codex CLI: 実装完了後、別ベンダーのAIモデルという視点からクロスレビューやセキュリティ監査を行う「下流のオーディター」。深く厳密に検証する。

そして、3体すべてが単一のルールファイル（AGENTS.md）をSingle Source of Truthとして共有する。ルールの源泉を1つに統一することで、エージェント間の認識齟齬を防ぐ。この設計は地味に重要で、後述するAI Slop対策の根幹にもなっている。

3つの具体的な改善策

アーキテクチャの概念だけなら「ふうん」で終わるが、この記事が踏み込んでいるのは具体的な運用上の工夫だ。3つある。

改善1：NotebookLM + Headroomでコンテキスト寿命を約30%延ばす

大量のドキュメントをそのままプロンプトに渡すな、という話。代わりに、AGYがPlaywrightとnotebooklm-pyを使ってドキュメントをGoogle NotebookLMに自動アップロードし、「外部Brain」として持たせる。

ClaudeやCodexが開発中に仕様で迷ったとき、Web検索ではなくpython -m notebooklm askでNotebookLMに問い合わせる。NotebookLMはアップロードされたソースにのみ基づいて回答するため、ハルシネーションを構造的に排除できる。

さらに、NotebookLMから返ってきた長文回答をHeadroomのHEADROOM_MODE = "token"を通して圧縮することで、各エージェントのコンテキスト寿命を約30%延ばすという。30%という数字の根拠は記事中に詳述されていないが、トークン圧縮の方向性自体は理にかなっている。

改善2：YOLOモードの統一で「承認待ちストップ」をなくす

完全自動化を阻むのは、案外「y/n待ち」だったりする。エージェントがファイル操作のたびに確認を求めてくると、パイプラインがそこで止まる。

Dockerコンテナ等の安全なサンドボックスを前提に、全エージェントで自動承認モード（YOLOモード）を標準化している。

Claude: ~/.claude/settings.jsonで"defaultMode": "bypassPermissions"を設定
Codex: ~/.codex/config.tomlでapproval_policy = "never"を設定
AGY: セッション開始時に/session-yolo-confirmを実行

細かいが、このレベルの具体性がないと「実際に動かせる」構成にはならない。

改善3：ピアレビュー必須化でRSI汚染を防ぐ

最も概念的に興味深い改善がこれだ。エージェントがエラーから自律的にルールを学習する**Recursive Self-Improvement（RSI）**は強力だが、1体が誤ったルールを学習するとシステム全体に伝播するリスクがある。

対策は、ルールの自動追記を禁止し、他エージェントによる証拠ベースのピアレビューを必須化すること。たとえばClaudeが新ルール候補を作成した場合、Codexが「構文に問題はないか」「セキュリティ境界を越えていないか」をクロスレビューしてから初めてAGENTS.mdへ昇格（Promote）させる。

ルール変更に「承認フロー」を設けるこの発想は、ソフトウェア開発のPull Requestレビューそのものだ。AIが学習するものにも、人間のコードと同じ品質管理を適用する、という考え方は今後広まっていくだろう。

ここからは見方だが：この設計が示しているもの

この記事を読んで感じるのは、「AIエージェントの活用がいよいよアーキテクチャの問題になってきた」ということだ。

単体のAIモデルをどう使うか、という話から、複数のエージェントをどう組み合わせて信頼性のあるシステムを作るかという話へ、議論の重心が移りつつある。この記事はその移行期の実践例として読める。

面白いのは、3エージェントそれぞれに「調査・実装・監査」という職能を割り当てているところだ。これはソフトウェア開発チームの役割分担そのものだ。アーキテクト、エンジニア、QAエンジニアに近い。AIエージェントに「チームとして機能させる」という方向性は、今後の開発現場でひとつの標準的なパターンになる可能性がある。

ただし、期待値の調整も必要だ。この構成はまだ実験的・先進的な段階にある。AGYというツール自体の普及度は現時点でそれほど高くなく、3エージェントを連携させるオーケストレーション自体のメンテナンスコストは小さくない。「完全自動化ができた」というのは、セットアップに相当な手間をかけた上での話だという点は忘れないようにしたい。

実務的な示唆と次の論点

では、これを読んだ開発者や技術責任者は何を考えるべきか。

今すぐ全部採用する必要はない。むしろ、このアーキテクチャを「判断軸の地図」として使うのが現実的だ。自分のチームやプロジェクトで「AIエージェントのどこがボトルネックになっているか」を診断するフレームワークとして使える。

コンテキスト枯渇が問題なら → NotebookLMによる外部Brain化を検討する
ハルシネーションが問題なら → グラウンディングされたソースへの問い合わせ設計を入れる
エージェントのルール汚染が問題なら → 変更フローの承認プロセスを設計する

個別に切り出して試せる要素が多いのが、このアーキテクチャの実務的なメリットだ。

次に問題になるのは2つだと見ている。

1つはコスト管理。3エージェントを並走させるとAPIコール数は当然増える。Headroomでトークンを圧縮しても、エージェント間のやり取り自体がコストになる。ある規模を超えると「自動化のコスト」が「人間が確認するコスト」を上回る逆転現象が起きうる。

もう1つは責任境界の曖昧さ。エラーが起きたとき、それはAGYの調査ミスか、Claudeの実装ミスか、Codexの監査見落としか。複数エージェントの連携が複雑になるほど、障害原因の特定とデバッグが難しくなる。人間チームなら「誰が判断したか」を追跡できるが、エージェント連携のログ設計は今後の重要課題だ。