マルチエージェント設計とは？FDEが現場で使う構成パターンと判断基準

マルチエージェント設計とは何か？単一エージェントとの違いは？

マルチエージェント設計とは、役割を分けた複数のAIエージェントを協調させて、ひとつのタスクを解く設計手法です。

FDE（Forward Deployed Engineer）が顧客の現場で生成AIを業務に組み込むとき、「エージェントを1体にするか、複数に分けるか」は早い段階で決める必要があります。Palantirが広めたFDEという職種は、顧客の業務と本番データのそばで動くシステムを作る役割です。そのため、この判断はデモの見栄えよりも、運用コストや障害時の切り分けのしやすさを左右します。

定義：役割・コンテキスト・ツールを分割する設計

マルチエージェントの本質は、1つのLLMに抱えさせていたコンテキストとツールを、役割ごとに切り分けることにあります。

単一エージェントは、1つのコンテキストウィンドウの中で計画・ツール呼び出し・結果の解釈を繰り返します。マルチエージェントでは、たとえば「計画を立てる司令塔」「検索する調査役」「出力を検査する評価役」のように役割を分け、それぞれに専用のプロンプト、ツール、コンテキストを持たせます。各エージェントは自分の担当範囲だけを見るので、指示が混ざりにくくなります。一方で、エージェント同士の情報の受け渡しを設計する必要が生まれます。

単一エージェントとの違いを比較表で整理

両者の違いは、性能よりも「コスト・並列性・デバッグ容易性」のトレードオフとして捉えると判断しやすくなります。

Anthropicは2024年12月の技術記事「Building effective agents」で、まずは単純な構成から始め、必要なときだけ複雑さを足すよう推奨しています。筆者の実感としても、顧客のPoC（概念実証）で最初からマルチエージェントを組むと、精度の問題なのか連携の問題なのか切り分けられなくなる場面が多いと感じます。

マルチエージェントを使うべき場面と避けるべき場面は？

並列化できる調査や独立した下位タスクには有効ですが、密結合な作業では単一エージェントのほうが無難です。

向いている場面：幅優先の調査と独立タスク

マルチエージェントが効果を出しやすいのは、問いを独立した下位の問いに分解でき、それらを並列に調べられる場面です。

Anthropicは2025年6月の記事「How we built our multi-agent research system」で、司令塔役（Claude Opus 4）が複数のサブエージェント（Claude Sonnet 4）を指揮する構成を公開しました。社内の調査タスク評価では、Claude Opus 4の単一エージェントを90.2%上回ったと報告しています。同じ記事では、性能差の大部分がトークン消費量で説明できること、マルチエージェントは通常のチャットの約15倍のトークンを使うことも示されています。

FDEの現場に置き換えると、次のような業務が候補になります。

• 複数の社内システムや文書群を横断して調べる、競合調査や規程調査
• 顧客ごと・拠点ごとに同じ処理を並列で回す、データ整備や分類
• 生成と検査を分ける必要がある、品質要件の厳しい文書作成

避けるべき場面：密結合・低予算・短納期

前の判断が次の判断を強く縛る作業では、エージェントを分けると文脈が途切れ、品質が落ちやすくなります。

Cognitionは2025年6月の記事「Don’t Build Multi-Agents」で、並列に動くサブエージェントがお互いの判断を知らないまま作業すると、成果物の整合性が崩れると指摘しました。そのうえで、コンテキストを共有することと、行動に暗黙の判断が含まれることを重視する原則を示しています。コーディングのように一連の変更が強く依存し合う作業は、この典型です。

マルチエージェントの代表的な構成パターンは？

代表的な構成は、オーケストレーター型・パイプライン型・ルーティング型・評価者型・ハンドオフ型の5つです。

ここでは、AnthropicとOpenAIが公開しているガイドの分類をもとに、FDEの現場で使いやすい形に整理します。Anthropicの「Building effective agents」は、プロンプトチェーン、ルーティング、並列化、オーケストレーター＝ワーカー、評価者＝最適化の5つを示しています。OpenAIの「A practical guide to building agents」（2025年）は、マルチエージェントをマネージャー型と分散（ハンドオフ）型に分けています。

中央集権型：オーケストレーター＝ワーカー

