技術要約：ゼロからのマルチエージェント・コーディングにおける第一級オブジェクトとしての協調モードに関する実証研究

問題提起

現在のマルチエージェント・コーディング・システムの評価には、主に3つの限界が存在する：

1. 合成環境： 既存のベンチマークは、時間や金銭的コストといった実用的な制約を無視した人工的なタスクに依存していることが多い。
2. 推論と通信の混同： エージェントの推論能力と、その通信プロトコルの効率性を区別できていないことが多い。
3. 表層的な指標： 最終的な出力や「初回試行」の成功のみを評価し、労働の分割、デプロイ、および具体的なフィードバックに基づく改善という反復プロセスを軽視している。

さらに、最先端のコーディング・エージェントは関数合成からリポジトリレベルの作業へと進化しているが、ほとんどのベンチマークは依然として単一エージェントによる修正行動を評価している。これらは、チームとしてのエージェントがいかにしてフルスタック・システムをゼロから構築し、ハンドオフ（引き継ぎ）を管理し、時間とトークンの予算内で解に収束するかを測定できていない。既存のマルチエージェント・ベンチマーク（AgentsNet、CloudDevべきなど）は、多くの場合、抽象的すぎてCI/CD（継続的インテグレーション／継続的デリバリー）から乖離しており、あるいは定義済みのAPIに依存しているため、「ゼロからの」というタスクの本質を損なっている。

手法：MSEval フレームワーク

著者らは、現実世界のソフトウェア・タスクにおけるマルチエージェントによる「バイブ・コーディング（vibe coding）」を定量的に評価するために設計されたベンチマーク、MSEvalを導入する。このフレームワークは、3〜4人の開発者チームがフルスタック・プロジェクトを反復的に構築する大学のソフトウェア工学の設定に基づいている。

コア・コンポーネント

1. データセット（10の実世界プロジェクト）：

   • 2018年から現在までの大学のキャップストーン・アサインメントから厳選。
   • リアルタイム・メッセージング、エンタープライズ資産管理、クラウドソーシング、要件追跡、画像処理、Eコマース、クリエイター分析、RBAC（ロールベースのアクセス制御）、ニュース検索、オンライン・ライブ授業の10ドメインをカバー。
   • 各プロジェクトは6〜8個のモジュールと30〜45個の重み付き項目に分解され、決定論的な100点満点のルーブリックに正規化されている。

2. 実行エンジン：LegoGent：

   • 制限付きの同期を備えた協調モードをインスタンス化するランタイム。
   • メカニズム： エージェントは共有ワークスペース内で並行して作業する。周期的な同期ループ（4分ごと）が進行状況のスナップショットを収集し、ブロードキャストを行う。アクティブなメールボックスにより、同期の間でもターゲットを絞ったピア間の質問が可能である。
   • デプロイ： 生成されたリポジトリは、XDeployを用いてネイティブなCI/CDパイプライン（GitLab + SonarQube）を通じてステージングされる。デプロイの失敗は、単なるコードの不完全性ではなく、測定された結果として扱われる。
   • モード： 以下のものを含む10種類の異なる協調トポロジーを実装：
     • フィーチャー・スクワッド（Feature Squads）： ユーザー向けモジュールごとに並列化。
     • レイヤー・スペシャリスト（Layer Specialists）： フロントエンド／バックエンドのレイヤーごとに並列化し、API契約において同期。
     • パイプライン（Pipeline）： 意図的な直列ハンドオフ（アーキテクト $\to$ バックエンド $\to$ フロントエンド $\to$ QA）。
     • PMオーバーサイト（PM Oversight）： 中央集権的なプロジェクトマネージャー。
     • QAファースト（QA-First）： 要件を実装前に受け入れターゲットに変換。
     • スウォーミング（Swarming）、ローテーション（Rotation）、オープンソース・レビュー（Open-Source Review）、敵対的テスト（Adversarial Testing）、競争チーム（Competitive Teams）。

3. 自動評価器：TAgent：

   • 自動化されたティーチング・アシスタント（TA）として機能。
   • プロセス： 要件ドキュメントを重み付きチェック項目へと解析する。実装表面（UI、API、コード）を探索してから調査を開始する。
   • 評価ストリーム：
     • UI： Playwrightを使用してライブサイトを駆動し、アクセシビリティツリーやDOMをチェックする。
     • API： OpenAPI/Swaggerをプローブするか、ソースファイルからルートを再構成する。
     • コード： LLMによる検査を通じて内部制約（例：パスワードのハッシュ化）を検証する。
     • フィードバック： スカラー値のスコアではなく、項目レベルのエビデンス（UIの状態、APIレスポンス、コードの場所）を生成し、次ラウンドに向けたランク付けされた修正アジェンダを可能にする。
   • 並列化： ステートフルなUIチェックのセットアップの重複とメイクスパンを最小化するために、タスクDAGと整数計画法を使用する。

