Codex を社内導入したいが、権限が強すぎて怖い、承認フローをどこまで入れるべきか分からない。そんな CTO・VPoE・情シス向けに、2026年7月時点の OpenAI 公式ドキュメントを基に、権限分離・承認・監査の現実的な実装チェックリストを整理します。公式 docs では、Codex はデフォルトでネットワークアクセスがオフで、sandbox と approval policy の二層で安全制御する考え方が明確です。
なぜ最初に権限分離を設計すべきか
OpenAI の Agent approvals & security では、Codex の安全制御は sandbox mode と approval policy の二層で成り立つと説明されています。sandbox は『技術的に何ができるか』、approval policy は『どこで止めて確認するか』を分担するため、まず技術境界を狭くし、そのうえで例外だけ承認させる設計が基本です。
ローカル実行では、Codex は通常 current workspace に限定された OS レベル sandbox で動き、ネットワークも初期状態では無効です。この前提があるからこそ、閲覧専用、workspace-write、限定ネットワーク許可のような権限プロファイルを部門ごとに配り分けやすくなります。
承認フローは『全部手動』ではなく例外承認に寄せる
公式 docs では Auto preset の例として `--sandbox workspace-write --ask-for-approval on-request` が示されており、通常の読み書きは自動で進めつつ、workspace 外編集やネットワーク利用だけ承認対象にする運用が想定されています。全部を毎回手動承認にすると速度が落ち、逆に full access 前提にすると監督不能になります。
企業導入では、依存関係の追加、外部送信、本番ブランチ反映、破壊的 MCP / app tool 呼び出しを例外承認へ寄せ、それ以外は標準化された sandbox で流すのが現実的です。
AI コーディング運用の承認境界や開発ルールを短期間で整えたい場合は、お問い合わせフォームからご相談ください。
監査ログで最低限残すべき5項目
2026年の Codex docs では、OTel を有効にすると API request、SSE/WebSocket event、user prompt、tool decision、tool result などの structured log を出せます。特に `codex.tool_decision` では approved/denied と、その判断が config 由来か user 由来かまで追えます。
社内監査で最低限残したいのは、実行者、対象リポジトリ、sandbox / approval 設定、誰が承認したか、結果どうなったかの5項目です。Codex 側のイベントを SIEM や OTel collector に寄せると、『誰が何を通したのか分からない』状態を減らせます。
PoCではクラウド実行とローカル実行を分けて考える
公式 docs によれば、Codex cloud は OpenAI 管理の隔離コンテナで動き、setup phase だけネットワークを使って依存関係を入れ、その後の agent phase はデフォルトで offline です。さらに cloud secrets は setup phase のみ利用可能で、agent phase 前に除去されます。
一方、CLI / IDE extension は開発者マシン側で動くため、どのパスを読ませるか、どのドメインへ通信させるかのローカル統制がより重要です。PoC は cloud、広い展開は権限テンプレート確立後に進める方が安全です。
秘密情報とGit運用の境界を先に決める
Codex の sandboxing docs では、workspace-write でもネットワークは既定でオフで、必要なら `sandbox_workspace_write.network_access=true` を明示して有効化する設計です。network_proxy を使えばドメイン単位の allow/deny 制御もできます。
この考え方を社内運用に落とすなら、『コードは触れてよいが .env や証明書は見せない』『feature branch は許可するが main 反映は人間承認』『ネットワークは allowlist のみ』という境界を先に決めるべきです。
2026年の導入チェックリスト
実装チェックリストは5つです。1) 初期は workspace-write か read-only から始める。2) ネットワークは必要なドメインだけ allowlist 化する。3) secrets、顧客データ、main 反映導線を承認対象へ分ける。4) OTel で tool decision / tool result を含む実行ログを収集する。5) PoC の時点で依存追加・外部送信・大規模差分の承認訓練を行う。
よくある質問：フル自動化はいつ許可すべきか
本番系で最初から danger-full-access を許可するのは避けるべきです。公式 docs でも、そのモードは trusted repository 前提で慎重に使うよう警告されています。まずは read-only と workspace-write を使い分け、承認・拒否・失敗ログが十分に溜まってから、一部の定型ジョブだけ段階的に自動化する方が現実的です。
