マルチエージェントはいつ必要？分業で速くなる仕事と複雑になる仕事を見分ける
複数のAIエージェントへ分ければ、必ず一体より賢くなるわけではない。独立して調べられる仕事は並列化の恩恵を受けやすいが、前の結果を細かく共有しながら進める仕事では、引き継ぎと調整の負担が増える。最初に一体のエージェントで作り、分業する理由を説明できる部分だけを切り出すのが基本だ。
例えば、三つの国の制度を調べて比較する架空の依頼なら、国ごとの調査を別のエージェントへ任せ、最後に一体が統合できる。一方、一つの短い文章を一文ずつ別のエージェントへ書かせても、文脈の共有と修正が増え、品質も速度も悪化しやすい。
分ける基準は役職名ではなく仕事の境界
「企画担当」「分析担当」「批評担当」と名前を付けただけでは、分業にならない。それぞれが受け取る入力、使える道具、返す結果、終了条件を定義する。二体が同じ検索を行い、同じ長文を返すなら、役割が重複している。
分離が役立つ代表的な条件は、複数の調査先を独立して探索できること、専門ごとに道具や権限を狭められること、一体の文脈へ入りきらない情報を別々に圧縮できることだ。Anthropicのマルチエージェント研究システムは、異なる観点を並列に探索する幅優先の調査、単一の文脈を超える情報、多数の複雑な道具を扱う仕事を適性として挙げている。
反対に、全員が同じ細かな状態を常に共有する仕事や、段階間の依存が多い仕事は不向きだ。担当を増やすほど、古い状態を参照する、同じ操作を重複する、互いの返答を待つといった問題が増える。
管理役が専門役を道具として呼ぶ
一つ目の構成は、管理役が利用者との会話を持ち続け、専門役を道具として呼ぶ方式だ。専門役は調査や分類など限定された結果を返し、管理役が複数の結果を統合して最終回答を作る。
OpenAI Agents SDKのオーケストレーション資料は、この方式をagents as toolsとして説明している。最終回答の責任を一体へ集めたいとき、複数の専門結果を組み合わせたいとき、共通のガードレールを一か所で適用したいときに向く。
管理役へ渡す結果は、長い思考過程ではなく、必要な事実、根拠、未確認事項、安定したIDを含む構造化データにする。誰が何を確認したかを残せば、統合時の重複と矛盾を見つけやすい。
会話そのものを専門役へ引き継ぐ
二つ目は、受付役が依頼を分類し、適切な専門役へ会話の担当を移すhandoffだ。選ばれた専門役が、その後の応答を直接担当する。問い合わせの種類ごとに必要な指示と道具が明確に違い、管理役が毎回答えを言い直す必要がない場合に向く。
引き継ぐ情報は最小限にする。利用者の依頼、確定した制約、必要な識別子、すでに終わった操作を渡し、無関係な会話や秘密情報を丸ごと共有しない。引き継ぎ先で権限が増える場合は、受付役の判断だけで許可せず、アプリケーション側で利用者の権限を再確認する。
誤った専門役へ渡した場合の戻り方も決める。たらい回しを防ぐため、最大引き継ぎ回数と、人へ戻す条件を設定する。
流れが決まっているならコードで制御する
調査、構成作成、執筆、校正という順番が固定なら、モデルに毎回次の担当を選ばせる必要はない。コードで順番を決め、各段階へ構造化した入力を渡す方が、速度、費用、再現性を管理しやすい。OpenAIの資料も、LLMが決めるオーケストレーションと、コードが決める方式を分け、後者をより決定的で予測しやすい方式としている。
独立した調査だけを並列に実行し、統合や書き込みは順番に行う。どの処理が前の結果へ依存するかを先に図にすると、並列化できる部分が見える。単に複数エージェントを同時に起動するだけでは、同じ道具やレート制限へ集中し、かえって遅くなることがある。
委任指示に完了条件を含める
専門役へ「この件を調べて」とだけ渡すと、調査範囲が重なり、必要な項目が抜ける。委任には目的、対象範囲、使ってよい情報源と道具、出力形式、終了条件、時間や呼び出し回数の予算を含める。
Anthropicの事例では、短く曖昧な委任により複数の専門役が同じ検索をしたり、別の年代を調べたりしたため、調整役へ役割分担と労力配分を明示したという。簡単な質問で多数の専門役を起動しないよう、依頼の複雑さに応じて数と道具の回数を変える必要もある。
専門役は「見つからなかった」という結果も返せるようにする。不足を隠してもっともらしい答えを作ると、管理役が誤った前提で統合する。根拠のURL、取得時刻、確認できなかった項目を共通形式にする。
費用と失敗はエージェント数に伴って増える
並列化は待ち時間を短くできるが、モデル呼び出しとトークンは増える。Anthropicは同社の研究システムについて、マルチエージェント構成が通常のチャットより大幅に多くのトークンを使うと報告し、高い価値がある仕事でなければ経済性が合わないと説明している。この数値を別の構成へそのまま当てはめることはできないが、分業を無料の性能向上と考えない方がよい。
一体が失敗したとき、全体を最初からやり直さない。専門役ごとに実行ID、状態、結果を保存し、失敗した部分だけを再試行する。遅い一体を永遠に待たないよう期限を設け、必須結果が欠けた場合と、部分結果だけで続行できる場合を分ける。
共有の書き込み先がある場合は、同じ対象を複数の専門役が更新しないよう所有者を決める。外部への公開や送信を各専門役へ任せず、統合後の一か所に集めると承認と重複防止を設計しやすい。
全体と専門役を別々に評価する
最終回答の正しさだけでなく、調整役が必要な仕事へ分解したか、範囲の重複と抜けがないか、適切な専門役と道具を選んだか、期限と予算を守ったかを評価する。専門役単体では正しくても、統合時に矛盾を無視すれば全体は失敗だ。
最初は単一エージェントを基準にし、同じ評価データでマルチエージェント構成と比較する。品質向上が追加費用、遅延、運用の複雑さに見合う仕事だけを移す。前の記事で扱った構成IDには、調整方式、専門役の版、委任形式も含め、変更時は小さく展開する。
マルチエージェントの価値は、AIの人数ではなく、独立した仕事を明確に分けられることにある。境界のない分業は会話を増やし、境界のある分業は並列性、専門性、文脈の分離を活かせる。