Codexおすすめ設定｜安全に使う項目と選び方を実務で整理

Codexおすすめ設定を考える前に、基準を固定する

Codexの設定に唯一の正解があるわけではありません。読むだけの調査、既存ファイルを直す開発、外部情報を参照する確認では、必要な権限と確認の頻度が違うからです。最初から広いアクセスを与えて応答を速くするより、作業の目的、対象の場所、変更してよい範囲、確認が必要な操作を先に決めるほうが、結果をレビューしやすくなります。おすすめ設定とは、便利な項目を最大まで有効にすることではなく、目的に対して余分な許可を増やさない初期値です。

OpenAIの公式説明でも、Codexのサンドボックスと承認は別の制御として扱われています。サンドボックスはファイルやネットワークへ届く範囲を定め、承認ポリシーは境界を越える操作の前に止まる条件を定めます。二つを同じ意味で考えず、まず境界を決めてから確認の強さを選ぶと、設定を読んだ人にも意図が伝わります（出典: Running Codex safely at OpenAI）。

設定は「能力」より境界を先に決める

モデルを高性能なものへ変えても、対象フォルダーが曖昧なままなら確認すべき差分は減りません。先に「このリポジトリ内だけ」「この作業では読むだけ」「このコマンドは確認してから」と境界を文章にし、そのあとでモデルや推論の強さを選びます。境界が決まっていれば、設定を変更したときも、結果の違いをモデルの違いと許可範囲の違いに分けて考えられます。

安定版と試験版を分けて記録する

Codex CLIは安定版と試験版が並行して公開されることがあります。試験版を試すこと自体は悪くありませんが、設定の検証記録に版番号を書かないと、挙動の変化を設定ミスと取り違えます。確認表には、版番号、確認日、使った入口、設定ファイルの場所、実施した小さな作業、結果を残し、安定版と試験版の結果を一つにまとめないようにします。

2026年8月時点で押さえたいCodexの更新

おすすめ設定を決める前に、現在のクライアントがどの版なのかを見ます。Codex CLI 0.147.0は2026年8月7日に公開され、プラグインカタログの検索、会話のセクション整理、承認を見直すための--approve-for-me、Cursor管理のスキル取り込み、MCPの新しい仕様への対応などを公式リリースに掲載しています。また、Windowsのバックグラウンド処理やパスの扱い、日本語表示に関する修正も記載されています（出典: OpenAI Codexのリリース一覧）。設定を見直す理由として十分な更新ですが、全項目を有効にする理由にはなりません。

一方、0.148.0-alpha.6は8月10日にプレリリースとして掲載されています。公式ページで確認できるのは版番号、公開日時、配布物などが中心で、個別の変更内容を読み取れる説明は確認できませんでした（出典: Codex CLI 0.148.0-alpha.6）。したがって、導入文で触れるべき「なぜ今か」は、安定版の更新と試験版の公開が続いていることです。「alpha.6でこの設定が変わった」とは断定せず、まず版番号と基本動作を確かめます。

0.147.0は設定を見直すきっかけになる

0.147.0の変更には、カタログ、会話の整理、承認、MCP、Windowsなど、設定と利用環境に関わる項目が含まれます。これは、以前の設定がそのまま使えないという意味ではありません。更新後に設定の優先順位、作業場所、承認の表示、外部情報の取得方法を小さな作業で確かめ、問題がなければ変更範囲を広げる、という確認のきっかけとして捉えます。

alpha.6は版番号と症状を分けて確認する

プレリリースの版番号を見つけても、目の前の症状がその版の変更によるものだとは限りません。まずcodex --versionで表示を残し、起動、設定の読み込み、短い読み取り、限定した編集の順に分けます。どの段階で違いが出たかが分かれば、版の問題なのか、設定の優先順位なのか、作業場所の状態なのかを絞り込めます。

まず使いやすいCodexおすすめ設定

