Explore → Plan → Implement（エクスプロア・プラン・インプリメント）

Claude Codeにコードを書かせると見当違いな実装が返ってきて困ったことがある人向け

Claude Codeに「Googleでログインできるようにして」とだけ頼むと、いきなりコードを書き出して、こちらが思ってたのと違う作りのものを返してくることがあります。動くには動くけど、見当違いの問題を解いてしまった状態です。Explore → Plan → Implement は、それを防ぐためにAnthropicが公式に推している作業の進め方です。

やることは単純で、いきなり書かせず「調べる→計画を立てる→実装する→確定する」の4段階に分けるだけ。公式ドキュメントは、この進め方の狙いを「solving the wrong problem を避ける」ことだと書いています。見当違いの問題を解いてしまうのを防ぐ、という意味ですね。

噛み砕くと

新しい職場の初日に、いきなり「この書類を全部直して」と言われても困りますよね。まず誰がどこで何をやってるか把握して、手順を紙に書き出して、それから手を動かす。そっちのほうが事故が少ない。Explore → Plan → Implement は、それをClaudeにやらせる進め方です。

調べる係（Explore）と、計画を立てる係（Plan）と、実際に手を動かす係（Implement）を、わざと別の段階に切り分けます。同じ会話の中で混ぜないのがコツ。混ぜると、まだ調べてる途中なのにファイルを書き換え始めて、土台がぐらついたまま家が建っていきます。

順番が命です。

調べる段階では「まだ変更しないで」を最初に言う

4段階の最初の2つ（調べる・計画する）は、プランモードという状態で進めます。プランモードに入っている間、Claudeはファイルを読んで質問に答えるだけで、勝手に書き換えません。公式の説明そのままで「reads files and answers questions without making changes（ファイルを読んで質問に答えるが、変更はしない）」状態です。

ここを飛ばして普通のモードのまま「いまのログインの仕組みを調べて」と頼むと、調べたついでに手が滑ってコードを書き始めることがあります。だから先にプランモードへ入れておく。これが土台です。

「個人ブログにGoogleログインを足す」で4段階を実際に動かす

題材は、自分の個人ブログに「Googleアカウントでログイン」ボタンを足す作業にします。これは公式ドキュメントが例に使っているのと同じ題材です。すでにブログ自体は動いていて、メールアドレスで入る独自のログインの仕組みが入っている前提で進めます。

ステップ1: Explore（調べる）— プランモードに入って現状を読ませる

まずプランモードに切り替えます。そのうえで、いまのログインまわりがどう作られているかを読んで把握してもらいます。ポイントは「まだ変更しないで」を言葉にしておくこと。

read /src/auth and understand how we handle sessions and login.
also look at how we manage environment variables for secrets.

日本語にすると「src/auth の中を読んで、いまセッションとログインをどう扱ってるか把握して。秘密の値の管理方法も見ておいて」です。Claudeは `src/auth` あたりのファイルを順に開いて、いまの作りを説明してくれます。ここで返ってくるのは説明だけ。ファイルは1文字も変わりません。

ステップ2: Plan（計画）— やることリストを先に作らせる

現状が頭に入ったら、まだプランモードのまま計画を作ってもらいます。公式のプロンプト例はこれです。

I want to add Google OAuth. What files need to change?
What's the session flow? Create a plan.

「Googleでのログインを足したい。どのファイルを変える必要がある？ログイン後の会話の流れはどうなる？計画を作って」という頼み方ですね。Claudeは「このファイルとこのファイルを直す」「Googleから戻ってきたあとの流れはこう」と、手順書を組み立ててくれます。

ここで大事なのが、できた計画をそのまま信じないこと。`Ctrl+G` を押すと、その計画が自分のエディタに開きます。中身を読んで、おかしいところを直してから先に進める。ここが効きます。

ステップ3: ここで初心者がやりがちな勘違い

計画ができた勢いで、同じ会話のまま「じゃあそのまま作って」と言いたくなります。これがやりがちな落とし穴。計画を練った会話には、検討の試行錯誤がごちゃっと残っています。その続きで実装させると、検討と実装が混ざって会話が散らかり、Claudeの精度が落ちることがあります。計画は計画として一度確定させる、という意識を持ったほうがいいです。

ステップ4: Implement（実装）— モードを抜けてから書かせる

計画に納得したら、プランモードを抜けて普通のモードに戻します。ここで初めて実際にコードが書かれます。公式のプロンプト例はこれ。

implement the OAuth flow from your plan. write tests for the
callback handler, run the test suite and fix any failures.

「さっきの計画どおりにGoogleログインの流れを実装して。コールバック処理のテストも書いて、テストを流して、落ちたら直して」という頼み方です。テストまで一気に頼んでいるのがミソ。Claudeは自分の計画と照らし合わせながら書いて、テストで自分の仕事を確かめます。

ステップ5: Commit（確定）— 変更を保存してPRを開く

実装とテストが通ったら、最後に変更を確定して保存します。公式のプロンプト例はとても短いです。

commit with a descriptive message and open a PR

「分かりやすいメッセージで変更を確定（commit）して、PRを開いて」。これでClaudeが変更内容を `commit` として記録し、PRまで作ってくれます。ここまでが1セット。

