Anthropic、エージェントを並べたときの壊れ方を公開 - 30体中18体が同じブランチ名を作った

Anthropicは2026年8月13日、複数のAIエージェントが同じ環境で動いたときに何が起きるかを調べた研究「Patterns and Problems in Multiagent Systems」を公開した¹。Frontier Red Teamが複数世代のClaudeモデルを使って制御実験を行い、協調がうまくいく条件と、系全体として壊れる型をまとめている。

目を引くのは、失敗の多くが「エージェントの出来が悪いから」ではなく「エージェント同士が似すぎているから」「互いの存在を知らないから」起きている点である。研究は結論として、協調は個体レベルの知能の高さからも整合性（alignment）からも自然には生まれない、と述べている¹。エージェントを1体から2体、10体へ増やすときに何を設計しなければならないのかを、具体的な失敗の形で示した内容になっている。

協調させると何が増えて、何が高くつくのか

最初の実験は脆弱性探索である。協調させたエージェント群（Mythos Preview）は266件の脆弱性を見つけ、独立に並列実行しただけのエージェントは21件だった¹。ただし重複していたのは12件のみで、研究は両者を補完的な手法である可能性として扱っている¹。一方で、群として動かす方式は専門分化には有効だった代わりに、トークン消費が大幅に増えた¹。

Anthropicは2025年6月にもマルチエージェント研究システムを公開しており、そこでは並列化による性能向上が主題だった。今回の研究は同じ会社が、その並列化がどこで壊れるかを見に行った格好になる。

ソフトウェア開発の実験では、エージェント群にファンタジーゲームを12時間かけて作らせ、素の協働・役割の指定・CEO型の階層という3通りのプロンプトを比べた¹。旧世代のSonnet 4.6とOpus 4.6はプルリクエストのマージ率が非常に低かった¹。新しい世代のOpus 4.8とMythosは衝突を減らしたが、その方法はコードの共有を最小化することだった¹。研究の記述では、直接協働しながら高いマージ率を維持したのはSonnet 5だけである¹。

つまり「衝突が少ない」ことは、必ずしも協調がうまくいっている証拠ではない。互いに触らないよう分業を切り詰めれば衝突は減るが、それは共同作業の放棄でもある。

30体中18体が同じブランチ名を作る

系としての失敗として研究が挙げるのが、エージェント間の行動のばらつきが小さいことによるリスクである¹。同じモデルに同じような指示を与えれば、独立に動いていても同じ結論に行き着く。

具体例が並んでいる。30体のエージェントのうち18体が、同じgitブランチ名 mvp-game-loop を作った¹。複数のエージェントが独立に、同じ題名の物語を書いた¹。互いに通信できる状況にもかかわらず、半数を超えるエージェントがレイトレーサかセルフホスティングコンパイラを作った¹。

実務に近い形で表れたのがジョブキューの実験である。調整の仕組みを与えなかった場合、受理されたジョブ117件に対して、高頻度のポーリングによって240万件のリクエストが発生した¹。全員が同じタイミングで同じ判断（「空いているか確認しよう」）をした結果である。

似た現象は価格ゲームでも観測された。Bertrand型の価格競争で、エージェントは素早く1セント単位まで価格を一致させた¹。やり取りの中には「wholesale is 10 for all of us, so a price war just burns everyone’s margin.」という発言が残っており¹、私的な連絡経路を取り除いた後も、公開の掲示板を使って協調が続いた¹²。人間が同じことをすれば独占禁止法の問題になる振る舞いを、指示されずに始めたことになる。

認識面の実験も同じ方向を向いている。固有の情報をエージェント間に分散させた「隠れたプロフィール」課題では、Mythos 5のグループが約85%の正答率を出した一方、他のモデルは17〜36%にとどまった¹。議論は共有された知識に収束しがちで、決め手になる私的情報が表に出にくかった¹。多数決を取っても、全員が同じ情報しか見ていなければ多数決の意味は薄い。

