# Claude CodeのPlan Mode：2026年版、手順と4つのフェーズを解説 > Claude CodeのPlan Modeとは何か、Shift+Tabでの有効化方法、Anthropicによる4つのフェーズ、すぐに使えるプロンプトテンプレート、自律的な夜間タスクのための/goalコマンドを解説します。 Source: https://ailoot.ai/blog/ja/claude-code-plan-mode/ Canonical: https://ailoot.ai/blog/ja/claude-code-plan-mode/ Language: ja Publisher: Ailoot (https://ailoot.ai/) Translation: guide-197 Revision: sha256-1b6da707230a11689812dc0d8007819166e508d00f42e6d45dfafbd5a551fbdb 詳しくは[Ailootのドキュメント](https://ailoot.ai/docs/)をご覧ください。 ## Plan Modeとは何か、なぜそれだけでは不十分なのか？
重要なポイント Claude CodeのPlan Modeは、AIがファイルを読み、コードを分析し、変更案を提示する一方、承認されるまでは何も書き込まないモードです。Shift+Tabを2回押すか、`--permission-mode plan`フラグを使って有効にします。方法が不確か、コードに不慣れ、構成要素や運用への意味のあるリスクがある場合に役立ちます。明確で低リスクの誤字なら、独立した計画工程は通常不要です。
通常モードではClaude Codeはすぐにコードを書きます。進行を把握していないと、多数のファイルにまたがる差分が突然出てくることがあります。Plan Modeは手順を逆転させ、まず調査と計画、次に承認、その後に変更を行います。 Anthropicは公式ドキュメントでPlan Modeを次のように説明しています。

Plan modeは、変更を加えずに調査して変更案を提示するようClaudeに指示します。Claudeはファイルを読み、調査のためにシェルコマンドを実行し、計画を書きますが、コードは編集しません。

