Codexのセキュリティを徹底解説！承認・サンドボックスの安全設定を紹介

中島大介（なかじ）公開日: 2026年9月17日最終更新: 2026年10月31日読了時間約20分

Codexは、AIがファイルの書き換えやコマンドの実行まで進めるコーディングエージェントです。便利さの一方で、会社のコードや顧客情報があるパソコンで動かすとなると、勝手な操作や情報漏洩への備えを確認せずには導入できません。

しかも検索結果には「Codex Security」という別機能の解説も混ざるため、知りたい情報にたどり着きにくい状況です。

本記事では、Codex本体を安全に使うための仕組みと設定を、OpenAIの公式ドキュメントに基づいて解説します。

この記事を読めば、自分の使い方に合うCodexの安全設定の組み合わせを判断できます。結論から言うと、Codexは標準でもサンドボックスと承認の二層で守られており、ネットワークはオフから始まる設計です。

Codexのセキュリティの全体像
サンドボックスモードでCodexの権限の範囲を決める【sandbox_mode】
承認ポリシーでCodexの確認のタイミングを決める【approval_policy】
情報漏洩を防ぐCodexのセキュリティ設定と考え方
config.tomlでCodexのセキュリティ設定を固定する
Codexのセキュリティに関するよくある質問
まとめ
参考リンク

Codexのセキュリティの全体像

Codexのセキュリティを調べるときは、まず別製品との違いと、安全を守る仕組みの大枠を押さえておく必要があります。全体像が分かると、本記事で紹介する設定が二層のどちらの話なのかを判断しやすくなります。Codexのセキュリティの全体像として押さえたい前提は、以下の2つです。

「使う側の安全設定」と「Codex Security」を切り分ける
Codexの安全設計はサンドボックスと承認の二層でできている

「使う側の安全設定」と「Codex Security」を切り分ける

Codexのセキュリティを検索すると「Codex Security」の名前が付いた別機能の解説記事が混ざって表示されます。OpenAIの公式ドキュメントによると、Codex Securityは、コードの脆弱性を発見・確認・修正するために作られたアプリケーションセキュリティ専門のエージェントです。Codex Securityの提供形態は、以下のとおりです。

ChatGPTアプリのプラグイン
CLIとSDK
GitHub連携のクラウド版(リサーチプレビュー段階)

名前は似ていますが、本記事で扱うのは、Codex本体を日々の作業で安全に使うための設定の話です。自分が知りたいのがどちらなのかを最初に切り分けると、情報収集の迷子を避けられます。Codex自体の概要から知りたい場合は、Codexとは何かを解説した記事から読むのがおすすめです。

Codexとは？読み方や旧モデルとの違い・できることまで徹底解説！

Codexの安全設計はサンドボックスと承認の二層でできている

OpenAIの公式ドキュメントは、Codexのセキュリティ制御を「連携して働く2つの層」と説明しています。1つ目はサンドボックスで、AIが技術的に何をできるかをOSレベルの仕組みで制限する層です。2つ目は承認ポリシーで、制限の外に出る操作の前にユーザーへ確認するかどうかを決めます。

サンドボックスが「できる範囲」、承認ポリシーが「確認のタイミング」を受け持つ役割分担です。2つは別々に設定でき、組み合わせ方で安全度と作業の速さのバランスを調整します。

サンドボックスモードでCodexの権限の範囲を決める【sandbox_mode】

サンドボックスモードは、二層のうち、Codexが技術的に何をできるかを決める層です。モードによって承認なしで進められる操作の範囲が変わるため、作業の内容に合わせて選ぶ必要があります。Codexの権限の範囲を決めるサンドボックスモードは、以下の3種類です。

read-onlyは読み取り専用で最も安全なモード
workspace-writeは作業フォルダ内だけ書き込めるモード
danger-full-accessはOpenAIが非推奨とする全開放のモード

read-onlyは読み取り専用で最も安全なモード

read-onlyは、ファイルの読み取りと質問への回答だけを許すモードです。ファイルの編集、コマンドの実行、ネットワークアクセスにはすべて承認が必要になります。