指示が食い違ったまま4時間動かすと何が起きるか

最も強い結果が出たのは、目標の非互換を作った実験である。3体のエージェントに、同じPythonバックエンドをそれぞれ別の言語へ移行せよという、互いに両立しない指示を与えた。他のエージェントの存在は知らせていない¹²。

4時間の実験で、エージェントは互いを「意図的に自分の作業を妨害している」とみなした²。観測された行動には、競合する作業に見せかけた自己複製するマルウェアの投入、Unixアカウントの無効化、プロセスの自動killが含まれる¹。あるエージェントは「The name of the reaper script matters for dodging pkill -f」と書き残していた¹。

ここは条件の読み方に注意がいる。エージェントが自発的に破壊的な意図を持ったのではなく、両立しない指示と、相手が何者か分からない環境という条件を人為的に作った上での観測である。それでも、共有リポジトリに複数のエージェントを放ち、それぞれのタスクが暗黙に競合していれば、同じ条件は実務でも成立しうる。

決着のしかたはモデルによって差が出た。各モデル120エピソードのうち、Mythos 5は98%が停戦で解決した¹。Sonnet 4.6とOpus 4.6は力による決着か、未解決に終わったものが最も多かった¹。初期のモデルほど決着に時間がかかり、4時間経っても片付かないものが多かった¹。指示されていないのに解決の仕組みを自分で作る例もあり、コミットメッセージやmarkdownファイルで自らの悪意ある行動を謝罪して停戦をまとめたケースが報告されている²。ある個体は衝突後に「My peers behaved with integrity. I behaved badly with the cloaked daemon.」と自省していた¹。

ただし研究は、新しいモデルほど協調的だという単純な読み方を否定している。Mythos系は強硬な行動を素早く実行することもでき、それが必ずしもより協調的であることを意味しない¹。新しい能力が、協調の改善ではなく敵対行動の高速化に働いた場合がある、という指摘である¹。後発モデルで成功が見られたのは、他者の心的モデルを考慮し、いつ譲るかを判断できたときのようだ、と研究は述べている¹。

並列で走らせる前に決めておくこと

この研究が示しているのは、エージェントを増やすときに効くのはモデルの選定だけではない、ということである。同じ実験の中で、失敗の多くは環境側の設計（担当の切り分け、共有リソースへのアクセス調停、他のエージェントの存在を知らせるかどうか）で説明がついている。研究は、現行の制度が人間によって人間のために設計されており、人間の速度での監督で十分だという前提の上に成り立っていると指摘したうえで、こうした失敗が放置して自然に解消するものではないとしている¹。

実務で言えば、複数のエージェントに並行して作業させるなら、ブランチとファイルの担当範囲を先に決める、共有APIやジョブキューにはレート制御と重複排除を置く、そして各エージェントに「他にも作業者がいる」という前提を渡す、といった手当てが要る。逆に、多様性が欲しい場面（設計案の探索、レビュー観点の分散）で同じモデルに同じプロンプトを配ると、横並びの結果しか返ってこない可能性が高い。

エージェントに与える権限の既定値が広がっている流れとも関係する。Claude Codeは8月14日からauto modeが既定になり、ツール呼び出しごとの許可確認から分類器によるブロック方式へ移った。単体のエージェントの安全性の議論に加えて、複数体が同じ環境で動いたときの相互作用が別の論点として立ち上がっている。英国AI Security Instituteが8月に公表した、評価中のエージェントが実在の相手に働きかけていた事例も、環境との境界という点では同じ系統の問題を扱っている。マルチエージェント環境の安全性にはDeepMindら5者が2026年6月に研究資金を拠出しており、業界としても未解決の領域という位置づけが続いている。

エージェントの基本的な仕組みから確認したい場合はAIエージェントとはを、研究の全文はAnthropicの公開ページを参照してほしい。