XMLタグと、段落分けや見出しでコンテンツを区切る方法とでは、効果にそれほど差がありますか？
差は「シグナルの明確さ」にある。段落分けやテキストラベル（例えば「例：」「入力：」といった文字マーカー）も一定程度の区切りを提供でき、人間の読者には理解できる。しかしこれらのマーカーは本質的に自然言語の一部であり、Claudeが処理する際も依然として内容の一部として解釈しており、構造的な境界宣言としては扱われない。
XMLタグの違いは、それがフォーマットレベルのシグナルであることだ。Claudeはマーカーテキストの意味を「理解」する必要がなく、コンテナの境界として直接認識する。これが公式ドキュメントが「複数の内容タイプが混在する」場面でタグの効果が最も顕著になると強調する理由でもある——内容タイプが多く混同しやすいほど、フォーマットレベルのシグナルが意味レベルのマーカーより信頼できる。
タグ名に標準的な語彙はありますか？適当に名付けると効果に影響しますか？
公式ドキュメントは、Claudeが特定の「標準」XMLタグセットのみを認識するよう訓練されているわけではないと明言しており、<customer_data>や<financial_report>のような状況特化の記述的な名前でも同様に機能する。
しかし「どんな名前でもいい」と「適当に名付ける」は別の話だ。命名の原則は2つある。第一に、名前を見れば中身が一目でわかること——これは後でプロンプトを修正する際にも役立つ。第二に、同一プロンプト内で命名の一貫性を保つこと。ある箇所で<input>を使い、似た性質の別箇所で<user_input>に切り替えるような不一致は、それ自体が新たな混乱を生む。
XMLタグはFew-Shot Prompting（少数事例学習）やChain-of-Thought（思考の連鎖）と併用できますか？
併用できるだけでなく、公式ドキュメントはこの組み合わせを「パワーユーザー向けテクニック」として明確に推奨している。よくあるパターンは、複数の例を<examples>に包み、内部で<example>を使って入出力のペアごとに個別に区切る方法だ。これによりClaudeは「ここに複数の例があり、それぞれが独立した入出力ペアである」と明確に認識でき、異なる例の内容を混同して解釈することがなくなる。
Chain-of-Thoughtの部分では、<thinking>と<answer>タグを組み合わせることが多く、Claudeに推論プロセスと最終回答を分けて出力させることで、後でプログラム的に一部だけを抽出しやすくなる。注意点として、既にAPIの拡張思考機能を使っている場合、さらに<thinking>タグで追加の推論出力を求めることは推奨されない——2つの推論メカニズムが互いに干渉し、かえって効果が下がる可能性がある。
私は普段API開発ではなく、claude.aiのブラウザ版でチャットしているだけですが、このテクニックは役に立ちますか？
完全に役立つし、思っているより敷居は低い。XMLの文法規則を理解したりコードを書いたりする必要はなく、チャット欄に直接<例>...</例>や<instructions>...</instructions>のような山括弧で異なる種類の内容を包むだけで、Claudeは同じように構造を認識する。
最も実用的な場面は、一度のメッセージで性質の異なる複数のテキストをClaudeに渡す必要があるときだ——例えば「従うべき文章スタイルの例」「背景資料」「今日書きたいテーマ」を同時に貼り付ける場合。これら3つのブロックに何のマーカーもなければ、Claudeが同じ種類のものと誤判断しやすい。10秒かけてタグを追加するだけで、より正確で、やり取りの往復が少ない回答が得られる——日常的なチャット利用においても十分に見合う投資だ。
3段落を超えるプロンプトを書いたことがあるなら、こんな経験があるはずだ。Claudeが「例」を指示の一部として扱ってしまう、あるいは「背景情報」を処理すべき問題そのものと誤解してしまう——これはClaudeの理解力が足りないのではなく、プレーンテキストのプロンプトは内容が増えるほど、そもそも明確な境界を持たないという構造的な問題だ。丁寧に書いたシステムプロンプトでも、内部構造が乱れていれば誤読される。
Anthropic公式のプロンプトエンジニアリングガイドは、プロンプトが指示・文脈・例・可変入力を混在させる場合、XMLタグがClaudeの誤判断を大きく減らすと明記している。この記事は公式ドキュメントの文法規則を繰り返すのではなく、タグあり／なしの実例を3つ並べて、違いが実際どう現れるかを見せる。
タグなしのプロンプトは典型的にこうなる：「このクレームに親切な口調で返信して」という指示、続いて過去の優れた返信を例として貼り付け、最後に今回実際に処理すべきクレーム内容を貼る。人間の目には3つのブロックが明確に分かれて見えるが、Claudeにとってはすべてがただのテキストであり、「2番目のブロックは参考例で返信不要」「3番目こそが実際に処理すべきもの」と示す構造的シグナルが存在しない。よくある失敗は、Claudeが例そのものに返信してしまう、あるいは例の口調を間違った対象に適用してしまうことだ。
例を<example>に、実際のクレームを<input>に包み、指示を<instructions>に保つことで、各ブロックの役割が曖昧でなくなる。これは装飾的な記号追加ではなく、Claudeが以前は推測に頼っていた意味的境界を、明示的な宣言に変換する作業だ。
2つ以上の文書をClaudeに渡して比較を依頼する場合、プレーンテキストの貼り付けが最も問題を起こしやすい——文書間に明確な区切りがないと、Claudeが文書Aの内容を文書Bの発言として誤帰属させることがあり、特に文書の書式が似ていて見出しの区別が乏しい場合に顕著になる。
公式が推奨する方法は、各文書をindex属性付きの<document>タグで包み、内部に<source>と<document_content>のサブタグをネストすることだ。この入れ子構造により、Claudeは回答生成時に「この主張はどの文書由来か」を明示的に示せるようになる——これは本サイトが複数ソースの検索結果を扱う際に実際に採用しているパターンでもあり、文単位での出典明示を求める前に、各ソースを個別にタグで包んでいる。
もう一つよくあるパターンは、プロンプト冒頭で役割を設定（「あなたはシニアバックエンドエンジニアです」）した後、長いフォーマット要求や出力規則、注意事項が続き、役割設定の影響力が徐々に薄れ、Claudeの口調が汎用的な方向に流れてしまい、本来設定されたはずの専門的な視点を失うことだ。
役割設定とフォーマット規則を分離する——例えば役割はシステムプロンプトに保ち、フォーマット要求を<formatting>に包む——ことで、Claudeは「これが私の身分」と「これが私の出力ルール」を区別でき、規則セクションが長くなっても役割設定の重みが希薄化しない。
公式ドキュメントの表現は具体的だ：プロンプトが「指示・文脈・例・可変入力を混在させる」場合にXMLタグを使う。逆も成り立つ——プロンプトが複数の内容タイプを含まない単純な一つの質問であれば、タグを追加してもノイズが増えるだけで実質的な改善にはならない。判断基準はプロンプトの長さではなく、互いに区別すべき内容タイプがいくつあるかだ。
次にプロンプトを書くときは、まず自分に問いかけてほしい：このテキストには指示・例・背景情報・処理すべき入力のうち、いくつの異なる役割の内容が含まれているか？答えが2つ以上なら、それぞれを専用タグで包む方が、Claudeに境界の推測を任せ続けるより確実だ。タグ名に決まった語彙はなく、重要なのは一つのプロンプト内で一貫性を保ち、中身が一目でわかる名前を選ぶことである。