司令塔がタスクの分解と統合を担う中央集権型は、制御しやすく、FDEが最初に検討しやすい構成です。

司令塔役のエージェントが計画を立て、サブエージェントに「目的・出力形式・使ってよいツール・終了条件」を渡し、返ってきた結果を統合します。前述のAnthropicの調査システムもこの形です。設計で特に効くのは、サブエージェントへの指示の粒度です。指示があいまいだと、サブエージェント同士が同じ調査を重複して行ったり、範囲を取りこぼしたりします。

分散型：ハンドオフとルーティング

入口で振り分けるルーティングや、担当を引き継ぐハンドオフは、業務部門の分担がはっきりした組織と相性がよい構成です。

たとえば「経理の問い合わせ」「人事の問い合わせ」のように業務の境界がはっきりしていれば、エージェントの境界を組織の境界に合わせられます。こうしておくと、顧客側の担当部署がプロンプトやナレッジの持ち主になりやすくなります。FDEが去った後の運用移管を考えると、この点はかなり重要です。

品質担保型：評価者＝最適化

生成と評価を別のエージェントに分ける構成は、評価基準を言語化できる業務で品質を底上げする手段です。

生成役が作った出力を、評価役がチェックリストに沿って判定し、差し戻します。評価基準が「読みやすく」程度のあいまいなものだと、ループが収束しにくくなります。差し戻し回数の上限を決めておくことが前提になります。

マルチエージェント設計の手順は？

単一エージェントで基準線を作り、その限界を計測してから分割する、という順序で進めるのが安全です。

ステップ1〜3：基準線と分割点を決める

最初の3ステップでは、分割する理由をデータで示せる状態にすることを目指します。

1. 評価セットを作る：顧客の実データから代表的な入力と期待する出力を集め、合否判定の基準を決めます。
2. 単一エージェントで基準線を測る：同じ評価セットで、精度・処理時間・トークン消費を記録します。
3. ボトルネックを特定して分割点を決める：「コンテキストが溢れる」「並列にすれば速くなる」「検査役が必要」など、分割で解決できる課題があるときだけ分割します。

ステップ4〜6：契約・評価・観測を設計する

後半の3ステップでは、エージェント間の受け渡しを「契約」として固定し、本番で追跡できるようにします。

4. 入出力の契約を定義する：各エージェントの入力・出力をJSONスキーマなどで固定し、自由文の受け渡しを減らします。
5. エージェント単位と全体の評価を両方回す：個々のエージェントの精度と、最終成果物の精度を分けて測ります。
6. トレースと停止条件を実装する：エージェント間のメッセージ、ツール呼び出し、トークン消費を記録し、反復回数やコストの上限を設定します。

筆者の経験では、手順4を省いて自由文で受け渡しを始めると、後から不具合の原因を特定するのにかなり時間を取られがちです。

FDEが現場でマルチエージェントを導入する際の注意点は？

最大の落とし穴はコンテキストの断絶とコスト膨張で、顧客環境では権限設計と説明責任も問われます。

技術面：コンテキスト共有・エラー伝播・コスト

技術面では、情報の断絶、エラーの連鎖、トークン費用の3つを、設計段階で抑え込む必要があります。

モデルの使い分けも有効です。司令塔には高性能なモデルを使い、定型的なワーカーには軽量なモデルを使う構成にすると、コストと精度のバランスを取りやすくなります。

組織面：顧客への説明・権限・運用移管

組織面では、「誰が、どのエージェントの判断に責任を持つか」を顧客と合意しておくことが欠かせません。

エージェントごとにアクセスできるデータやシステムの権限を、最小権限の原則で分けることも重要です。書き込みや外部送信を伴うツールには、人間の承認を挟むことを検討します。FDEは顧客の現場に常駐し続けるわけではありません。プロンプト、評価セット、トレースの見方を顧客側に引き継げる形で残すことが、マルチエージェントを運用に乗せるための条件だと筆者は考えています。

参考文献

• Anthropic「Building effective agents」（2024年12月）
• Anthropic「How we built our multi-agent research system」（2025年6月）
• Cognition「Don’t Build Multi-Agents」（2025年6月）
• OpenAI「A practical guide to building agents」（2025年）

本文中の現場での所感は、記者による一次体験の草稿です。公開前に監修者が確認・承認します。

姉妹メディアの関連記事