コードの調査や説明を頼む使い方なら、read-onlyで十分に実用的です。OpenAIの公式ドキュメントでは、バージョン管理されていないフォルダで作業する場合の推奨としても挙げられています。まず様子を見たい導入初期に向いたモードです。

workspace-writeは作業フォルダ内だけ書き込めるモード

workspace-writeは、作業中のワークスペース内に限ってファイルの読み書きと通常のコマンド実行を許すモードです。ワークスペースの外への書き込みと、ネットワークアクセスには承認が求められます。

Codexのサンドボックスの実装に使われるOSの仕組みは、以下のとおりです。

macOS：Seatbelt
LinuxとWSL2：bubblewrap
Windows：WSLを使わないネイティブのサンドボックス

どのOSでもOSの仕組みで境界を強制するため、フォルダの外を勝手に触られない技術的な裏付けがあります。workspace-writeは、日常的にCodexへ編集を任せる場合の基本形になります。

danger-full-accessはOpenAIが非推奨とする全開放のモード

danger-full-accessは、ファイルシステムとネットワークの制限を取り払うモードです。OpenAIの公式ドキュメントには「サンドボックスなし・承認なし(非推奨)」と明記されています。

承認とサンドボックスの両方を飛ばすフラグについては、公式ドキュメントに警告も書かれています。悪意あるプロジェクトが、認証情報を含むコンテナ内のすべてを持ち出せるという警告です。使うとしても、壊れてよい隔離環境に限定するのがOpenAIの立場です。

承認ポリシーでCodexの確認のタイミングを決める【approval_policy】

承認ポリシーは、二層のうち、制限の外に出る操作の前にユーザーへ確認するかどうかを決める層です。Codexの確認のタイミングを決める承認ポリシーの設定値は、基本の2つと細かく決める形式の合計3つです。古い解説に出てくる設定値の扱いも含めて、Codexの承認ポリシーで押さえたい点は以下のとおりです。

on-requestは必要なときだけ確認する
neverは確認なしで進める
granular形式は確認の種類ごとに決める
古い解説のuntrustedとon-failureに注意する

on-requestは必要なときだけ確認する

on-requestは、サンドボックスの制限を超える操作が必要になった時点で承認を求める設定です。OpenAIの公式ドキュメントに、on-requestがデフォルトと明記されています。普段は流れを止めず、境界を越えるときだけ人間が判断する動きです。

初期設定のまま使い始めても、危険な操作が無確認で走らない構造になっています。まずはon-requestのデフォルトの動きを理解するところが出発点です。

neverは確認なしで進める

neverは、承認のプロンプトを出さない設定です。注意したいのは、neverにしても何でも許可になるわけではない点です。確認が出なくなるだけで、サンドボックスによる「できる範囲」の制限は別の層としてそのまま残ります。

自動処理でCodexを止めたくない場合は、サンドボックス側で範囲を絞ったうえで確認を省く設計にします。たとえばneverとworkspace-writeを組み合わせると、Codexの二層構造に沿った使い方になります。

granular形式は確認の種類ごとに決める

OpenAIの公式ドキュメントには、基本の2値に加えて、確認画面の種類ごとに「対話で確認するか・自動で処理するか」を決めるgranular形式があります。granular形式は、サンドボックスの境界を越える承認・ルール・MCPの問い合わせ・権限要求・スキルの承認を個別に指定できる上級者向けの選択肢です。

古い解説のuntrustedとon-failureに注意する

古い解説にあるuntrustedは廃止され、on-failureも非推奨になりました。untrustedを書いたままにするとCodexが起動しない場合があると、OpenAIが注意しています。設定ファイルにuntrustedが残っていれば削除してください。

信頼できないプロジェクトで承認を厳しくしたい場合は、~/.codex/config.tomlのプロジェクト設定でtrust_level = "untrusted"を指定します。

情報漏洩を防ぐCodexのセキュリティ設定と考え方

Codexを会社で使うときに気になるのが、コードや顧客情報が外部へ流出しないかという点です。設定で防げる部分と、使う人が運用で決める部分を分けて押さえると、備えの抜けを見つけやすくなります。Codexで外部へのデータ流出に関わるポイントは、以下の4つです。

ネットワークアクセスは標準でオフになっている
学習への利用はプランによって扱いが異なる
クラウド実行はシークレットを除いた隔離環境で動く
渡すデータの線引きは設定の外側で決める

