OpenRouter Fusion Flash API：提供状況・セットアップ・400エラーの解決法

OpenRouter Fusion Flash APIを調べているなら、高速なFusionプリセットを使いたいか、HTTP 400エラーを解消したいケースが多いはずです。公式ドキュメントにはopenrouter/fusion-flashが掲載されていますが、ライブのモデル一覧に表示されないこともあります。組み込みを始める前に、まず自分のアカウントでこのエイリアスが利用できるか確認してください。

OpenRouter Fusion Flashは本当に利用できるのか

公式のFusion Routerドキュメントでは、openrouter/fusion-flashが独立したモデルスラッグとして記載されています。説明によると、このエイリアスではgeneral-fastプリセットがデフォルトで選択されます。より高速なエージェント型のやり取りを想定したプリセットで、レイテンシーのばらつきが少ないパネルが使われます。

同じ公式ガイドでは、標準のFusionについて、パネル内のモデルが並列に回答し、アナリストが一致点や相違点を比較し、外側のモデルが最終回答を生成する仕組みだと説明されています。Fusion Flashは、この複合ルーターでより高速なプリセットを選ぶものであり、単一プロバイダーのモデルではありません。

このガイドのために2026年9月11日に取得したライブのOpenRouterモデルカタログには、openrouter/fusionは含まれていましたが、独立したopenrouter/fusion-flashのレコードは確認できませんでした。Xでは、次のような同じ症状の報告もあります。

「ドキュメントにはopenrouter/fusion-flashが独立したモデルとして掲載され、/api/v1/modelsにも専用のエントリーがあると書かれている。しかし現在APIを呼び出すと、fusion-flashは有効なモデルIDではないという400エラーが返ってくる」— @PeterDaveHello

これはユーザーによる報告であり、OpenRouterが確認した情報ではありません。OpenRouterの公式ドキュメントがFusionを説明していることは確かですが、このガイドで確認できた公式発表の中に、Fusion Flashの独立した提供開始や撤回を裏付けるものはありませんでした。現時点での安全な結論は、ドキュメントには掲載されているが、組み込む前にライブ環境で利用可否を確認する必要がある、です。

コードを疑う前に確認しておきたいこと

アプリケーションが実際に使っているものと同じAPIキー、同じ環境でモデルカタログを取得します。

curl https://openrouter.ai/api/v1/models \
  -H "Authorization: Bearer $OPENROUTER_API_KEY"

JSON内を検索し、完全一致でopenrouter/fusion-flashを探してください。モデルページやSDKのオートコンプリート、キャッシュされた連携情報だけで利用可能だと判断するのは避けましょう。OpenRouterのモデルドキュメントでも、現在有効なモデル識別子と対応パラメーターを確認する情報源としてカタログが扱われています。

公式のステータスページも確認しておく価値はあります。ただし、プラットフォーム全体が正常でも、特定のルーターエイリアスが利用できるとは限りません。ステータスダッシュボードが示すのはChat APIやData APIといった大きなサービス単位であり、全体のChat APIが稼働している間も、エイリアス固有のカタログ不整合や設定ミスが起こる可能性があります。

OpenRouter Fusion Flash APIを最小構成でセットアップする

最初は、できるだけ小さなChat Completionsリクエストから始めます。SDKのアダプター、ツールスキーマ、ストリーミング、Fusionのカスタム設定を最初のテストから外すことで、問題の範囲を絞れます。

export OPENROUTER_API_KEY="your-key"

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion-flash",
    "messages": [
      {
        "role": "user",
        "content": "Reply with the word: ready"
      }
    ],
    "stream": false
  }'

このコードで示しているのはエンドポイントとヘッダーです。最初のテストではstream: falseを維持し、エラー本文全体を確認しやすくしておきます。

/api/v1/modelsにエイリアスが表示され、このリクエストが成功したら、アプリケーション固有のフィールドを1つずつ追加します。エイリアスが一覧にない場合は、プロンプトを変えたり同じリクエストを繰り返したりしても解決しません。診断として、ドキュメントに記載された同等の構成を試してください。

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/fusion",
    "plugins": [
      {"id": "fusion", "preset": "general-fast"}
    ],
    "messages": [
      {"role": "user", "content": "Reply with the word: ready"}
    ],
    "stream": false
  }'

このフォールバックで確認できるのは、Fusionルートと高速プリセットに到達できるかどうかです。エイリアスと明示的な設定が、バックエンドのすべての細部まで同一であることを検証するものではありません。

OpenRouter Fusion Flash APIの400エラーを切り分ける手順

