OpenRouter Fusion API登場｜複数モデルを合議させてFable級の精度を半額で出す新ルーター

この記事ではLLMに特化して解説します。LLM全般の仕組みは LLMとは？仕組みからローカル実行まで徹底解説【2026年完全ガイド】 をご覧ください。

30秒で理解するOpenRouter Fusion API

OpenRouterが2026年6月13日、Fusion API を発表した。要点だけ先に押さえる。

OpenRouterは、OpenAI・Anthropic・Google・Mistral・Meta など主要プロバイダの数百モデルを単一のOpenAI互換APIで束ねるLLMゲートウェイだ。これまでは「どのモデルにルーティングするか」を最適化する存在だったが、Fusionで初めて「複数モデルを同時に走らせて統合する」レイヤーへ踏み込んだ。

本記事は何の発表か — Fusion APIの位置づけ

まず、今回の発表が「新モデルのリリース」ではない点を明確にしておく。Fusionは新しい基盤モデルではなく、既存モデル群をオーケストレーションする上位レイヤーだ。OpenRouter公式アカウントの告知はこうだ。

Introducing the Fusion API, the smartest compound model in the market. Fusion achieves Fable-level intelligence at half the price. How it works 👇

（訳：市場で最も賢い複合モデル「Fusion API」を発表します。FusionはFable級の知性を半額で実現します。仕組みは以下のとおり👇）

— OpenRouter公式 @OpenRouter（2026年6月13日）

このツイートは公開から短時間で4,700以上のいいね、68万回超の表示を集めた。背景には、前日2026年6月12日に公開された技術ブログ「Surpassing Frontier Performance with Fusion（Fusionでフロンティア性能を超える）」がある。そこで示されたのは、安価なモデルを束ねた合議体が、フロンティアの単体モデルを上回りうるという実測結果だった。

「compound model（複合モデル）」という言い方がポイントだ。単体のLLMではなく、複数モデル＋判定ロジックを1つのAPIとしてパッケージし、利用者からは1モデルのように見える。後述するように、これは学術的に Mixture-of-Agents（MoA） や LLM-as-a-judge と呼ばれてきた手法を、設定不要のプロダクトに落とし込んだものだ。

なお、Fusionは Qwen 3.6 PlusがOpenRouterで1日1.4兆トークンを処理した過去最大級の事例 のような「単体モデルの巨大トラフィック」とは方向性が逆で、1リクエストあたりの計算量を増やして質を上げる発想に立っている。

Fusionの仕組み — panelとjudgeの2段構成

Fusionの動作は、panel（パネル＝回答者の合議体） と judge（判定者） の2段に分かれる。流れを図にする。

各段階を分解する。

ここで効いているのは「judgeが矛盾を可視化する」点だ。単体モデルは自信満々に間違える（ハルシネーション）が、3つのモデルのうち1つだけが言っている主張は judge が「contradiction」「unique insight（要検証）」として隔離できる。逆に全モデルが一致した部分は高信頼として残る。多数決ではなく、合意と相違を構造化して人間／後段に渡すのがFusionの本質だ。

ベンチマーク — 安価パネルがFable 5に1%差まで迫る

OpenRouterは DRACO という深層リサーチ評価ベンチで100タスクを測定した。DRACOは学術研究・金融・法律・医療などのドメインで、factual accuracy（事実正確性）/ breadth & depth（広さと深さ）/ presentation quality（提示品質）/ citation quality（引用品質） を採点する。結果を表にまとめる。

この表から読み取るべき発見は3つある。

3つ目の「自己融合」の結果は特に示唆的だ。複数の異なるモデルを集める「アンサンブルの多様性」だけでなく、いったん複数回答を出して judge で突き合わせる手続き自体が、単発生成より良い答えを生む。Chain-of-Thoughtやself-consistencyの延長線上にある発見と言える。

ただし注意点も明記しておく。DRACOは深層リサーチに特化したベンチで、短文応答・コード生成・対話などでは融合の優位がそのまま再現するとは限らない。引用品質や事実正確性が重視されるタスクで効果が大きい、という文脈で読むのが正しい。

開発者向け — Fusionの呼び方とパラメータ

