2026-08-27·無料·論文·12分で読めます

マルチエージェント設計パターン — 分担・討論・検証

エージェントを何体並べても、全員が同じ間違い方をするなら1体と変わりません。多数決が効く条件を式で押さえたうえで、分担・討論・敵対的検証の3つの型を、いつ使い、いつ1体で済ませるべきかまで整理します。

要点

同じ問題を n 体に解かせる多数決は、各体の正解率 p が 0.5 を超え、互いに独立に間違える場合にのみ有効である。
誤差の相関を ρ とすると、体数を増やしてもばらつきは σ²ρ より下がらず、同一モデル・同一プロンプトでは ρ が 1 に近い。
分担は精度より文脈のための型で、分けた仕事が互いの途中経過を知らなくても成立するときに効く。
討論は他人の理由を入力に入れて書き直す型で、同調を防ぐため1ラウンド目は他人の答えを見せず、最終決定は別の審判役に任せる。
敵対的検証の効果は検証器が誤答を落とす確率 r で決まり、コードのテストなど機械検証が閉じる場合が最も強い。

#agents #multi-agent #llm #system-design #evaluation

対象textタスクagent

Improving Factuality and Reasoning in Language Models through Multiagent Debate

一次資料 — この記事の根拠

この解説の公開 2026-08-27

Improving Factuality and Reasoning in Language Models through Multiagent DebatearXiv:2305.14325論文ページ·PDF

Self-Consistency Improves Chain of Thought Reasoning in Language ModelsarXiv:2203.11171論文ページ·PDF

AutoGen: Enabling Next-Gen LLM Applications via Multi-Agent ConversationarXiv:2308.08155論文ページ·PDF

会議を増やせば賢くなるのか

「三人寄れば文殊の知恵」には隠れた前提があります。3人が違う考え方をしていることです。同じ教科書で同じ研修を受けた3人なら、同じところで同じ勘違いをします。そこで多数決を取れば、間違いが3倍の自信を持って確定するだけです。

LLMエージェントを複数並べる設計は、この諺の工学版です。1体のエージェント（LLMエージェントを1から解説で扱った、考える→道具を使う→結果を見る、のループ）を複数走らせ、役割を分け、答えを突き合わせる。うまくいけば1体では届かない品質に届き、うまくいかなければ料金だけが体数の分だけ増えます。

この記事は「どんなときに増やすと得か」を先に決めてから型を見ます。順番が逆だと、流行りの構成をコピーして、遅くて高くて精度が同じシステムができあがるからです。

増やして得をする条件を、数で押さえる

いちばん素朴な形から始めます。同じ問題を $n$ 体に解かせ、多数決を取る。各体が確率 $p$ で正解し、互いに独立に間違えるとします。

P_{\text{maj}}(n) = \sum_{k > n/2} \binom{n}{k}\, p^{k} (1-p)^{\,n-k}

(1)

つまりこれは、少し表の出やすいコインを $n$ 枚投げて、表が過半数を占める確率を数えているのと同じ形です。 $p$ が1枚あたりの表の出やすさ（＝エージェント1体の正解率）、 $n$ が投げる枚数（＝体数）にあたります。

式(1)が言っているのは「 $n$ 体のうち過半数が正解する確率」だけです。 $\binom{n}{k}$ は「 $n$ 体から $k$ 体を選ぶ組み合わせの数」、 $p^k(1-p)^{n-k}$ は「その $k$ 体が当たり、残りが外れる確率」。大事なのは向きです。 $p > 0.5$ なら $n$ を増やすほど1に近づき、 $p < 0.5$ なら逆に0へ落ちます。もともと半分も当たらないタスクでは、体数を増やすほど確実に間違えます。

そしてこの式は「独立に間違える」という一行の仮定に全部を賭けています。誤差同士の相関を $\rho$ とすると、 $n$ 体の平均のばらつきはこうなります。

\operatorname{Var}\!\left(\frac{1}{n}\sum_{i=1}^{n} e_i\right) = \sigma^{2}\left(\frac{1}{n} + \frac{n-1}{n}\rho\right) \;\xrightarrow[\;n \to \infty\;]{}\; \sigma^{2}\rho

(2)

つまりこれは、体数を増やして薄められるのは「各体がばらばらにやらかす分」だけで、「全員が揃って同じ方向にやらかす分」は何体並べても残る、ということです。右側の矢印は「体数を無限に増やしたときの行き先」を表しています。

$e_i$ は各体の誤差、 $\sigma^2$ はその大きさ、 $\rho$ は「2体が同じ方向に間違える度合い」です。式(2)が伝えるのは1点だけ。体数をいくら増やしても、ばらつきは $\sigma^2\rho$ より下には行きません。 $\rho=1$ 、つまり全員が完全に同じ間違い方をするなら $1/n$ の項は消え、100体並べても1体と同じです。

