Codex plan modeの使い方｜計画を確かめて、合意した範囲だけ実装へ渡す

CodexのPlanモード（plan mode）は、ファイルを変える前に調査と質問と計画の提案を受けるための機能です。ChatGPTデスクトップアプリ、Codex CLI、IDE拡張では/planで切り替え、JetBrains IDEではモードの選択欄でPlanを選びます。要件がまだ固まっていない依頼に向いています。この記事では、入り方の違いのあと、計画に何を書かせるか、対象・依存・テスト・未決事項をどう確かめるか、合意した範囲だけを実装へ渡す方法を、編集部が小さな教材で試した結果を添えて説明します。

この記事は、OpenAIの公式資料（Best practices、Developer commands、Slash commands、Codex IDE extension、Prompting、Long-running work、Permissions、Agent approvals & security、Configuration Reference）とJetBrainsのヘルプ（いずれも2026年10月31日に確認）に基づく解説です。実測の範囲は、手元のCodex CLI 0.166.0で、小さな教材の写しでPlanモードを動かし、1回は実装まで通した確認だけです。デスクトップアプリ、IDE拡張、JetBrains IDEの画面は試していません。実際のサービスのコードでも試していません。

Codex Planモードとは：変更の前に調査と質問と計画を受け取る状態

公式のPromptingの資料は、複数の手順がある作業で、編集する前にCodexに調べさせ、進め方を提案させたいときに/planを使うよう案内しています。Codex CLIのコマンドリファレンスでも、実装を始める前に実行計画を提案させるコマンドとして説明されています。

公式のBest practicesは、複雑な作業、曖昧な作業、うまく説明しにくい作業では、コードを書き始める前に計画させるよう勧め、Planモードを「文脈を集め、確認の質問をし、より強い計画を作らせるもの」と説明しています。

普段の依頼との違いは、依頼の後に何が返ってくるかです。普段の依頼では、Codexは依頼に沿って作業を進めます。Planモードでは、まず質問と計画が返ってきて、それを読んでから実装するかを決められます。

上の使い分けは編集部の整理です。公式資料は、依頼の種類ごとの基準までは示していません。依頼文全般の書き方はCodexとは？使い方と仕事でできること、コマンド全体の見取り図はCodexのスラッシュコマンドで説明しています。

Planモードの入り方：アプリ・CLI・IDE拡張・JetBrainsの違い

入り方は、使っている場所によって違います。アプリのスラッシュコマンドの資料などの記載を整理すると次のとおりです。

Best practicesは/planかShift+Tabで切り替えると案内しています。編集部のCLIではShift+Tabで切り替わり、画面下の表示にPlan modeと出ました。もう一度押すと元に戻りました。別の場所でのキー操作は試していないので、自分の画面で確かめてください。CLIで依頼まで続けて書く例は次のとおりです。

/plan このサービスの移行計画を提案してください

JetBrainsのヘルプは、Collaboration modeの選択肢をDefaultとPlanに分けて説明しています。Read-onlyやWorkspace accessなどのOperation modeとは別の欄です。

Codexが作業している間は、/planは一時的に使えません。CLIでは、作業中にスラッシュコマンドを打ってTabを押すと、今の作業が終わった後に実行されるよう予約できます。今の作業を止めて計画に切り替えるか、終わるのを待つかは、作業の内容を見て決めます。

Planモードの推論の強さは、設定リファレンスにあるplan_mode_reasoning_effortで変えられます。指定しないと、Planモードに組み込まれた既定の値が使われます。編集部のCLIでlowを指定すると、切り替えたときにModel changed to gpt-6-astra low for Plan mode.と表示されました。設定ファイル自体の書き方はCodexのconfig.tomlで説明しています。

教材で試した結果：/planの質問のあとに計画と実装の確認が出た

編集部は、Planモードで実際に何が返るかを確かめるため、部門別の集計がまだない小さな教材を作りました。売上のCSVを読んで合計を1行だけ表示するreport.py、テストのtest_report.py、部門が空欄の行を1行含むsales.csvの3つのファイルです。この教材の写しをgitで管理し、読み取り専用のサンドボックスで、CLIから次の依頼を出しました。時間を短くするため推論の強さはlowにしました。質問には推奨の案を選びました。

/plan report.py に部門別の集計を足したいです。
出力の形や空欄の扱いはまだ決めていません。
実装の前に、調べた結果と、変更するファイル、
影響するもの、テスト、私が決めるべきことを
計画にしてください。

