2児のパパ系Webエンジニア
の開発日記
A Dad-of-Two Engineer's Development Diary

Codexの承認モードとサンドボックスの違いとは?エージェントに任せる範囲を決めた設定

Codexの承認モードとサンドボックスの違いとは?エージェントに任せる範囲を決めた設定

👀 結論から

エージェント系のツールを使っていて一番怖いのは、**性能ではなく「勝手にやられること」**だと思っています。

Codex にはそこを制御する仕組みが2つあって、承認モードとサンドボックスです。

最初はこの2つを同じものだと思っていたのですが、役割がはっきり違うと分かってから設定がすっきりしました。

結論から言うと、サンドボックスで「できること」を絞ってから、承認モードで「聞くタイミング」を決めるという順番で考えるのが分かりやすかったです(・∀・)

💡 承認モードとサンドボックスは別の話

整理すると、こういう関係でした。

仕組み決めているもの
サンドボックスそもそも何を実行できるか
承認ポリシーどのタイミングで人間に確認を挟むか

つまり、サンドボックスが外枠で、承認モードがその中でのふるまいですね。

ここを混同していると、「承認を厳しくしたのに怖い」「サンドボックスを絞ったのに毎回聞かれて面倒」みたいなチグハグが起きます。

私は最初、承認モードだけを厳しくして毎回確認が飛んでくる状態にしてしまい、結局ストレスで緩めるという遠回りをしました(´・ω・`)

🔒 4つの承認ポリシー

現行の承認ポリシーは4種類あります。

  • untrusted: 信頼済みのコマンド以外は確認する
  • on-request: 必要な操作について対話の中で確認する
  • never: 確認しない
  • granular: 承認の種類ごとに細かく制御する

私の使い分けはこんな感じです。

普段の開発は on-request にしています。

全部聞かれると流れが止まるので、エージェント側が「これは確認すべき」と判断したところだけ聞いてもらう形です。

他人のリポジトリや本番に近い環境を触るときは untrusted に上げます。

「信頼済み以外は聞く」なので確認は増えますが、知らないコマンドが黙って走る状態を避けられるのが安心材料になります。

never は、サンドボックスで実行範囲を十分に絞れている前提でしか使っていません。

🔧 config.toml で既定化しておく

毎回オプションで指定するのは現実的ではないので、~/.codex/config.toml に既定値を書いておくのがおすすめです。

ここに既定の承認モードとサンドボックスを書いておけば、起動のたびに指定しなくて済みます。

あわせて、前回書いた AGENTS.md 側にも日本語で禁止事項を書いておくと守りが二重になります。

  • config.toml → 仕組みとしてできることを制限する
  • AGENTS.md → お願いとして触ってほしくない場所を伝える

前者は確実に働く代わりに融通が利かず、後者は柔軟な代わりに絶対ではありません。

両方に書いておくと、片方をすり抜けてももう片方で止まるので、私はこの二段構えにしています。

🎯 どこまで自動で走らせるかの線引き

設定そのものより悩んだのが、**「どこまで自動でやらせるか」**でした。

今の自分の線引きはこれです。

自動でやらせる

  • ファイルの読み取り・検索
  • ビルドやテストの実行(失敗しても壊れない)
  • フォーマッタやリンタの実行

必ず確認を挟む

  • git push などリモートに影響する操作
  • 依存パッケージの追加・削除
  • マイグレーションやデータを触る操作
  • 設定ファイル・CI の書き換え

判断軸はシンプルで、**「間違っていたときに戻すのがどれくらい大変か」**だけ見ています。

ローカルで完結して戻せることは任せて、外に出ていくもの・戻しにくいものは必ず自分で確認する。

この線引きを一度決めてしまえば、あとは設定に落とすだけなので、最初に決めておく価値はかなりあると感じています🤔

🤔 チームで使うときに決めておきたいこと

個人で使うぶんには自分の感覚で決めればいいのですが、チームで Codex を使うなら、最低限のルールを揃えておくのがおすすめです(^^)

私が大事だと思っているのはこのあたりです。

  • 自動で通していいのは「読む」操作まで: ファイルの読み込みやテストの実行は自動、書き込みや外部への通信は確認を挟む
  • ネットワークは基本オフ: 依存パッケージのインストールなど、必要なときだけ許可する
  • 本番の認証情報は渡さない: エージェントが動く環境に、本番の API キーやデータベースのパスワードを置かない
  • 危ない操作の一覧を共有する: git push --force、データベースの削除、マイグレーションの巻き戻しなど、「これは人がやる」と決めた操作を書き出しておく

特に3つ目は、サンドボックスの設定がどうであれ、そもそも手の届く場所に置かないのが一番確実です👀

設定で防ぐのと、置かないことで防ぐのを両方やっておくと、エージェントに任せる範囲を広げるときも安心できます✨

パパ系Webエンジニア〜愛用ガジェット一覧 🛍️

AI開発・執筆に使っている作業デスク環境を楽天ROOMにまとめています ✨ デスク周りの参考にどうぞ 🙌

🙌 まとめ

Codex の承認モードとサンドボックスは、役割が違う2つの仕組みでした。

  • サンドボックス = 何を実行できるか(外枠)
  • 承認ポリシー = いつ確認を挟むか(untrusted / on-request / never / granular)
  • ~/.codex/config.toml に既定値を書いておくと毎回の指定が不要
  • AGENTS.md にも禁止事項を書いて二段構えにすると安心
  • 線引きは「戻すのが大変かどうか」で決める

性能の話より地味ですが、安心して任せられる範囲を決めること自体が生産性に直結すると感じています🙌

※ 承認モードの名称や既定値は今後も変わる可能性があります。最新情報は Codex 公式ドキュメント をご確認ください👀

参考になったらシェアしてもらえるとうれしいです🙌

Xでポスト Threads はてブ LINE
本日のAI速報 10月16日(金)・11件