ここがマルチエージェント設計の急所です。同じモデルに、同じプロンプトで、同じ温度で解かせた出力は $\rho$ が1に近く、多数決も討論もほとんど効きません。効かせたければわざと違わせる必要があります。温度を上げる、プロンプトの切り口を変える（先に反例を探させる／先に結論を書かせる）、渡す資料を変える、モデル自体を変える。複数の推論経路を引いて多数決を取る自己整合性（self-consistency, Wang et al., 2022）以来、サンプリングの多様性は繰り返し使われてきた資源です。

FIG 1温度を下げると1つの候補にほぼ全部の確率が寄り、上げると平らになる。温度が0に近い並列サンプルは「同じ答えのコピー」に近づき、式(2)のρが1へ寄っていく

パターン1: 分担 — 文脈を切って並べる

役割分担は、精度のためというより文脈と注意のための型です。1本のプロンプトに「仕様を読む」「実装する」「テストを書く」「レビューする」を全部詰めると、後半の指示ほど守られにくくなり、履歴も膨らみます。これを別々のエージェントに割り、各自には自分の仕事に必要な資料だけを渡します。

型は2つに分かれます。パイプライン型は調査→設計→実装→検証のように前の出力が次の入力になる直列型で、どこで壊れたか追いやすい代わりに上流のエラーが下流へそのまま流れます。ファンアウト型は独立な小仕事（10個のファイルを各々移行する、5つの観点でレビューする）を同時に配る並列型で、所要時間が最も遅い1体で決まります。

分担が効く条件はひとつです。分けた仕事が、互いの途中経過を知らなくても成立すること。共有状態が要る仕事を無理に分けると、片方が古い前提のまま進み、統合の段で辻褄が合いません。ファイルを書くエージェントを並列に走らせるなら、作業ディレクトリを分ける（gitならワークツリーを分ける）のが安全です。受け渡しの形式も固くしておきます。自然文で引き継ぐと下流のパースが割れるので、JSONスキーマで型を決めます（構造化出力と制約デコーディング）。

パターン2: 討論 — 互いの答えを読んで書き直す

討論（multiagent debate）は、 $n$ 体に独立に答えさせたあと、全員の答えを全員に見せてもう一度書かせる型です。数ラウンド繰り返し、収束した答えを採用します。Du らはこの手順で、数学や事実確認の課題において単発の生成より妥当な答えに寄ることを報告しました（Du et al., 2023）。多数決との違いは、他人の理由が入力に入る点です。ある体が見落とした条件を別の体が明示していれば、書き直しの過程で取り込めます。

同時に、討論には固有の失敗モードがあります。同調です。LLMは「あなたの答えは間違っているのでは」と言われると正しい答えを撤回する傾向があり、多数派が誤っている場面で全員が引きずられると、討論は誤りを増幅する装置になります。実務では3点で抑えます。

1ラウンド目は他人の答えを見せない（独立な初期案を確保する）
「相手に合わせる」ではなく「根拠を示して反論するか、根拠を示して撤回するか」を要求する
最終決定を参加者にさせず、別の審判役に理由の質で選ばせる

審判役を置くと、討論の強さと判定の強さを分けて調整できます。Khan らは、討論者側を強くすると判定側が自力では解けない問題でも正しい側を選びやすくなることを示しました（Khan et al., 2024）。判定は生成より簡単という非対称性が、この型の土台です。

パターン3: 敵対的検証 — 通す側と落とす側を分ける

3つ目は、書く役と落とす役を分ける型です。検証役には「良いか悪いか」ではなく「この答えが壊れる具体的な入力を1つ挙げよ」と反証を仕事として与えます。曖昧な評価を求めると「良いと思います」が返るだけで、フィルタとして機能しません。

効果は素直な条件付き確率で書けます。生成器の正解率を $p$ 、検証器が誤答を正しく落とす確率（再現率）を $r$ 、正答を誤って落とす確率を $f$ とします。

\Pr(\text{正解} \mid \text{通過}) = \frac{p\,(1-f)}{p\,(1-f) + (1-p)\,(1-r)}

(3)

つまりこれは、検証を通った答えのうち本当に正しいものの割合を、「正しくて通った量 ÷（正しくて通った量＋間違っているのに通ってしまった量）」で測っている、ということです。左辺の縦棒は「〜という条件のもとで」と読みます。

分子は「正しくて、かつ通ったもの」、分母の第2項は「間違っているのに見逃されたもの」です。式(3)から読むべきは、効くのは $r$ だということ。誤答の半分しか捕まえられない検証器（ $r=0.5$ ）では見逃し項が半分しか減らず、通過分の質はたいして上がりません。逆に $f$ が大きい検証器は正しい答えを捨てて再生成を呼ぶので、精度ではなく料金に響きます。

この型が最も強いのは検証が機械で閉じるときです。コードならコンパイルとテスト、SQLなら実行、JSONならスキーマ検証。 $r$ が実質的に高く、しかもLLMを呼ぶ必要がありません。「まず自動検証、残る観点だけをLLM検証役へ」が費用対効果として素直な順番です。1体に長く考えさせる方向（推論時スケーリング）と複数体で検証し合う方向は、生成に対して追加の計算を払う同じ家族です。

増えるのは賢さだけではない

