はじめに
Claude Codeに作業をお願いするとき、どのようなフローで進めているでしょうか。
いきなりやりたいことをざっと伝えて、そのまま実装まで進めてもらっていないでしょうか。
この機能を実装して
→ このような頼み方では良い結果が出にくいです
Claude Codeの公式ベストプラクティス( https://code.claude.com/docs/ja/best-practices )では、いきなり実装させるのではなく、Explore → Plan → Implement → Commit のように、調査・計画・実装・コミットを分ける進め方が紹介されています。
このブログでは、Claude Codeにただ実装をお願いするのではなく、
調査から始め、プランを立て、実装し、検証し、commit / PR まで進める重要性について整理します。
まず結論：「ちゃんと使う」とは「実装させる」ではなく「ループを設計する」こと
Claude Codeを浅く使ってしまうと、例えばこうなります。
この機能を実装して
Claudeはそれっぽくコードを書いてくれます。
ただ、それだけだといくつか問題があります。
- 既存設計を十分に読んでいない
- 影響範囲が曖昧
- テスト方針がない
- 動作確認が「できました」という自己申告になる
- PRレビューで人間が大量に尻拭いする
これでは、AIを使っているように見えても、実は開発プロセス自体はあまり変わっていないかもしれません。
一方で、もう少し丁寧に使う場合はこうなります。
まず実装せずに関連コードを調査してください。
既存の設計、変更が必要なファイル、影響範囲、テスト方針を整理してください。
その後、実装計画を出してください。
まだファイルは変更しないでください。
この違いはかなり大きいと思います。
Claude Codeを「実装者」としてだけ扱うのではなく、
調査者、設計補助者、実装者、テスター、レビュアーとして段階的に使う。
ここが最初の一歩になると思います。
公式ベースの5ステップ
公式のベストプラクティスでは、開発フローとして Explore → Plan → Implement → Commit が紹介されています。
現場で使うなら、ここに Verify を明示的に加えた5ステップにすると扱いやすいです。
| Step | フェーズ | Claudeにやらせること | 人間が見ること |
|---|---|---|---|
| 1 | Explore | 関連コード、仕様、既存パターンを調査する | 重要な前提を見落としていないか |
| 2 | Plan | 実装方針、変更ファイル、リスク、テスト方針を出す | 方針が妥当か |
| 3 | Implement | 計画に沿って実装する | スコープが広がっていないか |
| 4 | Verify | test / lint / build / screenshot / review を実行する | 「できた」の根拠があるか |
| 5 | Commit / PR | 差分要約、コミット、PR本文を作る | レビュー可能な単位になっているか |
大事なのは、実装前にExploreとPlanを挟むことだと思います。
Claudeにいきなりコードを書かせると、正しそうに見えても、問題設定を間違えたコードが出てくることがあります。
Step 1: Explore — まず読ませる、まだ書かせない
最初にやるべきことは、実装ではなく調査だと思っています。
悪い例：
ログイン周りを修正して
良い例：
まず実装せずに、ログイン処理に関係するコードを調査してください。
特に以下を確認してください。
- 認証フロー
- セッション管理
- トークン更新
- エラー時の挙動
- 関連するテスト
調査結果として、関連ファイル、処理の流れ、変更候補を整理してください。
Claude Codeはコードベースを読めるので、最初に「どこを見るべきか」を人間が全部指定する必要はありません。
ただし、何を調査してほしいかは明確にしたほうがよいです。
さらに、調査が大きくなりそうな場合はSubagentsを使うのが有効です。
Subagentsを使うと、別コンテキストで調査を進め、メイン会話のコンテキストを汚さずに結果だけ返すような進め方ができます。
調査フェーズの目的は、Claudeに「正しい問題」を掴ませることだと思います。
Step 2: Plan — 実装計画
調査が終わったら、すぐ実装ではなく計画を出させます。
ここでのポイントはプランモードで進めることで、ClaudeCode上で「shift+tab」でplan modeに入れることが重要です（プランモードでお願いします。とか入れておくと文脈から判断して自動で切り替えてくれる時もあります）
このプランモードが非常に重要なので、ここだけでも持って帰っていただきたいです。
実装計画を作ってください。
以下の形式で整理してください。
1. 変更するファイル
2. 変更内容
3. 既存仕様への影響
4. 代替案
5. リスク
6. テスト方針
まだコードは変更しないでください。
ここで人間がやるべきことは、計画をレビューし、理解することです。
AIが考えたプランを理解し、説明できることが重要だと思っています。
また、プランはmdとして保存しておくとあとで振り返れるので便利です。
Step 3: Implement — 小さく実装させる
計画が妥当なら、実装に入ります。
上記の計画に沿って実装してください。
計画から外れる必要がある場合は、実装前に理由を説明してください。
実装後、変更したファイルと変更理由をまとめてください。
ここで重要なのは、Claudeに自由にやらせすぎないことだと思います。
特に注意したいのは以下です。
- ついでのリファクタをさせない
- 関係ないファイルを触らせない
- 既存の設計思想を壊させない
- テストなしで「完了」にさせない
大きいタスクでは、最初から全部やらせるのではなく、ファイル単位・責務単位に分けるほうが安定しやすいです。
まずAPI層だけ実装してください。
UIやテストはまだ変更しないでください。
完了したら差分を説明してください。
Claude Codeは自律的に動ける一方で、放置するとスコープが膨らんでしまうことがあります。
人間の仕事は、手を動かすことから、スコープを制御することに少しずつ移っていきます。
Step 4: Verify — 「できました」を信じない
Claude Codeを使う上で特に重要なのは、検証です。
悪い例：
動いた？
良い例：
以下を実行してください。
- npm test
- npm run lint
- npm run build
失敗した場合は原因を説明し、修正して再実行してください。
最後に、実行したコマンドと結果をまとめてください。
海外の実践者も、AIが書いたコードは「ジュニアエンジニアが出したコード」として扱い、必ずテスト・実行・レビューするという考え方を強調しています。
Addy Osmani氏も、Claude Codeのようなツールを使う場合は、実装後にテストを走らせ、失敗したらAIにデバッグさせる write code → run tests → fix のループをワークフローに組み込むと述べています。
Claude Codeに向いているのは、まさにこのようなループだと思います。
テストが失敗している限り、原因を調査し、修正し、再実行してください。
テストが通ったら、最終結果だけでなく、失敗原因と修正内容も説明してください。
さらに、Claude Codeには /goal という考え方もあります。
/goal は「この条件が満たされるまで作業を続ける」という完了条件を設定するものです。
これは、毎回人間が「続けて」「直して」「もう一回テストして」と指示する状態から抜け出すための仕組みです。
ただし、完了条件はClaudeの出力上で確認できる形にする必要があります。
Step 5: Commit / PR — レビュー可能な形にまとめる
実装と検証が終わったら、最後にPR化します。
今回の変更をまとめてください。
- 概要
- 変更したファイル
- 変更理由
- 確認したコマンド
- レビューしてほしい観点
- 懸念点
その後、PR本文のドラフトを作ってください。
ここまでClaudeに任せられると、PRレビューの質も上がりやすくなります。
特に良いと思うのは、Claudeに「レビュー観点」を書かせることです。
このPRでレビュアーに重点的に見てほしい観点を3つ挙げてください。
仕様・セキュリティ・保守性の観点を含めてください。
AIが作ったコードほど、レビュー観点を明文化したほうがよいと思います。
「どこを見ればいいか分からない巨大PR」は、AI時代にはさらに危険になりやすいです。
また、Webページの実装の場合などは報告用にmdにスクショを含めたmainと作業ブランチの差分をレポートとして作成しています。
これによってmainブランチと作業ブランチの変更箇所が視覚的にもわかりやすく、報告にも使用できるのでおすすめです。（サイトの操作はPlaywrightを使用しています）
世界的に進んでいる使い方：Prompt EngineeringからLoop Engineeringへ
2026年現在、海外のClaude Code / Codex周辺では、単に「良いプロンプトを書く」よりも、Loop Engineering という考え方が語られるようになっています。
Loop Engineeringとは、ざっくり言えば、
人間が毎回プロンプトを書くのではなく、エージェントが継続的に調査・実装・検証・報告する仕組みを設計することです。
Addy Osmani氏(Googleのソフトウェアエンジニア)は、ループに必要な要素として以下を挙げています。
- Automations: 定期的に調査・トリアージする
- Worktrees: 複数エージェントの作業場所を分ける
- Skills: プロジェクト知識を再利用可能にする
- Plugins / Connectors: GitHub、Slack、DBなど外部ツールにつなぐ
- Subagents: 実装するAIと確認するAIを分ける
- Memory: 会話の外に状態を残す
これはClaude Codeの機能群ともかなり対応しています。
| 目的 | Claude Codeでの手段 |
|---|---|
| プロジェクト知識を覚えさせる |
CLAUDE.md, Skills |
| 外部ツールにつなぐ | MCP, Connectors |
| 同じ処理を毎回実行する | Hooks |
| 複数の観点で調査する | Subagents |
| 複数タスクを並列化する | Worktrees, multiple sessions |
| 完了条件まで回す | /goal |
| 定期実行する |
/loop, scheduled tasks, Routines |
| 深いレビューをする |
/code-review, /code-review ultra
|
ここまで来ると、Claude Code活用は「プロンプト術」ではなく、開発システム設計に近づいていきます。
ただし、AIに任せるほど人間の責任は重くなる
Claude Codeを深く使うほど、実装速度は上がります。
ただ、速度が上がるほど危険も増えます。
- 理解していないコードが増える
- 仕様の微妙なズレに気づきにくい
- 「テストが通ったからOK」と思い込みやすい
- AIの提案をレビューせず受け入れやすい
- 権限や認証情報の扱いが危険になる
海外の実践者も、AIが書いたコードは必ずレビューし、テストし、必要なら別モデルや別セッションで批判的に見ることを勧めています。
Claude Codeを使う時代のエンジニアの価値は、
「自分で全部コードを書くこと」から、
何を作るべきかを決め、AIに正しく調査・実装・検証させ、出てきたものを責任を持って判断することに移っていきます。
つまり、Claude Codeが進化するほど、人間の仕事は消えるというより、
実装者から設計者・レビュアー・オーケストレーターに寄っていくのだと思います。
まとめ
Claude Codeをちゃんと使うとは、単にコードを書かせることではないと思います。
- 実装前にExploreさせる
- Planを人間がレビューする
- 小さく実装させる
- テスト・lint・buildで検証させる
- PRまでレビュー可能な形にまとめる
-
CLAUDE.md/ Skills / Hooks / MCP / Subagents / Worktrees で再現可能なループを作る
この流れを作れて初めて、Claude Codeは「便利なコード生成AI」から「開発プロセスを変えるエージェント」に近づいていくのだと思います。
皆さんもClaudeCodeをうまく使って楽しい開発体験を！