AIコーディングツールを使い始めたとき、多くの方がまず試すのは「ログイン機能を作って」「この画面にバリデーションを追加して」といった直接的な実装指示ではないでしょうか。
それ自体は自然なことです。しかし、プロジェクトが少しでも複雑になると、いきなりの実装指示はトラブルの原因になりがちです。既存コードとの競合、不要な重複実装、意図しないアーキテクチャの崩壊。こうした問題は「作る前に考える」ステップを挟むだけで、かなりの部分を防げます。
その「考えるステップ」を仕組み化したのが、AIコーディングツールのプランモードです。Claude CodeやOpenAI Codexをはじめ、主要なコーディングエージェントがこの機能を搭載しています。
プランモードとは何か
プランモードは、AIコーディングエージェントに搭載されている分析優先のモードです。Claude CodeやCodexでは Shift+Tab で切り替えられ、AIがコードベース全体を調査しながら実装計画を立ててくれます。プランモード中はファイルの変更やコマンドの実行を行わず（Claude Codeでは読み取り専用が強制され、Codexではプロンプトレベルで制御されます）、「考えるだけで手を動かさない」状態を作り出します。
これにより得られる恩恵は大きく2つあります。
既存実装との競合チェック。 プランモードではAIがコードベースを事前に走査するため、すでに同様の処理が実装されていないか、変更が既存の設計パターンと衝突しないかを確認したうえで計画を立てます。「追加したら別のモジュールが壊れた」という事故を未然に防げます。
DRY原則に沿った設計。 既存コードの構造を把握してから計画を作るため、すでにある共通処理の再利用や、適切な抽象化レベルでの実装を提案してくれます。いきなり実装を始めた場合に起きがちな「似たような処理がもう一つ増えた」という状況を避けやすくなります。
仕様書ドリブンという考え方
プランモードをさらに一歩進めると、「仕様書ドリブン」という開発スタイルに行き着きます。
従来、仕様書の作成は人間の仕事でした。要件を整理し、影響範囲を洗い出し、実装方針をドキュメントにまとめる。これは重要なプロセスですが、時間もかかります。プランモードを活用すると、この「仕様書の下書き」をAIに代行させることができます。
やることはシンプルです。プランモードで要件を伝え、AIが生成した実装計画をレビューし、必要に応じて修正を加えてから実装に進む。仕様書を書くのではなく、AIが書いた仕様書をレビューする側に回るわけです。
この流れは、Thoughtworksが2025年のTechnology Radarで取り上げた「Spec-driven development」の考え方とも重なります。AIに曖昧な指示を投げるのではなく、明確な仕様を介して対話する。プランモードは、その入口として最も手軽な方法のひとつです。
プランモードの限界を知っておく
便利なプランモードにも、知っておくべき課題があります。
調査フェーズの冗長さ
プロジェクトの構造を熟知していて、修正箇所も明確な場合、プランモードの調査フェーズは冗長になることがあります。AIがコードベースを一通り読み込んで分析する時間とトークンが余計にかかるため、「この1行を直したいだけなのに」という場面ではオーバーヘッドになります。
目安として、変更内容を一文で説明できるならプランモードは不要、できないならプランモードを使うのがよいでしょう。
プランファイルの管理問題
これがプランモード最大の課題かもしれません。ツールによってプランの保存方式が異なり、それぞれに問題があります。
Claude Codeの場合、生成したプランファイルは ~/.claude/plans/ に自動保存されますが、実用上の課題があります。
- 無意味なファイル名。
async-bouncing-blossom.mdのようなランダムな名前で保存されるため、後から目的のプランを探すのが困難です - プロジェクトの混在。 同じPCで作業したすべてのプロジェクトのプランが1つのフォルダに混在します。どのプランがどのプロジェクトのものか、ファイルを開かないと判別できません
- 再参照されない。 プランファイルは作成されるものの、後続のセッションで自動的に参照されることはほとんどありません。せっかくの実装計画が、事実上の使い捨てになっています
この問題はClaude CodeのGitHubリポジトリでも多数のIssueが上がっており、コミュニティでも広く認識されている課題です。
Codexの場合、プランモードで生成された計画はそもそもファイルとして自動保存されません。セッション内のやり取りとしてのみ存在し、セッションが終われば消えてしまいます。プランを残したい場合は、プロンプトで「docs/plans/ に保存してください」のように明示的に指示する必要があります。OpenAIの公式Cookbookでは、AGENTS.mdにPLANS.mdの参照ルールを記述し、計画を構造化してリポジトリに残すアプローチが紹介されています。
プランを資産として残す方法
プランモードで生成された実装計画を、プロジェクトの資産として活用するにはどうすればよいでしょうか。いくつかのアプローチがあります。
手動でプロジェクトに残す
Claude Codeの場合、もっとも手軽な方法は ~/.claude/plans/ から目的のファイルを見つけてプロジェクトフォルダにコピーすることです。シンプルですが、ファイル名が分かりにくいため、毎回プランファイルの中身を確認して正しいものを選ぶ必要があります。小規模なプロジェクトでは十分実用的です。
Codexの場合、プランは自動保存されないため、プロンプトで保存先を明示する必要があります。たとえば「実装計画を docs/plans/ にMarkdownで保存してください」と指示します。AGENTS.mdに「プランモードでは必ず docs/plans/ に計画を書き出すこと」と記載しておけば、毎回の指示を省略できます。
Dockerでプロジェクトごとに隔離する（Claude Code向け）
Claude Code特有のアプローチとして、プロジェクトごとにDockerコンテナを用意し、その中でClaude Codeを実行する方法があります。コンテナ内の ~/.claude/plans/ をボリュームマウントで永続化すれば、プランファイルがプロジェクト単位で自然に分離されます。
# docker-compose.yml（例）
volumes:
- ./plans:/root/.claude/plans
- ./CLAUDE.md:/workspace/CLAUDE.mdCLAUDE.mdなど他の設定ファイルも環境ごとに分離できるため、複数プロジェクトを並行して開発する方には有効なアプローチです。ただし、Dockerの知識が前提となるため上級者向けです。
sqlewで構造化して記録する
sqlewは、AIコーディング中の設計判断を構造化して記録するMCPツールです。npmでインストールし、コーディングエージェントのMCP設定に追加するだけで利用を開始できます。
npm install -g sqlewClaude Codeの場合はPluginを追加でインストール、Codexの場合はSkillsと追加システムプロンプトをインストールすることで自動記録が有効になります。詳しくは下記リンクで解説しています。
sqlewの特長は、プランモードで生まれた設計判断をプロジェクトごと、さらにはレイヤー（機能領域）ごとに分類して記録できる点にあります。記録された情報はコーディングエージェントがMCP経由で自動的に参照するため、後続のセッションでも過去の設計意図が活きます。
プランモードが「考える」ための仕組みだとすれば、sqlewは「考えた結果を覚えておく」ための仕組みです。プランモードが解決しない「プランの再利用」という課題に対するアプローチとして、組み合わせて使うことで互いの弱点を補完できます。
なお、sqlewのOSS版は個人利用ではローカルファイルで完結しますが、チームでの利用にはMySQL/PostgreSQLなどのRDBサーバの構築が必要です。チーム向けにセットアップ不要で使えるSaaS版も提供しています。
まとめ：まず「考えてから作る」を習慣にする
AIコーディングの最初の一歩として、プランモードは非常に良い出発点です。「いきなり作る」から「まず計画を立てる」へ。たったこれだけの変化で、AIとの協働の質は大きく変わります。
そしてプランモードに慣れたら、次のステップとして「計画を記録し、再利用できる仕組み」を検討してみてください。AIが考えた結果を蓄積していくことで、プロジェクトが進むほどAIの精度が上がっていく。仕様書ドリブンの本質は、その好循環にあります。