400エラーは通常、リクエストまたはプロバイダー側で拒否されたことを示します。正確な原因はレスポンス本文によって異なります。500の障害や、外側のリクエストはHTTP 200で返ったもののFusion内部の処理が失敗したケースとは別物です。以下の順に確認すれば、各テストで何が分かったのかを整理できます。

1. エラー本文を最後まで読む

400 Bad Requestだけをログに残すのではなく、レスポンス全体を保存してください。

curl -i https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"openrouter/fusion-flash","messages":[{"role":"user","content":"ready"}]}'

エラーコード、メッセージ、プロバイダー名、リクエストIDまたは生成ID、メタデータを確認します。<「fusion-flash is not a valid model ID」という内容なら、モデルの検出結果と提供状況の不一致が疑われます。「Provider returned error」なら、プロバイダーの経路までは到達したものの、そこでリクエストを拒否された可能性があります。詳細のない400が返る場合は、推測で修正を重ねるのではなく、OpenRouterのActivityレコードを確認しましょう。

2. モデルIDが完全に一致しているか確認する

モデル識別子は大文字・小文字も含めた文字列です。リクエストの値を、ライブの/api/v1/modelsレスポンスと比較し、記号やスラッシュまで確認してください。アプリケーション設定に残っている古いエイリアスを削除し、推測でGeminiなど別のFlashモデル名に置き換えるのも避けます。

切り分けには、次のような対応表が役立ちます。

テスト	結果	次に行うこと
`openrouter/fusion-flash`が`/api/v1/models`にない	400または無効なモデルエラー	`general-fast`を指定した標準Fusionを使うか、エイリアスが表示されるまで待つ。ドキュメントをライブの検出結果として扱わない。
エイリアスはあるが、最小構成のリクエストが失敗する	アプリケーションの複雑さに関係なく400	エラー本文全体とActivityのメタデータを確認する。アカウント、ルーター、提供開始状況の問題かもしれない。
最小構成は成功するが、ツールを追加すると失敗する	ツール追加後に400	ツールスキーマを検証し、ツールを1つだけ、またはツールなしでテストする。
最小構成は成功するが、ストリーミングで失敗する	非ストリーミングは成功	クライアントのストリーミングアダプターとFusionの互換性を分けて検証する。
特定のカスタムパネルモデルだけ失敗する	別のパネル構成は動作する	そのモデルを削除または置き換え、プロバイダー固有のメタデータを確認する。
HTTP 200の中にFusion内部の失敗が含まれる	外側の通信は成功	パネルまたはアナリスト内部の失敗として扱い、トップレベルの400と混同しない。

3. 対応していないフィールドを取り除く

model、messages、stream: false、必須ヘッダー2つだけを送信します。そのうえで、次の順番でフィールドを戻していきます。

temperatureまたは推論関連の設定。
pluginsとFusionプリセット。
カスタムのanalysis_modelsまたはアナリストのmodel。
toolsとtool_choice。
ストリーミングと、フレームワーク固有のレスポンスオプション。

OpenRouterのFusionガイドでは、analysis_models、model、preset、max_tool_calls、max_completion_tokens、reasoning、temperatureが説明されています。ただし、あるエンドポイントやモデルファミリーで記載されているフィールドが、すべての上流モデルでそのまま使えるとは限りません。確認にはOpenRouter Modelsリファレンスと、対象モデルの対応パラメーター情報を使ってください。

4. ツールとメッセージ履歴を簡素化する

ツール対応クライアントでは、最終的なペイロードに不正なJSON Schema、未対応のツールパラメーター、不完全なassistant/toolメッセージの並びが含まれ、原因の分かりにくい400につながることがあります。公開されているHermes Agentの報告では、複数のテストモデルでツールを有効にした0.10.0におけるOpenRouterの400失敗が記録されています。報告ではデフォルトの28個のツールが原因ではないかと推測されていますが、ツールを無効にした場合の成功テストも、確定した根本原因も示されていません。issue #13927は再現調査の手がかりとして読み、すべてのFusion Flash 400がツール起因だと決めつけないでください。

切り分けでは、次の3つをすべて試します。

toolsを削除し、同じプロンプトを送る。
単純なオブジェクトスキーマを持つ最小限のツールを1つだけ送る。
過去のツール呼び出しやツール結果を含まない、新しい会話で始める。

テキストだけの最小リクエストと、削減したツール構成の両方が成功するなら、ツールを1つずつ戻します。長いツール利用履歴で失敗し、新規リクエストなら成功する場合は、モデル自体を疑う前に履歴を短縮または要約してください。

5. エイリアス、ルーター、プロバイダーの問題を分ける

