Codexのセキュリティを徹底解説！承認・サンドボックスの安全設定を紹介
Codexは、AIがファイルの書き換えやコマンドの実行まで進めるコーディングエージェントです。便利さの一方で、会社のコードや顧客情報があるパソコンで動かすとなると、勝手な操作や情報漏洩への備えを確認せずには導入できません。しかも検索結果には「Codex Security」という別機能の解説も混ざるため、知りたい情報にたどり着きにくい状態です。
この記事では、Codex本体を安全に使うための仕組みと設定を、OpenAIの公式ドキュメントに基づいて解説します。読み終えるころには、自分の使い方に合う設定の組み合わせを判断できます。結論から言うと、Codexは標準でもサンドボックスと承認の二層で守られており、ネットワークはオフから始まる設計です。
Codexのセキュリティの全体像
まず押さえたい前提は以下の2つです。
- 「使う側の安全設定」と「Codex Security」は別の話
- Codexの安全設計はサンドボックスと承認の二層でできている
「使う側の安全設定」と「Codex Security」は別の話
Codexのセキュリティを検索すると、「Codex Security」の名前が付いた別機能の解説記事が混ざって表示されます。Codex Securityは、公式ドキュメントによると、コードの脆弱性を発見・確認・修正するために作られたアプリケーションセキュリティ専門のエージェントです。提供形態はChatGPTアプリのプラグイン、CLIとSDK、GitHub連携のクラウド版(リサーチプレビュー段階)に分かれています。
名前は似ていますが、この記事で扱うのは、Codex本体を日々の作業で安全に使うための設定の話です。自分が知りたいのがどちらなのかを最初に切り分けると、情報収集の迷子を避けられます。Codexそのものの概要から知りたい場合は、次の記事から読むのがおすすめです。
Codexとは？読み方や旧モデルとの違い・できることまで徹底解説！
Codexの安全設計はサンドボックスと承認の二層でできている
公式ドキュメントは、Codexのセキュリティ制御を「連携して働く2つの層」と説明しています。1つ目はサンドボックスで、AIが技術的に何をできるかをOSレベルの仕組みで制限する層です。2つ目は承認ポリシーで、制限の外に出る操作の前にユーザーへ確認するかどうかを決めます。
サンドボックスが「できる範囲」、承認ポリシーが「確認のタイミング」を受け持つ役割分担です。2つは別々に設定でき、組み合わせ方で安全度と作業の速さのバランスを調整します。
サンドボックスモードで権限の範囲を決める【sandbox_mode】
Codexの権限の範囲を決めるサンドボックスモードは3種類です。
- read-onlyは読み取り専用で最も安全
- workspace-writeは作業フォルダ内だけ書き込める
- danger-full-accessは公式が非推奨とする全開放
read-onlyは読み取り専用で最も安全
read-onlyは、ファイルの読み取りと質問への回答だけを許すモードです。ファイルの編集、コマンドの実行、ネットワークアクセスにはすべて承認が必要になります。
コードの調査や説明を頼む使い方なら、read-onlyで十分に実用的です。公式ドキュメントでは、バージョン管理されていないフォルダで作業する場合の推奨としても挙げられています。まず様子を見たい導入初期に向いたモードです。
workspace-writeは作業フォルダ内だけ書き込める
workspace-writeは、作業中のワークスペース内に限ってファイルの読み書きと通常のコマンド実行を許すモードです。ワークスペースの外への書き込みと、ネットワークアクセスには承認が求められます。
サンドボックスの実装に使われるのはOSの仕組みです。macOSはSeatbelt・LinuxとWSL2はbubblewrap・WindowsはWSLを使わないネイティブのサンドボックスで境界を強制します。フォルダの外を勝手に触られない技術的な裏付けがある形です。日常的にCodexへ編集を任せる場合の基本形になります。
danger-full-accessは公式が非推奨とする全開放
danger-full-accessは、ファイルシステムとネットワークの制限を取り払うモードです。公式ドキュメントには「サンドボックスなし・承認なし(非推奨)」と明記されています。
承認とサンドボックスの両方を飛ばすフラグについては、悪意あるプロジェクトが認証情報を含むコンテナ内のすべてを持ち出せる、という警告が公式に書かれています。使うとしても、壊れてよい隔離環境に限定するのが公式の立場です。
承認ポリシーで確認のタイミングを決める【approval_policy】
確認のタイミングを決める承認ポリシーの基本の設定値は3つです。
- on-requestは必要なときだけ確認する
- untrustedは信頼できない操作だけ確認する
- neverは確認なしで進める
on-requestは必要なときだけ確認する
on-requestは、サンドボックスの制限を超える操作が必要になった時点で承認を求める設定で、公式ドキュメントにデフォルトと明記されています。普段は流れを止めず、境界を越えるときだけ人間が判断する動きです。
初期設定のまま使い始めても、危険な操作が無確認で走らない構造になっています。まずはこのデフォルトの動きを理解するところが出発点です。
untrustedは信頼できない操作だけ確認する
untrustedは、信頼できないコマンドの実行時のみ承認を要求する設定です。よく知られた安全な操作は確認なしで進み、疑わしいものだけ止まります。
確認の回数を減らしながら、怪しい操作への歯止めは残したい場合の選択肢です。
neverは確認なしで進める
neverは、承認のプロンプトを出さない設定です。注意したいのは、neverにしても何でも許可になるわけではない点です。確認が出なくなるだけで、サンドボックスによる「できる範囲」の制限は別の層としてそのまま残ります。
自動処理でCodexを止めたくない場合は、neverとworkspace-writeを組み合わせるなど、サンドボックス側で範囲を絞ったうえで確認を省く設計が公式の二層構造に沿った使い方です。
なお、基本の3値に加えて、公式ドキュメントには確認画面の種類ごとに「対話で確認するか・自動で却下するか」を細かく決めるgranular形式も追加されています。承認の設計をさらに作り込みたい場合の上級者向けの選択肢です。
情報漏洩を防ぐ設定と考え方
外部へのデータ流出に関わるポイントは以下の4つです。
- ネットワークアクセスは標準でオフになっている
- 学習への利用はプランによって扱いが異なる
- クラウド実行はシークレットを除いた隔離環境で動く
- 渡すデータの線引きは設定の外側で決める
ネットワークアクセスは標準でオフになっている
Codexのサンドボックス内では、ネットワークアクセスが標準でオフです。workspace-writeモードでも、通信が必要な操作には承認が求められます。許可する場合はconfig.tomlのsandbox_workspace_writeセクションでnetwork_access = trueと明示する仕組みです。
さらに細かく制御したい場合は、ドメイン単位で許可・拒否を指定する機能も公式に用意されています。勝手に外部と通信しない状態から始まり、開ける範囲を自分で決める設計です。
学習への利用はプランによって扱いが異なる
公式のドキュメントには、ビジネス向けではビジネスデータを既定でAIの学習に使用しないと記載されています。会社で使う場合は、ビジネス向けプランを選ぶことがデータ保護の前提になります。
個人プランでの扱いは、ChatGPT側のデータコントロール設定で管理する形です。業務のコードを扱うなら、契約プランと設定の両方を導入前に確認しておくと説明がつきます。
データの保持や削除の扱いについても、公式FAQには、契約するワークスペースのプランと管理側の設定に従うとの記載があります。保持期間の要件が決まっている会社は、契約前にプランの仕様確認まで含めるのが安全です。
クラウド実行はシークレットを除いた隔離環境で動く
Codexのクラウド実行では、タスクごとにコンテナが作られ、選んだブランチのコードがコンテナの中に展開されます。実行は環境準備の段階とエージェントが作業する段階に分かれており、APIキーなどのシークレットは環境準備でのみ使え、エージェントの作業が始まる前に取り除かれると公式に説明されています。
エージェント段階のインターネットアクセスも、標準ではブロックされる設計です。許可する場合もドメインの許可リストと、取得系に限定したHTTPメソッド制限を組み合わせられます。
渡すデータの線引きは設定の外側で決める
サンドボックスと承認で制御できるのは、Codexが「何をするか」の範囲です。人間が「何を渡すか」は設定では守れないため、入力の線引きを運用として決めておく必要があります。
線引きの基本は3点です。顧客の実名やAPIキーなどの機密はそのまま渡さず、動作確認にはダミーデータへ置き換えたものを使い、誤って入力した場合の報告先をあらかじめ決めておきます。会社としてのルール整備の進め方は、社内ルールの記事で詳しく解説しています。
生成AIの社内ルールの作り方を徹底解説！盛り込む項目とひな形も紹介
config.tomlで設定を固定する
毎回フラグを付けずに運用へ落とし込む方法は以下のとおりです。
- 設定ファイルの場所と書き方を押さえる
- 組織ではmanaged configurationで強制できる
設定ファイルの場所と書き方を押さえる
Codexの設定は、ユーザー全体なら~/.codex/config.toml、プロジェクト単位なら.codex/config.tomlに書いて固定できます。公式ドキュメントに載っている例は次の形です。
approval_policy = "untrusted"
sandbox_mode = "read-only"
[sandbox_workspace_write]
network_access = true
書き込みを許可する追加フォルダの指定(writable_roots)などのオプションも用意されています。チームで使う場合は、プロジェクトの設定ファイルをリポジトリで共有すると全員が同じ安全設定で作業できます。
なお、ベータ機能として公式ドキュメントに追加されたのが、サンドボックスと承認をまとめて名前付きで定義するPermission Profilesです。:read-only・:workspace・:danger-full-accessの3つの組み込みプロファイルがあり、ドメイン単位のネットワーク許可まで書ける新しい体系です。従来のsandbox_mode系の設定とは合成されず、どちらか一方だけを使う決まりのため、既存の設定と混ぜて書かないよう注意してください。
組織ではmanaged configurationで強制できる
組織向けには、管理者が設定を配布するmanaged configurationの仕組みがあります。ユーザーが上書きできない強制の層と、初期値として配る既定の層の2段階です。
強制できる項目には、許可する承認ポリシーの一覧(allowed_approval_policies)や許可するサンドボックスモードの一覧(allowed_sandbox_modes)が含まれます。danger-full-accessを組織全体で使えなくする、といった統制を設定ファイルの配布で実現できる形です。
Codexのセキュリティに関するよくある質問
導入前によくある不安をまとめました。
- Codexが勝手に外部へデータを送ることはありませんか？
- 承認なしの全自動で使っても大丈夫ですか？
- 会社で使うときは何から決めればよいですか？
Codexが勝手に外部へデータを送ることはありませんか？
サンドボックス内のネットワークアクセスは標準でオフのため、承認していない通信は基本的に走りません。一方で公式ドキュメントは、Webページなどに仕込まれた指示でAIを操るプロンプトインジェクションのリスクを明記しており、コードやシークレットの流出が起こりうると注意しています。
対策として公式が挙げるのは、信頼できるリソースだけをCodexに参照させ、インターネットアクセスをできる限り絞ることです。既定のオフを不用意に緩めない運用が守りの中心になります。
承認なしの全自動で使っても大丈夫ですか？
承認を切ること自体は、サンドボックスで範囲を絞っていれば選択肢になります。危険なのは、サンドボックスと承認の両方を同時に外す使い方です。
公式ドキュメントは、全開放のフラグについて認証情報を含むすべてを悪意あるプロジェクトに持ち出されうると警告しています。自動化したい場合も、二層のうち片方は必ず残す設計にしましょう。
人の確認を減らしつつ歯止めを残す公式の仕組みとしては、境界を越える操作の承認をレビュー役のAIが代わりに審査するAuto-reviewモードも追加されています。approvals_reviewerの設定をon-requestと組み合わせて使う形で、却下が続くと作業自体を中断する安全装置も組み込み済みです。ただし公式ドキュメントは、この仕組みを決定論的なセキュリティ保証ではないと明記しています。
会社で使うときは何から決めればよいですか？
決める順番は、契約プラン→設定の標準→運用ルールの3段階が整理しやすい流れです。まずビジネスデータが学習に使われないプランを選び、次にmanaged configurationで許可するモードを組織として固定します。
最後にAIが書いたコードのレビュー体制と、Codexに渡してよいデータの線引きを文書で決めます。ここまでそろえば、個人の注意力に頼らない運用が可能です。
Codexのセキュリティは二層のデフォルトを理解すれば固められます
Codexの安全設計は、できる範囲を制限するサンドボックスと、確認のタイミングを決める承認ポリシーの二層構造です。バージョン管理されたフォルダで作業する標準の組み合わせはworkspace-write+on-requestで、ネットワークはオフから始まるため、初期設定のままでも無防備ではありません。
安全度を上げたいならread-only、自動化を進めたいならサンドボックスで範囲を絞ったうえで承認を減らすのが、公式の設計に沿った調整です。会社利用ではビジネス向けプランとmanaged configurationを組み合わせれば、組織としての統制も設定で担保できます。
まずは自分の環境のconfig.tomlにサンドボックスと承認の2行を書き、意図した設定で動いているかを確かめるところから始めましょう。
