Claude プロンプト — 精度が変わる 15 の型テンプレ

型 1: 3 ブロック構造 — 役割 + 背景 + 指示で初日からプロ品質

最初に身につけるべき基本形が「役割 → 背景 → 指示」の 3 ブロック構造です。Claude は会話履歴とシステムメッセージを総合して回答方針を決めるため、最初の入力で「誰として」「何を前提に」「何をしてほしい」が分離していると、的外れな回答が激減します。逆にこの 3 要素がひと塊になっていると、Claude は前提条件を推測する負荷が増え、出力のブレ幅が大きくなります。

【役割】 あなたは Python のシニアエンジニアです。

【背景】 私は機械学習初心者で、scikit-learn で
分類器を作っていますが、精度が 60% で止まっています。

【指示】 以下のコードを改善し、各変更の意図を
日本語で説明してください。

(ここにコード)

3 ブロック構造が効く理由

人間が新しい仕事を引き受けるときと同じく、LLM も「自分の立場(role)」「現状(context)」「タスク(task)」がはっきりしているほど高い精度を出します。とくに「背景」を省くと、Claude は無難な一般論を返しやすくなり、初心者向けの過剰な前置きや、上級者には冗長な説明が混入します。背景に「読者の習熟度・利用環境・制約条件」を 1〜2 行入れるだけで、回答の粒度が一段安定します。

型 2: XML タグで構造化 — <context> <code> <instructions> で長文の精度が跳ねる

Claude は XML タグの解釈に強い特性があります。これは Anthropic の学習データに XML 風の区切りが多く含まれていたためで、Markdown の見出しよりタグの方が「ここは引用、ここは命令、ここは出力例」と確実に伝わります。複数の長文資料を渡して指示する場合や、引用と指示を混在させたい場合は、XML タグの利用が公式にも推奨されています。

<context>
私は scikit-learn 初心者です。
</context>

<code>
from sklearn.ensemble import RandomForestClassifier
...
</code>

<instructions>
1. 現在のコードの問題点を指摘
2. 改善後のコードを提示
3. 変更理由を日本語で説明
</instructions>

よく使う XML タグの定番

<context> <instructions> <example> <document> <code> の 5 つを押さえておけば大半のユースケースを覆えます。複数の資料を渡すときは <documents> の中に <document index="1"> を並べる入れ子が定番で、Claude は引用元番号付きで回答を返せるようになります。なおタグ名は厳格な仕様ではなく独自命名でも動きますが、命名は一貫させ、開きタグと閉じタグを必ず対応させるのがコツです出典。

型 3: Few-shot — 正解例 2〜3 個で出力フォーマットを揃える

「こう書いてほしい」を文章で説明するより、正解例を 2〜3 個並べる方が圧倒的に効きます。これは Few-shot プロンプトと呼ばれ、出力フォーマット・トーン・語彙レベル・粒度のすべてを一度に伝えられる強力な手法です。0 例(zero-shot)で迷う領域でも、3 例を見せるだけで Claude は迷いなくフォーマットを踏襲します。

以下の形式で分類してください。

<example>
入力: "今日は最高の一日だった"
出力: {"sentiment": "positive", "score": 0.9}
</example>

<example>
入力: "また失敗した..."
出力: {"sentiment": "negative", "score": 0.2}
</example>

入力: "なんとか仕事が終わった"
出力:

例の数と質のバランス

Anthropic 公式は 3〜5 例を推奨しています。1 例だけだとパターン推定が弱く、10 例を超えると入力トークンが膨らみコストが増えます。例の中に「典型ケース」「境界ケース」「微妙なケース」を 1 件ずつ含めると、エッジケースでの判断力が一段上がります。逆に偏った例ばかり並べるとその偏りを学習されてしまうので、例の選定は出力品質を直接左右します。

型 4: Chain of Thought — 「ステップごとに考えて」で難問の正答率が上がる

