OpenRouter Fusionとは｜複数モデルの審議で単体モデルを超える仕組み

OpenRouter は、さまざまな提供元の大規模言語モデル（LLM: Large Language Model）を、1 つの API でまとめて使えるようにするモデル基盤です。2026 年に発表された OpenRouter Fusion は、その上に乗る新機能で、1 つのプロンプトを複数モデルに同時に投げ、ジャッジ（judge）が回答を整理してから最終回答にまとめます（OpenRouter Blog: Surpassing Frontier Performance with Fusion）。

01.結論：OpenRouterとFusionの位置づけ

OpenRouter は「どのモデルを使うか」をアプリ側のコードから切り離す基盤です。Fusion はその発展形で、「1 つのモデルに任せる」のではなく「複数モデルにチームとして答えさせる」発想です。OpenRouter は X（旧 Twitter）への投稿で、この考え方を「モデル版の neurodiversity（多様な認知特性）」と表現し、1 人の天才に全部任せるのではなく、異なる強みを持つメンバーを集めてチームとして答えを作る、と説明しています（OpenRouter Blog）。

重要なのは、最強モデルが不要になるという話ではない点です。最前線のモデル（frontier model）は今後も必要です。ただし、1 つのモデルだけに依存する設計は、そのモデルが止まったり制限されたりしたときに弱くなります。Fusion が示すのは、複数モデルを束ねて品質と耐障害性の両方を上げる、という別の設計です。

02.OpenRouterとは：複数モデルを1つのAPIで束ねる基盤

OpenRouter は、Anthropic・OpenAI・Google など複数の提供元のモデルを、OpenAI 互換の 1 つの API でまとめて呼び出せるようにするサービスです。アプリ側は API キーを 1 つ持つだけで、モデルを切り替えたり、ある提供元が落ちたときに別の提供元へ回したりできます（OpenRouter）。基盤としての全体像（料金やビジネスモデルを含む）は、別記事で詳しく扱っています。

この「モデルを 1 つの窓口に集約する」性質が、Fusion の前提になります。複数モデルへ並列に投げ、別のモデルに審査させるには、そもそも複数モデルを同じ API から呼べる土台が要るからです。OpenRouter はその土台の上に、複数モデルを協調させる仕組みを Fusion として載せました。

03.OpenRouter Fusionとは：プロンプトを複数モデルの審議に変える

Fusion の流れは、利用者から見れば「1 つのプロンプトを送って、1 つの回答が返る」だけです。中では、パネルへの並列投入とジャッジによる整理が走っています。OpenRouter のブログによると、流れは次のようになります。

ここで大事なのは、Fusion が単なる多数決ではない点です。ジャッジは各回答を分解し、重なっている部分、食い違っている部分、片方だけが拾った論点、誰も触れていない盲点を整理したうえで統合します。OpenRouter は、ジャッジが返す分析を JSON として構造化しており、合意点（consensus）・矛盾（contradictions）・部分的な抜け（partial coverage）・個別モデルだけの独自洞察（unique insights）・盲点（blind spots）に分けて返すと説明しています（OpenRouter Docs: Fusion Server Tool）。

この設計が効くのは、最終回答だけでなく「なぜその回答になったか」の材料も得られるからです。単体モデルだと、整った文章の裏にある抜け漏れが見えにくい。Fusion だと、複数モデルの食い違いがそのまま判断材料として表に出てきます。リサーチや意思決定のように、間違いのコストが高い場面ほど、この差は大きくなります。

04.DRACOベンチマークが示したこと

OpenRouter の主張は「複数モデルを呼べます」だけではありません。深いリサーチ系のタスクで、パネルが単体モデルを継続的に上回り、高性能モデル同士を組ませると単体の最前線モデルを超え、安価なモデルのパネルでも単体の最前線モデルを超えて Fable 5 にかなり近づいた、と数字で示しています（OpenRouter Blog）。

DRACOとは何か

OpenRouter のブログによると、評価に使った DRACO は、Perplexity が公開した深いリサーチ系ベンチマークで、100 の複雑な調査タスクから構成されます。対象は、学術研究・金融・法律・医療・テクノロジー・UX デザイン・一般知識・needle-in-a-haystack 型（大量の情報から針 1 本を探すような検索）・パーソナルアシスタンス・商品比較の 10 分野です。単なる暗記テストではなく、複雑な問いに対して調査し、情報を比較し、複数ソースを統合して、正確かつ読みやすく答えられるかを見るテストです（OpenRouter Blog）。

各タスクは約 39 個の重み付き基準で採点され、評価カテゴリは事実正確性・深さと広さ・提示品質・引用品質に分かれます。さらに、誤答にはマイナス評価が入るため、長く書いてごまかしても高得点は取れない作りになっています。OpenRouter は、これが Fusion の狙う「調査・比較・専門的な判断・抜け漏れが致命傷になるタスク」と相性がよいと説明しています（OpenRouter Blog）。

