AIモデルが突然ダウンした時に備える：APIフェイルオーバー設計

2026年6月12日、米国の輸出規制により、AnthropicはClaude Fable 5をほとんど警告なしにオフラインにせざるを得ず、モデルは7月1日に復帰するまで停止していました。モデル文字列をハードコーディングしていたチームは19日間大混乱に陥りましたが、フェイルオーバーチェーンを設定していたチームは設定値を変更してすぐに作業に戻りました。

この教訓は、単一の障害よりも大きな意味を持ちます。ほとんどのLLMを利用したアプリケーションは、モデルの可用性をDNSや重力のように不変のものと見なしています。これはアーキテクチャ上の仮定ですが、誤りです。モデルは、法的リスク、容量制限、非推奨スケジュール、そして安全チームが引き戻す可能性を秘めた製品です。このガイドでは、AI APIのフェイルオーバーを設計する方法を解説します。これにより、次回モデルが停止する際（どのプロバイダのものであっても）、インシデント対応チームが奔走するのではなく、設定変更だけで済むようになります。

ボタン

モデルが消える理由

モデルが消える理由は、ほとんどのチームが想定しているよりも多くあります。

規制。 Fable 5の停止は、技術的な障害ではなく、輸出規制によるものでした。法規制やコンプライアンス関連の出来事は、非推奨スケジュールに従わず、90日前の通知もありません。障害発生時、外部からはこのように見えていました。
プロバイダのインシデント。 主要なプロバイダはすべて、数時間にわたる障害を経験しています。プロバイダのシステムが復旧する間、顧客とのSLAは一時停止しません。
非推奨化。 プロバイダは公開されたスケジュールに従ってモデルを廃止します。OpenAIは定期的に非推奨化ページを更新しており、Anthropicも同様に古いClaudeバージョンを廃止しています。非推奨化は、期日が設定されたスローモーションの障害です。
容量。 リリース週やトラフィックスパイク時には、プロバイダは負荷を軽減します。モデルが「存在している」にもかかわらず、リクエストは429や529を返し始めます。
安全性のためのロールバック。 プロバイダは、リリース後に問題を発見した場合、モデルへのアクセスを制限したり、撤回したりすることがあります。これは静かに行われ、アカウントごとに行われることもあります。

原因は異なりますが、症状は同じです。コードが依存しているモデルIDが応答しなくなります。原因に関わらず修正策は同じであるため、フェイルオーバー設計はインシデント対応ではなく、常に考慮すべき作業です。

フェイルオーバーの階層

フェイルオーバーは一つの決定ではありません。3つのレベルがあり、成熟したシステムでは通常、複数のレベルを実装しています。

レベル1：同一プロバイダ内のフォールバック。 同じベンダーの兄弟モデルにルーティングします。例えば、Fable 5 → Opus 4.8 → Sonnet 4.6のように。同じSDK、同じ認証、同じ応答形式なので、切り替えは安価で迅速です。Anthropicは、フォールバックパラメータを通じて、同じAPI呼び出し内で拒否されたリクエストを代替モデルで再試行するサーバーサイドの仕組みもサポートしています。必要になる前にフォールバックペアを把握しておきましょう。Fable 5 vs Opus 4.8の比較のような準備は、真夜中に役立つことでしょう。

レベル2：プロバイダをまたぐフォールバック。 完全に異なるベンダーにルーティングします。これにより、同一プロバイダチェーンでは対応できないプロバイダ全体の障害、アカウント停止、地域制限から保護されます。コストとして、2番目のSDK、2番目の請求関係、2番目の認証パス、そして動作が異なるプロンプトが必要になります。

レベル3：機能低下モード。 最先端のモデルをまったく使わずに、何らかの有用な情報を提供します。繰り返しのクエリにはキャッシュされた回答、分類タスクには小さなローカルモデル、あるいは明確なメッセージとともに機能自体を無効にします。機能が劣化することは許容されますが、アプリケーションが停止することは許容されません。

レベル	切り替えまでの遅延時間	品質の低下	エンジニアリングコスト
同一プロバイダ内フォールバック	数秒から数分; 設定変更または自動再試行	小〜中程度; 同じモデルファミリー、慣れた動作	低; 同じSDK、認証、応答形式
プロバイダをまたぐフォールバック	数分から数時間; ルーティングロジックとテスト済みプロンプトが必要	中程度; 異なるトークナイザー、形式、拒否動作	中〜高; 2番目の統合、請求、モニタリング
機能低下モード	構築後は実質的に即時	大きいが予測可能で正直	中程度; キャッシュ層、ローカルモデル、または機能フラグ

