UnitBoost：複合LLMシステムの「管理役」はLLMである必要があるのか——生成モデルを決定的なマージ演算子で置き換える

はじめに：複数のLLMを束ねるシステムに潜む「見えない管理者」

複合LLMシステム（compound LLM system）とは、1回のモデル呼び出しで答えを出すのではなく、複数の呼び出しの結果を組み合わせて最終的な答えを組み立てる仕組みを指す。たとえば、検索した複数の文書を別々のワーカーに読ませて多段の質問に答えるRAGのマルチホップ質問応答、複数モデルの案を1つに統合するMixture-of-Agents、複数のエージェントに議論させて合意を取るマルチエージェント・ディベート、自分の出力を批評して書き直す自己改良ループなどがこれにあたる。いずれも「複数の案をどう1つに畳むか」という共通の問題を抱えている。

こうしたシステムには、必ず「管理者（manager）」がいる。管理者の仕事は次の3つの決定に整理できる。

現在の主流設計では、この3つの決定は「もう1つのLLM」、すなわちメタエージェントに委ねられている。管理者自身が生成モデルなので対応の幅は広い。しかしその代償は小さくない。なぜその記述が採用されたのかは自然言語の根拠としてしか残らず検証できない。候補の並べ方を変えると結果が変わる。どの部分がどのワーカーに由来するのかを最終出力から追うこともできない。管理の3決定が、1回の不透明なモデル呼び出しに集中してしまっているのだ。

ここで問いを立て直したい。管理者は、生成モデルである必要があるのか。 統合・配分・停止という3つの決定は、決定的な演算子（argmax）――与えられた候補の中からスコア最大の値を機械的に選ぶ操作――で置き換えられる。出力全体を文章として競わせるのではなく、後述する「単元（unit）」という構造化された部品ごとに、どのワーカーのどの値を採用するかを明示的に選ぶ。この一手で、見えない管理者は、選択の理由と出所をすべて記録する検証可能な部品に変わる。候補選択の天井を超える仕組みは、この単元ごとの選択から生まれる。

なぜ「LLMに管理させる」設計が問題なのか

複合LLMシステム（compound LLM system／複数のモデル呼び出しを組み合わせて1つの答えを出す仕組み）では、上位の管理者が3つの仕事を担う。ワーカーの部分結果を最終出力にまとめる統合、未解決の部分に次の呼び出しを割り当てる配分、そしてこれ以上続けても意味がないと判断する停止である。現在の主流構成では、この3つがもう1つのLLM――メタエージェント――への1回のプロンプト呼び出しにまとめて詰め込まれている。この設計には構造的な欠陥がある。

第一に不透明さ。なぜその記述が採用されたのかは自然言語の根拠としてしか残らず、後から検証できない。第二に順序依存。候補の並べ方を変えると結果が変わる。実際、同一の5ワーカーを逐次チェーンで並べ替えると、57.5%の問題で出力スコアが変化したと報告されている。第三に出所の消失。どの部分がどのワーカーに由来するかを、最終出力からは追えない。要約と書き換えの過程で、どの候補にも支持されない主張が混入する余地も生まれる。

さらに、統合という工程そのものの限界も指摘されている。複数候補の統合は多くの場合、実質的に「1つの案をコピーしているだけ」で、管理者は選択器として振る舞うにすぎない（選択のボトルネック）。複数モデルが同時に失敗する問題では組み合わせの価値が頭打ちになる（共倒れ上限）。ワーカー同士が完全解を共有すると多様性が失われる（相互作用税）。いずれも「LLMを積めば賢くなる」という素朴な期待に対する具体的な反例である。

ここから導かれる結論は単純だ。どんなに優れた選択器でも、受け取った候補のうち最良のものを超えられない。ワーカーAが前半だけを正しく、ワーカーBが後半だけを正しく答えたとしても、両者を貼り合わせた答えはどの候補にも存在しない。それを実現するには別モデルによる書き直しが要る。だが書き直しは出所を消す。これが生成的管理者が抱えるジレンマである。

flowchart LR
  subgraph G["生成的管理者（LLM）"]
    W1[ワーカーA] --> M[1回のモデル呼び出しで<br/>統合・配分・停止]
    W2[ワーカーB] --> M
    M --> O1["最終出力<br/>出所不明・順序依存・根拠が検証不能"]
  end
  subgraph U["決定的なマージ演算子"]
    V1[ワーカーA] --> T["単元テーブル<br/>制約付きargmax"]
    V2[ワーカーB] --> T
    T --> O2["最終出力<br/>各値の出所を記録・順序不変"]
    T --> R["残差＝次の呼び出し先の名前"]
  end

UnitBoostの基本アイデア：「単元（unit）」という発想

