マルチエージェントは「チーム」になれるのか 50年前の古典が突きつける不都合な法則：及川卓也からエージェント時代の開発者たちへ（7）（3/3 ページ）

2026年、多くのチームが「マルチエージェント」という魔法の杖に手を出し、そして壁にぶつかり始めています。AIエージェントを複数並行させれば生産性は上がる。そう信じたくなる気持ちは分かります。しかし50年前、ソフトウェア工学の古典が既に警告していました。「人を増やすと、かえって遅くなる」と。その法則は、形を変えてAIエージェントの世界にも姿を現しています。

[及川卓也，Tably株式会社]

　現在、高い成果を出しているマルチエージェントシステムの多くは「オーケストレーター型」と呼ばれる構成を採用しています。1つの中核エージェント（オーケストレーター）が全体の設計と判断を担い、専門化された複数のエージェントがそれぞれの領域でタスクを実行する。オーケストレーターはブルックスの「執刀医」であり、専門エージェントは「専門スタッフ」です。

　Google研究が示したのは、この集中型の構成が「成功率とエラー抑制のバランスが最も良い」という結果でした。逆に、全員が対等に情報交換する分散型では263%もの通信オーバーヘッドが発生し、ハイブリッド型では515%にまで膨れ上がります。

　Anthropicのマルチエージェント設計ガイドも、エージェント数を抑えてオーケストレーターパターンを採用することを推奨しています。実際、5体を超えると調整コストが利点を相殺し始めます。

　興味深いのは、この「5人前後」という数字に、2つの全く異なる理由から到達していることです。ブルックスの法則が示すのは「コミュニケーション経路の組み合わせ爆発」。Googleの研究が示すのは「固定トークン予算下での推論能力の希薄化」。原因は違うのに、結論は同じ。Amazonの「2-pizza team」もSpotifyの「8人Squad」も同じ経験則です。50年前の洞察が、全く異なる技術的文脈で再発見されている。歴史を知ることの価値を、改めて感じます。

それでもチームには「歴史」が要る

　では、外科医チーム型に構成しさえすれば、マルチエージェントは「チーム」として機能するのでしょうか。構成の問題は解けたとしても、まだ足りないものがある気がします。

　ここで少し立ち止まって、「チーム」とは何かを考えてみたいのです。

　私が日本語版の解説を書いた『Team Geek──Googleのギークたちはいかにしてチームを作るのか』（ブライアン・フィッツパトリック＜Brian W. Fitzpatrick＞とベン・コリンズ＝サスマン＜Ben Collins-Sussman＞の共著）という本があります。この本の核心は、ソフトウェア開発がチームスポーツであるということ、そしてチームを機能させる土台は「HRT」――Humility（謙虚）、Respect（尊敬）、Trust（信頼）――の3つだということです。技術力ではなく、人間同士の関係性がチームの成否を分ける。

　Googleが2012年から実施した社内調査「Project Aristotle」も、同じ結論に至りました。180のチームを分析し、チームの成功を左右する最大の因子を突き止めたのですが、それは技術力でもメンバーの優秀さでもなく、「心理的安全性」（Psychological Safety）でした。HRTの中のTrust（信頼）が、組織的な規模で検証されたとも言えます。失敗しても責められないという信頼があるから、メンバーはリスクのあるアイデアを口にできる。そこから予想外のブレイクスルーが生まれる。つまり心理的安全性とは、チームの「創発性」を支える土壌なのです。

　AIエージェントには、この創発性がありません。エージェント同士の通信は、あらかじめ定義されたプロトコルに従う構造化されたメッセージ交換です。「ちょっと思いついたんだけど」という雑談も、偶然の発見（セレンディピティ）も起こらない。前のセクションで触れた通信コストの問題と根は同じです。コミュニケーションが構造化されているからこそオーバーヘッドが計測できるわけですが、逆に言えば、構造化されたメッセージの外にある創発的なやりとりは、そもそも発生しようがないのです。

