CodexのGitHub障害は復旧済み Web版とプルリクエストレビューで失敗・遅延
CodexとGitHubの復旧状況を2つの公式ページで確認するだけで、不要な再設定や二重実行を避けやすくなります。
レビューが止まった時、どこから安全に戻せばよいか気になりませんか？
2026年7月20日、GitHubに依存するChatGPTとCodexのワークフローで、エラー増加が記録されました。
OpenAIが特に挙げたのは、Codex WebとGitHub上のプルリクエストレビューで起きた失敗や遅延です。
OpenAI側は同日12時34分、GitHub側は13時44分に復旧を発表済みです。
ただし、失敗したレビューが自動で再実行されたとは確認できないため、状態を見ずに一括再実行しないでください。直近の別事例は、Codexアクセス拒否障害の解説で確認できます。
結論復旧確認はOpenAIとGitHubの両方を見る
双方がResolvedか確認し、未完了runと既存レビューを見てから1件ずつ再開します。複数のリポジトリで同時に失敗している間は、連携解除や権限変更を急がないのが安全です。
Codex GitHub障害は復旧済み｜公式時系列
OpenAIが確認したCodex GitHub障害は、日本時間9時34分の調査開始から12時34分の復旧まで約3時間でした。
一方、関連するGitHub側のインシデントは8時34分から13時44分までで、サービスごとの復旧時刻は一致していません。
| 日本時間 | サービス | 公式更新 |
|---|---|---|
| 8:34 | GitHub | 関連インシデント開始 |
| 9:34 | OpenAI | エラー増加を調査 |
| 12:25 | OpenAI | 回復監視へ移行 |
| 12:34 | OpenAI | 完全復旧 |
| 13:43 | GitHub | Actions完全回復 |
| 13:44 | GitHub | インシデント解消 |
この表は各社の公式更新時刻を並べたもので、個々の利用者に同じ時間だけ影響したという意味ではありません。
社内共有では「Codexが全面停止した」と広げず、GitHub依存ワークフローで障害が起きたと記録するのが正確でしょう。
出典: OpenAI Status「Elevated errors for GitHub-dependent ChatGPT and Codex workflows」(英語)
出典: GitHub Status「Incident with GitHub Actions」(英語)
別のCodex障害と混同しないためには、Codex 5.6 Sol障害の公式時系列のように、インシデント単位で対象機能と時刻を分けると整理しやすくなります。
Codex GitHub障害で何が起きたか
OpenAIは、影響の中心をCodex WebとGitHub上のPRコードレビューと説明しました。
関連先のGitHubでは、APIの部分障害に加え、新規Actionsワークフローの開始遅延や失敗、進行中runの失敗が起こり得る状態でした。
公式に分かること
主にCodex WebとPRレビュー
GitHub APIの部分障害
Actionsの遅延と失敗
公式にないこと
具体的な根本原因
利用者数と失敗率
全タスクの自動再処理
注意「主に」を「それ以外は無影響」と読まない
公式発表は影響の中心を示したもので、デスクトップ版やCLIが完全に無影響だったとは明記していません。未確認の非影響範囲を断定しないでください。
根本原因の詳細も、2026年7月21日の確認時点では未公表です。
GitHubは詳しいRCAを後日共有すると案内しており、具体原因は公式発表待ちとして扱います。
Codex WebとPRレビューで影響が出る仕組み
CodexのGitHubコードレビューは、Codex cloudを対象リポジトリに設定し、GitHub上へレビューを投稿する機能です。
手動レビューはPRのコメントで@codex reviewと依頼でき、自動レビューを有効にする運用もあります。
出典: OpenAI公式「Codex code review in GitHub」(英語)
Codex cloudの作業とレビューはGitHubリポジトリへの接続を前提とするため、GitHub側のAPIやActionsが不安定になると関連ワークフローへ波及します。
ただし、AIレビューとCIは別の確認工程であり、レビューが戻ってもActionsのテストが未完了ならマージ判断は止めます。
GitHub連携の不調をサービス障害と自社設定に分ける考え方は、ClaudeとGitHub連携の失敗原因にも共通します。複数リポジトリで同時発生したかが、最初の切り分け材料です。
Codex GitHub障害の復旧後に確認する3点
復旧後は、つながるかではなく、どこまで処理済みかを確かめます。
レビュー、コメント、Actionsのrunが途中まで進んでいる可能性があり、同じ依頼をまとめて送り直すと重複確認が増えるためです。
双方確認
Statusを見る
→
重複確認
runとレビュー
→
順次再開
1件ずつ試す
設定変更は単一PRだけに問題が残る時に検討する
- OpenAI StatusとGitHub Statusが双方ともResolvedか
- 対象PRに未完了run、既存レビュー、重複コメントがないか
- Actionsの必須チェックと人のレビューが完了しているか
- 単一PRだけならCodex cloudの対象リポジトリが正しいか
- Code reviewの有効化、
@codex review、GitHub権限に変更がないか
両StatusがResolvedで、単一リポジトリや単一PRだけ失敗するなら設定確認へ進みます。
普段の使い方から見直す場合は、仕事でのCodex活用と安全な進め方も参考になります。
業務を止めない平時の運用
障害中でも、GitHub Actionsやクラウドレビューを必要としないローカル作業なら続けられる場合があります。
ただし、リポジトリが手元にあり、外部送信やマージを伴わない作業に限って切り替えます。
平時の準備停止条件と再開担当を1枚にまとめる
公式確認担当、影響したリポジトリ、止める処理、続けられるローカル作業、再開の承認者を決めます。AIレビュー、CI、人の承認を一つの合否にまとめないことが大切です。
代替ツールを用意する場合も、機密情報を別サービスへ移す判断は障害対応と分けます。
AIコーディングツールの比較を参考に、平時に扱えるデータと承認手順を決めておくと、停止中に慌てて環境を変えずに済むでしょう。
よくある質問
QCodexのGitHub障害は復旧していますか？
Aはい。OpenAIは2026年7月20日12時34分JSTに完全復旧を発表し、GitHub側も同日13時44分JSTに関連インシデントを解消しました。
QCodexのどの機能に影響が出ましたか？
AOpenAIは、主にCodex WebとGitHub上のプルリクエストコードレビューで失敗や遅延が起きたと説明しました。
QCodexデスクトップ版やCLIも止まっていましたか？
A公式発表は影響の中心をCodex WebとPRレビューとしていますが、デスクトップ版やCLIが完全に無影響だったとは明記していません。
Q復旧後もPRレビューが動かない時は何を確認しますか？
A双方のStatusを確認したうえで、Codex cloudの対象リポジトリ、Code reviewの有効化、正確な@codex review、GitHub側の権限を確認します。
Q障害中にGitHub連携を解除して再設定すべきですか？
A複数リポジトリで同時に失敗し、公式Statusに障害が出ている間は復旧待ちを優先します。復旧後も単一リポジトリだけで問題が続く場合に設定を確認してください。
