0:00 0:00
Article
Claude CodeでXML風タグを使うべき場面とプロンプト例
Claude Codeの依頼文でXML風タグを使うべき場面と、使わないほうがいい場面を整理します。Anthropic公式が推奨するタグ構造の原則、コピペできるテンプレート、過剰設計を避ける判断基準まで、複雑な依頼を構造化したい人向けの実務ガイドです。
Claude Codeの依頼文が長くなり、指示と前提と参考コードが混ざって誤読されるようになったら、XML風タグで区切る出番です。本記事は、タグを使うべき場面と使わないほうがいい場面、コピペできるテンプレート、過剰設計を避ける基準を整理します。
結論：情報の種類が混ざるときだけタグで区切る
Anthropic公式のプロンプトエンジニアリングガイドは、XMLタグについて「指示・コンテキスト・例・可変入力が混ざる複雑なプロンプトを、Claudeが曖昧さなく解釈する助けになる」と説明しています（Prompting best practices）。逆に言えば、短い依頼や1種類の情報しかない依頼にタグは不要です。
要点は3つです。
- 使う場面：1つの依頼に「指示」「前提」「参考コード」「期待出力」など複数種類の情報が混在するとき
- 使わない場面：1〜2行の短い依頼、情報が1種類だけの依頼
- 過剰設計の禁止：タグの数を増やすこと自体が目的化したら、依頼が大きすぎるサイン
タグはMarkdownの見出しでも代替できます。重要なのは「種類ごとに区切る」ことであり、XMLである必要は必ずしもありません。
なぜタグで区切ると精度が上がるのか
Claude Codeは依頼文・読み込んだファイル・コマンド出力をすべて1つのコンテキストで扱います。地の文だけで「これは前提、これは指示、これは参考にするだけのコード」と書くと、参考コードを仕様と誤認したり、前提を指示と取り違えたりします。
タグで囲むと、どこからどこまでが何の情報かが構造的に明示されます。公式ガイドのベストプラクティスは次の2点です。
- タグ名はプロンプト全体で一貫した、内容を表す名前にする
- 自然な階層があるときはタグを入れ子にする（例：複数文書なら
<documents>の中に各<document>）
タグ名に決まりはありません。<instructions>や<context>のように中身が分かる名前を、自分のプロンプト全体で揃えて使えば十分です。
使うべき場面の判断基準
次のどれかに当てはまるときだけタグを使います。
| 状況 | タグの要否 | 理由 |
|---|---|---|
| 1〜2行の短い修正依頼 | 不要 | 区切る情報がない |
| 参考コードを「真似る用」で渡す | 必要 | 仕様と誤認させない |
| 長い仕様＋制約＋期待出力が同居 | 必要 | 種類ごとに分離する |
| エラーログやデータを大量に貼る | 必要 | 指示と入力を分ける |
ファイルは@参照だけで足りる | 不要 | 構造化済み |
短い依頼にタグを付けるのはむしろノイズです。タグは「情報が混ざって誤読が起きたとき」の対処であり、最初から全部に付けるものではありません。
コピペできるテンプレート
複数種類の情報が混ざる依頼の基本形です。タグ名は中身が分かる名前で揃えます。
<instructions>
src/api/invoice.ts に消費税計算を追加する。既存の計算関数を壊さない。
</instructions>
<context>
税率は外部設定から読む。端数処理は切り捨て。既存テストは tests/invoice.test.ts。
</context>
<reference>
既存の似た実装。これは真似る対象であって、変更対象ではない。
@src/api/shipping.ts
</reference>
<acceptance>
- 既存テストが全て緑のまま
- 新規に境界値テスト（0円・端数あり・上限）を追加し緑
- npm test が通る
</acceptance>
<forbidden>
- 依頼スコープ外のリファクタやファイル新規作成
- 新しい依存の追加
</forbidden>参考データを大量に渡すときは、入力部分だけ囲んで指示と分離します。
<task>
次のアクセスログから、5xxエラーが集中している時間帯と上位エンドポイントを表にして。
</task>
<logdata>
（ここにログを貼る、または cat access.log | claude で流し込む）
</logdata>長い入力を扱うときは、公式ガイドのとおり長文データを上部、指示と質問を下部に置くと精度が上がります。
XML風タグと7ブロック構造の関係
このシリーズの「Claude Codeに伝わるプロンプトの基本構造」で扱った7ブロック（目的・背景・入力・制約・出力・完了条件・禁止事項）は、Markdown見出しでもXML風タグでも表現できます。使い分けの目安は次のとおりです。
- 見出し（
## 目的）：人間も読む依頼文、CLAUDE.md、テンプレート配布 - XML風タグ：参考コードやログなど「囲んで他と切り離したい塊」がある依頼
完了条件と禁止事項の中身の書き方は「Claude Codeの成功率を上げる制約条件と受け入れ条件の作り方」に詳しくあります。本記事は「どう区切るか」に集中します。
過剰設計を避ける
タグは便利ですが、増やしすぎると逆効果です。次がアンチパターンです。
- 1行の依頼に5個のタグを付ける（情報がないのに枠だけ作る）
- 同じ意味で
<context>と<background>を混在させる（一貫性がない） - 巨大なログ全文を
<logdata>で囲んで貼る（コンテキスト圧迫） - 毎回タグ構造を変える（Claudeが構造を学習できない）
タグが3〜4種類を超えて膨らんだら、たいてい依頼が大きすぎます。その場合はタグを足すのではなく依頼を分割します。コンテキストを圧迫しない情報の渡し方は「Claude Codeに必要な情報だけ渡すコンテキスト設計」にまとめています。
チェックリスト
- その依頼に複数種類の情報が混ざっているか確認した
- 1〜2行の短い依頼にはタグを付けていない
- タグ名は中身が分かる名前で、プロンプト全体で統一した
- 参考コードは「変更対象でない」と明示して別タグにした
- 長い入力は上部、指示は下部に置いた
- タグ種類が増えすぎていない（増えたら依頼を分割した）
- 巨大ログを丸ごと囲んでコンテキストを圧迫していない
次に読むおすすめ記事：
- 「Claude Codeに伝わるプロンプトの基本構造」：タグ／見出しで埋める7ブロックの雛形
- 「Claude Codeの成功率を上げる制約条件と受け入れ条件の作り方」：制約と完了条件の中身の書き分け
- 「Claude Codeに必要な情報だけ渡すコンテキスト設計」：タグで囲む前に「入れない」判断をする方法
