Claude CodeやCursorといったAIコーディングツールを使っていると、ある壁にぶつかります。
一つのセッションにすべてを任せると、途中からAIが暴走し始めるのです。
指示していない機能を勝手に追加する。
コードベース全体を不必要に読み込む。
そして会話が長くなるにつれて、当初の設計意図を忘れていく。
こうした経験に覚えがある方も多いのではないでしょうか。
この問題に対して、Reddit上で興味深い議論が交わされていました。
ソロのAIコーディングセッションをやめて、3つのエージェントに役割分担させるというアプローチです。
本記事では、その議論から得られた知見を整理してお伝えします。
「設計・実装・レビュー」の分離が鍵
投稿者が提唱していたのは、AIコーディングにおける役割を3つに分けるという考え方でした。
Architect（設計者）は、全体の方向性を決める存在です。
ユーザーの要求を受け取り、スコープを明確にした指示書を作成します。
Builder（実装者）は、その指示書に従ってコードを書きます。
指示の範囲外には手を出しません。
そしてReviewer（検査者）は、実装が指示書どおりかを厳しくチェックします。
合格か差し戻しかを判定する役割です。
エージェント間のやり取りは、Markdownファイルを介して行われます。
仕組みとしてはシンプルですが、だからこそ透明性が高いのです。
何がどの段階で決まり、何が実装され、何が承認されたか。
すべてファイルとして残ります。
この構造自体は、特別に新しいものではありません。
ソフトウェア開発の現場で長年使われてきた「Plan → Build → Review」のサイクルそのものです。
ただし、それをAIエージェントに適用するという点に価値があります。
なぜソロセッションは破綻するのか
コメント欄で特に共感を集めていたのが、ソロセッションの限界に関する指摘でした。
あるユーザーは、こう分析しています。
ソロのClaudeセッションが失敗する原因は、AIがシステム設計全体をコンテキストに保持しながら、同時に実装の詳細も書こうとする点にある、と。
コンテキストウィンドウへの負荷が高まると、3万〜4万トークンあたりで設計上の決定事項を落とし始めるそうです。
役割を分離すれば、この問題は自然に解消されます。
設計の意図はMarkdownファイルに明示的に書き出される。
そのため、実装者が参照できるアーティファクトとして残るわけです。
これは実質的に、無料のコンテキスト管理と言えるでしょう。
また別のユーザーも、核心をついた指摘をしていました。
コンテキスト境界の強制こそが本質的な勝因だ、と。
各エージェントが問題を新鮮な視点で再解釈するため、最初のパスで見落とした前提を捉えられます。
しかもトークンの約40%を「過去の会話の発掘作業」に費やさずに済むとのことです。
3つという数には意味がある
コメント欄で繰り返し議論されていたのが、「なぜ3なのか」という問いでした。
ある興味深い分析によると、この仕組みが機能する理由は役割分離そのものではないそうです。
対立構造にこそ意味がある、と。
Reviewerには問題を見つけるインセンティブがあります。
その緊張関係こそが、単独のエージェントでは見逃してしまうミスを捕捉するのです。
2つだと簡単に合意してしまいます。
しかし3つだと、三角形の構造が生まれる。
各役割が他の2つに異議を唱えられますが、デッドロックには陥りません。
実際、多くのユーザーが独立してこのパターンに到達し、3つに落ち着いたと報告していました。
投稿者自身も最終的に「3人チームは最小単位」と結論づけています。
そして開発用・QA用・マーケティング用と、部門ごとに3人チームを編成する「3×3構造」を提案していました。
コミュニティが指摘した改善点
この投稿には多くのupvoteがつきました。
コメント欄では実践的な改善提案が数多く寄せられていたので、特に有用だったものを紹介します。
モデルの使い分けについて、複数のユーザーが設計と実装で異なるモデルを使う手法を共有していました。
たとえば、ArchitectにはOpusのような高性能モデルを割り当てる。
深い思考と詳細な設計を担わせるためです。
一方、Builderにはコスト効率の良いSonnetを使います。
明確な指示に従った実装に集中させるという考え方です。
計画段階を十分に詰めておけば、実装側のモデルは比較的軽量でも問題ないという意見が多く見られました。
Reviewerの盲点に対する指摘も鋭いものでした。
ReviewerとBuilderは同じモデル（同じ学習データ）で動いています。
そのため、盲点が重なるのです。
これを補うには、コードそのものではなくgit diffを見せたほうが効果的だといいます。
変更差分だけをレビューすれば、Builderが気づかなかったリグレッションを検出できる。
しかもコードベース全体を毎回読み直す必要もなくなります。
テスト専門エージェントの追加も、複数のユーザーが提案していました。
Reviewerがコードを「読む」だけでは不十分です。
実際に「動かす」ことで、検証精度が格段に上がるという考え方です。
あるユーザーは、ターミナルをプログラマティックに操作できるツールを使い、エージェントに実際のテスト実行をさせていると報告していました。
共有タスク状態の管理については、Markdownファイルでの手動ハンドオフに代わる手法が提案されていました。
MCPサーバーを使って、タスク状態をプログラム的に管理するという方法です。
タスクのステータスをtodo → in_progress → in_review → doneと遷移させる。
これにより、ファイルのコピー＆ペーストが不要になります。
懐疑的な声にも目を向ける
一方で、批判的な意見も無視できません。
最も多かったのは、「トークン効率が良い」という主張に対するデータの不在です。
投稿者は体感として改善を感じていました。
しかし、具体的な数値比較は提示していませんでした。
あるコメントは、科学的手法を提案しています。
まず仮説を立てる。
次に、同じ仕様のソフトウェアを両方のセットアップで構築する。
テストを通過するまでのトークン数と時間を計測し、3回ずつ繰り返して統計的信頼性を高める。
まさに正論でしょう。
また、「これは単にプロンプトをGitHubリポジトリに膨らませただけではないか」という厳しい指摘もありました。
既存のツールでも同等のことが実現できるという意見です。
たとえば、Anthropic公式のfeature-devプラグインやSuperpowersプラグインが例として挙げられていました。
投稿自体がAIで書かれたのではないか、という疑惑も浮上しています。
投稿者がそれを認めたことで、downvoteを浴びていました。
「自分の考えを2ページ分も書けない人が、他人にとって有用なものを作れるとは思えない」という辛辣なコメントもあります。
ただし、これに対しては反論もありました。
「英語が第三言語の人にとって、AIによる文章の補助は不可欠だ」という声も上がっており、議論は分かれていました。
実践への示唆
この議論全体を俯瞰すると、いくつかの示唆が見えてきます。
まず、多くの開発者が独立して同じパターンに到達しているという事実があります。
これは、この方向性が本質的に正しいことを示唆しているでしょう。
「設計と実装を分離し、第三者にレビューさせる」という構造は、人間のチームで何十年も機能してきた手法です。
AIにも同様の規律を適用するのは、自然な流れと言えます。
ただし、特定のツールやリポジトリに飛びつく必要はありません。
まず原則を理解しておきましょう。
コンテキストの分離。
明示的なハンドオフ。
対立構造によるチェック。
これらの原則さえ押さえておけば、CLAUDE.mdファイルとセッションの手動切り替えだけでも同じ効果を得られます。
あるコメントが端的に指摘していました。
計画をMarkdownに書き出し、新しいセッションでそのファイルを読み込んで実装する。
さらに別のセッションでレビューする。
各セッションが別のエージェントになるのだから、特別なリポジトリは要らない、と。
結局のところ、重要なのはツールではなく構造です。
AIにすべてを一度に任せるのをやめて、明確な役割と境界を与える。
それだけで、AIコーディングの質は大きく変わるはずです。
まとめ
AIコーディングにおける3エージェント体制は、多くの開発者が独立して到達している実践的なパターンです。
設計者・実装者・検査者の役割分離により、コンテキストの肥大化を防げます。
そしてハルシネーションやスコープの逸脱も抑制できるのです。
このアプローチはまだ発展途上にあります。
トークン効率の定量的な検証も、今後の課題として残っているでしょう。
それでも、Reddit上で多数の開発者が共有した実体験は、この方向性が有望であることを強く示していました。
既にAIコーディングツールを使っているなら、まずは小さく試してみてください。
次のタスクで、設計・実装・レビューのセッションを分けてみる。
その違いを体感してから、自分に合ったワークフローを組み立てていけばよいでしょう。
