OpenAI API障害が7月24日に発生 12コンポーネントの影響と復旧状況
OpenAI APIが止まっても、確認する順番が決まっていれば二重処理を避けやすくなります。
12コンポーネントの影響と復旧状況を分け、安全に戻す条件を確かめませんか？
今回の障害は2026年7月24日0時36分に公式掲載され、5時24分時点ではMonitoringです。
軽減策は適用されましたが、完全復旧を示すResolvedには進んでいません。
障害期間中はAPIの12コンポーネントに加え、ChatGPTの4項目とCodexの4項目が影響対象として表示されました。
OpenAI APIエラーが出ている企業は、再試行を重ねる前に発生時刻と処理済みの状態を照合してください。
結論軽減策適用後も回復監視中
今回の障害は一度Monitoringへ進んだ後にInvestigatingへ戻り、5時22分に再びMonitoringとなりました。公式更新の確認と少量再開を続ける段階です。
OpenAI API障害は7月24日0時36分に公式掲載
OpenAI公式ステータスは、今回のインシデントを「Elevated Error Rates」として掲載しました。
開始は7月24日0時36分JSTで、最初の状態はInvestigatingです。
その後、OpenAIは影響サービスのエラー増加を確認し、下流インフラプロバイダーと軽減策を進めていると説明しました。
プロバイダー名、根本原因、影響率は公表されていません。
Monitoring
軽減策適用後の回復を監視
≠
Resolved
公式がインシデント解決を告知
Monitoringは復旧に向けて状態を見ている途中です。
「軽減策を適用した」と「完全復旧した」を同じ意味で扱わないことが、社内の再開判断では欠かせません。
出典: OpenAI Status「Elevated Error Rates」(英語)
状態名の読み分けは、Codex障害でMonitoringからResolvedへ進んだ事例も参考になります。
OpenAI API障害で影響した12コンポーネント
今回、影響対象になったAPI項目は12コンポーネントです。
Chat CompletionsやResponsesだけでなく、画像、音声、ファイル、バッチ処理なども含まれます。
| 区分 | 影響コンポーネント |
|---|---|
| 生成・応答 | Chat Completions、Responses、Realtime |
| 学習・検索 | Fine-tuning、Embeddings |
| メディア | Images、Audio、Sora |
| 処理・管理 | Batch、Files、Login、Moderations |
読み方12件は障害期間中の影響対象数
「12 affected components」は、インシデントで影響対象となったAPI項目の数です。現在も12項目すべてが劣化中という意味ではありません。
同じインシデントページには、ChatGPTの4項目とCodexの4項目も表示されています。
ただしAPI、ChatGPT、Codexは利用経路が異なるため、自社で使うサービス単位で状態を見ましょう。
画面上の不具合とAPI障害を分ける考え方は、ChatGPT画像生成障害と利用制限の切り分けでも確認できます。
OpenAI API障害の復旧状況を時系列で確認
今回の障害は、3時50分にMonitoringへ進んだ後、4時37分にInvestigatingへ戻りました。
さらに5時22分に軽減策適用と回復監視が再度告知されています。
| JST | 状態・公式内容 |
|---|---|
| 0:36 | Investigating。調査開始 |
| 0:56 | Identified。軽減策を実施中 |
| 1:08 | Identified。対応を継続 |
| 1:48 | 下流インフラプロバイダーと対応 |
| 2:36 | 軽減策の実装を継続 |
| 2:58 | 軽減策の実装を継続 |
| 3:50 | Monitoring。回復を監視 |
| 4:37 | Investigatingへ戻る |
| 5:22 | Monitoring。再び回復を監視 |
回復監視から再調査へ戻った経過があるため、通常化を急ぐ段階ではありません。
OpenAI API復旧の確認は、最新更新がResolvedへ進んだかを基準にしてください。
複数サービスをまたぐ障害では、CodexとGitHubの2つの公式ページを照合する手順のように、依存先ごとに状態を分けて見る方法が役立ちます。
自社だけのAPIエラーか切り分ける
公式Statusに障害が載っていても、手元のOpenAI APIエラーが同じ原因とは限りません。
時刻、エンドポイント、モデル、サービス階層、プロジェクトを同じ条件で絞ります。
公式Status
同時刻の障害
→
HTTP状態
コードとエラー率
→
利用条件
モデルと階層
プロジェクトとネットワーク経路まで分けて比較する
- タイムゾーン付きの発生時刻を保存する
- 対象エンドポイントとモデルを1つずつ絞る
- HTTPステータスとエラー率を件数だけでなく割合で見る
- プロジェクトとサービス階層を混ぜずに比較する
OpenAI公式ヘルプも、集計された総数だけでなく、モデル、階層、プロジェクトを分けて調べるよう案内しています。
公式Statusが正常でも自社だけ失敗するなら、タイムアウト、プロキシ、ネットワーク経路も確認対象です。
出典: OpenAI Help Center「Troubleshooting API Errors and Latency」(英語)
OpenAI API障害時は再試行と二重処理を分ける
APIがタイムアウトした場合、応答を受け取れなくても処理自体が進んでいる可能性があります。
注文、通知、公開、請求などは、同じ要求をそのまま再送しないでください。
注意再試行の前に処理済みか確認
失敗ログだけで未処理と決めず、自社の処理ID、外部サービス側の結果、重複防止キーを照合します。確認後も一斉再開ではなく少量から戻してください。
- 連続再試行を止める
- 待機時間と再試行上限を決める
- 読み取り中心の短い処理で疎通を確認する
- 送信や公開は重複の有無を確認してから再開する
調査に使うログには、`x-request-id`または`X-Client-Request-Id`も残します。
OpenAIは、本番環境でリクエストIDを記録し、サポート時の調査に使うことを推奨しています。
出典: OpenAI API Reference「Debugging requests」(英語)
復旧後に少量から戻す流れは、Sora API障害で既存ジョブを照合して再開する手順にも共通します。
OpenAI API障害に関するよくある質問
確認復旧状態と自社対応を分けて回答
2026年7月24日5時24分JSTまでの公式情報を基準に、事実と企業側の判断を分けて答えます。
QOpenAI API障害は復旧しましたか？
A2026年7月24日5時24分JST時点ではMonitoringです。軽減策は適用されましたが、完全復旧を示すResolvedではありません。
QAPIのどの機能が影響を受けましたか？
AChat Completions、Responses、Fine-tuning、Embeddings、Images、Batch、Audio、Moderations、Realtime、Files、Login、Soraの12項目です。
Q12コンポーネントはいまもすべて障害中ですか？
A12件はインシデント期間中に影響対象となったAPI項目数です。現在も全項目が劣化中という意味ではないため、最新更新を確認してください。
QOpenAI APIエラーが出たら最初に何を確認しますか？
A公式Status、タイムゾーン付き時刻、エンドポイント、モデル、HTTPステータス、プロジェクトを確認します。
Q失敗したリクエストはすぐ再試行してよいですか？
A連続再試行は避けます。処理済みかを確認し、待機時間と上限を設けたうえで短い処理から再開してください。
QOpenAIサポートには何を伝えればよいですか？
A発生時刻とタイムゾーン、対象エンドポイントとモデル、HTTPステータス、エラー率、リクエストIDを共有します。
まとめ｜Resolvedまでは段階的に戻す
OpenAI API障害は5時22分に再びMonitoringへ進みましたが、5時24分時点ではResolvedではありません。
影響履歴の12件と現在の復旧段階を分けて読むことが大切です。
次の行動処理済み確認から少量再開へ
公式Status、発生時刻、HTTP状態、リクエストIDを残し、送信や公開は重複がないことを確かめてから戻してください。