最も簡単な使い方は、model を openrouter/fusion にするだけだ。OpenAI互換なので既存コードの差し替えで動く。

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion",
    "messages": [
      {"role": "user", "content": "炭素税への賛成・反対の最も強い論拠を調査して整理して"}
    ]
  }'

TypeScript SDKならこう書ける。

import { OpenRouter } from '@openrouter/sdk';

const openRouter = new OpenRouter({ apiKey: process.env.OPENROUTER_API_KEY });

const completion = await openRouter.chat.send({
  model: 'openrouter/fusion',
  messages: [
    { role: 'user', content: 'Survey strongest arguments for and against a carbon tax.' },
  ],
});

パネル構成やjudgeを明示制御したい場合は、通常のモデル呼び出しに tools としてFusionを渡し、parameters で細かく指定する。

{
  "model": "~anthropic/claude-opus-latest",
  "messages": [{ "role": "user", "content": "..." }],
  "tools": [{
    "type": "openrouter:fusion",
    "parameters": {
      "analysis_models": [
        "google/gemini-3-flash",
        "moonshot/kimi-k2.6",
        "deepseek/deepseek-v4-pro"
      ],
      "max_tool_calls": 8
    }
  }],
  "tool_choice": "required"
}

主なパラメータを整理する。

再帰についても設計済みだ。judgeやパネルの内側からFusionが再度発火しないよう、x-openrouter-fusion-depth ヘッダーで深度を制限し、合議は1階層のみに抑えている。APIを使わずに試すなら、チャットUI（openrouter.ai/fusion）でプリセットを選ぶか独自パネルを組んで動かせる。

料金 — 「半額」と「4〜5倍」の二面性を正しく読む

Fusionの料金は、どのパネルを選ぶかで印象が真逆になる。ここを誤解すると見積もりを外す。

仕組み上、Fusionは「パネルN回＋judge1回」の補完を消費する。公式ドキュメントは、デフォルトの3モデルパネルで 単一補完のおよそ4〜5倍、パネル数に対してほぼ線形にスケールすると説明している。つまり高精度プリセット（Opus / GPT / Gemini Pro）は素直に割高だ。

一方で公式ツイートの「Fable級を半額」は、安価モデルの予算パネルを指している。Gemini 3 Flash・Kimi K2.6・DeepSeek V4 Proという廉価モデル3枚を束ねると、合計コストがFable 5単体の約半分に収まりながら、精度はFable 5に1%差まで迫る。

判断基準はシンプルだ。間違いのコストが、追加の補完コストを上回るか。深層リサーチ、専門批評、法務・医療・金融のような高stakeな調査では、数回分の補完料を払ってでも合議で精度を取りに行く価値がある。逆に、短い定型応答やチャットの相づちにFusionを使うのは過剰だ。

競合との比較 — ルーターとオーケストレーターは別物

「複数モデルを扱うレイヤー」は他にもあるが、Fusionの1リクエスト内で合議する性質は質的に異なる。代表的な選択肢と並べる。

整理すると、世の中の多くは「1リクエスト＝1モデル」のゲートウェイ／ルーターで、賢く振り分けはしても同時に走らせて統合はしない。Fusionはここで一線を画す。

学術的には、複数LLMの回答を別のLLMで統合する Mixture-of-Agents（MoA）、回答を採点・選別させる LLM-as-a-judge が以前から提案されてきた。Fusionの新規性は手法そのものではなく、それを 設定不要・1つのモデル名で呼べるマネージドAPI に落とし込み、web search統合とコスト最適化（予算パネル）まで含めて製品化した点にある。自前でMoAパイプラインを組む手間と、パネル設計・judge設計・再帰制御の難所を、APIの裏側に隠した。

OpenRouter全体での位置づけ — ゲートウェイから合議レイヤーへ

Fusionを正しく理解するには、OpenRouterというプロダクトの進化線に置いてみるとよい。OpenRouterはもともと、数百のモデルを単一のOpenAI互換エンドポイント（/api/v1/chat/completions）で束ねるゲートウェイとして始まった。利用者はAPIキー1本とクレジット課金で、AnthropicのClaudeもGoogleのGeminiもMetaのLlamaも同じインターフェースから呼べる。プロバイダ障害時の自動フォールバック、最安プロバイダへのルーティング、利用量に応じた従量課金——これらが従来の価値だった。