— Anthropic Docs, https://code.claude.com/docs/en/permission-modes
単純に聞こえますが、ここには大きな変化が隠れています。Plan Modeは作業のリズムを変えます。まず合意し、その後に実行するのです。これは見た目だけの調整ではなく、モードそのものの変更です。バイブコーディングをする人にとって厄介なのは、AIエージェントが急ぎがちなことです。通常モードで「Google認証を追加して」と頼むと、Claudeは1分でコードを書きますが、ファイルの半分は間違っているでしょう。Plan Modeでは同じ依頼がテキストの計画になり、コードに手を付ける前に2分で読んで修正できます。 海外のガイドではほとんど語られない落とし穴があります。Plan Mode単体では心もとないツールです。計画は現在の会話にしか存在しません。ウィンドウを閉じると計画は失われ、別のエージェントに引き継ぐこともできません。バージョンも履歴もありません。タスクが大きい場合（30ファイルのモジュールのリファクタリングや、新しいデータベースへの移行など）、計画はすぐにコンテキストウィンドウの上限に達し、質が落ち始めます。 そのため、Plan Modeはリポジトリ内の`plans/`フォルダと組み合わせるとうまく機能します。計画を`plans/2026-05-21-google-oauth.md`として保存し、フェーズごとにチェックボックスで分ければ、次のエージェントが引き継げます。これが[コンテキストエンジニアリング](https://ailoot.ai/blog/ja/context-engineering/)の考え方です。プロンプトの最中ではなく、プロンプトを出す前にコンテキストを管理します。 ## Claude CodeでPlan Modeを有効にするには？
重要なポイント Plan Modeを有効にする公式な方法は4つあります。セッション中にShift+Tabを2回押すか、プロンプトの前に`/plan`を付けます。起動時には`claude --permission-mode plan`フラグを使います。全体に適用するには、`.claude/settings.json`の`defaultMode`フィールドを設定します。現在のモードは、ターミナル下部の`⏸ plan mode on`で確認できます。
セッション中に使う最も手早い方法は、キーボード操作です。 ``` Shift+Tab # cycles through modes: default → acceptEdits → plan ``` 2回押すと、ターミナル下部に`⏸ plan mode on`と表示されます。3回目を押すと通常モードに戻ります。作業の規模が大きくなってきたとき、その場で切り替えられる最も便利な方法です。 2つ目は、1つのプロンプトの前にプレフィックスを付ける方法です。 ``` /plan write a plan to migrate the database from MySQL to Postgres ``` 自動承認モードを使っていて、セッション全体のモードは変えたくない場合に便利です。1つの依頼だけPlan Modeで処理し、その後はこれまでどおり作業を続けられます。 3つ目は、セッションの起動時に指定する方法です。 ```bash claude --permission-mode plan ``` タスクに計画が必要だと事前に分かっている場合に使います。大規模なリファクタリングや移行の前などが該当します。 4つ目は、プロジェクトの`.claude/settings.json`でデフォルトを設定する方法です。 ```json { "permissions": { "defaultMode": "plan" } } ``` どんな場合に役立つでしょうか。複雑なシステムで、どの変更も隣接するモジュールに影響しかねないチーム作業の場合です。Plan Modeをデフォルトにすると、誤変更からチーム全体を守れます。 見落とされがちな5つ目の小技として、`Ctrl+G`で計画をテキストエディタで開けます。計画がほぼ正しいものの、2〜3点を言い換えたり、制約を追加したりしたいときに使います。手動で編集して保存すれば、Claudeはその内容に従って続けます。 ## Plan ModeにおけるAnthropic標準の4フェーズ、Explore・Plan・Implement・Commitとは？
重要なポイント Anthropicはベストプラクティスで、4フェーズからなる標準的なワークフローを示しています。Explore（ファイルを読み、コンテキストを調べる）、Plan（編集せずに変更計画を作る）、Implement（通常モードに切り替えて計画どおりに実装する）、Commit（説明的なメッセージでコミットし、PRを作成する）です。各フェーズにはそれぞれのツール制限があります。
多くのガイドでは3フェーズ（Explore-Plan-Execute）や2フェーズ（Plan-Implement）だけを紹介しています。これらは簡略化したものです。[公式ベストプラクティスガイド](https://www.anthropic.com/engineering/claude-code-best-practices)でAnthropicが示しているのは、正確に4つのフェーズです。Commitを独立したフェーズにすることには意味があります。「もう少し調整した。コミットは後でやろう」と結果を放置せず、記録するようになるからです。これは作業を失う最も一般的な原因です。 計画が正確であるほど、実装に必要な反復は少なくなります。計画に10分かければ、実装は1つのプロンプトで済みます。1分で計画をざっと書けば、修正に1時間かかります。 Anthropic Docsの例を使って、Google OAuthを追加する場合の4フェーズを見てみましょう。 | フェーズ | Claudeが行うこと | あなたが行うこと | モード | |----|----|----|----| | **Explore** | `/src/auth`を読み、セッションと環境変数の扱いを調べる | 調査範囲を決める | Plan Mode | | **Plan** | 変更するファイル、新規作成するファイル、リスクを含む計画を作る | 計画を読み、Ctrl+Gで編集し、承認する | Plan Mode | | **Implement** | 計画どおりに実装し、OAuthフローのコード、テスト、コールバックを書く | 適用される変更を逐一確認する | DefaultまたはacceptEdits | | **Commit** | 説明を付けてコミットし、Pull Requestを開く | メッセージを確認し、PRをレビューする | Default | フェーズごとにプロンプトも異なります。Exploreでは「/src/authを読んで、セッションとログインの扱いを理解して」。Planでは「Google OAuthを追加したい。どのファイルを変更する必要がある？計画を作って」。Implementでは「計画に沿ってOAuthフローを実装し、テストを書いて、テストスイートを実行し、失敗を修正して」。Commitでは「説明的なメッセージでコミットし、PRを開いて」。 重要な補足があります。Plan ModeでもClaudeが調査用コマンドを実行することは禁止されません。Read、LS、Glob、Grep、web fetch、調査のためのシェルコマンドは許可されています。禁止されるのはEdit、Write、およびファイルシステムを変更する操作です。そのため、Claudeはプロジェクト構成を読み、`git log`を実行し、テストを確認できますが、誤って何かを変更することはありません。 ## Claudeの計画を読み、承認するかどうかを判断するには？
重要なポイント 良いClaudeの計画には、具体的なファイル名と変更内容、順序立てた手順、明示的なリスク、成功基準が含まれます。悪い計画は、具体性のない「認証モジュールを更新します」のような表現を使います。以下の7つの基準で承認するか判断しましょう。フィードバックで改良するか、Ctrl+Gで直接編集できます。
Claudeが計画の作成を終えると、次に何をするか選択肢が表示されます。 - 承認して自動モードで開始 - 承認して編集を受け入れる - 承認して編集ごとに手動で確認 - フィードバックを続けて計画を練る - Ultraplanで改良する（ブラウザーでレビュー） 計画を承認すべきか判断することは、Plan Modeの重要なスキルです。「Approve」を反射的に押してしまい、後でコミットを取り消す羽目になることはよくあります。AIの追従的な振る舞いはすぐに答えを返そうとし、あなたは早くコードに取りかかりたいと思っています。どちらも間違いです。 良い計画は7つの基準を満たします。 1. **具体的なファイル名。**「認証を更新する」ではなく、「`src/auth/login.ts:42-58`を変更し、`src/auth/oauth-callback.ts`を作成し、`src/auth/session.ts:103`を更新する」と書かれています。 2. **手順が明記されている。**「どこかで全部やる」ではなく、計画がフェーズまたはステップに分かれています。 3. 外部依存関係が示されている。新しいライブラリが必要なら記載されています。環境変数が必要な場合も同様です。 4. リスクが列挙されている。良い計画は「移行で既存セッションが壊れる可能性があるため、Xを確認する必要がある」と書きます。悪い計画は副作用に触れません。 5. **成功基準がある。**「`test/auth`のテストが通り、リンターがクリーンで、開発サーバーがエラーなく起動する」などです。 6. 「根拠のない」前提がない。Claudeが「ライブラリZを使う」と書いたら、プロジェクトにインストールされているか確認してください。AIが作り出したものなら、`package.json`に記載がないと分かります。 7. 画面に収まる。単純な機能の計画が200行に及ぶなら、タスクが大きすぎて1つの計画では扱えない可能性があります。分割しましょう。 計画が基準を満たさない場合、選択肢は3つあります。 - **フィードバックを続けて計画を練る**—気に入らない点を具体的にClaudeに伝えると、計画を書き直します。 - **Ctrl+G**—エディタで計画を開き、手動で編集して保存します。Claudeはあなたのバージョンで続けます。 - **Ultraplanで改良する**—計画をClaude Code on the webのブラウザーモードに送り、セクションを確認してコメントした後、ローカルまたはクラウドで実行します。 実装の途中で問題が起きたら、無理に進めないことです。Plan Modeに戻って計画を書き直しましょう。後で40コミットを取り消すより10倍安く済みます。 ## Plan Mode + `plans/`フォルダ：長いコンテキストに対応する組み合わせ
重要なポイント Plan Mode単体で機能するのは現在の会話の中だけです。ウィンドウを閉じると計画は消えてしまいます。リポジトリに`plans/YYYY-MM-DD-feature.md`フォルダを作れば、計画を永続的な成果物にできます。フェーズ、チェックボックス、ステータスを含むファイルを、次のエージェントが引き継げます。「記憶の中の計画」から「コードの中の計画」への転換です。
Plan ModeはClaude Codeのモードです。`plans/`フォルダは、その上に構築する方法論です。フォルダを作らずにPlan Modeを使うと、1時間も作業すれば限界に達します。 考え方はこうです。Claudeのコンテキストウィンドウはセッションの記憶です。Opus 4.7では100万トークンを入れられますが、これは会話全体の容量です。複雑なタスクを1つの会話で計画し、実装を依頼し、バグを議論し、さらに別の話をすると、ウィンドウは「膨張」します。Claudeは初期の決定を忘れ始め、コンテキストを混同し、同じ質問を繰り返します。 解決策は黄金律です。**1つのタスクにつき1つの会話**。 手順は次のとおりです。 1. 会話1—計画を作る。Plan Modeを有効にし、タスクを説明すると、Claudeが計画を作成します。計画を`plans/2026-05-21-feature-name.md`に保存します。ウィンドウを閉じます。 2. 会話2—フェーズに分ける。新しいチャットを開き、「`plans/2026-05-21-feature-name.md`を開いて、フェーズに分けて」と頼みます。更新したファイルを保存します。 3. 会話3—フェーズ1を実装する。新しいチャットを開き、「`plans/2026-05-21-feature-name.md`にあるフェーズ1を実装し、完了した項目にチェックを入れて」と頼みます。ウィンドウを閉じます。 4. 会話4—フェーズ2を実装する。同じように進めます。 こうすると何がよいのでしょうか。各会話のコンテキストウィンドウを新鮮に保てます。フェーズ3を担当するClaudeはフェーズ1の詳細を知りませんが、リポジトリに`plans/`ファイルがあるため、計画は把握しています。サブエージェント、新しいセッション、`/goal`による実行など、次のエージェントが計画を引き継いで続けられます。 方法を比較します。 | 特徴 | Plan Modeのみ | Plan Mode + `plans/`フォルダ | |----|----|----| | 永続性 | 現在のチャットのみ | リポジトリに永続的に保存 | | 別のエージェントへの引き継ぎ | 不可能 | `cat plans/file.md` | | バージョンと履歴 | なし | git diffで確認 | | サブエージェントへの対応 | 現在のセッションのみ | 各フェーズを専用サブエージェントに割り当て | | チェックボックスとステータス | テキストのみ | Markdownのチェックボックス`[ ]` / `[x]` | | 計画のサイズ | ウィンドウの上限まで | 制限なし | 機能ごとに計画ファイルを1つ作ります。3か月後に、なぜある決済プロバイダーを別の候補より選んだのか思い出したいとき、該当する計画を開いて意思決定の履歴を読めます。何を話し合い、どの選択肢を検討し、なぜその道を選んだかが分かります。 これらは進行中の作業計画です。静的なドキュメントは数か月で古くなります。 ## Plan Modeと/goalを使って、Claudeを寝ている間に働かせるには？
重要なポイント `/goal`は、Anthropicが1年にわたって話してきた自律ループです。`/goal`コマンドはClaude Code v2.1.139（2026年5月11日）に登場しました。完了条件を設定すると、人間が関与せずにClaudeが条件を満たすまで作業します。小型の評価モデルが各ターンの後に、条件を満たしたかを確認します。
長時間のAIセッションにおける最大の制約は、モデル自体ではなく、Enterを押す人です。Claudeは各ターンの終わりに達するたび、あなたの返答を待ちます。`/goal`はその待ち時間をなくします。 構文は簡単です。 ```bash /goal all tests in test/auth pass and lint is clean, or stop after 20 turns ``` 条件は最大4000文字です。1セッションにつき目標は1つです。各ターンの後にHaiku miniモデルがトランスクリプトを読み、「条件達成—終了」または「未達成—次のターン」と判断します。評価モデルはツールを呼び出さず、読むだけです。 目標を解除するエイリアスは次のとおりです。`/goal stop`、`/goal off`、`/goal reset`、`/goal none`、`/goal cancel`。 Plan Modeとの組み合わせは次のようになります。 1. Plan Modeを有効にします（`Shift+Tab`を2回押す）。 2. 「MySQLからPostgresへのデータベース移行計画を作り、フェーズと基準を付けて`plans/2026-05-21-postgres-migration.md`に保存して」と頼みます。 3. 計画を確認し、編集して、承認します。 4. Plan Modeを終了します（`Shift+Tab`をもう1回押す）。 5. 目標を設定します。「`plans/2026-05-21-postgres-migration.md`の全フェーズを完了し、チェックボックスにチェックを入れ、すべてのテストを通す。50ターンで停止する。」 6. ノートパソコンを閉じて眠ります。 朝に結果を確認すると、「✓ goal completed」または「◎ stopped after 50 turns」と、実施内容の履歴が表示されます。 `/goal`でトークンを浪費しないための重要なルールが3つあります。 **ルール1：測定可能な最終状態。**「見栄えをよくする」はよくありません。「`npm test`が0を返し、`npm run lint`が0を返し、`CHANGELOG.md`に項目を追加する」は適切です。 ルール2：明示的な検証。条件には検証可能なもの、つまりコマンド、ファイル、エンドポイントを含めます。「すべて動く」ではなく、「curl localhost:3000/api/usersが200を返す」とします。 ルール3：ターン数を制限する。必ず`or stop after N turns`を追加します。Anthropicはドキュメントで明示的に推奨しています。

目標の実行時間を制限するには、条件にターン数または時間の節を追加します。たとえば「or stop after 20 turns」のようにします。

— Anthropic Docs, https://code.claude.com/docs/en/goal
`or stop after`を付けずに`/goal`を有効にすると、一晩で予算が消える可能性があります。 ## Plan Modeをエンジニアリングプロセスに変える4ステップのサイクルとは？
重要なポイント 構造のない単純なPlan Modeでは、平凡な結果しか得られません。効果的なワークフローは、1つのウィンドウで4つの手順を踏みます。解決策を出さずに事実を確認し、ネット上の先例をもとに選択肢を考え、2〜3手先のリスクまで含む詳細な計画を作り、根拠のない前提がないか自分で計画を確認します。この順序が、AIの追従的な振る舞いを抑えます。
よくある間違いは、「どう直せばいい？」と尋ねることです。Claudeが解決策を提示し、それを適用しても、何も直らないか、状況が悪化します。これが「AIの追従的な振る舞い」です。Claudeは素早く答えるよう訓練されており、あなたは早くコードに取りかかりたいと思っています。4ステップのサイクルがこの問題に対処します。 この4ステップのサイクルは、この振る舞いを抑えます。Plan Modeのセッション1つの中で、順番に使います。 **ステップ1. 解決策を出さずに事実を確認する。** プロンプト：「次の問題が起きています：\[症状の説明\]。今のあなたの仕事は事実を確認することです。解決策、アイデア、助言は禁止です。記録するのは、私が観察したこと、再現できる手順、利用可能なデータ、不足しているデータだけです。厳守する停止条件：解決策を提案しないこと。診断だけを記録してください。」 これにより、AIの最初の衝動である「解決策はこちらです」を抑えます。Claudeは「分かっていることと、分かっていないこと」で止まらざるを得ません。 **ステップ2. 先例をもとに選択肢を考える。** プロンプト：「診断が確定したので、類似の問題の解決例をオンラインで探してください。少なくとも3つの異なるアプローチを挙げてください。それぞれについて、一次情報へのリンク、簡潔な説明、今回の状況における長所と短所を示してください。」 これにより、AIの2つ目の衝動である「思いつきで解決策を作る」を抑えます。外部の情報を探し、確認可能なアプローチを持ち帰らせます。 **ステップ3. リスクを含む詳細な計画を作る。** プロンプト：「ステップ2の最良の選択肢を使い、詳細な計画を立ててください。具体的に変更するファイル、追加するもの、削除するもの、作成するテスト、壊れる可能性があるもの、2〜3手先にあるリスクを挙げてください。」 これはおなじみのPlanフェーズですが、1つ違いがあります。Claudeの推測ではなく、ステップ2で確認した選択肢をもとにしています。 **ステップ4. 計画を自己点検する。** プロンプト：「必須の自己点検をしてください。計画を正直に見直し、コード、ドキュメント、ステップ2の先例で検証していない根拠のない推測がないか確認してください。あれば明示して、計画を修正してください。」 これが最後のフィルターです。Claudeは自身の推論を確認し、幻覚を起こした箇所を認めなければなりません。このステップでは通常、計画の項目が少なくとも2つ修正されます。 4つのステップを終えれば、計画は承認できる状態です。タスクを理解し、選択肢を比較し、リスクを考慮したうえで実装に進めます。 この方法論は、難しいバグの診断や、誤りのコストが高いアーキテクチャ上の判断のためのものです。Plan Modeに適用すると、バイブコーディングをする人の最大の悩みである「AIが解決策を提示したので適用したら、すべてが壊れた」を解消します。 ## よくあるタスクでPlan Modeに使える5つのプロンプトテンプレートとは？
重要なポイント すぐに使えるプロンプトは、タスクごとに10〜15分を節約し、計画の質を高めます。モジュールのリファクタリング、データベース移行、新機能の追加、テスト作成、複雑なエラーのデバッグに使える汎用テンプレートが5つあります。それぞれ4ステップのサイクルに沿い、`plans/`フォルダと結び付いています。
**テンプレート1. モジュールのリファクタリング。** ``` Plan Modeを有効にします。タスク：{module-name}モジュールをリファクタリングします。 ステップ1：{module-path}モジュールの現在の構成を調べてください。以下を説明してください。 - モジュールに含まれるファイル - 外部依存関係 - 重複している部分 - 複雑になりすぎている関数 ステップ2：類似のモジュールをリファクタリングしたオンライン事例を2〜3件探してください。 少なくとも1つはAnthropic公式、または関連フレームワークの公式ドキュメントにしてください。 ステップ3：リファクタリング計画をplans/YYYY-MM-DD-refactor-{module}.mdに作成してください。 - 名前を変更するファイル - 別モジュールに切り出す関数 - 維持するテストと書き直すテスト - リスク：ユーザーに影響する可能性があること ステップ4：自己点検してください。計画に「根拠のない」前提はありませんか？ 書き直すか削除してください。 ``` **テンプレート2. データベース移行。** ``` Plan Modeを有効にします。タスク：データベースを{old}から{new}に移行します。 ステップ1：{schema-reading-command}を使って現在のデータベーススキーマを調べてください。以下を説明してください。 - 存在するテーブルとその規模 - 関連、インデックス、制約 - マイグレーションの保存場所 - 重要なデータ ステップ2：本番プロジェクトにおける{old → new}の移行事例を探してください。 pg_dump、dual-write、blue-greenの、少なくとも3つの異なるアプローチを挙げてください。 それぞれについて、データ量に照らした長所とリスクを列挙してください。 ステップ3：移行計画をplans/YYYY-MM-DD-db-migration.mdに作成してください。 - フェーズ（バックアップ、移行、検証、切り替え） - 各フェーズの成功基準 - 問題発生時のロールバック計画 - ダウンタイムの有無 ステップ4：自己点検してください。すべての数値にドキュメントの裏付けがありますか？ 開発環境に照らして各ステップを頭の中で確認しましたか？ ``` **テンプレート3. 新機能の追加。** ``` Plan Modeを有効にします。タスク：プロジェクトに{description}機能を追加します。 ステップ1：プロジェクト内で類似機能が現在どのように動いているか調べてください。 特に、以下を確認してください。 - {file-1} - {file-2} - 使われているアーキテクチャパターン - 類似機能のテスト ステップ2：類似のアーキテクチャを使うオープンソースプロジェクトで、この機能がどう実装されているか探してください。 少なくとも2つの異なるアプローチを挙げてください。 ステップ3：plans/YYYY-MM-DD-feature-{name}.mdに計画を作成してください。 - 新規ファイルの一覧 - 具体的な行を示した変更ファイルの一覧 - 実装の順序 - 追加するテスト - 今後のセッション向けのルールとしてCLAUDE.mdに追加する内容 ステップ4：自己点検してください。計画はプロジェクトのアーキテクチャに沿っていますか？ まだインストールされていないライブラリを前提にしていませんか？ ``` **テンプレート4. テストの作成。** ``` Plan Modeを有効にします。タスク：{name}モジュールをテストでカバーします。 ステップ1：{path}モジュールを調べ、以下を特定してください。 - 公開関数とそのシグネチャ - テストしない内部関数（実装の詳細） - エッジケース：空の入力、エラー、並行アクセス ステップ2：同じフレームワークを使う、人気のオープンソースプロジェクトで類似タスクのテスト例を探してください。 ステップ3：plans/YYYY-MM-DD-tests-{module}.mdにテスト計画を作成してください。 - 各公開関数について、テストの一覧 - 必要なモック - フィクスチャ - 検証方法（アサーションの形式） ステップ4：自己点検してください。すべてのテストは実装ではなく動作を検証していますか？ エッジケースをカバーしていますか？ ``` **テンプレート5. 複雑なエラーのデバッグ。** ``` Plan Modeを有効にします。タスク：エラーの原因{symptom-description}を理解します。 ステップ1：事実を確認します。解決策やアイデアは禁止です。以下だけを挙げてください。 - 観察したこと（エラーの正確な文言） - 再現手順 - 利用可能なデータ（ログ、トレース、ライブラリのバージョン） - 不足しているデータ（追加で収集する必要がある情報） ステップ2：このエラーの事例を探してください。 GitHubのissueやドキュメントから少なくとも3つの情報源を挙げてください。 各事例について、リンクと解決策の簡潔な要約を示してください。 ステップ3：plans/YYYY-MM-DD-bug-{name}.mdに診断計画を作成してください。 - 確認する仮説（可能性の高い順） - 各仮説を確認するコマンドやスクリプト - 各確認で予想される結果 ステップ4：自己点検してください。計画に「根拠のない」仮説はありませんか？ すべての仮説はステップ1の事実と結び付いていますか？ ``` 各テンプレートをコピーし、`{parameters}`を自分の値に置き換えて、Plan ModeのClaude Codeに貼り付けてください。結果として、`plans/`に実用的な計画ができ、承認して実装に使えます。 ## Plan Modeと通常モード、どちらを選ぶべき？
重要なポイント 方法が不明、コードに不慣れ、設計判断、移行、大きな副作用がある場合はPlan Modeを使います。ファイル数は依存関係を考える手がかりで、厳密な基準ではありません。小さく理解済みで低リスクなら直接作業できますが、一文で説明できるだけで認証や移行が安全にはなりません。
Anthropicは公式ドキュメントで次のように述べています。

Plan modeは便利ですが、余分な手間がかかります。範囲が明確で小さな変更（タイプミス、ログ行、変数名の変更）なら、Claudeにすぐ実行するよう頼んでください。アプローチが分からないとき、変更が複数ファイルに及ぶとき、またはコードに不慣れなときに、計画が最も役立ちます。差分を一言で説明できるなら、計画は省いてください。

— Anthropic Docs, https://www.anthropic.com/engineering/claude-code-best-practices
独立した計画を省けるのは、実際の差分が小さく、理解でき、低リスクのときです。方法の調査や、危険な横断変更の調整には計画を使います。ファイル名や一文の目的が分かっても、移行、認証、データ整合性のリスクは残ります。 判断表： | タスク | モード | 理由 | |----|----|----| | READMEのタイプミス | Default | 1ファイル、1か所の明白な変更 | | 1ファイル内の変数名変更 | Default | 範囲と参照を確認できる。副作用も評価する | | ログ行の追加 | Default | ロジックに影響しない1行の変更 | | ページに新しいボタンを追加 | Default | ボタンが1つで配置場所も分かるなら、計画は不要 | | モジュールのリファクタリング | Plan Mode | 5つ以上のファイル、副作用のリスク | | データベース移行 | Plan Mode + `/goal` | 複数ステップの作業で、ロールバック計画が必要 | | 認証の追加 | Plan Mode | 10以上のファイルに影響し、セキュリティが重要 | | モジュールのテスト作成 | Plan Mode | 何をテストするか判断する必要がある | | 原因不明のバグのデバッグ | Plan Mode + 4ステップサイクル | 診断なしでは解決策が的外れになる | | フレームワーク全体の移行 | Plan Mode + `plans/` + 夜間の`/goal` | フェーズと自律ループが必要な長期タスク | モードを選ぶ前に、方法、副作用、検証を理解しているか確認します。小さく局所的で低リスク、明白な検査があるなら直接進めます。不確実、不慣れ、移行、認証、複数構成要素の調整があるなら、対象3〜5ファイルをすでに挙げられても先に計画してください。 ## Plan Mode + CLAUDE.md + サブエージェントを組み合わせて、信頼性を高めるには？
重要なポイント Plan Modeは適切に設定した[CLAUDE.md](https://ailoot.ai/blog/ja/claude-md-template/)や[サブエージェント](https://ailoot.ai/blog/ja/claude-code-subagents/)と組み合わせると、10倍強力になります。CLAUDE.mdにはClaudeが計画作成で使うルールを設定します。サブエージェントを使うと、計画のフェーズを複数のエージェントに並行して割り振れます。この組み合わせがなければ、Plan Modeは一度限りのツールにとどまります。
CLAUDE.mdは、Plan Modeを含むすべてのセッションの開始時にClaudeが読むファイルです。CLAUDE.mdに「日付をハードコードしない。必ずデータベースから取得する」と書いてあれば、計画で日付をハードコードする提案は出ません。そのようなルールがなければ、計画は何でも提案できます。 組み合わせると、次のように機能します。 **レイヤー1. CLAUDE.mdでルールを定める。** このファイルでは、プロジェクトの技術スタック、アーキテクチャ原則、禁止事項（「非推奨APIを使わない」）、要件（「すべてのメールで共有レイアウトを使う」）を指定します。詳しくは[CLAUDE.mdの設定方法](https://ailoot.ai/blog/ja/claude-md-template/)をご覧ください。 **レイヤー2. Plan Modeでルールをタスクに適用する。** Plan Modeを有効にして「OAuthを追加して」と頼むと、ClaudeはCLAUDE.mdを読み、「トークンはデータベースではなくRedisに保存する」というルールを確認して、すぐ計画に反映します。計画はプロジェクトのアーキテクチャに沿ったものになります。 **レイヤー3. サブエージェントに作業を分ける。** 計画をフェーズに分けた場合、各フェーズを個別の[サブエージェント](https://ailoot.ai/blog/ja/claude-code-subagents/)に割り当てられます。各サブエージェントは独自のコンテキストウィンドウで作業するため、メインのコンテキストを圧迫しません。`plans/`の計画は信頼できる唯一の情報源として残ります。サブエージェントが読み、担当フェーズを実行し、チェックボックスを更新します。 ## Plan Modeを壊す7つの間違いとは？
重要なポイント Plan Modeがうまくいかない原因は、ツールの弱さではなく、よくある使い方の間違いです。主な間違いは7つです。計画をファイルではなく記憶に置く、すべてのタスクを1つのチャットに詰め込む、フェーズなしで計画を作る、十分に調査しない、診断なしにAIの追従的な提案を許す、自己点検を省く、`/goal`で曖昧な条件を使う、です。
**間違い1. 計画がチャットにしか存在しない。** 症状：計画を書いてウィンドウを閉じ、翌日に続きをしたいのに、何も残っていません。コンテキストが失われています。解決策：計画は必ずリポジトリ内の`plans/YYYY-MM-DD-feature-name.md`に保存します。チャットは作業机、ファイルはアーカイブです。 **間違い2. すべてのタスクを1つのチャットに入れる。** 症状：1つのセッションで認証、移行、UIデザイン、バグと次々に議論します。コンテキストウィンドウが「膨張」し、Claudeは前の内容を忘れます。解決策：1つのタスクにつき1つの会話です。計画が完成したらウィンドウを閉じ、実装を始めるときは新しいチャットを開きます。 **間違い3. フェーズのない3000行の計画。** 症状：計画はありますが、チェックボックスや区分がありません。何が終わり、何が残っているか分からず、委任もできません。解決策：各計画を3〜7フェーズに分けます。各フェーズを具体的な作業項目のチェックリストにします。 **間違い4. 計画の前に十分な調査をしない。** 症状：先例を探すよう頼まなかったため、Claudeが思いつきで解決策を提示します。1週間後に、オープンソースではずっと前からより良い方法が使われていたと分かります。解決策：4ステップサイクルのステップ2として、計画を作る前にClaudeにオンラインで2〜3件の先例を探させます。 **間違い5. AIの追従的な振る舞いが診断なしに解決策を出す。** 症状：「エラーXをどう直せばいい？」と尋ね、Claudeの解決策を適用しても何も直らないか、状況が悪化します。解決策：必ず「事実を確認する。解決策は禁止」と始めます。選択肢に進むのは診断の後だけです。 **間違い6. 自己点検を省く。** 症状：計画はもっともらしく見えますが、根拠のない前提が2〜3個含まれています（架空のライブラリ、存在しないAPI、誤ったバージョンなど）。その箇所で実装が失敗します。解決策：4ステップサイクルのステップ4として、Claudeに計画を正直に見直し、前提を指摘させます。 **間違い7. `/goal`の条件が曖昧。** 症状：「見栄えをよくする」という`/goal`を設定して夜通し動かしたら、朝には利用枠の200ドル分が使い切られていました。解決策：検証コマンドと必須の`or stop after N turns`を含む、測定可能な条件だけを使います。「よくする」「磨き上げる」といった表現は避けます。 バイブコーディングをする人が最もよく犯す8つ目の間違いは、`plans/`フォルダ自体を作らないことです。`plans/`フォルダのないPlan Modeは方法論ではなく、おもちゃです。Plan Modeを使ってもファイルを作らなければ、その機能の10%しか活用できません。 ## Plan Modeを初めて使った後、次に何をすべき？
重要なポイント Plan Modeの初回体験は出発点です。次にすべきことは、まだなければ[CLAUDE.md](https://ailoot.ai/blog/ja/claude-md-template/)を設定すること（なければ計画の拠り所がありません）、リポジトリに方法論を実践するための`plans/`フォルダを作ること、そして寝る前に自律タスク1つで`/goal`を試すことです。この3つ、Plan Mode、CLAUDE.md、`plans/`を組み合わせると、実用的なシステムになります。
難易度が低い順に、具体的なステップを3つ紹介します。 **ステップ1. まだなければCLAUDE.mdを設定する。** CLAUDE.mdがないと、Plan Modeは「真空の中」で動きます。Claudeはプロジェクトのルールを知らず、アーキテクチャを壊す計画を提案します。詳しくは[CLAUDE.mdの設定方法](https://ailoot.ai/blog/ja/claude-md-template/)をご覧ください。最小限のCLAUDE.mdは、技術スタック、ルール、禁止事項を記した50〜80行です。長さよりも具体性が重要です。 **ステップ2. リポジトリに`plans/`フォルダを作る。** プロジェクトのルートに`plans/`フォルダを追加します。命名形式を`YYYY-MM-DD-feature-name.md`に統一します。計画ごとにファイルを1つ作成します。1か月後には20〜30ファイル、半年後には100以上になるでしょう。それらは、プロジェクトの意思決定を記録した生きた履歴になります。 **ステップ3. 1つのタスクで`/goal`を試す。** 通常なら手作業で30〜40分かかるタスクを選びます。Plan Modeを有効にし、計画を作って`plans/`に保存します。Plan Modeを終了して、`/goal complete all phases in plans/file.md, all tests pass, or stop after 30 turns`を設定します。ノートパソコンを閉じて1時間、別のことをしてください。戻ったら結果を確認します。 これら3つが最低限です。これは段階的に整えるものです。一晩ですべてを作ろうとしないでください。まずCLAUDE.mdを作り、1週間後に`plans/`を追加し、1か月後に夜間の`/goal`を試します。
### 出典 - [Anthropic Docs - Permission Modes](https://code.claude.com/docs/en/permission-modes) - [Anthropic Docs - Common Workflows](https://code.claude.com/docs/en/common-workflows) - [Anthropic Engineering - Claude Code Best Practices](https://www.anthropic.com/engineering/claude-code-best-practices) - [Anthropic Docs - /goal command](https://code.claude.com/docs/en/goal) - [Anthropic Docs - Changelog](https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md)
準備ができたら、[Ailoot](https://ailoot.ai/)をご覧ください。 ## Claude CodeのPlan Mode：2026年版、手順と4つのフェーズを解説：よくある質問 ### 変更ファイルが分かれば、計画を省いてよいですか？ いいえ。ファイル名が分かっても副作用と検証の不確実性は残ります。移行、認証、複数構成要素の調整は、一覧が明確でも計画してください。 ### Plan Modeを別に使わなくてもよいのはいつですか？ 局所的な誤字など、小さく理解済みで低リスク、確認方法も明確な差分なら直接進められます。方法が不明、コードに不慣れ、運用・横断リスクがある場合は計画します。 ## Ailoot · 企業とそのプロジェクト群 Ailootは、蓄積した運営経験、幅広い顧客基盤、安定したサービス、継続的なKPI管理を基盤としています。 企業とそのプロジェクト群：数百万の顧客、毎月数十億規模の売上。 Ailootはこの運営経験を、お客様の製品、エージェント、アプリケーション、自動化でAI機能を利用するためのAPIアクセスに活かしています。