はじめに
OpenAI のステータスページに、新たに 20 件のインシデントが掲載されました。すべて解決済みで、現在は全コンポーネントが Operational です。
その中でも開発者が押さえておきたいのは次の 3 件です。
| 重要度 | インシデント | 影響 |
|---|---|---|
| high | ChatGPT・Codex・API（Agents API 含む）全体のエラー増加 | 30 コンポーネントに波及。RCA は 5 営業日以内に公開予定 |
| high | Agent API で OpenAI ホストのコンテナが過大請求 | 請求額に影響 |
| high | API モデル全体のエラー増加 | 主要 API エンドポイントの大半 |
この記事では、この 3 件を中心に、「自分のサービスは影響を受けたか」「何を確認すべきか」「今後どう備えるか」を整理します。
📌 影響を受ける人
- OpenAI API（Chat Completions / Responses / Realtime など）を本番で使っている開発者
- Agent API で OpenAI ホストのコンテナを使っている人（請求確認が必要）
- Codex（CLI / VS Code 拡張 / Web）を日常的に使っている人
- SSO / SCIM を使う法人の管理者
- ChatGPT Work を業務で使っているチーム
変更の全体像
今回のインシデントを領域ごとに分類すると、次のようになります。
最大のインシデント（change-007）は、API・ChatGPT・Codex の 3 系統すべてにまたがっており、共通基盤の問題が疑われます。ただし原因は RCA 公開前で、提供データからは断定できません。
変更内容
1. ChatGPT・Codex・API 全体のエラー増加（high）
今回の期間で最も影響範囲が広いインシデントです。30 のコンポーネントが影響を受け、すべて復旧済みです。RCA（根本原因分析）が 5 営業日以内に公開される予定と明記されているのも、このインシデントだけです。
| 系統 | 影響を受けたコンポーネント |
|---|---|
| API | Embeddings, Images, Batch, Audio, Files, Moderations, Chat Completions, Fine-tuning, Realtime, Responses, Agents, Compliance API |
| ChatGPT | Conversations, Voice mode, Image Generation, Deep Research, Agent, File uploads, Search, GPTs, ChatGPT Work, Sites, Connectors/Apps |
| Codex | Codex API, Codex Web, CLI, VS Code extension, Codex in ChatGPT Desktop |
| 共通 | Login |
2. Agent API のホスト型コンテナ過大請求（high）
OpenAI がホストするコンテナの利用料が、Agent API で過大に請求されていた問題が解決しました。
- 影響コンポーネントの記載はありません
- 返金などの対応は、提供データには書かれていません
- 該当期間にホスト型コンテナを使った場合は、請求額の確認が必要です（
action_required: true）
⚠️ 請求に関わる不具合
障害が「復旧した」ことと、過大請求分が「精算された」ことは別問題です。ステータスページ上で Resolved でも、請求側の補正が自動で行われるとは、このデータからは分かりません。
3. API モデル全体のエラー増加（high）
Audio、Realtime、Embeddings、Chat Completions、Fine-tuning、Files、Moderations、Responses、Login、Images、Batch の 11 コンポーネントが影響を受けました。主要エンドポイントのほとんどが対象です。
4. その他のインシデント（medium / low）
| 重要度 | インシデント | 影響コンポーネント |
|---|---|---|
| medium | ログイン・新規登録・広告機能の障害 | Login, Ads Manager, Ads API |
| medium | 一部 API リクエストのレイテンシ増加 | Chat Completions, Responses |
| medium | Codex の障害 | Codex API, Web, CLI, VS Code 拡張 |
| medium | GPT-6 Astra Pro のエラー増加 | 記載なし |
| medium | gpt-image-2.5-flare のエラー増加 | Images |
| medium | モバイルで Work Mode とモデルピッカーが表示されない | 14 コンポーネント |
| medium | SSO サインイン・SCIM プロビジョニングの障害 | 記載なし |
| low | Plus/Pro の Conversations エラー増加（計 3 件） | Conversations |
| low | ChatGPT Work のエラー増加（計 3 件） | ChatGPT Work |
| low | Space Pages のエラー増加 | Space |
| low | データ分析・ファイル作成の障害 | FedRAMP |
| low | サポートチャット障害（メール対応へ切替）、サポート返信遅延 | なし |
傾向から読み取れること
- ChatGPT Work 関連が 4 件（change-010、012、018、019）と多く、比較的新しい機能の安定性が課題になっている可能性があります
- Plus/Pro の Conversations エラーが 3 件繰り返されています
- Login が複数のインシデントに含まれており、認証基盤が共通の依存先になっていることがうかがえます
- 広告事業（Ads Manager / Ads API）もステータス監視の対象になっています
ただし、これらは件数からの推測であり、原因は公開データには書かれていません。
影響と対応
障害は「API 利用者」「Codex 利用者」「法人管理者」で影響が異なります。判断フローは次のとおりです。
アクション一覧
| 対象 | やること | 優先度 |
|---|---|---|
| Agent API 利用者 | 該当期間のホスト型コンテナ利用料を請求画面で確認 | 高 |
| API 本番利用者 | 自社ログでエラー・タイムアウトを確認し、失敗したバッチや非同期ジョブを再実行 | 高 |
| 全員 | 5 営業日以内に公開予定の RCA を確認 | 中 |
| SSO/SCIM 利用の管理者 | 障害時間帯のサインイン失敗とプロビジョニングの欠落を確認 | 中 |
| FedRAMP 環境の利用者 | データ分析・ファイル作成の失敗がなかったか確認 | 低 |
💡 Tips
ステータスページの Resolved は「現在は正常」という意味です。障害中に失敗した処理が自動で再実行されるわけではありません。 冪等な再実行の仕組みを用意しておきましょう。
コード例
障害は完全に防げないため、アプリ側でリトライとタイムアウトを備えておくことが現実的な対策です。以下は一般的な対策例で、今回のインシデント固有の公式推奨ではありません。
Before: 単発呼び出し
from openai import OpenAI
client = OpenAI()
resp = client.responses.create(
model="gpt-5", # 利用中のモデル名に置き換え
input="要約してください: ...",
)
print(resp.output_text)
エラー増加やレイテンシ悪化のときに、そのまま失敗するか長時間待たされます。
After: タイムアウトと指数バックオフ付き
import random
import time
from openai import OpenAI, APIConnectionError, APIStatusError, APITimeoutError
# SDK 側のリトライは無効化し、自前で制御する
client = OpenAI(timeout=30.0, max_retries=0)
RETRYABLE = {429, 500, 502, 503, 504}
def call_with_retry(max_attempts: int = 5):
for attempt in range(1, max_attempts + 1):
try:
return client.responses.create(
model="gpt-5", # 利用中のモデル名に置き換え
input="要約してください: ...",
)
except (APITimeoutError, APIConnectionError):
pass # ネットワーク・タイムアウトはリトライ対象
except APIStatusError as e:
if e.status_code not in RETRYABLE:
raise # 400 系などはリトライしても無駄
if attempt == max_attempts:
raise RuntimeError("リトライ上限に達しました")
# 指数バックオフ + ジッター
time.sleep(min(2 ** attempt, 30) + random.random())
resp = call_with_retry()
print(resp.output_text)
ポイントは次の 3 つです。
- タイムアウトを明示する: レイテンシ増加時に無限待ちを防ぐ
- リトライ対象を絞る: 一時的なエラーのみ再試行する
- ジッターを入れる: 復旧直後の一斉リトライによる再障害を避ける
請求確認の考え方
過大請求の確認は、ダッシュボードの Usage / Billing 画面で該当期間のコンテナ利用量を見るのが基本です。日別・プロジェクト別に、自社の実行ログ上のコンテナ利用時間と突き合わせると、差異に気づきやすくなります。
まとめ
- OpenAI のステータスに 20 件のインシデントが掲載され、すべて解決済み
- 最大の影響は、ChatGPT・Codex・API の 30 コンポーネントに及ぶエラー増加。RCA は 5 営業日以内に公開予定
- Agent API のホスト型コンテナ過大請求は、請求額の確認が必要。返金対応は提供データに記載なし
- API モデル全体のエラー増加では、11 の主要コンポーネントが影響を受けた
- ChatGPT Work（4 件）や Plus/Pro の Conversations（3 件）は繰り返し発生している
- 開発者は、タイムアウト・指数バックオフ・失敗ジョブの再実行手段を整えておくと、次の障害に強くなる
今すぐやることは 2 つです。Agent API のコンテナ利用者は請求を確認し、API 本番利用者は障害時間帯の失敗処理を確認してください。詳細な原因は、RCA の公開後に追記・確認するのがおすすめです。
参照: OpenAI Status（各インシデントの詳細ページ）