コストを最後に回すと設計をやり直す羽目になります。討論型の1回の実行で読むトークンは、おおよそ 体数 × ラウンド数 × 各体の出力の合計。全員が全員の答えを読む構成では、1ラウンドあたりの読み込み量が体数の2乗で効きます。

FIG 2全員が全員の出力を読む討論では、1ラウンドの読み込み量が体数の2乗で伸びる。「4体を8体に」がなぜ2倍で済まないのかが、この曲線の差

遅延も同じです。パイプライン型の所要時間は各段の和、ファンアウト型は最大、討論型はラウンド数だけ和が積み上がります。対話型の製品に3ラウンドの討論を入れれば、体感は確実に悪くなります。

コードで書く最小形

3つの型は、実装としてはこの骨格に収まります。

def solve(task, n=3, max_rounds=2):
    drafts = [propose(task, temperature=0.9, seed=i) for i in range(n)]  # 独立に書かせる
    for _ in range(max_rounds):
        reports = [critique(task, d) for d in drafts]      # 落とす役。反例が無ければ ok
        if all(r.ok for r in reports):
            break
        drafts = [d if r.ok else revise(d, r.evidence)     # 指摘されたものだけ書き直す
                  for d, r in zip(drafts, reports)]
    return judge(task, drafts)                             # 別の審判役が理由の質で1つ選ぶ

seed と temperature が式(2)の $\rho$ を下げる仕掛け、critique が式(3)の $r$ 、max_rounds が予算の上限です。この3つが表に出ていない実装は、後からどこを回せば良くなるのかが分かりません。

いつ1体で足りるか

増やさないほうがよい場面のほうが、実は多いです。

単発の正解率がすでに高い: $p$ が0.9を超えていれば多数決の伸びしろは1割未満。同じ予算はプロンプトと資料の整備に回すほうが効きます
検証が自動で閉じている: テストが通るまで1体にリトライさせるほうが安くて確実です
タスクが分けられない: 全体を同時に見ないと判断できない仕事は、分担すると各体が部分最適な答えを返します
レイテンシが要件: 対話UIの裏では、ラウンド数の積み上げがそのまま待ち時間です
誤りが相関している: 同一モデル・同一プロンプトで並べただけなら $\rho$ は1に近く、体数は料金にしか効きません

出発点は常に「1体 + 道具 + リトライ」です。その基線を実測し、失敗の内訳を見てから決めます。失敗が「見落とし」なら分担、「思い込み」なら討論、「もっともらしい嘘」なら検証。この対応づけがつかないうちに体数を増やすのは、原因を特定せずに薬を増やすのと同じです。

現場ではこう使う

この判断が実際に発生するのは、LLMアプリのバックエンド担当が回答品質のクレームに対処するとき、評価担当が「体数を増やせば上がるのか」を問われるとき、社内ツールの運用担当がエージェントの請求額を説明するときです。

触るパラメータは限られています。多様性を作る temperature / top_p / プロンプト差分、体数の n、討論の max_rounds、打ち切りのトークン予算とタイムアウト、並列度（concurrency）、審判役に使うモデル、受け渡しのJSONスキーマ、リトライ回数。配線と状態管理は LangGraph・AutoGen・CrewAI や各社のエージェントSDKが持っています。可観測性は必須で、Langfuse や OpenTelemetry などで1リクエスト＝1トレース、各体＝1スパンにしておかないと、どの体が事故ったのか永久に分かりません。

知らないと事故になる落とし穴を挙げます。第一に、同一モデル・同一プロンプトの並列は多数決にならない（式(2)）。第二に、討論の同調で正しい少数意見が消える。第三に、並列エージェントの書き込み衝突——同じ作業ディレクトリを触らせると片方の編集が上書きされます。第四に、終端条件の欠落。「合意するまで討論」は合意しないとき止まりません。ラウンド上限とトークン予算は必ず外側から掛けます。第五に、検証役の偽陰性。「問題ありません」しか返さない検証役は $r \approx 0$ で、コストだけを増やします。反例を1つ挙げさせる、テストを実際に走らせる、と具体的な作業に落とすのが対策です。

設計レビューでよく問われるのは「エージェントを増やしたのに精度が上がらない。なぜか」です。筋道は式(2)と式(3)で通せます。誤りが相関していないか（多様性の作り込み）、検証器の再現率が足りているか（見逃し項）、単発の正解率が0.5を割っていないか。この3つを確認せずに体数だけ増やした構成は、遅くて高いだけの単一エージェントとして振る舞います。

まとめ

多数決が効くのは「半分以上当たる」かつ「独立に間違える」ときだけ。相関 $\rho$ がばらつきの下限を決める（式(1)(2)）
分担は精度より文脈の型。分けられるのは互いの途中経過が要らない仕事だけ
討論は他人の理由を入力に入れる型。同調を防ぐため初回は独立、最終決定は別の審判役へ
敵対的検証は「反証を仕事にする」型。効くかどうかは検証器の再現率 $r$ で決まり、機械検証が使えるならそれが最強（式(3)）
増やす前に1体の基線と失敗の内訳を測る。見落としなら分担、思い込みなら討論、嘘なら検証