スコア：Fusionが単体モデルを上回った

公式ブログで示された主なスコアを並べると、Fusion 構成が上位に並びます。

この中で目を引くのは 2 点です。1 つは、Fable 5 と GPT-5.5 の Fusion が、Fable 5 単体を超えていること。もう 1 つは、Gemini 3 Flash・Kimi K2.6・DeepSeek V4 Pro という安価なモデルの Budget パネルが、GPT-5.5 単体や Opus 4.8 単体を上回り、Fable 5 単体にかなり近づいていることです。OpenRouter は、安価なモデルの Budget パネルが上位モデル単体を超え、Fable 5 に迫った点を強調しています。安価なモデルの組み合わせが単体の上位モデルを超えるという結果は、コスト設計に直接効いてきます。

Fable 5比較の注意点

とはいえ、Fable 5 が完了できた範囲で非常に強かったことも事実です。だからこそ、その Fable 5 に Fusion が近づく、あるいは超えるという結果に意味があります。数字を読むときは、この前提を踏まえておくと誤解が減ります。比較対象になった Claude Fable 5 そのものについては、次の記事で扱っています。

self-fusionと「統合」の効果

Fusion の強さは、違うモデルを混ぜたことだけが理由ではありません。OpenRouter は、Opus 4.8 を 2 回走らせ、Opus 4.8 自身で統合する self-fusion も試しています。結果は 65.5% で、Opus 4.8 単体の 58.8% から 6.7 ポイント上がりました（OpenRouter Blog）。

同じモデルでも、同じ問いを複数回処理すると、推論経路・ツール呼び出し・ソース選択・着眼点が変わります。それを後段で統合すると、単体の 1 回答より強くなります。OpenRouter は、Fusion による改善の大部分は「統合」そのものから来ており、一部が「モデルの多様性」から来ている、という趣旨も説明しています。Fusion は単なるモデルの寄せ集めではなく、複数回答を構造化して統合するプロセス自体に価値がある、という整理です。

ベンチマーク汚染への対処

OpenRouter は、ベンチマークの汚染（contamination）対策まで公開しています。パネルのモデルに Web 検索を与えたところ、モデルが DRACO の採点ルーブリック（採点基準）をオンラインで見つけてしまうことがありました。これは意図的な不正ではなく、検索語によって偶然見つかったものだと説明されています。

ただ、評価としては汚染リスクになります。そこで OpenRouter は、採点結果がホストされている場所を Web 検索と Web 取得から除外したうえで、ベンチマークを再実行したと説明しています。Fusion は Web 検索を使えるから強い一方で、Web 検索を使えるからこそ、評価時にはカンニングを防ぐ設計も要ります。公開されている数値は、この除外後に取り直したものです。

パネルの各モデルが Web 検索で外部情報を取り込むこの仕組みは、AI エージェントが外部の情報やツールにつながる流れの一つです。その基礎は、次の記事で整理しています。

05.Fusionの使い方：3つの入口

OpenRouter のドキュメントによると、Fusion には大きく 3 つの入口があります。どれも裏側では同じ Fusion パイプラインに入り、違いは「どこまで制御したいか」です（OpenRouter Docs: Fusion Server Tool）。

一番シンプルなのは、モデルスラッグとして呼ぶ方法です。通常の OpenAI 互換 API と同じく、model に openrouter/fusion を指定すれば使えます。

{
  "model": "openrouter/fusion",
  "messages": [
    { "role": "user", "content": "調査したいテーマを書く" }
  ]
}

OpenAI 互換 SDK でも、model に openrouter/fusion を指定するだけです。

const completion = await client.chat.completions.create({
  model: "openrouter/fusion",
  messages: [
    {
      role: "user",
      content:
        "Compare the strongest arguments for and against using Fusion in coding agents.",
    },
  ],
});

もう 1 つは、Server Tool として使う方法です。tools 配列に {"type": "openrouter:fusion"} を入れると、外側のモデルが「このタスクは複数視点が必要だ」と判断したときに Fusion を呼び出せます。すべてのタスクを Fusion に投げるのではなく、リサーチや比較で間違いのコストが高い場面、レビューや反証が要る場面だけ Fusion に切り替える運用ができます。なお Fusion Server Tool は beta の位置づけで、API や挙動は変わる可能性があると明記されています。毎回 Fusion を必須化したい場合は、tool_choice で強制する方法もドキュメントにあります。

06.パネルとジャッジのカスタムと失敗時の設計

