マルチエージェントの失敗は多くが「仕様の曖昧さ」で、モデルの弱さではありません
マルチエージェントシステムを導入するとき、多くのチームは最初にいくつかのエージェントをつなぎ、あとは自分たちで仕事を終わらせてくれると期待します。しかし実際には、同じ作業を奪い合い、同時に誰も担当しない部分を取りこぼし、最終的に成果がかみ合わないことがよくあります。これは個別の事例ではありません。カリフォルニア大学バークレー校 Sky Computing Lab の MAST 研究(Cemri ら、NeurIPS 2025 で発表)は、主要な 7 つのマルチエージェントフレームワークの実行トレース 1,642 件を分析し、失敗率が 41% から 86.7% の間にあることを実測しました。そして失敗を三つに分類しています。約 44% はシステム設計と仕様(役割の曖昧さ、タスク定義の不明確さ)に起因し、約 32% はエージェント間の調整と引き継ぎに、約 24% は検証の欠如に起因します。合わせると、そのほとんどが「作業をどう分けるか、役割をどう分担するか、引き継ぎをどうつなぐか」の問題であり、モデルが賢くないからではありません。Gartner も、2027 年末までにエージェント型 AI プロジェクトの 4 割超が中止されると予測しており、その主因は価値の不明確さ、コストの暴走、統制の不足です。
本稿はワークフロー設計の方法論を扱います。目標が一つ入ってきたとき、どう成果物として引き渡せる作業単位に分解し、各単位を明確に定義された役割に割り当て、役割間の引き継ぎをどう設計するか、という話です。どの協調トポロジーを使うか、記憶やコンテキストをどう共有するか、そもそも投資に見合うかには踏み込みません。この作業と役割の層を正しく分けてこそ、後段のアーキテクチャと実装に拠りどころが生まれます。
タスク分解:目標を検収可能な作業単位に切り分ける
分解とは作業を細切れにすることではなく、「それぞれが独立して引き渡せ、独立して検収できる」単位に切り分けることです。切り方が正しいかは三点で判断します。単一で明確な成果物があるか、その成果物の正誤を検査できるか、他の単位への依存が十分に少ないか。Anthropic はマルチエージェント研究システムのエンジニアリング記録を公開した際、主導エージェントがサブタスクに明確な目標・出力形式・境界を与えなければ、サブエージェントは作業を重複させたり情報の欠落を残したりする、と強調しました。同チームは「どれだけ投入するか」まで明確なルールにしています。単純な事実確認は 1 エージェントでツール呼び出し 3~10 回、直接的な比較は 2~4 エージェントで各 10~15 回、複雑な調査ではじめて 10 以上を動かす、というものです。この「複雑さに応じて労力を調整する」規律により、システム全体は単一エージェントを 90.2% 上回りました。
よくある切り方は三通りあり、実務ではしばしば併用します。
- 工程段階で切る:収集・分析・産出・確認と、目標を自然な手順に沿って切り分けます。順序が明確な作業に向きます。
- 領域で切る:法務・財務・技術をそれぞれ一塊に切ります。異なる専門知識が必要で、並行して進められる作業に向きます。
- 責務の型で切る:「産出」と「検問」を別の単位に分け、作る人と検査する人を別にします。品質に二重の防衛線ができます。
粒度は中間を狙います。粗すぎると単一エージェントが一度に多くを背負い、出力が不安定でデバッグも難しくなります。細かすぎると単位間の調整・引き継ぎコストがかえって利点を食いつぶします。実用的な原則はこうです。ある単位の成果物がすでに明確に記述でき、独立して検収できるなら、それ以上細かく切る必要はありません。実務ではまず粗く分けて一巡させ、どの単位がよく失敗するかを見てから、その部分だけを細分化します。最初から完璧な分解図を追い求めないことです。
役割定義:一つのエージェントは一つの責務だけを担う
作業単位を切り終えたら、それらを役割へ収束させます。役割とは「このエージェントに何ができるか」ではなく「このエージェントがどの結果に責任を負うか」です。最も重要な原則は単一責務です。一つの役割は一種類の成果物だけを担当します。責務が増えるほど、挙動は予測しにくく、誤りも特定しにくくなります。これはまさに MetaGPT(ICLR 2024)の核心設計です。人間のソフトウェア会社の標準作業手順(SOP)を工程に組み込み、プロダクトマネージャー・アーキテクト・プロジェクトマネージャー・エンジニア・QAエンジニアの五つの役割で組立ラインのように分業し、各役割が構造の定まった中間成果物(例えば PRD)を引き渡すことで、誤りが大幅に減ります。CrewAI は「役割・目標・背景」の三点でエージェントを定義し、責務の境界を背景に書き込み、下位の実行者には自己委譲を無効化して役割の逸脱を防ぐことを公式に推奨しています。
| 役割 | 担当する成果物 | 責務の境界(やらないこと) |
| プランナー | 目標をタスク一覧と順序に分解する | 自ら実行せず、成果の良し悪しも判定しない |
| リサーチャー | 必要な事実と資料を収集・整理する | 最終決定は下さず、根拠のみを提供する |
| 実行者 | 指示に従い具体的な成果物を完成させる | タスク範囲は変えず、範囲の問題はプランナーに戻す |
| レビュアー | 検収条件に照らし合格か差し戻しかを判定する | 自ら手を入れず、明確な差し戻し理由のみを示す |
境界を明確に書く最大の利点は、曖昧な領域をなくすことです。これはまさに MAST 統計で最大の割合を占める 44% の仕様系の失敗に対応します。各役割が何を引き渡すべきか、何に触れてはいけないかを知っていれば、二つの役割が同じ作業を奪い合ったり、「誰かがやると思っていた」せいで誰も担当しない作業が生じたりしません。境界は暗黙の了解で保つものではなく、役割定義の中に明文で書き込むべきものです。
引き継ぎ設計:渡すのは成果物の契約であり、半製品ではありません
役割の間で最も問題が起きやすいのが引き継ぎで、MAST の失敗の約 32% がこの層に落ちます。引き継ぎの失敗は多くの場合、データが届かなかったのではなく、受け取った側が完了したのか判断できず、形式も合わない何かを受け取ってしまうことです。良い引き継ぎは一つの契約として設計すべきです。エンジニアリングの実装ではすでに定まった手法があります。OpenAI が 2025 年にオープンソース化した Agents SDK は、引き継ぎを一つのツール呼び出し(transfer_to_X)として実装し、Guardrails で引き継ぎ境界の入力と出力を検証します。これは実質的に、すべての引き継ぎに検査を通すことを強制します。明確な引き継ぎ契約は、少なくとも次の四点を含みます。
| 契約の要素 | 答えるべき問い |
| 入力の前提 | 受け手が開始するには、どの条件が整っている必要があるか |
| 出力の形式 | 引き渡すものはどんな見た目で、どんな構造で表すか |
| 完了の定義 | どの条件を満たせば「やった」ではなく「完了」とみなすか |
| 検収条件 | 下流はどの基準で受理または差し戻しを判定するか |
すべての引き継ぎ点を検収条件付きの関門に変えれば、ワークフローは誤りを下流へ延々と持ち込まなくなります。研究によれば、調整されていないマルチエージェントシステムは誤りを最大 17 倍に増幅する一方、中央の検証で検問するアーキテクチャは約 4.4 倍に抑えられます。上流の成果物が完了の定義に合わないなら、引き継ぎのその場で差し戻すべきです。下流が半製品を無理に押し進め、最後になってようやくパイプライン全体の結果が使えないと気づく、という事態を避けるためです。
分解と引き継ぎで最も踏みやすい五つの落とし穴
- 細かく切りすぎる:単位が多すぎて調整コストが分業の利点を上回り、エージェントは大半の時間を互いの待機と引き継ぎに費やします。
- 役割の重複:二つの役割の責務記述に重なりがあり、実運用では奪い合うか押し付け合うかになります。
- 作ると審査が分かれていない:実行者に自分の成果物を審査させるのは検問がないのと同じで、品質に二重の防衛線がありません。
- 完了の定義がない引き継ぎ:「結果を次に渡す」としか言わず、何をもって完了とするかを示さないため、下流は推測するしかありません。
- 境界を暗黙の了解に頼る:責務と引き継ぎを明文化しないため、タスクや状況が変わると各自が解釈し始め、めいめいが独自に進めます。
この五つの落とし穴に共通する解決策は、分解・役割・引き継ぎを、まず設計し書き出すべきものとして扱い、エージェントをつないだ後に成り行きに任せないことです。MAST の失敗の 24% が検証の欠如によるものであることに呼応します。ワークフロー設計は本質的に設計の仕事です。設計が明確なほど、マルチエージェントシステムは予測しやすく保守しやすくなり、問題が起きたときも、どの役割がなすべきことをしなかったかを特定しやすくなります。
恩梯科技(Nerdtechnic):AI ワークフローを正しく分け、なめらかにつなぐお手伝い
マルチエージェントシステムが安定して成果を出すために難しいのは、エージェントをつなぐことではなく、作業を正しく分け、役割と引き継ぎを明確に定めることです。これは多くのプロジェクトが本番稼働後にようやく踏む落とし穴でもあります。恩梯科技の AI システムコンサルティングサービスは、まずお客様の実際のプロセスを棚卸しし、目標を検収可能な作業単位に分解し、各役割の責務と境界を定義し、検収条件付きの引き継ぎ契約を設計します。これにより、お客様の AI ワークフローは最初から明確な分業の上に育ち、本番稼働後に各役割がめいめい独自に動いて結果がかみ合わない、という事態を避けられます。
参考資料