3行でいうと

  • ステータスページは、人が状況を知るための窓口です。Anthropicのページは、過去90日の稼働、4段階の事件の経過（調査中、原因特定、監視中、解決）、メールやWebhookなどの購読を備えています。OpenAIのページの稼働率は、全モデル・全ティアをまとめた集計で、自分の使う範囲の可用性とは違いうる、と注記があります。
  • エラーは「待てば直るもの」と「待っても直らないもの」に分かれます。OpenAIは、課金や支出上限のエラーは再試行しても復旧しない、と書いています。Anthropicの利用ティアの月間支出上限による429にはretry-afterがなく、再開まで失敗し続けます。
  • 別のモデルへの切り替えは、名前の差し替えでは済まないことがあります。AnthropicのOpenAI互換の窓口は、本番向けではなく、構造化出力の保証（strict）などが無視される、と書いています。切り替え先は、事前に動作を確かめておく必要があります。

この記事は、実際に使って確かめた記録ではありません。この記事は、公式の文書を読んでまとめたもので、実際に使って確かめた記録ではありません。情報は2026年10月16日に確認し、10月22日に出典を読み直しました（ステータスページの事件の例は10月16日に読んだ時点のままです）。変わることがあります。

先に結論

ステータスページの読み方

Anthropicのstatus.claude.com

読んだ範囲では、このページはAtlassian Statuspageで動いています。構成要素は、claude.ai、Claude Console、Claude API、Claude Code、Claude Cowork、Claude for Governmentの6つです。APIが止まったかを見るには、Claude API（api.anthropic.com）の行を見ます。

状態の表示は5種類です：Operational（正常）、Degraded Performance（性能低下）、Partial Outage（一部停止）、Major Outage（大規模停止）、Maintenance（保守）。過去90日の日別の表示があります。事件の経過は、Investigating（調査中）、Identified（原因を特定）、Monitoring（監視中）、Resolved（解決）の4段階で、途中にUpdateの記載が入ることもあります。

購読の方法は、メール、SMS、Slack、Microsoft Teams、Webhook、Atom／RSSです。Webhookは、事件の作成、更新、解決と、構成要素の状態の変化を知らせ、受け取り側が失敗するとメールで知らせる、と書かれています。機械が読むためのJSONの窓口は、ページには載っていませんでした。僕らがstatus.claude.comのJSONの出力を取ろうとしたところ、取得できませんでした。あるかどうかは、確認できていません。

直近の事件の例（10月5〜13日、時刻はUTC）を見ると、モデル別の短い事件（例：2026年10月5日、影響が約30分で、13時05分に調査中、13時21分に解決）が並んでいました。モデル別の事件があるので、構成要素の行と、事件の本文の両方を見るべきだと思います。これは見立てです。

OpenAIのstatus.openai.com

こちらは、incident.ioで動いています。APIsのグループに、Chat Completions、Responses、Agents、Decisions、Fine-tuning、Embeddings、Images、Batch、Audio、Moderations、Realtime、Files、Login、Liveの14個の構成要素が並び（10月16日に読んだときは、Liveのない13個でした）、グループ全体の稼働率（読んだときは99.96%）と、各行の稼働率が出ます。ChatGPT、Codexなどは別のグループです。

読むうえで大事なのは、ページ下の注記です。稼働率は、すべてのティア、モデル、エラーの種類をまとめた集計であり、個々の顧客の可用性は、サブスクリプションのティア、モデル、APIの機能で変わりうる、と書かれています。つまり、ページが「ほぼ100%」でも、自分のモデルや自分のティアだけエラーが多い、ということは、公式の説明の範囲で起こりえます。

読んだ時点では、事件の例（「Delayed Costs data in the Compliance API」という題の、Costsデータの遅延）がIdentifiedの段階で載っていたと読みました（10月22日に履歴ページを見ると、10月12日と16日の同題の2件はどちらも復旧済みでした）。購読と履歴の窓口があります。RSSのようなリンクは、取得した内容には見えませんでした。

Googleについて

Google AI Studioのstatusのページ（aistudio.google.com/status）は、取得した内容が空で、表示の形式は確認できませんでした。この記事では、Geminiのステータス表示については書きません。

見立て：ステータスページは「引き金」にしない

ここからは、僕らの見立てです。

ステータスページは、人が状況を知るのに便利ですが、自動の切り替えの条件にするのは危ういと思います。理由は3つあります。1つ目は、更新が運営側の作業を経るため、遅れがありうることです（更新の速さについての約束は、読んだ範囲では見つかりませんでした）。2つ目は、OpenAIの注記のとおり、集計の数字が自分の経路の状況と違いうることです。3つ目は、Anthropicのようにフィードが限られていると、自動で読む作りにしづらいことです。

自動の判断は、自分のアプリが観測するエラー率と遅延で行い、ステータスページは、(a) 人が原因を調べるとき、(b) 利用者への案内文を決めるとき、(c) 購読の通知（SlackやWebhook）で担当者に知らせるときに使う、という分担が無難です。

エラーを分類する：再試行してよいか

3社の文書を並べると、次のような分類ができます。表は僕らの整理で、各社の記載を材料にしています。

種類 例（各社の記載） 再試行 次の手
要求の誤り Anthropic 400、Gemini 400 しない 要求を直す
認証・権限 401、403（OpenAIは地域外のアクセスも403） しない 鍵、権限、地域を直す
課金・支出上限 OpenAI credit_balance_exhaustedなど、Anthropicの支出上限の429、Gemini 402 しない（待っても直らない） アカウントの対応
速度の上限 429（OpenAIはRetry-Afterに従う） する（待つ） 間隔を空ける、並列度を下げる
一時的な過負荷・内部エラー OpenAI 503 server_is_overloaded、Anthropic 529、500、Gemini 503 する（バックオフ） 続くなら切り替え
時間切れ Anthropic 504、Gemini 408 条件つき 長い処理はストリーミングやバッチへ
応答の途中の失敗 Anthropic：200のあとのストリーミング中にエラーが出ることがある 通常の再試行は当てはまらない 部分的な出力の扱いを決める
3社のエラーの名前と注意点（2026年10月16日に確認、10月22日に読み直し）