Fusionでは、パネルモデル、アナリストモデル、外側のレスポンス生成モデルが関わることがあります。そのため、内部の1回の呼び出しが失敗しても、通常の単一モデルのエラーとは違う形で現れる場合があります。OpenRouterのドキュメントでは、実際に何が実行されたかを確認するため、生成情報とActivityデータを調べるよう案内しています。通常のレスポンスにあるmodelフィールドから外側で使われた具体的なモデルを特定できることはありますが、それだけでFusionが使われた、あるいは使われていないと断定することはできません。

Fusionが成功した場合、ドキュメントに記載されている生成メタデータには次の情報が含まれます。

{
  "router": "openrouter/fusion"
}

カスタムのanalysis_modelsを指定しているなら、いったん削除してプリセットを再テストします。プリセットでは成功するのに、特定のカスタムモデルで失敗する場合は、そのモデルのパラメーター、プロバイダーの提供状況、コンテキスト上限に関係している可能性が高いでしょう。SDK経由でだけ失敗するなら、動作するcURLのペイロードとSDKが実際に送信したペイロードを比較します。OpenAI互換クライアントは、アプリケーションのコードからは見えにくい形で、ツール、ストリーミングフラグ、レスポンス形式、メッセージ変換などを追加することがあります。

リトライをやめるべきタイミング

無効なモデルIDや、毎回同じ結果になるスキーマ拒否を自動リトライで解決しようとしてはいけません。リトライ不可と判断された400には、明確なフォールバックを用意します。

モデル一覧にエイリアスがない：general-fastを指定したopenrouter/fusionへ切り替えるか、カタログを監視しながら既知の通常モデルを使う。
ペイロード固有の400：最小リクエストを回帰テストとして残し、追加したフィールドのうち最初に失敗を引き起こしたものを修正する。
プロバイダー固有の400：問題のパネルモデルを外すか、設定済みのフォールバックを使い、プロバイダーのレスポンスを記録する。
Chat API全体の障害：OpenRouterのステータスページを確認し、アプリケーションのロジックを変更するのではなく展開をいったん止める。
内部失敗を含むHTTP 200：パネルの失敗をログに残し、部分的な結果を許容するか判断する。認証失敗として分類しない。

公式のFusion Routerドキュメントによると、デフォルトの3モデル構成では、単一の補完処理と比べて料金はおおよそ4～5倍になります。正確な請求額は内部で実行された呼び出しによって変わります。エイリアスの状態が不確かな間は、フォールバックによって信頼性だけでなくコストも管理できます。

OpenRouter Fusion Flash APIに関するFAQ

OpenRouter Fusion Flashの正しいモデルIDは何ですか？

公式ドキュメントに記載されているのはopenrouter/fusion-flashです。ただし、ドキュメントとライブのモデル一覧が一時的に食い違うことがあるため、デプロイ前にGET /api/v1/modelsで完全一致を確認してください。

Fusion Flashは一般的な高速モデルですか？

いいえ。ドキュメント上は、general-fastプリセットを使うFusionです。内部で複数のモデル呼び出しが発生することもあるため、「Flash」は単一呼び出しで動くことではなく、プリセットが目指すレイテンシーを表しています。

どのエンドポイントを使えばよいですか？

Bearer認証とJSONボディを使い、https://openrouter.ai/api/v1/chat/completionsを呼び出します。Fusion専用のURLパスを推測して作らないでください。

Fusionの実行を強制できますか？

Fusionのドキュメントではtool_choice: "required"がサポートされています。Fusionだけを利用可能なツールにしていれば、実質的にツール呼び出しを強制できます。ただし他のツールも指定している場合、requiredが意味するのは「何らかのツールを呼び出す」ことであり、必ずFusionが選ばれるわけではありません。

OpenRouterのステータスページが正常なのに、Fusion Flashが400を返すのはなぜですか？

ステータスページが示すのは、広い範囲のサービスコンポーネントです。エイリアスの欠落、無効なルーター設定、プロバイダー固有の拒否は、Chat API全体が稼働している間でも特定のルートだけに影響することがあります。

Fusion Flashは無料ですか？

無料だと決めつけないでください。OpenRouterのFusionモデルページでは、ルーターのエイリアスに個別のトークン価格が表示されない場合でも、内部のパネルとアナリストによる補完処理が請求額に影響すると説明されています。本番利用の前に、Activityと選択したモデルの料金を確認してください。

高速プリセットを使うのは、ライブのモデル検出結果と最小構成のリクエストが一致した場合だけにしましょう。それ以外では標準Fusionまたは既知のモデルへフォールバックし、失敗したペイロードを保存して、闇雲なリトライは避けてください。