ここ数ヶ月で、AIは「一人で全部やる」のをやめた

AI駆動開発を追っていると、ここ数ヶ月で空気が明らかに変わったのを感じる。少し前まで「AIがコードを書く」だけだったのが、いまは 複数のAIが役割分担しながら開発する 構造へ進化している。

PM役のAIが計画を立て、コーダー役が実装し、テスト役が検証し、レビュー役が品質をチェックする ― まるで人間の開発チームのように。「分業するAI」 の時代だ。

ただ、この流れには「Agent」「Sub-Agent」「Orchestration」「Swarm」「Agent Mesh」と、似た言葉が大量に出てきて混乱しやすい。この記事では、私がObsidianに整理した用語体系をベースに、最新の記事と論文を突き合わせながら、「AIの分業はいま実際どうなっているのか」 をやさしく整理してみたい。

まず、変化を一言でまとめるとこうなる。

アフェリエイト広告

用語の地図 ― 8つの概念を一枚で混乱の正体
ステップ1：まず「Agentic AI」― 質問に答えるAIから、仕事を進めるAIへ
ステップ2：「Multi-Agent」― 人間のチームを模倣する
ステップ3：「Sub-Agent」― 分業の本当の狙いは“文脈圧縮”だった
ステップ4：「Orchestration」― Agentより重要かもしれない指揮統制役
1. ここで本記事は、これを「指揮統制（C2）」と呼ぶ
論文で見る分業：AgentMesh ― Planner / Coder / Debugger / Reviewer
ただし ― 「本当に分業すべきか？」という激しい論争があった
1. そして2026年、答えはこう収束した
その先の地平 ― まだ答えの出ていない3つの模索
まとめ：2026年は「指揮統制(Orchestration / C2)の時代」
1. 参考にした記事・論文

用語の地図 ― 8つの概念を一枚で混乱の正体

ポイントは、これらは競合ではなく“積み上がり”だということ。上から順に見ていけば、分業がどう深まってきたかが分かる。

概念	狙い	代表製品
Copilot型	補助	GitHub Copilot
Agentic AI	自律実行	Claude Code
Multi-Agent	分業	CrewAI
Sub-Agent	専門化・文脈圧縮	Claude Code Tasks
Orchestration	指揮統制	LangGraph
Conversation Agent	議論	Microsoft AutoGen
Swarm	群知能	OpenAI Swarm系
Agent Mesh	ネットワーク化	AgentMesh
Agent OS	Agent基盤	OpenAI・Anthropicの長期戦略

ステップ1：まず「Agentic AI」― 質問に答えるAIから、仕事を進めるAIへ

すべての出発点が Agentic AI だ。従来のAIは「人 → プロンプト → LLM → 回答」で終わっていた。Agentic AI はここにループが入る。

つまり「質問に答えるAI」ではなく、「仕事を進めるAI」。Claude Code、OpenAI Agents SDK、GitHub Copilot、Google Agent Development Kit (ADK) などが代表だ。

ステップ2：「Multi-Agent」― 人間のチームを模倣する

一人のAgentにできることには限界がある。そこで登場するのが Multi-Agent。人間の開発チーム（PdM・設計・実装・QA）をそのままAI化する発想だ。

実装思想はフレームワークごとに個性がある。2026年時点の主要プレイヤーを並べると ―

CrewAI … 役割ベース。Researcher / Writer / Reviewer のように“クルー”を組む
Microsoft AutoGen … 会話ベース。Agent A→B→C が議論しながら進める（v1.0 GA 到達）
LangGraph … 有向グラフ。Agentをノードとして繋ぎ、状態保存・人間の介入チェックポイントを持つ（v0.4）
OpenAI Agents SDK … 軽量。handoff でAgentを切り替える
Google ADK … Gemini最適化、大規模Agent運用向け
Anthropic Claude Agent SDK … ネイティブなツール利用とMemory機能で本番採用が拡大

2026年の傾向として、各フレームワークは共通の抽象（オーケストレーション＋分離されたサブエージェント）へ収束し、差別化はエコシステムの厚みに移っている。(gurusup / pecollective)