ほとんどのチームは、今四半期中にレベル1を導入し、レベル3を最低限の基準として維持し、収益リスクが2番目の統合を正当化する場合にのみレベル2を追加すべきです。

もう一つの設計上のポイントとして、行き先だけでなく、トリガー条件も定義してください。トラフィックを下のレベルに移動させる条件を決定しない限り、チェーンは不完全です。合理的なデフォルト設定として、モデルIDに対する404エラーは直ちにフェイルオーバーし、拒否は次のモデルで1回再試行し、429エラーはフェイルオーバーする前にバックオフし、3回連続のタイムアウトはそのモデルのサーキットブレーカーを開く、といったものがあります。これらのルールをルーティング層に組み込んでおけば、真夜中に判断を下す必要はありません。

フェイルオーバーを安価にする設計上の工夫

フェイルオーバーは、障害が発生するずっと前の決定によって、安価にも高価にもなります。

モデルIDをコードではなく設定ファイルに置く。 モデル文字列をすばやくgrepで検索してください。もしそれが1つの設定ファイルではなく、アプリケーションコードのあちこちにある場合、デプロイなしにフェイルオーバーすることはできません。ルートごとの優先順位リストが機能する形式です。

# config/model-routes.yaml
routes:
  chat-assist:
    primary: claude-fable-5
    fallbacks:
      - claude-opus-4-8
      - claude-sonnet-4-6
    degraded_mode: cached_answers
    max_output_tokens: 8192
    timeout_seconds: 120
  ticket-classifier:
    primary: claude-sonnet-4-6
    fallbacks:
      - claude-haiku-4-5
    degraded_mode: rules_engine

ルーティングを一箇所で管理する。 ゲートウェイサービスであれ、数百行のラッパーであれ、どのモデルがリクエストを処理するかを決定するのは、ただ一つのモジュールであるべきです。そして、他のすべてはそのモジュールを呼び出すべきです。最小限のバージョンは次のようになります。

MODEL_CHAIN = ["claude-fable-5", "claude-opus-4-8", "claude-sonnet-4-6"]

def complete(prompt: str) -> str:
    last_error = None
    for model in MODEL_CHAIN:
        try:
            response = client.messages.create(
                model=model,
                max_tokens=8192,
                messages=[{"role": "user", "content": prompt}],
            )
            if response.stop_reason == "refusal":
                last_error = RefusalError(model)
                continue  # try the next model in the chain
            return response.content[0].text
        except (anthropic.NotFoundError, anthropic.RateLimitError,
                anthropic.APIStatusError) as err:
            last_error = err
            continue
    raise AllModelsUnavailable(MODEL_CHAIN) from last_error

本番バージョンではサーキットブレーカーやモデルごとのタイムアウトが追加されますが、原則はどんな規模でも変わりません。呼び出し元は「モデル」ではなく「完了」を要求します。

能力階層型プロンプトを作成する。 特定のモデルの癖に依存するプロンプトは、フェイルオーバーを絵空事にします。フォールバックセット全体で許容可能な出力を生成するコアプロンプトを作成し、モデル固有の工夫（特定の思考設定、調整済みのフォーマット習慣）は、タスクを壊さずに削除できるモデルごとのオーバーレイとして分離します。ベースプロンプトは、最も強力なプライマリモデルではなく、最も弱いフォールバックモデルでテストしてください。これは思っている以上に重要です。新しい最先端モデルは、しばしば簡潔で目標指向のプロンプトで良い結果を出しますが、小さなフォールバックモデルはより明示的な構造を必要とします。プライマリモデルのためにすべてを調整すると、フォールバックモデルはうまく従えない指示を引き継いでしまいますが、セット全体のために調整すれば、プライマリモデルでの微調整は少し失われるものの、エンドツーエンドで機能するチェーンが得られます。

リクエストパラメータもポータブルに保つ。 プロンプトだけがモデル固有の要素ではありません。思考設定、サンプリングパラメータ、出力制限はモデル世代によって異なり、プライマリモデルが受け入れるパラメータがフォールバックモデルで400エラーを返すことがあります。モデルIDの隣にモデルごとのパラメータセットを設定ファイルに保存し、ディスパッチ時にルーティング層がそれらを適用するようにしてください。無効なパラメータエラーで停止するフェイルオーバーは、フェイルオーバーとは言えません。

応答をプロバイダ非依存で処理する。 ルーティング境界で、応答を独自の内部形式に正規化します。テキスト出力、構造化されたフィールドの検証、停止理由を独自のenumにマッピングします。12箇所からプロバイダ固有の応答オブジェクトにアクセスするコードは、プロバイダを切り替えた日に壊れてしまいます。

