今さら聞けない Codex CLI 入門 第2回:基本の使い方と、勝手に書き換えさせない設定

Codex CLIの基本の使い方と、どこまで自動で任せるかの設定を表したイメージ図 ITライフハック
この記事は約8分で読めます。
当ページはプロモーションが含まれています

Codex CLI を調べていると、説明が食い違っている記事に出くわします。

「suggest / auto-edit / full-auto の三段階で切り替えます」と書いてあるものと、「サンドボックスと承認ポリシーを組み合わせます」と書いてあるもの。どちらが正しいのか分からなくなる。

答えを先に書きます。後者が現在の形です。

以前は三段階のモードで指定していましたが、いまは「触れる範囲」と「止まって聞くタイミング」が、別々の設定になっています。この2つを組み合わせて使います。

古い記事が残っているので混乱しますが、仕組みが分かれば、むしろこちらのほうが分かりやすいです。

サンドボックスと承認ポリシーという2つの軸が独立して効くことを示した図

スポンサーリンク

この記事で分かること

  1. 基本の頼み方
  2. サンドボックスと承認ポリシーの違い
  3. 目的別の組み合わせ
  4. 古い記事の三段階モードとの対応
  5. 止め方と、やり直し

スポンサーリンク

1. 基本の使い方

1-1. 2つの動かし方があります

対話モードで起動する。

codex

やり取りを続けながら作業します。長い作業には、こちらが向いています。

1回だけ実行する。

codex "このリポジトリが何をするものか説明してください"

聞いて、答えて、終了します。短い用事には、こちらが速いです。

1-2. どこで起動するかが大事です

作業したいプロジェクトのフォルダで起動してください。

Codex は、起動したフォルダとその中身を見ます。上の階層で起動すると、関係のないファイルまで読みにいって、時間もクレジットも余計に消費します。

cd ~/projects/my-app
codex

1-3. 頼み方の基本

日本語で頼めます。ただ、曖昧な言い方は通じません。

× この関数をいい感じに整理して

○ この関数を、20行以内になるように分割して。
  分割した関数には、何をするかが分かる名前を付けて

「読みやすく」「適切に」といった基準は、人によって違います。 こちらの頭の中にしかない基準は、伝わりようがありません。

1-4. 一度に全部を頼まない

大きな依頼を丸ごと投げると、全体としては形になるのに、細部が雑になります。 しかも、どこがまずいのかを探すのが大変です。

まず、どう直すつもりかを説明してください。
実際の変更は、確認してからお願いします

分けて頼むほうが、結果的に早いです。方向が違っていたときに、戻る距離が短くて済みます。


2. 2つの軸を理解する

ここが、この記事の中心です。

2-1. 役割が違う2つの設定

Codex の自動化は、役割の違う2つの設定を組み合わせて作ります。

サンドボックス。 Codex が触れられる対象を決めます。ファイル、ネットワーク。

承認ポリシー。 Codex が作業を止めて確認する場面を決めます。

この2つは、独立して効きます。 ここが大事です。

たとえば「承認は要らない」と設定しても、サンドボックスが読み取り専用なら、書き込みは弾かれます。 逆に、サンドボックスを広げても、承認ポリシー次第では毎回止まります。

2-2. サンドボックスの種類

