Claude Code プロンプティングガイド2025｜実践的な10のテクニック¶
この記事の対象者
- Claude Codeを使い始めたが出力品質にばらつきがある初心者〜中級者
- プロンプトの書き方で開発効率を改善したい実務者
この記事のポイント¶
- 公式ベストプラクティスに基づく4フェーズワークフローを理解
- 環境設定・コンテキスト管理で安定した出力品質を実現
- よくある失敗パターンを把握し、生産性の低下を回避
公式4フェーズワークフロー¶
Claude Codeの公式ベストプラクティスでは、4つのフェーズに分けて作業を進めることが推奨されています。このワークフローに沿ってプロンプトを構成することで、出力品質が安定します。
Phase 1: Explore（調査）→ Phase 2: Plan（設計）→ Phase 3: Implement（実装）→ Phase 4: Verify（検証・コミット）
| フェーズ | 目的 | 推奨モード |
|---|---|---|
| Phase 1: Explore | コードベースの理解・調査 | Plan Mode（Shift+Tab で切替） |
| Phase 2: Plan | ソリューションの設計 | Plan Mode |
| Phase 3: Implement | 変更の実装 | Normal Mode |
| Phase 4: Verify | テスト・レビュー・コミット | Normal Mode |
Plan Mode の活用
Shift+Tab を押すことで、Normal → Auto-accept edits → Plan Mode の順にモードを切り替えられます。調査・設計フェーズでは Plan Mode を使うことで、Claude がコードを変更せずに分析と提案に集中します。
Phase 1: Explore（調査）プロンプト¶
コードベースの理解と現状把握に集中するフェーズです。
「このリポジトリの全体構成を説明してください。
主要なエントリーポイント、依存関係、データフローを把握したい」
「@src/auth/handler.ts を読んで、認証フローの全体像を説明してください。
関連するミドルウェアや設定ファイルも確認してください」
@filename でファイルを直接参照
プロンプト内で @ファイルパス を使うと、該当ファイルをコンテキストに直接追加できます。Claude に読んでほしいファイルが明確な場合、この方法が最も効率的です。
Phase 2: Plan（設計）プロンプト¶
調査結果を踏まえて、実装方針を設計するフェーズです。
「認証モジュールにOAuth2.0対応を追加したい。
以下の制約を踏まえて実装計画を立ててください:
- 既存のセッション管理との互換性維持
- TypeScript strict mode対応
- 既存テストが全てパスすること
変更が必要なファイルの一覧と、変更の順序を提示してください」
「以下の3つのアプローチについて、それぞれのメリット・デメリットを分析してください:
1. 既存クラスの拡張
2. Strategy パターンによる分離
3. ミドルウェアとしての実装
推奨案とその理由も説明してください」
Phase 3: Implement（実装）プロンプト¶
Plan Mode から Normal Mode に切り替えて、実際の変更を行うフェーズです。
コンテキスト先行型プロンプト¶
要求の前にコンテキストを先に提供することで、実装精度が向上します。
「プロジェクト概要: Node.js Express API、月間10万リクエスト処理
現在の課題: 500エラーが頻発、ユーザビリティに影響
技術制約: TypeScript必須、既存DBスキーマ維持
上記を踏まえ、エラーハンドリングを改善してください」
制約条件の明確化¶
制約を明示することで、生成されるコードの実用性が大幅に向上します。
"""
制約条件:
- Python 3.9以上
- メモリ使用量500MB以下
- レスポンス時間200ms以内
- 既存のORM変更不可
- Docker環境対応必須
上記制約下で、以下の機能を実装してください:
[具体的な機能説明]
"""
CLIツール活用の指示¶
Claude Codeは外部サービスとの連携において、APIを直接呼び出すよりもCLIツールを使う方が効果的に動作します。
「GitHub Issueの一覧を取得して、未対応のバグを確認してください」
→ Claude Code は `gh issue list` を使用
「S3バケットの内容を確認してください」
→ Claude Code は `aws s3 ls` を使用
| サービス | 推奨CLIツール | 使用例 |
|---|---|---|
| GitHub | gh | gh issue list, gh pr create |
| AWS | aws | aws s3 ls, aws ecs describe-services |
| GCP | gcloud | gcloud compute instances list |
| Docker | docker | docker ps, docker logs |
Phase 4: Verify（検証）プロンプト¶
実装後にテスト・レビュー・コミットを行うフェーズです。
「変更した内容に対してテストを実行してください。
失敗したテストがあれば修正し、全テストがパスすることを確認してください」
「変更内容をレビューして、以下の観点で問題がないか確認してください:
1. エッジケースの考慮漏れ
2. セキュリティ上の懸念
3. パフォーマンスへの影響
4. 既存APIとの互換性」
Extended Thinking（拡張思考）の設定¶
複雑なタスクでは、Claude にじっくり考えさせることで出力品質が向上します。特定のキーワードではなく、設定で制御するのが正しいアプローチです。
| 設定方法 | 説明 |
|---|---|
| 設定ファイル | alwaysThinkingEnabled: true で常時拡張思考を有効化 |
| 環境変数 | CLAUDE_CODE_EFFORT_LEVEL を low / medium / high に設定 |
| Plan Mode | Shift+Tab で Plan Mode に切り替え（調査・設計フェーズに最適） |
キーワードトリガーについて
「ultrathink」「think harder」等のキーワードで思考モードが切り替わるという情報が広まっていますが、安定した制御方法ではありません。上記の設定ベースのアプローチを推奨します。
コンテキスト管理テクニック¶
Claude Codeのセッションが長くなると、コンテキストウィンドウの管理が重要になります。
基本コマンド¶
| コマンド | 用途 |
|---|---|
@ファイルパス | 特定のファイルをコンテキストに追加 |
/compact | コンテキストを要約して圧縮 |
/clear | コンテキストをリセットして最初からやり直す |
2回修正しても直らなければリセット¶
同じ問題を2回以上修正指示しても解決しない場合、コンテキストが汚染されている可能性があります。
手順:
1. /clear でセッションをリセット
2. 問題点を最初から明確に説明し直す
3. 必要なファイルを @filename で明示的に参照
サブエージェント（Task tool）で調査を分離¶
大規模な調査タスクでは、メインのコンテキストが調査結果で埋まることを防ぐために、サブエージェントの活用が効果的です。
「Task tool を使って、このリポジトリ内の全てのAPI
エンドポイントを一覧化してください。
結果のサマリーだけメインに報告してください」
サブエージェントはメインコンテキストとは独立して動作するため、大量のファイルを読み込んでもメインの作業コンテキストが圧迫されません。
環境設定のベストプラクティス¶
Claude Codeの出力品質は、プロンプトだけでなく環境設定にも大きく左右されます。
CLAUDE.md の作成¶
プロジェクトルートに CLAUDE.md を配置することで、Claude Code にプロジェクト固有のコンテキストを提供できます。
# 自動生成でブートストラップ
claude /init
CLAUDE.md のコツ
- 簡潔かつ具体的に書く（長すぎると指示が埋もれる）
- ビルドコマンド、テストコマンド、コーディング規約を含める
- 「〜しないでください」より「〜してください」の肯定形で書く
権限設定¶
# 権限の設定
/permissions
# サンドボックスモードの切替
/sandbox
Hooks（確定的アクション）¶
ファイル保存時のリント実行やコミット前のテスト実行など、毎回同じ動作が必要な処理は Hooks で自動化します。Hooks は Claude の判断を介さないため確実に実行されます。
カスタムスキルとエージェント¶
| 設定 | 配置先 | 用途 |
|---|---|---|
| Custom Skills | .claude/skills/ | 特定タスクの専門知識をオンデマンドで提供 |
| Custom Subagents | .claude/agents/ | 特定ワークフロー専用のエージェント定義 |
プロジェクトタイプ別の最適化プロンプト¶
Web開発プロジェクト¶
「プロジェクト種別: Webアプリケーション
フロントエンド: React + TypeScript
バックエンド: Node.js + Express
データベース: PostgreSQL
デプロイ: AWS ECS
チーム構成: 4名（フロント2名、バック2名）
コーディング規約: Prettier + ESLint
テストフレームワーク: Jest
[開発要件]
上記環境下で、以下の機能を実装してください...」
データ分析プロジェクト¶
"""
プロジェクト種別: データ分析パイプライン
技術スタック: Python + Pandas + NumPy
データ量: 月間100万レコード
処理時間要件: バッチ処理2時間以内
分析要件:
- 欠損値処理の自動化
- 異常値検出アルゴリズム
- 可視化レポート生成
上記を満たすコードを生成してください...
"""
よくある改善Before/Afterパターン¶
| 問題パターン | 従来のプロンプト | 公式推奨プロンプト |
|---|---|---|
| 曖昧な依頼 | 「このコードを良くして」 | 「可読性向上+パフォーマンス改善+エラー処理強化の観点で改善」 |
| 情報不足 | コードのみ貼り付け | プロジェクト背景+制約+目標を含めて説明 |
| 複雑すぎる依頼 | 「システム全体をリファクタリング」 | 「認証モジュールから段階的にリファクタリング開始」 |
よくある失敗パターンと回避策¶
公式ドキュメントで指摘されている、生産性を低下させる代表的なアンチパターンです。
1. キッチンシンクセッション¶
問題: 無関係なタスクを1つのセッションに詰め込む
❌ 「認証バグを直して、それからUIのCSSも調整して、
あとデプロイスクリプトも書いてください」
✅ タスクごとにセッションを分ける:
セッション1: 「認証バグの修正」
セッション2: 「UIのCSS調整」
セッション3: 「デプロイスクリプトの作成」
2. 修正の繰り返し（コンテキスト汚染）¶
問題: 同じ問題を何度も修正指示し、コンテキストが汚染される
❌ 「違います、こうしてください」→「まだ違います」→「そうじゃなくて...」
✅ 2回修正しても直らない場合:
1. /clear でリセット
2. 要件を最初から明確に記述し直す
3. CLAUDE.md の過剰記述¶
問題: CLAUDE.md に大量の指示を書きすぎて、重要な指示が埋もれる
❌ 100行以上の詳細なルール、例外事項、複雑な条件分岐
✅ 簡潔に核心を記述:
- ビルドコマンド: npm run build
- テストコマンド: npm test
- コーディング規約: ESLint + Prettier準拠
- 重要ルール: 最大3-5項目に絞る
4. テストなしの信頼（Trust-then-Verify Gap）¶
問題: Claude の出力を検証せずにそのまま使用する
❌ 実装だけ依頼して、テストを書かない・実行しない
✅ 実装と検証をセットで依頼:
「機能を実装し、テストも作成・実行してください。
全テストがパスすることを確認してから完了としてください」
5. 無限探索（スコープ未定義の調査）¶
問題: 調査範囲を限定せずに調べさせ、時間とトークンを浪費する
❌ 「このコードベースの問題点を全て洗い出してください」
✅ スコープを明確にする:
「src/auth/ ディレクトリ内の認証ロジックについて、
セキュリティ上の問題点を3つまで指摘してください」
次のステップ¶
これらのテクニックをマスターした後は、Claude Code完全活用ガイドでより幅広い機能を学習し、開発効率をさらに向上させましょう。