最初の設定は、便利さよりも原因を追えることを重視します。以下は、個人のユーザー設定または検証用のプロファイルに置く最小構成の例です。モデル名は契約や利用できる版によって変わるため、手元の選択画面や公式ドキュメントで確認してください。web_search = "cached"は、公式の設定説明で示されているWeb検索の方式の一つで、最新ページを直接取得する必要がない調査から始めるときに向きます。

# ~/.codex/config.toml または検証用プロファイル
model = "gpt-5.6"
approval_policy = "on-request"
sandbox_mode = "workspace-write"
web_search = "cached"

この組み合わせは「何でも許可する」ものではありません。作業場所内の読み書きと通常のローカルコマンドを進めつつ、範囲外への書き込みや外部接続など、境界を越える操作では確認を求める考え方です。現在のキー名や挙動は更新で変わる可能性があるため、設定を保存したら公式の設定リファレンスと実際の表示を照合します。

modelは作業内容に合わせて固定する

モデルは、難しい作業ほど高い推論設定を選べばよいという単純な項目ではありません。短い調査、既存コードの読み取り、小さな修正、広い設計変更では、必要な時間と確認の深さが違います。最初は利用可能な標準モデルを固定し、同じ入力で結果を比べたいときだけ変更します。モデルを毎回変えると、設定の問題と回答品質の差を切り分けにくくなるため、記録にはモデル名と確認日を含めます。

approval_policyは確認のタイミングを決める

approval_policy = "on-request"は、サンドボックス内の通常作業を進め、境界を越える必要があるときに確認する出発点です。読み取りだけを行う調査ではuntrustedを検討し、検証のために確認を減らす場合も、対象フォルダーと実行する内容を先に限定します。neverを便利さだけで常用すると、意図しない操作を見つける機会が減るため、用途と範囲が明確な場合に限ります。

sandbox_modeは作業場所の範囲を決める

read-onlyはファイルを読む調査、workspace-writeは現在の作業場所内で編集する開発、danger-full-accessは境界を外して扱う設定です。日常の開発では、まずworkspace-writeを選び、必要なときだけ書き込み先を増やします。公式のサンドボックス説明でも、アクセス範囲と承認ポリシーを組み合わせて考えるよう案内されています。

Web検索は必要な鮮度で選ぶ

Web検索は常に最新情報を直接取得すればよいわけではありません。仕様の概要や既知の公式説明を読むならcachedで十分な場合があり、当日のリリースや障害状況を確認するときだけ、利用できる方式と出典を確かめます。検索結果は外部の文章なので、設定例やコマンドをそのまま実行せず、公式ドキュメントへ戻って内容を確認してください。

目的別に設定を分ける

一つの設定をすべての作業に使い回すと、調査には広すぎ、実装には確認が多すぎる状態が生まれます。目的ごとに小さなプロファイルを用意すると、設定を変えた理由が明確になり、同じ条件を再現できます。設定の基本では、ユーザー設定、プロジェクト設定、プロファイル、CLIの指定が別の層として説明されています。最初は下の三つ程度から始め、必要性が分からない項目は追加しません。

調査用はread-onlyから始める

初めて触るリポジトリ、依頼内容がまだ曖昧な不具合、更新直後の挙動確認では、まずread-onlyを選びます。Codexには「構成を読み、関係するファイルと確認すべきテストを説明して」と依頼し、ファイルが変わっていないことを確認します。調査の結果を読んでから、編集が必要な範囲だけを次の設定へ移すと、最初の理解と変更を混ぜずに済みます。

通常開発はworkspace-writeを基本にする

自分が確認できる作業フォルダーで、小さな修正とテストを任せるならworkspace-writeが扱いやすい設定です。ただし、書き込み可能な場所が広いほど、依頼文に対象外を明記する価値が上がります。「このファイル群だけ」「公開APIは変えない」「テスト結果を先に報告する」と伝え、差分を確認してから次の依頼へ進みます。

外部接続や拡張は別の確認にする

