Codexの権限と安全設定|承認・サンドボックス・Git管理

Codex は、コードベースを読み、ファイルを編集し、コマンドを実行できるAIエージェントです。便利な一方で、「どこまで許可してよいのか」「勝手に危ないことをしないのか」が気になる方も多いはずです。
本記事では、Codex の権限と安全設定を初心者向けに整理します。承認、サンドボックス、ネットワークアクセス、秘密情報、Git差分、バックアップの考え方を押さえ、安心して使い始めるための基本ルールを作ります。
夕宮たいだふぁ……みんな〜、今日は安全設定の話だよぉ。ちょっと地味だけど、ここを押さえると安心してCodexを使えるんだぁ。
1. Codexの安全設定は何を守るのか
ひとことで:安全設定は、Codexが触れる範囲と、実行前に止まる条件を決めるものです。


Codex は、通常のチャットAIと違い、実際の作業フォルダを読み、ファイルを編集し、コマンドを実行できます。そのため、安全設定では次の3つを守ります。
- ファイル:どのフォルダを読めるか、どこに書き込めるか
- コマンド:どの操作を自動実行できるか、どこで承認が必要か
- ネットワーク:外部サイトやパッケージ取得へアクセスできるか
OpenAI公式の Agent approvals & security では、Codexの安全制御は主に Sandbox mode と Approval policy の2層で考えると説明されています。初心者向けに言い換えると、サンドボックスは「技術的にできる範囲」、承認ポリシーは「実行前に人間へ確認する条件」です。
この2つを理解すると、「Codexにどこまで任せてよいか」を自分で判断しやすくなります。



ていねいに言うと、サンドボックスは「触れる範囲」、承認は「止まって確認するタイミング」なんだぁ。この2つを分けて考えようねぇ。
2. サンドボックスとは何か
ひとことで:サンドボックスは、Codexが作業できる範囲を区切る仕組みです。
サンドボックスは、Codexがコマンドを実行するときに、ファイルシステムやネットワークへのアクセスを制限する仕組みです。公式ドキュメントでは、CLI / IDE extension ではOSレベルの仕組みでサンドボックスを実現し、通常はネットワークなし、書き込みは作業中のワークスペース内に制限されると説明されています。
初心者がまず覚えるべきモードは、次の3つです。
| モード | できること | 向いている場面 |
|---|---|---|
| read-only | ファイルを読む。編集やコマンド実行は強く制限される | 調査、説明、レビューだけしたい |
| workspace-write | 作業フォルダ内の読み書きができる | 通常の実装、README更新、テスト追加 |
| danger-full-access | サンドボックス制限なしに近い | 初心者は使わない |


最初は、調査だけなら read-only、通常作業なら workspace-write を選ぶのが安全です。danger-full-access や、承認とサンドボックスをまとめてバイパスする設定は、公式でも注意して使うものとして扱われています。初心者のうちは選ばないでください。



