CodexのPlan mode（計画モード）とは？/planの使い方と頼み方

「Codexにいきなり頼んだら、思っていたのと違う方向に作業が進んでしまった」「大きな作業を頼みたいが、先に進め方を確認しておきたい」と感じたことはないでしょうか。人に仕事を頼むときも、いきなり作業に入ってもらうより、先に段取りを聞いた方が安心です。

Codexの計画モード（Plan mode）は、その「段取りを先に出してもらう」ためのモードです。/planと入力すると、Codexは実装に入る前に、調べた内容と進め方を計画として提案します。ずれているところを直してから作業に進めば、やり直しの手間が減ります。

この記事では、計画モードの仕組み、入り方と使い方、計画の質を上げる頼み方、/goalや権限設定との違い、推論の深さの設定、計画を残す方法、うまくいかないときの対処までを順に解説します。内容は2026年10月時点のOpenAI公式ドキュメントにもとづいています。公式に書かれていないことは、そのとおり「公式には案内がない」と書いています。

計画モードとは

実装の前に、進め方を提案させるモード

公式のスラッシュコマンド一覧では、/planを「計画モードに切り替え、必要なら依頼も一緒に送る」コマンドと説明しています。目的は、実装作業が始まる前に、Codexに実行計画を提案させることです。

公式のベストプラクティスのページには、計画モードの役割がもう少し具体的に書かれています。Codexが必要な情報を集め、こちらに確認の質問をし、そのうえで実装前に「より確かな計画」を組み立てる、という流れです。難しい作業、あいまいな作業、言葉にしにくい作業では、まず計画させる進め方が勧められています。

向いている場面・向かない場面

計画モードは、すべての依頼で使う必要はありません。計画を読む時間もかかるため、場面で使い分けます。

迷ったときの目安は、「間違った方向に進んだとき、戻すのにどれだけ手間がかかるか」です。戻すのに時間がかかりそうな作業ほど、計画の段階で確認する価値があります。

計画に書かれる内容のイメージ

計画の中身は依頼によって変わります。公式に決まった書式はありませんが、読む側が確認しやすいのは、次のような項目がそろった計画です（記事用に作った例で、実際の出力そのものではありません）。

【目的】研修の申込フォームに「アレルギーの有無」の項目を追加する
【触るファイル】form.html（項目の追加）、send-mail.js（メール本文への反映）
【触らないファイル】料金ページ、トップページ
【手順】1. 現在の項目と送信処理を確認する　2. 項目を追加する　3. メール本文に回答を入れる　4. 画面で表示と送信を確かめる
【確かめ方】テスト用の申込を1件送り、メールに回答が入っていることを確認する
【確認したい点】回答は必須にしますか

この例のように、目的・範囲・手順・確かめ方・未決の点がそろっていれば、人が読んで判断できます。逆に、手順だけが並んでいて「どこを触るか」「どう確かめるか」が書かれていない計画は、そのまま進めると危ない計画です。追加で書くよう頼みましょう。

「計画」には2つの使われ方がある

公式の用語集では、Plan（計画）を「Codexが提案した、または進行を追いかけている、作業の手順」と説明しています。同じ「計画」でも、次の2つの場面があります。

後者は、Codexを自分のシステムに組み込む開発者向けの資料（app-server）に記載があります。計画の各手順が「pending（未着手）」「inProgress（作業中）」「completed（完了）」の状態を持ち、作業の進み具合に合わせて更新される仕組みです。計画モードで出てくる計画の文章も、専用の項目（plan）として扱われると説明されています。普段の利用で意識する必要はありません。

この記事で使う用語

公式ドキュメントには、いくつかの言葉が出てきます。この記事での意味を整理しておきます。

使える画面

公式ドキュメントで計画モードの記載があるのは、次の画面です。

ChatGPTのChatやWorkで依頼の進め方を相談したいときは、Codexの/planではなく、「先に計画を出して。私が承認するまで作業しないで」と依頼文で伝えます。公式のプロンプトの案内にも、進め方が重要なときは計画を求め、社外への送信や公開の前には承認を求める、という考え方が書かれています。

入り方と使い方

計画モードの入り方は、画面によらず基本的に同じです。最初の1回の流れを説明します。

