Claude Code 実践ワークフロー完全ガイド|タスクの渡し方・コンテキスト管理・アンチパターン対策

Claude Code 実践ワークフロー完全ガイド|タスクの渡し方・コンテキスト管理・アンチパターン対策 AI開発

Claude Codeを導入してみたものの「思ったより使いこなせていない」「同じようなことを何度も修正させている」「セッションが長くなると動作が遅くなる」——こうした経験をお持ちの方は多いのではないでしょうか。Claude Codeは使い方のコツを知るだけで生産性が大きく変わるツールです。

この記事では、Anthropicの公式ベストプラクティスドキュメントをもとに効果的なプロンプトの書き方・典型的な開発フロー・コンテキスト管理・よくあるアンチパターンを解説します。Claude Code全般の概要はClaude Code完全ガイドを参照してください。

スポンサーリンク

効果的なタスクの渡し方

具体的なコンテキストが品質を決める

Claude Codeへの指示は「曖昧な一言」より「具体的な説明」の方が圧倒的に良い結果を生みます。ファイルパス・制約・テスト方法・期待する出力を明記することで、修正回数が減り、最初から意図通りの実装が得られます。

種別
❌ 曖昧な指示 fix the login bug
✅ 具体的な指示 users report login fails after session timeout. check src/auth/, especially token refresh. write a failing test first, then fix it
種別
❌ 曖昧な指示 add tests for foo.py
✅ 具体的な指示 write tests for foo.py covering the edge case where the user is logged out. avoid mocks.

プロンプトに含めると効果的な情報

  • ファイルパスsrc/auth/token.ts@path/to/fileで内容を自動読み込み
  • 関連する既存実装の参照"look at how HotDogWidget.php is implemented"
  • テストケース:具体的な入出力例で検証基準を示す
  • 制約・禁止事項"avoid mocks""keep backward compatibility"
  • 期待するアウトプット:スクリーンショット・ログ・JSONの構造など

短いプロンプト vs 長いプロンプト

すべてのタスクに長い説明が必要なわけではありません。タスクのスコープと複雑さで使い分けましょう。

状況 推奨アプローチ
スコープが明確・単純な変更(タイポ修正・ログ追加・変数名変更など) 1文の短いプロンプトで直接指示
スコープが不明確・複数ファイルの変更が必要 計画フェーズを先に実施(後述)
不慣れなコードベースを修正する 探索フェーズから始める(後述)
外部ドキュメント・APIを参照する必要がある URLやファイルパスをプロンプトに添付
検証基準の提供が最重要
Claude Codeが自分で仕事を確認できる基準を常に提供してください。テストケース・スクリーンショット・期待する出力があると、Claude Codeが自動的にフィードバックループを回せるようになります。例:"implement validateEmail. Test: 'user@example.com' → true, 'invalid' → false. run tests after."

典型的な開発フロー:探索→計画→実装→検証

公式ドキュメントが推奨する開発フローは以下の4段階です。特に大きな変更・複数ファイルの修正・不慣れなコードベースへの変更ではこのフローを徹底してください。

フェーズ モード 何をするか 実例
① 探索 Plan Mode ファイルを読み込み、コードを理解する(変更なし) "read src/auth/ and understand how sessions work"
② 計画 Plan Mode 変更が必要なファイル・実装方針を決める "what files need to change? create a step-by-step plan"
③ 実装 Normal Mode 計画に従ってコードを書き、テストを実行する "implement the OAuth flow from your plan. write tests and fix failures"
④ コミット Normal Mode レビュー・PR作成 "commit with a descriptive message and open a PR"

Plan Modeへの切り替え方

Plan Modeではファイルの読み込み・分析のみ行い、コードの変更は一切行いません。計画をレビューしてから実装を承認できるため、大きなミスを防げます。Plan Mode完全ガイドも参照してください。

Plan Modeの切り替え方
# Shift+Tab を2回押す(ターミナル上)
# → Normal → Auto-Accept → Plan Mode の順に切り替わる

# 計画をエディタで編集したい場合
# Ctrl+G でプランを外部エディタで開く

新機能開発の実践例

新機能開発フロー(Googleログイン追加)
# --- Plan Mode(探索・計画) ---

あなた: "read src/auth/ and understand how we handle authentication"
Claude: [ファイルを読み込んで現状を説明]

あなた: "I want to add Google OAuth login. What files need to change?
         What's the implementation flow? Create a detailed plan."
Claude: [変更ファイル一覧・手順・懸念点を計画として提示]

# --- Normal Mode(実装) ---
# → Shift+Tab でモード切り替え

あなた: "implement the Google OAuth flow from your plan.
         write unit tests for the callback handler.
         run the test suite and fix any failures."
Claude: [実装・テスト実行・修正]

あなた: "commit with a descriptive message and create a draft PR"
Claude: [コミット・PR作成]

バグ修正の実践例

