Codex Planモード完全ガイド（2026年版）｜Plan→Executeで迷走を止める¶

対象 / ポイント

対象:

Codex CLIで設計と実装を分けて進めたい人
/plan と Read-only の役割差を短時間で把握したい人
古い collaboration_modes 記事との違いを確認したい人

ポイント:

現行の公式導線は /plan [description]
/plan は設計、Read-only は承認制御で役割が違う
古い feature flag 手順や /collab 前提の説明は歴史情報として扱う方が安全

Codexでも Plan→Execute を分離して回す導線が整い、迷走と事故を減らしやすくなりました。

2026年4月17日時点の公式導線

現在のOpenAI公式ドキュメントでは、Codexの計画モードは /plan [description] という built-in slash command として案内されています。いまの公式 Config Reference には collaboration_modes は見当たらないため、旧いコミュニティ記事にある feature flag 手順を現行の正式セットアップとして扱うのは危険です。¹² 本記事は 現行の /plan 導線を主軸 にし、旧手順は歴史メモとして扱います。

Claude Codeユーザーの方へ

Plan運用の移植ポイントは補足1にまとめています。

まず結論：Planの価値は「賢い文章」ではなく「工程分離」¶

Planモードの本質はこれです。

Plan（設計）：やること・やらないこと・手順・検証を先に固定
Execute（実装/実行）：Planを崩さずに実装を進める
迷ったら Planに戻って差分理由を書く（勝手に方針変更しない）

LLMコーディングの事故の多くは「書きながら要件がズレる」ことなので、工程分離が効きます。

Planモードはプロンプト制御であり、ランタイムブロックではありません

Planモードはモデルに「変更を行わない」よう指示しますが、この制約はプロンプトレベルでのみ適用されます。⁵ 重要な作業時には git stash やブランチ分離を併用してください。詳細はハマりどころ #4を参照。

10分で試す：現在の正式導線¶

2026-04-17 時点、OpenAI公式 docs で確認できる現行の入口は /plan [description] です。¹

1) バージョン確認¶

codex --version

まず最新版の挙動を確認します。PlanまわりはUI表記の変化が速いため、古いスクリーンショットより 現在のバージョンと現行 docs を優先する方が安全です。

2) セッション内で `/plan` を実行する¶

/plan fix the auth bug

OpenAI公式の slash commands 一覧には /plan [description] が明記されています。まずはこの built-in command を基準に使うのが現行の正式導線です。¹

3) 追加の安全策が必要なら `Read-only` を併用する¶

公式 docs では、/permissions から Auto / Read-only / Full Access を切り替えられます。³

/plan: 先に計画を作るための built-in command
Read-only: 変更やコマンド実行の前に承認を要求する安全側ポリシー³⁴

この2つは別物です。「まず /plan で設計を固める」 と 「必要なら Read-only で変更権限を絞る」 を分けて考えると混乱しません。

4) 実装に進むときは、そのセッションの最新UIに従う¶

公式 docs は /plan の入口を明示していますが、細かなUI表記や完了後の遷移文言はバージョンで変わりやすいです。古い /collab 手順や古いスクリーンショットではなく、手元の最新UIの案内を優先してください。

旧情報との切り分け¶

2026-04-17時点で、次の切り分けが妥当です。

現行の正式導線: /plan [description]
現行 docs にある安全側ポリシー: /permissions の Read-only
現行 docs で確認しにくい旧情報: collaboration_modes の手動有効化、/collab を主導線にする説明、古いUIヒント前提の操作説明

つまり、現在の公式 slash commands には /plan が明記され、現在の公式 Config Reference には collaboration_modes が見当たりません。さらに、2026-04-17時点で現行の公式 slash command docs を見直した限り、/collab は主導線として確認できませんでした。¹² そのため、最新記事としては、古い feature flag 手順や /collab 前提の説明を前半のメイン導線に置かず、/plan を基準に読む方が安全です。

実務で効く：Planテンプレ3種（コピペで固定）¶

Planモードでは「貼って埋めるだけ」で実装はしません。Planを固めたあと、モードを戻して実装します。

Planが長文化すると逆に遅いので、上限を決めます。

テンプレA：最短（小改修向け / 5〜10行）¶

目的（1行）
変更点（最大3つ）
影響範囲（ファイル/モジュール）
検証（コマンド or 観点）

例：

目的：監査ログをJSON化し、解析を安定させる
変更点：logger出力キー固定／例外時も同形式／既存フォーマットは非対応
影響：api/logger.ts、middleware/log.ts
検証：unit + e2e、サンプルログを jq で整形

テンプレB：堅め（中規模 / 仕様が揺れやすい）¶

Goal / Non-goal
手順（Step 1..N）
互換性（破壊的変更の有無）
ロールバック
テスト計画

