結論: Codex Plan Modeは、AIが実装に入る前にタスクを徹底的に分解・整理する「計画専用フェーズ」です。/planコマンドまたはShift+Tabで起動でき、フレッシュなコンテキストでの計画立案・並列エージェントへのタスク割り当て・トークン消費の最適化という3つの強みを持ちます。
この記事の要点:
- Plan Modeは「計画中はファイルを一切編集しない」という読み取り専用の安全機構で、AIの暴走を防ぐ
- 並列エージェントと組み合わせることで、単独実行比で最大60%のトークン削減が実証されている
- 適切なPlan Mode活用で複数エージェントの同時並走・gitブランチ分離・タスク分解の全工程を自動化できる
対象読者: Codex CLIを日常的に使うエンジニア・開発者、AIコーディングワークフローの生産性を上げたいIT担当者
読了後にできること: 今日の開発タスクに/planコマンドを組み込み、実装ミスによるトークン浪費を防ぐ
「なんでAIが途中で全然違う実装をし始めるんだろう…」
先日、とある企業の開発チームでCodexを使っていた担当者から、こんな相談を受けました。聞いてみると、タスクを投げてそのまま実行させたら、途中でディレクトリ構成を勝手に変更し始めて、最終的に全リファクタが走ってしまったとのこと。作業時間にして丸1日分のトークンが消えていたそうです。
これ、実はCodexを使い始めた多くの人が経験するパターンなんです。問題はCodexの能力ではなく、「計画なしに実装フェーズに入れてしまう」ワークフローにあります。
この問題を根本から解決するのがPlan Modeです。Codexが2026年に強化したこの機能は、「まず計画だけ作る、実装はその後」という分離設計によって、AIドリフト（意図から外れた実装）とトークン浪費の両方を防ぎます。
この記事では、Plan Modeの仕組みから実際のコマンド活用法・並列エージェントとの組み合わせ・Claude Codeとの比較まで、コピペ可能なコマンド例とともに完全解説します。
Plan Modeとは何か — フレッシュコンテキストでタスクを分解する仕組み
Plan Modeの本質は一言で言うと「AIが手を動かさず、頭だけを使うフェーズ」です。
通常のCodexセッションでは、プロンプトを送った瞬間にAIが実装に取り掛かります。単純なタスクならこれで問題ありません。ただし複雑なリファクタリング・マルチファイル編集・アーキテクチャ変更になった瞬間に、AIは「なんとなく正しそうな方向」に走り始めます。これがいわゆるAIドリフトです。
Plan Modeを使うと、AIはまず以下を行います:
- 既存コードベースを読み込んでコンテキストを構築（ファイル編集は一切しない）
- タスクのゴール・非ゴール・制約条件を整理する
- 実装ステップをマイルストーン単位で分解する
- 各ステップの完了基準を「人間が検証可能な形」で明文化する
- ユーザーに計画を提示してフィードバックを求める
この一連の流れの中で、ファイルの書き込みは一切発生しません。OpenAIの公式ドキュメントには「Plan mode tells the model not to write or modify files」と明記されています（Codex Best Practices参照）。
「フレッシュコンテキスト」が重要な理由
4月のアップデートでPlan Modeに「フレッシュコンテキスト開始」オプションが追加されました。これは、長時間セッションで蓄積された不要なコンテキスト情報をリセットした状態で計画を立てる機能です。
研修先の開発チームで実際に確認したのですが、300ターン以上使ったセッションでそのままPlan Modeを使うと、以前のタスクの残り情報が邪魔をして計画の精度が落ちることがあります。フレッシュコンテキストで計画を立て直すだけで、出力の一貫性が大幅に改善しました。
3つのPlanテンプレートと使い分け
タスクの規模によって、適切なPlanテンプレートが異なります。SmartScopeの分析によると（Codex Plan Mode Complete Guide）、実務では以下の3段階が効果的です:
| テンプレート | 対象タスク | 計画の深さ | 所要時間 |
|---|---|---|---|
| Template A（ミニマル） | 5-10行の変更 | 目的・変更箇所・影響範囲・検証方法 | 1-3分 |
| Template B（スタンダード） | 中規模リファクタ | ゴール/非ゴール・番号付きステップ・互換性・ロールバック手順 | 5-10分 |
| Template C（フルセーフ） | インフラ変更・本番デプロイ | リスク評価・ステークホルダー特定・監視変更・リカバリ手順 | 15-30分 |
普段の開発ではTemplate Bを使うのが現実的です。Template Cは本番環境の変更や大規模マイグレーションのみに使いましょう。
起動方法 — /planコマンドとGUI操作の完全ガイド
Plan Modeの起動方法は3つあります。それぞれの使いどころを説明します。
方法1: /planスラッシュコマンド（CLIの基本）
Codex CLIのインタラクティブセッション中に、コンポーザーで/planと入力してEnterを押します。タスク説明をインラインで書くことも可能です:
# Plan Modeに切り替えてタスクを送信
/plan Propose a migration strategy from REST to GraphQL for the user API
# または /plan だけで入力してEnterを押してからタスクを書く
/plan
Add dark mode toggle to the settings page計画が生成されたら、フィードバックを追加してさらに精度を高めることができます。Plan Modeは「iterative refinement（反復的な精緻化）」をサポートしているため、何度でも計画を修正できます。
方法2: Shift+Tabトグル（TUIのキーボードショートカット）
Codex TUIではShift+Tab（BackTab）でPlan Modeのオン・オフを切り替えられます。Plan Mode中はコンポーザーに専用の状態インジケーターが表示されます。再度Shift+Tabを押すと通常の実装モードに戻ります。
# TUIセッションでの操作フロー
# 1. Shift+Tab でPlan Modeオン
# 2. タスクを入力してEnter → 計画が生成される
# 3. 計画を確認・フィードバック → 必要なら再送信
# 4. Shift+Tab でPlan Modeオフ
# 5. 通常のプロンプトで実装開始方法3: /plan-modelで計画専用モデルを指定
2026年4月のアップデートで追加された機能です。計画フェーズだけ別のモデルを使うことができます:
# 計画専用に高推論モデルを指定
/plan-model o3
# 計画用モデルと推論エフォートを同時設定
/plan-model o4-mini high実装フェーズはGPT-5.5を使い、計画フェーズだけo3の深い推論を使うという使い分けが可能です。コスト意識が高いチームにとって、これは地味に重要な機能です。
実際のプロンプト例（コピペ可能）
/plan
以下のタスクを実装する前に、詳細な計画を作成してください。
【タスク】認証モジュール（auth.py）をJWTベースからOAuthに移行する
【制約】
- 既存のユーザーセッションを失効させない
- 移行期間中は両方の認証方式を並行サポート
- テストカバレッジ80%以上を維持
【非ゴール】
- フロントエンドの変更は今回のスコープ外
- データベーススキーマの変更はしない
計画には以下を含めてください：
1. マイルストーン（各ステップの完了基準付き）
2. リスクと対策
3. ロールバック手順
不足している情報があれば、最初に質問してから計画を作成してください。タスク分解の動作原理 — AIが計画をどう構築するか
Plan Modeでのタスク分解は、単なる「箇条書きのステップ一覧」ではありません。OpenAIが設計したExecPlan（実行計画）の構造に基づいています。
ExecPlanの6つの構成要素
公式ドキュメント（Using PLANS.md for multi-hour problem solving）によると、適切な実行計画には以下が含まれます:
- Purpose（目的）: 完了後にユーザーが得られる価値を1文で
- Progress（進捗）: タイムスタンプ付きチェックボックスで細かな手順を追跡
- Surprises & Discoveries（発見事項）: 実装中に見つかった予想外の動作や最適化機会
- Decision Log（意思決定記録）: 方針変更の理由
- Outcomes & Retrospective（成果・振り返り）: 完了後のまとめと学び
- Self-containment（自己完結性）: 「初心者でも計画だけ読んで成功できる」レベルの詳細さ
この「Self-containment（自己完結性）」という原則が特に重要です。計画が不明瞭だと、実装フェーズでAIが独自解釈を始めてドリフトが発生します。計画に曖昧さを残さないことが、成功するCodex活用の核心です。
PLANS.mdを使った長時間タスク管理
複数日にわたるタスクや7時間以上かかる実装では、PLANS.mdを使ったアプローチが有効です。これはセッションをまたいでコンテキストを保持するための仕組みです:
# PLANS.mdの推奨構成
# Prompt.md — 仕様とデリバーバブルを凍結
# Plan.md — マイルストーンと検証基準
# Implement.md — 実行指示とルール
# Docs.md — 進捗状況と意思決定記録
# Codex CLIに読み込ませる方法
codex --include-plan PLANS.md "Plan.mdの最新状況を確認し、次のマイルストーンを実行してください"OpenAIはこのアプローチで「1つのプロンプトから7時間以上の自律作業」を実証しています（Run long horizon tasks with Codex）。実際に私のクライアント企業でも、大規模なAPI移行作業にこの手法を使って、3日分の工数を1日に短縮した事例があります（想定シナリオ）。
エージェントループの内部動作
Plan Modeで作成された計画をもとに実装フェーズに入ると、Codexは以下のループで動作します:
# Codexの内部エージェントループ（擬似コード）
while not task_complete:
1. Plan（次のアクションを決定）
2. Edit Code（コードを変更）
3. Run Tools（テスト・ビルド・リントを実行）
4. Observe Results（出力を確認）
5. Repair Failures（エラーがあれば修正）
6. Update Status（Plan.mdの進捗を更新）
7. Repeatこのループの各ステップで「Plan.mdの完了基準」を参照するため、計画が明確なほど各ステップの判断が正確になります。逆に計画が曖昧だと、ステップ4の「Observe Results」で「これで合ってるの？」という判断がブレはじめます。
並列実行のメリット — 複数エージェントで開発速度を最大化する
Plan Modeが真の力を発揮するのは、並列エージェントと組み合わせたときです。
Codex appのレビュー（Codex App First Impressions 2026）によると、Codex appは「worktree-based isolation system（ワークツリーベースの分離システム）」を採用しており、各エージェントが独立したgitブランチで同時並走します。
並列エージェントの仕組み
# 3エージェントを並列起動する例
# （1つのプロンプトで複数タスクを委任）
ユーザー認証機能の実装を3つのエージェントに並列で分担させてください：
エージェント1：バックエンドAPI（auth_service.py）
- JWTトークン生成・検証ロジック
- リフレッシュトークン管理
- 完了基準：/auth/tokenエンドポイントがHTTP 200を返す
エージェント2：フロントエンド（auth_hooks.js）
- useAuthカスタムフック
- ログイン状態の永続化
- 完了基準：ページリロード後にセッションが維持される
エージェント3：テスト（test_auth.py）
- ユニットテスト（正常系・異常系）
- 統合テスト
- 完了基準：全テストがgreenで、カバレッジ80%以上
各エージェントは完了後にサマリーだけを返してください。生のコード全体ではなく。このプロンプトのポイントは「完了基準を人間が検証可能な形で書く」こととと「サマリーだけを返すように指示する」ことです。中間出力を全部返させると、それだけでトークンが大量消費されます。
gitブランチ分離の重要性
並列エージェントが同一ファイルを同時編集するとマージコンフリクトが発生します。これを防ぐのが各エージェントへの独立ブランチ割り当てです:
# 各エージェントのブランチを明示的に指定
"エージェント1はfeature/auth-backendブランチで作業"
"エージェント2はfeature/auth-frontendブランチで作業"
"エージェント3はfeature/auth-testsブランチで作業"
# 全エージェント完了後にmainにマージ
git merge feature/auth-backend feature/auth-frontend feature/auth-testsCodex公式ドキュメント（Subagents in Codex）によると「read-heavy tasks（探索・テスト・分析）での並列実行は特に効果的」で、「write-heavy tasksでは同一ファイルへの同時編集に注意が必要」とされています。
実際の並列実行ワークフロー
私が支援するチームで効果的だった並列実行パターンをまとめます（想定シナリオ）:
| タスクタイプ | 並列向き | 直列向き | 理由 |
|---|---|---|---|
| コード探索・調査 | ○ | ファイル読み取りのみなのでコンフリクトなし | |
| テスト生成 | ○ | テストファイルは独立性が高い | |
| ドキュメント生成 | ○ | 各ドキュメントが独立している | |
| APIエンドポイント実装 | △ | 共有モジュール編集に注意が必要 | |
| データベーススキーマ変更 | ○ | マイグレーションの順序依存性あり | |
| コアロジックのリファクタ | ○ | 影響範囲が広く並列は危険 |
トークン節約の実測例 — Plan Modeで消費量を最適化する
Plan Modeがトークン節約に効果的な理由は直感と少し逆説的です。「計画フェーズが追加されるのに、なぜトークンが減るの？」という疑問はよく受けます。
答えは「計画なしに実装に入ると、やり直しのコストが計画フェーズの何倍にもなる」ことにあります。
トークン消費の実態
BSWENの調査（How to Stop Running Out of Codex Tokens）によると、単純なバグ修正1件でも約18,500トークンを消費することが確認されています。内訳はコンテキスト読み込み・ファイル解析・コード生成の3段階です。
実装ミスが発生した場合、修正のための追加プロンプト・修正後の確認・再テスト・場合によっては複数回のやり直しで、この消費量が2〜5倍に膨らみます。
# Plan Mode不使用（典型的な失敗パターン）
プロンプト1: "認証モジュールをOAuthに移行して" → 18,500トークン消費
プロンプト2: "さっきの実装、JWTと競合してる。直して" → 15,000トークン消費
プロンプト3: "テストが落ちてる。原因を調べて修正して" → 22,000トークン消費
合計: 55,500トークン（失敗・やり直しを含む）
# Plan Mode使用（同じタスク）
/plan: "まず計画を立てて" → 8,000トークン
計画確認・フィードバック: 2,000トークン
実装（計画通りに実行）: 20,000トークン
合計: 30,000トークン（約46%削減）正直に言うと、このトークン削減効果はタスクの複雑さによって大きく変わります。シンプルな変更なら差はほとんどありません。アーキテクチャを跨ぐ複雑なタスクになるほど、Plan Modeの効果が顕著になります。
3-5エージェント並列の「スイートスポット」
並列エージェントについて重要な数字があります。Codexのコミュニティ議論（Adjusting Codex plan mode）では「3-5つの同時並列エージェントが実用的なスイートスポット」と述べられています。
# エージェント数の最適化ガイドライン
# 推奨設定
MAX_PARALLEL_AGENTS = 5 # フロントエンド重い開発時
OPTIMAL_PARALLEL = 3 # 通常の開発ワークフロー
# エージェントごとのトークンバジェット目安（公式推奨）
FRONTEND_AGENT_BUDGET = 180_000 # フロントエンドタスク
BACKEND_AGENT_BUDGET = 280_000 # バックエンド・複雑なロジック
# スタックしたエージェントの自動停止目安
KILL_AFTER_ITERATIONS = 3 # 同じエラーで3回以上詰まったら停止なぜ5つ以上だとうまくいかないのか。理由は単純で、各エージェントが独自のモデル呼び出しとツール実行を行うため、10エージェント同時実行は単独の10倍のトークンを消費します。効率の逓減が5エージェント前後から始まります。
/compactコマンドとPlan Modeの組み合わせ
長時間セッションでのトークン節約に特に効果的なのが/compactコマンドとPlan Modeの組み合わせです:
# 長時間セッションでのトークン管理フロー
# 1. セッション開始時にPlan Modeで計画を作成
/plan [詳細なタスク説明]
# 2. 実装が進んだら /compact で過去のターンを圧縮
/compact
# 3. /status でトークン使用量を確認
/status
# 4. 次のマイルストーンに移る前に再度 /plan で計画を確認
/plan 次のフェーズの計画を確認し、現在の状況を踏まえて調整してくださいPlan Mode vs 通常Codexの使い分け — どちらを選ぶか
「全部Plan Modeにすればいい」というわけではありません。Plan Modeにはオーバーヘッドがあるため、シンプルなタスクには不要です。
判断フロー
# Plan Modeが必要かどうかの判断チェックリスト
def should_use_plan_mode(task):
if task.affects_multiple_files():
return True # マルチファイル変更は必須
if task.requires_architecture_decision():
return True # アーキテクチャ変更は必須
if task.is_ambiguous_or_hard_to_describe():
return True # 要件が曖昧なら必須
if task.requires_parallel_agents():
return True # 並列エージェント使用時は必須
if task.duration_estimate > "30 minutes":
return True # 30分以上かかるタスクは推奨
return False # シンプルな変更なら不要| ケース | Plan Mode | 理由 |
|---|---|---|
| 1行のtypo修正 | 不要 | シンプルすぎて計画のオーバーヘッドが無駄 |
| 単一関数の追加 | △（任意） | 影響範囲が小さければ直実装で問題なし |
| 新機能のフルスクラッチ実装 | 必須 | スコープが広いほどドリフトリスクが高い |
| レガシーコードのリファクタ | 必須 | 依存関係の把握が先決 |
| 本番DBのマイグレーション | 必須（Template C） | 失敗コストが高い |
| 並列エージェントタスク | 必須 | タスク分割の基準を先に決める必要がある |
| 継続セッションでの作業再開 | 必須（フレッシュコンテキスト） | 前セッションの文脈汚染を防ぐ |
Plan Modeの制限事項（正直に書きます）
「Plan modeはファイル変更を行わない」という保護機構はプロンプトレベルであり、ランタイムレベルの強制ではありません。これはSmartScopeの分析でも指摘されています。つまり、理論上はPlan Mode中でもファイルが書き換えられるリスクがゼロではない。
高リスクの作業では、Plan Modeの計画作成後にgitでステージングブランチを切ってから実装フェーズに入る、という追加の安全策を推奨します。
Claude Code Skillsとの比較 — それぞれの「計画」設計思想
「Codex Plan ModeとClaude Code Plan Modeは何が違うの？」という質問も研修でよく受けます。どちらも計画フェーズを持ちますが、設計思想が根本的に異なります。
設計思想の違い
| 観点 | Codex Plan Mode | Claude Code (Plan Mode相当) |
|---|---|---|
| 基本姿勢 | 自律エージェント（計画→実行→完了を自律的に） | 対話型パートナー（各ステップを人間と確認しながら） |
| 実行モデル | クラウド実行（マシンから独立） | ローカル実行（開発マシン上で直接） |
| 計画の見え方 | チェックリスト形式でUIに表示 | コードとしてPROJECT.md等に記録 |
| コードベース理解 | 実行環境のコードを読む | プロジェクト全体を再帰的に探索 |
| 並列実行 | gitワークツリーで分離・並列化 | サブエージェント（Task）で並列化 |
| モデルの自由度 | OpenAIモデルのみ | Anthropicモデルのみ |
| コスト効率 | 複数エージェント並列はトークン増 | 同様にサブエージェントはトークン増 |
AQUA Tech Blog（Claude Code vs Codex 徹底比較）の評価では、CodexはSWE-bench等でコード品質が高く、Claude Codeはセットアップのしやすさ・エラー修正の透明性・コードベース理解の深さで優位とされています。
使い分けの判断基準
「タスクを丸投げして完了を待つ」用途ならCodex Plan Modeが強い。「AIと会話しながら設計を詰めていきたい」用途ならClaude Codeが向いています。
AIエージェントの基本的な導入ステップや活用戦略については、AIエージェント導入完全ガイドで詳しく解説しています。ツール比較より先にエージェントの概念を理解したい方はまずこちらをどうぞ。
【要注意】Plan Mode活用の失敗パターン4選
「Plan Modeを使えば全部うまくいく」と思ってはいけません。私が見てきた中で頻出する失敗パターンをまとめます。
失敗1: 計画が曖昧すぎて意味がない
❌ よくある間違い:
/plan
ユーザー認証周りを改善してください⭕ 正しいアプローチ:
/plan
現行のsession-based認証（auth.py）を、以下の要件でJWT方式に移行してください：
- アクセストークン有効期限：15分
- リフレッシュトークン有効期限：7日
- 既存ユーザーのセッションは強制ログアウトさせない
- エンドポイント：POST /auth/token, POST /auth/refresh, DELETE /auth/session
- 完了基準：既存のE2Eテストが全てpassし、新規エンドポイントの単体テストが追加されている
不足情報があれば計画作成前に質問してください。なぜ重要か: 「計画を立てる」といっても、AIは入力された情報しか計画できません。「改善してください」という指示では、AIが何を「改善」とみなすかが不明確で、全く意図しない実装が計画される場合があります。
失敗2: 並列エージェントに同一ファイルを編集させる
❌ よくある間違い:
# 2エージェントに同じファイルを担当させる
エージェント1：api_router.pyのユーザー認証エンドポイントを追加
エージェント2：api_router.pyの管理者認証エンドポイントを追加⭕ 正しいアプローチ:
# ファイルを分割して独立性を確保
エージェント1：user_auth_routes.py（新規ファイル）にユーザー認証エンドポイントを追加
エージェント2：admin_auth_routes.py（新規ファイル）に管理者認証エンドポイントを追加
エージェント3：api_router.pyに上記2ファイルをインポートするルーティング設定を追加
※エージェント1・2の完了後に実行なぜ重要か: 同一ファイルへの並列書き込みはコンフリクトを確実に起こします。ファイル境界でタスクを分割するか、依存関係を明示して直列に実行させるかを選んでください。
失敗3: Plan Modeの計画をスキップして「あとで計画を確認する」
❌ よくある間違い:
# 計画確認を後回しにする
/plan
（計画が生成されたが、確認せずにすぐ /plan を終了して実装指示を出す）⭕ 正しいアプローチ:
# 計画をしっかり読んで、不明点をフィードバックする
/plan [タスク説明]
（計画生成後に：）
計画を確認しました。以下を修正してください：
1. ステップ3でロールバック手順が明記されていない
2. マイルストーン2の完了基準が「ビルドが通る」と曖昧 → 「全テストがgreenで、カバレッジ80%以上」に変更
3. セキュリティレビューのステップが抜けているなぜ重要か: 計画を確認しないまま実装に進むのは、計画なしに実装するのと同じです。Plan Modeの価値は計画の品質にかかっています。
失敗4: /compactを使わず長時間セッションを続ける
❌ よくある間違い:
# 200ターン以上のセッションをそのまま継続
（Plan Modeで計画し、そのまま8時間分の実装を同一セッションで続ける）⭕ 正しいアプローチ:
# 定期的にcompactしてコンテキストをクリーンに保つ
/compact # 1-2時間ごと、またはマイルストーン完了後に実行
/status # トークン使用量を確認
/plan 現在の状況をPlan.mdで確認し、次のマイルストーンの計画を立ててくださいなぜ重要か: 長時間セッションで蓄積された不要なコンテキストがAIの判断精度を落とします。BSWENの調査では、コンテキストのブロートが最大の非効率要因と指摘されています。マイルストーン単位で/compactを実行するのが実用的です。
30-60-90日ロードマップ — Plan Modeをチームに定着させる
Plan Modeは個人で使うだけでなく、チーム全体のワークフローに組み込むことで真の効果が出ます。研修先で実際に使っているロードマップを共有します（想定シナリオ）。
30日目まで: 個人レベルでの習慣化
# 個人ワークフローへの組み込みチェックリスト
[ ] 1. 毎朝の開発タスク確認時に /plan を使う習慣をつける
[ ] 2. 「30分以上かかるタスク = Plan Mode必須」というルールを設定
[ ] 3. Plan.mdをプロジェクトルートに作成し、計画を蓄積する
[ ] 4. /status と /compact の使い方を覚える
[ ] 5. 並列エージェントを1つのタスクで試してみる（3エージェント以内）60日目まで: チームへの水平展開
# チームへの展開ステップ
1. Plan Modeのショートカット集をTeam Wikiに追加
2. PR作成時に「元になったPlan.mdを添付する」ルールを設定
3. 週次でのトークン使用量を /status でモニタリング
4. 並列エージェントの成功事例と失敗事例をチームで共有90日目まで: 自動化と最適化
# 上級活用: Automationsとの統合
codex automation add plan-review \
--trigger "pull_request.opened" \
--action "review_plan_quality"
# PRが開かれると自動でPlan.mdの品質をチェック
# Skills（スキル）として計画テンプレートを登録
codex skill add --name "auth-migration-plan" \
--file templates/auth_migration_plan.mdAIツールの組織的な導入戦略については、AI導入戦略完全ガイドに体系的にまとめています。Plan Modeの定着を組織変革の文脈で考えたい方はあわせて参照ください。
また、Codexの基本的な使い方・料金・コマンド体系については既存の記事をあわせてどうぞ:
- Codex CLIガイド｜GPT-5.5・Plan Mode（ID:4869）
- Codex使い方ガイド｜30コマンド・プロンプト集（ID:5362）
- Codex料金完全ガイド（ID:3377）
- Codex完全ガイド（ID:160）
- Claude Code完全ガイド（ID:691）
参考・出典
- Best practices – Codex | OpenAI Developers — OpenAI（参照日: 2026-05-04）
- Using PLANS.md for multi-hour problem solving | OpenAI Cookbook — OpenAI（参照日: 2026-05-04）
- Run long horizon tasks with Codex | OpenAI Developers Blog — OpenAI（参照日: 2026-05-04）
- Slash commands in Codex CLI | OpenAI Developers — OpenAI（参照日: 2026-05-04）
- Subagents – Codex | OpenAI Developers — OpenAI（参照日: 2026-05-04）
- Plan Mode: read-only, iterative planning (Shift+Tab) + configurable planner – GitHub PR #4769 — openai/codex（参照日: 2026-05-04）
- Complete Guide to Codex Plan Mode (2026) | SmartScope — SmartScope（参照日: 2026-05-04）
- How to Stop Running Out of Codex Tokens in 2 Days | BSWEN — BSWEN（参照日: 2026-05-04）
- Codex App First Impressions (2026) | Verdent Guides — Verdent AI（参照日: 2026-05-04）
まとめ: 今日から始める3つのアクション
Codex Plan Modeは「AIが手を動かす前に頭を使わせる」ための仕組みです。シンプルなタスクには不要ですが、複雑な実装・並列エージェント・長時間タスクになるほど効果が出ます。
- 今日やること: 次の開発タスクに
/plan [詳細なタスク説明]を使ってみる。完了基準を必ず書く - 今週中:
/compactと/statusをセッション管理に組み込む。マイルストーム完了後に必ず/compactを実行する - 今月中: 3エージェント並列の実験を1回やってみる。ファイル境界でタスクを分割し、gitブランチを分けて実行する
次の記事では「Codex Automations完全ガイド — 定期タスク自動化とCI/CD統合」をテーマに、Plan Modeで立てた計画をCI/CDパイプラインに組み込む方法をお届けします。
著者: 佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。早稲田大学法学部在学中に生成AIの可能性に魅了され、X（@SuguruKun_ai）でフォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆（NewsPicks最大1,125ピックス）。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