1. Codexの入力欄を開く作業するフォルダ（プロジェクト）を開いた状態で、デスクトップアプリ、CLI、IDE拡張機能のいずれかの入力欄を開きます。
2. /planと入力する入力欄で/planと入力し、Enterを押します。公式では、これでいまのチャットが計画モードに切り替わると説明されています。
3. 依頼を書く切り替えたあと、普通に依頼を書いて送ります。/planの後ろに依頼を続けて書けば、切り替えと依頼を一度に送れます。
4. 確認の質問に答えるCodexが情報を集め、必要に応じて質問を返してきます。答えられるものから答えます。
5. 計画を読んで、直す出てきた計画を読み、ずれている点は同じ会話で伝えて直してもらいます。
6. よければ実装を頼む計画に納得したら、その計画で作業を進めるよう頼みます。

画面ごとの使い分け

計画モードの入り方は共通ですが、計画を読んだあとに使える機能は、画面によって少し違います。公式ドキュメントの記載をもとに、使い分けの目安をまとめました。

非エンジニアの方がまず試すなら、変更点を画面で確認できるデスクトップアプリが取り組みやすいでしょう。計画を読み、直し、実装させ、差分を確認する、という流れを同じ画面の中で完結できます。

入り方の種類

Shift+Tabがどの画面で使えるかの区別は、公式には整理されていません。使えない画面では/planを使ってください。

作業中は/planが使えない

公式のCLIの説明には、Codexがすでに作業しているあいだは、/planが一時的に使えないと書かれています。作業の途中で「やっぱり先に計画を出して」と思っても、切り替えられません。

対処は2つです。ひとつは、作業が終わるのを待ってから/planで計画を頼む方法です。もうひとつは、作業を始める前の最初の1通目から計画モードにしておく方法です。大きな作業は、後者を習慣にすると取りこぼしが減ります。

作業中に方向を変えたいとき

計画モードに切り替えられない代わりに、作業中のCodexには追加のメッセージを送れます。公式では、進行中の作業に指示を足すことを「steer（舵を取る）」と呼んでいます。たとえば、「ここまでの進み具合と、残りの手順を一覧にして。確認するまで次に進まないで」と送れば、その時点での計画を出させて、確認を挟めます。

これは計画モードそのものではなく、依頼文で同じ効果をねらう方法です。切り替えのような専用の仕組みではないため、確実さを求めるときは、作業を止めて、計画モードで頼み直すのが安全です。

計画の読み方

計画が出てきたら、次の4点を確認します。全部を詳しく読む必要はありません。

• 目的：自分が頼んだことの意図と合っているか
• 範囲：触るファイルや画面が、想定より多くないか。触ってほしくない場所が入っていないか
• 順序：戻しにくい変更が、確認の前に来ていないか
• 確かめ方：終わったことを、どうやって確かめるかが書いてあるか

直したい点は、「手順3は不要。ログインの画面には触らないで」のように、番号や場所を指して伝えます。計画の全文を書き直させるより、直したい部分だけを伝える方が、意図が正確に伝わります。

計画を直すときの言い方

計画を直してもらうときは、「全体的におかしい」と伝えるより、どこを・どうしてほしいかを具体的に書きます。

「手順2と手順3の順番を入れ替えて」のように、番号を指して伝える方法も確実です。Codexは会話の流れを覚えているので、計画を最初から書き直さなくても、指摘した部分だけを直してくれます。

実装を頼むときの言い方

計画に納得したら、実装を頼みます。承認の操作の画面表示は公式に書かれていないため、同じ会話で言葉にして伝える方法が確実です。

最後の伝え方は、計画の外に作業が広がるのを防ぐのに役立ちます。計画と実装のずれは、「計画にない変更が必要になったときの扱い」を決めていないことで起きるからです。

計画をコピーして残す

CLIでは、/copyと入力するか、Ctrl+Oを押すと、直前に完了したCodexの出力をクリップボードにコピーできます。公式でも、「最新の完了した回答や計画の文章を、選択せずに取り出せる」と説明されています。コピーした計画は、メモや社内の共有ページに貼って、あとから見返せます。

デスクトップアプリやIDE拡張機能で同じことをしたいときは、計画の文章を選んでコピーするか、「この計画をmarkdownのファイルとして保存して」と依頼します。ファイルに残す方法は、後の章で詳しく説明します。

