Claude Codeで効くプロンプト5つの構造パターン — 命令型から探索型まで

このTipsでできること

Claude Codeに同じことを依頼しても、プロンプトの構造で結果の質が大きく変わります。本記事は、実運用で効きが大きい5つの構造パターンを取り上げます。

「何をどう書くか」ではなく、「どの構造で書くか」に注目します。各パターンは特定のタスクタイプに最適化されており、誤った構造でプロンプトを書くとClaude Codeが想定外の方向に走り出します。

5つの構造パターン

パターン1: 命令型(Imperative)

「これをやれ」という直接指示型。目的が明確で、進路修正の必要がないタスクに使います。

src/lib/auth.ts の verifyToken 関数を、jwt-decode から jose に置き換えてください。
インターフェイスは変えない、動作は同じ、依存だけ入れ替える方針です。
package.json も忘れずに更新してください。

効くシーン: 機械的な置換、リネーム、フォーマット適用、依存入れ替え。

注意点: 「やってみて」「いい感じに」のような曖昧語は避ける。具体的な対象・範囲・期待動作を指定する。

パターン2: 探索型(Exploratory)

「調べて報告」型。仕様の理解 / コード把握 / 影響範囲調査に使います。

このリポジトリで `useAuth` フックを使っているコンポーネントを全部リストアップしてください。
各コンポーネントについて、フックがどう使われているか(取り出している値、副作用の有無)を 1 行で要約してください。
最後に、このフックの破壊的変更を行うときの影響範囲を表でまとめてください。

効くシーン: リファクタ前の影響調査、ライブラリ導入前の現状把握、ドキュメント生成。

注意点: 「全部」「網羅して」と書くだけだとClaude Codeが場合によっては取りこぼす。「先にgrepで全候補を抽出してから、それぞれをReadで確認」のように手順をヒント化すると確実性が上がる。重い調査はTaskで隔離するのも有効。

パターン3: 比較型(Comparative)

「複数選択肢を出して比較」型。意思決定の前段階で使います。

このフォームバリデーションに使うライブラリ候補を 3 つ挙げてください。
各候補について以下の表を作ってください:
 
| 候補 | 採用ペース | バンドルサイズ | TypeScript 対応 | 学習コスト | 本プロジェクトの適合度(1-5) |
 
最後に、本プロジェクト(React + Next.js 16 + zod 既導入)での推奨候補を理由付きで 1 つ示してください。

効くシーン: ライブラリ選定、設計選択肢の比較、移行先の評価。

注意点: 「いい感じに比較して」だけでは表が出ない。評価軸を明示してテンプレートを与えるとクオリティが安定する。

パターン4: 計画型(Planning)

「先に計画を立てて、人間が確認してから実装」型。影響範囲が広いリファクタ / 大型変更で使います。

この lib/auth ディレクトリ全体を「サーバ専用ロジック」と「クライアント共有ロジック」に分割したいです。
まず計画だけ立ててください:
1. 現状の依存関係図(どのファイルがどのファイルを import しているか)
2. 分割後の目標構造
3. 移行手順を 5〜10 ステップで(各ステップで何が壊れる可能性があるか含む)
4. ロールバック方針
 
実装は計画レビュー後に着手します。**今は計画を立てるだけ**で、ファイル変更はしないでください。

効くシーン: モジュール分割、ライブラリ移行、データモデル改修、性能改善。

注意点: 「計画と実装を一気にやって」は失敗しやすい。Planセッションと実装セッションは分ける。計画書をファイル化すると、実装セッションでも参照できる。

パターン5: レビュー型(Reviewing)

「成果物を独立した目で評価」型。自分が書いたコードをセルフレビューさせるときに使います。

直近のコミット 3 つの diff(`git log -p HEAD~3..HEAD`)を確認して、以下の観点でレビューしてください:
 
- 命名: 役割が伝わるか、既存規約と整合しているか
- エラー処理: 想定外入力 / API 失敗 / 並行アクセスへの対応漏れがないか
- テスト: 振る舞いの変更に対するテスト追加が漏れていないか
- ドキュメント: README / CLAUDE.md / 関連 doc の更新が必要か
- セキュリティ: 認証情報の扱い / SQL injection / XSS の経路がないか
 
各観点で「問題なし」「軽微」「Must 修正」の 3 段階で評価し、Must は具体的な修正案を添えてください。

効くシーン: PR作成前のセルフレビュー、CIレビューの前段、認証情報を含む変更の確認。

注意点: 「レビューして」だけでは観点が散漫になる。判定基準を具体的に書くのがコツ。レビューは別セッション / 別Taskで走らせると独立した目になり、見落としが減る(サブエージェント完全活用パターン5)。

5パターンの使い分け早見表

他記事で書かれていない切り口

これら5パターンは、それぞれ「Claudeがどんなツールを使うべきか」を間接的に決めます。

• 命令型はEdit / Writeを多く使う
• 探索型はGrep / Read / Task(Explore 型)を多く使う
• 比較型はWebFetch / Readを多く使い、最後に表を生成
• 計画型はRead / Globを中心に、Plan 型サブエージェントが効く
• レビュー型はBash(git diff)+ Readで、別Taskで走らせると独立性が上がる

つまり構造を選ぶ = ツール使用パターンを選ぶということです。プロンプトの書き方ひとつで、Claude Codeの内部挙動が大きく変わります。

まとめ

「いい感じにやって」と曖昧に依頼するより、5パターンのどれに該当するかを意識して構造化したプロンプトを書くと、結果の質が一段安定します。試行錯誤しながら自分のワークフローに合うテンプレを5〜10個ストックすると、毎日のプロンプトが格段に楽になります。

関連記事としてClaude Code生産性向上tips 12選では、本記事のパターンを支える運用tips(Task隔離 / /clear / Hook等)を扱っています。