プロンプトパターン集

前編の「プロンプトの基本原則」では、明確さ・具体性・文脈提供という3つの基本を学びました。この記事では一歩進んで、特定の状況で繰り返し使える「プロンプトパターン」を紹介します。

パターンとは「型」のことです。しかし、ここで大切なのは テンプレートをコピペすることではなく、「なぜその型が機能するのか」を理解すること です。考え方を理解すれば、自分のタスクに合わせて自由に組み合わせ・応用できるようになります。

パターンの読み方

この記事では、各パターンを以下の統一フォーマットで解説します。

項目	内容
いつ使う	このパターンが特に有効な場面
構造	プロンプトの組み立て方
例	ビジネス寄り・開発寄りの具体的なプロンプト例
注意点	よくある失敗とその対策

7つのパターンを紹介しますが、最終セクションで「組み合わせ」の実践例も載せています。まず一通り読んだ後、自分のタスクに近い組み合わせを試してみてください。

パターン 1: Chain of Thought（段階的思考）

いつ使う

数値計算や論理推論が必要なとき
複数の要素を比較・評価するとき
答えよりも「なぜその答えなのか」のプロセスが重要なとき

Chain of Thought（CoT）は、Claude に「考える手順を明示させる」パターンです。人間でも、難しい問題を「まず〇〇を確認して、次に〇〇を検討して...」と声に出しながら考えると整理できますが、それと同じことを Claude に促します。

構造

最もシンプルな方法は、プロンプトの末尾に「ステップごとに考えてください」という一文を加えることです。

[タスクの説明]

ステップごとに考えを整理しながら答えてください。

より明示的にする場合は、考えるべき手順を自分で指定します。

[タスクの説明]

以下の順で検討してください：
1. まず〇〇を確認する
2. 次に〇〇を評価する
3. 最後に結論を出す

例

ビジネス寄り（予算の妥当性検討）:

以下の新規事業の予算案を評価してください。

事業名: 社内AI活用支援サービス
初期投資: 500万円
年間運用費: 120万円
想定収益: 年間200万円（3年目から）

ステップごとに考えを整理しながら評価してください：
1. 投資回収期間の計算
2. リスク要因の洗い出し
3. 類似事業との比較
4. 総合的な判断

開発寄り（コードのバグ調査）:

以下のPython関数が期待通りに動作しない原因を特定してください。

```python
def calculate_average(numbers):
    total = 0
    for n in numbers:
        total += n
    return total / len(numbers)
```

入力: [1, 2, 3]
期待する出力: 2.0
実際の出力: 2.0（一見正しいが、空リストを渡すとクラッシュする）

考えられるエッジケースをすべて洗い出してから、修正案を提示してください。

注意点

よくある失敗: 「ステップごとに」と言うだけで満足してしまう

「ステップごとに考えてください」という指示は万能ではありません。複雑なタスクでは、考えるべき観点を自分で指定したほうが精度が上がります。「何を考えてほしいか」をあらかじめ整理しておくことが、このパターンの真の使い方です。

パターン 2: Few-shot（具体例の提示）

いつ使う

出力のフォーマットを厳密に指定したいとき
文体や表現のトーンを揃えたいとき
「言葉では説明しにくいが、見ればわかる」品質基準があるとき

Few-shot（少数ショット）は、「こういう入力にはこういう出力を」という具体例を複数示すことで、Claude が期待するパターンを学習するアプローチです。料理のレシピと同様に、材料（入力）と完成品（出力）を見せれば、同じ調理法で新しい料理を作ってもらえます。

構造

以下の例を参考に、同じ形式で[タスク]を実施してください。

---例1---
入力: [入力例1]
出力: [出力例1]

---例2---
入力: [入力例2]
出力: [出力例2]

---ここから本番---
入力: [実際の入力]
出力:

例の数は2〜5個が適切です。1個だと「たまたまその形式になった」と判断される可能性があります。5個を超えると余分なトークンを消費する割に改善幅が小さくなります。

例

ビジネス寄り（会議メモの要約）:

以下の形式で会議メモを要約してください。

---例1---
入力:
「本日の会議では、Q3の販売実績について議論しました。田中部長から、
目標比120%達成との報告がありました。ただし地方の数字が弱く、
来期の施策として地方営業強化を検討することになりました。」

