Anthropic はプロンプト設計の指針を1ページのリファレンスにまとめています。以前は「XMLタグを使う」「思考させる」といった手法ごとに別々のページがありましたが、現在はそれらが Prompting best practices に統合され、旧URLはこのページへ転送されます。本稿はその内容の非公式な日本語解説です。
このリファレンスは3部構成になっています。最初にモデル別の指針、次に現行モデル共通の手法、最後に旧世代からの移行時の注意です。モデル別の指針が先に来ているのは、同じプロンプトでもモデルによって効き方が変わるためです。
まず押さえる4つの原則
共通手法の節は「一般原則」から始まります。公式が挙げている柱は次の4つです。
1. 明確に、直接に書く
Claude は明示的な指示によく反応します。「期待以上の仕事」をしてほしいなら、曖昧なプロンプトから推測させるのではなく、そう書いてください。公式は Claude を「優秀だが自社の慣習を知らない新入社員」に例えています。
判断の目安として、公式はゴールデンルールを置いています。前提知識のほとんど無い同僚にプロンプトを見せ、そのとおりに作業してもらってください。同僚が迷うなら Claude も迷います。
Create an analytics dashboardCreate an analytics dashboard. Include as many relevant features and
interactions as possible. Go beyond the basics to create a fully-featured
implementation.2. 理由を添える
指示の背景や動機を書くと、目的が伝わって出力が狙いに寄ります。公式の例は分かりやすいものです。
| 効きにくい | 効く |
|---|---|
NEVER use ellipses |
Your response will be read aloud by a text-to-speech engine, so never use ellipses since the text-to-speech engine will not know how to pronounce them. |
理由を書いておけば、Claude はそこから一般化します。三点リーダだけでなく、読み上げで困る他の記号についても同じ判断ができるようになる、ということです。
3. 例を使う
出力の形式・トーン・構造を寄せる手段として、例示（few-shot / multishot）がもっとも確実だと公式は書いています。例を足すときの条件は3つです。
- 関連していること — 実際のユースケースに近づける
- 多様であること — 端のケースを含め、意図しないパターンを学習させない
- 構造化されていること —
<example>タグ（複数なら<examples>）で囲み、指示と区別できるようにする
件数の目安は3〜5件です。例の関連性や多様性そのものを Claude に評価させたり、手持ちの例をもとに追加を生成させたりもできます。
4. XMLタグで区切る
次の節で詳しく扱います。
XMLタグで構造を与える
プロンプトの中に指示・背景・例・可変の入力が混在すると、どこからどこまでが何なのかが曖昧になります。XMLタグで種類ごとに包むと、この取り違えが減ります。
<instructions>
以下の議事録から決定事項だけを箇条書きで抜き出してください。
</instructions>
<context>
この議事録は社内の設計レビュー会のものです。
</context>
<input>
{{MINUTES}}
</input>公式が挙げる作法は2点です。ひとつはタグ名を一貫させること。もうひとつは、内容に自然な階層があるときは入れ子にすることで、たとえば複数の文書なら <documents> の中に <document index="n"> を並べます。
役割をシステムプロンプトで決める
システムプロンプトで役割を与えると、振る舞いとトーンがそのユースケースに寄ります。公式は「1文でも違いが出る」と書いています。
client = anthropic.Anthropic()
message = client.messages.create(
model="claude-opus-5",
max_tokens=1024,
system="You are a helpful coding assistant specializing in Python.",
messages=[
{"role": "user", "content": "How do I sort a list of dictionaries by key?"}
],
)
print(message.content)役割は system パラメータに置きます。messages の中に「あなたは〜です」と書くのではない点に注意してください。
長文コンテキストは「先に置く」
2万トークンを超えるような長い文書やデータを扱うときは、置く順番が効きます。公式の指示は明快です。
- 長いデータをプロンプトの先頭側に置く — 質問・指示・例よりも上に置きます。これは全モデルで性能が上がります。
- 質問は末尾に置く — 複数文書をまたぐ複雑な入力では、末尾に質問を置くことで回答品質が最大30パーセント向上したとテストで示されています。
- 文書はメタデータごとタグで包む —
<document>の中に<source>と<document_content>を置きます。
<documents>
<document index="1">
<source>annual_report_2023.pdf</source>
<document_content>
{{ANNUAL_REPORT}}
</document_content>
</document>
<document index="2">
<source>competitor_analysis_q2.xlsx</source>
<document_content>
{{COMPETITOR_ANALYSIS}}
</document_content>
</document>
</documents>直感に反しますが、「長い資料を貼ってから質問する」のが正解で、「質問してから資料を貼る」ではありません。
出力の形式を制御する
形式の指定でとくに効くやり方として、公式は3つ挙げています。
- やってほしくないことではなく、やってほしいことを書く
「マークダウンを使わないでください」ではなく「なめらかに流れる散文の段落で構成してください」と書きます。 - XMLで形式を指示する
「散文の部分は<smoothly_flowing_prose_paragraphs>タグの中に書いてください」のように指定します。 - プロンプト自体の文体を、望む出力に合わせる
プロンプトの書きぶりが応答の書きぶりに影響します。
現行モデルの既定の話しぶりについても記述があります。以前のモデルより簡潔で自然になっており、自賛的な進捗報告ではなく事実に基づく報告をし、効率のために要約を省くことがあります。ツール呼び出しのあとに毎回まとめが欲しい場合は、そう書いてください。
After completing a task that involves tool use, provide a quick summary of the work you've done.ただし Claude Opus 5 は冗長性について例外だと明記されています。既定の応答は従来モデルより長めで、effort を上下させても見た目の長さは安定して変わりません。簡潔さが欲しければ、プロンプトで明示的に指示してください。
並列ツール呼び出しを引き出す
現行モデルは、互いに依存しないツール呼び出しを並列に実行します。複数の検索を投機的に走らせる、複数ファイルを同時に読む、bash コマンドを並列に流す、といった動きです。
指示が無くても成功率は高いのですが、公式はこれをほぼ100パーセントまで上げられるプロンプト例を示しています。
<use_parallel_tool_calls>
If you intend to call multiple tools and there are no dependencies between the tool
calls, make all of the independent tool calls in parallel. Prioritize calling tools
simultaneously whenever the actions can be done in parallel rather than sequentially.
For example, when reading 3 files, run 3 tool calls in parallel to read all 3 files into
context at the same time. Maximize use of parallel tool calls where possible to increase
speed and efficiency. However, if some tool calls depend on previous calls to inform
dependent values like the parameters, do NOT call these tools in parallel and instead
call them sequentially. Never use placeholders or guess missing parameters in tool
calls.
</use_parallel_tool_calls>この指示が「依存があるときは直列にせよ」「欠けた引数を推測するな」まで含んでいる点が大事です。並列化だけを強く言うと、引数を埋められないまま同時に投げる方向へ倒れます。
考えすぎ・作りすぎを抑える
逆向きの調整も同じリファレンスに入っています。従来モデル向けに「迷ったらツールを使え」といった書き方をしていた場合、現行モデルではそれが過剰な発火になります。
- 一律の既定をやめ、条件つきの指示にする — 「既定で〔ツール〕を使う」ではなく「問題の理解が深まるときに〔ツール〕を使う」と書きます。
- 過剰なプロンプトを削る — 以前は発火しにくかったツールが、いまは適切に発火します。「迷ったら使え」は過剰発火の原因になります。
- effort を下げる — それでも積極的すぎる場合の逃げ道です。
思考量そのものを抑えたいときは、次のような指示が示されています。
When you're deciding how to approach a problem, choose an approach and commit to it.
Avoid revisiting decisions unless you encounter new information that directly
contradicts your reasoning. If you're weighing two approaches, pick one and see it
through. You can always course-correct later if the chosen approach fails.思考コストに上限を掛けたい場合の注意もあります。extended thinking の budget_tokens は Opus 4.6 と Sonnet 4.6 では動くものの非推奨で、Claude 4.7 以降のモデルでは budget_tokens を指定すると 400 エラーが返ります。上限が要るなら effort を下げるか、adaptive thinking と max_tokens の組み合わせを使ってください。
コード生成における作りすぎ（過剰設計）についても、そのまま貼って使える指示が用意されています。範囲・ドキュメント・防御的コード・抽象化の4点について、それぞれ「やらないこと」を具体的に列挙する形です。要点は「依頼されたことと明らかに必要なことだけを行う」で、バグ修正のついでに周辺を整理しない、一度きりの処理にヘルパーを作らない、といった線が引かれています。
モデル別ページへの入口
共通手法のほかに、モデルごとの独立したページがあります。同じプロンプトでも挙動が変わる箇所がまとめられているので、使うモデルが決まっているならこちらを先に読むほうが早いです。
| モデル | そのページで扱っている主な論点 |
|---|---|
| Claude Fable 5 / Mythos 5 | effort の水準、指示追従、長時間タスクの進捗申告、メモリ機構、reasoning_extraction という拒否カテゴリ |
| Claude Sonnet 5 | 応答の長さ、effort と思考深度の調整、ツール発火、指示の字義どおりの解釈、デザイン・フロントエンドの既定 |
| Claude Opus 5 | 応答の長さと冗長性、進捗報告、成果物の分量、タスク範囲と過剰検証、サブエージェント制御、自己訂正 |
| Claude Opus 4.8 | 応答の長さ、effort と思考深度、ツール発火、指示の字義どおりの解釈、サブエージェント制御、デザインの既定 |
読む順番の目安: 使うモデルのページ → 共通手法（本稿の範囲） → 旧世代から移行するなら移行の注意、の順です。共通手法だけを読むと、Opus 5 の冗長性のようなモデル固有の癖を見落とします。
関連ページ
出典: Prompting best practices - Claude Docs（2026-08-30 確認）。本稿は非公式の日本語解説であり、Anthropic とは提携関係にありません。