Codexのセキュリティ — サンドボックスの仕組みと、安全に導入するための設定・社内ルール

「Codexは危険？」— 不安の正体は3つに分解できる

Codexは、依頼を受けてファイルの編集やコマンドの実行まで自分で進めるAIエージェントです（基本の仕組みはCodexとはで解説しています）。「チャットAIより踏み込んだことができる」からこそ、セキュリティの不安も具体的になります。整理すると、論点は次の3つです。

1. 1暴走の不安 — 勝手にファイルを消したり、意図しない操作をしたりしないか
2. 2漏洩の不安 — 入力したコードや社内情報が、モデルの学習に使われないか
3. 3攻撃の不安 — インターネット接続を許可したとき、外部から悪意ある指示を仕込まれないか（プロンプトインジェクション）

以下、この3つの順に「Codex側に備わっている仕組み」と「使う側が決めること」を見ていきます。

サンドボックスとは — 暴走を技術的に防ぐ境界線

1つ目の「暴走の不安」に対する答えがサンドボックスです。サンドボックスは、エージェントがPC全体への無制限アクセスを持たずに自律的に働けるようにする「技術的な境界線」で、Codexが実行するコマンドはこの枠の中で動きます。触れる範囲はモードで選べます。

重要なのは、既定の workspace-write でも書き込めるのは指定した作業フォルダの中だけという点です。デスクトップ全体や他のプロジェクトのファイルを勝手に書き換えることはできません。複数のフォルダを扱いたい場合だけ、書き込み可能な範囲を明示的に追加します。

さらに、インターネットへのアクセスは既定で承認が必要です。「気づかないうちに外部と通信していた」という事態が起きない設計になっています。

承認 — 境界線を越えるときは人間が判断する2層目

サンドボックスが「技術的にできることの範囲」だとすると、承認（approval）は「その範囲を越えたいときに人間の許可を求めるルール」です。公式ドキュメントはこの2つを別々の制御として設計しており、既定の設定では次のように動きます。

• 作業フォルダ内の読み書き・コマンド実行 — 自動で進む（いちいち確認されない）
• 作業フォルダの外のファイル編集 — 承認を求められる
• ネットワークアクセスが必要なコマンド — 承認を求められる
• 破壊的な外部ツール（MCP等）の呼び出し — 承認を求められる

つまり既定のCodexは「フォルダの中では自走し、境界を越えるときだけ人間に聞く」バランスで動きます。より慎重にしたい場合は、安全とわかっているコマンド以外すべてに確認を求める設定（untrusted）にもできます。この「どこまで自動を許すか」の感覚は、Codexの始め方で実際に触りながら掴むのが早道です。

「危険な設定」を知っておく — 安全はオフにできてしまう

ここまでの安全装置は、設定で無効化できてしまうことも知っておく必要があります。導入時に社内で「使わない」と決めておくべき設定は2つです。

• danger-full-access — サンドボックスの制限を外すモード。名前のとおり危険で、公式も完全アクセスが本当に必要な場合に限るとしています
• 承認とサンドボックスの同時バイパス — CLIには全確認をスキップして無制限実行するオプションがあり、ヘルプに「EXTREMELY DANGEROUS（極めて危険）」と明記されています。外側に別のサンドボックスがある特殊な自動化環境専用です

また、ネットワークアクセスやWeb検索を許可する場合は、3つ目の不安であるプロンプトインジェクションへの注意が必要です。公式ドキュメントも、信頼できないWebコンテンツに仕込まれた指示をエージェントが取り込んで従ってしまい、コードや機密情報の流出につながりうると明確に警告しています。ネット接続を許可するのは信頼できるリソースに限り、エージェントの成果物をレビューしてから使う、が公式推奨の運用です。

入力したデータは学習に使われるのか

2つ目の「漏洩の不安」の中心は、モデルの学習利用です。2026年7月時点の公式方針では、契約プランによって既定値が異なります。

個人プランでもオプトアウトは可能で、オフにしても会話履歴は残ります。ただし業務データを日常的に扱うなら、設定を個人任せにせず、既定で学習に使われないビジネスプランを選ぶのが組織としては筋の良い選択です。Enterpriseでは保存データの暗号化（AES-256）・通信の暗号化（TLS 1.2以上）・SOC 2 Type 2監査・データ保持期間の管理といった統制もそろっています。プランの選び方はCodexの料金で詳しく解説しています。

クラウド版のセキュリティ — 既定でインターネット遮断

ローカルではなくOpenAIのクラウド環境で実行するWeb版・クラウドタスクにも、同じ思想の安全設計があります。エージェントの作業中のインターネットアクセスは既定でブロックされており、許可する場合も環境ごとに細かく絞れます。

• ドメインの許可リスト — アクセス先を指定ドメインだけに制限できる（開発でよく使うドメインのプリセットあり）
• HTTPメソッドの制限 — 取得系（GET・HEAD・OPTIONS）のみに絞り、外部への送信系リクエストをブロックできる

「クラウドに任せる＝何でも通信できる」ではなく、必要な通信だけを開けていく設計です。社外のクラウドで動くこと自体が心配な場合は、まずローカル実行だけで運用を始め、統制に慣れてからクラウド実行を解禁する段階導入もできます。

社内ルールのつくり方 — 決めるべきは5つだけ

仕組みを踏まえると、組織導入時に決めるべきことは多くありません。当社が伴走先と最初に決めているのは次の5つです。

1. 1プラン — 業務利用はビジネスプラン（既定で学習不使用）を基本とする。個人プラン利用を暫定許可する場合は学習オプトアウトを必須にする
2. 2サンドボックスと承認の標準設定 — 既定（workspace-write＋境界越えは承認）を標準とし、danger-full-access系の設定は禁止と明文化する
3. 3扱ってよいデータの線引き — 顧客の個人情報や認証情報（パスワード・APIキー）は入力しない、といった禁止リストを短く定める
4. 4ネットワーク許可の基準 — ネット接続やWeb検索を使ってよい業務・使うときの確認手順を決める（プロンプトインジェクション対策）
5. 5成果物のレビュー — エージェントの出力は人間がレビューしてから採用する。公式も推奨する基本動作をルールとして明文化する

こうした利用ルールは、ドキュメントとして配るだけでなくAGENTS.mdに書いてCodex自身に守らせることができます（書き方はAGENTS.mdの書き方を参照）。当社のCodex研修・導入伴走支援では、ルール策定を座学で終わらせず、権限設定・AGENTS.md整備・運用定着までを一体でご支援しています。