ClaudeのプロンプトでXMLタグを使う書き方と基本の型

ClaudeのプロンプトでXMLタグを使う目的は、指示・文脈・例・入力データを区切って誤読を減らすことです。使うタグは<instructions>・<context>・<input>のように、内容の種類を表す名前なら自由に決められます。

この記事では、タグの分け方の基本形と、Anthropic自身のシステムプロンプトで実際に使われている構造を並べて確認します。

ClaudeへのプロンプトをXMLタグで構造化するとは

XMLタグによる構造化とは、プロンプト内の指示・文脈・例・入力データをそれぞれ専用のタグで囲み、Claudeが役割を混同しないようにする書き方です。<instructions>のように内容の種類ごとにタグを分けるだけで、誤読の可能性は下がります。

XMLタグは必須か、何を決めれば使えるか

XMLタグは必須ではありません。効くのは指示・文脈・例・入力が1つのプロンプトに混ざるときで、短い一問一答なら素の文章でも成り立ちます。

Claude専用の決まったタグ一覧もありません。公式が求めるのは、プロンプト全体で一貫した説明的なタグ名を使うことと、階層のある内容を入れ子にすることの2点です。入れ子の具体例は、複数の文書を<documents>でまとめ、各文書を<document index="n">で区切る構成です。迷ったら、下の基本形の<instructions>・<context>・<input>から始めます。

instructions・context・exampleを分ける基本形

プロンプト全般のコツはClaudeプロンプトの書き方にまとめてあります。ここではXMLタグによる構造化の分け方に絞って説明します。

最初に押さえるべきパターンは、指示・文脈・入力の3種類をタグで分けることです。<instructions>・<context>・<input>という3つのタグ名がこの型の代表例です。名前は固定ではありませんが、同じ意味のタグはプロンプトやプロジェクトの中で使い回します。

<instructions>
アップロードした議事録から決定事項だけを抽出し、担当者ごとに箇条書きでまとめてください。
</instructions>
 
<context>
この議事録は週次の進行管理ミーティングのものです。読み手はプロジェクトマネージャーです。
</context>
 
<input>
{{MEETING_TRANSCRIPT}}
</input>

この形にしておくと、<context>の中身を差し替えるだけで別のミーティング用に転用できます。指示文と入力データが1つの段落に混在していると、Claudeが「これは指示なのか、それとも抽出対象の本文なのか」を判断する負荷が上がります。タグで区切ることは、その負荷をプロンプトの書き手側で先に取り除く作業だといえます。

例(example)は複数形のタグで束ねる

3〜5個ほどの具体例を渡す少数事例プロンプト(few-shot prompting)は、出力の形式・トーン・構造を安定させる手法です。ここでもタグの使い分けが決まっています。1つの例は<example>タグで囲み、複数の例をまとめるときは外側を<examples>タグで囲みます。

<examples>
<example>
入力: 会議で予算超過が報告された
出力: [警告] 予算超過が報告されました
</example>
<example>
入力: 新機能のリリース日が確定した
出力: [情報] リリース日が確定しました
</example>
</examples>
 
上記の例と同じ形式で、次の入力を分類してください。

<example>で囲んでおけば、Claudeは例と指示を区別できます。それが「参考として提示された過去の入出力」であることが、構造として伝わります。

公式は例の質に3つの条件を挙げています。1つ目は実際の用途に近いこと、2つ目は境界事例を含めて十分にばらけていること、3つ目は<example>(複数なら<examples>)で囲んで構造化されていることです。似た例ばかりだと、意図しない癖までClaudeが拾ってしまいます。例が足りているかは、Claudeに関連性と多様性を評価させたり、最初の数個をもとに追加の例を作らせたりして点検できます。

複数文書をタグでネストする設計

指示・文脈・例の3分割だけでは対応しきれないのが、複数の文書を同時に渡す場面です。2万トークンを超えるような長文入力を扱うときは、長文データをプロンプトの先頭、指示や質問より前に置きます。クエリを末尾に置くことで、複数文書を含む複雑な入力での応答品質が最大30%改善したという検証結果があります。

