Codex CLIは、ターミナルからローカルのコードを調査し、編集し、コマンドを実行できるOpenAIのコーディングエージェントです。便利な一方、最初から広い権限で任せるより、「対象プロジェクトで起動する→まず調査させる→必要な範囲だけ変更する→diffとテストで検証する」という流れにすると扱いやすくなります。この記事では、インストールから権限設定、変更後の確認までを現在の公式仕様に沿って整理します。
まず結論：Codex CLIは「対象プロジェクトで起動し、変更後に検証する」
Codex CLIを使うときに最初に意識したいのは、どのディレクトリを作業対象にするかと、どこまでの操作を許可するかです。公式ドキュメントでも、プロジェクトディレクトリでCodexを起動し、そのローカルリポジトリを調査・編集・実行する流れが基本として案内されています。
| 段階 | やること | 確認ポイント |
|---|---|---|
| 1. 対象を決める | 作業するプロジェクトへ移動する | 別リポジトリや親ディレクトリで起動していないか |
| 2. 状態を確認する | git statusなどで開始前の状態を見る | 未コミット変更を把握できているか |
| 3. Codexを起動する | codexを実行する | 画面に表示されるdirectoryと想定が一致しているか |
| 4. まず調査させる | 構成・原因・変更候補を説明させる | 変更前に対象範囲を理解できているか |
| 5. 変更を依頼する | 完成条件と検証条件を指定する | 必要以上に広い変更になっていないか |
| 6. 検証する | /review、git diff、テストを確認する | 意図しない変更や回帰がないか |
Codexにすべてを任せることより、「どの範囲を対象にして、何をもって完了とするか」を人間側が決めることが重要です。特に既存プロジェクトでは、作業開始前のGit状態を把握しておくと、Codexが加えた変更と元からあった変更を区別しやすくなります。
Codex CLIをインストールして初回起動する
OpenAIの公式ドキュメントでは、macOS/Linux向けのスタンドアロンインストーラーのほか、npmやHomebrewなどの方法が案内されています。ここでは公式Quickstartにあるスタンドアロン方式を例にします。
# macOS / Linux
curl -fsSL https://chatgpt.com/codex/install.sh | sh
# インストール後
codex初回起動時は、ChatGPTでサインインする方法など、利用可能な認証方法を選びます。起動後は対話画面からそのまま依頼を書けます。インストール方法や認証方式は更新される可能性があるため、導入時は公式ドキュメントの最新手順を優先してください。
用語解説：Codex CLI
Codexをターミナルから利用するためのコマンドラインインターフェースです。ローカルリポジトリのファイルを調査・編集し、許可された範囲でローカルコマンドを実行できます。
作業ディレクトリを決めてからCodexを起動する
Codex CLIは、起動したプロジェクトディレクトリを基準に作業します。いきなりホームディレクトリや複数プロジェクトを含む上位階層で起動するより、対象リポジトリへ移動してから始める方が作業範囲を明確にできます。
cd ~/projects/sample-app
git status
codexCodexの画面には現在のdirectoryが表示されます。セッション内では`/status`で現在の設定やワークスペースを確認できるため、「今どこを対象にしているか」が曖昧になったら先に確認します。
/status公式ドキュメントでは、作業前後にGitのチェックポイントを作り、必要なら変更を戻せる状態にしておくことも推奨されています。既存の未コミット変更がある場合は、Codexの作業と混ざらないように扱いを決めてから進めると安全です。
最初の依頼は「変更しない調査」から始める
初めて触るリポジトリや影響範囲が読めない不具合では、最初から「直して」と依頼するより、先に構成と原因候補を説明させると変更範囲を判断しやすくなります。
このリポジトリではまだ変更を行わないでください。
次の点だけ調査してください。
1. この機能に関係するファイル
2. 現在の処理フロー
3. 不具合の原因候補
4. 修正する場合に影響しそうな範囲
5. 確認すべきテスト
調査結果と根拠になったファイルを示してください。調査フェーズを分けると、Codexが見ているファイルと人間の想定が一致しているかを変更前に確認できます。特に本番コードでは、問題の原因と修正対象が一致しているかを一度レビューしてから編集へ進める方が手戻りを減らせます。
権限は/permissionsで確認する
Codex CLIでは`/permissions`から、そのセッションでどこまでファイル編集やコマンド実行を許可するかを確認・変更できます。現行の公式ドキュメントでは、代表的なサンドボックスとしてread-only、workspace-write、danger-full-accessが説明されています。
| モード | できることの目安 | 向いている場面 |
|---|---|---|
| read-only | ファイルを調査する。編集やコマンド実行は境界に応じて承認が必要 | 最初の調査、コードリーディング、計画作成 |
| workspace-write | ワークスペース内の編集と通常のローカルコマンドを許可 | 対象リポジトリで実際に修正・テストする |
| danger-full-access | サンドボックス制約を外す | 明確に必要性と影響を理解している場合に限定 |
/permissions公式のAutoプリセットでは、バージョン管理されたフォルダで`workspace-write`と`on-request`の組み合わせが案内されており、ワークスペース外の編集やネットワークアクセスなど境界を越える操作では承認が必要になります。変更せず相談・計画したい場合はread-onlyへ切り替えられます。
用語解説：sandbox（サンドボックス）
Codexが読み書き・コマンド実行できる範囲を制限する仕組みです。作業ディレクトリ内だけを書き込み可能にするなど、エージェントの実行境界を作るために使います。
権限は「強いほど便利」と考えず、必要な操作に合わせて選びます。特に外部ネットワークやワークスペース外への変更が関わる場合は、何のための操作かを確認してから承認する方が安全です。
変更依頼は「対象・完成条件・検証条件」をセットで伝える
Codexにコード変更を依頼するときは、実装方法を細かく指定する前に、どこを対象にし、何が満たされれば完了か、何を壊してはいけないかを明示するとレビューしやすくなります。
対象:
- src/features/profile 配下
目的:
- プロフィール更新時の二重送信を防ぐ
制約:
- APIのリクエスト形式は変更しない
- 既存の画面文言は変更しない
- 関係のないリファクタリングは行わない
完了条件:
- 送信中は再送できない
- 成功・失敗時に再び操作できる
検証:
- 既存テストを実行する
- 必要なら今回の回帰を防ぐテストを追加する
- 最後に変更ファイルと検証結果を要約する「きれいに直して」「最適化して」のような広い依頼では、検索意図とは別のリファクタリングまで入りやすくなります。変更対象と非対象を明確にし、最後に何を確認するかまで書いておくと、成果物を人間が判断しやすくなります。
変更後は/review・git diff・テストで確認する
Codexが変更を完了したら、その説明だけで終了せず、実際の差分とテスト結果を確認します。Codex CLIには`/review`があり、未コミット変更、コミット、ベースブランチとの差分などを対象にレビューできます。公式ドキュメントでは、専用レビューは作業ツリーを変更せず、優先度付きのFindingを報告する流れとして案内されています。
/reviewCLI外でも、Gitで差分を確認しておくと意図しない変更を見つけやすくなります。
git status
git diff --stat
git diff- 依頼していないファイルまで変更されていないか
- 設定値・依存関係・生成ファイルが意図せず変わっていないか
- エラー処理や境界条件が抜けていないか
- 既存テストと追加テストが通っているか
- テストを実行できなかった場合、その理由が明示されているか
テストコマンドはプロジェクトごとに異なるため、Codexに勝手なコマンドを想定させるより、package.json、README、CI設定などから既存の検証手順を確認させる方が確実です。
Codex CLIとIDE・クラウドを使い分ける
CodexはCLI以外にもIDEやクラウドなど複数の利用面があります。CLIは、ローカルのターミナルと既存開発ツールを中心に作業したい場合に向いています。
| 利用面 | 向いている作業 | 特徴 |
|---|---|---|
| Codex CLI | ローカルリポジトリの調査・編集・コマンド実行・レビュー | ターミナル内で開発ループをまとめやすい |
| IDE extension | エディタでコードを見ながらAIを使う | 編集しているコードの近くでやり取りしやすい |
| Codex cloud | クラウド環境へタスクを委任する | ローカルを離れて並行作業を進めたい場合に使える |
すでにVS Code中心で作業していて補完やエディタ内支援を重視するなら、CLIだけに統一する必要はありません。目的に応じて使い分けます。
（CodexとGitHub Copilotの違いや使い分けも比較したい場合については『CopilotとCodexの違いと使い分け10選｜VS Codeで効率化するAI開発ガイド』をご参照ください）
Codex CLIで起きやすい使い方のミス
| ミス | 起こりやすい問題 | 対策 |
|---|---|---|
| 対象より上位のディレクトリで起動する | 作業範囲が分かりにくくなる | 対象リポジトリへcdしてからcodexを起動する |
| 未コミット変更を確認せず始める | 元の変更とCodexの変更が混ざる | 開始前にgit statusを確認する |
| 最初から広い修正を依頼する | 原因調査と無関係な変更まで増える | 調査と編集を分け、対象を限定する |
| 権限を確認せず操作を進める | 意図しない範囲の操作を承認しやすい | /permissionsと/statusを確認する |
| 完了メッセージだけで判断する | 回帰や不要差分を見落とす | /review、git diff、テスト結果を確認する |
Codex CLIを安全に使うためのポイントは、AIへの依頼文を長くすることだけではありません。作業対象、実行権限、変更差分、テストという4つの境界を人間が確認できる状態にすることが重要です。
よくある質問
Codex CLIはどのディレクトリで起動すればよいですか？
基本は作業対象のプロジェクトやリポジトリへ移動してから`codex`を実行します。起動後は画面のdirectoryや`/status`でワークスペースを確認し、想定した範囲になっているか確かめてください。
Codex CLIでコードを変更させず、調査だけできますか？
できます。変更しないことを依頼文で明示するだけでなく、必要に応じて`/permissions`からread-onlyの設定を選ぶと、調査・計画と編集を分けやすくなります。
Codexが変更したコードは必ず正しいですか？
保証されません。変更後は`/review`やGit差分を確認し、プロジェクトの既存テスト・型チェック・Lintなど必要な検証を実行してください。テスト未実行なら、その状態を完了扱いにしない方が安全です。
Codex CLIでは毎回すべてのコマンドで承認が必要ですか？
いいえ。必要な承認はサンドボックスと承認ポリシーによって変わります。現行のAuto設定ではワークスペース内の通常作業を進め、境界外の編集やネットワークアクセスなどで承認を求める構成が案内されています。`/permissions`で現在の設定を確認できます。
まとめ：Codex CLIは「任せる範囲」と「検証」をセットで使う
- 対象プロジェクトへ移動してからCodex CLIを起動する
- 開始前にgit statusと/statusで作業状態・範囲を確認する
- 初めてのタスクは調査と編集を分ける
- /permissionsで必要な権限だけを選ぶ
- 変更依頼には対象・制約・完成条件・検証条件を含める
- 変更後は/review、git diff、テストで結果を確認する
Codex CLIは、ターミナルで調査から編集・検証までつなげられるのが強みです。最初は小さな変更から始め、どのファイルを触ったか、どのコマンドを実行したか、何を検証したかを確認できる運用にすると、既存プロジェクトへ取り入れやすくなります。
