筆者プロフィール: ソフトウェアエンジニア。「知った気にならない。いつまでも学び続ける」を信条に、業務と個人開発の両輪で技術を磨いています。AI 駆動開発で複数の個人開発アプリを構築・運用中。
👉 ポートフォリオ: 筆者ホームページ
この記事は約3分で読めます。
Claude に開発を任せるとき、どんなプロンプトを投げれば高品質なコードが返ってくるのか？ 本記事では 実装・レビュー・デバッグなど11パターンの実用プロンプト を、即コピペで使える形式でまとめます。連載「Claude プロンプト術 完全ガイド」の第3回です。
この記事の使い方
- 各パターンの
{{ }}を自分の状況に置き換えてコピペしてください - Claude Code / Claude Web / Claude API / Claude Desktop の 全プラットフォームで使えます
- 複数パターンの組み合わせも OK
🔵 信頼度について
本記事のプロンプト文言は筆者の解釈（🔵） です。公式のプロンプト原則（明確な指示・具体的コンテキスト・検証手段・動機付け）を、開発の実務シーンに応用したものです。
1. 実装依頼
{{機能名}} を実装してください。
【前提】
- 言語: {{言語}}
- フレームワーク: {{FW}}
- 既存コード: @{{ファイルパス}}
【要件】
- {{要件1}}
- {{要件2}}
【検証基準】
- {{テストケース1}} → {{期待結果}}
- {{テストケース2}} → {{期待結果}}
実装後、テストを実行し結果を報告してください。
ポイント: 「検証基準」を明示することで、Claude が自己検証できる（公式が推奨する最重要テクニック）。
2. コードレビュー依頼
以下のコードをレビューしてください。
観点: セキュリティ、パフォーマンス、可読性、テスト容易性。
各指摘には重要度（Critical/High/Medium/Low）を付け、
修正案のコードも併記してください。
{{コード}}
ポイント: 重要度ラベルで指摘を構造化、アクションに繋げやすくする。
3. デバッグ・バグ調査
以下のエラーが発生しています。根本原因を特定し、修正してください。
エラーを抑制するのではなく、原因に対処してください。
【エラーメッセージ】
{{エラーログ}}
【再現手順】
1. {{手順1}}
2. {{手順2}}
【環境】
- {{バージョン情報}}
修正後、失敗していたケースが通ることをテストで検証してください。
ポイント: 「根本原因に対処、エラーを抑制するな」と明示（公式の Before/After 例と同じ戦略）。
4. リファクタリング
以下のコードをリファクタリングしてください。
目的: {{目的（可読性向上/責務分離/パフォーマンス改善など）}}
【制約】
- 外部インターフェースは変更しない
- 既存のテストが全て通ること
- 1コミット = 1つの意図にまとまるよう段階的に
{{対象コード}}
ポイント: 「外部インターフェース不変」「1コミット1意図」で範囲を限定。
5. テスト生成
{{関数名}} のテストを書いてください。
【カバーすべきケース】
- 正常系: {{ケース}}
- 異常系: {{ケース}}
- エッジケース: {{空値/最大値/境界値など}}
【制約】
- モックは最小限
- テストランナー: {{Jest/pytest等}}
- AAA パターン（Arrange-Act-Assert）で記述
テストを書いた後、実際に実行して全てパスすることを確認してください。
ポイント: 「実際に実行して確認」で Claude 自身に検証させる。
6. ドキュメント生成
以下のコードから README.md を生成してください。
【含める内容】
- プロジェクト概要
- セットアップ手順（コピペで動くコマンド）
- 使い方（最小動作例）
- 主要な API / エンドポイント
- 環境変数一覧
【除外】
- 自明な説明
- AI っぽい修飾表現
{{コード or ディレクトリ}}
ポイント: 「除外」を明示すると AI 特有の冗長な表現を抑制できる。
7. 設計相談
{{機能名}} の設計を相談したいです。
いきなり実装案を出さず、まず設計を議論してください。
【背景】
{{状況・課題}}
【検討してほしい観点】
- アーキテクチャ（モノリス/マイクロサービス/レイヤー構成）
- データモデル
- 外部依存（DB/API/キュー）
- トレードオフ
3〜5個の選択肢を提示し、各メリット・デメリット・推奨度を表形式でください。
ポイント: 「いきなり実装案を出さず」で探索フェーズと実装フェーズを分離（Explore → Plan → Code の思想）。
8. 技術選定
{{用途}} に使う {{ライブラリ/FW}} を選定します。
候補: {{候補A}}, {{候補B}}, {{候補C}}
以下の観点で比較表を作成してください。
- 学習コスト
- パフォーマンス
- コミュニティの活発さ（GitHub Stars, 最終更新日）
- 本プロジェクトでの向き不向き
- ライセンス
公式ドキュメントを参照し、推測ではなく事実ベースで。
ポイント: 「公式ドキュメント参照」「事実ベース」で推測を排除。
9. 既存コード理解
@{{ファイルパス}} のコードを読み解いてください。
【知りたいこと】
- このファイルの責務
- 主要なクラス/関数の役割
- 他のどのファイルと依存しているか
- 「なぜこう書かれているか」の推測（git blame は必要なら参照）
初見の開発者にも分かるレベルで説明してください。
ポイント: @ でファイル直接参照、トークン効率が良い（公式記載）。
10. マイグレーション
{{FW}} を v{{旧}} から v{{新}} にアップグレードします。
【手順】
1. 公式のアップグレードガイドを参照
2. 破壊的変更をリストアップ
3. 本プロジェクトで影響する箇所を @ で特定
4. 修正パッチを段階的に提示
一度に全部変更せず、影響箇所ごとに確認できるよう分割してください。
ポイント: 「段階的に分割」で人間のレビューポイントを確保。
11. コマンド生成
{{やりたいこと}} を実現する {{Bash/Git/Docker/kubectl}} コマンドを教えてください。
【前提】
- OS: {{Windows/macOS/Linux}}
- 対象: {{ファイル/コンテナ/リソース}}
【望む形式】
- コマンド本体
- 各オプションの意味
- 実行前に確認すべきこと（破壊的でないか）
ポイント: 「破壊的でないかの確認」で rm -rf 系の事故を防止。
パターン活用のコツ 🔵
-
{{ }}を必ず埋める — 空欄のままだと Claude は推測で埋めてしまう - 検証手段は必ず添える — テスト・期待出力・スクショのいずれか
- スコープを切る — 「全ファイルに適用」より「このファイルのこの関数だけ」
-
スキル化を検討 — 繰り返し使うものは
.claude/skills/に登録すると/skill-nameで呼び出せる（🟡 Claude Code 限定）
次回予告
次回は Claude に伝わる指示の書き方。CLAUDE.md・動機説明・XML タグ・Few-shot など、プロンプト品質を底上げする5つのテクニックを解説します。
参考（一次ソース）
関連記事（連載「Claude プロンプト術 完全ガイド」全8回）
- 第1回: Claude プロンプト最重要3原則
- 第2回: Claude 開発ワークフロー
- 第3回（本記事）: Claude プロンプト 開発編11パターン
- 第4回: Claude に伝わる指示の書き方
- 第5回: Claude Code 固有機能の使い分け
- 第6回: Claude プロンプト 思考編13パターン
- 第7回: Claude プロンプト 日常編18パターン
- 第8回: Claude プロンプト術 完全ガイド — 全記事まとめ