モデルフォールバックチェックリストの作業は、ルーターがトラフィックを切り替える前に始まります。フォールバックモデルは、プライマリ経路が失敗したときにリクエストを救える一方で、回答品質、トークンコスト、ツール動作、ストリーミングの意味論、データ処理、インシデント可視性を変えてしまう可能性もあります。フォールバックは「別のモデルを試す」ための広いトグルではなく、評価済みの本番ポリシーとして扱うべきです。
このガイドでは、LLMゲートウェイ、OpenAI互換ルーター、マルチプロバイダーのAI API経路を運用するチーム向けに、実践的なモデルフォールバックチェックリストを示します。焦点は、フォールバックが顧客トラフィックに触れる前に答えておくべき問いです。つまり、バックアップモデルは十分に良いか、十分に安価か、ツール互換性は十分か、十分に可観測か、そして同じデータ境界で許可されているか、という点です。
Flatkeyが関連するのは、その公開製品コピーがflatkey.aiを、1つのAPIキー、https://router.flatkey.ai/v1のOpenAI互換ベースURL、明確な料金体系、統合請求、使用状況分析、ダッシュボード制御、自動切替、負荷分散、クォータ制限を備えたものとして位置づけているためです。これらの機能はルーティングの一元化を容易にします。ただし、エンジニアリング、プロダクト、財務、セキュリティが確認できる明示的なモデルフォールバックチェックリストの必要性はなくなりません。
クイックアンサー: モデルフォールバックのチェックリスト
本番で LLM model fallback を有効にする前の go/no-go 判定として、この model fallback checklist を使用してください。各行には、担当者、合格条件、停止条件を設定する必要があります。
| Gate | Pass Question | Stop Condition | Evidence To Keep |
|---|---|---|---|
| Quality | フォールバックは、プライマリ経路と同じタスク固有の評価を満たしていますか? | 許容された回帰予算を超えて、必要な事実、形式、安全性の姿勢、または顧客に見えるトーンを変更する場合は、フォールバックをブロックします。 | 評価セット、合格率、失敗例、レビュー担当者のメモ、承認済みフォールバック範囲。 |
| Cost and quota | フォールバックは、同じ予算、トークン上限、クォータプール、価格単位の前提内で実行できますか? | 別のチーム、アカウント、モダリティ、またはプロバイダーの予算を承認なしに消費する場合は、フォールバックをブロックします。 | 価格スナップショット、使用量見積もり、支出担当者、クォータ担当者、最大試行回数。 |
| Tools and schema | フォールバックは、同じ関数呼び出し、構造化出力、ツールの副作用、応答形式を処理できますか? | 必要なツール呼び出し、JSON schema、ストリーミングイベント、または出力フィールドが非対応または不整合である場合は、フォールバックをブロックします。 | ツール契約テスト、スキーマ検証、必須/並列ツール呼び出しチェック、再実行安全性のメモ。 |
| Streaming and retry boundary | フォールバックはユーザーに見える出力の前にのみ許可されますか、それとも UI は部分出力の後に再開始するよう設計されていますか? | 部分出力、ツール実行、または非冪等な副作用の後に、サイレントなフォールバックを行う場合はブロックします。 | 試行タイムライン、最初の出力タイムスタンプ、部分出力フラグ、再試行/フォールバック理由。 |
| Compliance and data boundary | フォールバックは、同じデータクラス、リージョン、ベンダーアカウント、保持ポリシー、ログモードで承認されていますか? | 安全性、プライバシー、DLP、認証、IP allowlist、未対応リージョン、または未承認のベンダー/アカウントの問題がある場合は、フォールバックをブロックします。 | データクラスタグ、承認済みベンダー一覧、ログモード、ポリシー決定、レビュー担当者の承認。 |
| Observability | 運用担当者は、要求モデル、選択モデル、プロバイダー、試行、エラー、コスト、最終結果を再構成できますか? | 最終的な成功によって、失敗した経路の試行や予算への影響が隠れる場合は、フォールバックをブロックします。 | リクエストID、ルートポリシーID、モデル試行チェーン、プロバイダーエラー、使用量、コスト、ダッシュボードリンク。 |
フォールバックがリトライと同じではない理由
リトライは、一時的な障害の後に同じ論理経路で同じリクエストを再送します。フォールバックは、モデル、プロバイダー、アカウント、エンドポイントファミリー、または動作面を変更します。だからこそ、AIゲートウェイのフォールバックには、標準的なネットワークリトライよりも厳格な承認プロセスが必要です。
OpenAIの現在のエラーコードガイダンスでは、認証エラー、レート制限、クォータ超過、サーバーエラー、過負荷、そして突然のリクエストレート低下が区別されています。これらのカテゴリのうち、リトライやフォールバックの対象になるのは一部だけです。500エラーや一時的な過負荷は、範囲を限定したリトライを正当化する場合があります。401、対応していない地域、安全性ブロック、形式不正のリクエスト、または月間予算の使い切りは、通常、所有者が根本原因を修正するまでフェイルクローズにすべきです。
公開されているVercel AI Gatewayのドキュメントでは、順序付きのモデルフォールバックとプロバイダー試行メタデータがゲートウェイパターンとして説明されています。ゲートウェイは、主要モデルが失敗したり利用できなかったりした場合にバックアップモデルを試すことができ、メタデータによってどのモデル/プロバイダーの試行が行われたかを示せます。これはパターンの証拠として使い、Flatkeyの動作主張として使わないでください。自社システムでは、モデルフォールバックチェックリストで、どの失敗が次の経路への移行を許可され、どの失敗で停止しなければならないかを定義する必要があります。
トラフィック前にフォールバック階層を定義する
すべてのフォールバックが同じリスクを持つわけではありません。同一モデルのプロバイダー障害時フェイルオーバーは、別のモデルファミリーよりも挙動をよりよく維持できる可能性があります。一方、より安価な小規模モデルは分類には許容できても、カスタマーサポートの回答には適さない場合があります。自動切り替えを有効にする前に、各ルートを階層に分けておきましょう。
| フォールバック階層 | 典型的な用途 | 主なリスク | 承認ルール |
|---|---|---|---|
| 同一モデル、別のプロバイダーまたはアカウント | プロバイダー障害、アカウントレベルの問題、リージョンのキャパシティ問題。 | プロバイダー固有のパラメータ、価格、レート制限、ログが異なる場合があります。 | エンドポイント、パラメータ、クォータ、コスト、ログフィールドの同等性チェック後に承認します。 |
| 同一ファミリー、より小さいまたは高速なモデル | レイテンシーに敏感なタスク、軽量な要約、単純な抽出。 | 品質および指示追従の劣化。 | より小さいモデルでの評価に合格したワークフローに対してのみ承認します。 |
| 別のモデルファミリー | プロバイダー障害または機能固有の復旧。 | 出力スタイル、安全性の挙動、ツール呼び出し、推論の深さ、トークン使用量が変化する可能性があります。 | 各ワークフローごとに、プロダクト、エンジニアリング、ポリシーの承認を求めます。 |
| フォールバックではなくキューに入れる | バッチジョブ、緊急性の低いエンリッチメント、バックフィル、レポート生成。 | ユーザー結果の遅延、見えにくいバックログ、古いデータ。 | ユーザー体験が遅延に耐えられ、ジョブが所有権メタデータを保持できる場合に承認します。 |
| クローズして失敗する | 認証、権限、安全性、データ境界、予算超過、不正なリクエスト。 | 短期的な失敗がユーザーまたはオペレーターに見える形で発生します。 | ポリシー、セキュリティ、コンプライアンス、および未承認予算のケースではデフォルトです。 |
タスクを評価する品質ゲート: モデル名ではなく
モデルフォールバックチェックリストの品質項目では、ワークフロー固有の評価を使うべきです。フォールバックはタイトル生成には適していても、契約レビューには不適切な場合があります。分類ラベルには適していても、ツールを使うサポートワークフローではリスクが高い場合があります。ポリシーは、実際に本番で動くタスクの形をテストすべきです。
小規模でも代表性のあるフォールバック評価セットを作成します:
- ゴールデン例: 通常ケース、境界ケース、優良顧客に対する、一次ルートで成功した出力。
- 失敗例: 以前に幻覚、拒否、スキーマのずれ、ツールの誤用、または長すぎる応答を引き起こしたプロンプト。
- 回帰チェック: 必須の事実、禁止事項、出力スキーマ、トーン、引用ルール、および安全性の姿勢。
- 人手レビュー: 自動チェックでは品質を判断できない例に対するレビュアーのメモ。
- フォールバックの適用範囲: フォールバックが承認される、正確なワークフロー、環境、顧客ティア、モデル一覧、および最大試行回数。
OpenAI の eval 例では、狭いフィールドをチェックしたり、正解と比較したり、出力をより包括的に判断したりできるグレーダーが示されています。このパターンをフォールバック承認に使ってください。各フォールバック候補には、曖昧な「見た感じ良い」レビューではなく、具体的な合否基準が必要です。
コストゲート: プライマリだけでなくフォールバック経路にも価格を設定する
フォールバックは、より高価なモデル、より大きなコンテキストウィンドウ、別のモダリティ、プレミアムなプロバイダーティア、または別のクォータープールへ静かにトラフィックを移動させることで、信頼性インシデントをコストインシデントに変える可能性があります。このモデルフォールバックチェックリストのコスト部分では、開始前に次の4つの質問に答える必要があります。
- コスト単位は何か？ テキストトークン、キャッシュされた入力、推論トークン、画像出力、動画秒数、またはプロバイダー固有の単位によって、予算の形は変わります。
- 1リクエストあたりの最大コストは何か？ フォールバック経路の入力、出力、コンテキスト、推論、試行回数の上限を設定します。
- どの予算が使われるか？ 承認なしに、本番トラフィックを別のチーム、顧客、BYOKアカウント、またはプロバイダー残高へ流し込まないでください。
- 経理はどのように把握するか？ ログには、要求されたモデル、選択されたモデル、プロバイダー、ルーティング理由、トークン使用量、コストを区別して記録する必要があります。
CloudflareのAI Gatewayドキュメントは、ここで役立つパターンの証拠です。ログページには、プロバイダー、ステータス、トークン使用量、コスト、期間などのリクエストメタデータが一覧表示されます。カスタムメタデータでチームやテスト識別子をリクエストに付与でき、カスタムコストヘッダーで公開モデルのコスト前提を上書きして、リクエスト単位の会計処理ができます。Flatkeyユーザーは、自動フォールバックに頼る前に、Flatkeyダッシュボード、使用ログ、請求レビューを通じて同種の証拠を可視化するべきです。
切り替え前に互換性を証明する: ツールとスキーマのゲート
ツール中心のワークフローでは、単なるテキスト生成よりも厳格なモデルのフォールバック チェックリストが必要です。OpenAI の関数呼び出しガイドでは、ツールはモデルに公開する機能として定義されており、複数ステップの流れとして、利用可能なツールを送信し、ツール呼び出しを受け取り、アプリケーション側のコードを実行し、ツール出力を送り返し、最終応答を受け取る、という手順が説明されています。つまり、フォールバックモデルは最初の回答だけでなく、ツールの一連のループ全体に対してテストする必要があります。
以下についてツール互換性テストを実施してください。
- ツール選択: プライマリモデルが正しいツールを呼ぶ場合、フォールバックも同じツールを呼び出すか?
- 引数: 必須フィールド、列挙型、ID、ネストされた JSON オブジェクトは検証できるか?
- 副作用: ツールは冪等か、それともフォールバックによって返金、メール送信、チケット更新、またはデータベース書き込みが重複して実行される可能性があるか?
- 並列ツール: プライマリの経路が並列ツール呼び出しを使用する場合、フォールバックも同じ挙動をサポートするか、それとも逐次化が必要か?
- 構造化出力: フォールバックは下流コードが期待するスキーマを満たすか?
- 拒否およびポリシー結果: フォールバックが危険な要求を拒否またはブロックしたとき、アプリケーションはそれを検知できるか?
OpenAI の構造化出力のドキュメントでは、Structured Outputs はモデル応答を提供された JSON Schema に準拠させるために設計されており、関数呼び出しと response-format スキーマを区別していると述べています。また、構造化出力にも依然として誤りが含まれる可能性があり、必要に応じて指示、例、またはより単純なサブタスクで扱うべきだとも説明しています。フォールバック ポリシーの観点では、これはスキーマ検証が必要ではあるものの十分ではないことを意味します。内容と副作用の両方を検証してください。
ストリーミングのゲート: 部分出力を隠さない
ストリーミングは モデルのフォールバックチェックリスト に別の境界を追加します。最初の可視トークンの前であれば、フォールバックはきれいな経路選択になりえます。ユーザーが部分出力を見た後でのサイレントな経路切り替えは、2つの異なるモデル応答を混ぜ合わせ、インシデントを隠してしまう可能性があります。
このデフォルトルールを使ってください:
- 最初の出力前: 障害が一時的で、フォールバック経路が事前承認されている場合、フォールバックを許可してもよい。
- 最初の出力後: 回答を不完全としてマークし、ユーザーに明示的に再開または再試行するよう求める。
- ツールによる副作用の後: クローズドで失敗するか、冪等な回復経路を使う。無条件に再実行しない。
- 安全性またはコンプライアンスのブロック後: クローズドで失敗する。より制約の少ないモデルにルーティングして回答を得ようとしない。
これは AI API 再試行戦略 および AI API のロードバランシングとフェイルオーバー のプレイブックと組み合わせて使います。再試行、フォールバック、キューイング、クローズドで失敗する判断は、1つの障害分類法を共有する必要があります。そうすることで、最終的な成功が経路パスを消し去ってしまうことを防げます。
同じデータ境界を維持するコンプライアンスゲート
フォールバック経路は、単純なコードパスでは見えない境界をまたぐ可能性があります。異なるプロバイダー、アカウント、リージョン、ログモード、認証情報の所有者、保持設定、またはモデレーションポリシーを使用する場合があります。model fallback checklist のコンプライアンス行は、トラフィックが移動する前にレビュー担当者が yes か no で判断できるほど明確であるべきです。
| Boundary | Question To Ask | Default Posture |
|---|---|---|
| Data class | このフォールバックは、顧客コンテンツ、社内ドキュメント、規制対象データ、秘密情報、または PII に類するペイロードに対して許可されていますか？ | データクラスがフォールバック経路として承認されていない限り、fail closed にします。 |
| Provider and account | この経路は、同じベンダーアカウント、BYOK アカウント、または承認済みベンダー一覧を使用しますか？ | アカウントをまたぐ漏れが発生する前に、アカウント所有者の承認を求めます。 |
| Logging mode | プロンプトと出力は保存されますか、それともこの経路はメタデータのみですか？ | 機密ペイロードの保持が承認されていない場合は、メタデータのみを使用します。 |
| Region or access policy | フォールバックが IP allowlist、未対応リージョンのルール、または顧客のデータ所在地ルールに違反する可能性はありますか？ | fail closed にして、所有者に通知します。 |
| Safety and policy | 主経路は、安全性、モデレーション、DLP、またはツールの認可によってブロックされましたか？ | フォールバックでポリシーブロックを迂回しないでください。 |
Cloudflare のログ記録ドキュメントは、この重要性を示す具体的な公開例を提供しています。リクエストログにはプロンプトとレスポンスが含まれることがあり、一方でリクエストごとのヘッダーによりペイロードの保存をスキップしてメタデータのみにすることができます。Flatkey のフォールバックポリシーも同様に、いつ生のコンテンツを保存できるか、いつ経路の証跡をメタデータのみにすべきかを決める必要があります。
フォールバックレビューのための可観測性フィールド
ログに「request succeeded」としか書かれていないなら、モデルフォールバックチェックリストは失敗しています。運用担当者は、成功または失敗に至った試行の連鎖を確認できる必要があります。
| フィールド | 重要な理由 |
|---|---|
| ルートポリシーIDとバージョン | どの承認済みポリシーがフォールバックを許可またはブロックしたかを示します。 |
| 要求したモデルと選択されたモデル | ユーザーの意図とルーターの判断を分離します。 |
| プロバイダー、アカウント、エンドポイントファミリー、該当する場合はリージョン | リクエストが運用上またはコンプライアンス上の境界を越えたかどうかを示します。 |
| 各試行ごとのエラークラスとステータスコード | 一時的なプロバイダー障害と、認証、クォータ、リクエスト形状、またはポリシーの問題を区別します。 |
| ツール呼び出しID、スキーマ検証結果、サイドエフェクトの状態 | ツールの重複実行と、隠れたスキーマドリフトを防ぎます。 |
| 使用量、コスト、キャッシュ、クォータ所有者 | 信頼性回復を支出と予算レビューに結び付けます。 |
| 部分出力フラグと最初の出力タイムスタンプ | フォールバックがユーザーに見える出力の前に起きたのか後に起きたのかを証明します。 |
| 最終処理結果 | 次のいずれかです: primary success, fallback success, queued, user retry required, fail closed. |
付属のAI API 可観測性ログの記事では、インシデントフィールドについてさらに詳しく説明しています。フォールバックでは、ルート試行の連鎖と停止理由を優先してください。
Flatkey ステージング展開計画
Flatkey または OpenAI 互換ルーターを通じて AI gateway fallback をテストする際は、この展開計画を使用してください。model fallback checklist を、仮定ではなく証拠に結び付けたままにできます。
- ステージングキーを作成する: フォールバックテストを本番の顧客トラフィックから切り離しておきます。
- ベースルートを確認する: 1つの OpenAI 互換クライアントを
https://router.flatkey.ai/v1に向け、プライマリモデル、エンドポイントファミリー、使用量行、ダッシュボードでの可視性を確認します。 - 現在のカタログ情報を記録する: 2026年6月18日時点で、Flatkey の pricing API は 638 のモデル行、23 のベンダー、および OpenAI chat completions、OpenAI Responses、Anthropic messages、Gemini generateContent、image generation、video generation を含むエンドポイントファミリーを返しました。これは恒久的な契約ではなく、日時のある証拠として扱ってください。
- 1つのフォールバック階層を選ぶ: 同一モデルのルートや、狭いタスク向けに明確に範囲を絞った低コストモデルなど、ワークフローに適した最もリスクの低いフォールバックから始めます。
- トラフィック投入前に eval を実行する: ゴールデン例、エッジケース、スキーマ検証、ツール呼び出し、ストリーミング境界、ポリシーブロックをテストします。
- 強制的な障害テストを実行する: プライマリのタイムアウト、レート制限、プロバイダーエラー、不正なリクエスト、認証エラー、クォータ枯渇、ポリシーブロック、出力後のストリーム障害をシミュレートします。
- ログと請求を確認する: 要求モデル、選択モデル、フォールバック理由、プロバイダー試行、使用量、コスト、キー、チーム、環境が表示されることを確認します。
- ロールバックルールを設定する: 品質、コスト、ポリシー、または可観測性のゲートに失敗した場合は、フォールバックを自動または手動で無効化します。
ステージングから本番へ移行する際は、LLM API gateway architecture、enterprise AI API gateway checklist、および Flatkey pricing と組み合わせてください。
フォールバックポリシーテンプレート
このテンプレートは Flatkey API 契約ではありません。フォールバックを有効化する前に、チームが調整できるレビュー用アーティファクトです。
{
"policy_id": "support-chat-fallback-v1",
"workflow": "customer-support-chat",
"environment": "production",
"primary_route": {
"model": "primary-approved-model",
"endpoint_family": "openai-chat-completions"
},
"fallback_routes": [
{
"model": "approved-backup-model",
"allowed_reasons": ["primary_timeout", "temporary_5xx", "provider_unavailable"],
"blocked_reasons": ["auth_error", "invalid_request", "quota_exhausted", "safety_block", "unapproved_data_class"],
"requires_eval_pass": true,
"requires_cost_owner": true,
"requires_tool_contract_pass": true,
"allow_after_partial_output": false
}
],
"limits": {
"max_total_attempts": 2,
"max_elapsed_ms": 12000,
"max_input_tokens": 8000,
"max_output_tokens": 1200,
"max_estimated_cost_usd": 0.05
},
"logging": {
"record_attempt_chain": true,
"record_requested_and_selected_model": true,
"record_error_class_per_attempt": true,
"record_usage_and_cost": true,
"payload_logging_mode": "metadata_only"
},
"rollback": {
"disable_on_schema_failures": true,
"disable_on_unapproved_cost_spike": true,
"disable_on_policy_boundary_error": true
}
}よくある質問
モデルフォールバックのチェックリストとは何ですか？
モデルフォールバックのチェックリストとは、プライマリ経路が失敗したときに、バックアップモデルまたはプロバイダーがトラフィックを安全に処理できるかどうかを判断するための本番レビュー用リストです。品質、コスト、クォータ、ツール、ストリーミング動作、コンプライアンス境界、観測性、ロールバックルールを含める必要があります。
再試行ではなく、LLMモデルフォールバックを使うべきなのはいつですか？
プライマリ経路で一時的なプロバイダー側の障害または利用不可が発生し、バックアップ経路が同じワークフロー向けにすでに承認されている場合は、LLMモデルフォールバックを使用してください。形式不備のリクエスト、認証エラー、安全性ブロック、予算超過、未承認のデータ分類に対してはフォールバックを使用しないでください。
AIゲートウェイのフォールバックは、ツール呼び出しをどのように処理すべきですか？
AIゲートウェイのフォールバックは、本番前にツール互換性を証明する必要があります。ツール選択、JSON引数、必須フィールド、スキーマ検証、副作用、冪等性、並列呼び出し、最終レスポンス形式をテストしてください。あるツールがすでに副作用を引き起こしている場合、その操作が明示的に繰り返し安全でない限り、別のモデルでリクエストを再実行しないでください。
最終レビュー手順
フォールバックを有効にする前に、1つの直接的な質問をしてください。このルートが切り替わった理由、何が変わったのか、どれだけコストがかかったのか、ポリシー境界を越えたのかどうか、そしてどのようにロールバックするのかを説明できますか？答えがノーであれば、モデル フォールバック チェックリストは完了していません。
Flatkey は、1つの OpenAI 互換パスの背後で、モデルアクセス、ルーティング、請求、使用状況の可視化、キー管理を一元化できます。その中心点を使って、自動切り替えが本番トラフィックに到達する前に、フォールバックの判断をテスト可能にしてください。ステージングでルートを検証する準備ができたら、キーを取得して、承認済みのフォールバック ポリシーを1つから始めましょう。
