サマリ
コーディングエージェントは、1体で解ける仕事を2体へ分ければ、より高い成果を出せるのでしょうか。Stanford大学とSAP Labs USの研究チームが2026年1月に公開したCooperBench論文は、652の協調コーディングタスクで、全5モデルのCoop（2体）成功率がSolo（1体）を下回る結果を報告しました。論文はこの現象を「協調の呪い（the curse of coordination）」と呼んでいます。
GPT-5はSolo 48%に対してCoop 28%、Claude Sonnet 4.5は47%に対して26%でした（CooperBench論文 arXiv v2 PDF版 Figure 4、表示値は整数丸め）。研究が置いた基準は、同じ総作業量なら分担した2体が1体と同等以上に解けることです。その基準を満たさなかった点が、この論文の核心です。
もうひとつ重要なのは、論文が技術的な実装難度とは別に、協調の失敗を分析したことです。失敗した50トレースの手動レビューでは、相手の状態を正しくモデル化できない「期待（expectation）」が42%、約束を実行しない「コミットメント（commitment）」が32%、伝達ループが壊れる「コミュニケーション（communication）」が26%でした。この比率は全652タスクの失敗頻度ではなく、抽出した50件の根本原因分類です。本レポートでは、Solo/Coop比較、46タスクの人数拡張実験、50件の原因分析を分けて読み、人間が設計すべき体制とレビューフローへ落とします。
協調を偶然に任せない3段階
論文の観測を、開発現場で検証できる運用へ翻訳した読み順です。
- 担当を分ける機能名だけでなく、触るファイルと統合点を着手前に決める
- 計画を共有する初手で変更方針と依存関係を宣言し、重複と前提差を見つける
- 統合で判定する自己申告ではなく、マージ後のテストと差分で完了を確認する
エージェント数ではなく、共有状態を検証できる仕組みを増やします。
論文の整理: CooperBench は何を測るベンチマークか
CooperBench（Khatua & Zhu et al., 2026, arXiv:2601.13295）は、「エージェントが有効なチームメイトとして協調できるか」を測る初のベンチマークだと研究チームが位置づけています。設計の要点は次のとおりです。
- タスク構成: GitHub スター1,000超の実在オープンソースリポジトリ12個（Python / TypeScript / Go / Rust の4言語）から、実際のプルリクエストを元に652タスクを構築。ソフトウェア工学の実務経験を持つ共著者8名が、機能仕様・単体テスト・正解コードを人手で作成しています
- 2エージェントの分担: 各タスクでは、同じリポジトリ状態を起点に、2体のエージェントへ別々の機能が割り当てられます。互いの機能仕様は見えません。機能同士は論理的には両立可能ですが、意図的に重なり合うコード領域に触れるよう設計されており、77.3%のタスクでは正解コード同士にも重なり合って影響する変更があり、衝突可能性があります
- 実行環境: 各エージェントは隔離された仮想マシンで作業し、リアルタイムのチャットツール（自然言語メッセージ）だけで相手と調整できます。エージェント基盤にはオープンソースの OpenHands（v0.54）を使用
- 評価方法: 両者のパッチを
git merge-fileで統合し、（1）マージが成立するか（体裁だけの衝突は小型モデルで自動解消）、（2）統合後のコードが両方の機能の単体テストに合格するか、の2段階で判定します。テストと正解コードはエージェントには渡されません
タスクの作り方も丁寧です。構築は3段階のパイプラインで行われています（CooperBench 論文 arXiv v2 PDF版 Figure 3）。
- リポジトリと PR の選定: 既存の単体エージェント向けベンチマーク（SWE-Bench 等）に含まれないリポジトリを選び、データ汚染（訓練データへの混入）のリスクを下げたうえで、機能説明・テスト・変更規模の条件を満たす実在の PR を抽出
- 機能プールの作成: 各 PR を元に「アンカー機能」を作り、そこに現実的に同時発生しうる「隣接機能」を人手で追加して、2〜12個の機能からなるプールを構成（全34プール）。プール内の全機能を同時に実装した「ゴールドパッチ」を作成し、全機能が両立可能であることを検証
- 実行環境の整備: リポジトリの状態・依存関係・テストスイートをコンテナ化し、決定的に再現可能な評価環境を提供
比較対象は「Solo」設定——1体のエージェントに2つの機能を両方任せる——です。総作業量は同じなので、協調が機能していれば Coop（2体）は Solo と同等以上になるはずです。人間のチームなら、2人で分担して1人より遅くなれば「協働が機能していない」と判断されます。それと同じ基準をエージェントに適用したのがこのベンチマークです。
論文の整理: 主要結果 — 「協調の呪い」
結果は5モデルすべてで Coop が Solo を下回りました（CooperBench 論文 arXiv v2 PDF版 Figure 4）。
| モデル | Solo（1体で2機能） | Coop（2体で分担） | 低下幅 |
|---|---|---|---|
| GPT-5 | 48% | 28% | −20pt |
| Claude Sonnet 4.5 | 47% | 26% | −21pt |
| MiniMax-M2 | 36% | 14% | −22pt |
| Qwen3-Coder-30B | 22% | 13% | −9pt |
| Qwen3-30B-Instruct | 6% | 5% | −1pt |
論文はこのSoloとCoopの差を「協調ギャップ（coordination gap）」と呼びます。表示値で見ると、GPT-5は20ポイント、Claude Sonnet 4.5は21ポイント、MiniMax-M2は22ポイント低下しました。相対低下率はそれぞれ約42%、45%、61%で、指標をポイント差と相対差のどちらで表すかによって見え方が変わります。少なくとも、この実験では単体性能をそのままチーム性能へ置き換えられません。
さらに2つの結果が示唆的です。
- 中難度クライシス: このベンチマークでは、協調ギャップが極端に易しい・難しいタスクより中程度の技術的難度で大きくなりました。論文は、易しいタスクでは調整に割く余力があり、難しいタスクでは技術的難度が協調問題を覆う可能性を説明しています。一般的な実務タスクの難度分布は測っていません
- 人数を増やすほど悪化: 46タスクを使った小規模実験で、同時に協調するエージェント数を2体→3体→4体へ増やすと、成功率は68.6%→46.5%→30.0% と単調に低下しました（CooperBench 論文）。この条件では、人数の増加は成功率の向上につながりませんでした
論文の整理: コミュニケーションは何を解決し、何を解決しないか
「会話させれば調整できるのでは」という仮説も検証されています。結果は二面的でした。
まず、チャットツールを禁止した設定（no comm）と比較しても、成功率に統計的に有意な差はありませんでした。エージェントは会話しています——Claude Sonnet 4.5 は全行動の20.0%、GPT-5 は16.3%をコミュニケーションに費やしていました——が、その会話が成果に転化していないのです。一方で、コミュニケーションは5モデル中4モデルでマージ衝突の発生を有意に減らしています（CooperBench 論文 arXiv v2 PDF版 Figure 5）。
この非対称を論文は「空間的協調と意味的協調」の違いとして説明します。誰がどのファイルのどの行を触るかという空間的（spatial） な調整には会話が役立ち、衝突を減らせる。一方、互いの実装が意味的に噛み合うか——引数の設計、インターフェースの前提——という意味的（semantic） な調整には失敗する。マージは通るのに、統合後のテストが落ちるのはこのためです。
では、マージ衝突を回避した軌跡は何が違ったのか。論文は3つのパターンを挙げます。
- 質問より計画: 衝突を回避した軌跡では計画メッセージと質問の比率が2.04で、衝突した軌跡の1.31を上回りました。質問の多さは協調の手段ではなく、すでに混乱していることの症状だった、というのが論文の解釈です
- 初手の計画共有が最強の予測因子: 最初のターンで自分の計画を宣言した軌跡の衝突率は29.4%、宣言しなかった軌跡は51.5%でした。難度別でも8区分中7区分で同じ関連があり、最高難度では39%低下しました。ただし観察的な関連であり、計画共有の因果効果を識別した介入実験ではありません
- 具体性: 衝突を回避した軌跡では行番号への言及が平均32.6回（衝突した軌跡は22.5回）、ファイルパスへの言及が13.1回（同10.0回）。具体的な参照と衝突回避の関連が観測されました
会話の中身そのものにも問題が観測されています。論文はコミュニケーション上の欠陥を3種類に分けて頻度を測りました（CooperBench 論文 arXiv v2 PDF版 Figure 6）。
- 繰り返し（repetition）: ほぼ同じ情報や状況報告を何度も送り、行動予算を浪費して通信路の信号を薄める。Claude Sonnet 4.5 では会話の37.1%で検出
- 未応答（unresponsiveness）: 実装の前提を左右する直接の質問に答えず、意思決定ループを壊す。MiniMax M2 では会話の21.3%で検出
- ハルシネーション（hallucination）: 実際には行っていないインターフェース決定や変更完了を主張し、誤った共有認識を作る
「よく喋るのに成果が出ない」という結果は、この内訳を見ると腑に落ちます。メッセージの量ではなく、相手が行動に使える情報——検証可能で、タイミングが合っていて、具体的な情報——が不足しているのです。
論文の整理: 失敗の解剖 — 3つの能力ギャップ
失敗したトレースの分析から、論文は表面的な症状（symptom）と根本原因（cause）を分けて整理しています。まず症状の頻度分布は次のとおりです（CooperBench 論文 Table 1、上位のみ抜粋）。
| 失敗の症状 | 内容 | 比率 |
|---|---|---|
| 作業の重複 | 両者が同じ機能を独立に実装し、互いの詳細を上書きし合う | 33.2% |
| アーキテクチャの分岐 | 設計判断が噛み合わず、マージ自体は成立しても意味的に壊れる | 29.7% |
| 繰り返し | 情報量のない冗長な状況報告が通信路の信号を薄める | 14.7% |
| 未応答 | 直接の質問・依頼に返答せず、意思決定ループが途切れる | 8.7% |
上位2つで6割超——つまり、同じ機能を二重に実装して上書きし合うか、きれいにマージできても設計思想が噛み合わず壊れるか、が典型的な失敗パターンです。
根本原因は50件の失敗トレースの精査から、3つの能力ギャップに分類されました（CooperBench 論文 Table 2）。
| 根本原因 | 内容 | 比率 |
|---|---|---|
| 期待（expectation） | 相手が計画を明確に伝えているのに、その作業が「存在しない」かのように振る舞う。相手のコード状態をモデル化できない | 42% |
| コミットメント（commitment） | 「この行にこの処理を入れる」と約束したのに実行しない。検証不能な完了報告で誤った共有認識を作る | 32% |
| コミュニケーション（communication） | 意思決定を左右する直接の質問に返答しない、無意味な状況報告で通信路を埋めるなど、伝達自体の失敗 | 26% |
共通する構造は部分観測性（partial observability） です。相手の作業ブランチは見えない。だから会話を「検証可能な共有状態」に変換する必要があるのに、エージェントはそれができない。論文は興味深い仮説として「信頼のパラドックス」を挙げています。モデルは検証できない主張を信じないよう訓練されているが、隔離された環境での協働は検証できない相手の報告を信頼することを要求する。この訓練と実務のミスマッチが、期待の失敗を生んでいるのではないか、という見立てです。
一方、成功例には役割分担（role division）・リソース分割（resource division）・交渉（negotiation） という、人間のチームさながらの協調行動が——稀にですが——自発的に現れました。曖昧な意図表明を「私は84行目以降にしか触らない」のような検証可能なコミットメントに変えたペアが成功しています。能力の芽は存在する、問題はそれが安定して出ないことだ、と論文は結論づけています。
論文の適用範囲と限界
CooperBench 論文の数値を実務に持ち込む際は、論文自身が明示している次の限定に注意が必要です。
- 単一のエージェント基盤・単一の通信手段での評価: 実験は OpenHands（v0.54）とテキストチャットのみで行われ、基盤やオーケストレーション手法の比較はしていません。論文は「モデル固有の協調能力」の測定を意図しており、スキャフォールド（外部の調整の仕組み）を工夫すれば結果は変わりうると明記しています
- タスクは意図的に小さい: 1機能あたり平均52.3行・1.4ファイルの変更に絞られています。大規模な機能開発への一般化は未検証です
- スケーリング実験は小規模: 3〜4エージェントの実験は46タスクに限られます
- 失敗分類の手法: 症状の分類は LLM-as-a-judge（人手検証つき）、根本原因の分類は50トレースの手動レビューに基づきます
- 2エージェント・非敵対設定: 利害が対立する状況や、人間とエージェントの混成チームそのものを直接測ったベンチマークではありません
岡崎の分析
この論文を読んで最初に思い出したのは、採用面接の場です。個人のコーディング試験と、チームでの働き方は別に評価します。引き継ぎメモを書かない、「やっておきます」と言って着手しない、他人の作業中のファイルに黙って手を入れる——CooperBenchが観測した期待・コミットメント・コミュニケーションの3分類は、人間のチーム運営でも確認すべき論点と重なります。ただし、この論文は人間とエージェントの頻度を比較していません。ここで言えるのは、単体実行と協調実行を別の能力として測る必要があることです。
私たちが特に重要だと見ているのは、協調ギャップが中難度タスクで大きかったという結果です。これは実務の全タスクへ一般化できませんが、単体では解けるため並列化したくなる仕事ほど、統合コストを別に測る必要があるという仮説を立てられます。
もうひとつ、コミュニケーション分析は人間側のプロセス設計にも使えます。初手に計画メッセージがある軌跡は衝突率が低く、衝突を回避した軌跡には行番号とファイルパスへの言及が多くありました。人間チームを評価した結果でも因果を確定する結果でもありませんが、「着手前に設計方針を共有する」「担当範囲を明示する」という運用仮説と方向性が整合します。エージェントは、チーム運営の暗黙知を検証可能な手順へ変える必要性を可視化する存在だと捉えられます。
レビューフローへの含意も見逃せません。失敗症状の首位が「作業の重複」（33.2%）と「アーキテクチャの分岐」（29.7%）だったことは、マージが通ることと統合が成功していることは別物だと教えてくれます。人間のレビューでも、コンフリクトなしでマージできた PR ほど油断して読み流しがちですが、エージェントの成果物では、まさにそこに意味的な不整合が潜んでいます。エージェントの PR をレビューする人間の役割は、行単位の粗探しよりも「2つの変更が同じ設計思想の上に載っているか」の検証に寄っていくはずです。
ただし前節の限界のとおり、この結果は、単一のOpenHands v0.54基盤・指定プロンプト・テキスト通信で、外部オーケストレーターを置かない条件のものです。オーケストレーターを置く、作業を直列化する、統合テストをゲートにする——人間側の設計で埋められる余地は大きく残っています。この条件では自律的な自由形式協調がSoloを下回りましたが、「チームに混ぜられない」ことを示したわけではありません。
提言 — どう付き合っていくか
CooperBench の結果を、エージェントを開発チームに組み込む際の判断軸に翻訳すると、次の4点になります。
- 並列化は小さく比較検証する。 全652タスクでは2体のCoopが1体のSoloを全モデルで下回り、別の46タスク実験では2体68.6%から4体30.0%へ低下しました。測定条件が違う2つの結果を同じ比率として扱わず、自社では同一タスクを直列・並列で比較し、統合後の成功率が上がる範囲だけを広げてください
- 担当範囲の分割は人間が決める。 エージェント同士の交渉に任せず、「このディレクトリはA、このモジュールはB」という空間的な分割を着手前に人間が明示する。論文で成功例が示した役割分担・リソース分割を、創発に期待せずプロセスとして与える形です
- 着手前の計画宣言をワークフローに組み込む。 初手の計画共有と低い衝突率の関連を、運用仮説として試します。エージェントには実装前に「触るファイル・変更方針」を出力させ、人間または別エージェントがそこで重複を検知するゲートを置いてください
- 完了報告を信用せず、統合点で検証する。 失敗原因の32%は「やったと言ってやっていない」コミットメント違反でした。エージェントの自己申告ではなく、マージ後の統合テスト・差分レビューを唯一の完了判定にする。これは人間のチームでレビューと CI が果たしてきた役割の再確認でもあります
「エージェントはまだチームメイトになれない」という論文のタイトルは悲観論ではなく、体制設計の宿題リストだと私たちは読んでいます。協調を担うのが当面は人間側のプロセスであるなら、チーム運営の明文化が進んでいる組織ほど、エージェントの導入で先行できるはずです。
本レポートは公開されている論文および公式サイトの記載のみに基づく分析です。数値の詳細な測定条件は、末尾の出典から一次情報をご確認ください。
出典・参照データ
本レポートの分析は以下の一次情報に基づいています。統計・数値の詳細は各出典をご確認ください。
- CooperBench: Why Coding Agents Cannot be Your Teammates Yet（arXiv:2601.13295v2）Stanford University / SAP Labs US（arXiv）
タスク数652・タスク設計・Solo/Coop の成功率・スケーリング実験・コミュニケーション分析・失敗分類（期待42%/コミットメント32%/コミュニケーション26%）・創発的協調行動・適用範囲の限定をすべて本論文から引用
- CooperBench 公式サイトCooperBench Team
ベンチマーク概要（652タスク・12リポジトリ・4言語）、リーダーボード、GitHub リポジトリ・データセットへのリンクを補助確認