公式の文書の記載を、そのまま書き写しています。

Anthropic：400 invalid_request_error、401 authentication_error、402 billing_error、403 permission_error、404 not_found_error、409 conflict_error、413 request_too_large、429 rate_limit_error、500 api_error、504 timeout_error、529 overloaded_error。次の点が書かれています。

  • 要求の大きさの上限：Messages APIは32MB、Batch APIは256MB、Files APIは500MBです。
  • 支出上限：組織やワークスペースの支出上限に達すると400（Claude Codeのワークスペースは429）。月の支出上限の429は、retry-afterがなく、アクセスが再開するまで失敗し続けます。
  • 急な増加：使用量が急に増えると、429になることがあります。
  • 識別：応答ヘッダーにrequest-id、エラー本文にrequest_idがあります。
  • SDKの再試行：接続エラー、429、5xxを、指数バックオフで、既定で2回まで自動で再試行します。max_retriesで変えられます。
  • 長い処理：10分を超えそうな要求は、ストリーミングかバッチを使うこと。通信がアイドルで切れると、Anthropicから応答がないまま失敗することがあります。

OpenAI：429には、要求の過多、slow_down（急に増えたとき）、credit_balance_exhausted、organization_spend_limit_exceeded、project_spend_limit_exceeded、organization_usage_limit_exceededがあります。最初の2つは待つ、あとの4つはアカウントの対応が要る、という区別です。500は少し待って再試行、503は、Retry-Afterがあればその時間以上待つ、とあります。slow_downの対策として、入力が毎分100万トークンに達したあとは、15分で50%以内の増加にする、という目安が書かれています。失敗した要求も、毎分の上限に数えられます。

Google（Gemini）：読んだトラブルシューティングのページでは、400、402、403は再試行せず、429（RESOURCE_EXHAUSTED）、503（UNAVAILABLE）、408、5xxは、指数バックオフで再試行します。例は1秒、2秒、4秒、8秒に、ランダムなずれ（ジッタ）を足す形で、回数に上限を設けます。Pythonの公式SDKは、既定で最大4回、約1秒から、最長60秒まで再試行します。このページには、503のときに別のモデルへ切り替える案内は、書かれていませんでした。完全なエラーの表は、別ページ（api-errors）にあるとされていて、そちらは読んでいません。

再試行の設計：増やしすぎない

OpenAIのレート制限の文書は、Retry-Afterがあればそれに従い、なければ指数バックオフ（待ち時間を倍々にする方法）にジッタを足し、試行の回数と合計の再試行時間の両方に上限を置くように書いています。さらに、自前の再試行の仕組みを持つなら、SDKの再試行を無効にするか、数に入れるように、とあります。入れ子の再試行になると、要求が掛け算で増えるためです。文書にある例のコードは、Retry-Afterを読まない、とも断り書きがあります。

Googleの本（SRE Book、過負荷の章）は、もっと踏み込んでいます。

見立てです。AIのAPIの過負荷（OpenAIの503、Anthropicの529）は、多数の利用者に同時に起きるタイプだと思います。そうだとすると、粘って再試行を続けるより、数回で見切って、第2層（別のモデル）か第3層（縮退）に進むほうが、全体の負荷を増やさずに済みます。ただし、これは僕らの推測で、公式の文書が「AIのAPIはこうしなさい」と書いているわけではありません。

別のモデルへ切り替える：何が壊れるか

同じ会社の別のモデルへ

同じ会社の中でも、モデルによって使えるパラメータが違います。Anthropicのエラー文書は、Claude Opus 5.5、Sonnet 5.5、Fable 5.1、Mythos 5.1では、ツールの強制呼び出し（tool_choiceがanyかtool）は400エラーになる、と書いています。旧世代の設定で動いていたコードが、新しいモデルへの切り替えで通らなくなる例です。モデルの廃止と移行については、別の記事で扱っています。

別の会社のモデルへ

AnthropicのOpenAI互換の窓口の文書は、切り替えを考えるときの注意点の宝庫です。目的は主にモデルの能力のテストと比較で、長期や本番向けとは考えていない、と書かれています。具体的な制限は次のとおりです。

「エラーにならず黙って無視される」点が特に重要です。切り替え先で動いているように見えても、構造化出力の保証が外れていて、あとから形の崩れたデータが混ざる、ということがありえます（構造化出力の保証の範囲は、別の記事で扱っています）。

切り替え先で、ほかに確かめること

見立てとして、次の4点を挙げます。

  1. 出力の質：切り替え先で、自分の評価用の問題を流し、合格の基準を満たすかを事前に見ておく。OpenAI向けに調整したプロンプトは、調整し直しが要ることがある、とAnthropicの文書も書いています。
  2. データの置き場所と保持：切り替え先が、別の地域や別の契約（データを残さない契約など）になっていないか。置き場所の話は、別の記事で扱っています。
  3. 利用上限と費用：切り替え先の、レート制限と料金。突然の切り替え先への集中で、そちらの上限（429）に当たることもあります。
  4. 戻し方：元のサービスが復旧したあとに、どう戻すか。いつ戻すかを自動にするなら、戻した直後に急に負荷が集中しないよう、徐々に戻す。

気をつけること

出典

更新履歴