コストと制限の違いを予算に組み込む。 フォールバックモデルは、トークンあたりの価格、コンテキストウィンドウ、最大出力が異なります。Fable 5からOpus 4.8へのフォールバックは、トークンあたりのコストを約半分に削減しますが、Sonnet 4.6はさらに安価ですが、出力の上限が低くなります。記憶に頼るのではなく、現在のモデル概要を確認してください。ルーティング層は、モデルごとのmax_output_tokensと切り捨て動作を保持し、フォールバックが暗黙的に切断された回答を生成したり、予期せぬ請求を引き起こしたりしないようにする必要があります。

フォールバックセット全体でのコントラクトテスト

一度も実行されないフェイルオーバーパスは、必要なときに必ず失敗します。フォールバックチェーンをAPIコントラクトとして扱い、それに準じてテストしてください。

機能するパターン：Apidogで、フォールバックチェーン内のすべてのモデルに対して、スケジュールとCIでクリティカルなプロンプトを実行するテストシナリオを1つ保持します。各モデルについて、次の3つの項目をアサートします。

スキーマ。 応答が解析され、必須フィールドが存在し、構造化された出力がJSONスキーマに対して検証されること。これは、フォールバックモデルがJSONを異なる方法でエスケープしたり、パーサーが前提とするフィールドを削除したりするような、微妙な破損を検出します。
レイテンシ。 p95がそのモデルに設定した予算を下回っていること。技術的には機能するが40秒かかるフォールバックは、別の種類の障害です。
品質シグナル。 安価で機械的なチェック：出力が空でないこと、正しい言語であること、必要な要素が含まれていること、そしてプロンプトセット全体の拒否率がベースライン近くに保たれていること。CIで表現力を評価しているわけではありません。これは、機能しなくなったモデルを検出するためのものです。

エンドポイントURL、APIキー、モデルIDを環境変数として保持する、モデルごとまたはプロバイダごとに1つのApidog環境で構成します。これにより、同じシナリオが環境を切り替えるだけでclaude-fable-5、claude-opus-4-8、claude-sonnet-4-6に対して変更なしで実行され、チェーンに4番目のモデルを追加する場合は、新しいテストを作成するのではなく、環境を追加するだけで済みます。

プロンプトセットは意図的に選択してください。何百ものケースは必要ありません。生産トラフィックを代表する10〜20のプロンプトがあれば十分です。送信する最も長いコンテキスト、解析する最も厳密な構造化出力、かつてパーサーを壊したエッジケース、そして少なくとも1つはドメインの機密境界に近いプロンプトを含め、拒否のずれがサポートチケットではなくテスト実行で明らかになるようにします。このセットをプロンプトと一緒にバージョン管理し、本番環境で予期せぬ事態が発生した場合は、その予期せぬケースをスイートに追加してください。

障害発生時のボーナスとして、1つの環境を記録された応答を返すモックサーバーに向け、プロバイダが停止している間もCIはモデルの下流すべてを検証し続けます。Apidogは、テストで既に使っている同じAPI仕様からそのモックを生成できるため、障害がリリースパイプラインをブロックすることもありません。

6月12日、冷静なチームと大混乱に陥ったチームとの違いは、まさにここにありました。一部のチームは、Opus 4.8パスが主要なプロンプトに対して有効な出力を生成するという夜間テストの結果を持っていました。他のチームは希望しか持っていませんでした。

運用準備

アーキテクチャによってフェイルオーバーが可能になります。運用によって迅速かつ明確な意思決定が可能になります。