出力:
【決定事項】地方営業強化施策を来期に向けて検討する
【共有事項】Q3販売実績：目標比120%達成。地方拠点が課題
【次のアクション】なし

---例2---
入力:
「エンジニアチームから、新機能の開発が来週完了予定との報告がありました。
リリースにあたってQAチームとの調整が必要で、山田さんが窓口になることが決まりました。
リリース日は未定です。」

出力:
【決定事項】QA調整の窓口：山田さん
【共有事項】新機能開発、来週完了予定。リリース日は調整中
【次のアクション】山田さん：QAチームへの連絡

---ここから本番---
入力:
「本日は予算会議でした。来期の広告費について議論し、前期比10%増の1,100万円で
仮承認されました。ただし役員会での最終承認が必要です。鈴木さんが来週の役員会で
プレゼンを担当します。」

出力:

開発寄り（コミットメッセージの生成）:

以下の形式でコミットメッセージを生成してください。

---例1---
変更内容: ユーザーが404エラーのページで「ホームに戻る」ボタンを押せなかった
出力: fix: 404ページのCTAボタンのクリックイベントが未登録だった問題を修正

---例2---
変更内容: ユーザープロフィール画面に生年月日フィールドを追加した
出力: feat: プロフィール画面に生年月日の入力・表示機能を追加

---例3---
変更内容: APIのレスポンス速度が遅かったのでキャッシュを入れた
出力: perf: ユーザー一覧APIにRedisキャッシュを導入し応答速度を改善

---ここから本番---
変更内容: パスワードリセット機能が特殊文字を含むメールアドレスでエラーになっていた
出力:

注意点

よくある失敗: 例が少なすぎる、または偏っている

例が1〜2個しかない場合や、似たパターンの例ばかり提示すると、Claude がパターンを正しく一般化できません。バリエーションのある例を3〜5個用意しましょう。また例が長すぎるとプロンプト全体が肥大化するので、できるだけ簡潔な例を選びます。

パターン 3: XML タグ構造化

いつ使う

プロンプトが長くなってきた（300文字以上が目安）
「指示」「背景情報」「入力データ」が混在している
Claude に特定の形式で出力させたい

XML タグとは <instructions> や <context> のような山かっこで囲んだ目印のことです（実際に XML を知らなくても問題ありません）。Claude はこのタグを「区切り記号」として認識し、プロンプトの各部分の役割を把握しやすくなります。

Claudeは特にXMLタグへの対応力が高く、タグを使うだけで回答の精度が目に見えて改善することがあります。

構造

<instructions>
[Claudeへの指示・依頼内容]
</instructions>

<context>
[背景情報・前提条件]
</context>

<input>
[処理してほしいデータや文章]
</input>

<output_format>
[出力形式の指定]
</output_format>

タグ名は自由に決められます。上記はあくまで一例です。大切なのは「何がどこにあるか」を Claude が迷わないように区切ることです。

例

ビジネス寄り（顧客メールへの返信文生成）:

<instructions>
以下の顧客からのクレームメールに対する返信文を作成してください。
謝罪、原因の説明、今後の対応策の3つを含めてください。
丁寧なビジネス文体で、300文字以内にまとめてください。
</instructions>

<context>
私たちはECサイトを運営しています。
今回のトラブルの原因：物流会社のシステム障害により配送が3日遅延した。
対応策：次回購入時に使える500円クーポンを発行する予定。
</context>

<customer_email>
先日注文した商品がまだ届きません。到着予定日を3日過ぎているのですが、
どうなっているのでしょうか。急ぎで必要だったのに困っています。
</customer_email>

開発寄り（コードレビューの自動化）:

<instructions>
以下のコードをレビューしてください。
以下の観点で問題点を指摘してください：
1. バグ・潜在的なエラー
2. パフォーマンス上の懸念
3. コーディング規約・可読性
各問題には severity（high/medium/low）を付けてください。
</instructions>

<code_language>Python 3.11</code_language>

<coding_standards>
- 関数は1つの責任のみ持つ
- 変数名はsnake_case
- 型ヒントを必ず付ける
</coding_standards>

<code>
def get_user_data(id):
    conn = sqlite3.connect('users.db')
    cursor = conn.cursor()
    query = f"SELECT * FROM users WHERE id = {id}"
    cursor.execute(query)
    return cursor.fetchall()
</code>

注意点

よくある失敗: タグ名が曖昧または矛盾している

