Claude に開発を任せる — 実装・レビュー・デバッグで使えるプロンプト 11 パターン

📅 2026/5/1 ⏱ 2分で読めます Claude Code AI駆動開発プロンプトエンジニアリング個人開発 +1

連載第 4 回です

「Claude に頼みたいことはあるのに、毎回プロンプトを考えるのが地味にしんどい」

そう感じたこと、ありませんか？私も以前、毎回 3 分くらい固まっていました。

前回で開発ワークフローの 4 段階をお伝えしました。今回は、各段階で実際に投げる プロンプトの型 を 11 パターン紹介します。

ここで紹介するのは全て、私が 個人開発の現場で日常的に使っている ものです。Claude Code / Claude Web / Claude API、どのプラットフォームでもそのまま使えます。

1. 実装依頼

{{ファイル/機能名}} に {{機能}} を追加してください。

コンテキスト:
- プロジェクト: {{プロジェクト説明}}
- 既存の類似実装: {{参照パス}}

検証:
- 実装後に {{テストコマンド}} を実行して結果を報告
- ビルドが通ることを確認

コンテキスト + 検証基準の 2 点セット が効きます。

2. コードレビュー依頼

{{ファイルパス}} をレビューしてください。

観点:
- セキュリティ (XSS / SQL インジェクション / 機密漏洩)
- パフォーマンス (N+1 / 不要な再描画 / ループ内 DB 呼び出し)
- 可読性 (命名 / 関数分割 / コメント過不足)

出力:
- 問題点を優先度順（High/Mid/Low）で列挙
- 各問題に行番号と修正案を添付

観点を明示 することで、Claude は抜け漏れなくレビューします。

3. デバッグ・バグ調査

次のエラーが出ています:
{{エラーメッセージ全文}}

再現手順:
1. {{手順1}}
2. {{手順2}}

やってほしいこと:
- 根本原因を特定（症状を隠さない）
- 修正案を提示（なぜその修正で直るかの説明付き）
- 再発防止のためのテスト追加案

「症状を隠すな、根本原因に触れろ」 を明記するのが大事。

4. リファクタリング

{{ファイルパス}} をリファクタしてください。

目的: {{ビジネス上の目的}}
制約:
- 既存のテストを壊さない
- API 互換性を維持
- 1 コミット = 1 関心事

制約を先に書く と、暴走しません。

5. テスト生成

{{対象ファイル}} のユニットテストを Vitest で書いてください。

カバー観点:
- 正常系（代表的な入力 3 ケース）
- 異常系（空入力 / null / 型エラー）
- 境界値

ファイル配置: {{対象}}.test.ts

6. ドキュメント生成

{{関数名}} の JSDoc を書いてください。

含める要素:
- 1 行サマリ
- @param ごとの説明
- @returns の説明
- @example の使用例 2 つ

7. 設計相談

{{機能}} の設計について相談させてください。

要件:
{{要件箇条書き}}

私が考えているのは {{案}} ですが、以下を議論したいです:
- この設計の弱点
- 他の選択肢（最低 2 案）
- 各選択肢のトレードオフ

「他の選択肢を 2 案以上」 と指示すると、視野が広がります。

8. 技術選定

{{課題}} を解決するための技術選定を手伝ってください。

前提:
- 制約 1: {{予算 / 時間 / 規模}}
- 制約 2: {{チームスキル}}

比較してほしい候補: {{A, B, C}}
観点: 学習コスト / 運用コスト / スケーラビリティ / エコシステム
出力: 比較表 + 最終推奨（理由付き）

9. 既存コード理解

{{ファイル/ディレクトリ}} のコードを読んで、以下を教えてください:

- 責務（何をするモジュールか）
- 主要な関数 5 つとその役割
- 依存関係（何に依存し、何から依存されているか）
- 弱点（リファクタ候補があれば）

新しいリポジトリに入ったとき最強 です。

10. マイグレーション

{{旧バージョン}} → {{新バージョン}} に移行してください。

手順:
1. 破壊的変更の一覧を公式 CHANGELOG から抽出
2. 影響を受けるファイルを grep
3. ファイルごとに修正案を提示（レビュー後に実装）

11. コマンド生成

{{やりたいこと}} を実現する {{シェル種別}} コマンドを書いてください。

環境: {{OS / shell}}
制約: {{インストール不要 / POSIX 準拠 等}}

パターン活用のコツ

どのパターンも共通して効くテクニック:

{{ }} を自分の状況に置き換えて コピペで使う
複数パターンを組み合わせる のも OK（例: 1 + 5 で「実装 + テスト生成」）
検証基準を忘れずに 添える（3 原則の原則 3）

私の体感 — パターン化の効果

以前は「なんて書こう…」と毎回 3 分悩んでいたのが、今は パターンを指差して {{ }} を埋める だけ。プロンプト作成時間が 10 分の 1 になりました。

そして、パターンが型化されていると Claude の精度も安定 します。毎回違う書き方をしているとき、Claude の出力品質も毎回違う。型が一定なら、結果の品質も一定に近づきます。これは設計書でも同じですね。

まずは 1 パターンだけ、自分用にコピーして手元に置いておくところから試してみてはどうでしょうか。

Claude に「いきなりコード」を書かせない — Explore → Plan → Code → Commit の 4 段階 — ワークフロー編
Claude を「優秀な新人インターン」として扱う — 公式が教える 3 つの最重要原則 — 原則編
Qiita 版（プロンプト全文・拡張パターン含む）: Qiita 筆者ページ