ステップ3：「Sub-Agent」― 分業の本当の狙いは“文脈圧縮”だった

Claude Code界隈でよく出る Sub-Agent は、Agentの中にAgentを持つ構造だ。

ここで重要なのは、分業の狙いが「役割分担」だけではないこと。本当の狙いは コンテキスト圧縮 にある。

プロジェクト全体が200万トークンあっても、各Sub-Agentには「必要な部分だけ」読ませる。これがAI駆動開発では決定的に効く。

この設計の威力を、Anthropic自身が数字で示している。彼らのマルチエージェント・リサーチ・システムは「オーケストレーター=ワーカー」型 ― リード(Lead)エージェントが計画を立て、3〜5体の専門サブエージェントを並列に動かし、各サブエージェントがそれぞれ独自のコンテキストウィンドウで探索する。結果、

単一エージェント(Claude Opus 4)に対し、リサーチ評価で +90.2% の性能向上
ただし通常のチャットの 約15倍のトークンを消費

という、明確なトレードオフがある。だから「成果の価値がコストを上回るタスク」にこそ向く。(ByteByteGo / The AI Engineer)

ステップ4：「Orchestration」― Agentより重要かもしれない指揮統制役

Agentが増えると、新しい問題が噴き出す。誰を呼ぶ？どの順番？失敗したら？状態はどう保存する？

この“交通整理”を担うのが Orchestration（オーケストレーション）だ。実は2025年後半〜2026年で、Agent本体より重要とすら言われるようになった概念である。仕事は多岐にわたる ― Agent選択／状態管理／メモリ管理／エラー回復／並列実行／結果統合。

ここで本記事は、これを「指揮統制（C2）」と呼ぶ

少し脱線するが、用語の話をさせてほしい。一般には Orchestration を「統治」や「司令塔」と訳すことが多い。だが私は、これを 「指揮統制」 と呼びたい。軍隊や大規模組織でいう C2（Command and Control） ― 指揮官が任務達成のために部隊を 計画・指示・調整・統制 する営み ― になぞらえた、筆者なりの解釈だ。(Command and control ― Wikipedia)

肝心なのは、これが単なる「指揮（命令を出すこと）」では終わらない点にある。C2が本来抱える射程は、もっと広い。

① 指揮（Command） … 誰に、何を命じるか（Agent選択・タスク割り当て）
② 作戦立案（Planning） … どの順序で、どう攻めるか（実行計画・依存関係の設計）
③ 兵站（Logistics） … トークン・メモリ・ツールという“補給”をどう配分し、枯渇させないか
④ ガバナンス（Governance） … 暴走・逸脱をどう防ぎ、状態保存と結果の責任をどう担保するか

オーケストレーションが担うAgent選択・状態管理・メモリ管理・エラー回復・並列実行・結果統合は、まさにこの4つにきれいに対応する。だから“統治”という曖昧な言葉や、単なる“司令塔”より、指揮統制（C2） と捉えるほうが実態に近い ― これが、以降この記事で「指揮統制」という語を使う理由だ。

近い構造として、ユーザーが直接Agentを叩くのではなく Harness（制御装置）→ Agent群 という「ハーネス型」も増えている。Orchestrator → Task Router → Sub Agents という階層で、CursorやClaude Codeの内部もこれに近いと言われる。

この「オーケストレーター＋サブエージェント」が、いまの分業の中心だ。では、その先に何があるのか ― それは記事の後半でまとめて見ていきたい。

論文で見る分業：AgentMesh ― Planner / Coder / Debugger / Reviewer

「分業」は流行語ではなく、学術的にも検証が進んでいる。象徴的なのが AgentMesh という論文だ（arXiv:2507.19902, Sourena Khanzadeh, Toronto Metropolitan University, 2025年7月）。

これは、高レベルの要求を完成コードへ変換するために、4つの専門エージェントを協調させるPythonフレームワークである。

Planner … ユーザー要求を具体的なサブタスクへ分解
Coder … 各サブタスクをコードとして実装
Debugger … テストして不具合を修正
Reviewer … 最終成果物の正しさと品質を検証

