Claude Code

Claude Code（Claude CLI）によるプロジェクトの進め方

Claude Code（Claude CLI）を「便利な補完ツール」で終わらせず、プロジェクトの推進力にするには、計画・実装・検証を回すワークフローの設計が欠かせません。本記事では、公式ドキュメントと実践者のブログ調査から、再現性の高い進め方を整理します。

本記事は、英語圏の公式ドキュメント・技術ブログを当社が調査し、要点を日本語でまとめたものです。各手法の出典は記事末尾の「参考元記事」に記載しています。詳細は必ず元記事をご確認ください。

基本フロー：Explore → Plan → Code → Commit

Anthropic 公式が推奨する中核は、「探索 → 計画 → 実装 → コミット」の4フェーズループです（元記事1）。

  1. Explore（探索）：プランモードで関連ファイルを読み、変更せずに理解する。
  2. Plan（計画）：詳細な実装計画を作らせ、人間がレビュー・修正する。
  3. Code（実装）：プランモードを抜けて計画どおり実装し、検証する。
  4. Commit（コミット）：変更をコミットし、プルリクエストを作成する。

公式は同時に「一文で説明できる差分なら計画は省く」とも述べており、計画の重さはタスクの複雑さに合わせるのが要点です。プランモードは Shift+Tab で切り替えられ、claude --permission-mode plan で起動時から指定もできます（元記事2）。

計画は「成果物（ドキュメント）」として残す

実践者の多くは、計画をその場のチャットで終わらせずファイルとして残す手法を取っています。Harper Reed 氏は、強力な推論モデルで spec.md（仕様）と prompt_plan.md（手順）を生成し、各タスクの完了状況を追跡しながら進めます。氏は「ロボットは TDD が大好きだ。本当に好む」と述べ、テストとモックを先に作ってから実装することでスコープのずれを防いでいます（元記事3）。

Les Orchard 氏も、短い spec.md から AI に plan.md を生成させ、「計画を反復する：編集し、AI に批評させ、質問に答え、繰り返す」と表現します。計画が固まったら、計画と既存コードだけを持って新しいセッションで実装に入り、コンテキストの肥大化を避けます（元記事4）。

ポイント： DataCamp の解説では、Claude に plan.md を書かせた上で「すべての指摘に対応せよ。ただしまだ実装するな」というガード文を添えて計画だけを練り上げる手法が紹介されています。「間違った差分を解きほぐすより、計画を承認するほうがずっと安い」のです（元記事5・6）。

CLAUDE.md をプロジェクトの記憶にする

プロジェクト固有のルールは CLAUDE.md に集約します。共通する助言は「とにかく短く保つ」こと。複数の情報源が約60行程度を目安に挙げ、肥大化したファイルは「実際の指示を無視させる原因になる」と警告しています。

検証ループ（多くは TDD）を閉じる

最も普遍的な技法が、Claude が自分で回せる合否判定を与えることです。なかでも TDD（テストを先に書き、失敗を確認し、コミットし、緑になるまで実装）は「セッションが長くなっても狂わない外部の判定基準（external oracle）」として繰り返し推奨されています。「動いた」ではなく「テスト出力を見せて」と証拠を求める姿勢も重要です（元記事5・6）。

並列化とチェックポイント

規模が大きくなったら、git worktree による隔離セッションで複数タスクを並行させます（claude --worktree feature-auth）。ヘッドレスモード claude -p は CI や大量ファイルの一括変換に有効です。ただし実践者は「並列数はツールの上限ではなく、自分のレビュー能力で決める（2〜3が目安）」と口を揃えます（元記事2・6）。

あわせて、小さく頻繁なコミットを「セーブポイント」として使い、うまくいかなければ巻き戻す運用が推奨されています（元記事4）。フォーマットやテストを確実に走らせたい処理は、助言的な CLAUDE.md ではなく決定論的に発火する Hook（PostToolUse など）で担保します（元記事6）。

当社の視点： ハシトシステムでは、AI を前提とした開発でも「計画をドキュメント化し人がレビューする」「検証を自動化する」という従来のプロジェクトマネジメントの原則は変わらないと考えています。Claude Code はその原則を高速に回すためのエンジンであり、計画と検証の設計こそが品質を決めます。

参考元記事

  1. Anthropic「Best practices for Claude Code」(公式ドキュメント) — https://code.claude.com/docs/en/best-practices
  2. Anthropic「Common workflows」(公式ドキュメント) — https://code.claude.com/docs/en/common-workflows
  3. Harper Reed「Basic Claude Code」(2025年5月8日) — https://harper.blog/2025/05/08/basic-claude-code/
  4. Les Orchard「Baby steps into semi-automatic coding」(2025年6月7日) — https://blog.lmorchard.com/2025/06/07/semi-automatic-coding/
  5. Bex Tuychiev / DataCamp「Claude Code Best Practices: Planning, Context Transfer, TDD」(2026年3月9日) — https://www.datacamp.com/tutorial/claude-code-best-practices
  6. Galian / DEV Community「Claude Code Workflow: Best Practices That Ship Code」(2026年6月8日) — https://dev.to/galian/claude-code-workflow-best-practices-that-ship-code-na

よくある質問（FAQ）

Claude Code の基本的なプロジェクトの進め方は？

Anthropic 公式が推奨する中核は「探索（Explore）→ 計画（Plan）→ 実装（Code）→ コミット（Commit）」の4フェーズループです。プランモードで関連ファイルを変更せずに読み込んで理解し、実装計画を作って人間がレビュー・修正し、計画どおり実装して検証し、最後にコミットしてプルリクエストを作成します。一文で説明できる差分なら計画は省くなど、計画の重さはタスクの複雑さに合わせます。

計画はチャットで進めればよいですか、それともファイルに残すべきですか？

実践者の多くは計画をチャットで終わらせず、spec.md（仕様）や plan.md / prompt_plan.md（手順）としてファイルに残しています。計画を編集し、AI に批評させ、質問に答えて反復したうえで、計画と既存コードだけを持って新しいセッションで実装に入ると、コンテキストの肥大化を避けられます。間違った差分を解きほぐすより、計画を承認するほうがずっと安いという考え方です。

CLAUDE.md はどのように書けばよいですか？

プロジェクト固有のルールを CLAUDE.md に集約し、とにかく短く保つことが重要です。複数の情報源が約60行程度を目安に挙げ、肥大化したファイルは実際の指示を無視させる原因になると警告しています。/init でたたき台を生成して git にコミットしチームで育て、各行に「これを消したら Claude がミスするか」という基準を当て、詳細はリンクや @path インポートで参照します。

← 技術ブログ一覧へ戻る