Codex を安全に走らせる、OpenAI 社内のガードレール大公開！

やっほー、しぃちゃんだよ！ 今日はね、AI コーディングエージェントを「安全に走らせる」ためのお話。ワクワクする新機能とはちょっと毛色が違うけど、エージェントを本気で仕事に組み込むなら避けて通れないテーマだから、しぃちゃん張り切って紹介しちゃうよ！

OpenAI News openai.com

なにが発表されたの？

OpenAI の News で、「Running Codex safely at OpenAI」っていう記事が公開されたの。これは OpenAI 自身が、社内で AI コーディングエージェント Codex をどうやって安全にデプロイしているかを解説したものなんだ。

Codex みたいなエージェントは、リポジトリを自分でレビューしたり、コマンドを実行したり、開発ツールを操作したりできちゃう。今まで人間が手でやってた作業を、エージェントが自律的にこなすようになったってこと。だからこそ、「どこまで触っていいか」「いつ人間の承認が要るか」「あとから何をやったか説明できるか」をちゃんと決めておく必要があるんだよね。

OpenAI が掲げたゴールはシンプルで、エージェントを明確な技術的境界の中に閉じ込めつつ、低リスクな作業はサクサク進めさせて、高リスクな行動だけははっきり止めて確認する。そして「何をしたか」を後から監査できるログを残す。この 4 つなの。

なぜ大事なの？

エージェントが賢くなるほど、ユーザーの代わりに実際の行動を起こす場面が増えていくよね。便利な反面、セキュリティチームからすると「勝手にどこかへ通信されたら？」「危ないコマンドを流されたら？」って不安がいっぱい。

生産性と安全のバランスを取るのって、口で言うほど簡単じゃないの。ガチガチに縛れば誰も使わなくなるし、ゆるゆるだと事故が起きる。OpenAI はこの記事で、「境界の中では生産的に、日常の低リスク操作は摩擦なく、高リスクな操作は立ち止まってレビュー」っていう原則を軸に、その落としどころを見せてくれたんだ。

これで何が変わるの？

いちばん大きいのは、エージェントの安全運用が「気合い」じゃなくて「仕組み」で語れるようになったこと。

サンドボックスで実行範囲を区切って、承認ポリシーで止めどころを決めて、ネットワークは許可制にして、認証は会社のワークスペースに紐づける。そのうえでエージェントならではのログを残す。この一式が揃うと、セキュリティチームは Codex を「使わせない」じゃなくて「安心して使わせる」方向に舵を切れるんだよ。開発者は速く動けて、管理者は見える化と制御を手に入れる。両取りを狙える設計なの。

深く潜ってみよう

原文から拾える具体を、しぃちゃんが噛み砕くね。

サンドボックスと承認 サンドボックスは技術的な実行境界。Codex がどこに書き込めるか、ネットワークに届くか、どのパスを守るかを決めるの。承認ポリシーは「いつ Codex が確認を求めるか」を担当していて、ユーザーは 1 回だけ許可することも、そのセッション中は同じ種類の操作をまとめて許可することもできる。サンドボックスの境界をまたぐリクエストには Auto-review mode を使っていて、これをオンにすると、計画した操作と直近の文脈を自動承認サブエージェントに送って、低リスクな操作（十分な権限があれば高リスクな操作も）を自動で承認してくれる。ユーザーをいちいち止めずに、日常的な作業は進めさせるってわけ。

ネットワークアクセス Codex には無制限の外向き通信をさせないの。管理されたネットワークポリシーで、想定される宛先は許可、行かせたくない宛先はブロック、見知らぬドメインは承認を要求。これで既知の安全なワークフローだけを、広い通信権限を渡さずに回せるんだ。

アイデンティティと認証情報 CLI と MCP の OAuth 認証情報は OS の安全なキーリングに保存。ログインは ChatGPT 経由に強制されて、アクセスは会社の ChatGPT エンタープライズワークスペースにピン留めされる。だから Codex の利用がワークスペースレベルの管理下に入って、活動が Compliance ログに残るの。

ルール すべてのシェルコマンドを同じ「安全」として扱わないための仕組み。日常開発でよく使う無害なコマンドはサンドボックス外でも承認なしで実行できて、特定の危険なコマンドはブロックしたり承認を要求したりできる。

管理されたコンフィグ この構えは、クラウド管理の requirements、macOS の管理プレファレンス、ローカルの requirements ファイルの組み合わせで適用されるの。requirements は管理者が強制するコントロールで、ユーザーは上書きできない。設定はデスクトップアプリ・CLI・IDE 拡張にまたがって効くよ。もっと詳しい設定方法は Codex の設定ガイド にまとまってるんだって。

エージェントネイティブなテレメトリ コントロールは仕事の半分。デプロイした後は「エージェントが何を、なぜやったか」の可視性が要るよね。従来のセキュリティログは「何が起きたか」は分かるけど「なぜやったか」は分からない。Codex は OpenTelemetry でのログエクスポートに対応していて、ユーザーのプロンプト、ツール承認の判断、ツール実行の結果、MCP サーバーの利用、ネットワークプロキシの許可・拒否イベントなんかを出せるの。ログは Enterprise と Edu 向けの OpenAI Compliance Platform からも見られるよ。

しかも OpenAI は、このログを AI 駆動のセキュリティトリアージエージェントと組み合わせてるの。エンドポイントの警告が「Codex が何か変なことをした」って言ってきたら、Codex のログが元のリクエストやツールの動き、承認の判断、ネットワークポリシーの結果まで遡って、その意図を説明してくれる。トリアージエージェントが分析をまとめてセキュリティチームに渡し、「想定内の挙動」「悪意のないミス」「本当にエスカレーションすべき活動」を切り分けるんだ。同じログは、社内での採用状況や、サンドボックスがどれくらいブロック・確認をしているかの把握にも使えて、SIEM やコンプライアンス基盤に集約できるよ。

まとめ

• Codex を安全に運用するための OpenAI 社内の考え方が、OpenAI の News で公開されたよ
• 原則は「境界の中では生産的に、低リスクは摩擦なく、高リスクは止めてレビュー」
• サンドボックス＋承認、Auto-review mode、ネットワーク許可制、OS キーリング、コマンドのルール、管理されたコンフィグで制御する
• OpenTelemetry ログと AI セキュリティトリアージで「何を・なぜ」やったかを監査できる
• ログは SIEM やコンプライアンス基盤に集約可能

刺さるのは、AI エージェントを社内に本格導入したいセキュリティチームや、Codex みたいなコーディングエージェントの管理を任される DevOps・プラットフォーム担当さん。「エージェントは怖いから禁止」から「仕組みで安全に使わせる」へ進みたい人には、いい設計図になりそうだよ！