codex 計画モードの使い方｜計画・確認・実行の分け方

codex 計画モードとは何か

Codex の Plan Mode は、コードをすぐ編集するための通常状態と、調査や相談を中心に進める状態を分ける仕組みです。公式のテンプレートでは、良い計画を作るまで会話を続け、目的と実施内容が決まった段階で具体的な計画を提示する、という順番が示されています。ここでいう計画は「ログイン画面を直す」のような短い宣言ではありません。どのファイルや領域を調べ、何を変更し、どの結果をもって完了とするかを、別の開発者が読み取れる粒度まで落としたものです。

計画モードの価値は、Codex の判断を人が見える場所へ引き出せる点にあります。通常状態では、依頼の解釈とファイル変更が同じ会話の中で進み、前提の誤りに気付く前に差分が生まれることがあります。計画を先に置けば、対象外の範囲、既存仕様との衝突、確認不足の箇所を変更前に指摘できます。計画が長いほど良いわけではなく、後から別の人が迷わず作業できることが基準です。

「計画」と「実行」を分ける理由

修正の依頼では、原因調査と変更作業を一度に頼みたくなります。しかし、原因がまだ確定していない段階で編集を始めると、仮説に合わせてコードを変えてしまい、もとの問題と新しい問題の区別が難しくなります。計画モードでは、まず観察した事実と推測を分け、変更はその後に置きます。これだけで、依頼者が想定していた範囲と、Codex が見つけた影響範囲を照合しやすくなります。

もう一つの理由は、確認の責任を分けられることです。計画中は調査結果を読む人、実行後は差分とテスト結果を確かめる人が必要になります。計画に確認項目が含まれていれば、完成したように見える画面だけで判断せず、既存機能、エラー時の表示、関連ファイルまで見直せます。

まず観察し、次に質問する

現行テンプレートは、環境を調べてから、目的や成功条件について質問する順番を重視しています。リポジトリの構成、設定、既存の命名、テストの位置など、手元で確かめられる情報を先に集める考え方です。これにより、「どのファイルですか」といった確認を利用者へ返す前に、Codex 自身が解決できる不明点を減らせます。

質問をする場合も、何でも聞けばよいわけではありません。仕様として選択が必要な点、複数の実現方法があり結果が変わる点、完了条件を決めるために欠かせない点に絞ります。質問への答えがなくても安全に進められる調査と、答えがなければ計画を確定できない判断を分けると、会話が散らかりません。

2026年8月の公式情報で確認できること

2026年8月12日時点で確認できる中心的な資料は、OpenAI が公開している Codex の GitHub リポジトリ内の Plan Mode テンプレートです。そこでは、Plan Mode を会話型の協働状態として説明し、計画が固まるまでの段階と、変更を伴う実行の境界を明示しています。特定のモデル名やアプリの画面だけを根拠にせず、現行テンプレートに書かれた考え方と、実際に使っている入口の表示を分けて読むことが重要です。参照先は OpenAI Codex の Plan Mode テンプレート です。

現行テンプレートの三つの段階

公式テンプレートが示す流れは、まず環境の事実を集め、次に利用者が何を望むかを確認し、最後に実施内容を具体化する三段階です。最初から実装案を決めるのではなく、対象範囲、成功条件、除外する範囲、選択が必要な点を順に確定します。記事や会話でこの順番を説明するときは、調査、意図の確認、実施計画という三つの見出しに分けると、読み手が自分の作業へ置き換えやすくなります。

この段階分けは、開発規模に関係なく使えます。小さな表示修正なら調査と意図の確認が数往復で済みますが、複数の機能へ影響する変更では、計画の中に互換性、確認方法、失敗時の戻し方まで含めます。短くても判断に必要な情報がそろっていることが大切で、長い文章を作ること自体が目的ではありません。

/plan と Shift+Tab の扱い

公式リポジトリの関連 issue では、CLI で Shift+Tab のショートカットまたは /plan を使って Plan Mode に入る事例が説明されています。これは、通常の入力文に「計画」という単語を入れることとは違います。入口を切り替えたうえで、Codex が調査と質問を中心に応答しているかを見ます。利用している版や画面によって表示が異なる可能性があるため、キー操作の存在だけで全環境の挙動を断定しないようにします。

関連 issue の詳細は Codex の Plan Mode に関する公式 issue で確認できます。issue は製品仕様の説明書そのものではなく、利用者が遭遇した症状と期待される動きを記録する場所です。そのため、Shift+Tab や /plan を使えることと、現在の版で常に同じ結果になることは分けて記録します。

表示と状態がずれるとき

公式 issue には、画面の右下に Plan mode と表示され、ツールの設定も計画向けに見える一方で、応答側は通常状態だと扱って編集を始めた、という報告があります。これはすべての環境で起きると確定した情報ではありませんが、計画モードを使うときの重要な確認材料です。表示を見た直後に大きな依頼を送らず、まず短い読み取り依頼で応答の性質を確かめます。