つまりOpenRouterは長らく「配送（routing）の最適化」を担うレイヤーだった。どのモデルに、どのプロバイダ経由で、いくらで送るか。そこに賢さはあっても、生成そのものは常に単体モデルの仕事だった。

Fusionはこの境界を初めて越える。ルーティングの先で複数モデルを同時に動かし、judgeで束ね、1つの回答に統合する。OpenRouterのスタックを階層で描くとこうなる。

重要なのは、Fusionが既存のルーティング層の上に乗っていることだ。パネルの各モデルは引き続きOpenRouterの通常ルーティングで最安・最速のプロバイダへ配送される。その上にFusionが「合議」という新しい抽象を追加した格好だ。だからこそ、利用者はopenrouter/fusionという1つの名前を呼ぶだけで、裏側の数モデル×複数プロバイダの並列実行を意識せずに済む。

この位置づけは、OpenRouterが「モデルの卸売り」から「モデルを組み合わせて売る付加価値レイヤー」へ事業の軸足を広げ始めた兆候とも読める。単体モデルの価格競争が激化するなかで、ゲートウェイ事業者が差別化を図る自然な方向だ。Fable級を半額で出すという訴求は、まさに「合議によって安価モデルの価値を引き上げる」というOpenRouterの新しいポジショニングを象徴している。

実務での使いどころ — judgeの構造化分析を活かす

Fusionの真価は、最終回答テキストだけでなく judgeが返す構造化分析（合意/矛盾/穴/洞察/盲点）を後段で使うところにある。Pythonで呼ぶ最小例を示す。OpenAI互換なのでopenaiクライアントがそのまま使える。

from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

resp = client.chat.completions.create(
    model="openrouter/fusion",
    messages=[
        {"role": "user",
         "content": "2026年の主要オープンウェイトLLMのライセンス差を調査して整理して"},
    ],
)
print(resp.choices[0].message.content)

運用上のコツを挙げる。

開発者・利用者への影響 — 「最強の1モデル」競争の終わり方

Fusionが示すのは、モデル選定の発想転換だ。これまでLLM活用の定石は「ベンチマーク最上位の単体モデルを選ぶ」だった。だがDRACOの結果は、安価モデルの合議がフロンティア単体を超えうることを実測で見せた。これは現場に3つの変化をもたらす。

一方で見落としてはいけない制約もある。Fusionはレイテンシとコストを質と交換する仕組みだ。パネルが並列とはいえ最遅モデルに律速され、judge合成の分だけ遅延も積む。リアルタイム性が要るUXには不向きで、バッチのリサーチ・分析・レポート生成に最適化されている。「速い・安い・賢い」を全部取る魔法ではなく、賢さを買うために速度とコストを差し出すトレードオフだと理解して使うのが正しい。

総じて、Fusionは「どのモデルが最強か」という問いを「どのモデルをどう合議させるか」という設計問題に置き換えた。2026年のLLM活用は、単体性能のチャンピオン探しから、複数モデルのオーケストレーション設計へと重心を移しつつある。その流れを、設定不要のAPIとして誰でも触れる形にしたのがFusionの意義だ。

まとめ

OpenRouter Fusion APIは、複数モデルを並列実行しjudgeで合議させる複合モデルだ。DRACOベンチでFable 5＋GPT-5.5の融合が69.0%と単体を上回り、安価な予算パネルはFable 5に1%差・半額で迫った。openrouter/fusion を呼ぶだけで使え、料金はパネル次第で「半額」にも「4〜5倍」にもなる。深層リサーチや高stakeな批評には強く、リアルタイム用途には不向き——この見極めが導入の鍵になる。

参照ソース

・OpenRouter公式X（@OpenRouter）「Introducing the Fusion API」 — https://x.com/OpenRouter/status/2065856853989270011
・OpenRouter Blog「Surpassing Frontier Performance with Fusion」 — https://openrouter.ai/blog/announcements/fusion-beats-frontier/
・OpenRouter Docs「Fusion Router」 — https://openrouter.ai/docs/guides/routing/routers/fusion-router
・OpenRouter Docs「Quickstart / Models」 — https://openrouter.ai/docs