はじめに
このシリーズでは、Harness Engineering・Loop Engineering・Context Engineering・Evaluationなど、1体のAIエージェントを支える要素を1つずつ見てきました。前回の記事では、それらの関係を1つの具体例で整理しました。
今回は、その1つ上の階層——複数のAIエージェントをどう束ねるかという、AI Orchestration（Multi-Agent Systems）を扱います。
なぜ1体では足りなくなるのか
1体のエージェントに「検索して、分析して、事実確認して、文章にまとめて」と全部を任せると、途中でよくある問題が起きます。
- 前半の検索作業に気を取られて、後半の文章の質が落ちる
- 1つのプロンプトが長大になり、指示のどこかが無視される
- 検索担当としては優秀でも、文章担当としては平凡、ということが起きる
人間の仕事でも同じです。1人に調査・分析・執筆・校正のすべてを任せるより、それぞれの担当を分けた方が、各工程の質が上がることがあります。AI Orchestrationは、この「分業」をAIエージェントの世界に持ち込む考え方です。
具体例で見る構成
前回の「毎朝ニュースを調べるエージェント」を、複数エージェントに分解してみます。
Orchestrator（指揮役）
├─ Research Agent … Web検索・情報源の収集
├─ Analyst Agent … 集めた情報の重要度判定・分析
├─ Critic Agent … 矛盾点・偏りの検証
└─ Writer Agent … 最終的な文章化
Orchestratorは、自分では検索も分析もしません。各エージェントに仕事を振り、出てきた結果を次のエージェントに渡し、最後に全体の完了を確認する「進行役」に徹します。
Orchestrationで新たに必要になる設計
1体のエージェントの設計（Harness / Context / Loop / Evals）に加えて、複数体になると新たに考えるべきことが増えます。
1. 誰が何を担当するか（役割分担）
担当が重なると同じ作業を二重にやったり、逆に誰も拾わない作業ができたりします。役割の境界線を明確にする必要があります。
2. 情報の受け渡し方（ハンドオフ）
Research AgentがAnalyst Agentに何を渡すか——記事の全文か、要点だけか——ここでもContext Engineeringの考え方が、エージェント間の受け渡しにも適用されます。
3. 誰が最終責任を持つか
Critic Agentが「この分析はおかしい」と判定した場合、誰がやり直しを指示するのか。Orchestrator自身がその判断基準（Evals）を持っている必要があります。
4. 失敗した担当をどう扱うか
Analyst Agentが処理に失敗した場合、Orchestratorがリトライさせるのか、別の方法に切り替えるのか。これは以前の記事で扱ったRecovery Engineeringの、マルチエージェント版です。
Orchestrationは「魔法」ではない
複数エージェントに分ければ何でも解決する、というわけではありません。むしろエージェントを増やすほど、通信のオーバーヘッド・コスト・デバッグの難しさは増えます。
実務での目安は、「1つのタスクの中に、明らかに性質の違う複数の専門作業が含まれているか」です。検索と分析と執筆のように、必要なスキルセットが明確に異なる場合はOrchestrationが効きます。逆に、単純作業の繰り返しであれば、1体のエージェントにLoop Engineeringを組み込むだけで十分なことがほとんどです。
まとめ
AI Orchestrationは、1体のエージェントの性能を上げる技術ではなく、複数の専門エージェントに仕事を分担させ、その進行を管理する設計です。1体のエージェントの中身（Harness / Context / Loop / Evals）が固まっていない状態でOrchestrationから手を出すと、問題が単に人数分に増えるだけなので、順番としては1体をきちんと設計してから複数体に広げるのが安全です。
拙著『AIエージェント設計論 — Harness/Loop EngineeringからRAGまで』でも、この考え方を踏まえた設計を扱っています。