はじめに
2026年8月2日時点で、OpenAI ステータスページに新規登録されたインシデントは合計20件でした。結論から言うと、すべて Resolved（解決済み） であり、新機能・料金改定・破壊的変更の告知は一切含まれていません。
とはいえ「全部復旧したから関係ない」で終わらせるにはもったいない差分です。理由は次の2点です。
- ほぼ全コンポーネント（31件）が同時に落ちる全社規模の障害が短期間に2回発生している
-
gpt-5.1-mini/gpt-4.1-miniのストリーミング中断、gpt-image-2のレイテンシ上昇など、特定モデルに紐づく劣化が複数報告されている
これらは「今は直っているが、同種の障害が今後も起こりうる」ことを示すシグナルです。特に本番でストリーミング応答や画像生成 API を使っているチームは、リトライ・タイムアウト設計を見直す良い機会になります。
📌 影響を受ける人
- ChatGPT / API を業務基盤として使っているチーム
gpt-5.1-mini、gpt-4.1-mini、gpt-image-2を本番利用しているエンジニア- Codex（Web / CLI / VS Code拡張 / API）を開発ワークフローに組み込んでいるチーム
変更の全体像
今回検出された20件のインシデントを、影響範囲の大きさで分類すると以下のようになります。
特に注目すべきは B の全社規模障害で、Chat Completions・Responses・Codex・Sora・Login など OpenAI のほぼ全プロダクトが横断的に影響を受けています。
変更内容
severity が medium 以上、かつ本番運用への示唆があるインシデントを中心にまとめます。
| ID | タイトル | severity | 影響コンポーネント数 | 主な影響範囲 |
|---|---|---|---|---|
| change-009 | 全サービス規模でのエラー率上昇 | high | 31 | Chat Completions, Codex, Sora, Login, Agent 他ほぼ全て |
| change-010 | 全サービス規模でのエラー率上昇（2件目） | high | 31 | change-009 とほぼ同一範囲 |
| change-007 | gpt-5.1-mini / gpt-4.1-mini のレイテンシ上昇・ストリーミング中断 | medium | 1（Chat Completions） | 特定モデル限定の性能劣化 |
| change-013 | gpt-image-2 の API エラー率・レイテンシ上昇 | medium | 1（Images） | 画像生成モデル限定 |
| change-011 | API中心の広範なエラー率上昇 | medium | 20 | Batch, Realtime, Chat Completions 等 |
| change-014 | 一部ユーザーでのChatGPTエラー率上昇 | medium | 15 | Conversations, Search, Agent 等 |
| change-012 | Codex Review のエラー率上昇 | medium | 4 | Codex Web/CLI/VS Code拡張/API |
| change-018 | ログイン・サインアップ障害 | medium | 2 | Login, API Platform |
| change-019 | GitHub連携ワークフローのエラー率上昇 | medium | 4 | Codex Web, Connectors, CLI, VS Code拡張 |
low severity の残り11件は、画像生成（Image Generation / Images）や Conversations、Voice mode といったコンポーネント単体〜数個の限定的な障害で、いずれも即座に Resolved となっています。件数としては画像生成関連の障害が6件と最多である点は覚えておいて良いでしょう。
⚠️ Breaking Change
今回の差分に破壊的変更は含まれていません。API のレスポンス形式や認証方式に変更はなく、コード修正は必須ではありません。
影響と対応
新機能追加やAPI仕様変更ではないため「今すぐ何かを直す」必要はありません。ただし、今回の障害傾向から次のような予防的な対応が推奨されます。
1. ストリーミング処理の再接続・リトライ設計を確認する
gpt-5.1-mini / gpt-4.1-mini でストリーミング応答が途中切断される事象（change-007）が報告されています。SSE などでストリーミングを受信している場合、切断時に安全に再開・再試行できる実装になっているか確認してください。
2. 画像生成APIのタイムアウト値を見直す
gpt-image-2 のレイテンシ・エラー率上昇（change-013）に加え、画像生成関連のインシデントが差分全体で6件と突出しています。画像生成は他のテキスト系エンドポイントよりレイテンシのばらつきが大きい前提で、タイムアウトとリトライのバックオフ幅を余裕を持って設定するのが安全です。
3. 全社規模障害への備え（サーキットブレーカー）
31コンポーネントに及ぶ全社障害が短期間に2回（change-009, change-010）発生しています。頻度としては稀ですが、OpenAI 依存度の高いプロダクトでは、フォールバック応答やサーキットブレーカーパターンを導入しておくと、障害時のユーザー影響を抑えられます。
4. ステータスページの監視を自動化する
手動でステータスページを確認するのではなく、Webhook や RSS 経由でインシデント発生を検知できるようにしておくと、障害発生時に迅速にリトライ設定を切り替えるなどの対応が可能になります。
コード例
Before: リトライなしのストリーミング処理
import openai
client = openai.OpenAI()
def stream_chat(prompt):
response = client.chat.completions.create(
model="gpt-5.1-mini",
messages=[{"role": "user", "content": prompt}],
stream=True,
)
result = ""
for chunk in response:
delta = chunk.choices[0].delta.content or ""
result += delta
print(delta, end="")
return result
このコードは、ストリーミング中に接続が切れると例外を投げて終了するだけで、途中経過を活かした再開ができません。
After: 中断検知とバックオフ付きリトライを追加
import time
import openai
client = openai.OpenAI()
def stream_chat(prompt, max_retries=3):
partial = ""
for attempt in range(max_retries):
try:
response = client.chat.completions.create(
model="gpt-5.1-mini",
messages=[
{"role": "user", "content": prompt},
# 途中まで生成済みの内容があれば続きから促す
*([{"role": "assistant", "content": partial}] if partial else []),
],
stream=True,
timeout=30, # タイムアウトを明示的に設定
)
for chunk in response:
delta = chunk.choices[0].delta.content or ""
partial += delta
print(delta, end="")
return partial
except (openai.APIConnectionError, openai.APITimeoutError) as e:
wait = 2 ** attempt
print(f"\n[warn] ストリーム中断: {e}. {wait}s後にリトライ ({attempt + 1}/{max_retries})")
time.sleep(wait)
raise RuntimeError("ストリーミングのリトライが上限に達しました")
画像生成 API についても同様に、タイムアウトを明示し、gpt-image-2 のようなレイテンシが変動しやすいモデルでは余裕のある値（例: 60秒以上）を設定することをおすすめします。
image = client.images.generate(
model="gpt-image-2",
prompt="a serene mountain landscape",
timeout=60, # デフォルトより長めに設定
)
まとめ
- 2026年8月2日時点の差分は新機能・料金変更なし、20件のインシデントはすべて解決済み
- 最大の注目点は31コンポーネントに及ぶ全社規模障害が2件連続で発生したこと
-
gpt-5.1-mini/gpt-4.1-miniのストリーミング中断、gpt-image-2のレイテンシ上昇などモデル固有の劣化も報告されている - 画像生成関連の障害が件数として最多（6件）であり、タイムアウト・リトライ設計の見直しに値する
- 今すぐの破壊的変更対応は不要だが、ストリーミングの再接続処理や画像生成APIのタイムアウト設定など予防的なレジリエンス強化を検討する良いタイミング
普段は流し見しがちなステータスページのインシデントですが、こうして俯瞰すると「どのコンポーネントで障害が多いか」「どのモデルが不安定になりやすいか」が見えてきます。本番運用しているサービスがある場合は、一度リトライ・タイムアウト設計を棚卸ししてみることをおすすめします。