<data> や <info> のような汎用的すぎるタグ名は、Claude が内容を推測しにくくなります。<customer_complaint> や <reference_document> のように、中身を一言で表すタグ名を使いましょう。また、閉じタグ（</instructions>）を忘れないよう注意してください。

パターン 4: ペルソナ / ロール設定

いつ使う

特定の専門家視点の意見・アドバイスが欲しいとき
出力のトーン・文体を特定の方向に揃えたいとき
複数の立場からの検討が必要なとき

ロール設定は「あなたは〇〇です」と Claude に役割を与えるパターンです。ロールを与えることで、Claude は関連する知識・視点・語彙を優先的に使うようになります。

重要なのは、ロール設定は「人格を変える」のではなく「フォーカスを当てる」もの という理解です。「あなたは厳しい批評家です」と言っても Claude が不親切になるわけではなく、批評的な観点を前面に出した回答をしてくれます。

構造

あなたは[ロール]です。[ロールの具体的な背景・経験・特徴を補足]。

[タスク]

補足が重要です。「あなたはマーケターです」より「あなたは10年以上BtoB SaaS のマーケティングを担当してきたプロです」のほうが、より具体的で適切な回答を得られます。

例

ビジネス寄り（プレゼン資料のレビュー）:

あなたは投資家向けのピッチデックを何百件もレビューしてきた
ベンチャーキャピタリストです。

以下のビジネスアイデアのサマリーを読んで、
「このアイデアに投資する/しない理由」を3点ずつ挙げてください。
忖度なしに厳しく評価してください。

[ビジネスアイデアのサマリーをここに貼る]

開発寄り（セキュリティ診断）:

あなたはWebアプリケーションのセキュリティ診断の専門家（ペネトレーションテスター）です。
OWASPのトップ10を熟知しており、脆弱性を見つけることが得意です。

以下のWebアプリの仕様を読んで、セキュリティ上のリスクを洗い出してください。
深刻度（Critical/High/Medium/Low）と推奨される対策もセットで記載してください。

[アプリ仕様をここに貼る]

複数のロールを使った対立的検討（メリット・デメリット分析）:

以下の新しい社内制度案について、2つの立場からそれぞれ意見を述べてください。

制度案: 週1回のリモートワーク全社員への導入

【推進派の立場として】
この制度の賛成理由を3点、具体的な効果予測とともに述べてください。

【慎重派の立場として】
この制度の懸念点を3点、具体的なリスクとともに述べてください。

最後に、中立的な立場として総合的な判断を述べてください。

注意点

よくある失敗: ロールが強すぎて事実確認が疎かになる

「あなたはその道30年のプロです」のような強いロール設定は、Claude が自信を持って回答する一方、不確かな情報でも断言してしまうリスクがあります。専門的な回答が必要な場合でも、「不確かな点は不確かと明示してください」という指示を添えることをお勧めします。

パターン 5: 分割と征服

いつ使う

タスクが複雑で、一度に処理するには情報が多すぎるとき
出力が長くなりすぎて品質が落ちるとき
各ステップの途中結果を確認・修正しながら進めたいとき

分割と征服（Divide and Conquer）は、大きなタスクを小さなサブタスクに分解して、順番に処理させるパターンです。人間が大きなプロジェクトをマイルストーンに分けるのと同じ発想です。

Claude は一度に扱う情報が増えるほど、後半の精度が落ちる傾向があります。分割することで各ステップの品質を保ちつつ、最終的に高品質な成果物を得られます。

構造

ステップ1: [最初のサブタスク]
（Claudeの出力を確認）

ステップ2: 上の結果をもとに、[次のサブタスク]
（Claudeの出力を確認）

ステップ3: これまでの内容を踏まえて、[最終タスク]

あるいは、プロンプト内でステップを明示する方法もあります：

このタスクを以下のステップで処理してください。
各ステップの完了後、次のステップを開始する前に私に確認を求めてください。

ステップ1: [サブタスク1]
ステップ2: [サブタスク2]
ステップ3: [サブタスク3]

例

ビジネス寄り（市場調査レポートの作成）:

まずステップ1を依頼します。

新しいオンライン英会話サービスの市場調査をしています。
まず最初に、この市場の主要プレイヤー（競合他社）を5社挙げ、
それぞれの特徴を簡潔にまとめてください。
次のステップ（価格比較・強み弱み分析）に進む前に、
このリストを確認させてください。