$planスキルを使う方法

公式のプロンプトの案内には、IDE拡張機能で大きなリファクタリング（動作を変えずに中身を整理すること）を計画する例があります。そこでは、$planというスキルが使える場合に、$planと明示して呼び出す書き方が紹介されています。計画の対象、守る条件、含めてほしい内容（手順ごとの移行計画など）を箇条書きで添えるのが例の形です。

スキルが使えるかどうかは環境によります。使えないときは、/planで十分です。スキルの仕組みは「Codex Skills」の記事で解説しています。

計画を良くする頼み方

計画モードを使っても、依頼があいまいなままだと、計画もあいまいになります。公式のベストプラクティスは、依頼に入れる内容として次の4つを挙げています。

公式は、この4つを入れると、Codexが範囲を絞って動き、思い込みでの判断が減り、結果が確認しやすくなると説明しています。

依頼文の例

非エンジニアの方でも、そのまま使える形にした例です（記事用に作った例です）。

/plan 会社のホームページの「お問い合わせ」フォームに、「希望の連絡方法（メール・電話）」を選ぶ項目を足したいです。
・対象は contact フォルダの中のファイルです
・見た目と、既存の項目の順番は変えないでください
・選んだ内容が、担当者に届くメールの本文に入るようにしてください
・作業を始める前に、触るファイルと手順の一覧を出してください
・分からない点は、作業の前に質問してください

最後の2行が、計画モードで特に役に立ちます。「触るファイル」を先に出させると影響範囲が分かり、「質問してください」と添えると、Codexが思い込みで進めずに、確認を挟んでくれます。

材料の渡し方

公式のベストプラクティスでは、材料を渡す方法として「@でファイルを指定する」ことが紹介されています。CLIの公式の説明には、エラーの画面写真や構成図、デザインの見本を画像として渡す方法もあります。/planに続けて書く依頼でも、文章の貼り付けと画像の添付ができます。

材料は多ければよいわけではありません。公式でも、関係するものに絞るよう勧められています。関係のないファイルまで渡すと、計画の対象がぼやけます。

あいまいな依頼と、はっきりした依頼

同じ作業でも、頼み方で計画の質が変わります。記事用に作った例を並べます。

はっきりした依頼には、共通して「何を」「どこまで」「何は変えないか」が入っています。この3つを意識するだけで、計画を読み直す回数が減ります。

質問に答えるときのコツ

Codexから確認の質問が来たら、次のように答えると、計画の精度が上がります。

• 分かる質問から答え、分からないものは「分からないので、一般的な方法で提案して」と伝える
• 質問の意図が分からないときは、「それは何のために聞いていますか」と聞き返す
• 決めていないことは、「未定。選択肢と、それぞれの影響を教えて」と頼む

質問に答えられないこと自体は、悪いことではありません。「何が決まっていないか」が見えるのが、計画モードの利点のひとつです。

「インタビューして」と頼む方法

公式のベストプラクティスには、計画モードのほかに、Codexに先にインタビューしてもらう方法も紹介されています。やりたいことの大まかなイメージはあるが、うまく言葉にできないときに、Codexに質問させ、前提を問い直させ、あいまいなイメージを具体的な内容に変えてから実装に入る、という方法です。

やりたいことは「社内の備品管理を楽にしたい」です。実装の前に、私に質問して、何を作ればよいかを具体的にしてください。前提がおかしければ指摘してください。

計画モードと組み合わせれば、質問を受けて、答えて、計画をもらう、という流れを1つの会話で進められます。

/goal・権限との関係

Codexには、計画モードのほかにも、作業の進め方を決めるコマンドや設定がいくつかあります。名前が似ていて混乱しやすいため、役割を表にまとめます。

つまり、計画モードは「進め方」、/goalは「ゴール」、権限は「許可の範囲」を決めるもので、役割が重なりません。組み合わせて使えます。

/planから/goalへつなぐ流れ

公式の長時間作業のページには、結果がまだはっきりしないときの進め方が書かれています。まず/planで整理し、そのあとで/goalを使う、という順番です。

