計画から運用まで、各フェーズで Claude Code をどう使うかの考え方と判断軸
大きめの機能開発では、最初に Claude へ大まかなアイデアを伝え、詳細を聞き出してもらう。
[ユーザー認証機能を追加したい] と伝えた後: I want to build [brief description]. Interview me in detail using the AskUserQuestion tool. Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.
インタビューが終わったら 新しいセッションを開始 して実装に移る。実装セッションのコンテキストが要件定義の会話で汚染されない。
既存プロジェクトに参加した直後は、Claude Code をシニアエンジニアへの質問相手として使う。
give me an overview of this codebase
アーキテクチャ・パターン・データモデルを質問する
look through ExecutionFactory's git history and summarize how its api came to be
「なぜこうなっているか」を git 履歴から読み解く
claude /init
プロジェクト構造を解析して CLAUDE.md のたたき台を自動生成
claude --permission-mode plan または セッション中に Shift+TabCtrl+G でプランをテキストエディタで直接編集できる。プロジェクト固有の設計判断（使用ライブラリ・パターン・禁止事項）は CLAUDE.md に書いておく。毎セッションで Claude が読み込むため、「毎回同じことを説明する」手間がなくなる。
# CLAUDE.md の例 # Code style - Use ES modules (import/export), not CommonJS (require) - Prefer functional components over class components # Architecture - API calls go through src/api/ — never fetch() directly in components - State management: Zustand only (no Redux)
大きなコードベースの調査は サブエージェント に委ねる。調査の全ファイル読み込みが自分のコンテキストを消費しなくなる。
Use a subagent to investigate how our auth system handles token refresh, and whether we have any existing OAuth utilities.公式: Explore first, then plan, then code
| 戦略 | 曖昧な指示（Bad） | 具体的な指示（Good） |
|---|---|---|
| スコープを絞る | "add tests for foo.py" |
"write a test for foo.py covering the case where the user is logged out. avoid mocks." |
| 既存パターンを参照 | "add a calendar widget" |
"look at HotDogWidget.php for the pattern, then implement a calendar widget following it" |
| 症状と場所を伝える | "fix the login bug" |
"users report login fails after session timeout. check src/auth/, write a failing test, then fix it" |
Explain the logic in @src/utils/auth.js What's the structure of @src/components?
「フィーチャーAを開発しながら、別のセッションでバグ修正」をファイルの衝突なしにできる。
claude --worktree feature-auth # ターミナル1 claude --worktree fix-payment-bug # ターミナル2（別ブランチ・別チェックアウト）
スコープが明確なタスクでは --permission-mode auto を使う。分類器がコマンドを評価し、危険なものだけをブロックする。
claude --permission-mode auto -p "fix all lint errors"
チームや個人で何度も使う手順は .claude/skills/ にスキルとして定義する。
# .claude/skills/fix-issue/SKILL.md --- name: fix-issue description: Fix a GitHub issue end-to-end disable-model-invocation: true --- 1. Use `gh issue view` to get details 2. Search relevant files 3. Implement fix with tests 4. Create a PR
/clear でリセット/clear して新しいプロンプトで再スタート/rewind（または ESC × 2）で前のチェックポイントに戻れる/btw で聞く（回答がコンテキストに残らない）| 検証の種類 | プロンプト例 |
|---|---|
| テストスイート | "write tests for the auth module, run them, and fix any failures" |
| ビルド終了コード | "the build fails with [error]. fix it and verify the build succeeds. fix the root cause, don't suppress the error" |
| UI のスクリーンショット比較 | "[デザイン画像を貼る] implement this design. take a screenshot and compare it to the original. fix differences." |
| スクリプトで fixture と diff | 出力を fixture と比較するスクリプトを渡す |
実装前にテストを書かせ、別のセッションで実装させる手法も有効。
# セッション A: テストを書く "find functions in NotificationsService.swift that are not covered by tests, then add tests for edge cases" # セッション B: テストを通す実装を書く （新しいセッションで @テストファイルを渡す）
2つのセッションで役割を分担する。
| セッション A（Writer） | セッション B（Reviewer） |
|---|---|
"Implement a rate limiter for our API endpoints" |
（実装後） |
| — | "Review @src/middleware/rateLimiter.ts. Look for edge cases, race conditions, and consistency with existing patterns." |
"Here's the review: [Session B output]. Address these issues." |
— |
Claude Code 組み込みの /code-review コマンドは、現在の diff に対してサブエージェントが独立してバグチェックを行い、結果をセッションに返す。
/code-review # 現在の diff をレビュー /code-review ultra # マルチエージェントクラウドレビュー（深い）
PR が開かれたときに自動でコードレビューするには GitHub Actions 統合を使う。
git diff main --name-only | claude -p \ "review these changed files for security issues"
レビュアーに「ギャップを探せ」と指示すると問題がなくても何か報告する。正確さや要件に影響するものだけを報告させる。
Use a subagent to review the rate limiter diff against PLAN.md. Check that every requirement is implemented, listed edge cases have tests, and nothing outside scope changed. Report gaps that affect correctness, not style preferences.公式: Add an adversarial review step
claude -p は Unix コマンドとして他のツールと連携できる。
claude "commit my changes with a descriptive message" claude "create a pr"
PR 作成後は claude --from-pr <number> でそのセッションに戻れる。
claude -p で Claude をスクリプトやパイプラインに組み込める。
# ログ異常の検知 tail -200 app.log | claude -p "Slack me if you see any anomalies" # CI での翻訳 claude -p "translate new strings into French and raise a PR" # セキュリティチェック git diff main --name-only | claude -p "review for security issues" # JSON 出力（パーサー向け） claude -p "List all API endpoints" --output-format json
| 方法 | 実行場所 | 向いている用途 |
|---|---|---|
| Routines | Anthropic クラウド | PC がオフでも動かしたいタスク（毎朝 PR レビュー・週次依存関係チェック等） |
| Desktop scheduled tasks | 自分のマシン | ローカルファイルや未コミット変更へのアクセスが必要なタスク |
| GitHub Actions | CI パイプライン | PR オープン・push などリポジトリイベントに連動するタスク |
| /loop | 現在の CLI セッション | セッション中の短期ポーリング |
claude --teleport して引き継ぐ@Claude にバグレポートをメンションすると PR が返ってくる公式ドキュメントが明示的にまとめている「避けるべきパターン」。
| パターン名 | 何が起きるか | 対策 |
|---|---|---|
| キッチンシンクセッション | 1つのタスクをしながら関係ない質問を混ぜる → コンテキストが無関係な情報で汚染される | 関係ないタスクへの切り替えは /clear でリセット |
| 繰り返し修正ループ | 同じ間違いを 2 回以上修正 → コンテキストが失敗した試みで汚染 | 2 回失敗したら /clear → 学んだことを含めたより具体的なプロンプトで再スタート |
| 肥大化した CLAUDE.md | CLAUDE.md が長すぎて重要な指示が無視される | 「これがないと Claude が間違えるか？」→ NO なら削除。フック化できるものはフックに移す |
| 信頼して検証しないギャップ | もっともらしい実装がエッジケースを処理していない | 常に検証手段（テスト・スクリプト・スクリーンショット）を渡す |
| 無限探索 | 「調査して」とだけ指示して数百ファイルを読まれる → メインのコンテキストが枯渇 | 調査は範囲を絞るか、サブエージェントに委ねる |
| フェーズ | Claude Code の使い方 | 核心の判断基準 |
|---|---|---|
| 計画・要件定義 | インタビュアー / 質問相手 | SPEC.md ができるまでコードを書かせない |
| 設計 | Plan mode で探索・プラン生成 | 差分を 1 文で説明できないなら Plan mode を使う |
| 実装 | 具体的なコンテキストを与えて実装 | コンテキストが汚れたら /clear、2 回失敗したら再スタート |
| テスト | 検証手段を渡して自律ループ | 「言葉で成功を報告」ではなくエビデンスを出させる |
| レビュー | 別セッション・サブエージェントでレビュー | 実装したエージェントにレビューさせない |
| デプロイ・運用 | 非インタラクティブ・スケジュール実行 | 自律タスクは「成功とは何か」「結果をどこへ」を明示 |