　さらに、人間のチームには「共有された歴史」があります。過去のプロジェクトで一緒に修羅場をくぐった記憶、あのリリースで感じた達成感。こうした蓄積が暗黙知となり、「あうんの呼吸」を生み出します。AIエージェントには、この歴史がない。先ほど述べたように、メモリ機能やルールファイルで一定のコンテキストを引き継ぐことはできます。しかし、それは「前回のプロジェクトではこういう判断をした」という事実の記録であって、「あのとき一緒に苦労したから、今回も信じて任せよう」という関係性の蓄積ではありません。人間のチームが共有するのは情報だけでなく、経験を通じて醸成された判断の基盤なのです。

　現状のマルチエージェントシステムは、「チーム」というよりも「パイプライン」に近い存在です。入力を受け取り、処理し、次に渡す。高度に構造化されていますが、そこに創発は起こりません。

　以前この連載の第4回で、AIエージェントを「同僚」として擬人化することの危険性を論じました。個々のエージェントに対する擬人化が判断停止や責任の曖昧化を招くように、複数のエージェントを「チーム」と呼ぶことにも同じ罠が潜んでいます。私たちは「マルチエージェントチーム」という言葉を使うとき、無意識のうちに人間のチームの持つ豊かさ――信頼、歴史、即興的な助け合い――を投影してしまっています。しかし実際に動いているのは、構造化されたメッセージを決められたプロトコルに従って交換するプロセスの集合体です。それは優秀な「パイプライン」ではあっても、「チーム」ではない。個体レベルでも集団レベルでも、擬人化は期待を膨らませ、幻滅への最短距離を作り出します。

エージェント時代の「棟梁」になる

　ここまで書くと、「じゃあマルチエージェントは使えないのか」と思われるかもしれません。そうではありません。道具の使い方を間違えているだけなのです。

　Anthropicのエージェント設計ガイドには、こんな一節があります。「最もシンプルな解から始め、成果が実証できたときにだけ複雑性を上げよ」。これはマルチエージェント否定論ではありません。むしろ、タスクの性質に応じて最適なアーキテクチャを選べ、という設計原則です。

　実際、並列で独立したタスクを処理する場面──大量の情報ソースを同時に調査する、複数のドメインの専門知識を組み合わせる──では、マルチエージェントは大きな成果を出しています。問題は「何でもかんでも複数にすればいい」という思考停止であって、マルチエージェントという技術そのものではありません。

　では、どう設計すればいいのか。先ほどの外科医チームモデルが、そのまま指針になります。

　中核となるオーケストレーターが全体の設計と判断を担い、専門化されたサブエージェントがそれぞれの領域でタスクを実行する。全員が何でもやるのではなく、明確な役割分担の下で動く。エージェント数は3〜5体程度に抑える。Anthropicの自社システムも、Googleの研究結果も、この構成が最も合理的であることを示しています。

　何より大事なのは、自分自身がオーケストレーターになるという意識です。エージェントの出力をレビューし、全体の整合性を取り、「何を作り、何を省くか」を判断する。その時間を、プロジェクト計画に最初から組み込んでおくこと。レビュー時間が91%増えるという数字は、決して驚きではなく、設計段階で織り込むべき定数なのです。「エージェントに任せたから自分は楽になる」のではなく、「エージェントに任せた分、レビューと統合に集中する」という覚悟が要ります。

　pandasの作者であるウェス・マッキニー（Wes McKinney）は、O'Reillyに寄稿した論考「The Mythical Agent-Month」の中でこう述べています。最も多くのエージェントを走らせ、最も多くのトークンを消費する開発者が成功するのではない。プロジェクトの概念モデルを頭の中に保持し、何を作り何を省くかを見極める「審美眼」を持つ開発者こそが、この時代を生き抜くのだと。

　日本の建築には「棟梁」という存在があります。自ら釘を打つだけでなく、建物全体の構造を見渡し、職人たちの仕事を束ね、最終的な品質に責任を持つ人です。棟梁は木の癖を読み、どの材をどこに使うかを判断します。全ての釘を自分で打つわけではありませんが、必要なときには自らノミを握る。釘を打つこと（コードを書くこと）をやめるわけではなく、それだけが仕事ではなくなるのです。

　エージェント時代のエンジニアに求められるのは、まさにこの棟梁の視座ではないでしょうか。最も多くのエージェントを走らせる人ではなく、何を作り何を省くかの審美眼を持つ人。コードの量ではなく、プロダクトの輪郭を描ける人。それが、この時代の棟梁になるのだと、私は考えています。