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が多数のファイルを読んでコンテキストを使い切ることがあります。「先に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セッションと実装セッションは分ける。計画書をファイル化すると、実装セッションでも参照できる。「ファイルは変更しないで」と書く代わりに、仕組みで止める方法は、後段の「計画型は『書かないでください』よりplan modeで境界を引く」にあります。

パターン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 -p "このエラーを説明して"のようにコマンドの出力を直接渡す方法です。-pは応答を出力して終了する非対話モードの指定です。ログファイルやビルド出力をコピー&ペーストする手間が省けます
• Claude自身に取りに行かせる:「必要な情報はBashコマンドやMCPツール、ファイル読み込みで自分で取得して」と指示する方法です。何を渡すべきか自分でも分からないときに有効です

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

計画型は「書かないでください」よりplan modeで境界を引く

パターン4の「今は計画を立てるだけ」という一文は、お願いにすぎません。Claude Codeにはこの境界を仕組みで引くplan mode(プランモード)があります。plan modeではClaudeがファイルを読み、シェルコマンドで調べ、計画を書きますが、ソースは編集しません。通常は、計画を承認するまで編集がブロックされます。

セッションの開始時から入りたいときは、起動オプションで指定します。v2.1.289のclaude --helpでは、--permission-modeの選択肢が次のように表示されます。

claude --permission-mode plan

--permission-mode <mode>   Permission mode to use for the session
                           (choices: "acceptEdits", "auto",
                           "bypassPermissions", "manual",
                           "dontAsk", "plan")

プロジェクトの端末セッションで常にplan modeから始めたい場合は、.claude/settings.jsonのdefaultModeにplanを設定します。VS Code拡張が開始する会話はプロジェクト設定の開始モードを読まないため、そちらではclaudeCode.initialPermissionModeをユーザー設定に書きます。

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

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

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

共通する処方箋は、「何を」だけでなく「どう判定するか」までプロンプトに含めることです。Claudeは作業が終わったように見えた時点で止まります。実行できる確認手段がないと、間違いに気づくのは人間だけになります。

UIの変更なら、スクリーンショットを貼って「実装したら画面を撮って元の画像と比べ、違いを列挙して直して」と頼む形になります。ビルドが落ちているときは、エラーを貼ったうえで「原因を直し、エラーを抑え込まず、ビルドが通ることまで確認して」と添えます。

よくある質問

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

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

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

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

まとめ

依頼の前に「結果をどう判定するか」を1文で書けるかを確かめると、パターン選びで迷いにくくなります。判定の書き方が決まらない段階なら探索型、決まっていて変更が大きいなら計画型、というのが目安です。

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