UnitBoostの出発点は、「最終回答という完成品を丸ごと競わせるのをやめ、その中身を分解して部品単位で管理する」という発想の転換にある。ここでいう単元（unit）とは、タスクの出力を機械的に識別できる最小の構成要素のことである。文章全体や回答全体ではなく、答え1つ、セル1つ、メソッド1つという粒度で扱えば、どのワーカーがどの部分を供給したかを追跡でき、部分的に正しい複数のワーカー出力を組み合わせる余地が生まれる。

この変換を担うのが単元写像（unit map）Uである。U は各ワーカーの出力 y_i を受け取り、それをスロットと値の組 (s, v) の集合に変換する。スロット s がタスク定義上の単元を指し、v がそのスロットに対してワーカーが提案した内容である。提案がなければそのスロットは空（⊥）として扱われる。つまりUは「自然言語の回答」を「どのポジションに何を置くか」という表形式の提案に正規化する役割を果たす。

具体例で考えると分かりやすい。複数回答を求める質問回答タスク（例：QAMPARI）では、正規化した答え1つが1単元になる。表形式の答えを返すタスク（例：FanOutQA）では、エンティティが単元、その属性が値である。クラス単位のコード生成（例：ClassEval）では、メソッドのシグネチャが単元、実装本体が値になる。いずれも「1問1答の答え」「1セルの値」「1メソッドの実装」という粒で競わせる点が共通している。

この粒度の違いが、管理の結果を大きく左右する。候補選択（1つの出力を丸ごと選ぶ管理）は、候補のうち1行だけを見て決める。一方、単元ごとの統合は、各列から最良の値を独立に拾い上げ、それらを組み合わせた新しい出力を作れる。次の図は、候補（行）×単元（列）のスコア行列における両者の探索範囲の違いを示したものである。

flowchart LR
  subgraph candidates["候補（ワーカー出力）"]
    W1["候補1: 単元A✔ 単元B✘ 単元C✔"]
    W2["候補2: 単元A✘ 単元B✔ 単元C✘"]
    W3["候補3: 単元A✘ 単元B✘ 単元C✔"]
  end
  W1 --> SEL["候補選択: 1行だけを選ぶ"]
  W2 --> SEL
  W3 --> SEL
  W1 --> MERGE["単元ごとの統合: 列ごとに最良値を拾う"]
  W2 --> MERGE
  W3 --> MERGE
  SEL --> OUT1["出力: 候補1の全内容"]
  MERGE --> OUT2["出力: 単元A=候補1, B=候補2, C=候補1"]

候補選択では、どの行を選んでもその行の欠落がそのまま残る。単元ごとの統合では、ワーカーが異なる場所で不完全になっているほど、組み合わせで欠落を埋められる可能性が高まる。後述の実験結果が示すように、UnitBoostが候補選択の天井を超えられるかどうかは、この「単元が複数あり、ワーカーが違う場所で失敗している」という条件にかかっている。単元が1つしかないタスクでは両者は一致し、優位性は生まれない。

マージ演算子を定義する：制約付きargmaxと残差

マージ演算子（merge operator）とは、複数のワーカーが提案した値の集合から、単元ごとに1つの値を選び出し、永続的な出力テーブルを組み立てる決定的な関数である。同じ入力集合を与えれば常に同じ出力を返し、確率的な揺らぎを持たない。ここでは、この演算子の本体である「制約付きargmax」と、次にどこへ呼び出しを向けるかを決める「残差」を順に定義する。

flowchart LR
    A[ワーカー候補の集合<br/>各値に供給元とスコア] --> B[単元ごとにスコアリング q]
    B --> C[制約付きargmax<br/>実行可能性 C を満たす範囲で<br/>合計スコアを最大化]
    C --> D[採用値テーブル<br/>slot / value / worker / round]
    D --> E[残差 R_t の抽出<br/>未充填・実行不能・doubtful]
    E --> A

制約付きargmaxとしての定式化

単元の集合を (S)、スロット (s) に対する候補値 (v) のスコアを (q(s, v)) とすると、マージ結果 (V^*) は次のように書ける。

$$ V^* = \operatorname*{arg,max}_{V \in \mathcal{V}C} \sum{s \in S} q(s, V_s) \tag{1} $$

(\mathcal{V}_C) は実行可能な割り当ての集合で、2つの条件を満たすものだけを含む。第一に、各スロットの値は (\bot)（空）か、いずれかのワーカーが実際に提案した値であること。第二に、タスク固有の実行可能性述語 (C) を満たすこと（例：コードのシグネチャ整合、表のセル型制約、回答数の上限）。候補選択が「候補の行を1つ選ぶ」操作であるのに対し、この式は列（単元）ごとの値を最大化しつつ、(C) によって全体の整合性を担保する。

