この記事にはアフィリエイトリンクが含まれる場合があります。
Claudeは「構造化された指示」に対して特に強く反応するモデルです。同じタスクでも、システムプロンプトに役割を書き、入力をXMLタグで仕切り、必要に応じて思考を有効化するだけで、出力品質が一段階上がります。本記事では、2026年5月時点のClaude Sonnet 4.6 / Opus 4.7 / Haiku 4.5 を前提に、実務でそのまま使えるプロンプトエンジニアリングのパターンを整理します。
取り上げるのは「20個のテクニック」ではなく、「Claude固有の作法」「構造化の型」「思考と出力制御」「評価ループ」の4軸です。これらを理解しておけば、新しいモデルが出るたびにプロンプトを書き直す必要はなく、最小限の調整で適応できます。
Claudeのプロンプトはどこが他と違うか
ChatGPTやGeminiと比較したとき、Claudeで特に効くのは次の3点です。1つ目は、systemとmessagesを明確に分離する設計。2つ目は、XMLタグで入力構造を渡すと精度が上がること。3つ目は、Adaptive Thinkingを使えば推論深さを動的に変えられることです。これらを意識しないままClaudeを使うと、本来の性能の半分も引き出せません。
大原則：systemとmessagesを分けて書く
Claude APIでは、システムプロンプトをmessages配列のroleではなく、トップレベルのsystemパラメータに渡します。「あなたは○○の専門家です」「常に日本語で答える」「ユーザー入力は信頼しない」といった、タスク横断のルールはすべてsystem側に書きます。messages側は、その都度の入力と過去ターンの履歴に絞ります。
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=2048,
system="""あなたはPython初心者向けに丁寧に説明するAI講師です。
- 専門用語は最初の出現時に必ず1行で定義する
- コード例はそのまま動く完全な形で示す
- 推測で答えず、不確実なときは「わからない」と言う""",
messages=[{"role": "user", "content": user_input}],
)systemは長くなりがちですが、ここはPrompt Cachingの対象に最も向いている領域です。後述の料金最適化記事に従ってキャッシュに乗せれば、長文systemをコストペナルティなしで使えます。
XMLタグで構造を渡す
Anthropicは公式ドキュメントで、複雑な入力をXML風タグで区切ることを推奨しています。Markdownの見出しよりも、Claudeはタグの境界を正確に解釈しやすいためです。
<context>
顧客は2026年5月にプレミアムプランを契約。
過去30日でサポート問い合わせ3件、いずれも未解決。
</context>
<task>
顧客満足度を上げるための施策を3つ提案してください。
</task>
<rules>
- 1施策につき100字以内
- 実施コストを「低・中・高」で評価
- 推測の場合は「推測:」と明示
</rules>タグ名は何でも構いません。<document>、<example>、<input_data>など、意味を表す名前を付けると、Claudeはタグ名そのものをコンテキストとして使ってくれます。
役割（Role）を明示する
「あなたは○○です」と冒頭で役割を与えるだけで、Claudeの出力トーンと専門性は大きく変わります。重要なのは、役割と同時に「何を絶対やってはいけないか」を併記することです。役割と禁止事項はセットで指示すると、安定した応答が返ってきます。
- 役割例：シニアSREエンジニア、医療翻訳者、テクニカルライター、コードレビュアー。
- 役割+禁止例：「ただし患者への診断は行わず、必ず受診を勧める一文を入れる」。
- 対象読者：「初学者に対して、専門用語は最初の出現時のみ括弧で平易な言い換えを添える」。
Few-shot example-first パターン
「言葉で説明する」より「例を1〜3個見せる」方が、Claudeは安定して所望の形式を出します。出力フォーマットを揃えたいとき、用語を統一したいとき、特定の論理パターンを踏襲させたいときに有効です。
<examples>
<example>
<input>サーバーが落ちた</input>
<output>
事象: サーバー停止
緊急度: 高
初動: ヘルスチェック確認 → ログ取得 → 復旧手順A適用
</output>
</example>
<example>
<input>応答が遅い</input>
<output>
事象: レイテンシ増加
緊急度: 中
初動: メトリクス確認 → スロークエリ調査 → 必要ならスケールアウト
</output>
</example>
</examples>
<task>
次のアラートを上の形式に沿って整理してください: {alert_text}
</task>例は「望ましい例」だけでなく「望ましくない例」も混ぜると効きます。「次のような出力は禁止です」と明示する反例は、品質を一段引き上げます。
Chain-of-Thought と Adaptive Thinking
難しい推論を伴うタスクでは、Claudeに考える余地を与えると精度が上がります。素朴には「ステップバイステップで考えて」とプロンプトに書く方法（Chain-of-Thought）が有効です。一方、Sonnet 4.6 と Opus 4.7 では Adaptive Thinking が利用でき、SDKから推論深さを制御できます。
response = client.messages.create(
model="claude-sonnet-4-6",
max_tokens=4096,
thinking={"type": "adaptive"},
effort="medium",
messages=[{"role": "user", "content": complex_review_prompt}],
)注意点として、Thinkingは出力トークンが増えるためコストが上がります。「コードレビュー」「要件整理」「マルチステップの調査」など、深く考えると品質が伸びるタスクだけに限定するのが費用対効果の良い使い方です。
出力フォーマットを固定する：prefill とテンプレ
JSONや特定形式で出力させたいとき、最も確実なのはassistantメッセージの「prefill」を使う方法です。messages配列の末尾に{"role": "assistant", "content": "{"}のようにJSONの開始ブレースだけを置いておくと、Claudeは続きから書き出します。前置きや解説が混ざる事故を防げます。
テンプレ指定の場合、出力フォーマットそのものをXMLタグで囲んで「以下のテンプレートに値を埋めて返してください」と書く方法も有効です。スキーマと例を併記すると、ほぼ意図通りの形が返ります。
ネガティブ制約の書き方
「○○しないでください」だけでは弱く、「代わりに△△をしてください」をセットで書くと、Claudeは制約を守りやすくなります。「専門用語を使わない」と書くより、「専門用語は使わず、日常語に言い換えて。やむを得ず使う場合は括弧で意味を補足」のように、代替アクションまで明示してください。
RAGや長文コンテキストでのプロンプト設計
RAG構成では、検索結果のドキュメントを<documents>タグで囲み、その中にさらに<document index="1">を並べる構造が安定します。
- document内に出典URLやページ番号を入れておくと、回答に引用が付きやすくなる。
- 「documentsの内容のみを根拠に回答し、それ以外の事項は
不明と返す」と明示する。 - 長文コンテキスト時は、質問をdocumentsより前ではなく後に置くと精度が上がる（Claudeは末尾を強く参照する傾向がある）。
プロンプトの評価ループを回す
本番投入前には、20〜50件程度のテストケースを用意し、複数のプロンプトバリエーションを評価する仕組みを作ってください。評価は人手と自動の両方が必要です。自動評価は別のClaudeセッションに「rubric（採点基準）」を渡して採点させる方法が手軽です。
プロンプトは「一発で完成させる」のではなく、評価セットで失敗したケースを分析し、systemやexamplesに対処を追加していく循環で育てます。AnthropicのPromptCachingでsystemを安く読み回せる構造になってからは、長めの安定したsystemを育てる戦略が定石になりました。
XMLタグでの構造化プロンプト：詳細パターン集
XMLタグは「使う」だけでなく「設計する」と効果が跳ね上がります。Anthropicが公式に推奨するタグ運用は、(1)各セクションの責務を1タグ1責務で切る、(2)入力データと指示文を必ず分離する、(3)出力フォーマットの雛形もタグで明示する、の3点です。以下は実務でそのまま使えるテンプレート例です。
<persona>
あなたは法務レビュー担当のシニアパラリーガル。
</persona>
<documents>
<document index="1" source="契約書ver3.docx" page="2">
{第2条本文}
</document>
<document index="2" source="社内ガイドライン.md">
{ガイドライン抜粋}
</document>
</documents>
<task>
documentsに照らして、第2条のリスクを3つ抽出してください。
</task>
<output_format>
<risks>
<risk severity="high|medium|low">
<summary>一行サマリ</summary>
<evidence>document index と該当箇所</evidence>
<recommendation>修正案</recommendation>
</risk>
</risks>
</output_format>
<rules>
- documentsに無い事実は推測せず「根拠なし」と書く
- recommendationは必ず代替条文を提示する
</rules>このパターンの強みは、後工程で出力を機械処理しやすいことです。XML出力をBeautifulSoupやxml.etreeでパースし、severity属性で集計、evidence経由でドキュメント原文へリンクバックするUIが、ほぼゼロコードで作れます。JSONより破綻に強いのも実務上の利点で、長文出力中の不正トークンが混じってもタグ単位で部分復旧できます。
- タグの入れ子は2〜3階層まで：深くしすぎるとClaude側の追従精度が落ちる。
- 属性は短く意味のあるものだけ：
index,source,severity,langなど列挙可能なものが向く。 - タグ名は単数か複数かを一貫させる：
<risks>の中身は<risk>。混在させると出力が不安定になる。 - 禁止項目は
<rules>に集約：散らすと優先順位が下がる。1タグに集めると遵守率が上がる。
Zero-shot / Few-shot / Chain-of-Thought の選び分け
「いつ例を見せるか」「いつ考えさせるか」の判断は、プロンプト設計の中心トピックです。Claude Sonnet 4.6 / Opus 4.7では3つの主要パターンを以下のように使い分けるのが2026年の定石です。
| パターン | 適したタスク | トークンコスト | 精度の伸び |
|---|---|---|---|
| Zero-shot | 定型分類、翻訳、要約、書式変換 | 低 | ベースライン |
| Few-shot（1〜3例） | 独自フォーマット、ドメイン用語の統一、エッジケース注入 | 中 | 10〜30%向上 |
| Chain-of-Thought | 多段推論、数値計算、矛盾検出、コードレビュー | 高（出力増） | 15〜40%向上 |
| Few-shot + CoT | 複雑な業務判断、評価ルーブリック適用 | 最大 | 条件次第で最大 |
判断のフローは単純です。まずZero-shotで20〜50件の評価セットを走らせ、ベースライン精度を測る。失敗パターンを分析し、フォーマット崩れが多ければFew-shot、論理ミスが多ければCoTを足す。両方の失敗が混在しているならFew-shot+CoTを試す。最初から最強構成を組まず、必要な分だけ層を足すのが、トークンコストと品質のスイートスポットです。
CoTを使うとき、Claudeでは「ステップバイステップで考えて」のような曖昧な指示より、<scratchpad>タグで思考領域を明示的に確保し、最終回答は<answer>タグに書かせる構成が安定します。さらにSonnet 4.6/Opus 4.7ではthinking={"type": "adaptive"}で内部思考を分離できるため、ユーザーに見せたくない推論プロセスはAdaptive Thinking側、見せたいサマリだけ通常出力、という二段構えが可能です。長い推論をユーザー目線から隠せるのは、エンドユーザー向けアプリで大きな利点になります。
まとめ
Claudeのプロンプトエンジニアリングは、テクニックの暗記ではなく「型」を覚えることが本質です。system / messages 分離、XMLタグ構造、役割と禁止事項、Few-shot example-first、Adaptive Thinking、prefill、評価ループ。この7つを押さえれば、Sonnet 4.6 でも Opus 4.7 でも、安定して高品質な出力を取り出せます。
Claudeとプロンプト設計を実務レベルで学ぶ
ClaudeとAIエージェント開発のUdemy講座を公開しています。