なぜ複数エージェントなのか
一つの強いエージェントに全部任せればよい、という考え方がどこで壊れるのか。文脈、役割、レビュー、承認、記録を手がかりに、複数エージェント構成が必要になる理由を整理する。
1. 問い
なぜ複数エージェントなのか。
この問いは、役割名が増えた瞬間に難しくなる。計画担当、実装担当、レビュー担当、承認担当、運用担当。名前を並べると、それだけで高度な仕組みに見える。だが、名前を増やしても仕事はよくならない。むしろ遅くなることもある。
それでも私が複数エージェントを考えるのは、単一エージェントでは構造的に抱えにくい責務があるからだ。問題は、一つのエージェントが賢いかどうかだけではない。一つの会話が、計画、実装、レビュー、承認、記録、報告を同時に抱えて崩れないかである。
短く言うと、複数エージェントは並列化のためだけにあるのではない。
責務を分けるためにある。
最初にこの圧力を置く。続く記事では、生き残る実行基盤としての tmux、エージェントを使った作業の背後にある二つの状態機械、個人用コンピューターの中の会社 を順に扱う。
2. 一つのエージェントは万能に見えすぎる
一つの強いエージェントは、多くの仕事をこなせる。計画し、調査し、実装し、テストし、要約し、報告できる。短い仕事ならそれで十分なことも多い。そこに役割を足すと、ただの儀式になる場合もある。
問題は、仕事が長くなったときだ。その一つの会話が、あまりにも多くの役割を背負い始める。
- 計画担当
- 実装担当
- レビュー担当
- 承認担当
- 調整担当
- 運用担当
これらを同じ文脈、同じ履歴、同じ成功欲求の中に入れると、失敗の形が見えにくくなる。作業した本人が「できた」と言う。古い前提が履歴の奥に残る。レビューの目線が、実装中の都合に引っ張られる。途中で組み立てた推論を、同じエージェントが守りたくなる。
これは能力不足の話ではない。役割の相性の話である。
3. 文脈を小さくする
最初の理由は、文脈を小さく保つことだ。ただ短くすればよい、という話ではない。各役割が実際に使える文脈だけを渡し、それ以外を減らす。
単一エージェント構成の弱点は、コンテキストウィンドウの上限、長時間作業での判断精度低下、一つの視点しか得られないこと、人間の介入タイミングが曖昧になることとして現れる。
運用寄りに見ると、別の形でも現れる。エージェントは最初の会話やチェックリストを見失う。プロジェクトの指示や利用できるスキルの存在を取り落とす。圧縮後に進め方が崩れる。原因は、必要な文脈を必要な瞬間に渡せていないことだ。
複数エージェントに分けると、各エージェントの仕事は小さくなる。計画担当は作業の形を決める。実装担当は作業に集中する。レビュー担当は差分と根拠を見る。承認担当は危険な操作を止める。調整担当は経路と未完了の依頼を見る。運用担当は状態、例外、人間への報告に集中する。
これは「たくさん並べると賢くなる」という話ではない。各役割に渡す文脈を減らす話である。
4. 実装担当とレビュー担当を分ける
二つ目の理由は、実装担当とレビュー担当を分けることだ。実装の途中から見ると終わって見える作業でも、要求から見直すと弱いことがある。
作業したエージェントだけが完了判定をする構成には、明らかな弱点がある。本人が書いた差分、本人が選んだ根拠、本人が通したテストだけで「完了」と言うことになる。
人間の開発でも、Pull Request を作者本人だけで承認するのは弱い。同じことがエージェントにも起きる。
もちろん、別エージェントを置けば自動的に客観性が生まれるわけではない。同じモデル、同じプロンプト、同じ文脈を持つ別インスタンスは、同じ見落としをすることがある。だから分離とは、単に別名のエージェントを置くことではない。
効く分離は、レビュー担当が見ているものを変える。
レビュー担当には、実装担当の長い思考過程ではなく、差分、根拠、検証コマンド、成果物を渡す。実装担当がなぜそう考えたかではなく、結果が要求に届いているかを見る。これだけで、同じモデルでも目線はかなり変わる。
5. 承認は別の状態である
三つ目の理由は、承認を作業から分けることだ。実装担当が注意深くなるだけでは、手続きにはならない。
削除、デプロイ、認証情報の変更、本番データへの書き込み、外部公開、公開コメント、ブランチ公開のような操作は、実装担当が実行できるからといって、そのまま実行してよいとは限らない。
ここで必要なのは、別の状態遷移である。
通常作業は進む。危険な操作だけが止まる。止まった理由、必要な承認、承認担当、却下された場合の代替案が記録される。これは一つのプロンプトで毎回思い出させるより、役割と仕組みに分けたほうが安定する。
複数エージェント構成では、承認担当を実装担当から分けられる。実装する役割と、危険な境界を越えてよいか判断する役割を同じにしない。これは組織っぽいが、見た目のためではない。事故の種類が違うからだ。
6. 会話とチェックリストを外へ出す
四つ目の理由は、記憶を一つの会話に閉じ込めないことだ。
エージェント間の会話、チェックリスト、成果物、返信義務は、Markdown やファイルに出したほうがよい。個別エージェントの会話ログに依存しすぎると、エージェントを交換できない。圧縮やクラッシュにも弱い。どの依頼が開いたままかを、人間がペイン履歴から推測する羽目になる。
外へ出すべきものは、少なくとも次の四つである。
- 誰が誰に依頼したか
- どの返信が必須か
- どの成果物が根拠か
- 何をもって完了と数えるか
この層ができると、エージェントは交換可能になる。Claude Code でも Codex でも、同じメール、同じ成果物、同じチェックリストを読める。モデルの個性は残るが、作業の継続性は会話ログではなく外部の記録に移る。
7. 並列化は副作用である
複数エージェントと言うと、すぐ並列化が連想される。もちろん並列化は効く。調査を分ける、別案を比較する、実装とレビューをずらす、複数の観点で批判させる。速度面の利点はある。
しかし、並列化を主目的にすると設計を間違えやすい。完了の条件を言えないまま、動きだけを増やしてしまうからだ。
本当に先に必要なのは、責務の分離、返信義務、レビュー、承認、成果物の記録である。そこがないままエージェントの数だけ増やすと、進捗が速く見えるだけで、何が終わっていて、何が未検証で、誰が何を待っているのかが分からなくなる。
並列化は、責務が分かれてから効く。
8. 複数エージェントは小さな組織である
だから、複数エージェントは技術というより組織設計に近い。似て見えるのは飾りではない。注意、権限、根拠を役割の間で動かす地点で、同じ問題が出る。
計画担当がいる。実装担当がいる。レビュー担当がいる。承認担当がいる。調整担当がいる。運用担当がいる。
これは人間の会社を真似たいからではない。人間の組織が、有限の注意、責任の分離、承認、引き継ぎ、監査、例外処理という問題に長く向き合ってきたからだ。エージェントの作業も、長くなり、広がり、失敗時の影響が大きくなるほど同じ問題に近づく。
単一エージェントで十分な仕事は、単一エージェントでよい。
複数エージェントが必要になるのは、次の問いが出てきたときだ。
- 実装した本人以外が根拠を確認する必要はあるか
- 危険な操作を別の承認状態にしたいか
- 作業の記憶を会話ログの外に置きたいか
- どの依頼が開いたままか機械的に見たいか
- 人間が毎回ペインを読まなくても進めたいか
- モデルや CLI を途中で差し替えたいか
これらにいくつも yes がつくなら、複数エージェントは趣味ではない。作業を壊さず長く走らせるための構造である。
9. 次に見るべきもの
この問いを先に置くと、続く三つの記事の位置づけも変わる。単なる道具紹介ではなく、責務を分けた後に何が必要になるかを見る記事になる。
次の記事の 「tmux は生き残るが、見える形は消える」 は、複数エージェントを載せる実行基盤の話である。ターミナルは消えない。ただし、人間が直接見続ける対象ではなくなる。
その次の 「エージェントを使った作業のための二つの状態機械」 は、運用状態とタスクの意味上の状態を分ける話である。メッセージが届いたことと、タスクが受理できることは違う。
最後の 「個人用コンピューターの中の会社」 は、この構造が個人の作業環境に入ると、なぜ小さな組織の形に見えるのかを扱う。
複数エージェントで見るべきものは、派手な群れではない。
一つの会話に押し込むには相性の悪い責務を、外に出し、名前を付け、記録し、確認できるようにすることだ。