ステップ6: 検証を渡せたかを振り返る

公式ドキュメントは、検証材料を渡すことを「the single highest-leverage thing you can do（できることの中でいちばん効くこと）」と書いています。テスト・スクリーンショット・期待する出力のどれかを渡すと、Claudeが自分で答え合わせできる。今回はステップ4でテストを頼んでいたので、ここは満たせています。逆に何も渡さないと、それっぽいけど中身が怪しい実装が静かに通ってしまいます。

つまり Explore → Plan → Implement は何をしてくれるのか

• やってくれる: いきなり書く前に現状を読ませ、手順書を作らせ、こちらが確認してから実装に入る、という安全な順番を強制してくれる
• やってくれない: 計画の中身の良し悪しを保証はしてくれない。`Ctrl+G` で開いて自分の目で確かめる作業は人間側の仕事
• 意味が薄い場面: typo（打ち間違い）の修正、ログを1行足すだけ、変数名を変えるだけ。やることが一文で説明できる小さい変更は、計画の手間のほうが重い

使いどころ3シナリオ

シナリオ1: 作り方が固まっていないとき

たとえば個人ブログに「読者がコメントを書ける機能」を足したいけど、どう作るのが正解か自分でも分かっていない。公式が "uncertain about the approach（やり方に確信が持てない）" と呼ぶ状況です。こういうときこそ、まずプランモードで似た作りのコードを読ませて、選択肢を計画として並べてもらう。いきなり実装させると、最初に思いついた1案だけで突っ走ってしまいます。

シナリオ2: 変更が複数ファイルにまたがるとき

今回のGoogleログイン追加がまさにこれ。ログインのファイル、セッションを管理するファイル、Googleから戻ってきたあとの処理、表示部分のボタン。公式の言う "the change modifies multiple files（変更が複数のファイルに及ぶ）" 状況です。触る箇所が3つ4つに散るときは、先に全体の手順書を作っておかないと、片方を直したらもう片方が壊れる、みたいな事故が起きます。

シナリオ3: 自分が中身を知らないコードを触るとき

他人が作ったブログテーマを引き継いだ、とか、昔の自分が書いて中身を忘れたコードを直す、とか。公式の "unfamiliar with the code being modified（変更する対象のコードに不慣れ）" です。まず Explore で「このログインはどういう仕組み？」と質問して中身を理解してから計画に進む。知らないまま実装させると、既存の作法を無視した浮いたコードが混ざります。

初心者が踏みやすい落とし穴

• 全部の作業で計画を立てようとする。打ち間違いの修正やログ1行の追加みたいな小さい変更まで計画すると、手間のほうが重い。公式も「一文で変更内容を説明できるなら計画は省け」と書いています。直接頼んでいい。
• 調べる段階でコードを書かせてしまう。プランモードに入れず、「まだ変更しないで」を言わないと、調べたついでに実装に直行して見当違いのものが出来上がります。最初に状態を固める。
• それっぽい実装をそのまま信じる。公式が "the trust-then-verify gap" と呼ぶ罠で、見た目は正しいのに例外パターンを処理してない実装が返ってきます。テスト・スクリーンショット・期待する出力を必ず渡して検証させる。検証できないものは世に出さない。
• 計画を読まずに実装へ進む。`Ctrl+G` で計画を開いて中身を確かめてから進めてください。Claudeの計画が見当違いなこともあります。計画を確認する一手間が、あとの作り直しを防ぎます。
• 実装のときにプランモードを抜け忘れる。プランモードは「調べるだけ」のモードなので、入ったままだと実際の書き換えが走りません。「作って」と頼んだのに何も変わらない、と焦る前にモードを確認。
• 計画と実装を同じ会話で混ぜる。計画を練った会話の延長でそのまま実装させると、検討の試行錯誤と実装が混ざって会話が散らかります。場合によっては精度が落ちるので、計画を一度確定させてから実装に入るほうが安全です。
• 計画さえあれば中身を確認しなくていいと思い込む。計画は「やることリスト」であって完成保証ではありません。実装後の検証（テスト・スクリーンショット）まで含めて1セットだと考えてください。

書き方

プランモードで調べる → 計画を作る（Ctrl+Gで開いて直せる）→ モードを抜けて実装＋テスト → 変更を確定（commit）してPRを開く、の4段階

やってみるとこうなる

入力

（プランモードで）read /src/auth and understand how we handle sessions and login.

出力例

Explore（プランモード）: 「read /src/auth ... まだ変更しないで」→ Claudeが現状を読んで説明だけ返す。Plan（プランモード）: 「I want to add Google OAuth. ... Create a plan.」→ 手順書ができ、Ctrl+Gで開いて直せる。Implement（普通のモード）: 「implement the OAuth flow from your plan. write tests ...」→ 計画どおりに実装しテストで自己検証。Commit: 「commit with a descriptive message and open a PR」→ 変更を確定してPRを作成。

関連項目

• Plan Mode（プランモード）
• /plan（プラン）
• Agentic Loop（エージェンティック・ループ）

公式ドキュメント

https://code.claude.com/docs/en/best-practices