MCPサーバー、プラグイン、Web検索などを追加すると、Codexが参照できる情報や呼び出せる機能が増えます。接続できたことは、実行してよいことの証明ではありません。提供元、読み書きの範囲、返ってくるデータ、失敗時の表示を一つずつ確認し、最初は読み取り中心の作業で試します。0.147.0ではMCPの対応範囲やプラグインカタログも更新されたため、導入前後で版番号と接続状態を記録します。

Windowsではサンドボックスの初期状態も見る

WindowsでネイティブにCodex CLIを使う場合、公式の設定説明には[windows]テーブルのサンドボックス設定が案内されています。管理者権限を使える環境で推奨値が適用できるか、適用できない場合の代替値で何が変わるかを確認します。Windowsではパス表記、作業フォルダー、バックグラウンド処理の終了状態も結果に影響するため、同じ設定でも確認場所を分けて記録します（出典: Codex設定の基本）。

設定ファイルの置き場所と優先順位

Codexの設定が効かないときは、値そのものより先に「どのファイルが読まれたか」を確認します。公式ドキュメントでは、CLIフラグと--configによる一時的な指定、プロジェクト内の.codex/config.toml、プロファイル、ユーザーの~/.codex/config.toml、システム設定、組み込みの既定値という順に優先順位が整理されています。画面やCLIで一時的に指定した値が、ユーザー設定より優先される点を忘れると、ファイルを直しても結果が変わりません。

ユーザー設定とプロジェクト設定を分ける

すべての作業で使いたい既定値はユーザー設定へ、特定のリポジトリでだけ必要な値はプロジェクト設定へ分けます。プロジェクト内の設定は共有しやすい反面、信頼していない場所のファイルを読み込ませることになります。初めて取得したリポジトリでは、設定の内容を読んでから信頼状態を判断し、知らない値が入ったまま読み込まれないようにします。

一回だけ変える項目はCLIで確認する

新しいモデルやサンドボックスの値を試すだけなら、設定ファイルを書き換えず--configやCLIオプションで一回だけ指定します。結果がよければ、何を標準にしたいのかを決めてからファイルへ移します。戻すべき値が分からなくなる問題を避けるため、試したコマンド、確認したファイル、結果、元の設定を同じメモに残します。

プロファイルで調査と開発を切り替える

調査と開発でサンドボックスや確認の強さを変える場合は、プロファイルが便利です。例えば調査用にread-only、通常開発用にworkspace-writeを用意し、選んだ名前を作業記録へ残します。プロファイルを増やしすぎると選択を誤るため、「調査」「通常開発」「更新検証」のように目的が一目で分かる名前にし、使わなくなったものは整理します。

# ~/.codex/review.config.toml
model = "gpt-5.6"
approval_policy = "on-request"
sandbox_mode = "read-only"
web_search = "cached"

初回におすすめ設定を試す手順

設定を保存して終わりにせず、変更した項目が実際の作業へ反映されたかを小さく確かめます。いきなり大きな機能追加を依頼すると、設定の影響と依頼の複雑さが混ざります。次の順番なら、読み取り、編集、確認、必要な外部情報という層を一つずつ確かめられます。

1. codex --versionを実行し、安定版か試験版か、表示された版番号、確認時刻を記録します。0.147.0と0.148.0-alpha.6の公式ページを見比べ、版番号だけで変更内容を推測しないようにします。
2. 現在のconfig.tomlの場所と設定値を確認し、ユーザー設定、プロジェクト設定、プロファイル、CLI指定のどれが使われているかを分けて記録します。元の値を保存してから一項目だけ変更します。
3. read-onlyでリポジトリの構成を説明させ、ファイルが変更されていないことを確認します。対象の場所、除外する場所、確認に使うテストを答えさせ、設定の読み込みとモデルの応答を同時に見ます。
4. workspace-writeとon-requestへ切り替え、短い文言の変更や一つのテストの修正など、戻しやすい作業を一件だけ依頼します。差分、テスト結果、変更されなかったファイルを確認し、許可範囲が想定どおりか判断します。
5. Web検索やMCPなど外部情報が必要な作業は、通常の編集とは別に試します。出典URL、参照した時刻、取得方法、返ってきた内容を記録し、検索結果の文章をそのまま設定やコマンドへ変換しません。
6. 期待と違う結果が出たら、モデル、設定の場所、版番号、作業フォルダーのうち一つだけを変えて再確認します。複数の項目を同時に変えず、どの変更で結果が変わったかを残してから標準設定を決めます。

