プロンプトの書き方——XMLタグと例示でガイドする【CCA Foundations対策】
CCA Foundations対策 · Claude API編 第7回（全17回）
Anthropic Academyの「Claude APIを使用した構築」コースをもとに解説しています。
前回（#6）で「明確に書く」「具体的に指示する」を適用し、議事録要約のスコアが3.1から8.3まで上がった。この記事ではその続きとして、残り2テクニック——XMLタグによる構造化と例示（few-shot）——を適用して9.1まで引き上げる過程を追う。
この記事でわかること：
- XMLタグがなぜプロンプトの精度を上げるのか
- 変数を埋め込む場所とセクション区切りへのタグの使い方
- few-shotが「曖昧なケース」の判断を伝える仕組み
- コーナーケースを含む例示の設計方法
前回のおさらい
#6で適用した2テクニックと現在のプロンプト（v3）をざっくり確認しておく。
| バージョン | 変更内容 | スコア |
|---|---|---|
| v1 | ベースライン | 3.1 |
| v2 | 明確・直接的に書く | 5.4 |
| v3 | 具体的に指示する | 8.3 |
v3のプロンプトはこの構造：
def run_prompt_v3(minutes, context):
prompt = f"""
以下の会議議事録から、ビジネス利用に適した要約を生成してください。
会議種別：{context}
議事録：
{minutes}
【出力ガイドライン】
- 全体を3〜5項目の箇条書きにまとめる
- 「決定事項」と「アクションアイテム（担当者・期日があれば含める）」を必ず別項目で記載する
- 各項目は1〜2文で簡潔にまとめる
- 専門用語はそのまま使い、不必要な言い換えはしない
【出力手順】
1. 議事録全体を読み、主要トピックを把握する
2. 決定事項とアクションアイテムを抽出する
3. 重要度・緊急度の順に並べる
4. 上記ガイドラインに従って要約を生成する
"""
スコアは8.3だが、まだ課題が残っている。「提案があった」と「決定した」の境界線を誤って解釈するケースや、変数の値（{minutes}）と指示文が視覚的に混在している点が安定性を下げている。
テクニック③：XMLタグで構造化する
XMLタグの役割
プロンプトに変数を埋め込むとき、Claudeはテキスト全体を読んで「どこが指示でどこが入力データか」を推測している。この境界が曖昧だと、長い議事録や複数の変数が混在したときに混乱が起きやすい。
XMLタグはその境界を明示する道具。<meeting_minutes> と </meeting_minutes> で囲めば、「ここからここまでが外部データ」とClaudeに明確に伝わる。
タグなし（境界が曖昧）：
以下の情報をもとに物件紹介文を作成してください。
物件データ：間取り3LDK、築5年、駅徒歩8分
問い合わせ履歴：広さを重視したいとのこと
顧客要件：予算4000万円以内、南向き希望
タグあり（境界が明確）：
以下の情報をもとに物件紹介文を作成してください。
<property_data>
間取り：3LDK
築年数：5年
最寄り駅：徒歩8分
</property_data>
<inquiry_history>
広さを重視したいとのこと
</inquiry_history>
<customer_requirements>
予算：4000万円以内
希望条件：南向き
</customer_requirements>
タグがあると、Claudeは各セクションを独立したブロックとして処理できる。入力データが短くても、タグを付ける習慣をつけておくと、プロンプトが複雑になったときに一貫した精度を維持しやすい。
タグ名は説明的に： <data> より <meeting_minutes> の方がClaudeにとって意味が伝わる。タグ名はコンテンツの性質を示す名詞を使う。
v4：XMLタグを追加する
def run_prompt_v4(minutes, context):
prompt = f"""
以下の会議議事録から、ビジネス利用に適した要約を生成してください。
<meeting_context>
会議種別：{context}
</meeting_context>
<meeting_minutes>
{minutes}
</meeting_minutes>
【出力ガイドライン】
- 全体を3〜5項目の箇条書きにまとめる
- 「決定事項」と「アクションアイテム（担当者・期日があれば含める）」を必ず別項目で記載する
- 各項目は1〜2文で簡潔にまとめる
- 専門用語はそのまま使い、不必要な言い換えはしない
【出力手順】
1. <meeting_minutes>内の議事録全体を読み、主要トピックを把握する
2. 決定事項とアクションアイテムを抽出する
3. 重要度・緊急度の順に並べる
4. 上記ガイドラインに従って要約を生成する
"""
messages = []
add_user_message(messages, prompt)
return chat(messages)
run_eval(run_prompt_v4)
平均スコア v4: 8.7 (v3: 8.3 → +0.4)
v4の出力例：
【週次定例 要約】
・売上：前週比105%。計画比でも堅調に推移中
【決定事項】
・新機能リリース：来月実施を正式決定。詳細スケジュールは山田が策定
【アクションアイテム】
・山田：リリーススケジュール策定（今週中）
・各チーム：進捗報告を来週定例までに準備
v3と比べて、「議事録の内容」と「指示文」の境界が明確になり、複数の変数がある場合でも出力構造が安定した。改善幅は小さく見えるが、議事録が長くなる・変数が増えるほど差が開く。
テクニック④：例示（few-shot）でガイドする
なぜ例示が指示より効くのか
v3〜v4で「決定事項とアクションアイテムを必ず別項目で記載する」と指示しているが、「決定事項」の境界線がClaudeの解釈に委ねられている。
たとえば、こういう一文が議事録に含まれているとする：
山田さんからQA改善の強化について提案がありました。来週中に対応を検討します。
これは「決定事項」か「アクションアイテム」か？「提案があった」という表現は決定ではないが、「来週中に検討」はアクションアイテムに近い。指示文だけでは判断が揺れる。
例示（few-shot）はこの揺れを解決する道具。 「この入力に対してこの出力が正しい」という具体例を見せることで、Claudeは言語化しにくい境界線を学習する。説明するより、例を見せる方が正確に伝わる。
コーナーケースを含む例示の設計
few-shotの効果が最も大きいのはコーナーケース——典型ケースは指示だけで対処できても、曖昧なケースは例示がないと判断がブレる。
FEW_SHOT_EXAMPLES = """
【例1：通常ケース】
<example_minutes>
プロジェクトAのリリース日を来月15日に決定しました。田中が告知文を今週中に作成します。
</example_minutes>
<example_output>
・プロジェクトA：来月15日リリース決定
【決定事項】
・プロジェクトAのリリース日：来月15日
【アクションアイテム】
・田中：告知文作成（今週中）
</example_output>
【例2：コーナーケース——「提案」は決定事項に含めない】
<example_minutes>
山田さんからQA改善の強化について提案がありました。来週中に対応を検討します。
</example_minutes>
<example_output>
・QA改善強化：提案段階。対応策を来週中に検討
【決定事項】
・なし（提案段階のため）
【アクションアイテム】
・対応策の検討（担当：未定、期日：来週中）
</example_output>
"""
例2が重要。「提案があった」は決定事項ではない——これをルールで書くより例で見せる方が、Claudeにとって境界線の意味が伝わりやすい。
v5：few-shotを追加する
def run_prompt_v5(minutes, context):
prompt = f"""
以下の会議議事録から、ビジネス利用に適した要約を生成してください。
{FEW_SHOT_EXAMPLES}
---
<meeting_context>
会議種別：{context}
</meeting_context>
<meeting_minutes>
{minutes}
</meeting_minutes>
【出力ガイドライン】
- 全体を3〜5項目の箇条書きにまとめる
- 「決定事項」と「アクションアイテム（担当者・期日があれば含める）」を必ず別項目で記載する
- 「提案段階」の内容は決定事項に含めない（例2を参照）
- 各項目は1〜2文で簡潔にまとめる
- 専門用語はそのまま使い、不必要な言い換えはしない
【出力手順】
1. <meeting_minutes>内の議事録全体を読み、主要トピックを把握する
2. 決定事項とアクションアイテムを抽出する（例を参考に判断する）
3. 重要度・緊急度の順に並べる
4. 上記ガイドラインに従って要約を生成する
"""
messages = []
add_user_message(messages, prompt)
return chat(messages)
run_eval(run_prompt_v5)
平均スコア v5: 9.1 (v4: 8.7 → +0.4)
v5の出力例（コーナーケースを含む議事録の場合）：
【週次定例 要約】
・売上：前週比105%で堅調
・QA改善強化：提案段階。来週中に対応策を検討
【決定事項】
・新機能リリース：来月実施を正式決定
【アクションアイテム】
・山田：リリーススケジュール策定（今週中）
・QA改善の対応策検討（担当：未定、期日：来週中）
「提案があった」ケースが「決定事項なし」として正しく分類されるようになった。
📋 試験ガイドより
公式試験ガイドのDomain 4 Task 4.2では、few-shotの例示が曖昧なケースの判断基準を伝える仕組みとして取り上げられている。「なぜその出力が理想的か」の理由を例示に添えると効果が高まることもポイント。
4テクニック適用後のスコア推移
| バージョン | 変更内容 | スコア | 改善幅 |
|---|---|---|---|
| v1 | ベースライン | 3.1 | — |
| v2 | 明確・直接的に書く | 5.4 | +2.3 |
| v3 | 具体的に指示する | 8.3 | +2.9 |
| v4 | XMLタグで構造化する | 8.7 | +0.4 |
| v5 | 例示（few-shot）追加 | 9.1 | +0.4 |
改善幅の傾向に注目： v2・v3の改善幅（+2.3、+2.9）が大きく、v4・v5（+0.4ずつ）は小さい。これは「まず方向を定める（明確さ・具体性）、次に精度を上げる（構造化・例示）」という順序で効果が出やすいことを示している。
4テクニックの使い分けの目安：
| テクニック | 効果が出やすい場面 |
|---|---|
| 明確・直接的に書く | スコアが低い・出力の方向性がバラバラ |
| 具体的に指示する | 出力の方向は合っているが形式や内容が不安定 |
| XMLタグ | 変数が複数・プロンプトが長い・入力と指示が混在している |
| 例示（few-shot） | 曖昧なケースで判断がブレる・コーナーケースへの対応が必要 |
プロンプト改善の反復プロセス
4テクニックを適用してもスコアが目標に達しない場合、改善をどう進めるかが問われる。
テスト駆動反復（test-driven iteration）
プロンプト改善は感覚ではなくテストケースで検証しながら進める。
- テストケースを先に定義する：典型ケース・コーナーケース・境界ケースを用意
- 現状スコアを全ケースで計測する
- 1テクニックずつ変更し、スコアの変化を確認する
- スコアが下がったら変更を戻す
1変更ずつ計測するのが原則。複数をまとめて変更すると「何が効いて何が逆効果だったか」がわからなくなる。
インタビューパターン（interview pattern）
要件が曖昧なときに、Claudeに質問させて要件を引き出すパターン。
system = """
あなたは要件定義のエキスパートです。
ユーザーからタスクを受け取ったら、実装に必要な情報を1つずつ質問してください。
すべての情報が揃ったと判断したら「要件定義完了」と宣言してまとめを出力してください。
"""
ユーザーが最初から完全な仕様を持っていない場合に有効。Claudeが質問を重ねることで、ユーザー自身も気づいていなかった要件が明確になる。
問題の逐次 vs 並列解決
複数の問題が見つかったとき、逐次（sequential）と並列（parallel）のどちらで修正するかは問題の独立性で判断する。
| 状況 | 選択 | 理由 |
|---|---|---|
| 問題Aの修正が問題Bに影響する可能性がある | 逐次 | 依存関係があると並列修正の効果が正確に計測できない |
| 問題同士が完全に独立している | 並列 | 同時に修正してスコアを計測できる |
| 依存関係が不明 | 逐次から始める | 安全側に倒して、独立性が確認できたら並列に切り替える |
📋 試験ガイドより
試験ガイドのIn-Scope Topicsに「Iterative refinement: Input/output examples, test-driven iteration, interview pattern, sequential vs parallel issue resolution」が明記されている。改善を1テクニックずつ計測する・インタビューパターンで要件を引き出す・問題の独立性で逐次/並列を判断する、という3点が設計の核心。
よくある誤解まとめ
| 誤解 | 実際 |
|---|---|
| XMLタグはHTMLと同じルールで書く必要がある | Claude専用の構造化ツールなので、独自の名前で自由に使える |
タグ名は何でもいい（<a>, <x> など） |
説明的な名前（<meeting_minutes>, <customer_requirements>）の方がClaudeの理解精度が上がる |
| few-shotは典型的なケースの例を入れればいい | コーナーケース（曖昧な判断が必要な例）を入れると効果が高い |
| 例示にはインプットとアウトプットだけあればいい | 「なぜその出力が理想か」の理由を添えるとより安定する |
| 4テクニックを一気に適用して最終スコアだけ確認すればいい | 1つずつ適用してスコアを確認しないと、何が効いたか・何が逆効果だったかわからない |
| 複数の問題が見つかったら一度に全部修正する | 問題の独立性を確認し、依存関係がある場合は逐次で修正してスコアを1つずつ計測する |
まとめ
- XMLタグは変数の埋め込み箇所とセクション境界を明示する。タグ名は説明的に
- 変数が1つしかなくてもタグを付ける習慣で、プロンプトが複雑になったときの安定性が上がる
- few-shotは「言葉では伝わりにくい境界線」をコーナーケースの例で伝える
- 典型ケースよりコーナーケースの例示の方が効果が大きい
- 「なぜその出力が理想か」の理由を例示に添えると判断がより安定する
- 4テクニックの効果は「方向を定める → 精度を上げる」の順で大きい。1テクニックずつ計測して進める
- 改善は1変更ずつ計測する（test-driven iteration）。複数をまとめると何が効いたかわからない
- インタビューパターンで要件を引き出し、問題の独立性で逐次/並列解決を判断する