モデルが突然消えてもAIアプリを生き延びさせる方法

AIの上に何かを作るすべての開発者は、いずれ同じ教訓を痛い目で学ぶ。依存しているモデルがそこにある保証はない、ということだ。ピーク時にレート制限されたり、拒否を返したり、過負荷エラーに当たったり、あるいは——2026年6月にClaude Fable 5に起きたように——あなたのコードとは何の関係もない理由で完全に停止させられたりする。こうした瞬間を生き延びるアプリは、最良のプロンプトを持つものではない。モデルが消えることを想定して計画していたものだ。

このガイドは、1つのプロバイダーを直接呼ぶ場合でも、ゲートウェイ経由でルーティングする場合でも機能する、実践的で多層的なレジリエンスのアプローチを順を追って説明する。

ステップ1: 単一モデルをハードコードしない

最も一般的な脆さは、モデル名がリクエストに直接焼き込まれていることだ。その文字列が動かなくなった瞬間、すべての呼び出しが失敗する。代わりに、モデルを設定として定義しよう——定数ではなく、小さな優先順位リストとして。

MODEL_CHAIN = [
    "claude-opus-4-8",      # primary
    "claude-sonnet-4-6",    # same provider, cheaper/faster
    "gpt-5.5",              # different provider entirely
]

このひとつの変更で、インシデント中にプロバイダーを切り替えることが、コードのデプロイではなく設定の編集になる。3番目のエントリが別ベンダーであることに注目してほしい。同一プロバイダーのフォールバックは単一モデルのダウンから守ってくれる。クロスプロバイダーのフォールバックは、プロバイダー全体のダウン——あるいはオフラインを命じられること——から守ってくれる。

ステップ2: 単発の試行ではなく、フォールバックチェーンを使う

パターンはシンプルだ。各モデルを順番に試し、失敗したら次へ進み、チェーン全体が尽きたときだけエラーを表に出す。

def call_with_fallback(messages):
    last_error = None
    for model in MODEL_CHAIN:
        try:
            return client.complete(model=model, messages=messages)
        except (RateLimitError, OverloadError, RefusalError) as e:
            last_error = e
            continue  # try the next model
    raise AllModelsFailedError(last_error)

何をきっかけにフォールバックするかが重要だ。一時的なoverloaded（HTTP 529）エラーで同じモデルを短いバックオフののち再試行するのは理にかなっている。だが認証エラーや不正なリクエストは、どのモデルでも同じように失敗する——それらはチェーン全体を焼き尽くすのではなく、即座に表に出すべきだ。

ステップ3: プラットフォームがネイティブにフォールバックを提供するなら、それに頼る

これを常に手作りする必要はない。いくつかのプラットフォームは今やサーバー側でやってくれる。

• AnthropicのAPIはベータのfallbacksパラメータを追加し、拒否されたリクエストを1往復で代替モデルにて再試行する——たとえばFable 5は、分類器がリクエストを拒んだときにOpus 4.8へフォールバックするよう設定されていた。課金は実際にレスポンスを返したモデルに従う。
• OpenRouterはmodels配列を優先順位順に渡せるようにし、コンテキスト長エラー、モデレーションフラグ、レート制限、ダウンタイムで自動的にフェイルオーバーし、応答したモデルのレートで課金する。
• LiteLLMは、デプロイやベンダーをまたいだ再試行・フォールバック・負荷分散を組み込んだRouterを備えており、最大限の制御のためにセルフホストできる。

OpenRouterやLiteLLMのようなゲートウェイは、多くのプロバイダーをまたぐ単一の統一エンドポイントを提供するので、クロスプロバイダーのフォールバックは統合すべき2つ目のSDKではなく、リスト内のもう1エントリにすぎなくなる。

ステップ4: サーキットブレーカーを追加して素早く失敗する

あるモデルが明らかにダウンしているなら、すべてのリクエストがそれのタイムアウトを待ってからフォールスルーするのは避けたい。サーキットブレーカーは直近の失敗を追跡し、閾値を超えると、クールダウン期間の間そのモデルを完全にスキップする。2026年の本番チームは一般に、ブレーカーをトリップさせるのに連続5回の失敗、回復をテストする前に約60秒のクールダウンあたりに落ち着いている。ブレーカーが開いている間、トラフィックはチェーン内の次のモデルへ直行する——無駄なレイテンシはない。

ステップ5: 自分のプロダクトにとって「劣化」が何を意味するかを決める

より安いモデルへのフォールバックはタダではない——品質は下がり、プロンプトの挙動が変わるかもしれない。それに備えよう。

• チェーン内のすべてのモデルでプロンプトをテストする。 1つのモデル向けに調整されたプロンプトは、そのフォールバックでは明らかに劣る出力を生むことがある。
• 劣化したときはユーザーに伝える——それが重要なら（例: 「高速モードで動作中」）。低品質な結果を黙って出荷するのではなく。
• 各リクエストに実際にどのモデルが応答したかをログに残す——インシデント後に、フォールバックがどれだけのトラフィックを吸収したか見られるように。

まとめ

レジリエンスはローンチ後に後付けする機能ではない——早期に加える少量の構造だ。定数ではなく設定、単発の呼び出しではなく優先順位チェーン、素早く失敗するためのサーキットブレーカー、そして各レベルでテスト済みのプロンプト。6月のFable 5停止中にアプリを止めずに済んだチームは運が良かったのではない。すべてのAIビルダーが初日に問うべき問いに、すでに答えていただけだ。このモデルが明日そこにいなかったら、どうなる?