もし計画中に意図しない変更が起きたら、会話を続けて修正を重ねる前に、変更されたファイルと差分を確認します。原因を版のせいだと決めつけず、表示、使用入口、作業場所、依頼文、変更時刻を記録してください。報告された症状と自分の環境で再現した事実を分けるだけでも、次に行う確認が明確になります。

使い方：計画モードを始める依頼文

Plan Mode に入ったら、最初の依頼でいきなり「全部直して」と書かず、調査と計画の完了条件を明示します。対象、背景、してほしいこと、まだしてほしくないことを一つの依頼に入れると、Codex が調査の範囲を決めやすくなります。特に「変更は計画の確認後」と書いておくと、利用者の意図と計画段階の境界を会話の中で共有できます。

Step 1: 対象範囲を一文で固定する

最初に、どの機能や問題を扱うのかを一文で固定します。「ログインを改善する」では広すぎるため、「期限切れの入力を送ったときの画面表示を調べ、関連する処理と確認方法を計画する」のように、現象と作業の終点を含めます。対象外にしたい画面や、今回はデータ構造を変えないといった境界も書くと、計画が別の課題へ広がりにくくなります。

Step 2: 変更前の調査を依頼する

次に、ファイルの読み取り、参照関係の確認、既存の確認方法の把握までを求めます。依頼文は次のように書けます。

まず対象範囲を読み取りで調べてください。現状の事実と推測を分け、関係するファイル、影響範囲、未解決の疑問を整理してください。計画を提示するまではファイルを変更せず、変更が必要な場合は理由と確認方法を先に示してください。

この文の目的は、読み取りだけを永遠に続けさせることではありません。調査が終わったら、どの情報が計画の根拠になったかを示してもらいます。調べたファイルが少ない場合も、なぜそれで十分なのか、まだ不確かな範囲はどこかを確認できれば、次の判断につながります。

Step 3: 完了条件と懸念点を出す

計画には、変更内容だけでなく「何をもって完了とするか」を入れます。画面なら表示条件とエラー時の振る舞い、処理なら入力と出力、文書なら対象読者と確認者を明記します。関連する既存機能が壊れていないことを確かめる方法も、手元で実行できる確認と目視で見る確認に分けて書くと、作業後に迷いません。

懸念点は、重大さの順に並べます。仕様が決まっていない点、既存利用者への影響、確認できる環境がない点、戻しに時間がかかる点を区別します。懸念を並べるだけで終わらず、回答が必要か、仮の前提で進められるか、いったん見送るべきかまで計画に記録することがポイントです。

Step 4: 計画を確認してから実行へ進む

計画を受け取ったら、すぐに「了解」と返すのではなく、対象、順番、完了条件、対象外の範囲を読み返します。自分が意図していないファイルが含まれていれば、その理由を聞き、範囲を修正してから進めます。計画に変更の前提が残っている場合は、質問への回答を先に行い、Codex が推測で埋めない状態を作ります。

確認が済んだら、どの計画を実行するのかを明示します。途中で新しい影響範囲が見つかった場合は、黙って範囲を広げず、いったん止めて計画を更新します。計画と実行を分ける目的は、変更を遅らせることではなく、途中で判断が変わったことを見えるようにすることです。

計画モードで読むべき出力

計画の品質は、文章の丁寧さよりも、実行する人が追加の推測をせずに進められるかで判断します。出力を読むときは、最初に現状の説明が事実に基づいているかを見ます。次に変更対象が具体的か、順番に無理がないか、確認方法が変更内容に対応しているかを確かめます。最後に、未解決の疑問や仮定が残っていないかを確認します。

対象と対象外が明確か

良い計画には、変更する範囲だけでなく、変更しない範囲もあります。たとえば認証画面の表示だけを直す依頼で、保存形式や利用者情報の構造まで変更対象に含まれていたら、理由の説明が必要です。関連して見つかった箇所をすべて直すのではなく、依頼の目的に直接必要なものと、将来の改善候補を分けて書けているかを確認します。

対象外の範囲は、仕事をしない言い訳ではありません。今は触れない境界を決めることで、差分を小さく保ち、確認しやすくします。将来の課題として残す場合は、現在の完了条件に含めないことを明記します。

変更の単位と順番が分かるか

計画の各項目は、曖昧な「必要な修正」ではなく、どの責務をどう変えるかで表現します。ファイル名だけを並べるのではなく、現行の処理、変更理由、影響する入口を短く説明します。順番は、基礎となる処理、利用者へ見える部分、確認用の追加というように、依存関係が分かる形にします。