Fusion は固定構成ではありません。OpenRouter の Fusion モデルページでは、既定は Quality preset とされており、安価にしたいときは Budget へ切り替えられます。さらに、analysis_models で参加モデル（パネル）を指定し、model でジャッジを指定できます。Server Tool のドキュメントでは、analysis_models は 1 から 8 モデルまで指定できるとされています（OpenRouter Docs: Fusion plugin）。

{
  "tools": [
    {
      "type": "openrouter:fusion",
      "parameters": {
        "analysis_models": [
          "~anthropic/claude-opus-latest",
          "~openai/gpt-latest",
          "~google/gemini-pro-latest"
        ],
        "model": "~openai/gpt-latest",
        "max_tool_calls": 8
      }
    }
  ]
}

• analysis_models：並列に走らせるパネル側のモデルです。各モデルは Web 検索・取得を使いながら回答します。
• model：それらの回答を読んで構造化するジャッジモデルです。
• max_tool_calls：パネルやジャッジが Web 検索・取得を何ステップまで使えるかの上限です。

ほかに max_completion_tokens・reasoning・temperature も指定できます。OpenRouter のドキュメントでは、既定の Quality preset として Claude Opus 系・OpenAI GPT 系・Gemini Pro 系の組み合わせが説明されています。Fusion は「モデル名を 1 つ入れれば終わり」でも使えますが、本当に使いこなすなら analysis_models とジャッジの model を設計する必要があります。

失敗時の設計も実務向きです。Fusion は複数モデルを使うため、どれかが落ちる可能性があります。OpenRouter のドキュメントによると、一部のパネルモデルがエラーになっても、少なくとも 1 つが成功すれば結果を返します。ジャッジが失敗した場合も、パネルの回答だけは返り、外側のモデルがそこから回答できます。完全に失敗するのは、すべてのパネルモデルが失敗した場合などに限られます。複数モデル化は品質向上だけでなく、耐障害性の設計にも関わるという整理です。

07.コストの考え方

OpenRouter の Fusion モデルページでは、価格についても明確に説明されています。Fusion は、パネルメンバー全員の呼び出しとジャッジ呼び出しの合計で課金されます。つまり、単体モデル 1 回分の価格で複数モデルが走るわけではありません（OpenRouter: Fusion モデルページ）。

安価な Budget パネルが上位モデル単体を上回り、Fable 5 に近いスコアを出したことは、コスト設計に直接効きます。コストとレイテンシ（応答までの遅延）はパネルとジャッジのぶん増えますが、間違いのコストが高いタスクなら、Quality と Budget をタスクごとに切り替えて見合う場面を選べます。

08.OpenCodeとの連携

OpenRouter は、オープンソースの AI コーディングエージェント OpenCode との連携ドキュメントも公開しています。OpenCode は、ターミナル UI とデスクトップアプリで使え、LSP（Language Server Protocol）連携・複数セッション・共有可能なセッションリンクを持ち、多数の LLM プロバイダーに対応します。その中に OpenRouter も含まれます（OpenRouter Docs: Integration with OpenCode／opencode.ai）。

連携手順はシンプルで、OpenRouter で API キーを作り、OpenCode で /connect を実行して OpenRouter を選び、API キーを貼り、/models でモデルを選びます。設定ファイル opencode.json に OpenRouter プロバイダーを書いて、使いたいモデルを追加する方法もあります。

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "openrouter": {
      "models": {
        "openrouter/fusion": {
          "name": "OpenRouter Fusion"
        }
      }
    }
  }
}

OpenRouter が OpenCode 連携のメリットとして挙げているのは、モデル数だけではありません。あるプロバイダーが使えない、または利用上限に当たったときに別プロバイダーへ回せること、チームで予算や利用状況を管理しやすいこと、API キーの再設定なしでモデルを切り替えられることです。あわせて、明示的にオプトイン（opt in）しない限りソースコードのプロンプトはログしないとも説明されています。コーディングエージェントで使うなら、この点は確認しておきたいところです。

09.よくある質問（FAQ）

10.まとめ

OpenRouter は多数のモデルを 1 つの API で束ねる基盤で、OpenRouter Fusion はその上で、1 つのプロンプトを複数モデルの審議に変える仕組みです。パネルが並列に答え、ジャッジが合意・矛盾・盲点を構造化してから最終回答にまとめます。DRACO ベンチマークでは、高性能モデルの組み合わせが単体を超え、安価な Budget パネルでも単体の上位モデルを上回って Fable 5 に迫りました。改善の大部分は「統合」そのものから来ており、self-fusion でも単体を上回ります。使い方は openrouter/fusion のモデル指定が最短で、Server Tool や plugin でパネルとジャッジを設計できます。コストはパネルとジャッジの合計で増えるため、間違いのコストが高い場面を見極めて使うのが出発点になります。仕様は beta を含み変わりうるので、最新は公式ドキュメントで確認してください。