ぁぅ……名前からして強そうなモードは、最初は触らなくていいよぉ。まずは read-only と workspace-write だけ覚えれば大丈夫なんだぁ。
3. 承認ポリシーとは何か
ひとことで:承認ポリシーは、Codexが実行前に人間へ確認するルールです。
承認ポリシーは、Codexがどの操作を自動で進め、どの操作で人間に確認するかを決める設定です。たとえば、作業フォルダ内のファイルを読むだけなら自動で進み、ネットワークアクセスやワークスペース外の編集では承認を求める、という動きになります。
公式ドキュメントでは、よく使う組み合わせとして次のような考え方が案内されています。
| 使い方 | 例 | 初心者向け判断 |
|---|---|---|
| 読み取りだけ | read-only + 承認あり | 調査だけなら安全 |
| 通常作業 | workspace-write + on-request | 最初の実装に向く |
| 編集は自動、危ないコマンドは確認 | workspace-write + untrusted | 慣れてきたら検討 |
| フルアクセス | サンドボックス・承認をバイパス | 初心者は避ける |
初心者におすすめなのは、workspace-write + on-request のように、作業フォルダ内の通常作業は進めつつ、外に出る操作やネットワークアクセスでは止まる設定です。
承認が出たときは、内容を読まずに許可しないでください。何を実行しようとしているか、どのファイルに触るか、ネットワークへ出ようとしていないかを確認します。
4. ネットワークアクセスをどう考えるか
ひとことで:ネットワークは便利ですが、最初は必要なときだけ許可します。
ネットワークアクセスは、パッケージのインストール、外部ドキュメントの確認、API通信などに使われます。一方で、外部から得た情報にはプロンプトインジェクションなどのリスクがあります。
OpenAI公式では、ローカルの Codex app / CLI / IDE extension の workspace-write モードでは、既定でネットワークアクセスはオフと説明されています。必要に応じて設定で有効化できますが、初心者はまずオフのまま使うのが安全です。
ネットワークを許可してよい場面は、次のような場合です。
- 公式ドキュメントを確認する必要がある
- 依存パッケージをインストールする必要がある
- テストに外部サービスのモックや取得が必要
逆に、次のような依頼では、すぐ許可しない方が安全です。
- よく分からない外部スクリプトを実行する
- 認証情報を使って外部サービスに接続する
- 本番APIや本番DBへアクセスする
- 不明なサイトからコマンドをコピーして実行する
ネットワークアクセスは「必要なときだけ、理由を確認して許可する」が基本です。



ネットにつながると便利だけど、ちょっとむずかしいねぇ。最初は「なぜ必要か」を確認してから許可しよ〜。
5. 秘密情報を渡さない
ひとことで:APIキー、SSH鍵、.env、本番情報はプロンプトに貼らないでください。
Codexに作業を頼むとき、エラー調査のためにログや設定を貼りたくなることがあります。しかし、次の情報は貼らないでください。
- APIキー
- SSH秘密鍵
.envの中身- 本番データベースの接続情報
- 顧客情報や個人情報
- 社内限定の認証トークン
エラー調査に必要な場合は、値を伏せて共有します。
DATABASE_URL=postgres://<user>:<password>@<host>/<database>
OPENAI_API_KEY=<redacted>
また、Codexに「.env を読んで原因を調べて」と頼むのも避けます。必要なのは値そのものではなく、変数名や設定の構造であることが多いです。
安全な依頼文は次のようになります。
`.env.example` と設定読み込み部分を確認してください。
実際の `.env` の値は読まないでください。
必要な環境変数名が足りているかだけ確認してください。
秘密情報は「便利だから一時的に貼る」でも危険です。貼らない運用を最初から習慣にしてください。



APIキーやSSH鍵を貼るのは、絶対ダメだよ。見せなくても調査できる形にして渡そうねぇ。
6. 破壊的操作を避ける
ひとことで:削除、リセット、強制上書き、デプロイは必ず止まって確認します。
Codexにコマンド実行を許可している場合、特に注意したいのは破壊的操作です。次のような操作は、理由を確認し、必要なら自分で実行するくらい慎重に扱ってください。
- ファイルやフォルダの再帰削除
git reset --hardgit clean -fd- ブランチの強制上書き
- 本番環境へのデプロイ
- 本番DBへのマイグレーション
- 権限やセキュリティ設定の緩和
Codexへの依頼文にも、禁止事項として書いておくと安全です。
Constraints:
破壊的なGit操作は実行しないでください。
ファイル削除が必要な場合は、実行前に理由と対象パスを提示してください。
本番環境へのデプロイや本番DBへの接続はしないでください。
「必要そうだから実行した」という事故を避けるため、危険な操作はプロンプトで先に止めておきます。
7. Git差分とチェックポイント
ひとことで:作業前後にGitの状態を確認し、戻せる状態を作ります。


