Codex の法人導入で最初に聞かれるのは、性能ではなく「勝手に何をされるのか」です。ファイルを書き換えるのか、社内のネットワークに出ていくのか、どこで人が止められるのか。ここが曖昧なままだと、現場に配ることも、情報システム部門として承認することもできません。
この記事では、株式会社デジライズが導入支援で最初に説明している「サンドボックス」と「承認ポリシー」の関係を、OpenAI の公式ドキュメントに書かれている範囲だけで整理します。設定名は公式の表記をそのまま使います。
二層で考える: できる範囲と、聞かれる範囲
Codex の挙動は 2 つの設定の組み合わせで決まります。
- サンドボックス: 技術的に何ができるかの境界
- 承認ポリシー: 境界に触れるとき、いつ人に聞くか
公式ドキュメントは、サンドボックスを「エージェントがあなたのマシンへ無制限にアクセスすることなく、自律的に動作できるようにするための境界」と説明しています。コマンドはフルアクセスではなく、制限された権限で実行されます。（出典: Sandboxing）
この 2 つを分けて理解しておくと、「承認をゆるめる」話と「できることを広げる」話を混同せずに済みます。
サンドボックスの 3 つのモード
公式ドキュメントには 3 つのモードが記載されています。
| モード | 記載されている内容 |
|---|---|
read-only |
エージェントはファイルを調べられるが、承認なしにファイルの編集やコマンドの実行はできない |
workspace-write |
ファイルの読み取り、ワークスペース内での編集、その境界内での通常のローカルコマンドの実行ができる |
danger-full-access |
サンドボックスの制限なしで動作し、ファイルシステムとネットワークの境界が外れる |
ローカル作業の既定は workspace-write です。（出典: Sandboxing）
法人で決めるべきことは単純です。danger-full-access を既定にしない。この 1 点を先に合意しておけば、残りは運用の話になります。
既定の組み合わせ
公式ドキュメントには、既定の構成として sandbox_mode = "workspace-write" と approval_policy = "on-request" の組み合わせが記載されています。（出典: Sandboxing）
この状態で何が起きるかを、承認側のドキュメントと突き合わせると次のようになります。
承認なしで進むこと
標準の Auto プリセットでは、Codex はワークスペース内でファイルを読み、編集し、コマンドを実行できます。サンドボックスの内側にとどまる操作は、追加のレビュー手順なしに続行されます。（出典: Agent approvals and security）
つまり「接続したフォルダの中は自動で進む」が前提です。だからこそ、最初に接続するフォルダの選び方が実質的なガードレールになります。
承認が必要になること
既定では、次の操作に承認が必要です。（出典: Agent approvals and security）
- ワークスペース外のファイルを編集する
- ネットワークアクセスを必要とするコマンドを実行する
- 副作用があると宣言しているアプリ（コネクタ）のツール呼び出し
- 破壊的なアプリ／MCP のツール呼び出し
ネットワークの既定
公式ドキュメントには「既定では、エージェントはネットワークアクセスを無効にした状態で動作します」と明記されています。ローカルの Codex では、workspace-write のサンドボックスにおいてネットワークは無効のままで、network_access = true のような設定で明示的に変更しない限り有効になりません。（出典: Agent approvals and security）
「既定で無効」であって「無効化できない」ではない点が重要です。設定と承認の両方を運用の対象にしてください。
設定の変え方と、変えてはいけない前提
挙動はコマンドのフラグ（--sandbox workspace-write --ask-for-approval on-request のような指定）や設定ファイルから変更できます。また approvals_reviewer = "auto_review" を設定すると、条件を満たす承認要求をレビュー担当のエージェントへ回せます。（出典: Agent approvals and security）
ここで押さえておきたいのは、承認の担当を変えることと、サンドボックスを広げることは別だということです。承認フローを自動化しても、read-only や workspace-write の境界そのものが動くわけではありません。逆に言えば、境界を締めておけば、承認運用を多少ゆるめても被害範囲は限定されます。
法人で先に決めておく 3 点
- 既定のサンドボックスモード:
workspace-writeを既定とし、danger-full-accessは原則禁止にする。例外を認める場合は、対象環境・期間・承認者を残す - ワークスペースの切り方: 自動で進む範囲はワークスペースの中です。基幹データの原本が入ったフォルダを直接つながない運用にする
- ネットワークを有効にする条件: 既定は無効です。有効化が必要な業務を洗い出し、誰の承認で有効にするかを決める
この 3 点は、組織としての統制全体から見ると入口の部分です。ロールや監査の設計まで含めた全体像はCodex の法人セキュリティとガバナンスの記事に、導入前に確認する項目の一覧はCodex 法人導入チェックリストにまとめています。
なお、この記事の内容は公開時点の OpenAI 公式ドキュメントで確認した範囲です。設定名や既定値は変わることがあるため、社内規程に落とし込む前に最新の記載をご確認ください。デジライズでは、この設計を含めた導入支援のご相談を承っています。
確認日：2026年9月14日。提供条件・機能・料金は変更されるため、最新情報は各公式ページをご確認ください。
デジライズの実績はデジライズ全体の社内集計値です。Codex の機能・対応環境・料金・提供条件は記事の公開・更新時点の OpenAI 公式情報に基づき、変更される場合があります。導入効果は企業や業務によって異なります。
Codex の法人導入・研修・業務活用を支援しています。
法人導入支援サービスを見る