空スロット (\bot) を常に選択肢に含める点は重要である。証拠が薄い単元を無理に埋めるより、未充填のまま残したほうが最終的な精度が上がる場合があるからだ。同時に、非空の選択は必ず既存のワーカー出力に由来することが保証されるため、新しい文章をその場で生成してしまうハルシネーション的な混入が構造的に起こらない。採用した値には供給元ワーカー・スコア・検証トレースを併記し、出所を後から追える状態にしておく。

なぜ単元ごとの最大化が「選択」に勝てるのか

この演算子が候補選択の天井を超えられる理由は、単純な不等式にある。単元ごとの最大値の和は、どの完全候補の合計スコア以上になる。

$$ \sum_{s \in S} \max_{v} q(s, v) ;\geq; \max_{V} \sum_{s \in S} q(s, V_s) $$

等号が成り立つのは、「1つの候補が全単元で最大」のときだけである。したがって利得は不等式そのものからではなく、その例外——ワーカーがそれぞれ違う場所で不完全になっているときに生まれる。ただし、これは理論上の上限であって、得られた値同士が噛み合わない「修復コスト」を無視している。実際に主張できるのは「単元ごとの利得 − 修復コスト」であり、結合の強いタスクではこのコストが利得を食いつぶし得る。

スコア (q) の3階層

スコアの作り方は3段階に整理できる。上位の階層ほど強い信号を使うが、その分だけ前提条件が増える。

オラクル階層は手法ではなく性能の天井を示す参照値である。実装可能階層は開発データだけで校正し、評価データのラベルには触れない。検証器不要階層はランキング信号だけを使うため、外部の検証ツールなしに動く。

古典メタサーチとの位置づけ

複数の検索結果を統合する古典的なメタサーチは、この枠組みの特別なケースとして整理できる。CombSUM や RRF のような順位融合は「検証器を持たず、一致度だけを見る」マージであり、UnitBoost はそこに実行可能性述語 (C)、供給元の明示、そして残差ラウンドを足したものと位置づけられる。単元の概念を持たない従来手法では、統合は候補全体のスコア比較に留まるのに対し、単元ごとの argmax は列方向の積空間を探索できる点が前進である。

残差と停止：どこに次の呼び出しを使うか

残差（residual）(R_t) とは、ラウンド (t) が終わった時点で「まだ十分に埋まっていない」と判定されたスロットの集合である。具体的には、(1) どのワーカーも値を提案していない未充填スロット、(2) 提案はあるが実行可能性述語 (C) を満たさず採用できなかったスロット、(3) 採用された値が存在しない（正のスコアを持つ値が無い）doubtful なスロットの3種類が含まれる。この集合が、次のラウンドのワーカーに配る作業キューそのものになる。管理者が「どこに仕事が必要か」を名指しし、「何を提案するか」はワーカーに委ねる、という役割分担である。

配分の設計で重要なのは、次のラウンドのワーカーが受け取る情報を絞ることだ。渡すのは単元仕様・すでに採用された値・そのスロットで観測された局所的な失敗信号だけで、他のワーカーの完全解は決して渡さない。完全解を共有するとワーカー同士が似た答えに収束し、場所の異なる不完全さ＝相補性が失われてしまうからである。新しく提案された値は既存と同じ単元テーブルに挿入され、式(1)の argmax で既存値と競合する。

配分先を変えるだけで結果が変わることは、表形式の回答を扱う FanOutQA で確かめられている。第3ラウンドの呼び出しを4通りに振り分けたときのセル F1 は次のとおりである。

さらに、名指しする残差の個数と利得には用量反応がある。指定なしを基準にすると、残差1個では −0.0092、2個で +0.0263、3個以上で +0.0516 となり、残差サイズと利得の順位相関は 0.183（p=0.0075）だった。少数のスロットを名指しするほうが、まとめて「怪しいところを直して」と頼むより効く。

flowchart TB
    T1["ラウンド1：採用値テーブルを構築<br/>FanOutQA セルF1 0.4778"]
    T2["ラウンド2：残差 R_1 にのみ呼び出し<br/>0.5219"]
    T3["ラウンド3：残差 R_2 にのみ呼び出し<br/>0.5524"]
    T4["ラウンド4：ρ_t = 0.055 に枯渇<br/>−0.0073 を失い停止"]
    T1 --> T2 --> T3 --> T4

採用の判定には参入マージン (\delta) を置く。すでに値があるスロットでは、既存スコア＋(\delta) 以上のスコアを持つ新値だけが候補になれる（未充填スロットへの提案は常に候補になる）。これは勾配ブースティングの学習率にあたる縮小（shrinkage）の類似物で、後から来た値をむやみに上書きしないための抑制である。もっとも効果は控えめで、(\delta) を 0〜0.40 で掃引しても QAMPARI は最大 0.0023、ASQA では (\delta=0.10) で +0.0036 しか動かない。利得の本体は縮小ではなく、過去のラウンドが誰も埋めなかったスロットに値を足し続ける「被覆の拡大」にある。