1. /planで整理するCodexにインタビューしてもらい、制約を洗い出し、結果を目標の形にまとめてもらいます。
2. 測れる完了条件にする「テストが全部通る」「画面にこの項目が出る」など、あとから確かめられる条件に直します。
3. /goalで始める/goalに目標を書いて送ります。書いた目標が、最初の依頼と完了条件の両方になります。
4. 進み具合を見て、必要なら調整する途中で目標を編集したり、一時停止や再開をしたりできます。

/goalの使い方として、公式のCLIの説明には次のものが書かれています。

目標の文字数は、1〜4,000字です。長い指示は、ファイルに書いておき、そのファイルを指す形にします。/goalの詳しい使い方は、今後の別記事で扱います。この記事では、計画モードとのつながりに絞っています。

依頼文で「計画だけ」と頼む方法との違い

計画モードを使わなくても、依頼文に「実装はせず、進め方だけを教えて」と書けば、計画に近い回答は得られます。ChatGPTのChatやWorkのように、Codexのコマンドが使えない画面では、この方法を使います。

実装に入る前に必ず確認したい作業が多いなら、毎回の依頼に書くより、/planを使うか、AGENTS.mdに決まりを書く方が、書き忘れが起きません。

計画だけで終わらせたいときは、権限を読み取り専用にする

先ほど説明したとおり、計画モードが編集を仕組みとして止めるのかどうかは、公式に書かれていません。一方で、公式の「Agent approvals & security」のページには、「変更せずに、相談や計画だけをしたいときは、/permissionsでread-only（読み取り専用）に切り替える」と書かれています。

読み取り専用にすると、Codexはファイルを読めますが、書き換えはできません。「計画を出させたいが、ファイルは絶対に触ってほしくない」というときは、次のように組み合わせます。

公式の権限のページでは、ほとんどの作業で、まず「Ask for approval」から始めることを勧めています。これは、現在のワークスペースの範囲で作業し、その範囲を超えるときには止まって確認する設定です。

実装のあとの確認：/diffと/review

計画を確認して実装まで進んだら、最後に結果の確認があります。CLIには、そのためのコマンドが2つあります。

公式の機能紹介では、/reviewは作業中のファイルを書き換えずに、優先度のついた指摘を返すと説明されています。計画と、実際の差分を見比べて、計画に書かれていない変更が入っていないかを確かめると、ずれに気づきやすくなります。

計画はローカルで、実装はクラウドで

公式のプロンプトの案内には、計画づくりと実装を分ける使い方が紹介されています。手元のコードを読ませながら計画を作り、長い実装だけをクラウドに任せる、という流れです。公式の例はIDE拡張機能での操作です。

1. 手元で計画を作る作業中の内容をコミットまたは退避して、差分を比べやすい状態にします。そのうえで、リファクタリングなどの計画をCodexに作らせます。
2. 計画を直す「どのファイルがどの段階で動くかを書いて」「戻す方法を入れて」など、不足を足してもらいます。
3. クラウドの環境を用意するあらかじめCodexのクラウド環境を設定しておき、入力欄の下のクラウドのアイコンから選びます。
4. 次の依頼でクラウドに任せる次の依頼を送ると、計画や手元の変更を引き継いだ新しいチャットがクラウドで作られます。公式の例は「Milestone 1を計画どおりに実装して」です。
5. 結果を確認して進めるクラウド側の差分を確認し、必要なら直して、プルリクエストを作るか、手元に取り込みます。段階ごとに繰り返します。

クラウドの作業は、隔離された環境で動きます。公式によると、作業の段階では、環境で許可しない限りインターネットは使えません。計画は手元で、実装は別の場所で、と分けられる点が、この使い方の利点です。

自動レビュー（Approve for me）は、許可を広げない

ほかの記事で「auto mode」と呼ばれることがある設定が、公式でいう「Approve for me」（自動レビュー）です。公式の説明では、承認を求める確認を、人ではなく別のレビュー担当のエージェントに回す仕組みで、Codexができる範囲そのものは広げないとされています。

計画モードで進め方を確認し、権限では範囲を決め、自動レビューは確認の手間を減らすために使う、という分担です。計画モードの代わりにはなりません。

設定と計画書

計画モードの推論の深さを変える

Codexの設定ファイルconfig.tomlには、計画モードだけの推論の深さ（どのくらい深く考えさせるか）を指定する項目があります。公式の設定リファレンスでは、次のように説明されています。

