［開発者向け］OpenAIがCodexの安全運用手法を公開——サンドボックス・ネットワーク制御・テレメトリの実装例

2026-05-11

はじめに

　OpenAIが2026年5月8日、コーディングエージェント「Codex」を社内で安全に展開するための管理手法を公式ブログで公開しました。本稿では、サンドボックス設定・ネットワークポリシー・認証管理・エージェント専用テレメトリといった各機能の設定方法と、OpenAI社内での運用実態を解説します。

参考記事

タイトル: Running Codex safely at OpenAI
著者: OpenAI Security Team
発行元: OpenAI
発行日: 2026年5月8日
URL: https://openai.com/index/running-codex-safely/

要点

OpenAIはCodexの実行境界をサンドボックスで定め、日常的な低リスク操作は自動承認し、高リスク操作は人間が確認する設計を採用している
ネットワーク接続はホワイトリスト方式で管理し、未登録ドメインへの接続には承認を要する設定が実装されている
認証情報はOSキーリングに保存し、特定のChatGPTワークスペースへのログインを強制することで、組織レベルの権限統制を実現している
prefix_rule によるコマンドルール定義で、一般的な開発コマンドはスムーズに、危険なパターンはブロックまたは承認必須とする運用が可能である
OpenTelemetryを用いたエージェント専用ログにより、ユーザープロンプト・承認決定・ネットワークポリシー判断などをSIEMやコンプライアンス基盤に連携できる

詳細解説

Codexの運用方針：「境界の内側で生産的に」

　Codexは、AIがユーザーに代わってリポジトリ確認・コマンド実行・開発ツールとの連携を行うコーディングエージェントです。こうしたエージェントが開発ワークフローに組み込まれるにあたり、セキュリティチームには「何にアクセスできるか」「いつ人間の承認が必要か」「どのような操作履歴があるか」を把握する手段が求められます。

　OpenAIが採用した基本原則は、限定された環境内で生産的に動作させるという考え方です。日常的な低リスク操作は摩擦なく処理し、高リスク操作には人間のレビューを挟む設計で、セキュリティと開発効率のバランスを取っています。設定はクラウドマネージドの要件ファイル・macOS管理プリファレンス・ローカル要件ファイルの組み合わせで適用され、デスクトップアプリ・CLI・IDE拡張の各Codexサーフェスに一貫して反映されます。

サンドボックスと承認ポリシーの設定

　Codexの実行境界は、サンドボックスと承認ポリシーの組み合わせで管理します。サンドボックスは書き込み可能なパス・ネットワーク接続の可否・保護対象パスを定義する「技術的な実行境界」として機能し、承認ポリシーはサンドボックス外の操作をいつ許可するかを決定します。ユーザーは操作を1回だけ承認するか、そのセッション中の同種操作を一括承認するかを選べます。

　頻繁に発生する低リスクな承認リクエストを自動処理するため、OpenAIは「Auto-review モード」を活用しています。これはCodexが計画中の操作と直近のコンテキストを自動承認サブエージェントに送信し、低リスクと判断された場合にユーザー介入なく処理を続行する仕組みです。高リスクな操作や意図しない副作用が想定される場合は引き続き人間に確認を求めます。

　以下は config.toml（ユーザー設定）と requirements.toml（管理者強制設定）の例です。

# config.toml

# Auto-reviewモードを有効化（低リスク操作を自動承認）
approvals_reviewer = "auto_review"

# 開発ディレクトリをサンドボックスの書き込み可能領域に追加
sandbox_workspace_write.writable_roots = ["~/development"]

# requirements.toml

# サンドボックス内モードのみを許可（サンドボックス外の自由な実行をブロック）
allowed_sandbox_modes = ["read-only", "workspace-write"]

　requirements.toml は管理者が強制する設定ファイルで、ユーザーが上書きできません。allowed_sandbox_modes に read-only と workspace-write のみを指定することで、Codexがサンドボックス外で任意の書き込みを行うことを防ぎます。以前のAgents SDKのサンドボックス対応でも同様の隔離思想が示されていましたが、Codex固有の設定ファイルとして体系化されたのが今回の公開内容です。

ネットワークアクセス制御

　OpenAIはCodexに対してオープンなアウトバウンド通信を許可せず、ホワイトリスト方式のネットワークポリシーを適用しています。既知の正常なワークフローに必要なドメインのみを許可し、接続させたくないドメインはブロック、未知のドメインへの接続は承認を要求する設計です。

# requirements.toml

# ウェブ検索はOpenAIのキャッシュからのみ許可（任意URLへのフェッチを防ぐ）
allowed_web_search_modes = ["cached"]

[experimental_network]
# ネットワークプロキシを有効化
enabled = true

# localhostへの接続を許可（ローカル開発サーバーとの通信用）
allow_local_binding = true

# このドメインへのすべてのリクエストをブロック
denied_domains = ["pastebin.com"]

# これらのドメインへのリクエストを自動許可
allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

　allowed_web_search_modes = [“cached”] の設定により、ウェブ検索をOpenAIのキャッシュ経由に限定できます。これはCodexが外部の任意のURLからコードや設定をフェッチするリスクを抑える観点から有効な設定だと思います。denied_domains と allowed_domains は複数指定が可能で、組織の実態に合わせて調整できます。

