Claude Codeのプロジェクト計画: plan modeとak plan (2026)
Claude Codeでのプロジェクト計画とは、「調査と計画」のフェーズと「コードを書く」フェーズを切り分けることです。こうすることで、AIは1つのファイルに触れる前に問題をきちんと理解できます。plan modeはShift+Tabでオンにでき（Claudeはファイルを読んで計画を提案するだけで、ディスクには何も書き込みません）、Explore → Plan → Implement → Commitのループに沿って進めます。大きなプロジェクトでは、ロードマップを作って作業を複数のフェーズに分割し、各フェーズをクリーンなコンテキストで実行しましょう。標準化された再現性のあるプロセスが欲しいなら、すぐに使えるak planスキルもあります。
なぜClaude Codeにコードを書かせる前に計画するのか？
Claude Codeでいちばんよくある失敗は、プロンプトを1つ打ち込んですぐにコードを書かせてしまうことです。速く感じますが、リスクは現実にあります。AIはしばしば「間違った問題を解いて」しまうのです。つまり、あなたが本当に必要としていることではなく、AIが「こうしてほしいのだろう」と思ったことをそのまま実行します。差分を見るころには、すでに十数個のファイルが変更されていて、手で直すか、全部捨てて最初からやり直すかの二択で身動きが取れなくなります。
先に計画することで、まさにこの問題を解消できます。コードに触れる前にClaudeへ計画を立てさせると、変更の範囲を事前に確認でき、誤解がまだ安いうちに気づけて、作業を境界の内側に収められます。おまけにトークンの節約にもなります。計画の1行を直すほうが、AIに間違ったものを書かせてから書き直させるよりもずっと安上がりだからです。
あまり語られないメリットもあります。計画は、あなたとAIが「完了の定義」で合意する場だということです。どのファイルが変わり、どう検証するかを計画に明記しておけば、最終的な差分を照らし合わせる基準ができます。コードを読みながら「本当に意図どおりに動いたのか？」と悩まずに済むのです。言い換えれば、計画はレビューを当て推量からチェックリストの照合へと変えてくれます。
計画すべきとき：変更が多くのファイルにまたがる、どう進めるか自信がない、あるいはフローをまだ知らない不慣れなコードベースで作業している、といった場合です。速さのために省いてよいとき：タイポの修正、定数の変更、1行だけの調整。差分をちょうど1文で言い表せるなら、計画はただのオーバーヘッドです。ツールを使うのがまったく初めてなら、まずClaude Codeとは何か、どう動くのかを読んでから、以下のセクションに戻ってきてください。
Claude Codeのplan modeとは何か & オンにする方法
Plan modeはClaude Codeのパーミッションモードの1つです。オンのとき、Claudeはあなたが承認するまでファイルを読んで計画を提案するだけで、ディスクには一切変更を書き込みません。許可を出す前にAIが何をしようとしているかを見られる、安全ブレーキのようなものだと考えてください。
オンにする方法は3つあります。
Shift+Tabを押してモードを順に切り替えます：default → acceptEdits → plan。planに到達するまで押し続けてください。- ターミナルから直接plan modeで起動します：
claude --permission-mode plan - ステータスバーで確認します。plan modeが有効なとき、ステータスバーには
⏸ plan mode onと表示されます。
あまり知られていないコツ：Claudeが計画を作ったら、Ctrl+Gを押すとその計画をテキストエディタで開き、実行前に手で編集できます。制約を加えたり、不要なステップを削ったり、特定のファイルを指定したりできます。計画を編集するほうが、すでに書かれたコードを編集するよりも常に安上がりです。
上記のショートカットの挙動は、Anthropicの公式ドキュメント（best practicesとcommon workflows、2026-08-09閲覧）に基づいています。plan modeは急速に進化しているので、お使いのClaude Codeのバージョンでショートカットを再確認してください。
4ステップの計画ループ：Explore → Plan → Implement → Commit
これはAnthropicが推奨するループで、いちばん覚えやすいものです。各ステップにはそれぞれの目的があります。混同しないようにしましょう。
Explore（plan modeで）
解決策を話し合う前に、Claudeに既存のコードを読んで理解させましょう。plan modeでは読むだけで編集はしないので、自由に探らせて構いません：
Read src/payments/ and src/orders/ to understand how the system handles payments today. No proposals yet - just summarize the flow.大きなプロジェクトでは、調査をsubagentに任せて、メインセッションのコンテキストをきれいに保ちましょう。subagentが読んで要約を返してくれるので、メインのコンテキストウィンドウが何千行もの内容で埋め尽くされずに済みます。このステップの目的は解決策ではありません。システムが今どう動いているかを、Claude自身の言葉で説明させることです。要約が間違っていれば、問題を理解できていないとすぐに分かります。
Plan
Claudeがコードを理解したら、具体的な計画を求めましょう：
I want to add discount codes to orders. Which files need to change? How does the flow work? Write a detailed plan before coding.計画をよく読んでください。おかしいところがあれば、Ctrl+Gを押して手で編集するか、返信してClaudeに修正させましょう。あわてて承認しないこと。
Implement
計画を承認する（またはShift+Tabを押してplan modeを抜ける）と、Claudeがコーディングを始めます。重要なのは、計画を検証基準で固定することです。完了を証明するためにAIが何をすべきかを、正確に指定しましょう：
Execute the plan. When finished, run npm test and make sure every test passes. If any test fails, fix it until it is green.Commit
最後に、きれいなコミットにまとめてPRを開きます：
Commit the changes with a clear descriptive message, then open a pull request with a summary of what changed.このステップを標準化するには、Claude CodeでのGitワークフロー & PR作成も参照してください。
大きなプロジェクトをフェーズ & ロードマップに分割する
上の4ステップのループは、完結した機能にはうまく働きます。しかし、数日から数週間続くプロジェクトでは、フラットな計画は破綻します。コンテキストが薄れ、Claudeは前の決定を忘れ、コントロールを失っていきます。
より長続きするアプローチは、Claudeに複数フェーズのロードマップを作らせることです。各フェーズには、目的、触れるファイル、そして「完了」の基準を明記します。ロードマップはファイルに保存し（たとえばPLAN.mdやplans/フォルダ）、/clearを実行しても消えないようにします。そして各フェーズを、それぞれ独立したセッションで、クリーンなコンテキストで実行します。フェーズの合間に/clearを実行し、各フェーズが必要なロードマップの一部だけを読み込んで、身軽に始められるようにしましょう。
フェーズ分割の原則：各フェーズはそれ自体で成立し、グリーンな状態（テストが通り、アプリが動く）で終わるべきです。そうすれば、どの時点で止めても、コードが中途半端に残りません。フェーズの順序は土台から外側へと進めましょう。先にバックエンドやロジックを作り、インターフェースは後回しにすることで、後続のフェーズは常に固い地盤の上に築けます。
「Googleでサインイン（OAuth）」機能のロードマップの例：
| フェーズ | 目的 | 触れるファイル | 完了基準 |
|---|---|---|---|
| 1. 認証の土台 | OAuthクライアントと環境変数を設定 | config/, .env.example | Googleのリダイレクトがローカルで動く |
| 2. コールバック & セッション | コールバックのルート、ユーザーの作成/照合、セッションの保存 | routes/auth, models/user | サインインでセッションが作られる。認証テストがグリーン |
| 3. サインインUI | 「Googleでサインイン」ボタン、状態の処理 | components/login | ボタンをクリック → ダッシュボードに到達 |
| 4. 仕上げ & セキュリティ | レート制限、ロギング、リファクタリング | 認証フロー全体 | 差分レビュー＋フロー全体のテストがグリーン |
複雑な機能には、interview → SPEC.md → 新しいセッションのパターンを使いましょう。Claudeに「要件について1問ずつ私にインタビューして、それをSPEC.mdに書き出して」と伝え、その後SPECを読んでクリーンなコンテキストで実行する新しいセッションを開きます。これは仕様駆動開発（まずSPEC.mdを書く）の本質であり、多くの現役開発者がすでに使っているbrainstorm → plan → cook → shipのワークフローとも一致します。
より質の高い計画のためのヒント
- 検証基準で固定する。良い計画には、必ず確認方法が含まれます。どのテストが通るべきか、ビルドが走るべきか、スクリーンショットが一致すべきか、といった具合です。
/goalで条件を設定すれば、AIは各ステップのあとに自己評価するようになり、まだ完了していないのに「done」と宣言してしまうのを防げます。言い換えれば、明確な受け入れ基準があってこそ/goalは安全に実行できるのです。 - CLAUDE.mdを書く。プロジェクトの規約（フォルダ構成、命名ルール、テストコマンド）をCLAUDE.mdファイルに記録しておけば、毎回繰り返さなくても、すべての計画が正しいコンテキストの中に収まります。
- プロンプトは具体的に。正確なファイルを指し示し、手本にすべきサンプルパターンを挙げ、スコープ外は何かを明言しましょう。具体的であるほど、計画は狙いに近づきます。
- subagentに計画をレビューさせる。新鮮なコンテキストを持つsubagentに計画や差分を見てもらいましょう。「まっさら」な視点は、メインセッションが見落とすようになった穴を拾ってくれることが多いです。
/rewindを使う。計画の方向性がうまくいっていないなら、その上にパッチを当て続けるのではなく、巻き戻して別のアプローチを試しましょう。
違いが分かるように、さっと並べて比べてみましょう：
弱いプロンプト： 「アプリにGoogleログインを追加して。」
強いプロンプト： 「src/auth/とsrc/routes/を読んで。src/auth/session.tsにすでにあるセッションのパターンをそのまま踏襲して、Googleログイン（OAuth）を追加したい。スコープ外：リフレッシュトークンはまだなし。計画を書いて：どのファイルが変わるか、コールバックのフローがどう動くか、そして検証基準（auth.spec.tsが通る）。」
ak plan — すぐ使える計画スキル（AgentKit）
混同を避けるための短い補足：ここでいうAgentKitはClaude Code向けのキット（agentkit.best、ak CLIを使用）であり、「OpenAI AgentKit」とはまったくの別物です。
機能に着手するたびに「計画を書いて」とプロンプトを打っている自分に気づいたなら、そのプロセスをパッケージ化したスキルがあります。ak-planです。自分でプロンプトを書く代わりにスキルを呼ぶと、一貫したフレームワークでロードマップ付きのマルチフェーズ計画を生成してくれます。--html（表示・共有できる自己完結型のアーティファクト）と--wiki（AgentWikiへ公開）に対応しています。このスキルはEngineer Kitに含まれます。60以上のスキルと30以上のワークフローを備えた$99のパッケージ（サイト上に継続課金の記載はありません）です。すぐに試したいなら、ak CLIを有効化（リンク経由で20%オフ）して、そこからキットをインストールできます。
正直に言うと、たいていの作業ではネイティブのplan modeですでに十分で、しかも無料です。うまく計画するのにキットは必要ありません。ak planが検討に値するのは、チーム全体のために標準化されて再現でき、ドキュメント化された（アーティファクト/wiki）計画が必要なときであって、始めるための前提条件ではありません。
AIで計画するときのよくある間違い
- 小さすぎることを計画する。1行変えるためにplan modeを起動しても、時間の無駄です。差分を1文で言い表せるなら、そのまま走らせましょう。
- 検証の拠り所がない長い計画。十数ステップの計画は立派に聞こえますが、確認基準がなければ、AIは実際には何も動かないのに簡単に「完了したように見せかける」ことができます。必ずテスト/ビルド/明確な条件を添えましょう。
- 1つのセッションに多くのタスクを詰め込む。関連のない3つの機能を同じコンテキストウィンドウで進めると、AIは混乱します。タスクの合間に
/clearを実行して、コンテキストを身軽に保ちましょう。 - 計画を信用して差分を飛ばす。計画が正しくても、コードが正しいとは限りません。コミットの前に、実際の差分を必ず読む必要があります。
よくある質問（FAQ）
plan modeは追加料金がかかりますか？
いいえ。plan modeはClaude Codeに組み込まれたモードで、有料のアドオンではありません。現在のプラン（たとえばProは月$20、Max 5xは月$100）の範囲内で使えます。
どのキーでplan modeがオンになりますか？
Shift+Tabを押してdefault → acceptEdits → planを切り替え、planで止めます。またはclaude --permission-mode planで起動します。ステータスバーには⏸ plan mode onと表示されます。
plan modeは勝手にファイルを編集しますか？
いいえ。plan modeでは、Claudeはファイルを読んで計画を提案するだけで、あなたが承認するまでディスクに変更を書き込みません。これがこのモードの中核となる安全機能です。
plan modeはextended thinking（think/ultrathink）とどう違いますか？
別物です。plan modeはパーミッションモードで、AIにファイル編集を許可するかどうかを制御します。extended thinking（think/ultrathink）はモデルの推論の深さを増やします。両方を併用できます。安全のためにplan modeをオンにし、問題が複雑なときはより深い思考を求めましょう。
ak planは必須ですか、そしてネイティブのplan modeとどう違いますか？
必須ではありません。ネイティブのplan modeはたいていのケースで十分で、しかも無料です。ak planは、標準化されたマルチフェーズ計画を--html/--wikiアーティファクト付きで生成する、すぐ使えるスキル（AgentKitのEngineer Kit内）です。プロセスを繰り返し、チーム用のドキュメントが欲しいときに便利です。
大きなプロジェクトはどう分割すべきですか？
Claudeにマルチフェーズのロードマップ（各フェーズに目的、触れるファイル、完了基準）を作らせ、それをPLAN.mdに保存し、各フェーズをそれぞれのセッションで実行して、フェーズの合間に/clearを実行してコンテキストをきれいに保ちましょう。
まとめ＋次のステップ
結論：Claude Codeにすぐコードを書かせないこと。Explore → Plan → Implement → Commitと進め、Shift+Tabでplan modeをオンにして承認前にプレビューし、大きなプロジェクトはクリーンなコンテキストでフェーズに分割しましょう。次は、完成された実践フレームワークとしてbrainstorm → plan → cook → shipのワークフローを、そして大きな機能に厳密な計画が必要なときは仕様駆動開発を読んでください。
チーム全体で計画を標準化したいですか？ Engineer Kitのak-planスキルは、フェーズ＋ロードマップのプロセスを共有可能なアーティファクトとしてパッケージ化します。ネイティブのplan modeでもたいていの作業には十分ですが、再現性とドキュメントが欲しいときに役立ちます。