複数文書を渡すときのタグ構成は、外側を<documents>、各文書を<document index="n">で区切り、その中に<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>
 
年次報告書と競合分析を比較し、戦略上の強みとQ3の重点領域を提案してください。

文書が増えるほど、どの発言がどの資料に基づくかを機械的に追いやすくする設計が効いてきます。長文タスクでは、Claudeに該当箇所を<quotes>タグへ先に引用させ、そのうえで結論を<info>タグに書かせる2段構成も使われています。引用を先に出させることで、Claudeは関連する内容に集中しやすくなり、文書の余計な部分に惑わされにくくなります。

出力フォーマットの指定にもXMLタグを使う

XMLタグは入力側だけでなく、Claudeに書いてほしい出力の形式を指定するときにも使えます。公式は「してはいけないこと」より「してほしいこと」を書くよう勧めています。「マークダウンを使わないでください」ではなく、「地の文だけの段落で構成してください」と書きます。

そのうえでタグを使う場合は、出力してほしいブロックの名前をタグとして指定します。たとえば「応答の地の文部分を<smoothly_flowing_prose_paragraphs>タグの中に書いてください」のように書きます。プロンプト自体の書き方を出力の書き方に近づけることも効果があり、プロンプト側からマークダウン記法を減らすと出力側のマークダウンの量も減る傾向があります。

前置きを省くためのprefillが使えなくなったあとは、出力をXMLタグの中に収めさせる方法が代わりになります。公式は、XMLタグ内に出力させる、構造化出力を使う、ツール呼び出しを使う、の3つを挙げています。構造化出力は、指定したスキーマにClaudeの応答を従わせるための機能です。前置きがたまに紛れ込む場合は、後処理で取り除きます。

指示のまとまりごとに固有のタグ名をつける

<instructions>や<context>のような汎用タグだけでなく、1つの指示のまとまり全体に固有のタグ名をつける書き方もあります。Claudeにツール呼び出しを積極的に行わせたい場面では、システムプロンプトに次のようなブロックを追加する例があります。

<default_to_action>
By default, implement changes rather than only suggesting them. If the user's intent is
unclear, infer the most useful likely action and proceed, using tools to discover any
missing details instead of guessing. Try to infer the user's intent about whether a tool
call (e.g., file edit or read) is intended or not, and act accordingly.
</default_to_action>

反対に、ユーザーの指示がはっきりするまで実装に踏み込ませたくない場合は、<do_not_act_before_instructions>のように意図が逆のタグ名をつけたブロックを使います。同じ考え方は、コード調査で推測に頼らせたくないときの<investigate_before_answering>ブロックにも使われています。タグ名がそのまま「このブロックが何を守らせる指示か」を表しているため、複数のルールを1つのシステムプロンプトに並べても、どの指示がどの効果を持つのかを見分けやすくなります。公式のサンプルブロックは英語で書かれています。タグ内の指示文を日本語と英語のどちらで書くか迷う場面もあります。Claudeは日本語と英語プロンプトで出力の長さに差が出るかで挙動の違いを確認できます。拒否判定に絞った言い回しの実例はClaude Fable 5.1のrefusal誤検知を防ぐプロンプトの書き方にまとめています。

タグで指示を分けるのと合わせて、システムプロンプトの先頭でClaudeに役割を与える書き方もよく使われます。「あなたはPythonに詳しいコーディングアシスタントです」のような一文をシステムプロンプトに置くだけで、Claudeの振る舞いとトーンはその役割に沿ったものに変わります。役割の指定とタグによる構造化は別々の技術なので、両方を組み合わせて使えます。

Anthropic自身のシステムプロンプトでも同じ構造が使われている

2026年9月22日更新のClaude Opus 5.5システムプロンプトは、<claude_behavior>という最上位タグ1つで全体を包み、その中を役割別のタグに分けています。