Claudeの回答を確認し、修正が必要なら調整した上でステップ2へ。

ありがとうございます。
では次に、先ほど挙げた5社の料金プランを比較し、
価格帯・提供価値の観点で整理してください。

開発寄り（新機能の設計と実装）:

ユーザー認証機能を実装したいと思います。
以下の順で進めてください。各ステップが終わったら確認を求めてください。

ステップ1: 必要なAPIエンドポイントの設計（POST /auth/register, POST /auth/login など）
ステップ2: データベーススキーマの設計
ステップ3: 各エンドポイントのPseudoコード（疑似コード）の作成
ステップ4: セキュリティ上の考慮点のレビュー

使用スタック: Node.js + Express + PostgreSQL

注意点

よくある失敗: 細かく分割しすぎてセッションが終わらない

タスクを5段階以上に分割すると、会話が長くなりすぎて途中で方向性を見失うことがあります。原則として、分割は2〜4段階が最適です。それ以上になりそうなら、大きなステップをまとめるか、別の会話セッションで続けることを検討してください。

パターン 6: 自己検証

いつ使う

重要な成果物の品質を高めたいとき
最初の回答が十分かどうか自信が持てないとき
エラーや見落としを減らしたいとき

自己検証は、Claude に自分の出力を「もう一度見直させる」パターンです。人間でも、文章を書いた後に読み返すと誤字や論理の穴に気づくことがあります。Claude も同様に、一度出力した内容を別の視点から確認させることで品質が上がります。

構造

方法は大きく2つあります。

方法1: 一度の回答内で検証も依頼する

[タスク]

回答を生成した後、以下の観点で自分の回答を検証し、
問題があれば修正したバージョンを出力してください：
- [検証観点1]
- [検証観点2]

方法2: 先に回答させてから検証を依頼する

（最初のメッセージ）
[タスク]

（Claudeの回答を受けて）
ありがとうございます。その回答を[観点]の視点から
批判的にレビューして、改善点があれば修正版を出力してください。

例

ビジネス寄り（提案書のレビュー）:

以下の提案書の概要を書きました。
まず内容を読んで改善点を5点挙げてください。
次に、その改善点を反映した改訂版を書いてください。

【改善の観点】
- 相手（経営層）にとって何が嬉しいのかが伝わるか
- 数字・根拠が不足していないか
- 反論されそうな点を先回りして答えているか

---
[提案書の文章をここに貼る]

開発寄り（テストケースのレビュー）:

以下の関数のユニットテストを書いてください。

```python
def divide(a: float, b: float) -> float:
    return a / b
```

テストを書き終わったら、「テストが網羅できていないエッジケース」が
ないかを自分で確認してください。
見落としがあれば追加のテストケースを加えてください。

注意点

よくある失敗: 「何でも検証して」という曖昧な指示

検証の観点を指定しないと、表面的なチェックだけで終わることがあります。「論理的矛盾がないか」「数字の根拠が示されているか」「読者が理解しやすいか」など、具体的な観点を明示することで検証の深さが変わります。

パターン 7: マルチターン戦略

いつ使う

長い会話セッションで文脈が失われてきたとき
複数の話題が混在してきたとき
前の会話の内容を参照しながら次のタスクを進めるとき

マルチターン戦略は、複数回のやり取り（ターン）を通じた会話の流れをデザインするパターンです。単発のやり取りではなく、「会話全体をどう設計するか」という視点が必要になります。

構造

文脈の確認（長い会話の途中で）:

これまでの会話で合意した内容を箇条書きでまとめてください。
特に、決定した仕様と未解決の課題を分けて整理してください。

文脈の引き継ぎ（新しいセッションを始めるとき）:

前回の会話の続きです。
以下の前提条件を踏まえて作業を続けてください：

[前のセッションの要点を箇条書きでペースト]

会話の方向修正:

少し方向を変えたいと思います。
今まで話していた[テーマA]については一旦置いておいて、
[テーマB]にフォーカスしましょう。

例

ビジネス寄り（複数回の会議後の議事録作成）:

第1ターン：情報の収集

今週の定例会議のメモを共有します。
まずこのメモから「決定事項」「課題」「次のアクション」を
それぞれ抽出して箇条書きにしてください。

[会議メモをここに貼る]

第2ターン：加工と整形