停止の判断は供給シグナルで行う。(\rho_t) を「ラウンド (t) で提案された値のうち、新規スロットに落ちた割合」と定義し、(\rho_t) がしきい値 (\tau) 以下になったらループを止める。上の FanOutQA の例では、ラウンド4で (\rho_t) が 0.055 まで落ち、そのラウンドはスコアを 0.0073 下げた。ただしシグナルは1ラウンド遅れて反応する。非生産的なラウンドが起きたのは分かるが、それはスコアを失った後である。QAMPARI では質問あたりの新規回答数が 5.32 から 2.34 に落ちた段階で生産性が尽きるため、上限ラウンドと併用して遅れを織り込む運用が現実的だ。

この仕組みは勾配ブースティングと形が似ているが、同じものではない。

決定的な違いは、更新される対象である。ブースティングはモデルのパラメータを更新するが、ここで良くなっていくのはシステムが永続的に保持する単元テーブル、つまり出力そのものである。採用済みの値はラウンドをまたいで保持され、捨てられない。残差は「まだ埋まっていない場所」に名前を与えるだけで、過去の採用を蒸し返さない。

実験：どこで、どれだけ効くのか

ここまでは、単元ごとの制約付きargmaxが候補選択の天井を超えうるという理屈を述べてきた。実際にどれだけ超えるのか、そしてその利得がどこから来るのかを確認する。評価は6つのベンチマークで行われ、いずれもタスク側が単元インターフェース（どのスロットに何が入るかを決める定義）を提供する。

評価指標もタスクごとに異なる。QAMPARIは20回答を予算とした上限付き再現率、ASQAは12回答時点の読み手カバレッジ、ELI5は5文の原子的主張カバレッジ、FanOutQAは回答表のセルF1である。上限付きの再現率やカバレッジは「見つけた単元を足し合わせるほど得点が増える」加法性を持つが、セルF1は全出力に精度の罰則を課すため性質が異なる。この違いが後の結論を分ける。

候補選択の天井を超えられるか

最も直接的な比較は、正解ラベルを使って候補の中から最良の1つを選ぶ「オラクル候補選択」との差である。ここで使うワーカー・プロンプト・証拠・呼び出し回数は固定し、管理ステップだけを差し替えている。

3件はいずれも p<.001 で有意である。さらに、入力条件を揃えた生成的な統合（同じ証拠を読ませた管理者モデル）と比較しても、QAMPARIで+0.0480、ASQAで+0.0764の利得が出ている。単元ごとの値の中に組み合わせの余地があるタスクでは、単一候補を選ぶよりも列方向に最大化するほうが強い。

flowchart LR
    B1["単元が1つ<br/>両者は一致・利得ゼロ"] --> B2["単元が数個<br/>マージンが正に転じる"] --> B3["単元が多いほど<br/>積空間の探索余地が拡大"]

利得の大半は「スコア」ではなく「管理の作り方」から出る

利得の内訳を分解すると、意外な事実が現れる。QAMPARIでラベルを一切使わない逆順位融合（RRF）だけで、オラクル候補選択を+0.0655上回る。一方、UnitBoostのスコア設計が上乗せした分は+0.0063に過ぎず、最良のラベルなし規則と比べても+0.0055しかない。つまり性能の大半は、洗練された採点ではなく単元空間で選ぶという管理の構造そのものが生んでいる。

正解ラベルの予算を絞った場合の挙動も実務的である。10問分のラベルだけで、最終マージン0.0718のうち0.0618を確保できる。ラベルを増やすほど上乗せは伸び、厳しい予算設定でも20〜50問程度で最良のラベルなし規則を初めて超える。

既存プロトコルへの「管理だけ差し替え」

実用上いちばん気になるのは、すでに動いている構成に入れられるかどうかだろう。ワーカー・プロンプト・証拠・ラウンド・呼び出し回数をそのまま維持し、管理ステップだけを置き換える実験が6構成で行われている。

ディベートでは、最終ラウンドの単元だけでなく各ラウンドで提案された単元をすべて同じテーブルに蓄積すると、さらに+0.0467が乗った。過去のラウンドが誰も埋められなかったスロットの値を捨てないことが効いている。

フロンティアモデルに管理させる場合との比較

強いモデルを管理者に据えた場合はどうか。制約なしのClaude Sonnet 5は0.4918でUnitBoostの0.4685を上回る。しかしその出力を精査すると、ワーカーが提案していない単元をモデル自身が書いている。候補の和集合に制限すると、どの構成もUnitBoostを下回る（p≦0.0005）。逆に、無制約の出力を「11番目の提案（新しいワーカー）」として受け入れれば0.5132まで上がる。ここから導かれる設計指針は明快で、モデルには提案させ、採用は明示的な演算子に保つのがよい。