流れは次のとおりでした。

1. 調査：Codexはファイルを読み、report.pyを実行して合計が28万円であることを確かめました。内訳は営業17万円、開発8万円、部門が空欄の行が3万円だと報告しました。この環境にはpytestがなく、テストランナーで実行できなかったことも報告しました。
2. 質問：Question 1/2で出力の形を、Question 2/2で空欄の扱いを聞いてきました。それぞれ案が3つ並び、推奨の案にはRecommendedが付き、どれでもない場合の選択肢もありました。
3. 計画：変えるファイル、変えないファイル、期待する出力の例、影響、テストと完了条件をまとめた計画が出ました。
4. 実装の確認：最後にImplement this plan?と聞かれました。

ここまでの間、3つのファイルのSHA256とgitの状態は変わりませんでした。条件を少しずつ変えて計6回動かすと（うち1回は入力の手違いで依頼文の先頭が崩れた回です）、出力の形の推奨は「合計の下に足す」の回と「オプションで足す」の回があり、質問も2問の回と3問の回がありました。計画は毎回同じものが返るとは限らないので、読んで確かめる手順が要ります。

書き込みを許可すると編集されるのかを試した

上の確認は読み取り専用だったので、ファイルが変わらないのがPlanモードの効果とは言えません。そこで、書き込みを許可したサンドボックス（workspace-write）で、report.pyに決まった1行を今すぐ追加するよう頼みました。同じ文をPlanモードと通常のモードに1回ずつ出しています。この確認は画面からではなく、Codex CLIに含まれるApp Server（プログラムからCodexを動かす仕組み）から行いました。承認を求めない設定で、推論の強さはlowです。

記録から分かるのは、Planモードの回ではCodexが書き込みを試みず、読み取りのコマンドだけを動かしたことです。サンドボックスが書き込みを拒否した記録はありません。編集が起きなかった仕組みまでは、この確認では分かりません。各1回の小さな確認なので、どんな依頼でも編集が起きないことを保証するものでもありません。必ず変更を防ぎたいときの扱いは、後の節で説明します。

Planモードへの依頼に書いておくこと

計画の質は、依頼で何を聞くかで変わります。公式資料は、よい依頼の要素として、欲しい動き、関係するコードや再現の手順、守る条件、確かめ方を挙げています。Planモードでは、そこに「まだ決めていないこと」を足します。

/plan 〔やりたいことを1文で〕
決まっていること：〔変えてはいけない動き、守る条件〕
まだ決めていないこと：〔出力の形、例外の扱いなど〕
計画に入れてください：調べた結果、変更するファイル、
影響するもの、実行するテスト、私が決めること

教材では、未定と書いた出力の形と空欄の扱いが質問になりました。公式の長時間作業の資料も、結果がまだはっきりしない場合は/planから始め、ChatGPTに聞き取りをさせて制約を洗い出すよう案内しています。

計画を実装の前に確かめる4つの項目

計画を読むときは、文章の長さや丁寧さではなく、次の4つが具体的かを見ます。これは編集部が決めた確認の基準です。例は教材で返ってきた計画から取りました。

読むときに気をつけたい点が2つあります。1つは、質問されなかった点もCodexが決めていることです。教材の計画には「表示順・空白除去・「未分類」の統合は上記を既定方針とします」と書かれていました。ここに異論があれば、実装を選ぶ前に直します。もう1つは、Codexが確かめたことと、これから確かめる予定のことを分けて読むことです。教材の計画でも、pytestでのテストは「実装時に」行う予定として書かれていました。区別が曖昧なら、聞き直します。CLIでは、/copyかCtrl+Oで直前の完了した出力をコピーできるので、計画の文章をチームに回すときに使えます。

Planモードの計画を実装へ渡す手順

計画を読み、自分で決める点に答えたら、実装へ渡します。計画の提案と実装の開始は別の段階です。CLIでは、計画の後に次の3つの選択肢が出ました。公式資料にはこの画面の説明が見当たらないので、編集部のCLI 0.166.0での表示です。版によって変わることがあります。

実装を選ぶとすぐに編集が始まるので、やらないことがあるなら選ぶ前に計画を直します。次の順番で進めます。教材で試したのは2と4です。

1. 質問に答えます。答えが変わると計画も変わるので、更新された計画を読み直します。
2. 範囲を計画に書かせます。No, stay in Plan modeを選び、今回やることとやらないことを伝えます。教材では、下の文を送ると「変更しないもの」の項目がある計画に直り、もう一度Implement this plan?が出ました。
3. 権限を確かめます。実装に切り替わった後は、そのときの権限の設定で動きます。
4. 実装を選びます。教材では、書き込みを許可し、承認を求めない設定でYes, implement this planを選びました。

