OpenRouter、複数AIの議論と分析を統合する複合推論システム「Fusion」を発表
要点
- OpenRouterは2026年9月10日、複数の言語モデルによる並行回答とジャッジモデルの比較分析を1つに統合する複合推論システム「Fusion」の技術詳細を公開した。
- 1つのプロンプトに対して1〜8種類のモデルが独立して回答を作成し、ジャッジモデルが合意点や矛盾、独自の洞察を整理した上で最終回答を出力する。
- デフォルトの3モデル構成では単一モデル実行時に比べてトークン費用が約4〜5倍、所要時間が約2〜3倍となるが、回答精度の向上を図る。
- Perplexity AIの深層調査ベンチマーク「DRACO」において、低価格帯モデルの組み合わせによる構成が最上位モデル単体のスコアに迫る結果を示した。
- 通常業務は単一モデルで処理し、誤答時の損失が大きい調査や分析タスクに絞ってFusionを呼び出す「選択的エスカレーション」の運用が推奨されている。
AIモデルのAPIルーティングプラットフォームを提供するOpenRouterは2026年9月10日、複数のAIモデルによる議論プロセスを1回のリクエスト内で完結させる複合推論システム「OpenRouter Fusion」の仕組みと利用指針を発表した。
同システムは、ユーザーから受け取った単一のプロンプトを複数のモデルへ同時に送信し、それぞれの回答を専門のジャッジモデルが比較・構造化分析した上で、最終的な回答を合成して返す仕組みとなっている。開発者が自前で複数モデルの連携機構（オーケストレーション）を構築・維持することなく、単一のモデル指定やサーバーツール経由でマルチモデル推論を実行できる点に特徴がある。
4段階で進行する推論パイプライン
OpenRouterの説明によると、Fusionの処理は以下の4つのステージで実行される。
- 呼び出し元モデルによるプロンプト評価: リクエストを受け取ったモデルが、通常の回答を直接返すか、より深い分析のためにFusionツールを呼び出すかを判断する。
- パネルモデルによる並行処理: 1〜8個の参加モデル（パネリスト）が独立してプロンプトに対する回答を作成する。各モデルはOpenRouterのWeb検索およびWebページ取得ツールを利用して最新情報を参照できる。
- ジャッジモデルによる比較分析: ドキュメント上で「アナリスト」とも呼ばれるジャッジモデルが各パネリストの回答を精査する。単純な多数決による判定ではなく、各回答の合意点、矛盾点、部分的な網羅性、独自の洞察、全体の盲点などを洗い出し、構造化された分析データを生成する。
- 最終回答の生成: 呼び出し元のモデルがジャッジの分析結果を受け取り、統合された最終的な回答を作成して利用者のアプリケーションへ返却する。
ジャッジの役割について同社は、複数モデルが同じ誤った主張を繰り返した場合でもそれを正解とみなさず、1つのモデルだけが提示した有益な指摘や全モデルが見落とした論点を抽出する点にあるとしている。
多様性と複数回実行による品質向上
Fusionによる回答精度の向上は、異なるモデル間の多様性に加え、同一モデルを複数回実行することによる推論パスの差異からも得られるという。
同社が実施した検証では、Claude Opus 4.8を2回並行実行し、同一モデルで統合処理を行った構成において、Perplexity AIが策定した深層調査ベンチマーク「DRACO」で65.5%のスコアを記録した。これは単体のClaude Opus 4.8によるスコア（58.8%）を6.7ポイント上回る結果であり、モデルの多様性がない同一モデル同士の組み合わせでも、比較と統合のプロセス自体が回答精度の向上に寄与することが示されたとしている。
また、Gemini 3 Flash、Kimi K2.6、DeepSeek V4 Proといった比較的低コストなモデルを組み合わせたFusion構成では、同ベンチマークで約64.7%のスコアを記録した。これは単体モデルであるClaude Fable 5のスコア（コンテンツフィルターの影響で100タスク中93タスクを測定した結果で約65.3%）に近い水準に達していると説明している。
コストとレイテンシのトレードオフ
Fusionは複数モデルの実行とジャッジ処理を挟むため、計算リソースの消費量が増加する。
標準的な3モデル構成のパネルでは、同じプロンプトを単一モデルで処理する場合と比較して、トークン費用が約4〜5倍に増加する。また、各パネリストの処理は並行して行われるものの、最も応答が遅いモデルの完了を待機した後にジャッジ処理を行うため、全体の応答時間（レイテンシ）は2〜3倍程度長くなるという。この遅延のため、リアルタイムなチャット応答やコードの自動補完といった用途には適さないとしている。
一方でコスト面について同社は、1回のリクエスト単価だけでなく「正しい回答を得るためのタスク全体の総コスト」で評価すべきだと説明している。低価格な単一モデルで誤答が発生し、再試行や人間の確認作業が発生するケースと比較した場合、Fusionで1回で正解を得られる方が全体の作業コストを低く抑えられる場面があるとしている。
また、設計上、実行ごとに異なる推論経路や検索結果をたどる非決定性（再現性の低さ）を持つため、回帰テストや日々の出力を比較する評価スイートなどの再現性が重視されるシステムには不向きである点も挙げられている。
推奨されるユースケースと運用方法
OpenRouterは、本番環境における最も効果的な運用パターンとして「選択的エスカレーション」を挙げている。日常的な定常リクエストは単一モデルに直接処理させ、誤答による手戻りや損失が大きい高度な調査タスクに限定してFusionを呼び出す設計が有効であるという。
具体的な適応例としては、戦略判断の前に多数の最新ソースを横断してまとめる競合調査、専門的な査読や批判的検討、複数選択肢の比較分析、デューデリジェンスの要約など、正確性の確保が最優先される場面を挙げている。