ワーカーの差し替えに対しても結論は安定している。ワーカーをQwen3-32Bに変えたQAMPARIの800問では0.4180、オラクル候補選択比で+0.0615を維持した。また順序への感度では対照的な結果が出ている。同じ5ワーカーを逐次チェーンで並べ替えると57.5%の問題でスコアが変化するのに対し、固定された候補集合に対するUnitBoostの出力は厳密に順序不変である。並べ替えで結果が変わらないことは、監査や再現の面で大きな利点になる。

効く条件と効かない条件：導入前チェックリスト

ここまでの利得は無条件に得られるものではない。単元構造と評価指標という2つの前提から、効く場合と効かない場合がかなりはっきり分かれる。導入を検討する前に確認しておくべき4点を整理する。

1. 相補性は「製造」しなければならない

相補性（complementarity）とは、複数のワーカーが互いに違う場所で失敗している状態を指す。単元ごとの最大化が候補選択を上回るのは、まさにこの状態のときだけである。互いに素な証拠の窓を読む10ワーカーは自然に相補的になるが、同じ証拠を10回読み直す確率的リサンプルでは相補性は生まれない。呼び出し回数と読めるパッセージ集合を固定したリサンプルプールでは、どの出力予算でもオラクル候補選択を超えられなかった。逆に証拠を分割すれば、ワーカー数を増やすほどマージンは伸びる。

必要なのは「弱い証拠」ではなく「分割可能な仕事」である点も押さえておきたい。検索品質を弱／標準／オラクル再順位と上げていくと、オラクル候補選択に対する利得は 0.0522／0.0718／0.1435 と増えていく。検索が良くなるほど、各ワーカーの不完全さの位置がずれ、組み合わせの余地が広がるためである。

2. 単元同一性が効く

「同じ意味の単元」を機械的に判定できるかどうかは、効き方を大きく左右する。言い換えをまたいで同一の事実を同一の単元と見なすのは難しく、語彙ベースの関係検出は同一事実ペアの5.9%しか捉えられず、誤統合率は1.3%だった。文埋め込みを導入してもペア識別は0.635から0.672に上がる程度で、5文の原子的主張カバレッジへの寄与は+0.0025にとどまる。一方、完全な参照同一性が与えられれば+0.1413が加算される。足りないのはしきい値の調整ではなく、異なる語で書かれた2つの文が同じ単元を占めると判定する能力そのものである。

3. 結合は修復コストとして現れる

単元同士が独立していない場合、単元ごとの最大化は「組み上げたときに壊れる」リスクを抱え込む。クラス単位のコード生成では、単体で自分のテストに通るメソッドが組み上げたクラスでも通る確率は0.985だが、兄弟メソッドを呼び出す場合は0.947まで落ちる（差0.038）。この結合ギャップは修復の呼び出しとして支払われる。SWE-benchでは参照パッチ500件中280件が単一ハンクで、そもそも積空間が候補空間に潰れてしまう。

4. エンドポイントが値段を決める

最後は評価指標の性質である。セルF1のような指標は全出力に精度の罰則を課すため、余分な単元を足すことは加点ではなく減点になる。この条件下でUnitBoostはオラクル候補選択に0.0650負けた。「次の単元の精度が指標の課金を上回る間だけ組み合わせる」という価格ルールは、組み合わせと選択のどちらが得かを40件中36件で正しく判断している（常に組み合わせるとした判断は24件）。

flowchart TB
    A["複数の識別可能な単元があるか"] -->|いいえ| Z["候補選択と同じ。導入不要"]
    A -->|はい| B["同じ意味の単元を機械的に判定できるか"]
    B -->|いいえ| Y["単元の分裂・誤統合が利得を消す"]
    B -->|はい| C["ワーカーは別々の証拠を読んでいるか"]
    C -->|いいえ| X["相補性なし。統合の余地が生まれない"]
    C -->|はい| D["エンドポイントは発見に加点するか"]
    D -->|いいえ| W["精度の罰則が上回る。選択のほうが強い"]
    D -->|はい| V["管理ステップの差し替えを検討"]

管理の方式はタスクの単元構造と評価指標から選ぶべきもので、既定で入れるものではない。逆に言えば、単元が複数あり、ワーカーが違う場所で失敗しているなら、管理ステップの差し替えを検討する価値は十分にある。

実装の勘所：導入するならここを見る

効く条件が確認できたら、次は実装である。管理ステップの差し替えは、ワーカー側の呼び出し設計よりも「何を単元と呼ぶか」の決定に集約される。判断が分かれる5点を整理する。

