Kiran Gopinathan氏の記事は、かなり刺激的です。主張を一言でまとめるなら、
マルチエージェントによるソフトウェア開発は、結局“分散システム”の問題であり、モデルが賢くなっても協調の難しさは消えない
という話です。
最近は、複数のLLMエージェントに役割分担させて、仕様策定、実装、レビュー、統合までやらせよう、という流れが強いですよね。たしかに夢があります。人間のチーム開発っぽく見えるし、うまく回れば速そうです。
でも著者は、ここにかなり本質的な落とし穴があると言います。
それは「各エージェントが何を作るべきか」を正しく一致させるのが難しい、という点です。
そしてこの難しさは、単なる“AIの知能不足”ではなく、複数の主体が同時に協力して1つの成果物を作るときに必ず出てくる、分散システム固有の問題だ、というのがこの文章の核です。
正直、これはかなり面白い見方だと思います。
AI界隈では「モデルがもっと賢くなれば解決」と言いたくなりがちですが、著者はそこに冷や水を浴びせています。しかも、ただの感想ではなく、分散システム理論を引っ張ってきて理屈を立てているのがいい。
記事では、たとえば「レシピ管理アプリを作って」といったプロンプトを例にします。
この指示は、当然ながらいろいろに解釈できます。
つまり、自然言語のプロンプトは仕様書ほど厳密ではないわけです。
ここでのポイントは、LLMにとって「正解」が1つではないこと。
著者はこれを、ある種の集合として表現します。
簡単に言えば、プロンプトPに対して「この条件を満たすソフトウェア候補の集まり」がある、という考え方です。
この時点で、もう“選択”が必要になります。
どの方向に寄せるか、どの設計を採るか、どの機能を優先するか。
ここがAIの知能だけでは埋まらない部分です。
単一のLLMに「全部やって」と頼むなら、まだ話は単純です。
しかし、複数のエージェントに役割分担させると話が変わります。
たとえば、
みたいな構成です。
すると、各エージェントはそれぞれの部分を作りながら、全体として同じ設計方針に揃えないといけない。
ここでズレると、簡単に破綻します。
たとえばネットワーク担当が callback-style の async API を選んだのに、統合担当が別の前提で組み立てていたら、あとで地獄を見るわけです。
これは開発現場ではあるあるですが、AIエージェントが相手でもまったく同じです。
著者はこれを、分散合意（distributed consensus）問題と見なします。
これはつまり、「複数の参加者が、通信しながら、最終的に同じ判断にたどり着く」問題です。
人間のチームでも難しいのに、LLMエージェントでも当然むずかしい、という話ですね。
ここが著者のかなり強い主張です。
よくある反論はこうです。
著者はこれを、かなりはっきり否定します。
理由はシンプルで、協調の問題はモデルの賢さだけでは消えないからです。
たとえば、どれだけ賢い人間でも、
という問題からは逃げられません。
これはまさに分散システムの世界です。
CPUやメモリの性能を上げても、「複数のノードが同時に動く」という構造そのものが難しさを生む。
著者は、マルチエージェントも同じだと言っています。
個人的には、この指摘はかなり筋がいいと思います。
AIの能力が上がると、つい「全部強くなって終わり」と思いがちですが、問題の種類が違うんですよね。
これは計算能力の問題というより、調整・合意・衝突解決の問題です。
記事の中盤では、分散システムの有名な不可能性結果である FLP theorem が出てきます。
これは超ざっくり言うと、
非同期な分散システムで、1つでも故障の可能性があると、決定的な方法だけで合意を必ず・期限内に達成するのは不可能
という結果です。
ここでいう用語を簡単に補足すると：
著者は、LLMエージェントのやり取りもかなり非同期だと見ています。
メッセージを送っても、相手が読むタイミングは相手次第。
ツール実行が終わるまで待つこともあるし、応答が遅れることも普通にある。
だからFLPの前提がわりと当てはまる、というわけです。
そしてFLPが示すのは、安全性（safety） と 生存性（liveness） を同時に完全には保証できない、という話です。
著者の言い方を借りると、「安全・生存・耐障害性（fault tolerance）は全部は取れない、pick two 的な話」に近いです。
このノリ、かなり分散システムっぽくて好きです。AIの話なのに、結局人類はまた分散システムに戻ってくるのか、という感じがします。
ここも地味に重要です。
マルチエージェントのワークフローって、外から見ると「ちゃんと進んでいる」ように見えることがあります。
でも実際には、
というループに入ることがある。
つまり、進んでいるようで、合意には至っていないわけです。
これは人間の会議でもよくあるやつです。正直、かなりイヤなほどリアルです。
著者はここで、「動いていること」と「合意できていること」は別だと強調します。
これはマルチエージェント設計の大事な盲点だと思います。
記事ではさらに、分散システムで使われる failure detector の話にも触れます。
これは簡単に言うと、「あいつ生きてる？ 死んでる？」を推定する仕組みです。
著者は、共有マシン上で ps | grep claude みたいなことをすると、他のエージェントが動いているか確認できるので、これは failure detector っぽいのでは？ と言っています。
もちろんこれは厳密な理論というより、かなり遊びのある比喩です。
でも発想としては面白いです。
AIエージェントに対して、単に“賢さ”を足すのではなく、死活監視や状態把握の道具を与えることが協調改善に効くのではないかという視点は、かなり実務的でもあります。
個人的には、このあたりは「AIに何を教えるか」より「AIの周辺にどんな仕組みを置くか」が重要だ、という示唆に読めました。
記事は途中で、Byzantine Generals Problem にも話を広げます。
これは「一部の参加者が嘘をつくかもしれない状況で、どうやって合意するか」という分散システムの有名問題です。
ソフトウェア開発の文脈では、エージェントが悪意を持っているとは限りません。
でも、
といった意味では、結果的に“信頼できない参加者”になりえます。
だから、この問題もマルチエージェント開発と相性がいいわけです。
ここでのポイントは、参加者が賢いかどうかではなく、参加者間の通信と信頼をどう設計するかです。
著者は、「マルチエージェント開発なんて無理」と言っているわけではありません。
そこは大事です。
むしろ言いたいのは、
うまくいくかどうかは、モデルの賢さだけではなく、協調のための形式化・ツール・ワークフロー設計にかかっている
ということだと思います。
つまり、今後必要になるのは、
といった設計です。
ここで著者が冒頭で触れていた「multi-agent workflows を記述するための language や scaffolding（足場）」が効いてきます。
単にプロンプトを工夫するだけでは足りなくて、分散した開発を扱うための言語や形式手法が必要ではないか、というわけです。
これはかなり納得感があります。
AIを“頭脳”として見るより、“分散する開発主体”として扱う方が、必要な道具立てが見えやすいからです。
この記事のメッセージを雑に言えば、
ということです。
私はこの主張、かなり好きです。
AI記事って、どうしても「未来は明るい」「モデルがもっと賢くなる」みたいな熱量に寄りがちですが、この記事はその熱に対して、いや、構造的な難しさは残るよね と言っている。
この冷静さがいいんです。
しかも、分散システム理論を持ち込むことで、単なる感想ではなく「なぜ難しいのか」をかなりうまく説明している。
AIエージェントを本気で実運用したい人ほど、こういう視点は避けて通れないと思います。
参考: Multi-agentic Software Development is a Distributed Systems Problem (AGI can't save you from it)
