AI開発更新メモ
Codexで「Selected Model is at Capacity」エラー、AI開発ツールは障害前提で使う
2026年6月16日にOpenAI Codexで発生した「Selected Model is at Capacity」エラーとCodex Cloud tasksの障害について、公式ステータスを主な根拠に復旧状況と個人開発者の備えを整理します。
公開 2026.06.17 / 更新 2026.06.17 / 情報確認 2026.06.17 / 7分
#Codex #OpenAI #障害 #AI開発ツール #運用
この記事のポイント
- OpenAI StatusでCodexの「Selected Model is at Capacity」エラーはResolvedと確認できる
- 同日、Codex Cloud tasksについても別の障害ステータスがResolvedになっている
- 個人開発では、障害時に作業ログ、差分、代替モデル、手動確認へ戻れる運用が重要
2026年6月16日、OpenAI StatusにCodex関連の障害が複数掲載されました。ひとつはCodexで「Selected Model is at Capacity」エラーが出る障害、もうひとつはCodex Cloud tasksに関する障害です。どちらもステータスはResolvedで、公式ページ上では影響サービスが復旧したと説明されています。
このメモでは、利用者のSNS反応や報道ではなく、OpenAI Statusで確認できる範囲を主軸に扱います。報道は、利用者側でどのような体験があったかを知る補助情報として読みます。
何が起きたか
OpenAI Statusの「Codex "Selected Model is at Capacity" Error」では、2026年6月16日にCodexでdegraded performanceが発生し、影響サービスが復旧したことが記録されています。ステータスページでは、10:32 AMにelevated errorsを確認、01:32 PMにmitigationを適用して監視、01:48 PMに fully recovered とされています。
同じ日に「Users may experience issue with Codex Cloud tasks」も掲載されました。こちらもCodexがaffected componentとして示され、12:07 AMに調査開始、12:55 AMに復旧とされています。つまり、同日にCodexまわりで複数の不安定要素があったと見てよい状況です。
個人開発者が見るべきポイント
- エラーが出たら、まず公式ステータスと自分の作業ログを分けて確認する
- 長い作業は小さく区切り、途中の差分と判断理由を残しておく
- モデル切り替えや手動作業へ戻れるように、依存しすぎない手順にする
- 本番反映、push、deploy、秘密情報を扱う作業は、障害中に急いで進めない
AI開発ツールは障害前提で使う
Codex、Claude Code、CursorのようなAI開発ツールは、作業速度を上げてくれます。一方で、クラウド側の混雑、モデル提供状況、権限、ワークスペース設定、ネットワークに依存します。止まったときに何を失うかを小さくしておくことが、実務ではかなり大事です。
| 備え | 実務での意味 |
|---|---|
| 小さく依頼する | 途中で止まっても、どこまで終わったか追いやすい |
| 差分を確認する | AIの途中作業や失敗をそのまま取り込まない |
| 代替手順を用意する | 別モデル、手動修正、通常のエディタ作業へ戻れる |
| 本番操作を分ける | 障害中の焦りでpushやdeployを誤らない |
よくある質問
この障害は復旧していますか?
OpenAI Statusでは、2026年6月16日のCodex関連インシデントはいずれもResolvedになっています。ただし、個別環境で同じ体感になるとは限らないため、利用前に公式ステータスと自分の画面を確認してください。
「Selected Model is at Capacity」は自分の設定ミスですか?
今回の公式ステータスではCodex側のdegraded performanceとして扱われています。ただし、別の日や別の環境では、モデル選択、プラン、ワークスペース設定が関係する可能性もあります。
障害時に別のAI開発ツールへ切り替えるべきですか?
短期的な回避策としては有効ですが、どのAI開発ツールにも障害や制限はあります。ツール変更より先に、差分確認、作業分割、手動復旧できる運用を整える方が再現性があります。