設定ファイルのサンプルには、次のように、計画モードだけhighにする書き方が載っています。

model_reasoning_effort = "medium"
plan_mode_reasoning_effort = "high"

これは、「普段の作業は標準の深さ、計画のときだけ深く考えさせる」設定です。個人用のconfig.tomlは、ホームフォルダの.codexフォルダの中にあります（公式は~/.codex/config.tomlと表記）。プロジェクトごとの.codex/config.tomlは、信頼したプロジェクトでだけ読み込まれます。IDE拡張機能では、歯車のアイコンから「Codex Settings」→「Open config.toml」で設定ファイルを開けます。

計画モードの既定の推論の深さがどのレベルなのかは、公式に数値の案内がありません。実際の値は、使っている画面の表示で確認してください。

設定はどこが優先されるか

同じ項目を複数の場所に書いたときは、公式の設定の説明にある優先順位で決まります。計画モードの推論の深さも、この順位に従います。

会社でCodexを管理している場合は、組織側の設定が優先される項目もあります。画面で選べない設定がある場合は、管理者に確認してください。

推論の深さをどう選ぶか

公式のモデルのページでは、推論の深さは、まず画面で標準になっているものから始め、結果を見て調整するよう勧められています。

深くするほど、時間がかかり、使用量も多く消費します。公式でも、すべての作業を最高にする必要はなく、必要なときに上げるものとされています。ChatGPTの料金と使用量の考え方は「Codexの料金」の記事で説明しています。

モデルとの関係

計画の質は、依頼の書き方に加えて、選んだモデルでも変わります。公式のモデルのページは、2026年10月時点で次のように案内しています。

使えるモデルは、プランや画面、提供状況で変わります。入力欄の下や/modelのメニューには、そのアカウントで使えるモデルだけが表示されます。計画モードだけ別のモデルを指定する設定は、公式の資料では確認できませんでした。モデルは会話ごとに選ぶものと考えてください。

難しい作業を、いくつかの部分に分けて同時に進める「Ultra」というレベルも案内されていますが、公式は「ほとんどの作業にMaxやUltraは必要ない」としています。計画づくりの段階では、まずHighまでで足りるかを試してください。

計画をファイルとして残す（PLANS.md）

長い作業では、計画を会話の中だけでなく、ファイルとして残す方法があります。公式のベストプラクティスは、より高度な使い方として、PLANS.mdや実行計画のテンプレートに沿ってCodexに進めさせる方法を紹介しています。

OpenAIのクックブック（活用事例集）には、この方法の例として「ExecPlan」が載っています。要点は次のとおりです。

• 計画のファイル（PLANS.md）に、計画の書き方のルールを書いておく
• AGENTS.mdに「複雑な機能や大きな変更では、PLANS.mdの計画書を使う」と書いておく
• 計画書は、そのファイルだけを読めば、初めてその作業を見る人でも進められるように書く
• 作業が進むたびに、進み具合や判断の理由を計画書に書き足す（生きた文書として扱う）

公式のクックブックは、このレシピが「アーカイブ済みで、古いモデルやAPIに触れている場合がある」と明記しています。そのまま写すのではなく、考え方の参考にして、自分のプロジェクトに合わせて書き換えるのが前提です。

AGENTS.mdに「計画を出す条件」を書いておく

毎回「先に計画を出して」と書くのが面倒なときは、AGENTS.mdに決まりを書いておけます。公式のベストプラクティスでは、AGENTS.mdは、リポジトリの構成、実行・テストの方法、守る決まり、完了の基準などを書くための、エージェント向けのREADMEと説明されています。

たとえば、次のような内容を書きます（記事用の例です）。

## 作業の進め方
- 3つ以上のファイルを変更する作業では、実装の前に、触るファイルと手順を示して確認を求める
- 完了したら、変更したファイルの一覧と、確かめ方を報告する

AGENTS.mdは、常に守ってほしい決まりを書く場所です。書き方は「Codex AGENTS.md」の記事で解説しています。

活用例

計画モードは、プログラムを書く人だけのものではありません。社内のフォームを直す、Excelの集計を自動化する、ホームページを更新するなど、「何をどの順番で触るか」が大事な作業に向いています。