　注意: [experimental_network] セクションは実験的機能として提供されており、今後の仕様変更がある可能性があります。

認証情報と権限管理

　Codexの認証情報管理もセキュリティ設計の重要な要素です。OpenAIでは以下の方針を採用しています。

CLI・MCP OAuthの認証情報はOSのキーリング（OSが提供するセキュアなパスワード保管領域）に保存
ログインはChatGPT経由に強制
特定のChatGPTエンタープライズワークスペースへのアクセスを限定

# config.toml

# CLI認証情報をOSキーチェーンに保存（平文ファイルへの保存を防ぐ）
cli_auth_credentials_store = "keyring"

# MCP OAuth認証情報をOSキーチェーンに保存
mcp_oauth_credentials_store = "keyring"

# ChatGPT経由のログインを必須化（他の認証方法をブロック）
forced_login_method = "chatgpt"

# 特定のChatGPTワークスペースへのアクセスを限定（<workspace-uuid>は実際のIDに置換）
forced_chatgpt_workspace_id = "<workspace-uuid>"

　forced_chatgpt_workspace_id を設定することで、Codexの利用がワークスペースレベルの管理下に置かれ、ChatGPTコンプライアンスログプラットフォームでのアクティビティ記録も有効になります。エンタープライズプランを利用している組織では、このログをコンプライアンス監査に活用できます。

コマンドルールの定義

　すべてのシェルコマンドを等しく扱わないために、OpenAIは prefix_rule（プレフィックスルール）を活用しています。日常的な開発コマンドはサンドボックス外でも承認なく許可し、危険なパターンはブロックまたは承認必須とする設定です。

# default.rules
# GitHub CLIでのPR参照（読み取りのみ）を許可
prefix_rule(
   pattern = ["gh", "pr", ["view", "list"]],
   decision = "allow",
   justification = "Allows read-only GitHub PR inspection via gh CLI.",
)

# Kubernetesのリソース参照コマンドを許可（変更系は含まない）
prefix_rule(
   pattern = ["kubectl", ["get", "describe", "logs"]],
   decision = "allow",
   justification = "Allows Kubernetes resource inspection for debugging.",
)

　pattern は [“gh”, “pr”, [“view”, “list”]] のように階層的に記述でき、gh pr view や gh pr list といった複数のサブコマンドをまとめて指定できます。decision に “allow” の代わりに “deny” を指定することで、特定のコマンドパターンを一律ブロックすることも可能です。

　注意: これらのルールはサンドボックス外での動作に適用されます。サンドボックス内では allowed_sandbox_modes の設定が優先されます。

エージェント専用テレメトリと監査ログ

　セキュリティ管理は設定だけでなく、事後の可視性も重要です。従来のセキュリティログは「何が起きたか」（プロセスの起動・ファイル変更・ネットワーク接続）を記録できても、「なぜCodexがその操作をしたか」というエージェント固有の文脈を説明しにくいという課題がありました。

　Codexは OpenTelemetry（OTel、クラウドネイティブ環境で広く使われるオブザーバビリティ標準規格）によるログエクスポートに対応しており、以下のイベントを記録できます。

ユーザープロンプトの内容
ツール承認決定（承認・拒否・自動承認）
ツール実行結果
MCPサーバーの使用状況
ネットワークプロキシの許可・拒否イベント

# config.toml

[otel]

# ユーザーのプロンプトをログに含める（セキュリティ調査時の文脈把握に有効）
log_user_prompt = true

# 環境名（prod/staging/devなどを区別するためのラベル）
environment = "prod"

[otel.exporter.otlp-http]

# OTLPエンドポイント（SIEMやログ収集ツールのURLに置き換える）
endpoint = "http://localhost:14318/v1/logs"

# プロトコル形式（binary / json から選択）
protocol = "binary"

　log_user_prompt = true の設定でユーザーのプロンプトもログに含めることができます。OTLPエンドポイントへのエクスポートにより、SIEM（セキュリティ情報・イベント管理システム）やコンプライアンスロギング基盤への集約が可能です。

　OpenAIでは、このログをAI搭載のセキュリティトリアージエージェントと組み合わせて運用しています。エンドポイントアラートが発火した際に、Codexのログからオリジナルのリクエスト・ツール操作・承認決定・ネットワークポリシー判断を読み取り、「期待通りのエージェント動作」「無害なミス」「本当にエスカレーションが必要な行動」の3種に分類する体制を整えています。同じテレメトリは社内での利用状況の把握（使用頻度・MCPサーバーの活用状況・ネットワーク制御の精度など）にも活用しているとのことです。

　エンタープライズ・教育機関向けには、OpenAI Compliance PlatformからもCodexアクティビティログを取得できます。詳細な設定方法についてはOpenAIの開発者向けドキュメントおよびCompliance APIのドキュメントを参照してください。

まとめ

　今回OpenAIが公開した内容は、Codexを社内で安全に運用するための設定ファイル・ネットワークポリシー・テレメトリ設計の具体的な実践例です。コーディングエージェントの導入を検討するセキュリティチームや開発チームにとって、設定の粒度や監査ログの活用方針を検討するうえで参考になる事例だと思います。Codexの組織展開についてより詳しく知りたい方は、Codex企業展開の解説記事もあわせてご参照ください。