2026/06/08Codex

導入・運用セキュリティ

Codexの承認モードとサンドボックス｜安全運用

AIに開発やファイル操作を任せたいけれど、「勝手に大事なファイルを書き換えられたら」「外部に情報を送信されたら」と不安で踏み切れない。中小企業でCodexの導入を検討するとき、必ず出てくるのがこの安全性の悩みです。

結論から言うと、Codexは「どこまで自律実行を許すか」を承認モードとサンドボックスという2つの設定で細かくコントロールできます。最初は確認ありで運用し、慣れてきたら自動化の範囲を広げる。この段階的な進め方が、事故を防ぎながらAI活用を加速させる現実的な答えです。

株式会社Fyveは、AI業務効率化の受託開発と専属AI活用顧問サービスを提供しています。私たちは日常業務でCodexを使い込み、クライアントへの導入支援も行ってきました。本記事では、その実務経験から「安全な自律実行」を実現する設定の勘所を、非エンジニアの経営者・管理者の方にもわかるように解説します。

Codexの安全設計は「2つの層」でできている

まず大前提として、Codexの安全性は単一の設定ではなく、性質の違う2つの層が組み合わさってできています。ここを混同すると設定がちぐはぐになり、「許可したつもりがブロックされる」「制限したつもりが素通りする」という事故につながります。

OpenAIの公式ドキュメントでも、この2層は明確に区別して説明されています。それぞれの役割は次の通りです。

承認ポリシー（approval policy）：Codexが行動を実行する前に、人間に「確認を取るかどうか」を決める層。いわば「報告・連絡・相談」のルール
サンドボックスモード（sandbox mode）：Codexが技術的に「何をできるか」を決める層。書き込める場所やネットワークへの到達可否といった物理的な境界線

たとえるなら、承認ポリシーは「上司に相談してから動くか、自分の判断で動くか」という社内ルール。サンドボックスは「そもそもこの社員に渡されている鍵やアクセス権の範囲」です。両方をセットで考えることが、安全運用の出発点になります。

承認モード：read-only / auto / full-access の3段階

承認モードは、Codexがどこまで自分の判断で動いてよいかを決める設定です。対話画面では大きく3つのモードが用意されており、コマンド実行中に /permissions と入力すれば、その場で切り替えられます。

3つのモードは、自律性が低い順に次のように並びます。導入直後の組織が左から右へ段階的に移行していくイメージで捉えてください。

Read-only（読み取り専用）：Codexはファイルを読んで分析・提案はできますが、書き込みやコマンド実行は一切せず、必ず人間の承認を待ちます。「まず相談だけ」の最も慎重なモード
Auto（自動・既定値）：作業フォルダ内であれば、ファイルの読み書きや一般的なコマンド実行を自動で行います。フォルダの外に触れる場合やネットワークを使う場合だけ確認を求めます。日常作業の標準モード
Full Access（フルアクセス）：ネットワークアクセスを含め、マシン全体に対して確認なしで動けます。信頼できるリポジトリ・タスクに限って、ごく限定的に使うモード

承認モードの段階をread-only→auto→full-accessの順に示した3段階の図

設定ファイル（config.toml）では、この承認の挙動を approval_policy という項目で指定します。Codexに直接こう頼んで設定してもらうのが確実です。

approval_policy = "on-request"   # 必要なときにCodexから確認を求める
# approval_policy = "untrusted"  # 既知の安全な読み取り以外は都度承認
# approval_policy = "never"      # 一切確認しない（自動実行・非対話向け）

上の on-request は対話作業の標準値で、Codexが「これは確認が必要」と判断したときだけ尋ねてきます。untrusted はより慎重で、安全とわかっている読み取り操作以外はすべて承認を求めます。never は確認を一切しない設定で、後述するサンドボックスと組み合わせない限り使うべきではありません。なお旧来の on-failure は非推奨となっているため、新規導入では使わないでください。

サンドボックス：書き込み範囲とネットワークの境界線

