技術要約: AgentRoom: CRDTベースの共有ワークスペースにおける並行マルチエージェントコーディング

1. 問題提起

並行マルチエージェントコーディングシステムは、マルチファイルプロジェクトにおける分業、冗長性、および並列的な探索の活用を目指している。しかし、既存のアプローチは根本的な調整のボトルネックに直面している。現在のシステムは通常、逐次的なターン制（例：設計 $\to$ 実装 $\to$ レビュー）に依存しており、エージェントは前段のプロセスが完了するのを待機するか、あるいは、エージェントが独立したサンプルを生成して事後的にマージする非協調的な並列処理に依存している。

本論文は、非協調的な並行システムにおける特定の失敗モードとして、**「スタブ作成と離脱（stub-and-exit）」**現象を特定している。これは、単一のエージェントが1つのファイルのスケルトン（骨組み）のみを生成し、タスクが困難すぎると判断して作業を放棄してしまう現象である。さらに、非協調的な並列処理は、明示的な調整なしに複数のエージェントが同じファイルを編集する場合、サイレントなファイルの書き換えや意味的な衝突を引き起こすことが多い。CRDT（Conflict-free Replicated Data Types）は、人間によるチームに対してデータの一貫性を解決するが、バイトレベルの収束を保証するだけであり、意味的な互換性は保証しない。例えば、2つのエージェントが同じオフセットに互換性のない関数シグネチャを挿入した場合、バイトレベルでは正常にマージされるが、コンパイルエラーが発生する。

核心となる研究課題は、CRDTによってマージされた共有ワークスペース上での明示的な調整が、計算リソースを一致させた場合に、逐次的なパイプラインや非協調的な並列処理の両方を上回ることができるか否かである。

2. 手法

システムアーキテクチャ: AgentRoom

AgentRoomは、以下の3つの協調設計されたコンポーネントで構築された、並行コーディングエージェントのための実行環境である。

1. 共有ワークスペース (CRDT基盤): pycrdt（Y.jsのYrsポート）によって媒介される共有ファイルシステム。$\Delta_{crdt} \approx 2$ 秒以内に並行する文字レベルの編集をマージし、強い最終一貫性（SEC）を確保する。
2. 調整インターフェース (MCPツール): エージェントは、非構造化されたチャットではなく、Model Context Protocol (MCP) ツールを介して相互作用する。主なツールは以下の通りである：
   • room_claim(path): ファイルの所有権をアトミックに割り当てる。別のエージェントがパスを保持している場合は拒絶される。
   • room_release(path): 所有権を解放する。
   • room_broadcast/read: ステータス更新のための追記型JSONLメッセージログを維持する。
   • room_state: クレーム（所有権主張）の状態とピアの活動状況を公開する。
3. アドバイザリー・プロトコル: エージェントは6段階のワークフロー（状態の読み取り、ファイルのクレーム、衝突時の修正、書き込み、ポーリング、完了報告）に従う。このプロトコルはプロンプト層における「アドバイザリー（助言的）」なものであり、システムはclaimツールを通じて所有権を強制するが、エージェントは協力することが期待される。この設計はChubbyスタイルのアドバイザリー・ロッキングを模しており、厳格なカーネルレベルのブロッキングなしに、クロスエージェント間のバグ修正（例：あるエージェントが別のエージェントのルーティングエラーを修正する）を可能にする。

実験設定

• モデル: 5つの最先端コーディングモデル（Anthropic Claude Sonnet 4.6, Haiku 4.5; OpenAI GPT-5.4, GPT-5.4-mini; Google Gemini 3 Flash）。
• タスク: 難易度がJWT認証（6ファイル）から二重記帳による財務台帳と不正検知（15ファイル以上）まで多岐にわたる、4つのExpress.js/TypeScriptタスク（T1–T5）。
• ベースライン:
  • Solo: 単一エージェント。
  • Shared-only: MCPツールやコラボレーションプロンプトを持たない、CRDTワークスペース上の複数エージェント。
  • Parallel-merge: 異なるワークスペースで動作する複数のエージェントを、事後的にマージしたもの。
  • ChatDevスタイル: 役割ベースの逐次パイプライン（要件定義 $\to$ 設計 $\to$ 実装）。
• 指標:
  • 品質スコア (Quality Score): 仕様の網羅性、正確性、コード品質、テストの厳密性に基づいてLLMジャッジ（Sonnet 4.6）が算出する複合的な[0, 1]スコア。正規表現およびASTスコアラーによってクロス検証される。
  • 離脱率 (Abandonment Rate): 「1ファイルでの離脱（スタブ作成と離脱）」のバイナリ分類。
  • 創発スコア (Emergence Score, ES): マルチエージェントの平均品質とSoloの平均品質の比率。

3. 主要な結果