まさに人間の開発工程（設計→実装→デバッグ→レビュー）をエージェントの分業に写し取った形だ。「分業するAI」というトレンドが、製品だけでなく研究の土俵でも本命視されていることがよく分かる。(arXiv / alphaXiv)

ただし ― 「本当に分業すべきか？」という激しい論争があった

ここまで読むと「分業は正義」に見えるが、2025年、これに真っ向から反対する声が上がった。見逃せない論争なので触れておきたい。

Cognition（AIコーダー Devin の開発元） は2025年6月、「Don’t Build Multi-Agents（マルチエージェントを作るな）」という強烈なブログを公開した。主張はこうだ ― マルチエージェントは魅力的に見えるが実務では“かなり悪い”。タスクを複数Agentに分けると、伝言ゲームのように重要情報が抜け落ちる。だから彼らはシングルスレッド＋専用の圧縮LLMで文脈を管理する設計を採る。(Cognition)

その翌日、Anthropicが前述のマルチエージェント・リサーチ・システムの記事で「複雑で並列化できるタスクには有効だ」と反論。「やるな(Cognition)」vs「慎重にやれ(Anthropic)」 の構図が生まれた。

論争の核心は コンテキストエンジニアリング ― プロンプト設計の次に来る、文脈を動的にどう設計・受け渡すかという問題だ。マルチエージェント最大の難所はまさにここにある。(Vellum)

そして2026年、答えはこう収束した

この激しい論争は、2026年に入っておおむね決着した。Anthropic・OpenAI・AutoGen・Cognition・LangChain の主要5陣営が、「オーケストレーター＋分離されたサブエージェント」を既定アーキテクチャとして採用するに至ったのだ。(FlowHunt / niteagent)

つまり、

無秩序に分業するのでもなく、頑なに一人で抱えるのでもない。
指揮統制役(Orchestrator)が、独自の文脈を持つサブエージェントへ慎重に仕事を渡す。

これが、現時点の“正解”として共有された分業のかたちだ。

その先の地平 ― まだ答えの出ていない3つの模索

「オーケストレーター＋サブエージェント」で現状は収束した。だが、そのさらに上のレイヤーには、まだ答えの出ていない3つの構想がある。いずれも研究と実装が走り始めたばかりの、いわば将来的模索だ。順に、中央集権をどこまで弱められるか（Swarm）→ 中央そのものを無くせるか（Agent Mesh）→ そもそもAgentを動かす基盤をどう作るか（Agent OS）と、抽象度が上がっていく。

① Swarm ― 「指揮者」を弱め、群れで動かせるか

オーケストレーションが中央集権（Conductor＝指揮者型）だとすれば、その対極にあるのが Swarm（群知能型）だ。中央の司令塔を弱め、数十〜数百のAgentがアリや蜂の群れのように自律協調して動く。2026年の多エージェント設計は、この「Conductor（中央・階層制御）」と「Swarm（分散・並列実行）」の二大パターンで語られるようになった。(AGIX)

OpenAIが実験的・軽量フレームワークとして公開した Swarm（OAS） は、Agent同士が自然言語のプロンプトで協調する仕組みで、この分散パターンへの関心を象徴している（※正式製品ではなく実験的位置づけ）。学術的にも SwarmSys（分散・群発想のスケーラブルな推論）など研究が活発だ。(codewave / SwarmSys arXiv:2510.10047)

ただし現状は楽観できない。「LLMによる群れは本当に新フロンティアか、それとも概念の引き伸ばしか？」と問う論文もあり、膨大な計算オーバーヘッド、そして長期計画や分散下での適応的戦略形成の弱さが課題として指摘されている。群知能は魅力的だが、まだ“群れたフリ”の段階を抜け切れていない。(LLM-Powered Swarms arXiv:2506.14496)

② Agent Mesh ― 中央を無くし、Agentが直接つながれるか

Swarmからさらに進み、中央管理そのものを無くすのが Agent Mesh（網目型）だ。従来の「中央が全Agentを管理する」形を捨て、Agent ↔ Agent ↔ Agent が直接通信するネットワーク構造をとる。