サンドボックスモードは、Codexが実際にコマンドを実行するときの「物理的な檻」です。承認モードが「聞いてくるかどうか」だとすれば、サンドボックスは「そもそも何が許されているか」を決めます。仮にCodexが暴走しても、サンドボックスの境界を超えることはできません。

サンドボックスにも3つの段階があります。

read-only：読み取りのみ。一切の書き込み・コマンド実行を許さない最も厳格な境界
workspace-write：作業フォルダ（ワークスペース）内に限り書き込み・ローカルコマンド実行を許可。日常作業の既定的な低摩擦モード。この設定ではネットワークアクセスが既定でオフ
danger-full-access：ファイルシステムもネットワークも制限なし。サンドボックスの保護が外れた状態。名前の通り危険なので、本当に信頼できる場面に限る

ここで実務上もっとも重要なのが、workspace-writeではネットワークが既定で遮断されている点です。AIが外部に勝手にデータを送ったり、未知のパッケージをダウンロードしたりする経路が、初期状態で塞がれています。これは情報漏洩を心配する企業にとって大きな安心材料です。

もし作業上どうしてもネットワークが必要な場合は、設定で明示的に開放します。Codexにこう設定してもらってください。

[sandbox_workspace_write]
network_access = true   # ワークスペース書き込みモードでネットを開放

このように「既定はオフ、必要なときだけ意図的にオン」という設計思想になっています。逆に言えば、何も設定しなければネットワークは閉じたまま安全側に倒れる、ということです。

OSレベルで隔離されているという安心材料

「設定でブロックしていると言っても、ソフトウェアの約束事に過ぎないのでは」と感じる方もいるでしょう。実際にはCodexのサンドボックスは、OS（基本ソフト）の機能を使ってより低いレベルで隔離を実現しています。アプリケーションの善意に頼らず、OSが境界を強制する仕組みです。

公式ドキュメントによると、ローカルでCodexを動かす場合、以下のOS標準のサンドボックス機構が使われます。

macOS：Apple Seatbelt（sandbox-exec）を用い、指定したサンドボックス設定に対応するプロファイルでコマンドを実行
Linux：Landlock と seccomp という仕組みを組み合わせて、ファイルアクセスやシステム呼び出しを制限

これらはCodex独自の発明ではなく、OSが提供する実績あるセキュリティ機構です。つまりCodexの安全性は、AIの判断の良し悪しだけでなく、その下のOSの仕組みでも二重に守られているということです。

なお、クラウド版のCodexはさらに隔離が徹底されています。クラウドでは各タスクがOpenAI管理下の独立したコンテナで動き、利用者のPC本体や他のデータには一切アクセスできません。クラウドでもネットワークは既定で無効で、必要に応じて全開放か、許可ドメインを列挙したホワイトリスト方式を選べます。

私たちが推奨する段階的な導入ステップ

ここまでの設定を踏まえ、私たちがクライアントへの導入支援で実際に取っている進め方を紹介します。最初から自動化を全開にするのではなく、信頼を積み上げながら範囲を広げるのが鉄則です。

具体的には、次の3ステップで移行していくことをおすすめします。

ステップ1（観察期）：Read-only + read-onlyサンドボックスで開始。Codexがどんな提案をするか、まず「相談相手」として使い、挙動の癖をつかむ
ステップ2（伴走期）：Auto + workspace-writeに移行。作業フォルダ内は任せ、外部やネットワークに触れるときだけ確認を取る。ネットワークは引き続きオフのまま運用
ステップ3（自動化期）：信頼できる定型タスクに限り、対象を絞って自動化を拡大。それでもdanger-full-accessは原則使わず、必要な権限だけをピンポイントで開放する

導入支援の現場で繰り返し感じるのは、「いきなりフルアクセスにして事故る」より「慎重すぎて使われない」ほうがよくある失敗だということです。最初の数週間をRead-onlyで過ごし、Codexの提案精度に納得してからAutoへ進む。この順番なら、現場の心理的なハードルも自然に下がっていきます。

設定はチームで共有することも大切です。config.toml に承認ポリシーとサンドボックスモードを明記しておけば、誰が使っても同じ安全レベルが担保されます。属人的な「気をつける」ではなく、設定として安全を固定するのが組織導入のコツです。

