Codexの設定方法と安全な使い方

結論：Codexの設定は2層に分かれている

Codexで「設定」と呼ばれるものは、常に効き続ける設定ファイル側と、その依頼の間だけ効く指示文側の2つに分かれます。この2つを混ぜて考えると、「設定したはずなのに効いていない」という状態になります。

危険なのは設定ファイルの層です。指示文のミスはその1回で終わりますが、広げた権限は自分で戻すまで残り続けます。「毎回書く注意事項」で安全を担保しようとせず、まず設定ファイル側を絞ってください。

どちらの層の問題かは、同じ依頼をもう一度出すと分かります。指示文を書き直しただけで直るなら指示文の層、書き直しても同じことが起きるなら設定ファイルの層です。

この2層に落とすと、作業を始める前に決めておく項目は次の8つになります。どれかが空欄のまま本番ファイルを対象にしないでください。

• 作業フォルダ
• 対象ファイル
• 触らないファイル
• バックアップ方法
• 報告書形式
• 停止条件
• GitHub連携の有無
• 本番反映の流れ

設定ファイルの層で決めること（config.toml・承認方法・作業フォルダ）

設定ファイルの層で決めるのは、使うモデル、推論の既定、承認の求め方、実行できる範囲の4つです。それぞれに入れる値は環境と時期で変わるため、ここでは「何を決める欄があるか」と「どこで決めるか」だけを並べます。設定ファイルは ~/.codex/config.toml（Windows は %USERPROFILE%\.codex\config.toml）で、ChatGPT デスクトップアプリ・Codex CLI・IDE拡張が同じファイルを読みます。プロジェクトごとの .codex/config.toml は、信頼したプロジェクトでだけ読み込まれます。

この4つのうち、事故に直結するのは下の2つです。承認の求め方と実行できる範囲は、広く設定すると確認の画面が出なくなるだけで、作業中に目立つ知らせが出続けるわけではありません（いまどの設定かは、アプリや IDE拡張では入力欄の下の権限の表示、CLI では /status で確かめられます）。作業が普段より早く終わった時に、後から「止まらなかった」と気づきます。

たとえば「承認を求める」設定でも、作業フォルダの中にあるCSSなら、指示に書いていなくても確認なしで書き換えられることがあります。一度止まって確認を求めるのは、作業フォルダの外のファイルを書き換える時や、インターネットにつなぐコマンドを実行する時です。フルアクセスにするとその確認もなくなり、パソコン上のどのファイルでも、通信が要るコマンドでもそのまま進みます。どちらが正しいかではなく、止まる場所が減れば気づく機会も減るという関係で選んでください。フルアクセスモードにすると承認と権限がどう変わるかを先に読んでおくと、広げた設定を元に戻す条件も一緒に決められます。また、触ってはいけない範囲とSTOP条件を書き出しておくと、権限を広げた時に何が被害範囲になるかが読めます。

作業フォルダも、この層で扱う項目です。作業フォルダそのものは、アプリで開いたフォルダやプロジェクト、CLI では起動したフォルダで決まり、書き込める範囲は既定でその中に限られます。指示文に毎回書く前提にすると、書き忘れた回だけ範囲が広がります。設定ファイル側で読み書きできる場所を絞り、そのうえで指示文に対象を書く、という二重にしておくのが安全です。

更新後に「何で動いているか」を確認する

設定ファイルに model を書いていない環境では、更新のたびに動くモデルが変わることがあります。同じ指示文を出しているのに結果の粒度や所要時間が変わった時は、指示文より先にモデルが入れ替わっていないかを見てください。

Codexで選べるモデルは、増えたり入れ替わったりします。GPT-6 Astra（gpt-6-astra）のような新しいモデルが選べるようになった環境では、既定に任せているかぎり、昨日と同じ依頼を別のモデルが読むことがあります。モデルそのものの性能や料金は姉妹サイトのgptguide.jpで扱っているので、このページでは設定側の扱いだけを説明します。

どの段階の深さで動かすかはCodexの推論レベルで決めてください。設定ファイル側には model_reasoning_effort という既定を置く欄がある、とだけ押さえておけば十分です。

作業フォルダの決め方

作業フォルダは、今回の作業で必ず変わるファイルが入っている一番小さい単位で切ります。Codexには、作業対象のフォルダを明確に伝えます。サイト全体を触る必要がない場合は、対象ページやCSSだけに範囲を絞ると確認しやすくなります。

たとえばトップページの見出しだけ直すなら、対象はそのHTML1枚と、当たっているCSS1枚です。同じ階層にある下書き、書き出し前の画像、過去の退避ファイルは、隣に置いてあっても対象から外します。

• 公開用ファイルと原稿ファイルを分ける
• 秘密情報を含むフォルダを作業対象にしない
• 画像や生成物が多い場合は対象を明示する
• 退避したバックアップの置き場所を作業対象に含めない
• クラウドの同期フォルダを作業対象に入れない

最後の項目は見落としやすい場所です。同期フォルダの中身が変わると、その変更は別の端末へそのまま伝わります。そこで、バックアップと素材をGoogleドライブに置き、作業フォルダから外すと決めておくと、保管場所と作業対象がぶつかりません。

触ってよい範囲を実際にどう決めるか

「作業フォルダを限定する」と書かれていても、具体的にどこで線を引くかは迷います。判断に困ったら、次の順で考えてください。

1. 1. 壊れたら困るものを先に挙げる。公開中のページ、フォーム、決済まわり、認証情報。これらを「触らない側」に置きます。
2. 2. 今回の作業で必ず変わるものを挙げる。1ページのHTMLだけなのか、CSSも含むのか。ここが「触る側」です。
3. 3. どちらでもないものを「触らない側」に寄せる。迷ったら含めない、が原則です。後から足すのは簡単ですが、意図せず変わったものを見つけるのは困難です。
4. 4. 3の判断を指示文に書く。頭の中で決めただけでは伝わりません。