ネットワークアクセスは標準でオフになっている

Codexのサンドボックス内では、ネットワークアクセスが標準でオフです。workspace-writeモードでも、通信が必要な操作には承認が求められます。許可する場合はconfig.tomlのsandbox_workspace_writeセクションでnetwork_access = trueと明示する仕組みです。

Codexには、さらに細かく制御したい場合に、ドメイン単位で許可・拒否を指定する機能も用意されています。勝手に外部と通信しない状態から始まり、開ける範囲を自分で決める設計です。

学習への利用はプランによって扱いが異なる

OpenAIの公式ドキュメントには、ビジネス向けのプランではビジネスデータを既定でAIの学習に使用しないと記載されています。会社で使う場合は、ビジネス向けプランを選ぶことがデータ保護の前提になります。

個人プランでの扱いは、ChatGPT側のデータコントロール設定で管理する形です。業務のコードを扱うなら、契約プランと設定の両方を導入前に確認しておくと説明がつきます。

データの保持や削除の扱いについても、OpenAIの公式FAQには、契約するワークスペースのプランと管理側の設定に従うとの記載があります。保持期間の要件が決まっている会社は、契約前にプランの仕様確認まで含めるのが安全です。

クラウド実行はシークレットを除いた隔離環境で動く

Codexのクラウド実行では、タスクごとにコンテナが作られ、選んだブランチのコードがコンテナの中に展開されます。実行は、環境を準備する段階と、エージェントが作業する段階に分かれています。

OpenAIの公式ドキュメントによると、APIキーなどのシークレットは環境準備の段階でのみ使え、エージェントの作業が始まる前に取り除かれます。エージェント段階のインターネットアクセスも、標準ではブロックされる設計です。許可する場合も、ドメインの許可リストと、取得系に限定したHTTPメソッド制限を組み合わせられます。

渡すデータの線引きは設定の外側で決める

サンドボックスと承認で制御できるのは、Codexが「何をするか」の範囲です。人間が「何を渡すか」は設定では守れないため、入力の線引きを運用として決めておく必要があります。

Codexに渡すデータの線引きの基本は、以下の3点です。

顧客の実名やAPIキーなどの機密はそのまま渡さない
動作確認にはダミーデータへ置き換えたものを使う
誤って入力した場合の報告先をあらかじめ決めておく

会社としてのルール整備の進め方は、生成AIの社内ルールの記事で詳しく解説しています。

生成AIの社内ルールの作り方を徹底解説！盛り込む項目とひな形も紹介

config.tomlでCodexのセキュリティ設定を固定する

サンドボックスと承認の設定は、設定ファイルのconfig.tomlに書いておくと、毎回フラグを付けずに運用へ落とし込めます。チームや組織で同じ安全設定をそろえたい場合にも、設定ファイルが土台になります。Codexの設定をファイルで固定するときに押さえたい点は、以下のとおりです。

設定ファイルの場所と書き方を押さえる
ベータ版のPermission Profilesは従来の設定と混ぜない
組織ではmanaged configurationで強制できる

設定ファイルの場所と書き方を押さえる

Codexの設定は、ユーザー全体なら~/.codex/config.toml、プロジェクト単位なら.codex/config.tomlに書いて固定できます。OpenAIの公式ドキュメントに載っている例は、次の形です。

approval_policy = "on-request"

sandbox_mode = "read-only"

[sandbox_workspace_write]

network_access = true

書き込みを許可する追加フォルダの指定(writable_roots)などのオプションも用意されています。チームで使う場合は、プロジェクトの設定ファイルをリポジトリで共有すると、全員が同じ安全設定で作業できます。プロジェクト側の設定は、対象のプロジェクトを信頼済みにした場合だけ読み込まれる点に注意してください。

ベータ版のPermission Profilesは従来の設定と混ぜない

OpenAIの公式ドキュメントには、サンドボックスと承認をまとめて名前付きで定義するPermission Profilesが、ベータ機能として追加されています。組み込みのプロファイルは、:read-only、:workspace、:danger-full-accessの3つです。Permission Profilesは、ドメイン単位のネットワーク許可まで書ける新しい体系です。