順番に複数の選択肢がある場合は、品質、作業量、戻しやすさの違いを示します。採用案を一つに絞れないときは、利用者へ質問を返す段階です。Codex に選ばせる場合も、何を優先して選んだのかを計画に残せば、後から判断を見直せます。

確認方法と完了条件が対応しているか

計画に「確認する」とだけ書かれていたら、何を見ればよいかを具体化します。入力の代表例、失敗する例、境界の値、既存利用者が通る例を分け、どの結果なら合格なのかを記録します。画面の見た目だけでなく、ログ、データ、応答、関連する処理の結果を確認する必要があるかも、変更の性質に合わせて決めます。

完了条件は、変更した人の感覚ではなく、第三者が再確認できる形にします。「問題なく動く」ではなく、「期限切れの入力で指定の文言が表示され、通常の入力では既存の画面遷移が保たれる」のように書くと、確認の漏れが見えます。

未解決の疑問が隠れていないか

計画の最後には、回答が必要な疑問、仮定した事項、調査できなかった事項を分けて置きます。これらを一つの「注意点」にまとめると、実行を始めるべきか判断できなくなります。回答が必要な疑問は質問として返し、仮定は利用者が了承すれば進められる条件として書き、調査できない事項は確認者と確認方法を決めます。

作業中の安全な確認

Plan Mode の目的は、何も触らずに会話を長引かせることではなく、必要な観察を行いながら、変更の境界を明確にすることです。公式テンプレートは、読み取り、検索、設定や構成の確認、変更を伴わない検査など、計画を良くするための調査を許容する一方、ファイル編集や計画を実施する操作は計画段階の外に置いています。実際の利用では、調査と変更を同じ依頼に混ぜないことが最も分かりやすい確認になります。

ファイルを変えない観察を先にする

最初の確認では、対象ファイルの内容、参照関係、設定の読み込み先、既存の確認方法を調べます。読み取り結果を保存する必要がある場合も、対象のリポジトリを変更するのか、一時的な記録にとどめるのかを区別します。調査の途中で生成物や差分が生まれていないかを、作業開始時と計画提示後に確認すると、意図しない変更を早く見つけられます。

計画を承認する前の境界

計画を確認する前は、Codex に編集、削除、移動、外部への公開を頼まない状態を保ちます。提案された変更内容を読むことと、実際に変更を適用することは別の行為です。計画の説明にコード例が含まれていても、説明を読んだ時点でファイルが変わったとは限りません。画面の出力と実際の差分を分けて確認してください。

また、計画の中に利用者が許可していない操作が紛れていないかを見ます。対象外の場所への変更、不要な設定変更、確認のために過大な範囲を調べる提案があれば、目的との関係を問い直します。小さな疑問を残したまま進むより、ここで一度計画を修正した方が後の確認は軽くなります。

変更後の確認を設計する

実行へ移る前に、変更後に何を確認するかを計画へ戻しておきます。代表的な入力と失敗する入力、既存機能への影響、差分の範囲、確認結果の記録場所を決めます。テストがある場合は、既存の確認を通すだけで十分なのか、新しい条件を追加すべきなのかを、変更の理由と結び付けます。

確認で問題が見つかったときの戻し方も、必要な範囲で決めます。単一ファイルの変更なら差分を読み返して戻せるか、大きな変更なら段階ごとに区切るかを検討します。戻し方を先に考えることは失敗を前提にすることではなく、判断を急がずに済む境界線を用意することです。

よくある誤解とトラブル

計画モードは、名前だけを見ると「計画らしい文章を出す機能」と受け取られがちです。実際には、状態、依頼文、作業場所、表示、変更結果を一緒に見なければ、計画段階にいるかを判断しにくい場合があります。公式情報と自分の環境で起きたことを分け、断定できる事実、確認中の事項、まだ分からない事項を別々に扱うことが、トラブル時の基本です。

「計画して」と言えば必ず Plan Mode になるのか

なりません。公式 issue では、依頼文に計画を求める表現があっても、それだけで Plan Mode が有効になるわけではないという説明があります。通常状態のまま計画らしい返答を始めることもあるため、計画を優先したい場合は、利用している入口で明示的に状態を切り替え、表示と応答の両方を確認します。

計画という言葉を依頼文に入れること自体は有用です。対象外、変更禁止の範囲、質問を先に返してほしい条件を伝えられるからです。ただし、それは意図を伝える補助であり、状態の切り替えを保証する操作ではありません。この違いを理解しておくと、計画中に編集が始まったときの原因を誤って決めつけずに済みます。

Plan Mode なのにファイルが変更されたら

まず、会話を続ける前に差分を確認し、意図しない変更がどこで起きたかを記録します。画面に計画表示が出ていたか、どの操作で状態を切り替えたか、最初の依頼が何だったか、変更されたファイルは何かをそろえます。差分がない場合は表示だけの問題かもしれませんが、差分がある場合は、計画を確定する前の状態として扱わず、利用者が内容を確認します。

