2026年5月8日

OpenAI における Codex の安全な運用

実際の開発ワークフローでコーディングエージェントを安全に運用するために、OpenAI が採用している制御機能、運用上の境界、テレメトリーを紹介します。

読み込んでいます...

AI システムの能力向上に伴い、ユーザーに代わってタスクを実行する場面が増えています。コーディングエージェントは、リポジトリのレビュー、コマンドの実行、開発ツールとの連携などを自律的に行えます。こうした作業は、これまで人が直接対応する必要がありました。

Codex では、こうした機能に加え、安全に導入するために組織が必要とする制御機能もあわせて提供しています。セキュリティチームには、エージェントの動作を管理する仕組みが必要です。たとえば、どのリソースにアクセスできるか、どのタイミングで人による承認を求めるか、どのシステムと連携できるか、そしてその動作を説明するためにどのようなテレメトリーを取得するか、といった点です。

OpenAI では、いくつかの明確な方針のもとで Codex を運用しています。エージェントの動作範囲を技術的に明確な境界内に制限すること、低リスクな操作は開発者が迅速に進められるようにすること、そして高リスクな操作は必ず明示的に確認できるようにすることです。また、エージェント固有のテレメトリーを保持することで、エージェントが実行した内容を把握し、監査できるようにしています。具体的には、構成管理、制限付き実行、ネットワークポリシー、エージェント固有ログなどを組み合わせています。

Codex の動作管理

Codex の運用では、制限された環境内で安全に活用できること、日常的な低リスク操作はできるだけ妨げずに実行できること、高リスクな操作ではレビューを必須にすることを基本方針としています。

サンドボックス化と承認

承認とサンドボックス化は連携して機能します。サンドボックスは技術的な実行範囲を定義するもので、Codex がどこに書き込めるか、ネットワークにアクセスできるか、どのパスを保護対象として維持するかなどを制御します。承認ポリシーは、Codex がいつユーザーに実行許可を求めるかを定義します。たとえば、サンドボックス外で操作を行う必要がある場合です。ユーザーは、その操作を一度だけ承認することも、そのセッション中は同種の操作を承認することもできます。

サンドボックスの境界を越えるリクエストについては、自動レビューモード⁠（新しいウィンドウで開く）を利用しています。この機能を有効にすると、特定種類のリクエストを自動承認できるため、ユーザーが都度作業を中断して Codex の操作を承認する必要を減らせます。Codex は、実行予定の操作と直近のコンテキストを自動承認サブエージェントに送信します。これにより、低リスクな操作や、十分なユーザー承認がある高リスクな操作については、ユーザーに確認を求めることなく自動承認できます。その結果、定型的な作業は止めずに進めつつ、高リスクな操作や意図しない影響を及ぼす可能性がある操作では停止して確認を行えます。

TOML

1# config.toml
2
3# Turn on auto_review
4approvals_reviewer = "auto_review" 
5# Add known development directories to the sandbox automatically
6sandbox_workspace_write.writable_roots = ["~/development"] 
7
8# requirements.toml
9
10# Require Codex to operate inside the sandbox
11allowed_sandbox_modes = ["read-only", "workspace-write"]

ネットワークアクセス

Codex に無制限の外向きネットワークアクセスは許可していません。管理対象のネットワークポリシーによって、想定された宛先へのアクセスは許可し、Codex にアクセスさせたくない宛先はブロックし、不明なドメインについては承認を必須にしています。これにより、広範なネットワークアクセスを与えることなく、一般的で安全性が確認されたワークフローを実行できます。

TOML

1# requirements.toml
2
3# Ensure web fetch only comes from OpenAI's cache
4allowed_web_search_modes = ["cached"] 
5
6[experimental_network]
7# Turn on Network Proxy
8enabled = true
9# Allow Codex to interact with localhost
10allow_local_binding = true 
11# Block all requests to this domain
12denied_domains = ["pastebin.com"] 
13# Auto-allow requests to these domains
14allowed_domains = ["login.microsoftonline.com", "*.openai.com"]

ID と認証情報

Codex の認証方法についても管理しています。CLI と MCP の OAuth 認証情報は安全な OS キーリングに保存され、ログインは ChatGPT 経由に限定されます。また、アクセスは当社の ChatGPT Enterprise ワークスペースに紐付けられています。これにより、Codex の利用をワークスペースレベルで管理できるほか、Codex のアクティビティを ChatGPT Compliance Logs Platform 上で確認できます。

TOML

1# config.toml
2
3# Store CLI Auth Creds in OS Keychain
4cli_auth_credentials_store = "keyring"           
5# Store MCP Creds in OS Keychain
6mcp_oauth_credentials_store = "keyring"          
7# Require Auth via ChatGPT
8forced_login_method = "chatgpt"                  
9# Require Auth to Specific ChatGPT Workspace
10forced_chatgpt_workspace_id = "<workspace-uuid>"

