何が発表されたのか
OpenAIは、同社のAIモデル「Codex」をベースにした自律型開発エージェントによる、本番環境の監視（プロダクションモニタリング）および障害自動復旧のデモを公開しました。本発表は、開発者が深夜のシステム障害対応から解放される未来を示す、実用的なプロトタイプの提示です。
登壇したトニー・レール（Tony Loehr）氏とアンケ・ハオ（Anke Hao）氏は、実際の開発現場で頻発する3つの障害シナリオを用意し、Codexがシステムテレメトリ、ソースコード、デプロイ履歴を横断して分析する様子を実演しました。本機能は現在、研究・実験段階にあり、将来的な一般提供（GA）を見据えたプレビュー位置づけとなっています。
発表された機能・アップデートの全容
Grafana連携によるチェックアウトエラーの自動特定と修正
最初のデモでは、本番環境で稼働するWebサービスのチェックアウト機能において、新バージョン（v2）のデプロイ直後にエラー率が急増するシナリオが実演されました。
画面左側にはGrafanaのダッシュボードが表示されており、チェックアウトのヘルスステータスが緑色の「HEALTHY」から赤色の「DOWN」へ切り替わります。エラー率は約20%に達し、P95遅延も急上昇している状態です。
ここで、画面右側のCodexのコンソールから、調査用コマンドを実行します。Codexは、過去10分間のローカルチェックアウトの証拠（evidence）を収集する自律タスクを開始しました。
Codexは以下の手順を自律的に実行します。
- 直近のデプロイ（v1からv2への変更）におけるコードの差分（diff）を自動で抽出します。
- 該当するエラーログとソースコードの因果関係を分析し、エラーの原因となっているコード行を特定します。
- 問題を修正するためのパッチ（修正コード）を自動生成します。
- バックグラウンドでテストスイートを実行し、修正パッチが既存のテストを通過することを確認します。
解析完了後、Codexの画面上に「PATCH READY（パッチ準備完了）」のステータスと修正内容が表示されます。開発者が「APPROVE（承認）」ボタンをクリックすると、パッチが自動的に本番環境へ適用されました。Grafana上のエラー率は即座に0%に低下し、システムは健全な状態に戻りました。
Kubernetes連携によるOOMKilled障害の自律的ロールバック・修正
2つ目のデモでは、Kubernetesクラスタ上で稼働する「Northstar」と呼ばれるマイクロサービスアプリケーションの障害が扱われました。このアプリは、edge-gateway、orders-api、inventory-apiの3つのサービスで構成されています。
開発者が「inventory-api」の新しいコンテナイメージをロールアウトしたところ、CI/CDパイプラインは通過したものの、本番デプロイ後にコンテナがOOMKilled（メモリ不足による強制終了）を繰り返す現象が発生しました。これにより、連鎖的に他のサービスもダウンし、クラスタ全体が機能不全に陥ります。
ここで開発者は、Codexの「kubernetes-rollout-investigator」と呼ばれる専用スキルを起動します。Codexは即座にKubernetesのイベントログとマニフェストファイルをスキャンし、コンテナのメモリ制限設定と実際の消費メモリの推移を比較分析しました。
Codexは、新バージョンで追加されたメモリ消費の多い処理に対して、割り当てメモリ制限（limits）が過小に設定されていることを突き止めました。AIはメモリ割り当てを適切に拡張するパッチを生成し、ローカル環境での検証を経て、開発者に承認を求めます。開発者が承認すると、安全にKubernetesのローカルロールアウトが実行され、クラスタ全体のサービスが正常に復旧しました。
Codex Securityによるリソース制限不足に起因する遅延の解決
3つ目のデモでは、コードの変更（デプロイ）が一切行われていないにもかかわらず、システムのパフォーマンスが低下するシナリオが実演されました。
チェックアウトのレスポンスタイムが極端に遅延している原因を調査するため、Codexのセキュリティ監査プラグイン「Codex Security」が使用されました。スキャンの結果、特定の認証済みユーザーが、共有ワーカープールに対して300万行に及ぶ巨大なCSVデータのエクスポート要求を送信していることが判明しました。
このシステムにはリソース境界（resource boundary）が設定されておらず、単一の重いリクエストがスレッドを占有し、一般ユーザーのチェックアウト処理をストリープ（枯渇）させていたことが原因です。
Codexは、この「リソース制限の欠如」をセキュリティ上の脆弱性と判断し、以下の制限コードを自動生成しました。
- 最大エクスポート行数の制限（
maxRows: 100,000） - 同一ユーザー（Principal）あたりの同時実行レポート数の制限（
maxReportsPerPrincipal: 1）
開発者がこの「アプリケーションアップデート」を承認すると、システムは不正な巨大リクエストに対して自動的に「HTTP 422（Unprocessable Entity）」を返してブロックするようになります。これにより、一般ユーザーのチェックアウト処理速度は2.1msという極めて高速な水準に回復しました。
