OpenRouterがダウン？コードを変えずにフェイルオーバーする方法

人々が OpenRouter Down で検索するとき、通常はすぐに2つの答えを知りたいものです。OpenRouter は本当にダウンしているのか、そして自分のアプリを書き直さずにリクエストを止めずに済ませるにはどうすればよいのか、ということです。

最も安全な答えは、コード内であわててモデルを切り替えないことです。まず、問題が OpenRouter 全体なのか、プロバイダー固有なのか、アカウント固有なのか、それとも自分のリトライキューなのかを確認します。次に、フェイルオーバーを設定へ移します。つまり、ステータス確認、リトライ予算、プロバイダーフォールバック、モデルフォールバック、そして差し替え可能な OpenAI 互換の base_url です。

確認日: 2026年10月13日。この記事を、OpenRouter が今まさにダウンしていることの証拠として扱わないでください。インシデントを開始する前に、OpenRouter のステータスページと自分のログを確認してください。

簡潔な答え

OpenRouter がダウンしている場合、または OpenRouter の特定ルートが失敗している場合は、次の順序で対応します。

1. https://status.openrouter.ai/ とエラーログを確認します。
2. OpenRouter プラットフォームのエラーと、上流のモデル／プロバイダーのエラーを切り分けます。
3. 429、503、および in-flight budget の 402 レスポンスでは、Retry-After を尊重します。
4. コンプライアンス上の要件がない限り、provider.allow_fallbacks を有効にしておきます。
5. レスポンス品質の契約上許される場合は、リクエスト設定でモデルフォールバックを追加します。
6. API ゲートウェイまたはバックアップエンドポイントを環境変数の背後に置き、アプリケーションコードを編集せずに base_url を切り替えられるようにします。

最後の点が、実際の「コードを変えずに」行う方法です。アプリケーションは設定からエンドポイントを読み込むべきです。

OPENAI_BASE_URL=https://openrouter.ai/api/v1
OPENAI_API_KEY=...

インシデント中は、運用上の変更は次のようになります。

OPENAI_BASE_URL=https://router.flatkey.ai/v1
OPENAI_API_KEY=...

SDK のコードはそのままです。

OpenRouter はダウンしていますか？

1回の失敗したリクエストから OpenRouter Down と判断してはいけません。失敗したリクエストは、次のような意味を持つことがあります。

OpenRouter のエラードキュメントによると、502 は選択したモデルがダウンしているか、無効なレスポンスを返したことを意味し、503 は利用可能なモデルプロバイダーがルーティング要件を満たしていないことを意味し得ます。同じドキュメントでは、OpenRouter が 429、503、および一部の in-flight budget の 402 レスポンスで Retry-After を返す場合があるとも説明されています。出典: OpenRouter errors and debugging。

OpenRouter は過去に公開障害を起こしたことがあります。2026年2月17日と19日の事後報告では、サードパーティのキャッシュ依存関係による API 障害が説明されており、インシデント中に一部のユーザーが紛らわしい 401 エラーを目にしたことも記載されています。この過去の投稿は文脈として有用ですが、現在の障害を示す証拠ではありません。出典: OpenRouter outage postmortem。

最初の5分: OpenRouter ダウンのトリアージ

トラフィックを切り替える前に、このチェックリストを使ってください。

OpenRouter Down のインシデントで最もよくあるミスは、すべてのワーカーが即座にリトライするようにしてしまうことです。リトライ嵐は、1つのプロバイダーエラーを、自分のアプリ内でのプラットフォーム全体のキュー問題に変えてしまう可能性があります。

コードを変えずにフェイルオーバーする

コード変更なしのパターンはシンプルです。SDK の使い方は安定させ、ルートを設定可能にします。

import OpenAI from "openai";

export const ai = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
  baseURL: process.env.OPENAI_BASE_URL,
});

その後、エンドポイントの選択は環境変数、デプロイ設定、機能フラグ、またはシークレットマネージャーで管理します。

ai_gateway:
  primary:
    base_url: https://openrouter.ai/api/v1
    key_env: OPENROUTER_API_KEY
  backup:
    base_url: https://router.flatkey.ai/v1
    key_env: FLATKEY_API_KEY
  switch_policy:
    trigger: confirmed_platform_incident_or_error_budget_exhausted
    owner: on_call_engineer
    rollback: after_30_minutes_below_error_threshold

これは、OpenRouter のクイックスタートに「SDK を OpenRouter に向けることで、その API は OpenAI SDK 経由で利用できる」とあるため機能します。同じ統合パターンこそが、OpenAI 互換のバックアップゲートウェイを実用的にします。出典: OpenRouter quickstart。

モデルを変更する前にプロバイダーフォールバックを使う

OpenRouter に到達できるが、どれか 1 つのプロバイダーに問題がある場合、プロバイダーフォールバックが最もリスクの低い対応です。同じモデル契約を維持したまま、ルーティングに別の適格プロバイダーを試させます。

OpenRouter のプロバイダールーティングのドキュメントでは、可用性を最大化するためにリクエストは既定で上位プロバイダー間で負荷分散され、provider オブジェクトには既定で true の allow_fallbacks が含まれると説明されています。また、sort や order を設定するとロードバランスの挙動が変わり、厳しいプロバイダーフィルターはルーティングの余地を減らすとも警告しています。出典: OpenRouter provider routing。

まずは次から始めます。

{
  "model": "anthropic/claude-sonnet-4.5",
  "messages": [{ "role": "user", "content": "..." }],
  "provider": {
    "allow_fallbacks": true
  }
}

インシデント中はこれに注意してください。

{
  "provider": {
    "only": ["one-provider"],
    "allow_fallbacks": false
  }
}