公式Quickstartでは、Codexはコードベースを変更できるため、タスクの前後でGitのチェックポイントを作ることが推奨されています。
初心者向けの最低限の流れは次のとおりです。
- 作業前に
git statusを見る - 未コミット変更がある場合は内容を確認する
- Codexに小さく依頼する
- 作業後に差分を見る
- 必要ならテストを実行する
- 問題なければコミットする、または下書きとして残す
コマンド例です。
git status
git diff
採用する場合は、意味のある単位でコミットします。
git add README.md
git commit -m "docs: update setup instructions"
ここで大切なのは、Codexの変更を人間が読める単位に分けることです。大きな差分を一気に採用するほど、レビューは難しくなります。



差分が読める大きさだと、安心感がぜんぜん違うんだぁ。小さく頼んで、小さくコミットしていこ〜。
8. 初心者向けの安全設定パターン
ひとことで:最初は読み取り、通常作業、ネットワークありを使い分けます。
初心者は、すべての作業を同じ権限で行う必要はありません。目的に応じて、次のように使い分けると安全です。
| 場面 | おすすめ設定 | 依頼例 |
|---|---|---|
| コードを説明してほしい | read-only | このプロジェクトの構成を説明してください |
| READMEやテストを追加したい | workspace-write + 承認あり | READMEを最小限で更新してください |
| 依存パッケージが必要 | workspace-write + ネットワークは必要時だけ承認 | インストール前に必要な理由を説明してください |
| 本番環境に関わる作業 | 原則Codexだけで進めない | 方針案だけ出してください |
最初のおすすめは、次の3段階です。
- read-onlyで調査だけ試す
- workspace-writeで小さな編集を試す
- 必要なときだけネットワークや追加権限を承認する
この順番なら、Codexの動きを見ながら少しずつ任せる範囲を広げられます。
9. 次に読む記事
ひとことで:安全設定を押さえたら、実践ワークフロー集へ進みます。
本記事では、Codexの権限と安全設定を、サンドボックス、承認、ネットワーク、秘密情報、破壊的操作、Git管理の観点で整理しました。
次に読む記事は、CX-06「Codex実践ワークフロー集|修正・レビュー・調査の頼み方」です。安全な境界線を理解したうえで、実務でよく使う調査、修正、レビュー、テスト追加、ドキュメント更新の頼み方をパターン化します。
より深く設定を理解したい場合は、公式の Agent approvals & security、Codex Quickstart、Codex Security を確認してください。なお、Codex Securityはリポジトリの脆弱性検出・修正支援に関する製品であり、本記事の主題であるサンドボックスや承認設定とは別の話題です。



ふぁ……これで安全設定の基本はOKだよぉ。こわがりすぎず、でも雑に許可しすぎず、ちょうどよく使っていこ〜。
この記事とあわせて読みたいCodex記事
ひとことで:この記事の理解を深めるための関連回です。
- CX-02 Codex導入ガイド|App・IDE・CLIの選び方と初期設定
- CX-03 Codexの使い方|最初に試すプロンプトと安全な進め方
- CX-11 Codex Cloud・Automations入門|作業を任せる運用設計
- CX-12 Codexベストプラクティス完全ガイド|失敗しない使いこなし方
Codexシリーズ記事一覧
ひとことで:Codex編は、導入から専門機能まで順番に読めるシリーズです。
- CX-01 Codex入門|できること・始め方・Claude Codeとの違い
- CX-02 Codex導入ガイド|App・IDE・CLIの選び方と初期設定
- CX-03 Codexの使い方|最初に試すプロンプトと安全な進め方
- CX-04 Codexプロンプト設計|Goal・Context・Done whenの書き方
- CX-05 Codexの権限と安全設定|承認・サンドボックス・Git管理(本記事)
- CX-06 Codex実践ワークフロー集|調査・修正・レビューの依頼文例
- CX-07 Codex AGENTS.md完全ガイド|プロジェクト指示を書く方法
- CX-08 Codex MCP入門|外部ツール連携の仕組みと安全な使い方
- CX-09 Codex Skills完全ガイド|作業手順を再利用する方法
- CX-10 Codex Subagents入門|複数エージェントで並列作業する方法
- CX-11 Codex Cloud・Automations入門|作業を任せる運用設計
- CX-12 Codexベストプラクティス完全ガイド|失敗しない使いこなし方








