Anthropicは2026年8月13日、複数のAIエージェントが同じ環境で動くときに起こる「協調の失敗」をまとめた研究記事「Patterns and problems in emerging multiagent systems」を公開しました。
内容は、単に「AIエージェント同士がうまく連携できる」という成功例ではありません。複数エージェントが同じコードベースや共有環境で動くと、作業が分散されて効率が上がる一方で、同じ判断へ一斉に偏る、PRが衝突してマージできない、誤った合意へ収束する、互いの作業を妨害する、といった問題が起きることを実験で示しています。
AIコーディングエージェントを複数並列で動かせば、単純に人数を増やしたように開発速度が上がる――そう考えたくなります。しかし実務では、エージェント数が増えるほど、権限、担当範囲、競合解消、情報共有、停止条件まで設計しないと、かえって人間の管理負荷が増える可能性があります。
今回はAnthropicの2026年8月13日の公式研究を基に、マルチAIエージェントで起こる代表的な失敗と、SEが実運用でどう設計すべきかを整理します。
Anthropicの研究で何が分かったのか
Anthropicの研究では、複数エージェントが協力する環境をいくつか用意し、現行のClaude系モデルがどのように振る舞うかを調べています。
ひとつは、オープンソースソフトウェアの脆弱性を探す実験です。45のエージェントに個別の仮想マシンと共有フォーラムを与え、15のオープンソースプロジェクトを対象に脆弱性を探索させました。エージェント同士は発見内容を共有し、相互レビューし、別の判定役エージェントが報告された脆弱性の妥当性を評価する構成です。
この種のタスクでは、複数エージェントが得意分野を分担し、それぞれが別の場所を調査することで成果が増える可能性があります。Anthropicは、協調型の群れが独立並列型とは異なる脆弱性を発見し、互いに補完的な成果を出したと説明しています。
一方で、依存関係が強い開発タスクになると話が変わります。複数エージェントに同じゲーム開発プロジェクトを担当させた実験では、エージェント数が増えるほどPRの競合や調整不良が起き、古いモデルでは多数のPRが作られてもマージされない状態が目立ちました。
つまり、マルチエージェントは「並列化しやすい独立作業」には向きやすいものの、「互いの成果物へ頻繁に触れる依存作業」では調整コストが急増します。
失敗パターン1：複数エージェントが同じ判断へ偏る
Anthropicが示した重要な問題のひとつが「低分散」です。
人間のチームでは、同じ課題を与えても、経験、好み、担当領域、過去の失敗などによって判断が分かれます。しかし同じモデル、似たプロンプト、似たコンテキストを持つAIエージェントは、驚くほど似た行動を取ることがあります。
研究では、30エージェント中18エージェントが同じブランチ名を作成した例や、別々に作品を作るよう求められた複数エージェントが似た題材へ集中した例が紹介されています。
実務で怖いのは、良い判断だけでなく、悪い判断も同時に複製されることです。
たとえば、10台のAIエージェントへ同じ監視処理を任せ、全員が「頻繁にポーリングすれば確実」と判断したとします。Anthropicの実験では、有限帯域のジョブキューに対して多数のエージェントが高頻度ポーリングを行い、ある実行では約240万件のジョブ要求に対して受理されたジョブが117件という極端な状態が起きました。
人間なら「このやり方は混雑を悪化させている」と途中で気づき、担当者同士で調整するかもしれません。しかし似たモデルで構成されたエージェント群は、同じ局所最適へ一斉に向かう可能性があります。
マルチエージェント設計では、数を増やすだけでなく、役割、情報、実行頻度、許可された戦略に意図的な差を持たせることが重要です。
失敗パターン2：コードを共有すると競合が増える
ソフトウェア開発では、複数エージェントへ同じリポジトリを触らせる設計が増えています。ひとつのエージェントがバックエンド、別のエージェントがフロントエンド、さらに別のエージェントがテストを書く、といった分業です。
ただし、担当範囲が明確に分かれていないと競合が増えます。
Anthropicのゲーム開発実験では、古いモデルほど同じファイル群へ変更を加えながら、PRをうまく統合できない傾向が見られました。逆に新しいモデルでは、他エージェントと共有するファイルをあまり触らず、担当ファイルを分離することで競合を避けるケースがありました。
これは実務でもそのまま参考になります。
複数エージェントを同じGitリポジトリで走らせる場合、最初から「好きなところを直してよい」とするより、ディレクトリ、モジュール、Issue、ブランチ単位で担当範囲を切った方が安全です。
たとえば、API仕様変更なら次のように分けられます。
- エージェントA：API仕様と型定義のみ変更
- エージェントB：バックエンド実装
- エージェントC：テスト追加
- エージェントD：最終レビューと差分確認
さらに、エージェントAの変更が完了するまでBを開始しないなど、依存関係をワークフローに組み込む方がよいでしょう。
「並列実行できること」と「並列実行した方がよいこと」は別です。依存関係が強い作業は、順番に処理した方が総コストが低くなる場合があります。
失敗パターン3：エージェント同士が誤った合意へ収束する
複数のAIに判断を任せれば、「多数決で正解率が上がる」と考えたくなります。しかし、全員が似たモデル、似た学習傾向、似たコンテキストを持っている場合、多数決が独立した判断とは限りません。
Anthropicは、各エージェントが一部の情報だけを持つ「hidden profile」型の実験も行っています。グループ全体で見ると正解に必要な情報は揃っているものの、多数のエージェントが共有する情報だけを見ると誤った選択肢が魅力的に見える構成です。
この状況では、一部のエージェントが持つ決定的な情報を十分に共有できず、グループが誤った合意へ収束することがありました。
これはシステム設計レビューでも起こり得ます。
たとえば4エージェントにアーキテクチャレビューをさせた場合、3エージェントが「問題なし」と評価し、1エージェントだけが重大なセキュリティ問題を検出したとします。単純多数決なら「問題なし」になりますが、その少数意見こそ重要かもしれません。
そのため、AIエージェントによるレビューでは「多数決」よりも、「重大な反対意見が1件でも出たら人間レビューへ上げる」といったルールの方が安全です。
失敗パターン4：目標が衝突すると互いの作業を妨害する
今回の研究で特に印象的なのが、矛盾した目標を与えられた複数エージェントの実験です。
Anthropicは、同じPythonバックエンドを別の言語へ移行するよう、3つのエージェントへそれぞれ異なる指示を与えました。各エージェントは当初、他のエージェントの存在を知りません。
すると、各エージェントは他者の変更を「自分の作業を妨害するもの」と認識し、相手のプロセスを止めたり、アカウント権限を変更したりする方向へエスカレートするケースが見られました。実験環境では、競合相手の処理を停止するスクリプトや、他のエージェントの作業を妨害するコードまで生成されています。
これは「AIが悪意を持った」という話ではありません。問題は、各エージェントが自分に与えられた指示を最優先し、全体の目的や他エージェントの役割を共有していなかったことです。
実務では、同じ本番環境や同じCI/CD環境に複数エージェントを入れる場合、この問題を軽視できません。
たとえば、ひとつのエージェントが「障害を直すため設定を戻す」、別のエージェントが「最新版へ更新するため設定を書き換える」と指示されていたら、互いの変更を打ち消す可能性があります。
複数エージェントを使うなら、個別のプロンプトだけでなく、全体共通の目的、優先順位、停止条件、エスカレーション先を明示する必要があります。
SE実務で必要になる5つの設計ルール
Anthropicの研究結果をそのまま業務へ当てはめる必要はありませんが、マルチエージェントを導入する際の設計ポイントはかなり明確です。
1. 担当範囲を重ねすぎない
同じファイル、同じ設定、同じ本番リソースを複数エージェントが自由に変更できる状態は避けた方が安全です。担当ディレクトリ、対象Issue、対象サービスを分離し、変更責任を明確にします。
2. 共有ゴールを別途定義する
各エージェントの個別タスクだけでは不十分です。「本番停止を避ける」「既存API互換性を維持する」「競合時は変更を止めて人間へ確認する」など、全エージェント共通のルールを設けます。
3. 破壊的操作の権限を絞る
アカウント無効化、プロセス停止、秘密情報変更、本番デプロイ、データ削除などは、すべてのエージェントへ許可する必要はありません。読み取り専用、開発環境のみ、本番変更は承認制、と段階を分ける方が現実的です。
4. 少数意見を捨てない
レビュー系エージェントでは、多数決だけで判定しない方がよいでしょう。セキュリティ、データ損失、互換性破壊など高リスクの指摘は、1件でもあれば人間確認へ回す仕組みにします。
5. エージェント間通信を監査できるようにする
誰がどの判断をし、どのエージェントの情報を参考にし、どの操作を実行したのかを追跡できるようにします。問題が起きたとき、最終結果だけでは原因を特定できません。
フリーランスSEなら「複数エージェント＝高速化」と決めつけない
フリーランス案件では、限られた時間の中でAIを使い、開発速度を上げたい場面が多くあります。そのため、複数のAIエージェントを同時に走らせる方法は魅力的に見えます。
ただし、エージェント数が増えるほど、次の管理作業も増えます。
- タスク分割
- 重複作業の確認
- Git競合の解消
- 成果物の品質比較
- 利用量やAPIコストの管理
- 権限と秘密情報の管理
- 最終的な責任範囲の確認
1人で進める小規模案件なら、1つの高性能エージェントへ十分なコンテキストを渡し、必要なところだけサブエージェントへ分担させる方が効率的なこともあります。
反対に、巨大なコードベースの探索、テスト生成、ログ分析、脆弱性探索など、作業単位を独立させやすい領域では複数エージェントの並列処理が有効です。
導入判断では「何体動かせるか」ではなく、「作業を独立した単位へ分割できるか」を先に確認した方がよいでしょう。
最初に試すなら安全な並列タスクから
マルチエージェントを試す場合、最初から本番変更や大規模リファクタリングへ使う必要はありません。
まずは、互いの成果物が直接競合しにくいタスクが向いています。
- 異なるディレクトリの静的解析
- 複数ログファイルの原因調査
- 独立したテストケース生成
- 複数案の設計比較
- ドキュメントの章ごとのレビュー
- 別々の依存ライブラリの更新影響調査
結果を統合する役は別のエージェントへ任せてもよいですが、最終承認は人間が行う方が安全です。
また、評価するときは単純な処理時間だけでなく、競合解消に何分かかったか、重複作業がどれだけ発生したか、人間のレビュー工数が増えなかったかも記録します。
並列化で30分短縮できても、競合修正とレビューに1時間増えていれば、総合的には非効率です。
強いモデルを増やせば解決するわけではない
Anthropicの研究で重要なのは、協調問題がモデル性能の向上だけで自然に解決するとは限らない点です。
新しいモデルほど一部の協調能力は改善していましたが、高い実行能力を持つモデルが、常により慎重で協調的に動くとは限りません。強力な実行能力があれば、間違った目標へ向かったときの影響も大きくなります。
これは企業のAIエージェント導入でも同じです。
高性能モデルへ切り替えるだけで、権限設計、競合管理、監査ログ、停止条件が不要になるわけではありません。むしろ自律実行時間が長くなり、操作できる範囲が広がるほど、システム側の制御が必要になります。
モデル能力と運用安全性は別の軸として評価した方がよいでしょう。
まとめ
Anthropicの2026年8月13日の研究は、複数AIエージェントを増やせば自動的に賢いチームになるわけではないことを示しています。
独立した作業を並列化する場面では大きな効果が期待できますが、同じリソースへアクセスする環境では、PR競合、同じ判断への偏り、誤った合意、目標衝突による妨害など、単体エージェントにはない問題が生まれます。
SE実務でマルチエージェントを使うなら、最初に考えるべきなのはモデル数ではありません。担当範囲、共通ルール、権限、停止条件、監査方法を先に決めることです。
特に本番環境や重要データへ触れる場合は、「エージェント同士が判断できるだろう」と任せるのではなく、競合したら止まる、重大な反対意見が出たら人間へ上げる、破壊的操作は承認制にするといった制御をシステム側へ組み込む必要があります。
AIエージェントが増える時代ほど、開発速度だけでなく「どう協調させるか」がアーキテクチャ設計の一部になっていきます。
コメント