バグ修正フロー
あなた: "I'm seeing this error when I run npm test:
         TypeError: Cannot read property 'id' of null
         at /src/user.ts:45
         [エラー全文をペースト]"

Claude: [エラーの原因を分析]

あなた: "suggest a few ways to fix the null check in user.ts"
Claude: [修正案を3種類提示・推奨案を説明]

あなた: "implement option 2. write a test that reproduces the bug first,
         then fix it, then run all tests"
Claude: [テスト追加→修正→テスト実行]

コンテキスト管理の戦略

Claude Codeのコンテキストウィンドウは最重要なリソースです。コンテキストが満杯になると動作が遅くなり、重要な指示を忘れやすくなります。以下の戦略でコンテキストを効率よく使いましょう。

/compact:コンテキストを圧縮する

/compactは古いツール出力・中間の試行錯誤をまとめて圧縮します。会話の流れとコードは保持されますが、詳細な中間ステップは削除されます。

/compact の使い方
# 基本(自動でコンテキスト全体を圧縮)
/compact

# フォーカス指定(特定の内容に絞って圧縮)
/compact Focus on the authentication changes only
/compact Keep only the final implementation, discard debug attempts

/clear:コンテキストをリセットする

/clearはコンテキストを完全にクリアします。無関係な別タスクに切り替えるときに使います。重要な指示・ルールはCLAUDE.mdに書いておけば、クリア後も自動で読み込まれます。

新セッションで始めるべきタイミング

状況 推奨アクション
無関係なタスクに切り替える(認証→UIデザイン変更など) /clearでコンテキストをリセット
同じ問題で2回以上修正が空振りした /clearしてプロンプトを改善して再試行
調査タスクでコンテキストが膨らんでいる Subagentsに委譲(独立したコンテキストで実行)
長期作業の翌日の再開 claude --resume セッション名で再開

セッションに名前をつけて管理する

セッション命名と再開
# 起動時に名前をつける
claude -n "auth-refactor"

# セッション中に名前をつける
/rename auth-refactor

# 後で再開する
claude --resume auth-refactor

# セッション一覧から選んで再開
claude --resume
# または /resume コマンド

よくあるアンチパターン6種と対策

公式ドキュメントに記載されているアンチパターンです。これらは生産性を大きく下げる原因となります。

アンチパターン 原因 対策
①キッチンシンク会話 1つのタスクが終わると別タスク→また別→と切り替え続けてコンテキストが雑然とする 無関係タスクの間で/clearを実行
②同じ失敗を繰り返す 失敗したアプローチの試行錯誤でコンテキストが満杯になり、新しい解法を見つけられない 2回失敗したら/clearしてプロンプトを根本から書き直す
③CLAUDE.mdが長すぎる 詳細なルールを書きすぎて重要な指示がノイズに埋まる 「この行を削除してもClaudeが失敗するか?」で判定。200行以下を目標に
④検証基準なしで実装させる 実装はできたが動作確認できず、後になってバグが発覚 必ずテストケース・期待出力を指示に含める。"run tests after"を口癖に
⑤無制限の探索 「調査して」と漠然と指示→100ファイル読み込み→コンテキストが満杯で何もできなくなる 探索スコープを狭める("read only src/auth/")かSubagentsに委譲
⑥確認なしで大きな変更 複数ファイルの変更を一気にさせて後戻りができなくなる 大きな変更はPlan Modeで計画確認→Normal Modeで実装の順で進める

CLAUDE.mdの効果的な書き方

CLAUDE.mdはClaude Codeへの「常駐指示書」です。何を書くかと同じくらい何を書かないかが重要です。詳細な設計ガイドはCLAUDE.md完全設計ガイドを参照してください。

書くべき内容・書かないべき内容

✅ 書くべき内容 ❌ 書かないべき内容
Bashコマンド(npm run devnpm testなど) 標準的なコーディング規約(Claudeは既に知っている)
デフォルトと異なるコード規約 詳細なAPIドキュメント(URLでリンクすればよい)
アーキテクチャ上の重要な決定事項 頻繁に変わる情報(コミットすべきではない)
プロジェクト固有のテスト・ビルド手順 長い説明・チュートリアル(ファイルにインポートで対応)
開発環境の特殊な設定 自明な実践(「きれいなコードを書いて」など)

具体性のあるルールを書く

❌ 曖昧なルール ✅ 具体的なルール
“コードをきれいにフォーマットする” “インデントはスペース2つ、セミコロンなし、ESモジュール使用”
“テストを確認する” “コミット前に必ずnpm testを実行する”
“APIの設計に従う” @docs/api-design.mdのエンドポイントパターンを参照”

@importで長い情報を分離する

CLAUDE.mdが長くなってきたら@ファイルパスで外部ファイルをインポートして分割できます。必要な時だけ読み込まれるため、コンテキストの節約にもなります。

CLAUDE.md(@importを使った分割例)
# プロジェクト名