ルール

Codex がすべてのシェルコマンドを同じリスクレベルとして扱わないよう、ルールを設定しています。エンジニアが日常的な開発で使用する一般的で安全なコマンドは、サンドボックス外でも承認なしで実行できます。一方、危険性の高いコマンドについては、ブロックしたり承認を必須にしたりできます。これにより、通常の開発作業は迅速に進めつつ、サンドボックス外で実行したくない操作についてはレビューやブロックを適用できます。

Starlark

1# default.rules
2
3prefix_rule(
4    pattern = ["gh", "pr", ["view", "list"]],
5    decision = "allow",
6    justification = "Allows read-only GitHub PR inspection via gh CLI.",
7)
8prefix_rule(
9    pattern = ["kubectl", ["get", "describe", "logs"]],
10    decision = "allow",
11    justification = "Allows Kubernetes resource inspection for debugging.",
12)

管理構成

この運用方針は、クラウド管理の要件、macOS の管理対象設定、ローカル要件ファイルを組み合わせて適用しています。要件とは、ユーザーが変更できない管理者側の制御設定です。macOS の管理対象設定とローカル要件ファイルを利用することで、一貫したベースラインを維持しながら、チーム、ユーザーグループ、環境ごとに異なる構成を検証できます。これらの設定は、デスクトップアプリ、CLI、IDE 拡張機能を含むローカルの Codex 環境全体に適用されます。

エージェント固有のテレメトリーと監査証跡

制御だけでは十分ではありません。エージェントを導入した後は、それらが何を行っているのか、そしてなぜその操作を行ったのかを把握できる可視性が必要になります。従来のセキュリティログも、Codex の操作内容を確認するうえでは有用ですが、多くの場合、「何が起きたか」を示すものにとどまります。たとえば、プロセスの開始、ファイル変更、ネットワーク接続の試行などです。一方で、Codex がなぜその操作を行ったのか、あるいはユーザーの意図が何だったのかについては、別途判断する必要があります。

Codex は、セキュリティチームに対して、エージェントの動作をより把握しやすい視点を提供できます。Codex は、ユーザープロンプト、ツール承認の判断、ツール実行結果、MCP サーバーの利用状況、ネットワークプロキシの許可・拒否イベントなど、さまざまな Codex イベントについて OpenTelemetry ログのエクスポートをサポートしています。Codex のアクティビティログは、Enterprise および Edu のお客様向け OpenAI Compliance Platform からも利用できます。

TOML

1# config.toml
2
3[otel]
4log_user_prompt = true
5environment = "prod"
6
7[otel.exporter.otlp-http]
8endpoint = "http://localhost:14318/v1/logs"
9protocol = "binary"

OpenAI では、AI 搭載のセキュリティトリアージエージェントとあわせて Codex ログを活用しています。エンドポイントアラートによって Codex の異常な操作が検知された場合、エンドポイントセキュリティツールは不審なイベントが発生したことを通知します。その後、Codex ログを参照することで、ユーザーやエージェントがどのような意図で操作を行ったのかを把握できます。AI セキュリティトリアージエージェントは、元のリクエスト、ツールのアクティビティ、承認判断、ツール実行結果、関連するネットワークポリシーの判断やブロック内容を Codex ログから確認します。そして、その分析結果をセキュリティチームに提示することで、想定どおりのエージェント動作、無害なミス、本当にエスカレーションが必要なアクティビティを見分けられるようにしています。

同じテレメトリーは、運用面でも活用しています。これらのログを使って、社内での導入状況がどのように変化しているか、どのツールや MCP サーバーが利用されているか、ネットワークサンドボックスがどの程度ブロックや確認要求を発生させているか、そしてロールアウトのどこに調整が必要かを把握しています。これらの OpenTelemetry ログは、SIEM やコンプライアンスロギングシステムに集約できます。

今後の取り組み

Codex のようなコーディングエージェントが開発ワークフローに統合されるにつれて、セキュリティチームには、この変化を管理するために設計された専用ツールが必要になります。Codex は、安全な導入に必要な制御機能、構成管理、サンドボックス化、そして詳細なエージェント対応テレメトリーを提供します。こうした機能により、セキュリティチームは、開発者の生産性と、エンタープライズセキュリティに必要な可視性・制御のバランスを取りながら、より安心して Codex を導入できます。Codex の構成に関する詳細はこちら⁠（新しいウィンドウで開く）、Compliance API に関する詳細はこちら⁠（新しいウィンドウで開く）をご覧ください。

著者

OpenAI

さらに読む

すべてを表示

グローバルリーダーシップによる若者の安全と機会の推進

グローバルアフェアーズ2026年6月2日

信頼できる第三者評価のための共通プレイブック

安全性2026年5月29日

Frontier Governance Framework > card image

OpenAI の Frontier Governance Framework

安全性2026年5月28日