プライマリだけでなく、すべてのモデルをプローブする。 ユーザーのトラフィックとは別に、チェーン内の各モデルに対してスケジュールされた合成プロンプトを実行します。 status.anthropic.comのようなプロバイダのステータスページは便利ですが、遅延があり、プロバイダの世界を記述するものであって、あなたのアカウント、地域、またはレート制限ティアを記述するものではありません。あなた自身のプローブが最初に失敗します。
5xxだけでなく、拒否率やエラー率にもアラートを設定する。 モデルレベルの問題は、HTTPレベルのダッシュボードがグリーンであっても、拒否率の上昇、404 model_not_foundエラーの発生、または429エラーとして現れることがよくあります。
カットオーバールーンブックは必要になる前に作成する。 誰がフェイルオーバーを決定するのか、どの設定値が変更されるのか、サポートや顧客へのアナウンスは何と言うのか、そして最初の1時間でどのダッシュボードを監視するのかを定義します。Fable 5の障害時には、ルーンブックがなかったチームは、実行するよりも決定することに多くの時間を費やしました。
復帰の段階的実行。 プライマリが復帰した際、トラフィックの100%を一気に切り替えないでください。少量のトラフィックでカナリアテストを行い、品質と拒否のメトリクスをフォールバック時のベースラインと比較し、その後段階的に増量します。Fable 5 APIへの切り戻し方でそのプロセスの仕組みを説明しており、このパターンはあらゆる復帰するプライマリモデルに適用されます。
リハーサルする。 四半期に一度、ステージング環境で意図的にフェイルオーバーを実施するか、リスク許容度に応じて小規模なトラフィックセグメントで本番環境で実施します。ドリルによって、フォールバックアカウントの期限切れのAPIキー、誰も見つけられないダッシュボード、そして6か月前に名前が変更された設定値などが見つかります。これらはすべて、平穏な火曜日に見つける方が安価です。

Fable 5の事例から具体的に学べること

7月1日の復帰には、ポリシー構築に値する詳細がありました。AnthropicはFable 5を再デプロイしましたが、それは再訓練された安全分類器を備えたものでした。同じモデルID、同じAPIサーフェスですが、オフラインになったモデルとバイト単位で同じではありませんでした。拒否の境界線が移動しました。6月上旬には問題なかったプロンプトが、7月には異なる結果を返す可能性があり、以前は発動していたいくつかの拒否がもはや発動しないこともありました。

このことから導かれるルールは、復帰時には再有効化ではなく、再テストを行うということです。停止、ロールバック、または長期的な非推奨からの復帰など、何らかの理由で停止していたモデルが戻ってきた場合、それは新しいモデルバージョンとして扱うべきです。完全なコントラクトスイートを実行し、拒否率と品質のメトリクスを、フォールバック時の数値ではなく、障害発生前のベースラインと比較します。段階的に増量する前にカナリアテストを行ってください。

もう一つ、静かな教訓があります。19日間は、フォールバックモデルが実質的なベースラインとなるのに十分な期間です。ユーザーはOpus 4.8の挙動に適応し、社内チームはそれに基づいてプロンプトを調整しました。復帰は単なる技術的なイベントではなく、製品変更であり、製品リリースと同じくらいの注意を払う必要があります。

よくある質問

同一プロバイダのフォールバックチェーンで十分ですか、それとも2番目のプロバイダが必要ですか？

まずは同一プロバイダから始めてください。非推奨化、容量のインシデント、安全性のロールバック、モデル固有の停止に、ごくわずかなエンジニアリングコストで対応できます。Anthropicのサーバーサイドフォールバックのような機能は、導入をほぼ無料にします。プロバイダ全体での障害やアカウントレベルのイベントが、2番目の統合を維持するコストよりも高くなる場合に、プロバイダをまたぐパスを追加してください。機能低下モードは、いずれの場合でも構築する価値があります。

トラフィックがより小さなモデルにフェイルオーバーした場合、ユーザーは気づきますか？

タスクによりますので、推測するのではなく測定してください。情報抽出や分類においては、適切にプロンプトされたより小さなモデルは、しばしば区別がつきません。長文の推論ではギャップが見られます。Fable 5 vs Opus 4.8の比較のようなベンチマークは、初期の参考になります。能力階層型プロンプトと正直なUI文言（「現在、応答は簡潔になる場合があります」など）は、知覚されるギャップをさらに狭めます。

フォールバックパスはどのくらいの頻度でテストすべきですか？

毎日スケジュールに従って、プロンプトやルーティング設定の変更があった場合はCIで、そしてチェーンに影響を与える可能性のあるプロバイダのアナウンスがあった直後にテストすべきです。主要な20のプロンプトを3つのモデルに対して実行するトークンコストは、障害発生時に壊れたフォールバックを発見するコストに比べれば微々たるものです。

モデルの可用性は、より予測不可能になるでしょう。より厳格な規制、より速いリリースおよび非推奨サイクル、そしてすべてのローンチで変動する容量がその理由です。次のFable 5のような事態を乗り切るチームは、モデルを恒久的な設備ではなく、予備がテスト済みの交換可能なコンポーネントとして扱っていたチームです。この作業は、設定ファイル、ルーティングラッパー、そして毎晩実行されるコントラクトスイートに収まります。Apidogをダウンロードし、今日からフォールバックチェーンをスケジュールテストに組み込みましょう。次の障害はいつ起こってもおかしくないのですから。