1. 単元写像 U はタスク構造から逆算する

単元（unit）とは、タスク定義上で機械的に識別できる最小の答えの単位である。単元写像 U はワーカー出力をスロット-値の提案 (s, v) に変換する関数で、実装では「値の正規化」と「スロットキーの決定」の2段になる。複数回答なら正規化した答え1つ、表形式ならエンティティ属性（ベンチマークが与えるキー）、コードならメソッドシグネチャが単位になる。逆に自由記述の言い換えを同一単元と見なす設計は、判定精度が上がらない限り利得を消すため避ける。

2. 実行可能性述語 C は明文化して検証する

述語 C は「その値の割り当てが実行可能か」を返す条件である。空スロットを常に選択肢に残し、制約を満たすものだけ採用するルールを条件式として書き下す。密な結合がある場合、積空間の列挙による厳密解も選択肢になるが列挙コストと引き換えになる。実測ではスコア順の参入と網羅列挙が95クラスすべてで一致しており、まずスコア順で試すのが現実的である。

3. 採用の証跡を残す

採用した各値について、供給元ワーカー・スコア・検査した制約のトレースを記録する。順序不変性と出所追跡はこの記録から得られる。

4. 停止は遅れを見込んで運用する

供給シグナル ρ_t は、ラウンド t で提案された値のうち新規スロットに落ちた割合である。しきい値 τ を下回ったら止める設計だが、このシグナルは非生産的なラウンドより1ラウンド遅れて反応する（実測では ρ_t がラウンド4で0.055に落ち、そのラウンドで0.0073を失った）。質問あたりの新規回答が5.32から2.34へ落ちた後に止めるといった形で、上限ラウンドと併用するのが安全である。

flowchart LR
    A["候補集合"] --> B["単元写像 U で (s, v) に分解"]
    B --> C["テーブルへ挿入・既存値と競合"]
    C --> D["制約付き argmax"]
    D --> E["残差 R_t を算出"]
    E --> F{"ρ_t ≤ τ ?"}
    F -->|いいえ| G["残差を次のワーカーへ"]
    G --> C
    F -->|はい| H["最終出力を確定"]

5. コストはワーカー側で増える

管理のマージ自体はモデル呼び出しをゼロ回で行える。ただし実装可能なスコアは値ごとに検索裏打ちの検証を1回必要とし、相補的なワーカーを増やせばその分だけ呼び出しが増える。10パッセージ窓を読む1ワーカーは1問あたり入力5,108トークン、1ワーカーが全パッセージを読むと18,879トークン、10ワーカーに分割すると51,128トークンになる。得られるのは固定ワーカーからの取り出し効率と後続ラウンドの配分であって、ワーカー単価の削減ではない。あわせて呼び出し上限、データとツールの制限、人間が介入できる停止手段、意思決定ログの保存を運用側に用意しておきたい。

この論文がもたらす意味：メタエージェント設計への問いの立て直し

UnitBoostの主張を精度改善の話として読むと、見落とすものがある。ここで更新されるのは数値ではなく、設計の問いの形だ。これまで複合LLMシステムの設計者は「管理者は生成モデルであるべきか」と問い、暗黙にイエスと答えてきた。メタエージェント・LLMを1つ置き、統合・配分・停止をまとめて委ねる。対応の幅は広いが、判断の理由は自然言語の根拠としてしか残らず、候補の順序を変えれば結果が変わり、どの部分がどのワーカーに由来するかを追えない。

提案される問い直しはこうだ。管理者のどの決定にまだモデルが必要か。 意味的な提案と修復――候補に無い単元を書き足す、壊れた組み合わせを直す――はモデルに残す。採用（候補と単元の中からの選択）、配分（残差という名前への割り当て）、停止（新規単元の供給が尽きたか）は明示的な手続きに移せる。実験はこの線引きを裏づける。制約なしのフロンティアモデルを管理者に据えると候補選択の水準は上回るが、その出力を候補の和集合に制限するとどの構成もUnitBoostを下回った。逆に無制約の出力を新しい提案として候補に加えれば0.5132に達する。生成には自由を与え、採用には制約を課すという役割分担がここから導かれる。

失うものは小さくない。無制約の生成的管理者が示した0.4918という水準は、候補に縛られない書き換え能力から来ている。採用を明示的に保つ設計は、その能力を「11番目の提案」として取り込む形でしか回収できない。

実務上の含意は明快である。Mixture-of-Agents、ディベート、批評→修正、逐次チェーンといった既存構成は、ワーカー・プロンプト・証拠・ラウンド・呼び出し回数を固定したまま管理ステップだけを差し替えられ、+0.0129〜+0.1820の改善が報告されている。ただし無条件ではない。単元が1つしかない、等価な単元を機械的に識別できない、エンドポイントが全出力に精度のコストを課す、のいずれかに当てはまるなら利得は出ない（セルF1ではオラクル候補選択に0.0650負ける）。管理の方式はタスクの単元構造と評価指標から選ぶべきもので、既定で入れるものではない。