前半で紹介した論文 AgentMesh（Planner / Coder / Debugger / Reviewer の協調）も、この“網目で協調する”発想の具体例といえる。狙いは、ハブ（中央）がボトルネックや単一障害点になるのを避け、Agentを柔軟に増減・接続できるようにすること。

とはいえ、各Agentが勝手に通信し始めると、前述の「伝言ゲームで文脈が失われる」問題が一気に深刻化する。だからこそ Agent Mesh は、文脈とガバナンスをどう担保するかという難題と表裏一体で、まだ研究色が濃い。(AgentMesh arXiv:2507.19902)

③ Agent OS ― Agentを動かす「基盤」を誰が握るか

最も抽象度が高いのが Agent OS（エージェント基盤）だ。アプリがOSの上で動くように、AgentをOSのように管理する層を作ろうという構想である。具体的には、複数Agentにメモリ・ツールアクセス・意思決定ロジック・監督（ガバナンス）を与え、実システムをまたいだ多段タスクを完遂させる調整レイヤーを指す。

ここはすでに大手の主戦場になりつつある。

Microsoft … Windowsに Agent OS を組み込む方向。Build 2025で、Agentに企業ネットワーク内の“身元”を与える Entra Agent ID、AIがユーザーの本ファイルに触れず隔離環境でコードを実行できる Agent Workspaces を発表
Anthropic … 非開発者にエージェント能力を開放する Claude Cowork を2026年1月に投入
PwC … Oracle Cloud / AWS 上で独自の “Agent OS” を立ち上げ

学術側でも AIOS（LLMエージェントOS）や AgentOS（アプリのサイロを自然言語駆動のデータ生態系へ）といった論文が出ており、ジョブごとのガバナンス・メタdataやAgent横断の共有グラフを一級概念として扱う設計が議論されている。Gartnerは「2026年末までに企業アプリの40%がタスク特化型Agentを組み込む」と予測しており、その受け皿としてAgent OSの覇権争いが始まっている。(Make / AIOS解説 ― Knowlee / AgentOS arXiv:2603.08938)

Swarm・Agent Mesh・Agent OS ― この3つは、まだどれも“確定した正解”ではない。
だが「分業の次」を占う実験場として、研究と巨大資本が同時に流れ込んでいる。

まとめ：2026年は「指揮統制(Orchestration / C2)の時代」

エージェントの分業は、ここ数ヶ月で一気に成熟した。流れを最後にもう一度たどると ―

Agentic AI：質問に答えるAIから、仕事を進めるAIへ
Multi-Agent：人間のチームを模倣して分業
Sub-Agent：分業の本当の狙いは「文脈圧縮」。Anthropicは+90.2%（ただし15倍トークン）
Orchestration（指揮統制／C2）：Agentより重要な“指揮統制役”が主役に。単なる指揮でなく作戦立案・兵站・ガバナンスまで含む
論争と収束：「作るな(Cognition)」vs「慎重に(Anthropic)」→ 2026年は オーケストレーター＋分離サブエージェントが既定に
その先の模索：Swarm（指揮者を弱める）→ Agent Mesh（中央を無くす）→ Agent OS（基盤を握る）― いずれもまだ実験段階

LangGraph・OpenAI Agents SDK・Google ADK・Claude Code の競争軸も、モデル性能そのものより「Agentをどう管理するか」へ移った。2024年が「書く」、2025年が「働く」だったとすれば、2026年は間違いなく 「指揮統制する」 年だ。

そして現状の収束点（オーケストレーター＋サブエージェント）は、ゴールではなく通過点でもある。その先には Swarm・Agent Mesh・Agent OS という、中央集権をどこまで解くか／基盤を誰が握るかをめぐる模索が控えている ― ここが次の数年の主戦場になるだろう。

分業は万能薬ではない。鍵を握るのは、どれだけ多くのAgentを並べるかではなく、文脈(コンテキスト)をどう設計し、誰にどう渡すか。エージェントを増やす前に、まず「指揮者」を考える ― それが、この数ヶ月で業界がたどり着いた結論であり、次の地平へ進むための足場でもあると思う。

AIが「分業」を始めた ― エージェント指揮統制（オーケストレーション）の時代をやさしく整理する