はじめに

2026年10月24日、Microsoft Research が Agensh を OSS として公開しました。論文のタイトルは「Agensh: Scaling Organizational Intelligence to 1,024 Agents」で、中央のオーケストレーターなしで、最大 1,024 エージェントを協調させるマルチエージェント基盤です。

Agent に複雑な仕事を任せると、途中で止まったり、勝手に「完了」と言い出したりしますよね。この問題に対する今の定番の答えが、ゴールを持たせて、完了するまでループを回す設計です。たとえば OpenAI の Codex CLI には /goal コマンドがあります。

Agensh の README を読んだとき、「同じ Agent の話なのに、見ている問題がまったく違うな」と感じました。

/goal のような設計が扱うのは、1本の作業ラインをどう最後までやり切らせるか
Agensh が扱うのは、ワーカーを何百と並べたとき、司令塔がどうボトルネックにならないようにするか

この記事では、Agensh の仕組みと結果を整理して、Orchestrator 型との違いと、Agentic Workflow がこれからどこへ向かいそうかを考えてみます。

⚠️ 先にお断りしておくと、この記事は論文（arXiv）、GitHub の README と REPRODUCE.md を読んだ内容がベースです。Agensh 自体を手元で動かしてはいません。「論文に書いてあること」と「私の解釈・予想」は、文中で分けて書いています。

TL;DR

何が出た？
Microsoft Research が、司令塔なしで動く自己組織化型のマルチエージェント基盤 Agensh を MIT ライセンスの OSS として公開しました（2026-10-24）。

論文で分かったこと

見たところ	結果
最難関5タスクの平均テスト通過率（1 → 128 エージェント）	✅ 19.31% → 28.78%（約 49% の相対改善）
pandoc の再実装（1 → 1,024 エージェント）	✅ 33.89% → 55.06%
大きな組織ほど早く同じ通過率に届くか	✅ 最初の2時間で、大きい組織ほど早く到達
協調の形は誰かが設計した？	⚠️ 設計ではなく、全員同じプロンプトから自然に出てきたと報告
全部解けた？	❌ pandoc でも 55%。まだ道半ば

私の整理
Agent の信頼性をスケールさせる設計（Codex の /goal のような、ゴールを持たせて完了までループする方式）と、Agent の組織をスケールさせる設計（Agensh）は、競合せず補い合う関係に見えます。

対象: ProgramBench の最難関5タスク、GPT-5.6-sol（high）、1タスク6時間、インターネットなし。Copilot harness の上に載せた構成です。

Agensh って何？

まず基本情報です。

項目	内容
公開元	Microsoft Research（Zhihao Zhan さんらの論文。著者に Furu Wei さん）
論文	arXiv:2609.26781（2026-09-22 公開）
OSS 公開	2026-10-24（コード、実験の起動スクリプト、再現ガイド）
ライセンス	MIT
一言でいうと	司令塔なしで、ワーカーが仕事を自分で見つけて協調する multi-agent harness

実装面で面白いのは、Agensh が単体 Agent のループを置き換えず、その上に載る層として作られている点です。README によると、各ワーカーの中身は GitHub の Copilot harness（Copilot CLI）のループで、Agensh は「組織としてどう動くか」の部分だけを足しています。論文では Claude Code など別の harness にもアダプタで繋げられると書かれています。

「信頼性」側の代表例：Codex の `/goal`

Agensh の前に、比較の基準になる「1本のラインを最後までやり切らせる」設計を見ておきます。分かりやすい例が、OpenAI の Codex CLI の /goal です。

公式のスラッシュコマンドのページにも /goal は載っています。動き方の詳細は、v0.128 のリリースを解説している記事（参考に載せています）によると、次のとおりです。

/goal "目標" で、プロンプトを1回きりのタスクではなく持続する目標として登録する
毎ターンの終わりに、Codex が目標の達成度を評価して、未達なら次の一手を自分で計画して続ける
止まる条件は4つ。達成、トークン予算の上限、人間による pause / clear、解決できない障害（認証情報がない、要件が曖昧、直せないテストなど）
ターンの合間に差し込まれる専用のプロンプトテンプレートが、進捗の評価と予算の制御を担当している

/goal "認証モジュールをセッション方式から OAuth2 に移行して、テストを更新し、CI を通す"