例として、問い合わせフォームのある1ページで見出しと本文だけを直す場合を当てはめます。1では、フォームのPHP、メール送信の設定、.htaccess を「触らない側」へ置きます。2では、そのページのHTMLと、見出しに当たっているCSSの2枚を「触る側」に入れます。3で迷うのは他ページと共有している部品ですが、影響が1ページに収まらないので「触らない側」へ寄せます。4で、この3つの結論をそのまま指示文に書きます。

特に3番です。「たぶん触らないだろう」は範囲の指定になりません。関連しそうなファイルをまとめて渡すと、良かれと思って整えられてしまうことがあります。作業後に「なぜこのファイルが変わっているのか」を調べる時間のほうが、範囲を絞る手間より長くかかります。

最初から「触らない側」へ置いておくのは、秘密情報、設定ファイル、メール設定、サーバー全体設定、.htaccess、DB操作に関わるファイル、バックアップディレクトリです。実在のパスや秘密情報を指示文に書かないことも重要です。必要な場合でも、まず調査だけに留め、変更が必要になりそうなら停止して報告させます。

ここまでの判断は、毎回ゼロから書くと抜けます。目的、対象ファイル、やらないこと、停止条件、確認項目、報告書形式をCodexの指示文テンプレート集の型に当てはめて書くと、書き漏らしが減ります。

停止条件は「起きたら止まる状況」で書く

チェックリストによく出てくる「停止条件を決める」ですが、何をどう書けばよいか分かりにくい項目です。抽象的に「危なそうなら止まって」と書いても機能しません。判断が要らない形にするのがコツです。

右列はどれも「この状況になったら」という客観的な条件になっています。左列は主観の判断を求めているため、判断が自分と違えばそのまま進みます。停止条件を書く時は、「危険かどうか」ではなく「何が起きたか」で書けているかを確認してください。

バックアップと戻し方

バックアップで決めるのは置き場所ではなく、事故が起きた時にどこまで巻き戻すかです。全部を戻す前提にしておくと、うまくいった変更まで一緒に消えます。

戻す単位は「1回の依頼」に揃えます。1つの依頼で3ファイルが変わったなら、その3ファイルをひとまとめにして退避します。ファイル単位でばらばらに退避すると、どれとどれを同時に戻せば元の状態になるのかが、後から分からなくなります。

退避の粒度と保管場所は作業前のバックアップ指示テンプレートを型にして決め、戻す時は直前の変更範囲だけを見て戻す手順に沿って進めます。3段目の照合を省くと、退避はあるのに何が消えたか分からない状態になります。

作業タイプ別の注意点

同じ設定でも、作業の種類によって注意する場所が変わります。着手前に、今回がどれに当たるかを確かめてください。

• HTML/CSSだけ触る作業: 表示と内部リンクを確認する
• PHPやフォームを触る作業: 入力チェックとメール設定を分ける
• sitemap/robotsを触る作業: 既存内容を壊さない
• GitHub連携を使う作業: 権限とPR差分を確認する
• 本番反映作業: バックアップとロールバックを先に決める

外出先から進める場合は、承認と報告の確認までにとどめます。権限や作業フォルダのような設定ファイル側の変更はPCで行うのが安全です。小さい画面では差分の全体が見えず、承認した範囲を読み違えます。スマホからは承認と確認だけにして、設定変更はPCで行う形に決めておくと、移動中の判断ミスが減ります。

設定は一度決めて終わりではない

最初に決めた設定は、作業の種類が変わると合わなくなります。次のタイミングで見直してください。

• 作業の対象が変わった時。1ページの修正から、サイト全体の一括変更に移る時は、範囲も停止条件も別物になります。
• 想定外の変更が起きた時。原因を潰すだけでなく、なぜ範囲外に手が届いたのかを見てください。設定側に穴があります。
• 止まってほしい場面で止まらなかった時。停止条件の書き方が主観に寄っている可能性があります。
• 逆に、止まりすぎて進まない時。条件が厳しすぎると、確認の往復で時間を失います。安全と速度の釣り合いを取り直してください。

最後の項目も実際には問題になります。安全側に振りすぎた設定は、結局「まあいいか」と緩められて元に戻ります。守り続けられる水準に調整するほうが、理想的だが守られない設定より安全です。

設定を変えていないのに動かない時

設定を触っていないのに動かなくなった時は、設定ファイルを開く前にサービス側の状態と自分の利用枠を先に見ます。ここを飛ばして設定を書き換えると、向こうが復旧した後に、変えた設定だけが残ります。

見る順番は次のとおりです。（1）表示されたエラー文をそのまま読む。（2）サービス側の状態と自分の環境を切り分ける手順に沿って、公式statusと codex doctor の結果を分けて確認する。（3）利用の上限に当たっている可能性があるなら、利用の上限とリセットをアカウントで確かめる手順で残量と次回リセットを見る。（4）ここまでで切り分かない時に、はじめて設定ファイルと指示文を疑います。

この順番にする理由は、設定ファイルの変更だけが後まで効き続けるからです。止まっている最中に権限を広げてしまうと、原因が消えた後もその状態で動き続けます。

安全設定チェックリスト

本番ファイルを対象にする前に、8項目すべてに答えられるかを確認してください。

• 作業フォルダを限定した
• 触るファイルを明記した
• 触らないファイルを明記した
• バックアップ方針を決めた
• 停止条件を決めた
• 変更後の確認項目を決めた
• 報告書形式を指定した
• 本番反映前チェックを行う