設定 触れる範囲
読み取り専用 ファイルを読むだけ。書き換えない
ワークスペース書き込み 作業フォルダの中なら書き換えてよい
全アクセス 制限なし(通常は使わないでください

普段使うのは、真ん中です。 プロジェクトのフォルダの中は自由に触れて、その外には出られない。この状態が、いちばんバランスが取れています。

codex --sandbox workspace-write

2-3. 承認ポリシーの種類

設定 止まるタイミング
要求時に確認 サンドボックスの範囲を超える操作のときに聞く
確認しない 止まらない。範囲外の操作はブロックされる

「確認しない」を選んだ場合の挙動が、少し分かりにくいので補足します。

止まらないのですが、サンドボックスの外に出ようとする操作は、承認を求められるのではなく、そのまま拒否されます。 つまり「聞かずに実行する」のではなく「聞かずに止める」動きになります。

codex --sandbox workspace-write --ask-for-approval on-request

これが、日常的に使いやすい組み合わせだと思います。プロジェクトの中は自由に作業でき、外に出るときだけ確認が入ります。

2-4. なぜ2つに分かれているのか

一見すると面倒ですが、組み合わせられるのが利点です。

「書き換えは自由にしていいが、外部への通信は必ず確認したい」といった調整ができます。1つのスイッチでは、こうした細かい設定はできません。


3. 目的別の組み合わせ

目的に応じたサンドボックスと承認ポリシーの組み合わせを示した図

実際の場面ごとに、おすすめの設定を書きます。

3-1. まず様子を見たい

読み取り専用で起動します。

codex --sandbox read-only

ファイルを一切書き換えません。 「このコードは何をしているのか」「どこを直せばいいか」を聞くだけなら、これで十分です。

初めてのプロジェクトで試すときは、まずこれから始めるのが安全です。

3-2. 普段の作業

codex --sandbox workspace-write --ask-for-approval on-request

プロジェクトの中は自由に、外に出るときだけ確認。 日常的にはこれで問題ないと思います。

3-3. 止まらずに走らせたい

テストを回しながら直させる、といった繰り返し作業では、いちいち止まると煩わしいことがあります。

その場合、承認を「確認しない」にします。 ただし、サンドボックスは広げないでください。

範囲外の操作はブロックされるので、暴走はしません。 ここが大事な点です。

3-4. やってはいけない組み合わせ

codex --yolo

サンドボックスも承認も、両方なしという設定です。

何が起きても止まりません。 使い捨ての環境や、壊れても困らないコンテナの中でない限り、使わないでください。

同じことが、設定ファイルでも指定できます。個人の全体設定に書かないでください。 必要なときだけ、その場で指定する形にしてください。


4. 古い記事との対応

検索すると、三段階のモードで説明している記事が出てきます。混乱しないよう、対応を書いておきます。

古い書き方 いまの考え方
suggest 読み取り専用に近い。提案はするが、変更には承認が要る
auto-edit ファイルの編集は自動、コマンド実行の前に確認
full-auto サンドボックス内なら、編集もコマンドも自動

書き方が変わっただけで、やりたいことは同じです。

ただ、古いフラグがそのまま使えるとは限りません。 記事に載っているコマンドがエラーになったら、世代が違う可能性を疑ってください。

手元で使える形は、これで確認できます。

codex --help

この記事の内容と食い違っていたら、そちらが正しいと思ってください。


5. 途中で切り替える

起動したあとでも、設定を変えられます。

/approvals

承認まわりの設定を、その場で変更できます。

作業の性質が変わったときに使います。 調査のあいだは読み取り専用、実装に入るときに書き込みを許可する、といった切り替えです。

5-1. 更新でリセットされることがあります

注意点があります。Codex を更新すると、設定したモードが初期状態に戻ることが報告されています。

「昨日と同じはずなのに、やたら確認が出る」と感じたら、更新が入っていないか確認してください。


6. 止め方と、やり直し

6-1. 止める

動いている途中で止めたいときは、Ctrl + C です。

方向が違うと思ったら、遠慮なく止めてください。 最後まで走らせてから直すより、途中で止めて指示し直すほうが早く、クレジットの節約にもなります。

6-2. 変更を確認する

作業のあと、何が書き換わったのかは自分で確認してください。

git diff

6-3. Git を使ってください

これは強くおすすめします。

どの承認モードで使うにしても、Git のリポジトリの中で作業していれば、変更を戻せます。 これがあるかないかで、安心感がまったく違います。

まだ使っていないなら、練習用フォルダでもいいので、git init してから試してください。

git init
git add -A
git commit -m "作業前"

これだけで、いつでも元に戻せる状態になります。


7. プロジェクトのルールを渡す

毎回同じ説明をしているなら、ファイルに書いておけます。

プロジェクトのルートに AGENTS.md という名前で置くと、Codex が起動時に読み込みます。

# このプロジェクトについて

- PHP 8.1 以上で動作します
- 関数は20行以内、ネストは3段まで
- 出力は表示の直前にエスケープしてください
- vendor/ と node_modules/ の中は編集しないでください

「読みやすく」ではなく、判定できる形で書くのがコツです。詳しくは第4回で扱います。


8. 最初にやってはいけないこと

大事なファイルがあるフォルダで、いきなり試さない。 まずは練習用のフォルダで慣れてください。

Git のない状態で、書き込みを許可しない。 戻せなくなります。

--yolo を試しに使ってみない。 「どうなるか見てみよう」で使うものではありません。

設定ファイルの全体設定に、強い権限を書かない。 うっかり常用することになります。


まとめ

  • 動かし方は2通り。対話モード1回だけ実行
  • プロジェクトのフォルダで起動する。 上の階層だと余計に読み込む
  • 自動化は2つの軸の組み合わせ。触れる範囲(サンドボックス)止まる場面(承認ポリシー)
  • この2つは独立して効く。 承認なしでも、サンドボックスが読み取り専用なら書き込めない
  • 日常は「作業フォルダ内は書き込み可 + 範囲外は確認」が使いやすい
  • 「確認しない」設定でも、範囲外の操作はブロックされるので暴走しない
  • --yolo は使わない。 壊れても困らない環境限定
  • 古い記事の三段階モードは、いまの2軸に置き換わっている。codex --help が正解
  • 更新するとモードがリセットされることがある
  • Git の中で作業する。 どのモードでも、戻せる状態を先に作る

設定の話が長くなりましたが、ここを一度整理しておくと、あとが楽です。 「勝手に書き換えられるのが怖い」という不安は、範囲を決めてしまえば消えます。

次回は、コマンドと起動オプションの一覧をまとめます。用途から引ける形にするので、手元に置いておく用の回になります。

※本記事の情報は2026年8月時点のものです。承認まわりの仕様は変更されることがあるため、最新の情報は codex --help および公式ドキュメントをご確認ください。

タイトルとURLをコピーしました