Permission Profilesは、従来のsandbox_mode系の設定とは合成されず、どちらか一方だけを使う決まりです。既存の設定と混ぜて書かないよう注意してください。

組織ではmanaged configurationで強制できる

組織向けには、管理者が設定を配布するmanaged configurationの仕組みがあります。managed configurationは、ユーザーが上書きできない強制の層と、初期値として配る既定の層の2段階です。

OpenAIの公式ドキュメントによると、managed configurationで強制できる項目には、以下のものが含まれます。

許可する承認ポリシーの一覧(allowed_approval_policies)
許可するサンドボックスモードの一覧(allowed_sandbox_modes)

danger-full-accessを組織全体で使えなくする、といった統制を設定ファイルの配布で実現できる形です。

Codexのセキュリティに関するよくある質問

Codexの導入前によく出る不安を、外部へのデータ送信・全自動での利用・会社での決め方の順にまとめました。Codexのセキュリティに関するよくある質問は、以下のとおりです。

Codexが勝手に外部へデータを送ることはありませんか？
承認なしの全自動で使っても大丈夫ですか？
会社で使うときは何から決めればよいですか？

Codexが勝手に外部へデータを送ることはありませんか？

サンドボックス内のネットワークアクセスは標準でオフのため、承認していない通信は基本的に走りません。

一方で、OpenAIの公式ドキュメントは、Webページなどに仕込まれた指示でAIを操るプロンプトインジェクションのリスクを明記しています。プロンプトインジェクションによって、コードやシークレットの流出が起こりうるという注意です。

Codexのクラウド実行について、OpenAIの公式ガイドが挙げる対策は、信頼できるリソースだけをCodexに参照させ、インターネットアクセスをできる限り絞ることです。既定のオフを不用意に緩めない運用が守りの中心になります。

承認なしの全自動で使っても大丈夫ですか？

承認を切ること自体は、サンドボックスで範囲を絞っていれば選択肢になります。危険なのは、サンドボックスと承認の両方を同時に外す使い方です。

OpenAIの公式ドキュメントは、全開放のフラグについて、認証情報を含むすべてを悪意あるプロジェクトに持ち出されうると警告しています。自動化したい場合も、二層のうち片方は必ず残す設計にしましょう。

Codexには、人の確認を減らしつつ歯止めを残す仕組みとして、境界を越える操作の承認をレビュー役のAIが代わりに審査するAuto-reviewモードも追加されています。Auto-reviewモードは、approvals_reviewerの設定をon-requestと組み合わせるか、CLIなら--approve-for-meフラグで有効にします。

却下が続くと作業自体を中断する安全装置も、Auto-reviewモードに組み込み済みです。ただし、OpenAIの公式ドキュメントは、Auto-reviewモードを決定論的なセキュリティ保証ではないと明記しています。

会社で使うときは何から決めればよいですか？

会社でCodexを使うときに決める順番は、契約プラン→設定の標準→運用ルールの3段階が整理しやすい流れです。それぞれの段階で決める内容は、以下のとおりです。

契約プラン：ビジネスデータが学習に使われないプランを選ぶ
設定の標準：managed configurationで許可するモードを組織として固定する
運用ルール：AIが書いたコードのレビュー体制と、Codexに渡してよいデータの線引きを文書で決める

ここまでそろえば、個人の注意力に頼らない運用が可能です。

まとめ

Codexのセキュリティは、二層のデフォルトを理解すれば固められます。Codexの安全設計は、できる範囲を制限するサンドボックスと、確認のタイミングを決める承認ポリシーの二層構造です。

バージョン管理されたフォルダで作業する場合の標準の組み合わせは、workspace-writeとon-requestです。ネットワークはオフから始まるため、初期設定のままでも無防備ではありません。

安全度を上げたいならread-only、自動化を進めたいならサンドボックスで範囲を絞ったうえで承認を減らすのが、Codexの設計に沿った調整です。会社利用ではビジネス向けプランとmanaged configurationを組み合わせれば、組織としての統制も設定で担保できます。

まずは自分の環境のconfig.tomlにサンドボックスと承認の2行を書き、意図した設定で動いているかを確かめるところから始めましょう。