Microsoftの研究チームが、競合の多くがまず作る部品——オーケストレーターを削ぎ落としたマルチエージェント・コーディングハーネスを公開した。Agenshでは、すべての作業者が同じ5段階のループを回し、同じプロンプトを受け取る。違うのは作業者IDだけだ。仕事を配るリードセッションは存在しない。論文はこの設計を同時1,024作業者まで押し上げており、その数値は発想が成り立つ理由と、割に合わなくなる地点の両方を映し出している。
記事の要点
- ProgramBenchの最難関5課題における最終テスト通過率の平均は、エージェント1体で19.31%、8体・32体・128体でそれぞれ20.68%、26.52%、28.78%だった。いずれもGPT-5.6-sol（high）を6時間の予算で走らせた結果である。
- pandoc単体では1体が33.89%、128体が50.94%、1,024体が55.06%。作業者を8倍に増やして得たのは4.12ポイントだった。
- 協調はありふれたインフラの上で動く。共有ワークスペースはGiteaリポジトリ、メッセージはMattermost、そして型付きの発見を追記していくだけのログである。
ハーネスはどうやってオーケストレーターを代替するか
各作業者は共有ゴールと仲間の進捗を把握し、サブタスクを取得してその範囲を宣言する。続いてツールで作業を進め、受け入れ基準に照らして結果を検証し、共有ワークスペースへマージしてまた最初に戻る。取得範囲が重なった場合は、プランナーではなく作業者同士がダイレクトメッセージで片づける。
協調を支えるのは三つのサービスだ。共有ワークスペースはGitプラットフォームで、実験ではGiteaを使った。作業者は各自プライベートブランチを持ちmainへ統合するため、マージ衝突は通常の衝突として表面化する。メッセージインターフェースはMattermost。チームチャンネルはループ1周の開始時に届き、優先度の高いダイレクトメッセージはインフラ系ツール呼び出しのたびに末尾で届く。共有コンテキストは型付きエントリを追記するだけのストアで、観測した挙動はOBSERVED、確認済みの事実はFACT、失敗した手法はFAIL、進行中の取得はCLAIM、完了した変更はPATCH_SUMMARYとして残り、直近の記憶を超える履歴はgrepツールで辿る。
協力ループはランタイムではなく作業者プロンプトの中にある。著者らがAgenshを、単体エージェントのハーネスを置き換えるものではなくその上に重ねた層だと説明できるのはそのためだ。実験はその下にCopilotを敷いて回しており、論文は薄いアダプタさえあればClaude Codeなど他のハーネスも差し込めると主張する。引用された既存ハーネスとの対比は明確である。Claude Codeのエージェントチームは今も固定されたリードセッションを中心に回り、Codexはサブエージェントの結果を親へ返し、Kimi Agent Swarmは作業を分解し割り振るオーケストレーターを学習させる。
スケーリング曲線が実際に示すもの
ProgramBenchは、インターネットを遮断した状態で6時間以内に参照プログラムの挙動をゼロから再現せよとエージェント組織に求める。チームは200インスタンスのうち最難関の5つ——FFmpeg、GROMACS、pandoc、PHP-src、ctags——を選んだ。いずれも数千のファイルと数百万バイトのソースを抱えるリポジトリである。
モデルとハーネスを固定した条件で、128体は1体を9.47ポイント上回った。相対では約49%の改善である。規模の大きい集団は到達も早かった。pandocでは128体が30分のチェックポイントでテスト通過率30%を超え、32体は60分、8体は90分を要し、単体エージェントは最初の2時間その線を下回ったままだった。締め切りの厳しい作業なら、最終スコアよりこの到達時間のほうが効いてくる。
1,024体の実験は見出しであり、同時に但し書きでもある。単体より21.17ポイント積み増したが、128体と比べれば4.12ポイントにとどまる。論文はどの構成についてもトークンや費用の勘定を示していない。最後の896体の対価は読者に委ねられた格好だ。しかも上限が挙動の完全再現であるベンチマークにおいて、55.06%はなお部分的な再現にすぎない。
面白いのはスコアではなく振る舞いのほうだ
全作業者が同一のプロンプトを受け取る以上、構造らしきものはすべて自ずと立ち上がるしかない。実行の軌跡はそれが起きていることを示す。GROMACSでは作業者がモジュールのインターフェースを先に宣言し、その後は各自が独立して実装した。FFmpegでは、範囲の重複を仲間に指摘された作業者が自分の担当を狭めた。PHP-srcでは仲間が承認した貢献に別の作業者が反例を出し、承認が撤回され、修正版はマージ前に改めてレビューを受けた。
規模が最大になると役割が固まってくる。pandocでは2体が統合プロトコルを発明した。作成者がブランチを試験し、コミットハッシュを仲間へ送って検証とマージを任せる方式である。他の作業者がそれを真似し、後にはレビュー側の仲間がサイクル全体を引き受ける形へ改訂された。複数の作業者が統合役として動き、ある作業者は候補を複数当たって最初に有効な応答を返した相手を採用し、残りをキャンセルした。この冗長性こそが、1体の失敗で組織全体が止まるのを防いだ。表のどの単一の数字より有用な性質である。
同時に、他のスウォーム研究の結果が投げかけたのと同じガバナンスの問いが付いて回る。自らレビュー規約を書く組織は、プランナーの指示に従う組織より監査しにくい。Agenshはコミット、メッセージ、型付きの発見といった成果物を読める形で残すが、エージェントたちが落ち着いたその作業手順を承認した人間は誰もいない。
FAQ — よくある質問
Agenshのコードは公開されているのか
論文はコード公開を告知しておらず、リポジトリへのリンクもない。ただし、ハーネスがセルフホスト可能なインフラ上で動くことは明記されている。共有ワークスペースにGitea、メッセージングにMattermostを用い、協力ループはランタイムではなく作業者プロンプトに収められているため、記述からの再現が利く設計である。
実験にはどのモデルを使ったのか
報告されたすべての実行が推論努力highのGPT-5.6-solを用い、下地の単体エージェントハーネスにCopilot、課題あたりの予算に6時間を置いている。著者らは協力ループがハーネスに依存しないと述べるが、他モデルでの結果は示していない。
エージェントが多いほど結果は必ず良くなるのか
比例はしない。1体から1,024体まで各段階でスコアは上がったが、128体から1,024体で得たのはpandocで4.12ポイント、1体から128体の17.05ポイントとは開きがある。論文はエージェント数をスケーリングの一軸として提示しており、ただで手に入る軸とはしていない。