ありがとうございます。
その整理をもとに、全員に送る議事録メールの文章を作成してください。
件名も提案してください。

開発寄り（設計レビューの段階的進行）:

第1ターン：大きな方向性の確認

新しいECサイトのバックエンド設計を相談したいです。
まず、マイクロサービスとモノリシック構成の
メリット・デメリットを比較してください。
私たちのチーム規模（5人）と想定トラフィック（月10万PV）を前提にしてください。

第2ターン：詳細設計

モノリシック構成で進めることにしました。
では次に、この規模のECサイトに必要な主要なAPIエンドポイントの
一覧を設計してください。

注意点

よくある失敗: 一つの会話に詰め込みすぎる

Claude は会話が長くなるほど、初期の文脈を参照しにくくなります（これは「コンテキストウィンドウ」の制限によるものです）。一つのトピックが完結したら新しい会話を始めるか、定期的に「これまでの合意事項を整理してください」と確認することをお勧めします。

パターンの組み合わせ

各パターンは単独でも使えますが、組み合わせることで真の威力を発揮します。

組み合わせ例 1: 競合分析レポートの作成

XML タグ構造化 + Chain of Thought + 自己検証を組み合わせています。

<instructions>
競合他社の分析レポートを作成してください。
以下の観点を順番に検討して、構造化されたレポートにまとめてください：
1. 製品・サービスの特徴比較
2. 価格帯と対象顧客層
3. マーケティング戦略の傾向
4. 自社との差別化ポイント

レポートを書き終えたら、「見落とした観点がないか」「根拠が不足している主張がないか」を
自分で確認して、必要に応じて加筆してください。
</instructions>

<context>
私たちは中小企業向けのプロジェクト管理SaaSを提供しています。
主な顧客: 従業員50〜200名の製造業・サービス業
価格帯: 月額5,000〜30,000円（チーム規模に応じて）
</context>

<competitors>
- Asana（米国発、大企業向けが強い）
- Backlog（日本語対応、エンジニア向け）
- Notion（ドキュメント管理寄り）
</competitors>

組み合わせ例 2: コードのバグ修正と品質改善

ロール設定 + Chain of Thought + 分割と征服を組み合わせています。

あなたはコードの品質改善を専門とするシニアエンジニアです。
以下の関数について、2つのフェーズに分けてレビューしてください。

フェーズ1: バグと潜在的なエラーの特定
- 現在のコードで問題になりうる箇所をすべて列挙
- 各問題の深刻度（Critical/High/Medium）を付ける
- フェーズ1が終わったら私に確認を求めてください

フェーズ2: リファクタリング提案
- フェーズ1で合意した問題を修正した改訂版コードを提示
- 変更箇所とその理由をコメントで記載

```python
def send_notification(user_id, message, type):
    user = db.query(f"SELECT * FROM users WHERE id={user_id}")
    if user.email_enabled == True:
        send_email(user.email, message)
    if type == "urgent":
        send_sms(user.phone, message)
    log.write(f"{user_id}: {message}")
```

組み合わせ例 3: ビジネス企画書の作成（Few-shot + 分割と征服）

新サービスの企画書を作成します。
以下の例と同じ構成で、各セクションを1つずつ作成してください。

---構成の例（既存の企画書より）---
## サービス概要
[3行以内の要約。「誰の、どんな問題を、どう解決するか」を含める]

## 市場規模と機会
[数字を使った市場規模、成長率、参入タイミングの根拠]

## 競合との差別化
[主要競合3社との比較表 + 自社の独自価値]

---現在のサービス情報---
名称: WorkLog（仮）
コンセプト: 中小企業の現場作業者向け日報アプリ
ターゲット: 建設業・製造業の現場監督（スマホのみ使用）
強み: 音声入力対応、オフライン動作可能

まず「サービス概要」セクションを作成してください。
確認後、次のセクションに進みます。

次のステップ

パターンを理解したら、次は「どこに・どのタイミングで指示を書くか」というシステムレベルの設計に進みましょう。

ビジネス活用事例 — 業務での具体的な Claude の活用パターンを学ぶ
API 活用ガイド — API を使ったシステム連携やプロンプト設計を深掘りする
Claude Code ワークフロー — 繰り返し作業を Claude Code で自動化するフロー設計
プロンプトの基本原則 — このページの前編。明確さ・具体性・文脈提供の3原則