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系統

5つの構造パターンは、いずれも「テキストをどう構造化するか」の話でした。実際のプロンプトでは、テキスト以外の形でどう情報を渡すかも結果を左右します。Claude Codeがサポートしているリッチコンテンツの渡し方は次の5系統です。

• @でファイル参照する:場所を言葉で説明する代わりに@src/lib/auth.tsのように指定すると、Claudeが該当ファイルを読んでから応答します
• 画像を直接貼る:スクリーンショットをコピー&ペーストやドラッグ&ドロップでそのまま渡せます。UIの見た目を伝えるときはテキストで説明するより確実です
• ドキュメントURLを渡す:APIリファレンスや外部ドキュメントのURLをそのまま貼れます。頻繁に参照するドメインは/permissionsでallowlistに登録しておくと、確認のたびに止まりません
• パイプで流し込む:cat error.log | claudeのようにコマンドの出力を直接渡す方法です。ログファイルやビルド出力をコピー&ペーストする手間が省けます
• Claude自身に取りに行かせる:「必要な情報はBashコマンドやMCPツール、ファイル読み込みで自分で取得して」と指示する方法です。何を渡すべきか自分でも分からないときに有効です

命令型・探索型で「情報源を指す」プロンプトを書くとき、この5系統のどれを選ぶかで結果の精度が変わります。エラーメッセージはパイプで流し込み、UIの崩れは画像で見せ、既存パターンはファイル参照で示す、というように渡し方をタスクの性質に合わせるのがコツです。テキストの構造化と情報の渡し方は独立した2つの軸として、組み合わせて考えるとプロンプトの精度が上がります(公式ドキュメントが示す原則はClaude Codeベストプラクティスも参照してください)。

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

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

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

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

よくあるつまずきと直し方

5パターンを意識しても、実際のプロンプトではいくつかの典型的なつまずきが起きます。パターン別に代表的な失敗と直し方を挙げます。

• 命令型のつまずき:「〜を直して」とだけ書いて、直った状態の定義を省く。Claude Codeは「動いているように見える」修正で止まることがあるため、期待する出力やテストコマンドまで1文で添えると手戻りが減ります
• 探索型のつまずき:「全部調べて」とだけ依頼し、途中で読むファイル数が膨らんでコンテキストを消費する。範囲(対象ディレクトリ・拡張子・除外パターン)を先に絞ると、同じ調査でも消費を抑えられます
• 比較型のつまずき:評価軸を与えずに「比較して」とだけ頼み、出てくる表が依頼ごとに違う項目になる。評価軸をこちらで固定して渡すと再現性が上がります
• 計画型のつまずき:「計画を立てて」と頼んだのに、そのまま実装まで進んでしまう。「今は計画だけで、ファイルは変更しないでください」の一文を明示しないと、計画と実装の境界が曖昧になります
• レビュー型のつまずき:「レビューして」とだけ頼み、観点が命名だけに偏る、あるいは逆に総花的すぎて具体性を欠く。観点をあらかじめ列挙してから依頼すると、判定のばらつきが減ります

共通する処方箋は同じで、「何を」だけでなく「どう判定するか」までプロンプトに含めることです。これは検証可能性(テストケースや期待出力を渡す)という考え方と同じ発想で、5つの構造パターンのどれを使う場合にも効きます。

よくある質問

5つの構造パターンは組み合わせて使えますか

はい。1つの依頼で複数のパターンをつなげて使うことは珍しくありません。「まず影響範囲を調べて(探索型)、その結果をもとに計画を立てて(計画型)」のように、探索→計画の順で連結するのが典型的な組み合わせです。パターンは排他的なカテゴリではなく、目的に応じて組み立てるパーツとして捉えると使いやすくなります。

どのパターンを使うか迷ったときはどうすればいいですか

迷ったら探索型から始めるのが安全です。曖昧な依頼でも、Claude Codeに現状を調べさせて報告を受けてから次の指示を出せば、軌道修正のコストを小さく保ったまま方向性を固められます。最初から命令型で細部まで指定しようとすると、前提の誤りに気づくのが遅れます。

曖昧なプロンプトは避けるべきですか

一律には避けるべきではありません。探索フェーズでは、あえて曖昧な依頼(「このファイルを改善するなら?」など)が有効な場面もあります。軌道修正できる前提であれば、曖昧さは禁忌ではなく使い分けの対象です。避けたいのは、命令型のように進路修正の余地がないタスクで曖昧語を使うことです。

自分のプロンプトが狙った構造になっているか確認する方法はありますか

送信前に「これは命令型か、探索型か」と一度自問すると、狙った構造になっているか確認しやすくなります。曖昧語(「いい感じに」「うまく」)が混ざっていたら、該当パターンの「注意点」に立ち返って書き直すのが早道です。

5つの構造パターンはClaude Code以外でも使えますか

構造そのものは、テキストベースでやり取りするAIアシスタント全般に応用できる考え方です。ただし本記事で触れているツール(Grep / Task隔離 / Planセッション相当の機能など)はClaude Code固有の実装に依存する部分があるため、他のツールで使う場合は自分の環境で使える機能に読み替えてください。

まとめ

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

関連記事としてClaude Code生産性向上tips 12選では、本記事のパターンを支える運用tips(Task隔離 / /clear / Hook等)を扱っています。構造を選んでもなお一手詰まる難所だけ、その場で思考の深さを底上げしたいときはClaude Code ultrathinkでその場だけ深く考えさせるが使えます。