LLM API のフォールバックルーティングは、すべてのリクエストがテキストを返すのであれば単純です。プライマリルートがタイムアウトした場合は、1回再試行し、バックアップモデルに切り替え、スキーマを検証し、理由を記録します。
しかし同じ製品が画像生成、音声文字起こし、音声出力、動画生成もルーティングする場合、そのロジックは破綻します。JSON 抽出には安全なバックアップでも、ブランド用ビジュアルに対して自動的に安全とは限りません。音声認識のフォールバックは、音声合成のフォールバックと同じではありません。動画のフォールバックは、重複コスト、キューの混乱、または人間の承認がまだ必要な出力を生み出す可能性があります。
このガイドでは、LLM APIのフォールバックルーティング：テキスト、画像、音声、動画のためのマルチモーダルエージェントルーティング を、AI 製品チーム向けの実装プレイブックに落とし込みます。目的は、万能の単一モデルを選ぶことではありません。目的は、エージェントが扱う各モダリティごとに、ルート選択、検証、フォールバック、コストレビューを明示的にすることです。
2026年9月12日時点で、Flatkey の公開ページでは、1つのキー、1つの残高、1つの請求書、100以上の公式 AI モデル、1,000以上のツール、OpenAI 互換のセットアップ、利用ログ、自動フェイルオーバーを製品の中心に据えています。Flatkey の公開モデルおよび価格ページでは、テキスト、画像、音声、動画向けのモデルルートも公開されています。モデルの利用可否、価格、ルートの健全性は変わりうるため、導入前の現時点の商用チェックポイントとして、これらの公開ページを扱ってください。
簡単な答え：マルチモーダルのフォールバックルーティングでは何が変わるのか？
テキストのみのシステムでは、フォールバックは通常1つの問いを立てます。「別のルートで同等の回答を生成できるか？」
マルチモーダルシステムでは、LLM API のフォールバックルーティングは4つの問いを立てる必要があります。
- 何が生成されるアーティファクトか？ テキスト、画像、音声、動画は、同じ品質基準を共有しません。
- そのアーティファクトはどのように検証されるか？ JSON パーサー、視覚レビュー担当者、文字起こしチェッカー、動画承認キューは、それぞれ異なる検証システムです。
- 実際に回復可能な失敗は何か？ レート制限、タイムアウト、不正な入力、安全性による拒否、品質の低い出力には、それぞれ異なる対応が必要です。
- バックアップは契約を維持できるか？ フォールバックルートが安全なのは、モダリティ、出力形状、レイテンシ予算、コスト上限、レビュー経路を維持できる場合だけです。
実践上のルールはシンプルです。人間またはポリシー層が明示的に移行を承認しない限り、フォールバックはワークフローのクラス内にとどめる。
テキスト、画像、音声、動画で一般的な再試行が失敗する理由
一般的な再試行は、失敗したリクエストをすべて転送の問題として扱います。それではマルチモーダルなエージェントルーティングには浅すぎます。
| モダリティ | 一般的な失敗の形 | なぜ汎用的なリトライが危険なのか |
|---|---|---|
| テキスト | タイムアウト、レート制限、パーサーの失敗、ツール呼び出しの不一致、弱い応答 | リトライ自体は安全かもしれませんが、モデルを切り替えるとスキーマ、引用、ツール、トーンが壊れる可能性があります。 |
| 画像 | 安全性ブロック、アスペクト比の誤り、ブランド不一致、低忠実度、不十分な編集追従 | 別の画像モデルは有効なファイルを返しても、クリエイティブレビューには不合格のままかもしれません。 |
| 音声 | 未対応形式、品質の低い文字起こし、言語の誤り、音声の不一致、レイテンシーの急増 | 文字起こし、翻訳、音声出力は別々のジョブであり、それぞれに別のフォールバックルールがあります。 |
| 動画 | 長いキュー、タスク失敗、期限切れのアセット、不整合なモーション、コストの高い却下済み出力 | むやみに再送信すると、重複ジョブ、重複コスト、さらにレビュー対象のアセットが増える可能性があります。 |
ルーターは、失敗がリトライ可能なサービスイベントなのか、無効なリクエストなのか、安全性やポリシーの結果なのか、あるいは品質不足なのかを把握する必要があります。これらのカテゴリごとに異なるアクションが導かれます。
モデル名ではなく、ルートクラスから始める
LLM APIの最も安全なフォールバックルーティングは、ルートクラスから始めます。モデルは可用性や品質の変化に応じてクラスの内外を移動できますが、ワークフローポリシーは安定しているべきです。
| ルートクラス | 主なジョブ | 検証クラス | デフォルトのフォールバック動作 |
|---|---|---|---|
| テキスト推論 | 抽出、分類、要約、コーディング、構造化出力、ツール呼び出し | スキーマチェック、パーサーテスト、ルーブリックサンプリング、ツールの成功 | バックアップが応答形式とツールの動作を維持する場合は、自動フォールバックを許可できます。 |
| ビジョン理解 | 画像分析、文書レビュー、スクリーンショット解釈 | テキスト出力チェックと視覚入力のカバレッジ | 画像生成ルートではなく、別のビジョン対応推論ルートへフォールバックします。 |
| 画像生成または編集 | 新規画像、編集、製品バリエーション、クリエイティブ下書き | 視覚QA、ブランドチェック、プロンプトテンプレートレビュー | 一致するアスペクト、スタイル、レビュー規則を備えた承認済みの画像ルートへのみフォールバックします。 |
| 音声入力 | 文字起こし、翻訳、会議要約、通話QA | 文字起こし精度チェック、言語チェック、タイムスタンプレビュー | 同じ入力制限を持つ別の文字起こしまたは音声理解ルートへフォールバックします。 |
| 音声出力 | 音声合成、音声エージェント応答、ナレーション | 再生QA、音声ポリシー、レイテンシー予算 | 承認済みの音声ルートへフォールバックします。文字起こしのフォールバックとは切り分けてください。 |
| 動画生成 | テキストから動画、画像から動画、プレビュークリップ、クリエイティブアセット | 人手による承認、長さ/忠実度チェック、キュー監視 | フォールバックは狭く保ちます。多くの場合、別ジョブを自動作成するより、手動レビューで失敗させます。 |
このルートクラスのマップは、よくある誤りを防ぎます。それは、"マルチモーダルモデル"を1つの能力の入れ物として扱ってしまうことです。解析のために画像を受け取れるモデルが、必ずしも画像を生成できるとは限りません。音声を理解できるモデルが、自動的に本番用の音声モデルになるわけではありません。デモで動画を生成できるモデルが、顧客向け自動化に安全であるとは限りません。
コードを書く前にフォールバックの意思決定マトリックスを使う
意思決定マトリックスは、プロダクト、エンジニアリング、運用に共通のポリシーを与えます。以下のマトリックスから始めて、例を自社のモデル、プロバイダー、承認ルールに置き換えてください。
| 条件 | テキストのアクション | 画像のアクション | 音声のアクション | 動画のアクション |
|---|---|---|---|---|
| 出力開始前にプライマリルートがタイムアウトした | 予算内で再試行し、その後は承認済みのテキストルートにフォールバックする | アセットが作成されていなければ1回再試行し、その後は承認済みの画像ルートにフォールバックする | 同じ音声ジョブ種別内で再試行またはフォールバックする | まずタスク状態を確認する。元の状態が分かるまでは重複ジョブを作成しない。 |
| レート制限または容量エラー | バックアップがスキーマとコスト制限を満たす場合にフォールバックする | バックアップがプロンプト、サイズ、レビュー制限を満たす場合にフォールバックする | バックアップが同じファイル形式と言語をサポートしている場合にフォールバックする | 重複コストとキュー動作が許容できる場合にのみフォールバックする。 |
| 無効なリクエストまたは未対応の入力 | 停止してリクエストを修正する | 停止してプロンプト、入力タイプ、サイズ、またはアスペクト比を修正する | 停止してメディア形式、長さ、言語、またはサンプルレートを修正する | 停止して長さ、参照メディア、プロンプト、またはエンドポイントのフィールドを修正する。 |
| 安全性またはポリシーによる拒否 | フォールバックで拒否を隠してはならない | 別のモデルでポリシーを回避してはならない | 別の音声プロバイダーでポリシーを回避してはならない | 別の動画プロバイダーでポリシーを回避してはならない。 |
| 出力が自動検証に失敗した | 契約が機械検証可能ならフォールバックする | 視覚レビューに回すか、承認済みルートポリシーの下で再生成する | 文字起こし/再生レビューに回すか、同じジョブ種別内でフォールバックする | 人間のレビューに回す。盲目的なフェイルオーバーではなく、再生成ルールを使う。 |
| 部分的なストリーミング出力がすでにユーザーに届いている | 通常は停止して整合性を取る。モデルの透過的な切り替えは避ける | ほとんどの画像ルートでは該当しない | 停止してユーザー可視の状態を整合させる | 可視のジョブ状態が存在するようになってから、見えない形で切り替えてはならない。 |
| ツール呼び出しに副作用が発生した可能性がある | 再試行またはフォールバックの前に冪等性を整合させる | アセット/ストレージへの書き込みをすべて整合させる | 文字起こし、通話、または音声セッションの状態を整合させる | まずタスクID、ストレージ、課金、承認状態を整合させる。 |
このマトリックスは、この記事の主要な価値です。LLM APIのフォールバックルーティングを、エンジニアリングの後回し事項から、本番トラフィックが動く前にレビュー可能なポリシーへと変えます。
マルチモーダルエージェントルーティングの参照アーキテクチャ
本番用ルーターは複雑である必要はありませんが、明確な境界は必要です。
flowchart LR
A[エージェントのリクエスト] --> B[ワークフローを分類]
B --> C[プライマリルートを選択]
C --> D[プロバイダーまたはゲートウェイを呼び出す]
D --> E[アーティファクトを検証]
E -->|pass| F[返却してログに記録]
E -->|retryable failure| G[フォールバックポリシー]
E -->|policy or invalid input| H[実行可能なエラーで停止]
G --> I[承認済みバックアップルート]
I --> D
G --> J[人によるレビューまたは手動キュー]
主な要素は次のとおりです:
- ワークフロークラス分類器: ルート選択の前に、ジョブをテキスト、ビジョン、画像生成、音声入力、音声出力、または動画生成としてラベル付けします。
- 機能レジストリ: どのルートが各モダリティ、エンドポイント、入力形式、出力形状、最大コンテキスト、ストリーミング動作、コストクラスをサポートするかを記録します。
- フォールバックポリシー: 再試行可能なエラー、許可されたバックアップ、バイパス防止ルール、および最大試行回数を定義します。
- 検証レイヤー: ユーザーに返す前、または下流へ送る前にアーティファクトをチェックします。
- 台帳と可観測性: モデル、ルート、オーナー、ステータス、フォールバック理由、レイテンシー、使用量、コスト、レビュー結果を記録します。
Flatkey は、チームが 1 つの OpenAI 互換ルーター、1 つの共有残高、そしてサポートされるモデルルートをレビューする 1 か所を求める場合に、プロバイダーまたはゲートウェイ層に配置できます。アプリケーションは引き続きポリシーを所有します。つまり、どのモダリティクラスにフォールバックを許可するか、いつ停止するか、いつ人が判断すべきかです。
ポリシーをデータとして定義する
ルーティングポリシーを散在する if 文の中に置かないでください。小さなデータオブジェクトのほうがレビューしやすく、変更も安全です。
{
"workflow": "support_ticket_with_screenshot",
"route_class": "vision_understanding",
"primary_model": "primary-vision-reasoning-route",
"fallback_models": ["backup-vision-reasoning-route"],
"fallback_on": ["timeout_before_output", "rate_limit", "upstream_5xx"],
"do_not_fallback_on": ["safety_rejection", "invalid_input", "partial_stream_sent"],
"verification": {
"type": "structured_text",
"required_fields": ["summary", "severity", "evidence"]
},
"max_attempts": 2,
"max_incremental_cost_usd": 0.05,
"log_fields": [
"request_id",
"workspace_id",
"route_class",
"model",
"fallback_reason",
"latency_ms",
"cost_usd",
"verification_status"
]
}
同じ構造でメディアワークフローも表現できます:
{
"workflow": "product_video_preview",
"route_class": "video_generation",
"primary_model": "primary-video-route",
"fallback_models": ["approved-video-preview-route"],
"fallback_on": ["provider_5xx", "capacity_unavailable"],
"do_not_fallback_on": ["client_timeout_without_task_state", "safety_rejection", "asset_created"],
"verification": {
"type": "human_review",
"checks": ["duration", "motion", "brand_safety", "reference_consistency"]
},
"max_attempts": 1,
"manual_queue_after_failure": true
}
この違いに注意してください。テキストポリシーは、結果が機械で検証可能なため、しばしば自動的にフォールバックできます。ビデオポリシーはより限定的です。というのも、2回目の生成は単なる再試行ではなく、別の成果物であり、別のコスト発生イベントだからです。
モダリティ別のフォールバックルール
テキスト: 応答契約を維持する
テキストは、検証を自動化できるため、最も始めやすい分野です。LLM APIのフォールバックルーティングでは、テキストのバックアップは以下を維持すべきです。
- エンドポイントの形状;
- 使用している場合はストリーミングイベントの形状;
- JSONまたは構造化出力の挙動;
- ツール呼び出しの挙動;
- 引用または検索取得の要件;
- レイテンシ上限;
- コスト上限。
よくある間違いは、予測可能な構造化出力ルートから、見栄えはよいが下流のパースを壊す、より創造的なモデルへフォールバックしてしまうことです。このルートが製品自動化を支えるのであれば、文章のスタイルよりもパーサの安定性のほうが重要です。
ビジョン: 画像理解と画像生成を分ける
ビジョン系のジョブは、画像についてのテキストを生成することが多いです。画像生成ジョブは、新しい視覚的成果物を生成します。これらは同じフォールバックバケットを共有すべきではありません。
OpenAI、Google Gemini、Anthropic はいずれも画像理解または画像関連のAPI機能を文書化していますが、それらのドキュメントは異なるリクエスト面とモデル挙動を説明しています。マルチモーダルエージェントルーティングにおけるポリシー上の問いは、単に「このルートは画像を扱えるか？」ではありません。むしろ「このルートは、同じ入力制約と出力契約で、この画像ジョブを扱えるか？」です。
たとえば、スクリーンショットのトリアージワークフローでは、構造化テキストを返すビジョン対応の推論ルートが必要になるかもしれません。ブランド向けクリエイティブワークフローでは、ファイルを返し、ビジュアルレビューに合格する画像生成ルートが必要です。これらは別々のルートクラスです。
画像生成: クリエイティブレビューを迂回しない
画像のフォールバックは、クリエイティブ契約を保護すべきです。
- アスペクト比;
- 解像度またはサイズクラス;
- 編集か新規生成か;
- プロンプトテンプレートとの互換性;
- ブランドおよびコンプライアンスレビュー;
- 保存とアセットのライフサイクル;
- 承認済みアセットあたりのコスト。
主要な画像ルートが入力不正で失敗した場合、フォールバックは適切ではありません。リクエストを修正してください。生成前にプロバイダが一時的に利用不能で失敗した場合は、バックアップルートがすでにビジュアルQAを通過していれば、フォールバックが妥当な場合があります。
音声: 文字起こし、理解、音声合成を分ける
音声ルーティングは、しばしば3つの異なるジョブを内包しています。
- 音声認識: 音声を文字起こしに変換します。
- 音声理解: 音声コンテンツ、話者の意図、または会議の文脈について推論します。
- 音声合成: 音声出力を生成します。
これらのジョブには、それぞれ異なる失敗モードがあります。文字起こしルートは、単語誤り率、ドメイン語彙、話者ラベル、タイムスタンプ、レイテンシーによって評価できます。音声ルートは、音質、発音、レイテンシー、許可された音声ポリシー、再生体験によって評価されます。
フォールバックは、特定の音声ジョブタイプの内部にとどめるべきです。"audio-capable" を単一のポリシーラベルとして使わないでください。
動画: フォールバックを別の本番イベントとして扱う
動画は通常、自動フォールバックにおいて最もリスクの高いモダリティです。失敗した、または遅いリクエストによって、すでにプロバイダー側のタスクが作成されている可能性があるためです。別のタスクを作成する前に、システムは次を把握している必要があります:
- 元のタスクが存在するか;
- それがキュー中、処理中、成功、失敗、または期限切れのいずれか;
- 出力 URL が作成されたか;
- 使用量またはコストが記録されたか;
- レビュー担当者がそのアセットを確認済みか;
- 2回目の生成が予算や承認フローに違反しないか。
動画生成では、安全なデフォルトは次のとおりです。タスクが存在しない場合にのみトランスポートをリトライし、既存タスクを終端状態までポーリングし、その後に手動または厳密に承認された再生成パスを使用します。
フォールバックが発生したときにログに記録するもの
ログに見えないフォールバックは、改善が不可能になります。少なくとも、すべてのリクエストは次を記録する必要があります:
| フィールド | 重要な理由 |
|---|---|
request_id |
ユーザーから見える挙動を、プロバイダーおよびゲートウェイの証跡に結びつけます。 |
route_class |
ジョブがテキスト、ビジョン、画像、音声、または動画のどれだったかを示します。 |
primary_model and final_model |
どのルートが応答したか、またはアーティファクトを生成したかを明らかにします。 |
fallback_reason |
タイムアウト、レート制限、上流エラー、検証失敗、または手動オーバーライドを区別します。 |
attempt_count |
無制限のリトライループを防ぎます。 |
latency_ms |
フォールバックがユーザー体験を改善したのか悪化させたのかを示します。 |
usage and cost |
バックアップルートの経済性を可視化します。 |
verification_status |
フォールバックを、API の成功だけでなく出力品質に結びつけます。 |
reviewer_outcome |
画像、音声、動画の受け入れ追跡に必要です。 |
AI プロダクトチームにとって、最も有用な指標は、しばしば生の稼働率ではありません。フォールバック後の受け入れ済み出力率 です。迅速に応答するが、却下されるアセットを返すバックアップルートは、プロダクト上は信頼できません。
Flatkey の位置づけ
Flatkey が LLM API のフォールバックルーティングに関連するのは、運用上の痛みが 1 回の API 呼び出しよりも大きいからです。マルチモーダル製品では、プロバイダー固有のキー、直接請求アカウント、散在するモデル ID、一貫性のないエラー処理、そしてテキスト、画像、音声、動画の実験用の個別ダッシュボードが蓄積されがちです。
Flatkey の公開ドキュメントとサイトでは、対応モデル呼び出し向けに、OpenAI互換の単一ルーターURL、モデルカタログ、使用ログ、1つの残高、1つの請求面をチームに提供しています。ライブサイトでも、信頼性は自動フェイルオーバーと公開ステータス/SLAの面を中心に打ち出されています。とはいえ、独自のモダリティポリシーが不要になるわけではありません。ポリシーを機能コード全体に分散させるのではなく、1か所で運用できるようにするだけです。
次のような場合は Flatkey を使用します。
- 対応モデルルートを比較しながら、1つのルーターエンドポイントを使いたい場合;
- モデルの可用性と商用コンテキストを確認する場所を1つにしたい場合;
- 分散したプロバイダーアカウントではなく、1つの残高と1つの請求書にしたい場合;
- モデル、トークン、コスト、レイテンシ、オーナー確認のための使用ログが必要な場合;
- より多くのエージェントやワークフローが AI API を採用する中で、ルートガバナンスを整えたい場合。
1つのプロバイダーだけで要件を満たし、ワークロードにフォールバックが不要で、クロスモデル制御よりも最もシンプルなベンダー経路が重要な場合は、プロバイダーの直接アカウントを使用します。
LLM API のフォールバックルーティングの展開チェックリスト
マルチモーダル製品で自動フォールバックを有効にする前に、次のチェックリストを完了してください。
- モダリティを棚卸しする。 テキストを生成する、画像を解析する、画像を生成する、音声を受け付ける、音声で話す、または動画を生成するすべてのワークフローを一覧化します。
- ルートクラスを割り当てる。 1つの「マルチモーダル」というラベルで異なるアーティファクト型をまとめないでください。
- 検証を定義する。 フォールバックを信頼できるようにする前に、すべてのルートクラスに合否判定方法が必要です。
- リトライとフォールバックを分ける。 リトライは同じルートを繰り返します。フォールバックはルートを変更します。再生成は新しいアーティファクトを作成します。
- バイパス防止ルールを書く。 安全性による拒否、無効な入力、副作用、目に見える部分出力は、黙ってフォールバックすべきではありません。
- コスト上限を設定する。 リクエストは救えても予算を破るフォールバックなら、製品としては失敗です。
- ルート決定をログに残す。 プライマリルート、最終ルート、失敗理由、コスト、レイテンシ、検証結果を保存します。
- 障害注入をテストする。 タイムアウト、レート制限、5xx エラー、無効な入力、パーサー失敗、拒否された画像、悪いトランスクリプト、遅い動画ジョブをシミュレートします。
- 低リスクのワークフロー1つから始める。 製品全体で一気にモダリティ横断フォールバックを有効にしないでください。
- 受理済み出力率を毎週レビューする。 単なる HTTP 成功応答ではなく、実用的な結果を最適化します。
これが、LLM API の信頼できるフォールバックルーティングと、互換性のないルート間での盲目的なリトライとの違いです。
よくある質問
LLM API のフォールバックルーティングとは何ですか？
LLM API のフォールバックルーティングとは、失敗、劣化、または利用不能なモデルルートに対して、再試行するか、承認済みのバックアップに切り替えるか、実行可能なエラーで停止するか、あるいは人間によるレビューに回すかを決めるポリシーです。
なぜマルチモーダルエージェントルーティングはテキストのみのルーティングより難しいのですか？
マルチモーダルエージェントルーティングが難しいのは、テキスト、画像、音声、動画の出力それぞれで、検証方法、コスト曲線、レイテンシの期待値、レビューリスクが異なるためです。1つの一般的なフォールバックルールで、これら4つすべてを安全にカバーすることはできません。
1つの API ゲートウェイでテキスト、画像、音声、動画を扱えますか？
はい、1つのゲートウェイで、サポートされているルート全体のアクセスと利用状況の確認を一元化できます。それでも、アプリケーション側では、各モダリティと各ワークフローごとに個別のルートクラスとフォールバックポリシーが必要です。
フォールバックはいつ自動にすべきですか？
自動フォールバックが最も安全なのは、出力契約を機械的に検証でき、バックアップルートがすでにテスト済みで、部分的な出力がユーザーに届いておらず、副作用が不確実ではなく、バックアップがレイテンシーとコストの制限内に収まる場合です。
フォールバックはいつ手動のままにすべきですか？
成果物に主観的なレビューが必要な場合、リクエストによって副作用が発生した可能性がある場合、重複作業のコストが高い場合、またはポリシー/安全性による拒否が発生した場合は、フォールバックは手動のままにすべきです。動画生成やブランドに敏感な画像生成は、しばしばこのカテゴリに入ります。
再試行はフォールバックと同じですか？
いいえ。再試行は同じリクエストを同じルートにもう一度送ります。フォールバックはルートを変更します。再生成は新しい成果物を作成します。これらはコストと品質への影響が異なるため、別々のポリシーアクションとして扱ってください。
チームはフォールバックの品質をどのように測定すべきですか？
成功率、フォールバック率、レイテンシー、増分コスト、パーサー失敗、レビュアーの स्वीकार率、フォールバック後の却下出力率、受理された出力率を測定してください。HTTP 200は測定の始まりにすぎません。
次のモデル変更の前にルーティングポリシーを構築する
LLM APIのフォールバックルーティングを形式化する最も強い理由は、モデルへのアクセス変更がアプリケーションアーキテクチャよりも速く進むからです。テキスト、画像、音声、動画の新しいルートは今後も登場し続けます。それらの一部は消えたり、遅くなったり、価格が変わったり、負荷下で異なる振る舞いをしたりするでしょう。
製品にルートクラス、検証ルール、コスト上限、そして観測可能なフォールバック判断があれば、モデルの追加や削除は管理されたポリシー更新になります。ルーティングロジックが機能コードの中に隠れている場合、あらゆるモデル変更が移行リスクになります。
まずは1つの限定されたワークフローから始め、そのモダリティと検証クラスを定義し、承認済みのバックアップをテストしてから拡張してください。サポートされているルート全体でアクセスと課金を一元化する準備ができたら、Flatkey APIクイックスタートを使用し、統合AI APIワークフローを確認し、Flatkeyモデルディレクトリで現在のモデル可用性を比較してください。
