# How I Use Claude Code [How I Use Claude Code | Boris Tane](https://boristane.com/blog/how-i-use-claude-code/) ![[Pasted image 20260310094339.png]] ## 概要 Claude Codeを使いこなすための、計画と実装を厳密に分離するワークフローである。 AIにコードを書かせる前に、必ず計画書を作成させ、人間のレビューと承認を経ることを原則とする。 このプロセスにより、無駄なトークン消費を防ぎ、アーキテクチャの制御を維持できる。 ## ワークフローの各フェーズ ### 1. リサーチ (Research) - 実装前にコードベースを深く理解させるためのフェーズである。 - 「深く」「詳細に」といった明示的な指示（Directive）を与え、表面的な理解を防ぐ。 - 調査結果は必ず `research.md` という永続的なMarkdownファイルに書き出させる。 - 人間は `research.md` をレビューし、キャッシュ層の無視やORM規約の違反などの誤解があれば、計画段階に入る前に修正する。 ### 2. 計画 (Planning) - リサーチ内容が承認された後、実装計画を `plan.md` に作成させる。 - Claude Code内蔵の計画モードではなく、独自に作成した `.md` ファイルを使用する。これによりエディタとの統合と永続性を確保する。 - 計画には、アプローチ、変更するファイルパス、コードスニペット、およびトレードオフを含める。 ### 3. アノテーションサイクル (The Annotation Cycle) - 計画書 (`plan.md`) を開発者とAI間の「共有されたミュータブルな状態 (shared mutable state)」として扱う。 - エディタ上で `plan.md` を開き、インラインで直接メモや修正（アノテーション）を追記する。 - Claudeにアノテーションを反映させる指示を出す。このサイクルを通常1〜6回繰り返す。 - **「まだ実装しないこと (don't implement yet)」** という制約（ガードレール）を必ず付与し、先走りを防ぐ。 - 最後に、計画書内に詳細なタスクとフェーズからなるToDoリストを追記させる。 ### 4. 実装 (Implementation) - 全ての意思決定が計画段階で完了しているため、実装は機械的な作業として扱う。 - 標準的な実装用[[Prompt Engineering|プロンプト]]の例： - 「すべて実装せよ。タスクが終わったら `plan.md` のToDoに完了マークをつけること。全て終わるまで止まらないこと。」 - 「不要なコメントやJSDocを追加しないこと。`any` や未知の型を使わないこと。」 - 「継続的に型チェック (typecheck) を実行し、新たな問題が発生していないか確認すること。」 - これにより、型安全性を確保しつつ、中断のない連続的なコーディングを実現する。 ## 実装中のフィードバックと軌道修正 - 実装が始まったら、開発者は「監督者 (supervisor)」の役割に移行する。 - 短く簡潔な指示（例：「`deduplicateByTitle` 関数が実装されていない」）で軌道修正を行う。 - フロントエンド開発では、視覚的なフィードバック（「もっと広く」「まだ見切れている」）を連続して与え、必要に応じてスクリーンショットを添付する。 - AIの修正が複雑になりすぎたり脱線した場合は、パッチを当てるのではなくGitで変更をリバートし、スコープを再設定する。 ## 重要なプラクティス - **スコープの削減:** スコープクリープを防ぐため、計画段階で「あったら良い機能 (nice-to-haves)」を積極的に削ぎ落とす。 - **インターフェースの保護:** 関数のシグネチャや公開APIに対しては厳格な制約を設ける。 - **単一の長いセッション:** リサーチ、計画、実装を一連の長い対話セッションで完結させる。Claudeのコンテキスト自動圧縮機能により、セッションが長引いても `plan.md` のような重要なアンカーは保持され、[[LLM]]はタスクに対する深いメンタルモデルを構築できる。