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

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

Codex は、コードベースを読み、ファイルを編集し、コマンドを実行できるAIエージェントです。便利な一方で、「どこまで許可してよいのか」「勝手に危ないことをしないのか」が気になる方も多いはずです。

本記事では、Codex の権限と安全設定を初心者向けに整理します。承認、サンドボックス、ネットワークアクセス、秘密情報、Git差分、バックアップの考え方を押さえ、安心して使い始めるための基本ルールを作ります。

夕宮たいだ

ふぁ……みんな〜、今日は安全設定の話だよぉ。ちょっと地味だけど、ここを押さえると安心してCodexを使えるんだぁ。

目次

1. Codexの安全設定は何を守るのか

ひとことで:安全設定は、Codexが触れる範囲と、実行前に止まる条件を決めるものです。

Codexの安全設定をサンドボックスと承認ポリシーの2層で示す図
図1:安全設定は「触れる範囲」と「確認する条件」の2層で考える

Codex は、通常のチャットAIと違い、実際の作業フォルダを読み、ファイルを編集し、コマンドを実行できます。そのため、安全設定では次の3つを守ります。

  • ファイル:どのフォルダを読めるか、どこに書き込めるか
  • コマンド:どの操作を自動実行できるか、どこで承認が必要か
  • ネットワーク:外部サイトやパッケージ取得へアクセスできるか

OpenAI公式の Agent approvals & security では、Codexの安全制御は主に Sandbox modeApproval policy の2層で考えると説明されています。初心者向けに言い換えると、サンドボックスは「技術的にできる範囲」、承認ポリシーは「実行前に人間へ確認する条件」です。

この2つを理解すると、「Codexにどこまで任せてよいか」を自分で判断しやすくなります。

夕宮たいだ

ていねいに言うと、サンドボックスは「触れる範囲」、承認は「止まって確認するタイミング」なんだぁ。この2つを分けて考えようねぇ。

2. サンドボックスとは何か

ひとことで:サンドボックスは、Codexが作業できる範囲を区切る仕組みです。

サンドボックスは、Codexがコマンドを実行するときに、ファイルシステムやネットワークへのアクセスを制限する仕組みです。公式ドキュメントでは、CLI / IDE extension ではOSレベルの仕組みでサンドボックスを実現し、通常はネットワークなし、書き込みは作業中のワークスペース内に制限されると説明されています。

初心者がまず覚えるべきモードは、次の3つです。

モードできること向いている場面
read-onlyファイルを読む。編集やコマンド実行は強く制限される調査、説明、レビューだけしたい
workspace-write作業フォルダ内の読み書きができる通常の実装、README更新、テスト追加
danger-full-accessサンドボックス制限なしに近い初心者は使わない
Codexのread-only、workspace-write、danger-full-accessの権限範囲比較
図2:初心者はread-onlyとworkspace-writeを中心に使う

最初は、調査だけなら 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 --hard
  • git clean -fd
  • ブランチの強制上書き
  • 本番環境へのデプロイ
  • 本番DBへのマイグレーション
  • 権限やセキュリティ設定の緩和

Codexへの依頼文にも、禁止事項として書いておくと安全です。

Constraints:
破壊的なGit操作は実行しないでください。
ファイル削除が必要な場合は、実行前に理由と対象パスを提示してください。
本番環境へのデプロイや本番DBへの接続はしないでください。

「必要そうだから実行した」という事故を避けるため、危険な操作はプロンプトで先に止めておきます。

7. Git差分とチェックポイント

ひとことで:作業前後にGitの状態を確認し、戻せる状態を作ります。

Codex作業前後にgit status、git diff、test、commitで確認する安全フロー
図3:Git差分を見てからCodexの変更を採用する

公式Quickstartでは、Codexはコードベースを変更できるため、タスクの前後でGitのチェックポイントを作ることが推奨されています。

初心者向けの最低限の流れは次のとおりです。

  1. 作業前に git status を見る
  2. 未コミット変更がある場合は内容を確認する
  3. Codexに小さく依頼する
  4. 作業後に差分を見る
  5. 必要ならテストを実行する
  6. 問題なければコミットする、または下書きとして残す

コマンド例です。

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段階です。

  1. read-onlyで調査だけ試す
  2. workspace-writeで小さな編集を試す
  3. 必要なときだけネットワークや追加権限を承認する

この順番なら、Codexの動きを見ながら少しずつ任せる範囲を広げられます。

9. 次に読む記事

ひとことで:安全設定を押さえたら、実践ワークフロー集へ進みます。

本記事では、Codexの権限と安全設定を、サンドボックス、承認、ネットワーク、秘密情報、破壊的操作、Git管理の観点で整理しました。

次に読む記事は、CX-06「Codex実践ワークフロー集|修正・レビュー・調査の頼み方」です。安全な境界線を理解したうえで、実務でよく使う調査、修正、レビュー、テスト追加、ドキュメント更新の頼み方をパターン化します。

より深く設定を理解したい場合は、公式の Agent approvals & securityCodex QuickstartCodex Security を確認してください。なお、Codex Securityはリポジトリの脆弱性検出・修正支援に関する製品であり、本記事の主題であるサンドボックスや承認設定とは別の話題です。

夕宮たいだ

ふぁ……これで安全設定の基本はOKだよぉ。こわがりすぎず、でも雑に許可しすぎず、ちょうどよく使っていこ〜。

この記事とあわせて読みたいCodex記事

ひとことで:この記事の理解を深めるための関連回です。

Codexシリーズ記事一覧

ひとことで:Codex編は、導入から専門機能まで順番に読めるシリーズです。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

目次