次の範囲に計画を直してください。
やること：report.py に部門別の表示を足す。
test_report.py にテストを足す。
やらないこと：sales.csv の変更、
合計の計算方法の変更。
部門が空欄の行は「未設定」として集計します。
完了の条件：追加したテストと
既存のテストが通ること。

結果として変わった教材のファイルはreport.pyとtest_report.pyだけで、sales.csvは変わりませんでした。実行時にできる__pycache__は別に残りました。1回の小さな教材での結果なので、範囲を書けば必ず守られるという意味ではありません。IDE拡張とアプリの実装の案内は試していません。資料では/planはPlanモードの切り替えと説明されています。JetBrains IDEで実装へ進むときは、選択欄をDefaultに戻す形になると読めますが、画面では試していません。

計画が大きいときは、最初の一部分だけを実装させ、結果を見てから次へ進めると、やり直しが小さくなります。公式のPromptingの資料でも、計画を段階に分け、最初の段階からクラウドで実装する例が示されています。

実装の後に計画と差分を照らす

計画に合意しても、実装が計画どおりとは限りません。実装が終わったら、計画に書いた「変えるファイル」「やらないこと」と実際の差分を照らします。CLIなら/diffで変更を見て、/reviewでコードレビューを始められます。

完了の条件も読み直します。教材では、計画の完了条件は「テストが通ること」でした。Codexはpytestを用意できず、標準ライブラリのunittestからテストの関数を動かして、5件すべて成功と報告しました。こうした代わりの確かめ方で足りるかは、人が判断します。レビューの進め方はCodexのコードレビューで説明しています。

長い作業は/goalへ渡す

何度かのやり取りを続ける作業なら、計画を固めた後に/goalへ進める方法もあります。公式資料は、Planモードで成果・制約・確かめ方を整理してから、測れる完了条件をつけた目標として/goalで始める流れを案内しています。Goalモードが使える場合に限られます。

Planモードと権限の設定は別物：実行前に両方見る

Planモードは、作業の進め方を決めるモードです。公式の権限の資料が説明するサンドボックスと承認は別の仕組みで、どのファイルやネットワークに触れるか、いつ止まって確認するかを決めます。JetBrainsのヘルプでも、Planを選ぶCollaboration modeと、Read-onlyやWorkspace accessなどのOperation modeは別の設定です。

公式資料の書き方にも差があります。JetBrainsのヘルプは「変更をせずに分析し提案する」と書き、OpenAIの資料は「編集の前に」「実装の前に」と書いています。Agent approvals & securityの資料は、変更せずに話したり計画したりしたいなら/permissionsでread-onlyに切り替えるよう案内しています。

そこで編集部では、次のように使い分けることをすすめます。

• 変更を確実に防ぎたい調査：Planモードだけに任せず、権限もread-onlyにします。編集が起きなかったのを確かめたのは1回だけで、その仕組みも確かめていないためです。公式資料も、変更せずに計画したい場合はread-onlyを案内しています。
• 実装に切り替える前：CLIなら/permissions、アプリとIDE拡張なら入力欄の下の権限の欄を見ます。教材を読み取り専用のサンドボックスのまま、必要な時に承認を求める設定で実装へ進めると、編集の前に承認の確認（Yes, proceed）が出ました。公式資料は、普段の作業ではAsk for approvalから始めるよう勧めています。
• 計画の中のコマンド：本番のデータやネットワークに触れるコマンドが含まれていないかを読みます。止めたいコマンドは、Codexのrulesで確認や禁止にできます。

/planが使えない・期待と違う時の確認順

まとめ：Planモードは計画を読み、範囲を決めてから実装へ渡す

CodexのPlanモードは、要件が固まっていない依頼で、実装の前に調査と質問と計画を受け取るための機能です。入り方は/planかJetBrains IDEのPlanで、作業中は/planが一時的に使えません。計画は対象・依存・テスト・未決事項の4点で確かめ、やらないことまで計画に書かせてから実装を選びます。実装の後は、計画と差分を照らします。変更を確実に防ぎたいときは、権限もread-onlyにします。

チームでPlanモードをどの作業に使い、誰が計画を確かめるかを決めたい場合は、法人向けのご相談も受け付けています。