例：社内の申込フォームに項目を足す流れ

総務の担当者が、研修の申込フォームに「アレルギーの有無」の項目を足す場合を例に、流れを追います（記事用に作った例です）。

1. 計画モードで依頼する「/plan 研修の申込フォームに、アレルギーの有無を書く項目を足したい。見た目は変えない。作業の前に、触るファイルと手順を教えて」と送ります。
2. 質問に答えるCodexから「必須項目にしますか」「回答は担当者のメールに入れますか」と質問が来るので、順に答えます。
3. 計画を確認する変更するファイルが2つ、手順が4つと示されます。「フォーム以外のファイルも変更対象に入っている」と気づいたので、「ほかのページには触らないで」と伝えて直してもらいます。
4. 実装を頼む直した計画に納得したら、その計画で進めるよう頼みます。
5. 結果を確認する作業が終わったら、変更点の一覧（差分）を見て、画面で項目が表示されること、送信したメールに内容が入ることを確かめます。

この流れでは、手順3で「ほかのページに触る」予定が見つかっています。計画を出さずに進めていたら、作業が終わってから気づいていた点です。

部署ごとの依頼文の例

そのまま使える形にした例です（記事用に作った例です）。フォルダ名や条件は、自社に合わせて書き換えてください。

経理：月次の集計表づくり

/plan 「経費」フォルダにある今月分のCSVを、部署別・勘定科目別に集計するExcelを作りたいです。
・元のCSVは書き換えない
・集計の結果は「出力」フォルダに保存する
・合計が元のCSVの合計と一致するかを確かめる手順も入れる
・作業の前に、読み込むファイルと手順を一覧にして、分からない点は質問してください

営業：商談メモの整理

/plan 「商談メモ」フォルダの今月分を読んで、案件ごとに「会社名・次にやること・期限」をまとめた表を作りたいです。
・メモの内容は書き換えない
・期限が書かれていないものは「未記入」と表示する
・実際に作業する前に、どのファイルをどう読むかを示してください

広報：ホームページの文言修正

/plan 会社のホームページの「会社概要」ページで、住所と電話番号の表記を変更したいです。
・新しい表記は「東京都〇〇区…」「03-0000-0000」です
・同じ情報が載っている他のページも全部洗い出して、変更の対象を一覧にしてください
・デザインとレイアウトは変えない
・公開前に確認する手順も添えてください

どの例にも、「元のデータを書き換えない」「作業の前に一覧を出す」という条件が入っています。計画モードの利点は、この「実装の前に確認する」という約束を、依頼の形で固定できることです。

使い始めて1週間の進め方

いきなり大きな作業で試すより、小さな作業で慣れてから広げる方が安全です。次の順番を目安にしてください。

1. 1〜2日目：読むだけの作業で試す「このフォルダの構成を説明して」「この処理がどこにあるか調べて」など、ファイルを書き換えない依頼を/planから出し、計画と回答の形に慣れます。
2. 3〜4日目：小さな変更で試す誤字の修正や、文言の差し替えなど、戻しやすい変更を計画つきで頼みます。計画を読んで、直して、実装させる流れを一巡します。
3. 5日目：差分を見て、計画とのずれを確認する計画に書かれていない変更が入っていないかを、差分と/reviewで確かめます。ずれがあれば、次の依頼文に「触らないもの」を足します。
4. 6〜7日目：決まりを書き残す何度も答えた質問や、毎回書いている条件を、AGENTS.mdに書いておきます。社内で使うなら、計画を出させる作業の基準もこのときに決めます。

/sideで、計画への疑問をその場で確かめる

計画を読んでいて、「この手順の意味が分からない」「この変更は危なくないか」と気になることがあります。そのたびに本線の会話に質問すると、計画づくりの流れが途切れます。

CLIでは、/sideで、いまのチャットから枝分かれした一時的な相談用のチャットを開けます。公式の例は「/side Check whether this plan has an obvious risk（この計画に分かりやすい危険がないか確認して）」です。脇で確認して、本線に戻ります。本線のチャットの記録は別になります。

/forkで、別の案を並べて比べる

進め方に2つの案があって迷うときは、/forkで、いまの会話を複製できます。元の会話はそのまま残るため、片方で案Aを、もう片方で案Bを計画させ、比べられます。どちらを採るかは、計画を読み比べて、人が決めます。