埋めた例（そのまま置き換え可）

Goal: 支払いAPIを決済ゲートウェイv2に切り替える
Non-goal: 決済画面のUIは変えない
手順: Step1 トークン発行をv2に差し替え / Step2 Webhook検証を追加 / Step3 旧v1コードを削除
互換性: モバイルv1.8未満は非対応（エラー表示）
ロールバック: フラグ PAYMENTS_V2=false でv1に戻す
テスト: unit(payments/*), e2e(カード/3DS/失敗系)

テンプレC：事故らない（インフラ/権限/監視/課金）¶

リスク（高/中/低）と理由
影響ステークホルダー
監視/アラート/メトリクス変更
実行手順（判定基準・復旧）

埋めた例（インフラ変更向け）

リスク: 中（権限昇格ミスで漏洩の恐れ）
影響ステークホルダー: SRE, セキュリティ, 請求チーム
監視/アラート: CloudWatch AuthzDenied 閾値 5→3 に変更
実行手順:
 1) IAMロール billing-writer にポリシーv3を適用
 2) ログで AssumeRole 成功を確認
 3) カナリアで請求書PDF作成を実行し、失敗ならポリシーv2へ戻す

高度な活用テクニック：逆質問とPLANS.md¶

Planモードをさらに強力にするための2つのテクニックがあります。

1. 「逆質問（Interview you）」アプローチ¶

やりたいことの概要はあるが、要件をうまく言語化しきれない場合に非常に有効です。Planモード中に以下のようにプロンプトを出します。

「〇〇機能を追加したいのですが、まだ要件がふわっとしています。実装方針を固めるために、私の前提を疑い、必要な要件を明らかにするための質問を私にしてください。」

Codexからの質問に答えることで、曖昧なアイデアが具体的な実装計画へと昇華されます。

2. PLANS.md / 実行テンプレートの配置¶

より高度なワークフローの場合、リポジトリ内に PLANS.md や execution-plan-template.md といったテンプレートファイルを配置し、Codexにこれを読み込ませて計画を作らせることができます。定型業務や複数ステップの手順が既に確立しているチームで特に効果的です。

迷走を止める：Plan→Execute「1レーン」運用¶

おすすめは「Planと実装の境界」を運用で固定することです。

Planで合意
- 成功条件（Done）を先に決める
- 手順と検証をテンプレで固定
実装（Coding/Execute側）
- Planに沿って実装
- 途中で要件が動いたら Planに戻って差分理由を追記
検証してDone
- Planに書いた検証を実行し、満たしたら完了

合言葉（おすすめ）：

「成功条件はX。Step1→Step2。迷ったらPlanに戻る。」

ハマりどころ¶

1) 古い導線の記事や投稿をそのまま信じると混乱する¶

検索上位には、初期の collaboration_modes 時代の説明がまだ残っています。しかし現行の公式 docs は /plan を明示しており、計画導線の入口はここに寄っています。

対策としてはこれが堅いです。

入口は /plan を基準にする
安全性は /permissions の Read-only で補う
古いフラグ手順は「歴史メモ」として読む

2) Planが長文化して遅い¶

Planは「書くこと」が目的になると破綻します。テンプレA/B/Cに固定し、上限を守る。

3) 受け渡しが曖昧で"いつも通り"¶

Plan→Executeの橋渡し文（成功条件・手順・迷ったら戻る）を毎回入れる。

4) Planモードはプロンプト制御であり、ランタイムブロックではない¶

Planモードはモデルに「ファイル変更を行わない」よう指示しますが、この制約はプロンプトレベルでのみ適用されます。ランタイムで物理的にブロックされるわけではありません。⁵

実際にはモデルはほぼ確実に指示を守りますが、リスクの高い変更では：

使い捨てブランチや git stash を活用する
/status で意図しないファイル変更がないか確認する
Planモードをコードレビューや CI の代替とは考えない

補足1：Claude CodeのPlan運用をCodexに移植するコツ¶

Claude CodeのPlanが実務で効いた理由は、だいたいこの3つです。

Non-goal を最初に書く（「やらない」を固定）
検証を先に決める（Doneがブレない）
変更が増えるほど差分理由をPlanに残す（意思決定ログになる）

Codexでもこれをそのまま移植すると、Planの価値が出やすいです。

補足2：Planの"ちょうどいい"粒度（判断基準）¶

5分で終わる修正：テンプレA（短く）
半日以上の変更：テンプレB（互換性とロールバック）
事故ったら痛い領域：テンプレC（運用者目線）

補足3：チームで効かせる運用（最小ルール）¶

PR/レビューの前に「Plan（テンプレA以上）」を貼る
Planの差分が出たら、Planに「変更理由」を追記してから実装継続
Done判定はPlanの検証項目で行う（気分で終えない）