その後、同じ会話で修正を重ねるか、新しい会話で計画を作り直すかを選びます。重要なのは、原因が明らかでないまま「もう一度だけ」と進めないことです。版の更新、利用している入口、設定、作業場所の違いが影響する可能性があるため、再現条件を小さくして確認します。

計画が長いのに実行できないとき

計画が長くても、対象と完了条件が曖昧なら実行しにくいままです。各項目に、根拠となる現状、変更の目的、確認方法を一つずつ対応させます。背景説明が繰り返されている場合は短くし、逆に未解決の疑問や仮定が抜けている場合はそこを補います。文章量ではなく、判断を残しているかで見直してください。

また、最初から大きな計画を完成させようとせず、調査の区切りで計画を更新します。新しい事実が見つかって対象範囲が変わるなら、変更前に計画を修正し、何が変わったかを説明します。計画を一度作ったら固定するのではなく、根拠が変わったときに更新できるものとして扱う方が、現実の開発に合います。

作業規模別の使い分け

計画モードは、すべての依頼を同じ重さで扱う必要はありません。重要なのは、変更の不確かさと影響範囲に合わせて、確認の深さを調整することです。小さな修正では対象と完了条件を短く固定し、大きな変更では現状、選択肢、影響範囲、戻し方まで確認します。調査だけをしたい場合は、変更しない成果物を求めると境界が保ちやすくなります。

小さな表示修正に使う場合

文言や余白のように対象が絞られている修正では、長い設計書は必要ありません。ただし、どの画面のどの状態を直すのか、通常時と失敗時のどちらを確認するのかは書きます。Codex に関係ファイルを調べてもらい、変更候補と確認方法を数行で出してもらってから進めれば、対象外の画面まで触ることを防げます。

複数の機能へ影響する場合

データの扱い、公開される画面、外部との接続など複数の責務に影響する変更は、計画モードと相性が良い領域です。先に現行の流れを読み、依存している箇所を確認し、選択肢ごとの利点と懸念を整理します。すべてのファイルを一度に変えるのではなく、検証可能な単位へ分けることを計画に含めると、問題が起きた場所を特定しやすくなります。

調査だけを依頼する場合

原因を知りたい、構成を理解したい、変更案を比べたいという依頼では、最初から編集を求めない方がよい場合があります。「現在の状態を説明し、根拠となるファイルと未確認事項を示してください」と伝えれば、計画モードの読み取りを活かせます。調査結果を受け取った後で、別の依頼として修正や検証を頼むと、調査の結論と変更の判断を分けて見直せます。

Codex 計画モードを使うときの確認表

最後に、計画を実行へ移す前に読む確認表をまとめます。これは操作を機械的に増やすためではなく、依頼者とCodexが同じ範囲を見ているかを確かめるためのものです。対象、根拠、変更、確認、未解決の疑問がそろっていれば、短い計画でも実行の判断ができます。

1. 対象の機能、現象、作業場所が一文で説明されているか確認する。
2. 読み取った事実と、まだ確定していない推測が分けられているか確認する。
3. 変更する範囲と、今回は変更しない範囲が明記されているか確認する。
4. 変更の順番と、各段階で見る結果が対応しているか確認する。
5. 通常の入力、境界の入力、失敗する入力の確認方法があるか確認する。
6. 計画を確定する前に答えが必要な質問が残っていないか確認する。
7. 画面の表示だけでなく、実際の差分と確認結果を読む担当者が決まっているか確認する。

公式の実装方針をさらに確認したい場合は、OpenAI Codex のリポジトリ と、そこから参照できる Plan Mode のテンプレート を読みます。Codex CLI がローカルで動くコーディングエージェントであることや、利用入口の案内は 公式 README にまとまっています。個別の画面や版で差があるときは、公式の記述と手元で確認した結果を並べて記録してください。

まとめ

codex 計画モードは、作業を遅くするための待機時間ではなく、調査、意図の確認、実施内容の確定を変更前に分けるための状態です。公式テンプレートが示すように、まず環境の事実を集め、次に成功条件や選択が必要な点を確認し、最後に別の人でも実行できる計画へ具体化します。Shift+Tab や /plan を使う場合も、表示を見ただけで判断せず、短い読み取り依頼と差分の確認で状態を確かめます。

小さな修正では対象と完了条件を短く書き、大きな変更では影響範囲、確認方法、未解決の疑問、戻し方まで含めます。計画中に意図しない変更が起きた場合は、まず差分と再現条件を記録し、計画と実行をいったん切り分けます。事実と推測を分けること、変更前に確認できる形へ整えることを守れば、Codexへ任せる範囲を自分で調整しやすくなります。