設定が効かないときの切り分け

設定変更の失敗は、値が間違っているとは限りません。別の場所のファイルが優先されている、プロジェクトが信頼されていない、CLIの一時指定が残っている、版によってキーの扱いが違う、といった原因でも同じ症状になります。表示されたメッセージと設定ファイルを先に記録し、再インストールや広い権限への変更は最後に回します。

毎回確認を求められるとき

approval_policyだけを見るのではなく、sandbox_mode、現在の作業場所、実行しようとしている操作を分けます。作業場所の外へ書こうとしているなら確認が出るのは想定内です。プロジェクト設定が読まれていない場合は、信頼状態と設定ファイルの場所を確認し、CLIの一時指定が残っていないかを見ます。確認を減らすことを目的に広いアクセスへ変える前に、対象の操作が本当に必要かを見直します。

変更したのにファイルが変わらないとき

read-onlyが有効なまま、または編集対象が作業場所の外にある可能性があります。まずCodexへ現在の作業場所と変更対象を説明させ、実際のパスを確認します。プロジェクト設定がユーザー設定より優先される場合もあるため、設定の層を上から順に読みます。Windowsでは相対パスと絶対パスの表示が混ざりやすく、同じ名前の別フォルダーを見ていないかも確認します。

検索結果が古く見えるとき

cachedは、公式の説明でもWeb検索の既定方式として扱われる方式です。当日のリリースや障害のように鮮度が必要な確認では、現在の設定がどの方式を使っているかを確認し、必要なら公式ページをブラウザーで直接開きます。検索結果に更新日やURLがなければ、事実として採用せず、OpenAI、GitHub、Cursorなど提供元の公式ページへ戻ります。

更新後に挙動が変わったとき

版番号を固定して同じ依頼を試し、安定版と試験版を別の記録にします。0.147.0の公式リリースには多くの変更がある一方、0.148.0-alpha.6のページは個別の変更内容を詳しく説明していません。したがって、「更新したから直った」「alpha.6で追加された」と急いで結論を出さず、起動、設定読み込み、読み取り、編集、外部接続のどこで差が出たかを確かめます。

Codexおすすめ設定の確認表

設定をチームや別の端末へ移すときは、設定値だけを共有するのではなく、何を確認したかを残します。特に、承認とサンドボックスを同じ「安全設定」として一行にまとめると、どこまで書けるのか、いつ止まるのかが不明確になります。次の表を確認メモに写し、利用する入口や版が変わるたびに結果を更新すると、問題が起きたときの比較材料になります。

この表で未確認の欄があっても、すぐに設定を広げる必要はありません。未確認の理由を残し、低リスクの読み取り作業で埋めます。設定変更前後の差分を見比べることで、Codexが変えたコードと、利用者が変えた設定を分けて確認できます。

まとめ

Codexおすすめ設定は、モデルを最大にすることではなく、目的に対して必要な範囲だけを許可し、結果を確認できる状態を作ることです。通常の出発点は、作業場所を限定するworkspace-write、境界を越えるときに確認するon-request、調査時のread-only、必要な鮮度に合わせたWeb検索です。ユーザー設定、プロジェクト設定、プロファイル、CLI指定の優先順位を把握し、版番号と確認日を記録すれば、更新後の違いも追いやすくなります。

2026年8月7日の0.147.0は、承認、Windows、プラグイン、MCPなどを見直すきっかけになる更新でした。8月10日の0.148.0-alpha.6は、公開された事実と詳細な変更内容を分けて扱う必要があります。最初は読み取り、小さな編集、差分確認、必要な外部情報の順に試し、設定を一項目ずつ調整してください。公式情報はCodex設定の基本、サンドボックス、リリース一覧を起点に確認できます。