Claude Codeの実践的プロンプトパターン15選 — 日常開発で使える型

Claude Code に「この関数を直して」と雑に投げても、それなりに動きます。でも「それなり」と「的確」の差は大きいです。

この記事では、自分が日常の開発で実際に使っているプロンプトのパターンを15個紹介します。それぞれ「なぜその書き方が効くのか」も添えました。コピペして自分のプロジェクトに合わせて改変してみてください。

基本原則：Claude Code のプロンプトで意識すること

パターンに入る前に、3つの原則を押さえておきます。

1. ゴールを先に、制約を後に。 Claude は最初に読んだ情報を重視します。「何をしたいか」を先に書き、「ただしこの制約を守って」を後に続けます。
2. 具体例は最強のプロンプト。 「こういう入力に対して、こういう出力が欲しい」という例示は、抽象的な指示の10倍効きます。
3. コンテキストを渡しすぎない。 関連ファイルを全部読ませるより、「この関数だけ見て」と限定したほうが精度が上がることが多いです。

バグ修正系

パターン1：エラーメッセージ貼り付け型

このエラーを修正して

[エラーメッセージをそのまま貼り付け]

なぜ効くか： Claude Code はエラーメッセージからスタックトレースを辿り、該当ファイルを自動で見つけて修正します。余計な説明は不要です。バグ報告を受けたら、エラーログをそのまま貼るのが最速です。

パターン2：再現手順付き型

○○ページで△△ボタンを押すと、□□が起きる。
期待する動作は✕✕。

なぜ効くか： エラーメッセージがない場合（UIのバグなど）に使います。「現状の動作」と「期待する動作」の差分を明示することで、Claude が修正ポイントを特定しやすくなります。

パターン3：仮説提示型

○○が起きている。原因は△△だと思う。
まず仮説が正しいか確認して、正しければ修正して。

なぜ効くか： 自分なりに原因の仮説がある場合、それを伝えることで Claude の探索範囲が狭まります。仮説が間違っていれば Claude が「違います、実は□□が原因です」と教えてくれるので、学びにもなります。

リファクタリング系

パターン4：Extract 型

この関数が長すぎる。意味のあるまとまりで関数を分割して。
関数名は処理内容が分かる名前にして。

なぜ効くか： 「リファクタリングして」は曖昧すぎます。「関数を分割」という具体的な操作を指定することで、Claude が何をすべきか迷いません。

パターン5：パターン統一型

このディレクトリ内のファイルで、エラーハンドリングのパターンがバラバラ。
○○.ts のパターンに統一して。

なぜ効くか： 「お手本」となるファイルを1つ指定することで、Claude がそのパターンを正確に認識し、他のファイルに適用します。抽象的に「統一して」と言うより遥かに正確です。

パターン6：命名改善型

この変数名/関数名がわかりにくい。より意図が伝わる名前に変更して。
ただし公開APIの名前は変えないで。

なぜ効くか： 命名の改善は Claude が得意な領域です。ただし「公開APIは変えない」という制約がないと、import している他のファイルまで壊れるリスクがあります。

テスト系

パターン7：テスト生成型

この関数のテストを書いて。
正常系、異常系、境界値をカバーして。
既存のテストファイルのスタイルに合わせて。

なぜ効くか： 3行目が重要です。「既存のスタイルに合わせて」がないと、プロジェクトの他のテストと書き方がバラバラになります。Claude は既存テストを読んで mock の使い方やアサーションのスタイルを合わせてくれます。

パターン8：テスト失敗修正型

テストを実行して。失敗したら修正して。全部通るまで繰り返して。

なぜ効くか： Claude Code はテスト実行 → エラー読解 → 修正のループを自律的に回せます。人間が介在する必要がないため、これを投げて別の作業をすることもできます。

新機能実装系

パターン9：Plan モード活用型

/plan

○○機能を追加したい。
- ユーザーが△△できるようにする
- □□の制約を守る
- 既存の✕✕機能には影響を与えない

なぜ効くか： 3ステップ以上の複雑な実装は、いきなりコードを書かせるより Plan モードで全体設計を先に固めたほうが手戻りが少なくなります。計画に納得してから実装に移ります。

パターン10：既存パターン踏襲型

○○と同じパターンで、△△を追加して。
○○の実装を参考にして、必要な部分だけ変えて。

なぜ効くか： ゼロから設計を考えさせるより、既存の類似機能を「テンプレート」として指定するほうが、コードベースの一貫性が保たれます。

コードレビュー・PR系

パターン11：差分レビュー型

git diff を見て、この変更に問題がないかレビューして。
特にセキュリティとパフォーマンスの観点で。

なぜ効くか： 「レビューして」だけだと観点が広すぎます。「セキュリティとパフォーマンス」のように観点を限定することで、深いレビューが得られます。

パターン12：PR作成型

ここまでの変更をコミットして、PRを作って。
PRの説明にはなぜこの変更が必要かを書いて。

なぜ効くか： Claude Code は git の操作から PR 作成まで一貫して行えます。「なぜ必要か」の指示で、PR の description が「what（何を変えたか）」だけでなく「why（なぜ変えたか）」を含む良い PR になります。

調査・理解系

パターン13：コード考古学型

この関数がなぜこうなっているのか、git log と周辺コードから推測して。

なぜ効くか： レガシーコードの意図を知りたいときに使います。Claude Code は git blame や git log を辿って変更の経緯を調べ、「おそらくこういう理由でこう書かれている」と推測してくれます。

パターン14：影響範囲調査型

この関数を変更した場合、影響を受けるファイルを全部リストアップして。

なぜ効くか： 大規模な変更の前に、影響範囲を把握するために使います。Claude Code は grep と依存関係の解析を組み合わせて、呼び出し元をすべて洗い出します。

メタ系

パターン15：CLAUDE.md 更新型

今の会話で分かったことのうち、今後も役立つものがあれば CLAUDE.md に追記して。

なぜ効くか： バグ修正や機能追加の過程で得られた知見（「この API は非推奨」「この設定はこうしないと動かない」等）を CLAUDE.md に蓄積させます。次回以降のセッションで同じ問題に遭遇しなくなります。

アンチパターン：避けるべきプロンプト

NG1：「全部やって」

❌ このアプリの全体をリファクタリングして、テストも書いて、ドキュメントも更新して。

スコープが広すぎてどこから手をつけるか迷います。大きなタスクは分割して、1つずつ依頼するのがおすすめです。

NG2：「良い感じにして」

❌ この UI を良い感じにして。

「良い感じ」の定義が不明です。具体的に「ボタンの色をプライマリカラーに」「余白を 16px に」と指定します。

NG3：コンテキスト過多

❌ [50ファイル分のコードを貼り付けて] この中のバグを探して。

Claude Code は自分でファイルを探索できます。全部渡すより、「○○の機能にバグがある」と伝えて探索させたほうが精度が高くなります。

まとめ

15のパターンを整理すると、共通するのは3つの原則に集約されます。

1. 具体的に指示する — 「リファクタリングして」ではなく「関数を分割して」
2. 制約を明示する — 「公開APIは変えない」「既存のスタイルに合わせて」
3. Claude の強みを活かす — ファイル探索、git 操作、繰り返し実行を任せる

プロンプトは使い分けることで洗練されます。意識して使い続けることで、Claude Code との協業効率は確実に上がっていきます。