設定値はバージョンで変わりうる前提で

最後に注意点をひとつ。Codexは更新が活発なツールで、承認モードの名称やサンドボックスの挙動、設定項目はバージョンによって変わることがあります。本記事は2026年6月時点の情報をもとにしていますが、実際に設定する際は必ず最新の公式情報で確認してください。

たとえば、macOSのSeatbelt環境では network_access = true の設定が一部のバージョンで正しく反映されない事例も報告されています。挙動が想定と違うと感じたら、思い込みで進めず、公式ドキュメントや実機での挙動確認を優先するのが安全です。AIに重要な操作を任せるからこそ、設定の正確さは妥協しないでください。

よくある質問

承認モードとサンドボックスモードは、どちらを設定すればいいですか？

両方をセットで設定します。承認モードは「Codexが確認を取るか」、サンドボックスは「技術的に何ができるか」を決める別々の層です。たとえば「自動で動いてほしいが書き込みはフォルダ内だけ」なら、承認=Auto・サンドボックス=workspace-writeの組み合わせになります。片方だけでは安全設計が完成しません。

既定（デフォルト）のままでも安全ですか？

はい、既定値はかなり安全側に倒れています。承認はAuto、サンドボックスはworkspace-writeで、作業フォルダの外には触れず、ネットワークも初期状態でオフです。まずは既定のまま使い始め、必要に応じて締めたり緩めたりするのが現実的です。

Codexに勝手に外部へ情報を送られる心配はありますか？

標準的なworkspace-writeモードでは、ネットワークアクセスが既定で無効になっています。そのため、明示的に network_access = true を設定しない限り、外部との通信経路は塞がれています。情報漏洩を心配する企業ほど、この既定の遮断を活かした運用を推奨します。

danger-full-access は使ってはいけないのですか？

禁止ではありませんが、原則として避けるべきです。このモードはファイルシステムもネットワークも制限を外すため、サンドボックスの保護がほぼなくなります。本当に信頼できるリポジトリとタスクに限り、しかも一時的に使うのが鉄則です。日常運用では出番はほとんどありません。

設定をチーム全員で統一できますか？

できます。config.toml に approval_policy と sandbox_mode を記述しておけば、そのプロジェクトを使う全員に同じ安全設定が適用されます。プロファイル機能を使えば、用途別に複数の設定を保存して切り替えることも可能です。属人化を避けたい組織導入で有効です。

クラウド版とローカル版で安全性は違いますか？

考え方は共通ですが、隔離の強さが異なります。ローカルではOSのSeatbeltやLandlockで隔離し、クラウドではOpenAI管理下の独立コンテナで動くため、利用者のPC本体には一切アクセスできません。どちらもネットワークは既定でオフです。社外秘の度合いが高い作業ほど、隔離レベルを意識して使い分けてください。

設定名や挙動が記事と違う場合はどうすればいいですか？

Codexは更新が頻繁なため、バージョンによって名称や挙動が変わることがあります。本記事と実機の表示が異なる場合は、必ず最新の公式ドキュメントを確認してください。特にネットワークや承認まわりは安全に直結するため、推測で進めず公式の記述に合わせることをおすすめします。

まとめ

Codexの安全性は「承認ポリシー（確認を取るか）」と「サンドボックス（技術的に何ができるか）」の2層で構成される
承認モードはread-only→auto→full-accessの3段階。/permissions でその場で切り替え可能
サンドボックスはread-only→workspace-write→danger-full-accessの3段階。workspace-writeが既定の低摩擦モード
workspace-writeではネットワークが既定でオフ。必要なときだけ network_access = true で明示的に開放する
ローカルはSeatbelt/Landlockで、クラウドは独立コンテナでOSレベルに隔離される
導入は「Read-onlyで観察→Autoで伴走→限定的に自動化拡大」の段階移行が安全
設定名・挙動はバージョンで変わりうるため、必ず最新の公式情報で確認する

Codexを企業導入する際の情報漏洩対策やセキュリティ全般を、より広い視点で整理した記事です。