関連研究の中での位置づけも、この問い直しの一部である。UnitBoostは辞書的な順位融合（メタサーチ）の系譜に、実行可能性の条件・採用値の出所・残差ラウンドを足したものと見なせる。CombSUMやCombMNZ、Borda、逆順位融合といった古典的手法は「どの候補を選ぶか」だけを扱い、単元ごとの値の組み合わせや次の呼び出し先を決めない。Mixture-of-Agentsやディベートは統合の質を経験的に上げてきたが、統合がどの単位で行われているかを明示しない。単元を管理の単位に持ち出すことで、これらは比較可能な設計空間の一点になる。

著者自身が認める限界も押さえておきたい。タスクが用意した単元、あるいは機械的に回復できる単元を必要とし、言い換えをまたぐ同一性の判定は未解決である。ラベル付き開発スコアは3つの検索条件と2つのワーカープールで転移するが、コーパスをまたぐ転移は未検証。スコアはワーカー単位の信頼度を持たず、残差の枯渇検知は1ラウンド遅れる。監査可能な管理であっても、スコアや実行可能性述語が不適切なら悪い判断を効率よく反復するだけになる。

管理役をモデルにするか演算子にするかは、万能の正解がある問いではない。だが「どの決定にモデルが必要か」という形に置き換えると、議論は実装可能な設計判断に落ちる。タスクが複数の識別可能な単元を持ち、ワーカーが違う場所で失敗しているなら、管理ステップの差し替えは検討に値する。そうでないなら、無理に入れないことが正解だ。

よくある質問

UnitBoostは、複数のLLM（ワーカー）が出した答えを、生成モデルではなく決定的なマージ演算子で統合する方式である。単元（unit）とはタスクが機械的に識別できる答えの部品（エンティティ名や表のセルなど）を指し、マージ演算子は「制約付きargmax」で単元ごとに最良の値を選び、埋まらなかった部分を残差として次の呼び出しに回す。ここでは導入を検討する際に迷いやすい6つの論点をまとめる。

生成的な管理者（メタエージェントLLM）を使うのと比べて、何が決定的に違うのか？

生成的な管理者は、統合・配分・停止という3つの制御決定を1回の不透明なモデル呼び出しに詰め込むため、説明が自然言語の言い訳になり、提案の順序にも反応する。UnitBoostはこの3つを、永続する単元テーブル上の制約付きargmax、名前付き残差、供給ベースの停止という明示的な手続きに分解し、固定された候補集合に対して順序不変性と採用元の追跡を得る。実際、利得の大半はスコアの作り込みではなく管理の作り方から生まれ、QAMPARIではラベルなしの逆順位融合だけでオラクル候補選択を+0.0655上回り、スコア改善分の寄与は+0.0063にとどまった。

UnitBoostはどんなときに「選択」より優れるのか？

タスクが複数の識別可能な単元を持ち、ワーカーがそれぞれ違う場所で不完全になっているときに効く。単元ごとの最大値の和は、どんな完全候補1つの合計以上になるため、欠落箇所がずれているほど利得が大きくなり、QAMPARIで+0.0718、ASQAで+0.0596、FanOutQAでは+0.1949の改善が報告されている。逆に許容される単元が1つだけなら両者は同一の結果になり、優位性は消える。

既存のMixture-of-Agentsやディベート構成に後から入れられるのか？

入れられる。ワーカー・プロンプト・証拠・ラウンド・呼び出し回数を固定し、管理ステップだけを差し替える6つの構成で、+0.0129〜+0.1820の改善が報告されている。内訳はMixture-of-AgentsがQAMPARIで+0.0457、ASQAで+0.0645、ディベートが+0.1235、批評→修正が+0.1522、逐次チェーンが+0.1820、役割分担が+0.0129である。ディベートでは最終ラウンドだけでなく各ラウンドの単元をすべて1つのテーブルに残すと、追加で+0.0467が得られた。

どんな場合に効果が出ない（あるいは逆効果になる）のか？

出力が単一の分割不能な単元しか持たない場合、等価な単元を機械的に識別できない場合、そしてエンドポイントが出力したすべての単元に精度のコストを課す場合である。特にFanOutQAのセルF1のような指標では、余分な単元を足すほど精度の罰則が課されるため、UnitBoostはオラクル候補選択に0.0650負ける。単元同一性の面でも、語彙ベースの関係検出は同一事実ペアの5.9%しか捉えられず、完全な参照同一性がある場合の+0.1413に対してほぼ改善が見られない。

停止の判断はどうやって行うのか？

