複数のAIモデルを1本のAPIで同時に走らせ、回答を比較・統合できる仕組みが、OpenRouterから公開されました。モデル選定やリサーチ用途で、単体モデルより高い精度を狙いたい開発者にとって、実装の選択肢が広がります。
この記事でわかること
- Fusion APIが何をする機能か
- パネル・判定・最終回答までの処理の流れ
- DRACOベンチマークで示された性能の目安
- APIの呼び出し方と料金の考え方
https://openrouter.ai/openrouter/fusion/api
Fusion APIとは
Fusion APIは、OpenRouterが2026年6月に発表した複合モデル向けのAPI機能です。1つのプロンプトを複数のAIモデルに並列送信し、それぞれの回答を別のモデルが比較・分析したうえで、最終的な1つの回答として返します。
OpenRouterは公式に「Fable並みの知能を半額で実現する」と説明しています。AnthropicのFable 5が輸出規制で利用できなくなった状況を受け、代替手段として注目されています。
なぜ複数モデルの並列実行が必要か
調査レポートや実務リサーチでは、1つのモデルだけでは見落としが出やすくなります。モデルごとに得意分野が異なるため、同じ質問でも回答の質や視点が変わります。
従来は、複数のAPIを個別に叩き、出力を目視で比較する必要がありました。Fusion APIは、この手作業をAPI側で自動化します。開発者はopenrouter/fusionというモデル名を指定するだけで、パネル実行から統合までを一括で依頼できます。
処理の流れ
Fusion APIの内部処理は、大きく3段階に分かれます。
まずパネルと呼ばれる複数のモデル(最大8つ)が、同じプロンプトに並列で回答します。各モデルにはWeb検索(openrouter:web_search)とWeb取得(openrouter:web_fetch)が有効化され、最新情報を参照しながら回答を生成します。
次に判定モデル(ジャッジ)が、パネル全員の回答を受け取り、単純にマージするのではなく構造化された分析を行います。分析結果はJSON形式で、合意点・矛盾点・部分的なカバレッジ・個別モデルの独自洞察・誰も触れなかった盲点の5項目に整理されます。
最後に、判定結果をもとに最終回答が書き出されます。OpenRouterの報告によると、性能向上の約75%はこの統合・分析ステップに由来し、残り約25%がモデル多様性によるものだとされています(参考)。
DRACOベンチマークの結果
OpenRouterは、Perplexityが公開する深層リサーチ向けベンチマーク「DRACO」でFusion APIを検証しました。DRACOは法律・医学・金融など10分野100タスクで構成され、各タスクは約39の重み付き基準で採点されます。誤答にはマイナス点が付き、冗長だが曖昧な回答は得点を水増ししません。
松丸彗吾氏の検証によると、DRACOでのスコアは次のとおりです(参考)。
- Fable 5単体:65.3%
- Opus 4.8 + GPT-5.5の組み合わせ:67.6%
報道では、Fable 5とGPT-5.5をFusionで組み合わせた構成が約69%に達し、Opus 4.8 + GPT-5.5 + Gemini 3.1 ProやOpus 4.8 + GPT-5.5の組み合わせを上回ったと報じられています(参考)。
低コスト構成でも、Gemini 3 Flash・Kimi K2.6・DeepSeek V4 Proの3モデルをFusionしたパネルは、単体のGPT-5.5やOpus 4.8を上回り、Fable 5のスコアとの差は1%以内に収まったとされています。このパネルのコストはFable 5の約半分です。
なお、Web検索付きの検証では一部モデルがDRACOの採点基準をオンラインで参照してしまう事象が起きたため、OpenRouterは該当ドメインを除外して再計測したと報じています。
APIの使い方
Fusion APIには3つの呼び出し方があります。いずれも同じパイプラインに接続されます。
最も手軽なのは、モデル名にopenrouter/fusionを指定する方法です。OpenAI互換のChat Completions APIにそのまま載せられ、既存のSDKでもベースURLを差し替えるだけで利用できます。
パネルの構成をカスタマイズする場合は、pluginsフィールドでfusionプラグインを指定します。analysis_modelsにパネルに参加させるモデル(1〜8個)、modelに判定モデルを設定します。デフォルトのQualityプリセットは、Claude Opus最新版・GPT最新版・Gemini Pro最新版の3モデルです。Budgetプリセットに切り替えると、より安価なモデルで構成できます。
判定を毎回強制したい場合は、tool_choice: "required"を付与します。通常はモデルが自律的にFusionの呼び出し要否を判断し、短い質問には直接回答します。
料金と向いている用途
Fusion APIの料金は、パネル全モデルと判定モデルの推論コストの合計です。デフォルトの3モデルパネルでは、通常の単体呼び出しの約4〜5倍のコストになると公式ドキュメントに記載されています。実際にどのモデルが走ったかは、OpenRouterのActivity画面で確認できます。
向いているのは、リサーチ品質が最優先で、1回あたりのコストより正確さが重要な場面です。市場調査、専門分野の比較分析、高リスクな意思決定の下調べなどが典型例です。大量の定型処理を毎秒数千件走らせる本番ワークフローには、コスト面で不向きです。
既存のルーティング機能との違い
OpenRouterには、Auto RouterやPareto Routerなど、プロンプトに応じて最適な1モデルへ振り分ける機能もあります。Fusion APIは「1モデルを選ぶ」のではなく「複数モデルの知見を統合する」点で異なります。モデル選定の悩みを1つに絞るのではなく、複数の視点を意図的に取り込む設計です。
Fable 5のような高性能モデルが使えなくなった今、Fusion APIは複数の利用可能なモデルを組み合わせて同等以上のリサーチ品質を狙う現実的な手段として位置づけられます。