AIツール
Codex CLIを安全に使い始めるための基本設定
Codex CLIを仕事で試す前に、作業場所、サンドボックス、承認、差分確認をどう決めるかを公式情報と実務用チェックリストで整理します。
- 公開日
- 最終検証
- 次回確認
- 確信度
- HIGH
この記事で分かること
- 初回試用を安全な作業場所に限定する理由
read-only、workspace-write、承認設定をどう使い分けるか- 編集を許可する前に確認すべきGitの状態
- 自動化で守るべき「出力先」と「人の確認」の境界
結論： 初回は、重要なデータを含まない専用フォルダーで
read-onlyを指定し、変更を任せるのはGitで差分を確認できる作業場所だけにします。便利な設定より、対象・権限・戻し方を先に決めることが重要です。
サンドボックスは操作できる範囲を、承認は人に確認するタイミングを決める。二つを別々に確認する。
最初に決めるのは「何をさせないか」
Codex CLIを導入するとき、「コードを書かせたい」という目的だけで作業場所を決めると、関係のない秘密情報や他案件まで読み取れる状態になりがちです。最初に次の三点を紙に書ける状態にします。
- 読ませてよいフォルダーはどこか
- 変更を許可するファイルはどこか
- 意図しない変更が出たとき、誰がどの差分を確認して戻すか
本番データ、秘密鍵、顧客情報、バックアップだけを置いたフォルダーは試用先にしません。実際の案件を使うなら、Git管理済みで、作業前の状態と差分を人が確認できる場所から始めます。
サンドボックスと承認を混同しない
OpenAIのCLIリファレンスでは、サンドボックスは実行・ファイル操作の範囲を決め、承認ポリシーは追加の操作を人に尋ねる扱いです。どちらか一方だけを安全設定と考えないでください。
| 設定 | 向いている作業 | 最初に確認すること |
|---|---|---|
read-only |
構成調査、レビュー、原因調査 | ファイルが変わらないこと |
workspace-write |
Git管理済みプロジェクトの限定修正 | 変更可能な領域と差分確認方法 |
| 広い権限 | 隔離済み検証環境だけ | なぜ狭い権限で足りないのか |
--ask-for-approval never は、安全性を高めるスイッチではありません。承認を求めないだけで、広いサンドボックスと組み合わせれば広い範囲の操作が可能になります。初回の検証では、権限を増やす前に、許可されていない操作が失敗することを確認します。
安全な初回試用の手順
1. CLIとログイン状態を確認する
Get-Command codex -All
codex --version
codex login statusここではバージョンとログイン状態だけを確認します。認証情報、トークン、ログインURLを共有ログやチャットへ貼り付けません。
2. 専用フォルダーで読み取り専用にする
New-Item -ItemType Directory -Force -Path "C:\work\codex-trial"
Set-Location "C:\work\codex-trial"
codex -C "C:\work\codex-trial" --sandbox read-only --ask-for-approval on-request起動後は、まず「このフォルダーの構成を説明してください。作成・変更・削除はしないでください」と依頼します。完了後に別のシェルでフォルダー内容を見て、新規ファイルが生じていないことを確認します。
3. 変更作業はGitの確認から始める
Set-Location "C:\work\my-project"
git status --short
git rev-parse --show-toplevel既存の差分がある場合は、誰の変更かを先に確認します。その後で初めて、作業範囲を限定して workspace-write を検討します。
codex -C "C:\work\my-project" --sandbox workspace-write --ask-for-approval on-request作業後は必ず git diff とテストを実行します。「依頼どおりに見える」ことと「意図したファイルだけが変わった」ことは別の確認です。
非対話実行は、出力を記事や本番へ直結しない
codex exec は自動処理に使えます。公式リファレンスでは、実行ごとに --sandbox read-only、--ephemeral、出力スキーマを指定できます。下書き用途なら、CLI自身に記事や設定を直接変更させず、構造化した最終出力だけを別の出力先へ返す設計にします。
codex exec `
--ephemeral `
--sandbox read-only `
--output-schema ".\automation\schemas\draft.schema.json" `
--output-last-message ".\output\draft.json" `
"指定資料を読み、根拠URL付きの下書き案だけをJSONで返してください。"この例で重要なのはコマンドそのものではなく、次の境界です。
- 読み取り対象を限定する
- 出力は未公開の専用領域だけに置く
- スキーマ、根拠URL、禁止事項を機械的に検査する
- 保存、Gitへの反映、本番公開は別工程で人が判断する
導入時チェックリスト
| 確認項目 | 合格の目安 |
|---|---|
| 作業場所 | 他案件や秘密情報を含まない、対象が明確なフォルダー |
| 権限 | 最初は read-only。拡張理由を説明できる |
| 差分 | 作業前後に git status と git diff を確認できる |
| 出力 | 下書き・ログ・本番公開の保存先が分かれている |
| 停止 | 失敗時に中断し、広い権限へ安易に切り替えない |
| 監査 | 実行日時、対象、結果、承認を必要最小限で追える |
よくある失敗
- いきなり既存の本番リポジトリで試す：まず複製または専用の試用場所で確認します。
neverを自動安全化だと誤解する：承認とサンドボックスを別々に評価します。- 生成結果をそのまま保存・公開する：根拠、差分、影響範囲を人が確認する工程を分けます。
- エラー時に広い権限へ切り替える：不足している権限・パス・入力を特定してから最小限だけ直します。
まとめ
安全な開始は、専用フォルダーを read-only で調べ、Gitの差分確認を習慣化することです。編集や自動化へ進む場合も、対象範囲、出力先、承認、停止条件を分けて設計します。AIにできることを増やす前に、AIにさせないことを明文化してください。
参照した一次情報
確認日：2026年8月10日。製品の表示や利用可能な設定は変わる可能性があるため、実行前に公式リファレンスを確認してください。
PRIMARY SOURCES
確認した一次情報
広告