OpenRouter Fusion APIとは何なのか
前回の記事では、OpenRouterとは何かをまとめました。今回はそこで触れなかった、最近話題のFusion APIについて書きます。
Fusionとは何者か
ひとことで言うと、ひとつのプロンプトを複数のモデルに同時に投げて、その答えを1つに統合して返す仕組みです。2026年6月にOpenRouterがリリースしました。
なお、前回書いた通常の「ルーティング」とは別物です。ルーティングが「1つのモデルを選んで投げる」のに対して、Fusionは「複数のモデルに考えさせて、合成する」。
仕組み
パイプラインはおおまかに3段階です。
プロンプトをモデルのパネル(複数モデル)に並列で投げる。
ジャッジモデルが全部の回答を受け取り、「合意点・矛盾・部分的にしか触れられていない点・独自の洞察・誰も触れなかった盲点」を構造化して抽出します。ここでジャッジは回答をマージするのではなく、比較するのがポイントです。
その分析をもとに、最終的な回答を1つ書き上げます。
おもしろいのは、効果の源泉の内訳です。OpenRouter自身の検証によれば、Fusionがもたらす品質向上のおよそ4分の3は「統合(synthesis)」から、残り4分の1が「モデルの多様性(diversity)」から来ているとされています。同じモデルを自分自身とfusionさせるだけでもスコアが上がった、という報告もあり、複数の答えを突き合わせて練り直すプロセス自体に効果がある、ということのようです。
呼び出しは簡単で、model: "openrouter/fusion"と指定するだけ。OpenAI互換APIの1行を差し替えれば動きます。パネルやジャッジを自分で指定したい場合は、サーバーツールとして使うと細かく制御できます。
コストと性能
課金は積み上げ式です。4つのモデルに通せば4回分、プラスでジャッジの分を払う。だから、Quality(高品質)プリセットは単一のトップモデルを1回呼ぶより、ざっくり3倍ほど高くつきます。一方でBudget(廉価)プリセットは、安いモデルを組み合わせることで、トップモデル1回よりむしろ安くなる構成もあります。
性能の方は、Perplexityの研究系ベンチマーク(DRACO)で、Qualityパネルが単体のトップモデルを数ポイント上回ったと報告されています。Budgetパネルもトップモデルに1%以内まで肉薄しました。
ただし注意も要ります。このベンチマークは英語・テキストのみの研究タスクで、コーディングは含まれていません。コードの正しさは「動くか動かないか」のバイナリなので、複数モデルの答えを混ぜると、かえって実行できない混成物になりやすい。ここはFusionが苦手とする領域だと思います。また、長期にわたる作業(long-horizon)では優位が出なかった、ともされています。
いつ使い、いつ使わないか
個人的には、Fusionは「常用するもの」ではないと感じました。
向いているのは、リサーチ・比較分析・専門的な批評など、間違えたときのコストが、数回分の追加課金より大きい場面です。複数の専門家に意見を聞いて突き合わせる、という人間のやり方をそのまま自動化したい局面ですね。
逆に、リアルタイム性が要るアプリ、単純なクエリ、コーディング、そして大量に回すルーティン処理には向きません。レイテンシも当然、複数モデル+ジャッジの分だけ伸びます。
なお、Fusionの中身であるマルチモデル合成という発想自体は新しいものではなく、2024年から「Mixture of Agents(MoA)」として研究されてきたものです。Fusionはそれを、インフラを自前で組まずに1行で使えるよう製品化した、という位置づけになります。
まとめ
Fusionは「複数モデルに熟議させて1つの答えに練り上げる」仕組みで、常用するとコストもレイテンシも膨らみます。ここぞ、という場面の切り札として持っておくのがよさそうです。