複雑な推論タスクには「ステップごとに考えて、最後に結論を出してください」と明示するだけで精度が上がります出典。これを Chain of Thought(CoT、思考の連鎖)と呼び、数学・論理・複数ステップの計画立案・コードのバグ調査など、多段の推論が必要な場面で特に効果が出ます。即答を求めると Claude は最頻パターンに引っ張られた回答を返しがちですが、思考過程を書かせると途中で誤りに気付き、自己訂正が働きます。

思考と結論を分離する書き方

実装上は「<thinking> タグの中で考えてから、<answer> タグで最終回答を出してください」と指示する形が定番です。これにより、Claude が長く思考しても最終回答だけを抽出しやすくなります。Claude 4.X 系では Extended Thinking と呼ばれる拡張思考機能が API 側で利用でき、CoT を明示しなくても内部で深く推論する選択肢もありますが、軽量モデルや日常的な使い方では手書きの CoT 指示で十分な精度が得られます。

型 5: プレフィル — assistant 側の冒頭を仕込み、出力形式を強制する

API では messages の最後に assistant ロールの応答冒頭を仕込めます。{ で始まる JSON 出力を強制したいときの定番テクニックで、回答の先頭文字列を先回りして与えることで「ここから書き続けろ」と Claude に強制できます。前置きやコードフェンスをつけてくる回答を排除するうえでも極めて有効です。

# Python SDK 例
messages=[
  {"role": "user", "content": "上記をJSONで返して"},
  {"role": "assistant", "content": "{"}
]

これにより Claude は { の続きから書き始め、Markdown コードフェンスや前置きを省略します出典(注: Opus 4.7 ではプレフィル廃止のため Sonnet / Haiku で利用)。XML タグの開始タグ(<analysis>)や、Markdown 見出し(# 結論)を先頭に仕込むのも定番で、ダウンストリーム処理が必要な場面で出力フォーマットの破綻を未然に防げます。なお過剰な仕込みは逆に Claude を縛りすぎるので、最低限の起点(1〜10 文字程度)に留めるのが鉄則です。

型 6: 出力フォーマットの明示指定 — 「JSON で」「表で」「100 字以内で」

期待形式を 指示の最後に明記 する。曖昧な「整理して」より、「次の JSON スキーマで返してください」の方が安定します。プロンプトの末尾に書かれた指示は Claude の注意が最後に向かうため最も忠実に守られやすい性質があり、「最後にひと押しで形式を念押しする」のが実務上のコツです。

出力は以下の JSON スキーマに従ってください:
{
  "title": "string",
  "tags": ["string"],
  "summary": "string (100 字以内)"
}

用途別フォーマットの選び方

ダウンストリームのプログラム処理に渡すなら JSON、対人ドキュメントなら Markdown、複数候補を比較表示するなら Markdown 表(列名を明示する)が定番です。スキーマを与えるとフィールド漏れ・型違反が大幅に減りますが、フィールド数が多いと出力長が伸びコストも増えるため、本当に必要な項目だけに絞り込むのが鉄則です。後段でパースする想定なら、Tool Use(Function Calling)機能を併用するのがさらに堅牢な選択肢になります。

型 7: システムプロンプトでロールを永続化

API の system パラメータに「あなたは編集長です」等を記載すると、ユーザーメッセージごとに役割を再宣言する必要がなくなります。Claude.ai の Projects でも同様の効果が得られ、毎回プロンプト冒頭にコピペする手間が消えます。

system と user の使い分け

system には「立場・ルール・禁止事項・出力形式の前提」など会話全体で不変の取り決めを、user には「今回のタスク・対象データ」を入れます。両者を混ぜると、会話が長くなるにつれて Claude がどちらを優先すべきか曖昧になり、ルール違反が増える原因になります。さらに system プロンプトは Anthropic API のプロンプトキャッシュで再利用しやすく、長めのルール集を system に置いておくとレイテンシーとコストの両面でメリットがあります。

型 8: ロール付与 — 「シニアエンジニア」「校閲者」で文体と粒度が揃う

役割を具体的に指定するほど出力品質が上がります。「専門家」より「scikit-learn を 5 年使うシニア ML エンジニア」の方が的確で、文体・前提知識・参照する技術用語の粒度が一気に揃います。役割を曖昧にしておくと、Claude は誰に向けて何を書くかを推定しなければならず、無難で当たり障りのない説明に流れがちです。

役割 + 読者像で精度を倍にする

「あなたは○○です」だけでなく「読者は△△です」とセットで指定すると、説明の深さが安定します。たとえば「あなたはシニア ML エンジニア。読者は Python は書けるが機械学習未経験のバックエンドエンジニア」と書けば、用語の前提知識・図示の必要性・コード例の量が一意に決まります。仕事の現場で同僚に依頼するときと同じ感覚で、立場と相手の両方を文章にしておくのがコツです。

型 9: 制約条件の明示 — 「ただし〜禁止」「最大 N 字」「平易な日本語で」

肯定的な指示と一緒に 禁止条項・上限・対象読者 を併記すると暴走が止まります。Claude は親切心が強いため、放っておくと前置きや注釈、補足の例示などを足してきます。逆にいえば、書いてはいけない要素・出してほしくない情報・守るべき長さを明示すると、無駄な拡張がほぼ消えます。

制約は 4 軸で書き分ける

実用では「長さ(最大 N 字 / N 段落)」「語彙(中学生でもわかる言葉で / 専門用語禁止)」「除外(コード以外を書かない / 言い訳を書かない)」「読者像(IT 部門のマネージャー向け)」の 4 軸を意識すると過不足なく書けます。とくに長さの指定は曖昧にせず、「800 字以内」「5 行以内」「3 つだけ」のように数値化することで、Claude が出力途中で長さを自己制御できるようになります。

型 10: Step-back プロンプティング — 抽象的な原則から考えさせる

複雑な問題で「先に上位概念・原則を 1 行で書いてから、具体策を述べてください」と指示すると、検討の筋道が整います出典。これを Step-back プロンプティングと呼び、いきなり具体例を並べる前に、前提となる原則・分類・判断軸を言語化させることで、表層的なテンプレ回答から抜け出せます。

Step-back と CoT の使い分け

Chain of Thought が「順を追って解く」のに対し、Step-back は「ひとつ抽象度を上げて視点を取る」アプローチです。設計判断や戦略立案、要件整理のような「正解が複数ある領域」では Step-back の方が深い検討につながります。逆に四則演算や手順固定のロジック検証では、Step-back を入れすぎると遠回りになりがちです。タスク特性に合わせて、推論の深さと抽象度を切り替えてあげるのが上級者の使い方です。

型 11: Self-critique — 「自分の回答を批判的に見直して」で品質が一段上がる

最初の回答後に「この回答の弱点を 3 つ指摘し、改善版を出してください」と続けると、品質が大きく上がります。1 回のターンで自己レビューを内包させるのが coding 系で特に有効で、最初に出した素案にありがちな抜け漏れ・冗長さ・前提誤りを Claude 自身がチェックして直してくれます。

Self-critique が効くタスクと効かないタスク

文章の校正・コードのリファクタ・設計案の検討のように「評価基準が明確で、見直すと改善余地がある」タスクでは抜群の効果が出ます。一方、事実調査(○○は何年に起きたか等)では、Claude 自身が誤った情報をもとに「自信のある」自己評価を返すことがあるため、Self-critique だけで信頼性を担保するのは危険です。事実系は別途一次情報で検証する、という運用と組み合わせるのが堅実です。

型 12: 温度(temperature)の使い分け — 0 で決定的、0.7〜1.0 で創造的

API で temperature を制御。事実回答・コード生成は 0〜0.3、ブレスト・キャッチコピーは 0.7〜1.0。Claude.ai では Temperature 設定はないため、プロンプトで「複数案を出して」と明示する。0 に近づけるほど確率の高いトークンを選び続けるので、同じ入力に対する回答が再現しやすくなります。逆に 1 に近づけるほど確率分布の裾を広く拾うため、表現にバリエーションが生まれます。

温度設計の実務パターン

業務向けには「分類・抽出・要約・コード生成」を 0〜0.2、企画・コピー・ネーミングを 0.7〜0.9 に設定する二段構成が定番です。top_p は通常デフォルト(1.0)で問題なく、まず温度だけを動かすのが鉄則。ブレストで複数案を集めたい場合は、同じプロンプトを温度 0.9 で 5 回叩き、出てきた案を 0.0 のもう 1 リクエストで集約整理させる「発散 → 収束 2 段プロンプト」が品質と再現性のバランスを取りやすい構成です。

型 13: max_tokens / 出力長の制御 — 暴走を防ぐ最後の砦

長文タスクでは max_tokens を必ず設定。「冗長な前置きをカットし、本題のみ 800 字以内で」と本文側でも明記する。max_tokens は API 側でハードリミットを掛けるための保険で、無限ループや想定外の長文出力でコストが暴走するリスクを防ぐ最後の砦になります。

プロンプト内指示と API パラメータの二重防御

実務では「プロンプト内で目標長を提示(例: 800 字以内)」と「API の max_tokens で物理上限を設定(例: 2000 トークン)」をセットで使うのが定番です。前者だけだと Claude が指示を緩く解釈する余地があり、後者だけだと出力が途中で切られてしまいます。両方を組み合わせると、目標長付近で自然に終わり、何かあっても物理的に切れる二重防御になります。Claude モデルごとに最大出力長の上限が違うため、Sonnet・Haiku・Opus それぞれの公式仕様を必ず確認しておきましょう。

型 14: 否定形ではなく肯定形で書く — 「するな」より「こうしろ」

「コードフェンスを使うな」より「プレーンテキストで返してください」の方が安定します。Claude を含む LLM は 肯定的な指示の方が従いやすい出典。否定形の指示は「禁止された行為」を一度脳内でイメージさせるため、かえって禁止対象が出力に紛れ込むことがあります。

否定形を肯定形に書き換える例

「英語で答えるな → 必ず日本語で答えてください」「コードフェンスを使うな → プレーンテキストの 1 行で返してください」「長く書くな → 200 字以内に要点だけまとめてください」のように、禁止条項はほぼ常に肯定形に翻訳できます。どうしても禁止を伝える必要があるときは「○○の場合は△△と返してください(他のフォーマットでは返さない)」のように、肯定的な代替指示の後に短く注記する形にすると、Claude が混乱しにくくなります。

型 15: 「わからない」を許容する — 幻覚を抑える最強の一文

「情報がない場合は『わかりません』と答えてください」と明記すると、根拠のない推測が大幅に減ります。事実調査・要約タスクで必須の一行で、たった 1 文加えるだけで幻覚(hallucination)を大きく抑制できます。LLM は本来「最もそれらしい続き」を生成する仕組みのため、「わからない」と答えること自体を許可しないと、知らないことでも自信を持って書いてしまう傾向があります。

引用必須・出典必須の追加指示

事実精度をさらに高めたい場合は、「与えられた <document> 内の記述からのみ回答し、書かれていない事項は『資料に記述なし』と返答してください」のように出典を明示的に縛ります。Claude が外部知識を補完しないようにすることで、社内ドキュメントや契約書、製品仕様書など「ソースを限定したい用途」での信頼性が劇的に上がります。回答の信頼性を最重視するなら、型 15 と型 6(出力フォーマット指定)を組み合わせ、出典 ID と回答テキストをセットで JSON 出力させる構成が王道です。

出典(一次情報)

本記事の作成に直接参照した一次情報源は以下の通りです。Anthropic 公式ドキュメントは継続的に更新されるため、最新の正確な情報は各リンク先で必ずご確認ください。プロンプト設計のベストプラクティスはモデル世代ごとに微妙に変化することがあり、Sonnet 4.6 / Opus 4.7 / Haiku 4.5 など利用するモデルに応じて公式ガイドを当たるのが堅実です。

• Anthropic: Prompt engineering overview
• Anthropic: Use XML tags
• Anthropic: Chain of Thought
• Anthropic: Prefill Claude's response
• Anthropic: Be clear, direct, and detailed
• Anthropic: Use examples (multishot prompting)
• Anthropic: Giving Claude a role with a system prompt