ラウンドtの値が「まだ誰も埋めていないスロット」に落ちた割合 ρ_t を監視し、これがしきい値以下になったらループを止める。ただし供給シグナルは非生産的なラウンドの1つ後で反応するため、QAMPARIでは質問あたりの新規回答が5.32から2.34へ落ちた後、FanOutQAでは ρ_t=0.055まで下がったラウンド4で0.0073を失ってから枯渇が検出された。実務的には上限ラウンドを併用し、遅れを見込んで余裕を持って止める運用が現実的である。

マージ演算子を使えば計算コストは下がるのか？

マージそのものはモデル呼び出しを伴わない決定的な計算だが、コストはワーカー側で増える。実装可能なスコアは値ごとに検索裏打ちの検証を1回呼び、相補的なワーカーを増やせばその分だけ推論も走る。1ワーカーが10パッセージ窓を読む場合で1問あたり入力5,108トークン、全パッセージを一度に読ませると18,879トークン、10ワーカーに分割すると51,128トークンになるという会計が示されており、UnitBoostが得るのは固定ワーカーからの取り出し効率と後続ラウンドの配分であって、ワーカー単価の削減ではない。

まとめ

複合LLMシステム（複数のモデル呼び出しを組み合わせて1つの答えを出す仕組み）の「管理役」は、生成モデルである必要はない。統合（部分結果のまとめ）・配分（次の呼び出し先の割り当て）・停止（打ち切りの判断）という3つの決定は、永続する単元テーブル上の制約付きargmax、名前付き残差、供給ベースの停止条件として外に出せる。要点は3つだ。

1つ目は、単元ごとの制約付きargmaxが候補選択の天井を超えること。正解ラベルで最良の候補を1つ選ぶオラクル候補選択に対し、QAMPARIで+0.0718、ASQAで+0.0596、FanOutQAのセルF1で+0.1949の改善が報告されている。これは不等式から自動的に出るのではなく、「ワーカーが異なる場所で不完全になっている」という例外から生まれる。単元が1つしかないタスクでは両者は一致し、利得は消える。

2つ目は、残差が次の呼び出し先を名指しできること。未充填・実行不可能・採用値のない単元の集合を残差とし、呼び出しをその名前に配分するとFanOutQAのセルF1は0.5524に達し、無指定（0.5374）や再読（0.5106）を上回る。ただし枯渇シグナルは非生産的なラウンドの1ラウンド遅れで反応するため、上限ラウンドとの併用が現実的だ。

3つ目は、効く条件と効かない条件が演算子から演繹的に導けること。相補性が製造されていること、等価な単元を機械的に識別できること、そしてエンドポイントが全単元に精度のコストを課さないこと。セルF1のような指標ではUnitBoostはオラクル選択に0.0650負ける。

導入の判断は、この3点を自分のタスクで確認するところから始まる。複数の識別可能な単元を持ち、ワーカーが違う場所で失敗しているなら、ワーカー・プロンプト・証拠・ラウンド・呼び出し回数を固定したまま管理ステップだけを差し替える価値がある。Mixture-of-Agents、ディベート、批評→修正、逐次チェーンといった既存構成でも+0.0129〜+0.1820の改善が報告されている。逆に、単元が分割できない、等価な単元を識別できない、指標が全出力に課金する、のいずれかに当てはまるなら無理に入れない。

設計上の問いも更新される。「管理者は生成モデルであるべきか」ではなく、「管理のどの決定にまだモデルが必要か」。提案（意味的な生成と修復）はモデルに残し、採用・配分・停止は明示的な手続きに移すと、順序不変性・単元単位の出所追跡・検証可能な失敗条件が手に入る代わりに意味的な自由を手放す。どちらを取るかは、タスクの単元構造と評価指標が決める。

参考資料

• UnitBoost: Managing Compound LLM Systems with a Merge Operator, Not a Model — https://arxiv.org/abs/2609.09815
• UnitBoost（HTML版） — https://arxiv.org/html/2609.09815v1
• マルチエージェントLLMパイプラインにおける幻覚の雪崩現象：Hallucination Snowball論文解説 — https://gotosocial.chinng-lab-srv.dev/marutiezientollmpaipurainniokeruhuan-jue-noxue-beng-xian-xiang-hallucination-snowballlun-wen-jie-shuo/
• The Regression Tax: Decomposing Why Skills Help and Hurt LLM Agents — https://gotosocial.chinng-lab-srv.dev/the-regression-tax-decomposing-why-skills-help-and-hurt-llm-agents/

関連記事

• LLM評価は「測るたびに揺れる」——事前登録された5万件の監査が暴いた、LLMジャッジの計測としての脆さ
• 「ニュートラルな評価ハーネス」は存在しない——LLMリーダーボードは「設定にもろい設問」によって作られている