ここで注目したいのは、完了の判定が基本的に Codex 自身に任されている点です。だから、目標には「CI が通る」「テストが全部 pass する」のような検証できる条件を書くのがコツになります。解説記事でも、向いているのは移行・リファクタ・テスト生成のように、コンパイラやテストが進捗を教えてくれる仕事で、設計の判断が曖昧な仕事や、成果を測るベンチマークを回せない仕事は苦手だと整理されていました。

/goal が答えているのは、「途中で止まる」「勝手に『完了』と言う」を減らすという信頼性の問題です。ただ、ループを回すのは1本のラインです。ワーカーを並べて速度を上げる話は、また別の軸になります。

ちなみに Agensh の論文は、Codex の sub-agent も Orchestrator-Worker 型の仲間として挙げています。同じ Codex の中に、縦の軸（/goal）と横の軸（sub-agent）が両方あるのは面白いところですね。

なぜ Orchestrator 型だと詰まるのか

今のマルチエージェントは、ほとんどが Orchestrator-Worker 型です。メインの Agent が計画して、タスクを分けて、ワーカーに割り当てて、結果を回収します。

論文は、Codex の sub-agent、Claude Code の sub-agent と agent teams、Copilot の fleet、Kimi Agent Swarm などを、この構造の仲間として挙げています。論文の主張は、システム全体のスケールが、司令塔の「割り当てる・調整する・統合する」容量に縛られるというものです。

とはいえ、Orchestrator 型が悪いという話ではありません。

Anthropic は、マルチエージェントの Research 機能を Orchestrator-Worker で作っています。社内評価では、Claude Opus 4 をリード、Claude Sonnet 4 をサブエージェントにした構成が、単体の Opus 4 を 90.2% 上回ったそうです。一方でトークン消費はチャットの約 15 倍、しかも「コーディングは Research より並列化できる部分が少ない」とも書いています。
Magentic-One（Microsoft）は、Orchestrator が計画・進捗の追跡・エラー時の再計画をして、専門エージェントに仕事を振る構成です。司令塔が全体を見渡せるので、挙動を追いやすいのが利点です。

ワーカーが数個〜十数個の規模なら、Orchestrator 型は見通しがよくて強いと思います。Agensh が狙っているのは、そこから先の数百〜千の世界です。

Agensh の仕組み

協調ループ

Agensh では、全ワーカーが同じ5ステップのループを非同期に回します。

文脈を集める: ゴール、現状、仲間の進捗、これまでの知見を読む
サブタスクを claim する: 自分で「これをやる」と決めて、共有コンテキストに宣言する。他のワーカーと被ったら、ダイレクトメッセージで調整する
実行する: ツールを使って作業する。他の人に役立ちそうな発見は、途中でも共有する
検証する: サブタスクの受け入れ条件に照らして確認する。満たしていなければ直す
マージする: 共有ワークスペースに統合して、何を変えたか・なぜか・検証の証拠を共有する

マージが終わったら、また1に戻ります。全員の足並みを揃える必要がないので、遅いワーカーを待つこともありません。

ここで、私が一番目を引かれたのはステップ4の「検証する」がループに組み込まれていることです。完了を名乗る前に、自分の仕事を受け入れ条件で確認するわけですね。信頼性の話は、ここでも消えていません。

3つの基盤

ループを支えるのが、論文の言う「agentic organization infrastructure」です。

基盤	役割	実装
共有ワークスペース	進行中・統合済みの成果を置く。履歴とマージ競合の検出がある	Git プラットフォーム（Gitea）
メッセージ	全体アナウンスと、緊急の1対1メッセージ	Mattermost
共有コンテキスト	再利用できる知見と、誰が何をやっているかの宣言	DeLM の考え方をベースに調整

共有コンテキストには型があって、OBSERVED（観測した挙動）、FACT（確認済みの事実）、FAIL（うまくいかなかった方法）、CLAIM（今やっている作業の宣言）、PATCH_SUMMARY（完了した変更の要約）の5種類です。失敗を FAIL として全員に共有するところは、同じ失敗を何人もが繰り返さないための工夫だと読めました。

もう一つ、地味に大事な点があります。協調ループは、ランタイムにハードコードされているのではなく、ワーカーのプロンプトに書かれた手順として実現されています。そして、そのプロンプトはワーカー ID 以外、全員まったく同じです。役割分担を誰かが割り振っているわけではありません。

結果：エージェントを増やすと何が起きた？

評価には ProgramBench を使っています。参照プログラムの挙動だけを手がかりに、インターネットなしで一から作り直す、という難しいベンチマークです。その中で最難関の5つ（FFmpeg、gromacs、pandoc、PHP-src、ctags）が対象です。