4. 実験デザイン：

   • グリッド： 10プロジェクト $\times$ 10協調モード = 100構成。
   • イテレーション： 最大3回の洗練ラウンド（構築 $\to$ デプロイ $\to$ 評価 $\to$ フィードバック）。
   • メトリクス： 機能完了スコア（0–100）、ウォールクロック・レイテンシ、USDコスト、およびトークン使用量（プレフィックス・キャッシュ済みおよび新規）。

主な貢献

1. MSEval ベンチマーク： 現実的なプロジェクトと多様な協調モードにわたってマルチエージェント・コーディングを評価する100ケースのグリッドを提供。仕様、コード、および分析スクリプトのすべてを公開。
2. LegoGent ランタイム： 制限付き同期、明示的なピア・メッセージング、およびCI/CDデプロイ検証を備えた、イベント駆動型のマルチエージェント・ランタイム。
3. TAgent グレーダー： 実装表面を探索し、反復的な洗練のための重み付きで実行可能なフィードバックを提供する、ドキュメント駆動型の自動評価器。
4. 実証研究： 組織トポロジーが、速度・コスト・品質のトレードオフの主要な決定要因であり、モデルの能力に匹敵する影響力を持つことを示す包括的な分析。

結果

本研究では、複数のモデル（Claude Opus 4.8, GPT-5.5, DeepSeek v4 Flash/Pro, GLM-5.2, Qwen3.6-Flash）を10のモードで評価した。

• トポロジー vs モデル能力： 組織トポロジーはパフォーマンスに大きく影響する。同一のタスクとモデルであっても、トポロジーを変えることでスコアが30ポイント以上変動し、ウォールクロック時間は数倍になるケースもあった。
  • 構造化されたパイプライン（Structured Pipelines）： 高い品質を維持しつつ、最も速く収束した。
  • 過剰な監視（PM Oversight）： ボトルネックとなるため、パフォーマンスを低下させることが多い。
  • オープンソース／敵対的（Open-Source/Adversarial）： 後半のラウンドで大きな利点を示したが、初期スコアは低かった。
• モデルの性能：
  • Claude Opus 4.8： 最高スコア（例：IMシステムで97）を達成したが、高コスト（$654）かつ長時間（110分）を要した。
  • GPT-5.5： 同等のスコア（96）を、大幅に低いコスト（$138）と時間（74分）で達成した。
  • GLM-5.2： 全グリッド平均スコアで最高に達したが、最も遅く、最も高価であった。
  • DeepSeek v4 Pro： モードを問わず安定したパフォーマンスを示す強力なベースラインであった。
• 洗練のダイナミクス：
  • ラウンド間の遷移の82.0%でスコアの向上が見られ、94.7%の実行がラウンド1よりもラウンド3で高いスコアで終了した。
  • 退行（Regression）： ある要件の修正が別の要件を壊してしまうという明確な失敗モードが存在した（例：IMシステムにおけるPM監視下の実行では、ラウンド3でスコアが80.9から66.0に低下した）。
• 失敗の分類学：
  • 機能的不足（Functional Shortfall）： 失敗の大部分（56%のチェック）を占め、特に機能の欠落（23.8%）と不完全なロジック／エッジケース（32.2%）が目立った。
  • 前提条件のカスケード（Prerequisite Cascades）： 認証または権限の失敗（失敗の23%）が、後続のチェックをテスト不能にし、契約の脆弱性を浮き彫りにした。
  • 統合の問題（Integration Issues）： セキュリティおよびトランスポートの失敗（8.5%）が頻発しており、これは必ずしもコーディングエラーではなく、CI/CD統合の課題に起因していた。

意義と主張

本論文は、協調モードがマルチエージェント・コーディングにおける「第一級オブジェクト（first-class citizen）」であると主張している。つまり、組織トポロジーは基礎となるモデルの選択と同等に重要であるということである。

• 測定可能なトレードオフ： MSEvalは、速度・コスト・品質のトレードオフを測定するための厳格な基準を確立した。「並列化」が必ずしも時間やコストを削減するわけではなく、明確なトポロジーによって管理されなければ、重複したコンテキストやマージコンフリクトを生み出す可能性があることを明らかにしている。
• リーダーボードを超えて： 本ベンチマークは、単一の「最高の成果物」から、ソフトウェア・デリバリー・ループ全体へと焦点を移し、協調ポリシー（例：誰が成果物を所有し、どのようにハンドオフが行われるか）の影響を測定可能にした。
• 実用的な示唆： 結果は、将来のエージェント・システムが、コラボレーション・モード、モデル選択、および停止ポリシーを、固定されたデフォルトではなく、実行時の決定事項として扱うべきであることを示唆している。「最高の」モデルは普遍的に優れているわけではなく、最適な選択は特定のトポロジーと予算制約に依存する。

著者らは、現代のLLMは相当なソフトウェアを構築できるものの、その成功はオーケストレーションによって強く形作られるものであり、現在の評価手法はこれらのシステム的なダイナミクスを捉えるために進化しなければならないと結論付けている。