目次
- 初心者から「使える人」へ — この記事で身につくこと
- Explore → Plan → Code → Commit ワークフロー
- プランモードを使いこなす
- モデルの使い分け戦略
- コンテキスト管理の実践テクニック
- プロンプトの書き方 — 結果が10倍変わるコツ
- Git連携ワークフロー
- バグ修正の実践フロー
- コスト最適化 — 賢く使う7つのテクニック
- セッション管理で作業を中断・再開
- まとめ
1. 初心者から「使える人」へ — この記事で身につくこと
Claude Codeをインストールして基本的な操作はできるようになった。でも「使いこなしている」と言えるだろうか?
初心者と中級者の差は、ツールの知識量ではありません。ワークフロー(作業の進め方)の違いです。同じClaude Codeを使っていても、進め方次第で成果物の品質もスピードもまったく変わります。
この記事では、Claude Codeの公式ベストプラクティスと実務で効果が実証されたテクニックを体系的にまとめました。以下のスキルが身につきます。
- 公式推奨の4ステップ開発ワークフローを自然に回せるようになる
- プランモードで大きな変更も安全に進められる
- モデルの使い分けでコストと品質を両立できる
- コンテキスト管理で長時間セッションでも品質を維持できる
- 結果が劇的に変わるプロンプトの書き方を習得できる
前提:この記事はClaude Codeのインストール・基本コマンドを理解していることを前提としています。まだの方はClaude Code 初心者完全ガイドを先にお読みください。
2. Explore → Plan → Code → Commit ワークフロー
Anthropicの公式ベストプラクティスが推奨する開発ワークフローは、4つのフェーズで構成されています。これはClaude Codeの作者であるBoris Cherny氏をはじめ、Anthropic社内チームが実際に使っている手法です。
Step 1:Explore(探索)
いきなりコードを書かせない。まずClaude Codeにコードベースを読ませて、現状を理解させます。
関連するファイルを読んで、現在の認証フローの実装を理解してください。
コードは書かないでください。
「コードは書かないでください」と明示するのがポイントです。この指示がないと、Claude Codeは親切心からすぐにコードを生成しようとします。
Step 2:Plan(計画)
探索結果を踏まえて、変更計画を立案させます。
この認証フローにJWTリフレッシュトークンの仕組みを追加したい。
実装計画を提案してください。コードはまだ書かないでください。
変更するファイル、追加するファイル、変更の順序を示してください。
計画の質が最終的な成果物の品質を決めます。複雑な変更ほど、このフェーズに時間をかけるべきです。
Step 3:Code(実装)
計画に納得したら、実装を許可します。
この計画で進めてください。Step 1のデータモデルの変更から始めてください。
大きな変更の場合は、計画のステップを1つずつ実行させるのが安全です。一度にすべて任せるのではなく、小さな単位で進めてフィードバックしましょう。
Step 4:Commit(記録)
この変更をコミットしてください。
Claude Codeはgit diffを分析し、変更内容に適したコミットメッセージを自動生成します。
なぜこの順序が重要なのか:「いきなりコードを書かせる」と、Claude Codeは限られた理解のまま実装を始め、手戻りが発生しやすくなります。Explore → Plan を挟むことで、Claude Codeがプロジェクト全体を理解した状態で実装に入れるため、一発で正しいコードが出る確率が大幅に上がります。
3. プランモードを使いこなす
プランモードはStep 2(計画)をシステムレベルで強制する機能です。プランモード中、Claude Codeはファイルの読み取りと分析はできますが、ファイルの編集やコマンドの実行は一切できません。
プランモードの起動方法
| 方法 | 操作 | 用途 |
|---|---|---|
| キーボード | Shift+Tab を2回押す |
セッション中の切り替え(最も一般的) |
| コマンド | /plan |
セッション中に直接プランモードへ |
| 起動オプション | claude --permission-mode plan |
最初からプランモードで開始 |
| 設定ファイル | settings.jsonのdefaultMode: "plan" |
常にプランモードで起動 |
Shift+Tabを押すと、パーミッションモードが以下の順で切り替わります。
通常モード → Auto-Accept Mode(⏵⏵ accept edits on) → Plan Mode(⏸ plan mode on)
つまり通常モードからはShift+Tabを2回押すとPlan Modeに入ります。もう1回押すと通常モードに戻ります。
プランモードの効果的な使い方
大きな変更の前に必ず使う。具体的には以下のケースです。
- 複数ファイルにまたがる変更
- アーキテクチャに影響する変更
- 既存の動作を壊す可能性がある変更
- 初めて触るコードベースでの作業
逆に、1ファイルの小さな修正やタイポ修正にプランモードは不要です。
思考深度をコントロールする
プロンプトに特定のキーワードを含めることで、Claude Codeの思考深度(使用するトークン量)を調整できます。
| キーワード | 思考トークン(目安) | 使いどころ |
|---|---|---|
think |
約4,000 | 通常の判断 |
think hard |
約10,000 | 複雑なロジック |
megathink |
約16,000 | 大規模な設計判断 |
ultrathink |
約32,000 | 最も深い分析が必要なとき |
ultrathink。このマイクロサービスの認証アーキテクチャを分析して、
JWTからセッションベースに移行する計画を立ててください。
メリット・デメリット・移行リスクも評価してください。
4. モデルの使い分け戦略
Claude Codeでは/modelコマンドでセッション中にいつでもモデルを切り替えられます。適切に使い分けることで、コストと品質のバランスを最適化できます。
3つのモデルの特性
| モデル | 強み | 弱み | 最適な用途 |
|---|---|---|---|
| Opus 4.6 | 最高の推論能力、複雑なタスクに強い | 遅い、コスト高、レート制限あり | 設計判断、複雑なバグ調査、大規模リファクタリング |
| Sonnet 4.6 | 速度と品質のバランスが優秀 | 非常に複雑な推論はOpusに劣る | 日常的なコーディング、実装、テスト作成 |
| Haiku | 最速、最低コスト | 複雑なタスクは苦手 | 単純な修正、フォーマット、定型作業 |
実践的な使い分けフロー
# 1. 複雑な設計にはOpus
/model opus
「認証システムのリファクタリング計画を立てて」
# 2. 計画に納得したら実装はSonnet
/model sonnet
「この計画で実装してください」
# 3. 単純な修正はHaiku
/model haiku
「このファイルのインデントを修正して」
opusplanエイリアス — 最もおすすめの設定
手動で切り替えるのが面倒な方にはopusplanエイリアスがおすすめです。
/model opusplan
このエイリアスを使うと、プランモード中は自動でOpus 4.6、実装フェーズではSonnet 4.6に切り替わります。「計画は賢く、実装は速く」を自動化してくれる、コスト効率の最も高い設定です。
Effort Level(Opus 4.6専用)
Opus 4.6では、タスクの複雑さに応じた推論深度を設定できます。
/modelコマンド内で左右矢印キーを使ってスライダーを調整- 環境変数:
CLAUDE_CODE_EFFORT_LEVEL=low|medium|high
シンプルなタスクにlowを設定すると、Opusでもコストを抑えられます。デフォルトはhighです。
5. コンテキスト管理の実践テクニック
Claude Codeの応答品質はコンテキスト(会話の文脈)の状態に大きく左右されます。コンテキストが肥大化すると応答が遅くなり、品質も低下します。これを適切に管理するのが中級者への第一歩です。
コンテキストの現状を把握する
/context
このコマンドでコンテキストの使用量がカラーグリッドとして可視化されます。何がスペースを消費しているか(会話履歴、ツール出力、MCPツール定義など)が一目でわかります。
/compact — 最も重要なコマンド
# 基本:会話を圧縮して要約
/compact
# 応用:保持したい内容を指示して圧縮
/compact APIの変更内容に集中して
/compactは会話の要点を保持したまま圧縮するコマンドです。引数を渡すと、何を重点的に保持するかをコントロールできます。
/compact と /clear の使い分け
| 状況 | 使うコマンド | 理由 |
|---|---|---|
| 同じタスクを続けたいが会話が長くなった | /compact |
文脈を保持しつつスペースを確保 |
| まったく別のタスクに切り替える | /clear |
不要な文脈が邪魔になるため完全リセット |
| Claudeの応答がおかしくなった | /clear |
コンテキストの汚染をリセット |
CLAUDE.mdでcompact指示をカスタマイズ
CLAUDE.mdに# Compact instructionsセクションを追加すると、/compact実行時にデフォルトで保持する内容を指定できます。
# Compact instructions
- 現在作業中のファイルパスを必ず保持
- APIエンドポイントの変更履歴を保持
- テスト結果のサマリーを保持
コンテキスト管理のベストプラクティス
- 30分以上の作業ごとに
/compactを実行する習慣をつける - タスク切り替え時は
/clearで完全リセット - 大量のファイルを読む調査作業はClaude Codeのサブエージェントに委譲する(メインのコンテキストを汚染しない)
- MCPサーバーは必要最小限に接続する(各サーバーのツール定義がコンテキストを消費する)
6. プロンプトの書き方 — 結果が10倍変わるコツ
Claude Codeは自然言語を理解しますが、伝え方次第で出力の質が劇的に変わります。Anthropic公式が推奨するプロンプトの書き方を紹介します。
原則1:スコープを明確にする
| 悪い例 | 良い例 |
|---|---|
| 「foo.pyのテストを書いて」 | 「foo.pyのparse_config関数のテストを書いて。設定ファイルが存在しない場合と、JSONが不正な場合のエッジケースをカバーして。モックは使わないで」 |
原則2:情報ソースを指定する
| 悪い例 | 良い例 |
|---|---|
| 「このAPIの設計がおかしい理由は?」 | 「ExecutionFactoryのgit履歴を調べて、このAPIがどういう経緯で今の形になったか要約して」 |
原則3:既存パターンを参照させる
| 悪い例 | 良い例 |
|---|---|
| 「カレンダーウィジェットを追加して」 | 「ホームページの既存ウィジェットの実装を確認して。HotDogWidget.phpがよい参考になる。同じパターンに従って新しいカレンダーウィジェットを実装して」 |
原則4:検証基準を含める
| 悪い例 | 良い例 |
|---|---|
| 「validateEmail関数を実装して」 | 「validateEmail関数を実装して。テストケース: user@example.com → true、invalid → false、空文字 → false。実装後にテストを実行して」 |
@メンションでファイルを直接指定
@に続けてファイルパスを入力すると、そのファイルの内容が会話のコンテキストに含まれます。
@src/utils/auth.js のロジックを説明して
@src/components/ のファイル構成を見せて
ファイルパスはTabキーで補完できます。特定のファイルについて質問・変更を依頼するときに使いましょう。
画像・スクリーンショットの入力
Claude Codeは画像も理解できます。UIのバグ報告やデザインの指示に便利です。
- ドラッグ&ドロップ:ターミナルウィンドウに画像をドラッグ
- クリップボード貼り付け:
Ctrl+V(macOSのiTerm2ではCmd+Vも可) - パス指定:「この画像を分析して: /path/to/screenshot.png」
7. Git連携ワークフロー
Claude CodeはGitと深く統合されています。コミット、ブランチ作成、PR作成まで自然言語で操作できます。
コミットの自動生成
この変更をコミットして
Claude Codeはgit diffを分析し、変更の「何を」ではなく「なぜ」を説明するコミットメッセージを自動生成します。直近のコミット履歴も参照して、プロジェクトのコミットメッセージスタイルに合わせます。
ブランチ作成からPRまで
# 機能ブランチを作成して作業を開始
feature/jwt-refreshブランチを作成して、そこで作業して
# 作業完了後
この変更でPRを作成して。レビュアーにポイントが伝わるようなdescriptionを書いて
PR作成にはgh(GitHub CLI)がインストールされている必要があります。Claude Codeがgh pr createを実行し、適切なタイトルと本文を自動生成します。
コードレビューを依頼する
# ステージされた差分のレビュー
git diff --cached の内容をレビューしてください。
バグの可能性、セキュリティ上の問題、パフォーマンス問題の観点で確認して。
# GitHub PRのレビュー
gh pr diff 123 の内容をレビューして
Git連携のベストプラクティス
- 常にGit管理下で作業する —
/rewindやgit checkoutでいつでも元に戻せる安心感が大事 - 小さな単位でコミット — 大きな変更を1コミットにまとめず、論理的な単位で分割
- コミット前にdiffを確認 — 「コミット前にdiffを見せて」と依頼して内容を確認する習慣をつける
8. バグ修正の実践フロー
バグ修正はClaude Codeが最も威力を発揮する場面の1つです。ただし、伝え方次第で効率が大きく変わります。
効果的なバグ報告の3要素
Claude Codeにバグ修正を依頼するときは、3つの情報を必ず含めましょう。
バグの再現手順:
1. npm run dev でサーバー起動
2. /api/chat にPOSTリクエストを送信(bodyに { "message": "hello" })
3. レスポンスのストリームが途中で切れる
期待動作: ストリームが最後まで届く
実際の動作: 3秒後に500エラーが返る
エラーログ:
TypeError: Cannot read properties of undefined (reading 'choices')
at StreamHandler.process (src/handlers/chat.ts:142)
at async POST (src/app/api/chat/route.ts:28)
段階的なデバッグアプローチ
複雑なバグは、いきなり修正を依頼するのではなく段階的に進めます。
# Step 1: まず調査だけ依頼
このエラーの原因を調査してください。コードは変更しないでください。
# Step 2: 原因が特定されたら再現テストを作成
このバグを再現するテストを書いてください。テストが失敗することを確認してください。
# Step 3: 修正を実装
このテストが通るようにバグを修正してください。
# Step 4: 回帰テスト
修正後、既存のテストがすべて通ることを確認してください。
この「失敗するテストを先に書く → 修正 → テスト通過を確認」という流れは、テスト駆動開発(TDD)の原則に沿っており、Claude Codeとの相性が非常に良い手法です。
9. コスト最適化 — 賢く使う7つのテクニック
Anthropicの公式データによると、Claude Codeの平均コストは約$6/開発者/日、90%のユーザーが$12/日以下に収まっています。以下のテクニックでさらに効率的に使えます。
1. opusplanエイリアスを使う
前述の通り、計画はOpus、実装はSonnetの自動切り替え。これだけでコストを大幅に削減できます。
/model opusplan
2. /compactを定期的に実行
コンテキストが肥大化するとトークン消費が増えます。30分ごと、またはタスクの区切りで/compactを実行しましょう。
3. タスク切り替え時は/clear
前のタスクのコンテキストが残っていると、無駄なトークンを消費します。別のタスクに移るときは/clearでリセット。
4. プロンプトは具体的に
曖昧な指示はClaude Codeに余計な探索をさせ、トークンを浪費します。「このコードを改善して」より「src/auth.tsの定数をenumに抽出して」の方が効率的です。
5. CLAUDE.mdは500行以下に
CLAUDE.mdは毎セッションの開始時にコンテキストに読み込まれます。肥大化すると毎回のコストが増え、重要な指示を見落とす原因にもなります。
6. 不要なMCPサーバーを切断
接続中のMCPサーバーは、そのツール定義がコンテキストを消費します。使わないサーバーは無効化しましょう。/contextでどれくらい消費しているか確認できます。
7. Effort Levelを調整(Opus使用時)
シンプルなタスクにOpusを使う場合は、Effort Levelをlowに設定してトークン消費を抑えましょう。
コスト確認コマンド
| コマンド | 対象 | 表示内容 |
|---|---|---|
/cost |
API従量課金ユーザー | セッションのトークン使用量と金額 |
/stats |
サブスクライバー | 日次使用量、セッション履歴、モデル使用傾向 |
/usage |
サブスクライバー | プランの使用量制限とレートリミット状態 |
10. セッション管理で作業を中断・再開
開発作業は1回のセッションで終わるとは限りません。Claude Codeにはセッションの中断・再開機能が組み込まれています。
セッションに名前をつける
/rename auth-refactor
作業中のセッションに名前をつけておくと、後から簡単に再開できます。
セッションを再開する
# 直前のセッションを続ける(最も簡単)
claude -c
# 名前で再開
claude --resume auth-refactor
# セッション中に再開
/resume
/resumeを引数なしで実行すると、インタラクティブなセッションピッカーが開きます。セッション名、最終アクティビティからの経過時間、メッセージ数、Gitブランチが表示され、検索(/キー)やプレビュー(Pキー)もできます。
セッション管理のベストプラクティス
- 作業開始時に
/renameで名前をつける習慣をつける - 機能ブランチごとにセッションを分ける(
/resumeピッカーのBキーで現在のブランチのセッションだけ表示可能) - 長い中断の後は
/compactしてから作業を再開する claude -cは直前の会話を続ける最速の方法。ターミナルを閉じてしまった後に便利
11. まとめ
この記事で紹介したテクニックの要点をまとめます。
| テーマ | 核心 |
|---|---|
| ワークフロー | Explore → Plan → Code → Commitの4ステップを守る |
| プランモード | 大きな変更の前には必ずプランモードで計画を立てる |
| モデル選択 | opusplanで計画はOpus、実装はSonnetの自動切り替え |
| コンテキスト | /compactを定期実行、タスク切り替え時は/clear |
| プロンプト | 具体的に、検証基準を含めて、既存パターンを参照させる |
| Git | 常にGit管理下で作業。小さな単位でコミット |
| バグ修正 | 調査 → テスト作成 → 修正 → 確認の4段階で進める |
| コスト | opusplan + /compact + 具体的プロンプトでコストを最小化 |
| セッション | /renameで名前をつけ、claude -cで素早く再開 |
これらのテクニックは、Anthropicの公式ベストプラクティスとClaude Code作者のワークフローに基づいています。一度にすべてを取り入れる必要はありません。まずは「Explore → Plan → Code → Commit」のワークフローと、/compactの定期実行から始めてみてください。それだけでも、Claude Codeとの作業効率は大きく変わるはずです。
さらに深くClaude Codeを使いこなしたい方は、上級テクニック(Hooks・Skills・Subagents・MCP)を解説したClaude Code 完全攻略ガイドに進みましょう。
関連記事
- Claude Code 初心者完全ガイド|インストールから実践まで丁寧に解説
- Claude Code 完全攻略ガイド|ハッカソン優勝者が明かす本当の使い方
- Claude Code Agent Teams完全ガイド
- Claude Code vs Codex 徹底比較