厳格なルーティングは、コンプライアンス、データ保持、リージョン、または価格ポリシーのために正しい場合があります。しかし、厳格なルーティングは信頼性設定ではありません。機微なワークロードで厳格なルーティングが必要な場合は、より自由にフェイルオーバーできる別の非機微パスを作成してください。

出力が相互に置き換え可能な場合にのみモデルフォールバックを追加する

モデルフォールバックはプロバイダーフォールバックより強力です。プライマリモデルがダウンしたり、レート制限されたり、ブロックされたりした場合でもアプリを生かし続けられますが、出力のスタイル、レイテンシ、コスト、コンテキスト長、ツール動作、評価結果も変わり得ます。

OpenRouter のモデルフォールバックのドキュメントでは、models パラメータでモデル ID を優先順に指定できると説明されています。最初のモデルがエラーを返すと、OpenRouter は次のモデルを試します。また、レート制限やダウンタイムがフォールバックを引き起こしうるエラーとして挙げられています。出典: OpenRouter model fallbacks。

契約上の同等性が緩いタスクにはモデルフォールバックを使ってください。

{
  "models": [
    "anthropic/claude-sonnet-4.5",
    "openai/gpt-4o",
    "google/gemini-2.5-pro"
  ],
  "messages": [{ "role": "user", "content": "このサポートスレッドを要約してください。" }]
}

正確なモデル自体が製品保証の一部であるタスクでは、サイレントなモデルフォールバックを避けてください。

実用的なインシデントポリシー

このポリシーは意図的に地味です。OpenRouter がダウンしたときの対応を、劇的ではなく運用可能なものに保ちます。

openrouter_down_policy:
  status_checks:
    - openrouter_status_page
    - synthetic_chat_completion
    - provider_error_rate_by_model
    - queue_retry_rate

  retry_budget:
    max_attempts: 3
    honor_retry_after: true
    jitter: true
    stop_retrying_on:
      - invalid_credentials
      - spent_budget
      - moderation_block
      - bad_request

  provider_fallback:
    default_allow_fallbacks: true
    loosen_provider_constraints_for:
      - non_sensitive_batch_jobs
      - internal_tools
      - support_summaries

  model_fallback:
    require_contract: equivalent_quality_or_validated_schema
    log_selected_model: true
    disallow_for:
      - evals
      - compliance_outputs
      - customer_promises_about_exact_model

  base_url_failover:
    primary: OPENAI_BASE_URL
    backup_env: OPENAI_BACKUP_BASE_URL
    switch_owner: on_call_engineer
    switch_requires:
      - confirmed_status_incident_or_internal_error_budget
      - rollback_plan
      - public_request_log_enabled

記録すべき重要なフィールドは次のとおりです。

Flatkey の位置づけ

Flatkey は、OpenRouterがダウンしたときの対応手順をアプリケーションコードの外に置きたい場合に有用です。Flatkey のプロダクト位置づけは、統合された LLM API ゲートウェイです。1つのキー、1つの残高、そして公式のテキスト・画像・動画モデル全体でルーティングできる OpenAI 互換エンドポイントを提供します。このインシデントパターンにおける実用的な価値は運用面にあります。

• アプリを OpenAI 互換のクライアント形状のまま維持する。
• アプリのロジックを変更せずに、バックアップの base_url 経由でワークロードをルーティングする。
• モデルの許可リスト、サブキー、リクエストログ、予算制御、フォールバックポリシーを一元管理する。
• 伝聞ではなく、リクエストの証跡を使ってゲートウェイの挙動を比較する。

小さな障害の間に、すべてのワークロードを移行しないでください。まず代表的なワークロードを1つ移し、エラー率、レイテンシ、選択されたモデル、フォールバック理由、コストを監視してから、切り替え範囲を広げるか判断してください。

参考になる次の読み物:

• OpenRouter Rate Limits
• LLM API fallback routing
• Model fallback strategy
• AI API quota management
• Flatkey API quickstart

OpenRouter がダウンしたときの FAQ

今、OpenRouter はダウンしていますか？

まず OpenRouter のステータスページ を確認してください。この記事は、OpenRouterがダウンという検索が実際の障害やローカルなプロバイダー障害を指している場合にどう対応するかを説明するものであり、今まさに OpenRouter がダウンしていると断定するものではありません。

OpenRouter がダウンしている場合、最初に何をすべきですか？

強いリトライを止め、ステータスコードを確認し、対話系トラフィックを保護してください。障害が確認されたら、モデルのフォールバックよりもプロバイダーのフォールバックを優先し、コードのデプロイよりも base_url の設定切り替えを優先してください。

コードを変更せずに OpenRouter からフェイルオーバーできますか？

はい。アプリが OpenAI 互換エンドポイントを設定から読み込むようになっていれば可能です。baseURL または base_url を環境変数の背後に置き、SDK の呼び出し形を安定させたまま、デプロイ設定でエンドポイントを切り替えてください。

障害時に OpenRouter のモデルフォールバックを使うべきですか？

フォールバック先のモデルがそのタスクに適している場合にのみ、モデルフォールバックを使ってください。多くの社内ワークフローには適していますが、評価、規制対象の出力、または顧客に特定モデルを約束していたケースには適していません。

OpenRouter がダウンするリスクに対する、最も安全な長期的対策は何ですか？

ルートレベルの移植性を前提に設計してください。つまり、設定可能な base_url、リクエスト単位のログ、リトライ予算、プロバイダーフォールバック、テスト済みのモデルフォールバック契約、そしてバックアップの OpenAI 互換ゲートウェイ経路です。目的はあらゆる障害を避けることではなく、フェイルオーバーを当たり前のものにすることです。