<refusal_handling>の中身には、具体例を示す<example>が3つあります。最初の2つは<user>・<response>・<rationale>の3点セットです。3つ目だけは応答側を<bad_response>と<good_response>に分け、良い応答と悪い応答を1つの例の中で対比させています。

理由を書く<rationale>が全例に付いている点が、自作プロンプトに持ち帰れる部分です。例を渡すだけでなく「なぜその応答が正しいか」まで同じ構造で添えれば、判断の基準まで例の中で伝えられます。

同じシステムプロンプトの<product_information>には、プロンプトの助言を求められたとき「特定のXMLタグを求める」手法を挙げる一文があります。

タグの使い分け早見表

ここまでに出てきたタグを、渡したい内容の種類ごとに一覧にまとめました。新しくプロンプトを書くときは、まずこの表のどの行に当たるかを決めてからタグ名を選ぶと、タグ名がプロンプトやプロジェクトの間でぶれにくくなります。会計や法務など専門領域のプロンプト設計はClaudeでJ-GAAPとIFRS差分チェックを行うプロンプト設計にあります。

<thinking>タグで推論を書かせるとどうなるか

XMLタグの使い方で、公式docs同士の書き方が食い違うのが、推論過程を出力に書かせるタグです。

best practicesのページでは、thinkingをオフにした場合の代替として、考えてから答えさせ、最終回答を<answer>タグに入れさせる方法を挙げています。一方でFable 5.1・Fable 5・Opus 5.5・Opus 5・Sonnet 5.5では、推論を<thinking>タグなどに書き出させるプロンプトが拒否されることがあります。この5モデルでは、thinkingを有効にして推論を任せる使い方が前提です。

拒否はHTTP 200で返り、stop_reasonが"refusal"、stop_details.categoryが"reasoning_extraction"になります。エラーではない点が見落としやすい挙動です。出力が始まる前の拒否でも、reasoning_extractionは通常のリクエストと同じ料金で課金されます。contentは空で、トークン数はusageに入ります。課金対象のカテゴリは見直されることがあります。

途中で拒否された場合は、入力トークンと、すでにストリーム済みの出力が通常料金で課金されます。途中まで届いた出力は不完全なものとして捨てます。このカテゴリには推奨のフォールバックモデルが無いため、同じリクエストを再試行するのではなく、プロンプトを書き換えます。

逆方向の落とし穴もあります。Opus 5はthinkingを無効にすると、応答の見える部分に<thinking>などの内部用XMLタグを出力してしまうことがあります。原因になりやすいのは、システムプロンプトにある「考えるな」という指示で、まず外すよう案内されています。タグ名を名指しで禁じる指示は効きにくく、「内部用やシステム用のXMLタグを応答に含めない」という一般形の指示のほうが効くとされています。

thinkingを無効のまま運用する場合に公式が示す文面は、次の3点を1つにまとめた形です。ツールを使う前に一言添えてよいこと、頼まれたことに合うツールが無ければ推測せずにそう伝えること、内部用やシステム用のXMLタグを応答に含めないことです。

When you use a tool, you may say a brief sentence first. If no tool can express what the user asked for, say so instead of guessing. Do not include internal or system XML tags in your response.

よくあるつまずき

XMLタグの運用でつまずきやすい点は、命名・分離・ネストの3つです。

• タグ名が揺れると、<context>と<background>のように同じ意味のタグが並び、使い回すプロンプトの一貫性が崩れます。プロジェクト単位で語彙を決めます。
• <instructions>の中に例を混ぜると、指示と例の境界が消えます。例は<example>に分けます。
• 階層の無い内容まで入れ子にすると、開閉の管理が書き手の負担になります。入れ子にするのは、文書のように実際に階層がある内容だけです。

まとめ

タグ名は一貫していれば何でもよく、決めるべきは「どの内容をどのタグで囲むか」という分け方です。まずは指示と入力データを分けるところから始め、推論を出力に書かせるタグだけは、最新モデルで拒否されうるので別扱いにします。