Tier I: 分散と離脱の抑制

最も統計的に堅牢な発見は、「スタブ作成と離脱」という失敗モードの抑制である。

• 離脱のオッズ: 12のモデル $\times$ タスクの層全体において、統合されたCochran-Mantel-Haenszel (CMH) 推定値は、SoloエージェントはAgentRoomよりもタスクを離脱（1ファイルでのスタブ作成）する確率が13.7倍高いことを示している（95% CI [3.9, 48], $p < 10^{-5}$）。
• 分散の減少: AgentRoomは、Soloと比較して実行ごとの標準偏差を30–45%減少させる。例えば、T4におけるSonnet 4.6では、$\sigma$は0.23（Solo）から0.14（AgentRoom $\times$2）へと低下した。
• メカニズム: 明示的なclaimプロトコルにより、エージェントが互いの作業をサイレントに上書きしたり、複雑さゆえにタスクを放棄したりすることを防いでいる。これは、エージェントがファイル所有権を調整し、支援を求めることができるためである。

Tier II: 品質と調整のアブレーション

• 調整 vs 並列性: 計算量を一致させた場合、AgentRoom ($\times$2) はParallel-merge（調整なしの並行処理）を大幅に上回る。
  • AgentRoom 平均品質: 0.669
  • Parallel-merge 平均品質: 0.456
  • 差分: $+0.213$ (Welch $t=3.35, p=0.003$)。
  • 洞察: 非協調的な並行処理は、2番目のエージェントが最初のエージェントの作業を上書きしてしまうことが多いため、単一エージェントよりも性能が低くなる。調整こそが、単なる並列化ではなく、品質の主要な推進力である。
• 調整 vs 逐次処理: AgentRoomは、ChatDevスタイルの逐次パイプライン（0.333）を大幅に上回る（0.669）。逐次パイプラインは、各フェーズの境界において離脱の失敗モードを増幅させる。
• コンポーネント分析:
  • CRDT + Prompt (MCPなし): 0.588（Shared-onlyの0.575よりわずかに高い）。
  • 完全版 AgentRoom (CRDT + Prompt + MCP): 0.669。
  • 結論: 最大の性能向上は、単なる共有基盤やコラボレーションプロンプトではなく、**明示的な調整チャネル（MCPツール）**からもたらされる。順序としては、Shared-only < Prompt-only < AgentRoom となる。

スケーリングと不均一性

• エージェント数: 品質は$N=2$のエージェントでピークに達する。$N=3$または$4$に増やすと、単一のブロードキャストチャネルの飽和と調整オーバーヘッドの増加により、収穫逓減または品質の低下を招く。
• 不均一なペア: 強力なモデル（Sonnet）と弱いモデル（Codex）を組み合わせると高いスコア（0.721）を得られるが、弱いモデル（Gemini）と組み合わせると低いスコア（0.542）となる。これは、2番目のエージェントの能力が重要であり、調整がモデルの能力差を消し去るわけではないことを示唆している。
• クロスドメイン: 結果はクロス言語チェック（Rust+axum, Python DevBench）でも保持されるが、サンプルサイズはより小さい。

4. 意義と主張

本論文は、マルチエージェントコーディングにおいて、並行性やCRDT基盤そのものよりも、明示的な調整が成功の主要な要因であることを主張している。

• パラダイムシフト: CodeCRDT（暗黙的かつ観測駆動型の調整と事前割り当てられたロールを使用）とは異なり、AgentRoomはMCPツールを介した明示的なファイルレベルのクレームセマンティクスを使用している。これにより、実証的な問いは「逐次ベースラインに対するスピードアップ」から「失敗モードの抑制」へと移行している。
• 情報密度: 著者らは、調整が結合情報エントロピーの崩壊を防ぐと論じている。調整がない場合、エージェントは同じファイル上で衝突し、冗長な編集に計算資源を浪費する。クレームを用いることで、エージェントは互いに素なファイル上で作業でき、情報密度を$N$に対してほぼ線形にスケールさせることができる。
• アドバイザリー・ロッキング: 本システムは、プロンプト層において分散アドバイザリーロックを実装している。これにより、ファイル境界を越えたバグ修正などの柔軟性を維持しつつ、非協調的システムにおける壊滅的な「サイレント上書き」の失敗を防いでいる。
• 限界: 著者らは、結果が現在のセットアップ（Express.js/TypeScript、特定のモデル）に特有であること、および「品質」の指標が実行オラクルではなくLLMジャッジの複合体であることを認めている。$N=2$を超えてスケールすることのメリットについては、依然として未解決の課題である。

要約すると、AgentRoomは、マルチエージェントコーディングにおいては、複数のエージェントの生の並列性やCRDT基盤のマージ能力よりも、状態管理と明示的なシグナリングの方が重要であることを示している。