5タスクの平均テスト通過率は、1 エージェントで 19.31%、8 で 20.68%、32 で 26.52%、128 で 28.78%
pandoc では、1 エージェントの 33.89% が、128 で 50.94%、1,024 で 55.06% に上がった
最初の2時間を見ると、大きい組織ほど早く同じ通過率に届く（pandoc では 128 エージェントが 30 分の時点で 30% を超えた）
README には、モデルを GPT-6.1-sol に変えた結果も載っていて、pandoc の通過率は 1 エージェントの 56.19% が 32 エージェントで 79.59% になっています

数字の読み方で気をつけたいところ

正直、これは冷静に読んだほうがいい数字だと思いました。

128倍のエージェントで、約 49% の相対改善です。1 → 8 では 19.31% → 20.68% と、伸びはゆっくりです。伸びが大きくなるのは 32 エージェントあたりからでした。
私が読んだ範囲では、トークンコストやエージェントあたりの効率を比べた記述は見当たりませんでした。Anthropic が「マルチエージェントはチャットの約 15 倍のトークンを使う」と書いていることを考えると、実務で使うときはここが一番気になります。
1,024 エージェントでも pandoc は 55% で、完全には解けていません。
条件は「6時間、インターネットなし、巨大な既存ソフトの再実装」です。日々の開発タスクにそのまま当てはまるとは限りません。

論文が主張しているのは「速さと質の両方が、エージェント数で伸びる可能性がある。エージェント数は新しいスケーリング軸になる」という点です。私もそこは面白いと思っています。

規模が大きくなると、協調の形が勝手に変わる

私が一番「おお」となったのは、スコアよりも軌跡の観察でした。

規模	観察された協調（論文より）
8	gromacs でモジュールのインターフェースを先に announce して、各自が実装。FFmpeg では、作業が重なった仲間と話して自分の担当範囲を変えた
32	PHP-src で、一度承認された変更に別のワーカーが反例を見つけて承認を撤回し、直してから再レビューしてマージ
128	過去の経験をもとにレビュアーを選ぶ。pandoc では「ブランチを更新してテストし、コミットハッシュを送って、仲間が検証・マージする」という統合手順を2人が決め、他のワーカーも使い回した。失敗が出たあとは、手順を改訂した
1,024	統合役を複数のワーカーが担当。複数の候補に声をかけて、最初に返事をした人に任せ、他は取り消す。ある人が失敗しても、同じ領域に詳しい別のワーカーが引き継ぐ

これらはすべて、全員が同じプロンプトから出てきたと論文は書いています。人間の組織でいう「役割ができる」「手順が標準化される」「特定の人に依存しなくなる」という進化が、Agent の世界で観察された、というのは興味深いです。

ただし、これは論文が選んだ事例の報告です。どのくらいの頻度で、どのくらい安定して起きるのかは、私には判断できません。

海外の議論と並べて読む

Cognition の「Don't Build Multi-Agents」

Cognition（Devin の会社）は、2025年に「Don't Build Multi-Agents」というブログで、マルチエージェントの脆さを2つの原則で説明しました。

文脈を共有する。メッセージだけでなく、エージェントの軌跡全体を
アクションは暗黙の判断を含み、判断が食い違うと結果が悪くなる

Flappy Bird のクローンを作るとき、サブエージェント1が Super Mario 風の背景を作り、サブエージェント2がゲーム素材らしくない鳥を作る、という例が印象的でした。

ここからは私の解釈ですが、Agensh の共有コンテキスト（FACT / FAIL / CLAIM）と、マージ時の「何を変えたか、なぜか、検証の証拠」の共有は、この2つの問題に対する一つの答えに見えます。司令塔の頭の中に文脈を置くのではなく、全員が読める場所に文脈を外出ししているわけです。

司令塔なしの先行例

Agensh の論文は、関連研究として Carlini さんによる、16 の Claude エージェントが Git リポジトリとタスクのロックファイルだけでコンパイラを作る実験を挙げています。オーケストレーションの Agent なしで、各ワーカーがタスクを選んでマージする構成です。Git を共有ワークスペースにして司令塔を外す発想は、Agensh だけのものではなく、複数の場所で同時に出てきているわけですね。

2つの「スケール」を並べてみる

ここで冒頭の話に戻ります。私が見ている整理は、こうです。

