AIコーディングの「考える場所」と「書く場所」が、ついに同じ画面に揃いました。
OpenAIのCodexにPlan mode（プランモード）が追加され、リポジトリを読み込んだうえで実装計画を立て、承認後にコード変更へ進む流れが一つのツール内で完結します。複雑・曖昧なタスクでは、実装前に計画を立てるよう公式マニュアルでも推奨されています（参考）。
この記事では、XDA DevelopersのYasir Mahmood氏が報告した「Claudeで計画してからCodexへ渡す」二段構えが不要になった実例と、Plan modeの使い方・設定を整理します。
この記事でわかること
- Plan modeが解決する「計画と実装の分断」という課題
- Codexアプリ・CLI・IDE拡張での有効化方法
- 曖昧な依頼への質問機能と推論レベルの使い分け
- Claude Codeとの役割分担が変わる理由
計画はClaude、実装はCodex──この分業が生むロス
AIコーディングを本格運用している開発者の間では、設計の相談をClaude Codeで行い、確定した方針をCodexに渡して実装させる、という二段構えが広く使われてきました。Mahmood氏も長い間この流れを採用し、着手順序・触るファイル・壊れやすい箇所をClaude側で整理してからCodexへ移していました（参考）。
課題は、計画ツールがリポジトリの実体を見られないことです。フォルダ構成や命名規則、どのファイルが重要かを記憶ベースで説明し、そのテキストをCodexに貼り付けると、Codex側が同じ文脈を再構築し直す必要が出ます。人間が橋渡しをするたびに情報が欠け、計画の精度も実装の一貫性も落ちます。
Plan modeは、この「別タブで考えて、別タブで書く」構造そのものを不要にする機能です。
Plan modeはリポジトリを読んでから計画を出す
Plan modeは、Codexがファイル編集やコマンド実行に入る前に、コードベースを読み、方針を提案するモードです。OpenAI公式ブログでは、Codexアプリ・CLI・IDE拡張のいずれでもネイティブに利用でき、複雑な作業をレビュー可能なステップ列に分解してから変更に入れると説明されています（参考）。
有効化の方法は次のとおりです。
- Codexアプリ: コンポーザーの「+」メニューからPlan modeを選択する。スラッシュコマンド
/planでも切り替え可能 - Codex CLI:
/planを入力するか、コンポーザーでShift+Tabを押す - IDE拡張: チャット入力欄のモード切替、または
/planコマンド
Plan mode中は読み取り専用の動作が基本です。計画に納得するまでディスク上のファイルは変更されず、承認後に実装フェーズへ進みます。GitHubのCodex本体へのマージ済みプルリクエストでも、Plan modeは読み取り専用サンドボックスで計画ターンを実行し、承認前にファイルを書き換えない設計とされています（参考）。
承認設定で「どこまで任せるか」を決める
Plan modeと並行して設定できるのが、Codexの承認ポリシーです。Mahmood氏の記事では、Codexアプリの承認設定を「Ask for approval（都度確認）」「Approve for me（危険操作のみ確認）」「Full access（制限なし）」の3段階で説明しています。
公式ドキュメントの対応関係は次のとおりです。
- Auto（デフォルト）: ワークスペース内の読み取り・編集・コマンド実行は自動。ワークスペース外の編集やネットワーク利用は承認が必要
- Read-only: ファイル閲覧と質問応答のみ。編集・コマンド・ネットワークは計画承認後に限定
- Full Access: マシン全体とネットワークへのアクセスを承認なしで許可
/permissions コマンドでセッション中に切り替えられます。計画段階ではRead-onlyを選び、実装に移るタイミングでAutoへ緩める、という使い分けが安全です（参考）。
使い方の流れ──小さな修正から認証移行まで
Mahmood氏の実例に沿った操作の流れを示します。
1. 小さな機能追加
「サインアップフォームに入力バリデーションを追加して」と依頼すると、Codexは関連ファイルを読み、短い計画を提示して待機します。承認後に実装へ入り、計画中はディスクが書き換わりません。
2. 曖昧な依頼への質問
「キャッシュを入れたいが詳細は未定。前提を疑って、必要な質問を全部してから計画して」と伝えると、Codexは実装前にインタビュー形式で確認します。メモリか永続化か、TTL、対象API、古いデータの扱いなど、Claudeの計画チャットで自分で答えていた項目を、コードのある場所でそのまま聞き返します。2026年1月のCodex本体更新では、Plan modeは探索を先に行い、本計画の前にTL;DRチェックポイントを挟むよう強化されています（参考）。
3. 推論レベルを上げた大規模タスク
「セッションCookie認証をJWTへ移行し、変更前に計画して」と依頼する場合、モデルピッカー横の推論コントロールで Extra High を選ぶと、ミドルウェアの書き換え対象、ルートの認可変更、更新すべきテストまで、実ファイル名を根拠にした計画が返ります。GPT-5.5では Low・Medium・High・Extra High の4段階があり、単純な修正はLow、複数ファイルにまたがる作業はExtra Highが向きます。
~/.codex/config.toml では、Plan mode専用の推論設定 plan_mode_reasoning_effort をグローバル設定と分けて書けます。実装フェーズは medium、計画フェーズだけ high や xhigh にする、という運用が公式設定例にも載っています（参考）。
Claude Codeとの比較──役割は「対話」から「文脈付き計画」へ
Claude Codeは対話を通じた設計整理に強く、Codexはリポジトリ操作と実装検証に強い、という棲み分けは今も有効です。変わったのは、Codex側が計画フェーズでもリポジトリを直接読める点です。
Mahmood氏は、Plan mode導入後にClaudeでの事前計画をやめ、曖昧な要件の詰めや大規模リファクタの設計もCodex内で完結させるようになったと報告しています。別ツールへ計画をコピペする手間と、文脈の欠落リスクが消えるのが主なメリットです。
一方、数時間〜数日にわたる自律実行や、セッションをまたいだ計画の保持には、Plan mode単体では不十分な場合があります。公式マニュアルは、より高度なワークフローとして PLANS.md テンプレートを使った実行計画ファイルの運用も案内しています。Plan modeは日常の中〜大規模タスク向け、PLANS.mdは長時間の自律実行向け、と使い分けるのが現実的です。
今後の展望
Mahmood氏が注目しているのは、繰り返し作業向けの計画テンプレート保存と、承認済み計画をAutomationsへつなぐ流れです。Codexアプリには、並列スレッド、Skills、Automations、Git worktreeといった長時間タスク向け機能が既に揃っており、Plan modeと組み合わせると「計画→実装→検証→修復」のループをさらに定型化しやすくなります（参考）。
AIコーディングの実務では、「どのモデルが賢いか」より「計画と実装の間で文脈が切れないか」の方が成果に直結します。Plan modeはその切れ目を一つのツール内で塞ぐ、実用的なアップデートです。複雑な依頼をCodexに渡す前に /plan をオンにする習慣だけでも、手戻りは目に見えて減るはずです。