うまくいかないとき・注意点

症状と対処

計画の承認の仕方や、画面に表示されるボタンの名前は、公式ドキュメントには書かれていません。画面の表示に従って進めてください。

計画を承認する前のチェックリスト

計画を読み終えて「実装を進めてよい」と伝える前に、次の項目を確かめます。1つでも「いいえ」があれば、計画の直しを頼みます。

慣れないうちは、このチェックを毎回書き出す必要はありません。「目的・範囲・戻し方・確かめ方」の4点だけでも、見る習慣をつけてください。

結果が違ったときの戻し方

計画を確認して進めても、できあがった結果が思っていたものと違うことはあります。そのときに備えて、作業を始める前に、いまの状態をGitでコミットするか、別の場所に退避しておくと、差分を比べやすく、元にも戻せます。公式のプロンプトの案内でも、計画づくりの前に、作業中の内容をコミットか退避しておくことが勧められています。

気に入った変更はコミットし、気に入らない変更は元に戻します。自分で手を入れたり、変更を戻したりしたときは、そのことをCodexに伝えておくのがポイントです。伝えておかないと、次の依頼で、戻した部分をまた書き換えてしまうおそれがあります。公式のプロンプトの案内にも、同じ注意が書かれています。

計画を出させすぎない

計画モードは便利ですが、すべての依頼に使うと、かえって手間が増えます。1行の修正のたびに計画を読んで承認していると、確認作業が負担になり、肝心の大きな変更で読み流してしまうおそれがあります。

目安として、「戻すのに手間がかかる」「複数の場所に影響する」「公開中のものや、他の人が使っているものを変える」のどれかに当てはまる作業で使います。それ以外は、直接頼んで、/diffで結果を確認する方が、全体の効率はよくなります。

チームで計画をレビューする

複数人で使う場合は、依頼した本人だけでなく、別の人が計画を確認する流れにすると、見落としが減ります。たとえば、計画をマークダウンのファイルで保存し、共有の場所に置いて、確認してもらう方法です。

1. 計画をファイルに残す「この計画をmarkdownのファイルに保存して」と頼み、依頼した人が内容を読みます。
2. 確認する人に渡す社内の共有ページやリポジトリに置き、目的・範囲・戻し方を見てもらいます。
3. 承認してから実装を頼む確認が済んだら、その計画のファイルを材料として指定し、実装を頼みます。
4. 結果を計画と見比べる実装後の差分を、計画のファイルと見比べて、ずれがないかを確かめます。

承認の記録を残したい場合も、計画をファイルにしておくと、あとから「何を確認して進めたか」を見返せます。

使用量について

公式の料金のページでは、ChatGPT WorkとCodexは使用量を共有すると書かれています。計画モードだけの使用量の数字は、公式には案内がありません。計画を出させる分、会話は長くなるので、使用量が増えることは見込んでおいた方が安心です。

残りの使用量は、CLIの/statusや/usageで確認できます。使用量の確認方法は「Codexの使用量の確認」の記事で説明しています。

会社で使うときに決めておくこと

チームで計画モードを使うときは、次のような決まりを先に作っておくと、人によって使い方がばらばらになるのを防げます。

• どういう作業は、計画を出させてから進めるか（例：3つ以上のファイルを変える、公開しているものを変える）
• 計画は誰が確認するか（依頼した人、レビュー担当、両方）
• 計画をどこに残すか（会話のみ、共有ページ、リポジトリのファイル）
• 権限の初期設定（まずは「Ask for approval」とし、読み取り専用を使う場面を決める）

よくある質問

まとめ

計画モードは、「Codexに任せる前に、人が方向を決める」ための仕組みです。大きな作業ほど、最初の数分を計画の確認に使うと、あとの手間が減ります。まずは、影響が小さい作業で/planを試し、計画の読み方と直し方に慣れるところから始めてみてください。

社内でCodexを使い始める段階では、権限の初期設定、AGENTS.mdの書き方、計画を出させる作業の基準など、決めることが増えます。INTERCREATE JAPANでは、Claude CodeやCodexの導入から、社内で使い続けられるルールづくりまでをお手伝いしています。