L4Agentを一つ増やす前に、誰が決めるのかを決めておく

ECプラットフォームでは、セールの商品ページの文案が公開されるまでに、いくつもの関門を通ります。マーケティングは売りをもっと強く打ち出したい。法務は断定的な表現や違反になりそうな表現をすべて削る。カスタマーサポートは、ページの約束が守れないことを心配する。越境サイトのチームは、それを現地で使える形に直したい。どの立場にも理があり、しかもたびたびぶつかります。

前回の最後に書いたとおり、こうしたタスクを単一のL3 Agentに任せると、ひとつのプロンプトの中で全員の立場を同時に代弁するしかありません。衝突は黙って処理され、誰が譲ったのかが見えなくなります。

L3は、ひとつのことをやり遂げさせます。L4が答えるべきなのは別の問いです。いくつものことが衝突したとき、誰が決めるのか、いつ止めるのか。この二つに答えられないままAgentを増やしても、意見の食い違いが見えにくくなるだけです。

L4が必要になるとき

ひとつのタスクに互いに衝突する複数の目標があり、異なる視点で牽制し合い、最後に誰かが裁定する必要があるときだけ、L4が必要になります。 並列呼び出しや複数システムをまたぐだけなら、L3でもできます。

この線は厳しく引く必要があります。L4は高くつくからです。Agentが一つ増えるたびに、モデルの呼び出しが増え、待ち時間が延び、問題が起きたときに調べる場所も一つ増えます。だから私は一段ずつ上に試していきます。意図の振り分けはL2のルーティングに、データを取ってレポートを作るような目標のはっきりしたタスクはL3に。上のような衝突が出てきたときだけ、L4に上げます。

この基準で冒頭の商品ページを見直してみます。マーケティング、法務、カスタマーサポートの目標が引っ張り合い、最後は誰かが決めなければならない。これはL4の仕事です。三つのシステムから数字を取ってきて一本のレポートにまとめるだけなら、L3で足ります。

職種ではなく、関心事で分ける

L4に取りかかる多くのチームは、最初に組織図をなぞってAgentを作ります。営業Agent、マーケティングAgent、財務Agent。直感的にはもっともですが、たいていは各Agentが何でも少しずつ担当し、小さなL3がいくつもできるだけになります。彼らが本当は何を争っているのかも、かえって見えにくくなります。

より安定した分け方は、各Agentにひとつの目標だけを代弁させることです。商品ページの例なら、何でもこなす「文案Agent」を一つ作るのではなく、二つに分けます。ひとつはコンプライアンスだけを見て、すべての文を広告表現の基準とプラットフォームの規約に照らす。もうひとつは約束が守れるかだけを見て、ページに書いた約束（発送日、価格保証、返品・交換）をアフターサービスと倉庫が引き受けられるかを確かめる。仕入れでも同じです。購買に必要なのは「購買担当Agent」ではなく、在庫水準を見るAgentと、キャッシュフローを見るAgentです。この二つの目標はもともとぶつかり合うもので、その衝突こそ、人に見せるべき情報です。

職種は、組織が分業のために設計したもので、ひとつの職種の中に複数の目標が同居していることがよくあります。意思決定の場で本当に引っ張り合っているのは、そうした目標のほうです。

誰が決め、いつ止めるのか

複数のAgentがそれぞれ意見を言うだけでは、まだシステムとは呼べません。安定して結論にたどり着くには、少なくとも三つのことを先に決めておく必要があります。

一つ目は、全員が同じものを直すこと。Agent同士がチャット履歴を伝え合って引き継ぐのではなく、全員がひとつの作業ドキュメントを見ます。いまの文案の下書き、各立場の意見、このラウンドで何が変わったか。誰がどの部分を変えてよいかは事前に決めておきます。そうしないと誰でも何でも変えられるようになり、どの版が正しいのか、すぐに誰にも分からなくなります。各ラウンドの記録も残し、問題が起きたら直前の安定した版に戻れるようにしておきます¹。

二つ目は、書かない審査役を置くこと。審査役の仕事はひとつだけ、この版が通るかどうかを判断することです。審査役はモデルでなくてもかまいません。多くの場合、いちばん良い審査役は決まったルールです。広告表現の禁止語リスト、プラットフォームの規約、アフターサービスの方針。ルールで判断できることは、モデルの推測に任せません。

三つ目は、いつ止めるかを先に決めておくこと。複数のAgentが陥りやすいのは、こちらが直すと向こうが戻し、いつまでも終わらないという罠です。よく使う止め方は三つあります。ラウンド数が上限に達したら、まとめに入る。各立場の修正がだんだん小さくなり、一定以下になったら、合意とみなす。重要なトレードオフに当たったら、そのまま人に判断を委ねる。

graph TD
  A[タスク：セールの商品ページの文案] --> B{オーケストレーター}
  B --> C[視点 A：マーケティング]
  B --> D[視点 B：約束を守れるか]
  B --> E[視点 C：コンプライアンス]
  C <--> F[共有の作業ドキュメント]
  D <--> F
  E <--> F
  F --> G[審査役 Evaluator]
  G -- 不合格 --> B
  G -- 合格、またはトレードオフ --> H[人が決める]

引っ張り合いを見えるようにする

L4のインターフェースは、答えをひとつ返すだけではいけません。各立場がどう引っ張り合ったのかが、ユーザーに見えている必要があります。たとえば「コンプライアンスはプラットフォームの規約に基づいて、タイトルから『業界最安値』を削除した。マーケティングはこれに異論を示し、書き直し案を出した」。理由が見えて初めて、人は判断できます。

もうひとつ役に立つのは、各立場の重みをユーザーが調整できることです。今四半期はコンプライアンス優先、次の四半期は効率優先。変える回数は多くありませんが、一回ごとが本物の業務判断です。

よくある三つの失敗

以下の三つの名前は私がつけたもので、文献に定まった呼び方はありません。

• 共振ハルシネーション：Aが誤った前提から結論を出し、BがAの出力の上にさらに積み上げる。最後には、筋が通っていて、きわめて具体的で、しかし完全に間違った結論ができあがります。Agent同士が裏付け合うので、誤りがかえってもっともらしく見えます。
• 妥協的コンセンサス：衝突する要求のバランスを取ろうとして、誰も反対しないが、誰も実行できない結論が出てきます。衝突は裁定されたのではなく、ならされただけです。
• 状態ドリフト：ラウンドが重なるうちに、もとの目標が細部の応酬に埋もれ、最終成果物が本題からずれていきます。マルチエージェントの失敗分類MASTでいう「タスクの脱線」（task derailment）にほぼ当たります²。

何で組むか

2026年10月時点で、マルチエージェントシステムを組むのによく使われるフレームワークには、LangGraphやCrewAIがあります³。MicrosoftのAutoGenはアーカイブされ、メンテナンスも終わっています。新しいプロジェクトには、Microsoft Agent Frameworkが推奨されています⁴。

フレームワークの移り変わりは速いものです。まず上の三つ、共有の作業ドキュメント、審査役、止めるルールをはっきりさせておけば、フレームワークを替えるときに直すものはずっと少なくなります。

おわりに

冒頭の商品ページに戻ります。マーケティングは強く打ち出したい、法務は安全でありたい、カスタマーサポートはどの約束も守りたい。L4はこの引っ張り合いを消してはくれません。L4にできるのは、引っ張り合いを机の上に出し、どの立場の理由も見えるようにして、最後の判断を人に委ねることです。

次回はシリーズ最後の記事で、評価について書きます。Agentがどれだけ速く変わっても、まず何を解決するのかをはっきりさせる、という話です。