## 概要
〇〇システムのバックエンドAPI。詳細は @README.md を参照。

## よく使うコマンド
開発: `npm run dev`
テスト: `npm test`
利用可能なコマンド全体は @package.json を確認。

## コード規約
@docs/coding-standards.md を参照。

## Git ワークフロー
@docs/git-instructions.md を参照。

チーム開発での活用

settings.jsonのチーム共有

チームで共通のClaude Code設定を使うには、.claude/settings.jsonをGitでコミットします。個人設定は.claude/settings.local.jsonに書いて.gitignoreに追加します。

ファイル Gitへの扱い 用途
.claude/settings.json コミットする チーム全員が使う共通設定(権限・MCP・フック等)
.claude/settings.local.json .gitignoreに追加 個人の上書き設定(マシン固有の設定等)
.claude/CLAUDE.md コミットする チームへの共通指示・プロジェクトルール

モノレポでのCLAUDE.md設計

モノレポ(複数パッケージが1リポジトリ)では、ルートと各サブディレクトリに分けてCLAUDE.mdを配置できます。Claude Codeは作業中のディレクトリに応じて自動的に適切なCLAUDE.mdを読み込みます。

モノレポのCLAUDE.md配置例
./CLAUDE.md               # グローバル共通(リポジトリ全体のルール)
./backend/CLAUDE.md       # バックエンド固有(API設計・DB接続等)
./frontend/CLAUDE.md      # フロントエンド固有(コンポーネント規約・状態管理等)
./mobile/CLAUDE.md        # モバイル固有

Worktreeで並列タスクをこなす

複数の機能開発やバグ修正を同時に進めたい場合は、Worktreeを使って並列でClaude Codeセッションを実行できます。Worktree完全ガイドも参照してください。

並列タスクの実行
# 別々のターミナルで実行
# ターミナル1
claude --worktree feature-oauth    # feature-oauthブランチで作業

# ターミナル2
claude --worktree bugfix-timeout   # bugfix-timeoutブランチで作業

# 作業が完了したらメインブランチにマージ

環境への投資で長期的な効率を上げる

最初に少し時間をかけて環境を整えると、その後の毎回の作業が大幅に効率化されます。

投資内容 効果
CLAUDE.mdの整備 毎回同じ説明をしなくてよくなる。チームで一貫性が保てる
カスタムスキルの作成 定型タスク(コードレビュー・テスト生成等)をコマンド1つで実行
settings.jsonの権限設定 許可確認の画面が減り、作業がスムーズになる
MCPサーバーの設定 GitHub・Slack・DBを直接操作できるようになる
フック(Hooks)の設定 定型チェック(lint・フォーマット)を自動化
Subagentsで大きなタスクを分割する
1つのタスクが大きすぎてコンテキストが不安な場合は、Subagentsに委譲することで独立したコンテキストで並列実行できます。例:「全テストファイルを調査するサブエージェント」を立ち上げて、結果だけをメインセッションに返す方式です。Subagents完全ガイドを参照してください。

よくある質問

QClaude Codeが同じミスを繰り返します。どうすればいいですか?

A2回同じ失敗をしたら、/clearでコンテキストをリセットしてください。失敗した試行がコンテキストに残っていると、同じ方向で考え続けることがあります。リセット後は問題を別の角度から説明して再試行してください。また、再発を防ぐためにCLAUDE.mdに「〇〇はしないこと」として記録しておくと効果的です。

QCLAUDE.mdはどのくらいの長さが適切ですか?

A200行以下を目標にしてください。各行に対して「この行を削除してもClaude Codeが失敗するか?」と問いかけ、「No」ならば削除します。長くなる場合は@ファイルパスで外部ファイルに分割するか、.claude/rules/にpath-specificルールとして切り出してください。

Q/compactと/clearの使い分けが分かりません。

A/compactは会話の流れを保ちながら古いデータを圧縮します。同じタスクを続けているが、コンテキストが多くなってきた場合に使います。/clearはコンテキストを完全にリセットします。全く別のタスクに切り替えるときや、失敗したアプローチを一旦白紙に戻すときに使います。

QClaude Codeに大きな変更を一気にさせても大丈夫ですか?

APlan Modeで計画を先に確認することを強く推奨します。計画段階で「ここはこうしてほしい」と方針を調整できるため、実装後に大幅な手戻りが発生するリスクを減らせます。また、Gitで小さなコミットに分けておくと、問題が起きた場合にgit revertで元に戻しやすくなります。

QチームメンバーによってClaude Codeの使い方にバラツキがあります。

A.claude/settings.json.claude/CLAUDE.mdをGitにコミットして共有してください。また、よく使う操作をカスタムスキル(.claude/skills/)に定義しておくと、チーム全員が同じスラッシュコマンドで同じ品質の作業ができます。企業環境ではManaged settingsでポリシーを強制することも可能です。