/goal のような「ゴールを持たせて完了までループする」設計は、「Agent の信頼性をどうスケールさせるか」
Agensh は「Agent の組織をどうスケールさせるか」

3つの問いで比べてみます。

問い	Orchestrator 型	自己組織化型（Agensh）
誰が仕事を分解する？	司令塔	各ワーカーが自分で提案して claim
状態はどこにある？	司令塔の文脈（台帳など）	共有ワークスペース・メッセージ・共有コンテキスト
誰が「完了」を決める？	司令塔（`/goal` では Codex 自身が評価）	各ワーカーが受け入れ条件で検証して、マージで統合
詰まりやすい場所	司令塔の容量	衝突の調整・統合の手間・コスト
向く規模	数個〜十数個	数十〜千

3行目が、私がいちばん考え込んだところです。

Agensh のステップ4は、自分が claim したサブタスクの受け入れ条件で検証します。論文からは、この条件を誰が・どの厳しさで決めるのかは読み取れませんでした。ワーカー自身が決めるなら、「自己申告で完了にする」問題が、1,024 エージェントそれぞれの内側に残りうるということです。実験では ProgramBench のテストという外部の採点があるので、スコア自体は客観的です。ただ、普段の開発で同じことをやるなら、マージの条件をテストや CI という外部シグナルに結びつける設計が欲しくなるはずです。

Agentic Workflow はどこへ向かう？（ここからは私の予想）

ここは論文に書いてあることではなく、私の見立てです。

1. 司令塔は消えずに、薄くなる
タスクを細かく割り当てる役は、自己組織化の側に移ると思います。残るのは、「ゴールと完了条件を最初に決める」役です。ここは人間か、軽量な司令塔が担当します。

2. 主役は「共有基盤」になる
Git、チャット、共有コンテキストが、Agent の間をつなぐ本体になります。Agensh が Gitea と Mattermost という既存のツールを使っているのは、そのヒントだと思いました。基盤が既存の開発ツールなら、人間も同じ場所に参加できます。

3. 完了の判定は、Agent の外に出す
ワーカーが増えるほど、自己申告の誤りは積み重なります。テスト、CI、マージ条件のような外部シグナルで完了を決めて、未達なら再ループする。信頼性の設計は、組織が大きくなるほど重要になるはずです。

使い分けの目安も、現時点の私の感覚で書いておきます。

状況	向いていそうな構成
ワーカー数が少ない、流れを人が追いたい	Orchestrator 型
1本のタスクを確実に終わらせたい	`/goal` のような、検証できるゴールを持たせたループ
巨大で、分割しやすく、時間制約が厳しい	自己組織化型（検証の仕組みとセットで）
コストを抑えたい、依存関係が強く並列化しにくい	まず単体 Agent を磨く

手元で試すなら

REPRODUCE.md を読むと、Agensh は気軽に試すツールというより実験基盤です。

Linux、Docker Engine、Compose v2、systemd、cgroup v2 が必要で、スクリプトは Docker 用のパスワードなし sudo も要求する
既定はワーカー 8、1タスク 6 時間、モデルは gpt-5.6-sol（high）
ProgramBench を別途インストールして使う

ですので、個人の開発でまず試せるのは「考え方だけ持ち帰る」ことだと思います。たとえば、複数の Agent を走らせるときに、(1) 作業ごとにブランチを分ける、(2) 失敗した方法を共有ファイルに書き残す、(3) マージ前に必ずテストを通す、の3つを決めておくだけでも、Agensh の発想を小さく真似できます。

まとめ

Agensh は、Microsoft Research が MIT ライセンスで公開した、司令塔なしの自己組織化型マルチエージェント基盤です
5ステップの協調ループと、共有ワークスペース・メッセージ・共有コンテキストの3基盤で動きます
結果は、1 → 128 エージェントで平均 19.31% → 28.78%、pandoc は 1 → 1,024 エージェントで 33.89% → 55.06% でした。ただしコスト比較は、私が読んだ範囲では見当たりませんでした
規模が大きくなるほど、レビュー役や統合手順といった協調の形が自然に出てきたと報告されています
Agent の信頼性をスケールさせる設計と、組織をスケールさせる設計は、競合ではなく補い合う関係に見えます。私の予想は「薄い司令塔 + 自己組織化するワーカー + 外部検証」の3層です

Agent の話題は、「賢いモデルをどう作るか」から「賢いモデルをどう組織するか」に移ってきたように感じます。Agensh を実際に動かせたら、また感想を書きたいと思います！

参考