第2章 例と構造化

学習目標

• 例が、意図したルールと偶然のパターンを同時に教えることを説明し、偶然のパターンを見つけて取り除く。
• few-shot例を、関連性・多様性・形式の一貫性という基準に沿って構成し、例と評価データを分離する。
• XMLタグで指示・コンテキスト・例・入力の境界を分ける。
• 出力の受け手（人、システム、音声）に合う形式を選び、データ辞書と欠損値の表現を決める。
• 機械が読む出力に、指示・例・構造化出力から適切な方法を選び、形式の遵守と内容の正確さを別々に検査する。
• プリフィルに依存したプロンプトを、最新モデルに適した手法へ移行する。

はじめに

ある通信販売会社が、商品に関する問い合わせを「配送、交換、決済、その他」の4つに分けるプロンプトを作りました。担当者は4つの例を入れましたが、偶然、そのすべてが「こんにちは」で始まる丁寧な文でした。運用を始めると、挨拶なしで短く書かれた問い合わせが「その他」に集中し、急ぎの事情を書いた問い合わせ数十件が、1日以上も放置されました。担当者が原因を突き止めたのは、「その他」の担当者が仕事が増えたと苦情を訴えてから、1週間もたった後でした。モデルは、担当者が教えようとした分類基準とともに、「丁寧な文でなければ正式な問い合わせではない」という、誰も意図していなかったルールまで学んだのです。偏りを生んだのは、担当者が書いた指示ではなく、担当者が選んだ例でした。例は、最も強力な指示であると同時に、最も制御しにくい指示でもあります。

この章では、よい例の条件と多様性の設計、境界事例、偏りを減らす手順、例と評価データの分離から始めます。続いて、指示と資料の境界を引くタグ、受け手に合った形式、データ辞書と欠損値の表現、構造化出力が保証する範囲と限界、プリフィルの代替手段、根拠フィールドの設計を見ていきます。「さらに深く」では、思考機能のあるモデルに方法を示す例と、表示環境に応じた書式の問題を扱います。

重要な概念

例は仕立て屋に渡す見本の服

仕立て屋に「すっきりしたシャツ」と伝えるより、見本のシャツを何着か渡すほうが、はるかに正確です。ただし、見本がすべて白い半袖なら、仕立て屋は、客が白い半袖だけを望んでいると誤解するかもしれません。few-shot例、つまり、入力と望ましい出力の組をいくつか示す方法も同じです。Anthropicのガイドは、例を、出力の形式、口調、構造を調整するうえで最も信頼できる方法の1つに挙げています。しかし、モデルは例に潜む、意図していないパターンまで一緒に学びます。

例を入れる前に、「この例の集まりが教えること」を2つの欄に分けて書いてみると、危険が見えてきます。

右列の内容が例の間で均等に混ざっていなければ、モデルはそれをルールと捉える場合があります。

よい例の条件

例の数については、ベンダーごとに重点を置く点が異なります。Anthropicは3〜5個を勧め、例の関連性や多様性をモデルに評価させたり、追加の例を作らせたりすることもできると付け加えています。Geminiのガイドは、常に例を入れるよう勧める一方、多すぎると応答が例に過度に合わせられる過学習が起こる場合があると警告しています。OpenAIの推論モデルのベストプラクティスは、まず例なし（zero-shot）で試すよう求めています。その一方で、長いコンテキストに数百個の例を入れる方法（many-shot）が、特定のタスクではファインチューニング済みモデルと同程度の性能を出したという、Googleのドキュメントの説明もあります。まとめると、「内容は異なるものに、形式はまったく同じに、数は実験で決める」ということです。例を少しずつ増やしながら、同じ評価セットで測定し、得点が伸びなくなるか、出力が例の文に似てきたら止めます。

多様性を設計する表

「多様に」は、第1章で見た、判定できない表現です。例を選ぶ際は、多様性をいくつかの軸に分けて、表を埋めます。

表の空欄こそ、次に探すべき例です。実際のログから空欄に合う入力を探し、個人情報を削除したうえで入れます。

境界事例と対照ペア

簡単な例は、モデルもすでに正しく答えられます。判断基準を教えるのは、迷いやすい例です。「箱はつぶれているが、商品はまだ開けていない」は、配送の問題でしょうか、それとも交換の依頼でしょうか。こうした境界事例に正解を付けて示すと、モデルは2つのカテゴリを分ける線がどこにあるかを学びます。

境界をさらに明確にするには対照ペアを使います。ほぼ同じ入力が、小さな違い1つで異なるラベルになる組です。

<examples>
  <example>
    <input>届いた靴の片方のかかとが外れています。同じサイズに交換してください。</input>
    <label>交換</label>
  </example>
  <example>
    <input>届いた靴の片方のかかとが外れています。返金してほしいです。</input>
    <label>返金</label>
  </example>
</examples>

誤った出力を例として見せる方法には、注意が必要です。誤った形式を長く示すと、その形式がコンテキストに強く残り、かえって真似してしまうことがあります。誤答例がどうしても必要なら、短くし、「このようにはしない」という表示と理由を添え、そのすぐ後に正しい例を置きます。基本は、望む結果を示すことです。

例による偏りを減らす手順

例による偏りとは、例の集まりの偏りによって、モデルの判断が傾く現象です。よくある種類は3つです。特定のラベルが多いためにそのラベルへ偏る場合、例の順序や最後の例に結果が引っ張られる場合、そして例の文言をそのまま写す場合です。次の手順で診断し、偏りを減らします。

1. 症状を数値で確認する。 ラベル別正答率と出力ラベル分布を実際の分布と比較する。特定ラベルが実際より多ければ偏りである。
2. 例を多様性の表に照合する。 偏ったラベルが例でも多いか、文体や長さが片寄っているかを見る。
3. 一度に1つだけ変える。 ラベルのバランスを整える、順序を混ぜる、文体を混ぜる、のうち1つを変え、同じ評価セットでもう一度測定する。
4. 模倣を確認する。 生成タスクでは出力と例の文の重なりを数える。重なるなら例ごとの表現を変え、「例は構成と口調を示すもので、文を転記しない」と理由付きで書く。
5. 安易に例外ルールを追加して対処しない。 Anthropicのコンテキストエンジニアリング記事の助言どおり、長い例外一覧より、まず代表的な例の組を選ぶ。

例と評価データを混ぜない

例を選ぶ元のデータと、評価セットを作る元のデータが、同じログであることはよくあります。このとき、例として使った入力が評価セットに残っていると、モデルは正解を見た問題をもう一度解くことになり、得点が実際よりも高く出ます。手順は次のとおりです。まず、評価用の入力を別に取り分けて固定し、残りの入力から、多様性の表を埋める例を選びます。例を変えるたびに、評価用の入力と重なっていないかを確かめます。第5章では、この原則を「改善用セットと確認用セットの分離」として再び扱います。

XMLタグで境界を引く

プロンプトの中で、指示、参考資料、例、ユーザー入力が混ざると、モデルが参考資料の中の文を指示と誤解することがあります。Anthropicのガイドは、内容の種類ごとに<instructions>、<context>、<input>のようなタグで囲むと、誤解が減ると説明しています。タグは、書類フォルダの色付きインデックスのような役割を果たします。

<instructions>
見積依頼メールを読み、依頼品目と希望納期を抽出する。
</instructions>
<price_policy>
見積の有効期間は発行日から30日とする。
</price_policy>
<email>
{{CUSTOMER_EMAIL}}
</email>

タグを使う原則は単純です。

• 決まったタグ名はありません。中身がわかる名前を選び、一度決めたら変えません。
• 階層がある内容は入れ子にします。複数文書なら<documents>内に<document index="1">を置き、OpenAIの例のようにXML属性でメタデータを付けて指示から参照できます。
• タグの役割は境界を明示することにとどまります。出力形式は別に指定する必要があり、タグはセキュリティの壁にもなりません。外部資料に</email>などが混ざって境界を壊す可能性がある場合、第3章で扱うようにJSONで包むほうが安全です。
• OpenAIとAnthropicは、Markdown見出しも区分の手段として挙げています。1つのプロンプトでは方式を統一します。

受け手に合う形式を選ぶ

形式を決める最初の問いは「この出力を誰が受け取るか」です。

人向け説明と機械向けデータを同時に受け取るなら、説明を決まったタグ、データを別フィールドに置くか、呼び出しを分けます。説明文がデータに混入すると、構文解析（パース）に失敗します。

データ辞書と欠損値の表現

フィールドの名前だけを決め、意味を決めておかなければ、同じフィールドにも、人やリクエストごとに異なる内容が入ります。スキーマを書く前に、まずデータ辞書を作ります。

特に大切なのは、「ない」を1つにまとめないことです。原文に情報がない場合、項目自体が該当しない場合、根拠が足りず判断できない場合は、その後の業務での意味が異なります。3つにそれぞれ異なる値を定め、指示とスキーマの説明の両方に記します。必須の文字列フィールドだけを設けると、モデルは情報がなくても、もっともらしい値を埋めようとします。値がない可能性があるフィールドは、nullを許容するようにスキーマを作る必要があります。

構造化出力：形式を強制する機能

出力形式を固定する方法には3段階あります。

OpenAIはJSONモードと構造化出力を区別しています。どちらも有効なJSONを作りますが、スキーマ遵守を保証するのは構造化出力だけであり、可能ならそちらを勧めています。要件はベンダーで少し異なります。

分類では許容ラベルをenumで定義します。Anthropicはenumフィールド付きツールか構造化出力を勧める一方、enum値の大文字・小文字は保証されないため、大文字・小文字を区別せずに比較し、大文字・小文字の違いしかない値を定義しないよう求めています。

形式の遵守と内容の正確さは別

構造化出力が保証するのは、形です。内容が正しいかどうかまでは保証しません。OpenAIのドキュメントは、構造化出力にも誤りが含まれうることを明記し、指示を整える、例を与える、タスクを単純な下位タスクに分ける、といった方法を勧めています。そのため、機械が読む出力は、4段階で検査します。

1. 構文： JSONとして解析できるか。
2. スキーマ： フィールド、型、enumが正しいか。対応していないために強制できなかった制約（最大値、長さ）は、この段階でコードによって確かめる。
3. 業務ルール： 納期は今日より後か、品目コードはコード表にあるか。
4. 原文照合： 値が原文に実際に存在するか。サンプルを抽出して人が確認するか、原文の文字列検索によって確かめる。

プリフィルの原理と代替手段

プリフィル（prefill）は、assistantメッセージの前半をあらかじめ埋めておき、その後をモデルに続けさせる手法です。たとえば、最後のassistantメッセージを{で埋めると、モデルはJSONの残りを続けて書きます。モデルが次の文字を予測しながら文章を書くという性質を利用し、書き出しを固定する方法でした。

Anthropicのドキュメントによると、Claude 4.6モデル以降、そしてClaude Mythos Previewでは、最後のassistantターンのプリフィルには対応しなくなり、そのようなリクエストは400エラーを返します。以前のモデルは引き続きプリフィルに対応しており、会話の途中にassistantメッセージを入れることは影響を受けません。ドキュメントは、モデルの指示に従う能力が向上し、大半の用途ではプリフィルが不要になったと説明したうえで、用途ごとの移行方法を示しています。

モデルを変更する際、最初に点検すべき項目がプリフィルです。エラーが起きる場所が明確なので見つけるのは簡単ですが、プリフィルが担っていた役割を何で代替するかは、上の表のように、用途ごとに別々に決める必要があります。

根拠フィールドには短い説明を

判定結果とともに、根拠も受け取りたいことはよくあります。このとき設計することは2つです。1つ目は、フィールドの順序です。モデルは先頭から順に書くため、根拠を先に、判定を後に書かせると、判定が根拠に基づくようになります。OpenAIの構造化出力はスキーマのキーの順序に従い、Anthropicは必須プロパティを先に出すため、順序を守るには、すべてのプロパティを必須にするか、順序の変更を考慮して解析します。

2つ目は、根拠フィールドに何を求めるかです。思考機能を持つ最新のClaudeモデルでは、reasoning、thinking、traceのようなフィールドに段階ごとの思考過程を書くよう求めると、reasoning_extractionカテゴリの拒否が返ることがあります。公式ドキュメントは、代わりに短い説明や結果を裏付ける証拠を求めるよう案内しています。フィールド名も、evidence、explanationのように、何を求めているかがわかる名前にします。第4章で、この話題を再び扱います。

さらに深く

思考機能のあるモデルには方法を見せる

思考（thinking）機能のあるモデルでも、例は効果を発揮します。Anthropicのドキュメントは、解法の例が、モデルが思考ブロックの中で類似の問題に取り組む方法を形作ると説明し、各例を「問題、適用する方法、期待する答え」という形で示すよう勧めています。入力と答えだけを示す例は、答えの形だけを教えますが、方法まで示す例は、会社固有の計算ルールのように、モデルが一般知識では知りえない手順を教えます。

方法を示す場合でも、最終的な回答は、決めたフィールドやタグからだけ取り出すように指示すれば、説明と回答が混ざって解析に失敗することを防げます。

表示環境が書式を決める

モデルの既定書式が表示環境に合わなければ、ユーザーには記号がそのまま見えます。Markdown非対応画面にアスタリスクやハッシュ記号がそのまま表示されるのが典型です。Anthropicは最新モデルが数式にLaTeXを既定で使うとし、平文が必要ならLaTeXやMathJaxの代わりに/、*、^などだけで表す指示例を提供しています。

書式を直すときも第1章の原則を適用します。

1. 禁止より望む書式を伝える。「Markdown禁止」より「滑らかな段落で」とする。
2. 理由を添える。「この画面は書式を描画できず、星印が文字として出る」とする。
3. プロンプトの書式を、望む出力に合わせる。平文の出力を望むなら、プロンプトからも見出しと箇条書きを取り除く。
4. 後処理は最後の手段とする。正規表現で記号を除くと、数式の乗算記号など必要なものまで消しかねない。

実務の場面

あさひ医院：受付メモをカルテの入力欄へ

地域の病院「あさひ医院」は、看護師が受付窓口で書いたメモから、症状、発症時期、服用薬を抽出し、電子カルテの入力欄にあらかじめ入れようとしています。最初のプロンプトは、「次のメモから情報をJSONで抽出して」という指示と、2つの例でした。運用してみると、ときどきonsetというフィールド名がstart_dateに変わり、服用薬がないときはフィールド全体が抜け落ちました。メモに時期が「数日前から」としか書かれていない場合には、具体的な日付が創作されて入っていました。

情報チームのソさんは、原因を3つに分けました。第1に、2つの例がどちらも服用薬があり、時期も明確なメモだったため、「ない場合」と「曖昧な場合」の形を示していませんでした。第2に、指示と例だけでは、フィールド名とその存在を保証できません。第3に、onsetが必須の日付フィールドだったため、モデルが値を空にしておく方法がありませんでした。

ソさんは、まずデータ辞書を作りました。onsetは「患者が述べた症状の開始時期」です。メモに日付があれば日付を入れ、「3日前」のような相対表現しかなければ、原文の表現をonset_textにそのまま入れ、onsetはnullにします。服用薬については、「ないと述べた」（空配列）と「メモに言及がない」（null）を区別しました。看護師が次の問診で尋ねる必要があるのは、まさに後者だからです。

次にソさんは、多様性の表に合わせて例を4つに増やしました。薬はないと述べたメモ、薬への言及がないメモ、時期が相対表現になっているメモ、症状が複数あるメモです。4つの例すべてに、同じタグと同じフィールド順を使います。メモの原文は<memo>タグで囲み、指示から分離しました。カルテへの入力はシステムが直接読むため、構造化出力でスキーマを強制し、onsetは日付またはnullを許容するように変えました。

チームの1人が、日付を抽出できなければ受付日を入れようと提案しましたが、ソさんは採用しませんでした。受付日は症状の開始日ではなく、もっともらしい値が埋まっていると、医師が確認せずに見過ごす可能性があったからです。最後に、停止理由を先に確認し、正常に終了した場合だけカルテに入力するようにしました。また、1日10件のサンプルは、看護師に原文と照合してもらうようにしました。その後、フィールド名が変わったり、抜けたりすることはなくなり、創作された日付もサンプルからは見つかりませんでした。例は判断の境界を、スキーマは形を、データ辞書は意味を担うように、役割を分けたことが要点でした。

かどオフィス：施設苦情の分類の偏りを直す

シェアオフィス運営会社「かどオフィス」は、入居企業がアプリで送ってくる施設の苦情を、「設備故障、清掃、騒音、入退室・防犯、その他」の5つのラベルに分類し、担当チームへ自動的に割り振っています。2週間の試験運用で、担当チーム長たちの不満がたまっていました。設備チームには見当違いの苦情が集中し、騒音の苦情は繰り返し「その他」に分類されていたのです。

運営企画担当のチャさんは、人が分類し直した400件と、モデルの分類を比較しました。モデルは、実際よりもはるかに頻繁に「設備故障」を選んでいました。例を多様性の表に照合すると、原因が見えてきました。5つの例のうち3つが設備故障で、5つとも長い敬語の文であり、最後の例も設備故障でした。一方、実際の苦情は、「3階の会議室の横がうるさすぎる」のような短い文が半数を超えていました。

チャさんは、修正する前に、400件のうち150件を評価用として取り分けて固定しました。残りの250件から、多様性の表の空欄を埋める例を選びました。各ラベルにつき1つ以上、短い文と長い文、そして2つの境界事例を入れました。1つは「エアコンの音が大きすぎて通話ができない」というもので、騒音に見えますが、原因が機器なので設備故障です。もう1つは「廊下でずっと大声で通話している人がいる」というもので、こちらは騒音です。2つの例には、ラベルとともに「原因が機器なら設備故障」という短い理由を添えました。例の順序も、同じラベルが続かないように混ぜました。

出力は割り振りシステムが直接読むため、構造化出力でlabelをenumに強制しました。また、担当チーム長が確認できるように、evidenceフィールドには、判断の根拠となった苦情中の表現を短く転記させました。思考過程を書くフィールドは作りませんでした。

検討会議では、「ラベルごとに例外ルールを付け加えよう」という意見が出ました。しかし、チャさんは、まず例の構成だけを変えた版を評価することにしました。ルールと例を一度に変えると、何が効果を上げたのかわからなくなるからです。固定しておいた150件で比較すると、騒音の苦情の正答率が大きく上がり、設備故障への偏りが減りました。残った誤りの大半は、「その他」と別のラベルの境界に関するものでした。チャさんは、その種類だけを選び、次の修正対象として記録しました。

間違えやすいポイント

• 例は多いほどよい。 同じ種類を増やすと偏りだけが強まり、多すぎると過学習します。数は実験で決めます。
• 例がよければ評価も信頼できる。 例の入力が評価セットに混ざると得点が膨らみます。評価入力を先に分けます。
• 入力にタグを使えば、出力も構造化される。 出力形式は別に指定する必要があり、機械が読む出力はスキーマで強制します。
• JSONモードならフィールドも守る。 JSONモードは構文のみ、フィールドと型は構造化出力が保証します。
• スキーマを守れば、値も正しい。 構造化出力は形を保証するだけで、内容は保証しません。業務ルールと原文照合は、別に検査します。
• 必須フィールドにすれば、欠落しなくなる。 情報がないのに必須にすると、もっともらしい値が創作されます。値がない可能性があるものには、nullを許容します。
• プリフィルはどこでも使える。 最新Claudeでは400エラーになります。用途別の代替へ移します。

ひと目でわかるまとめ

公式ドキュメントで確認する

• Anthropic — Prompting best practices：「Use examples effectively」「Structure prompts with XML tags」「LaTeX output」「Migrating away from prefilled responses」を読む。
• Google — Prompt design strategies：few-shot例の個数と形式の一貫性を読む。
• OpenAI — Structured model outputs：JSONモードとの違い、必須フィールドとadditionalPropertiesの規則、拒否処理を確認する。
• Anthropic — Structured outputs：output_config.formatとstrictツール、非対応のスキーマ機能、プロパティ順を見る。
• Anthropic — Refusals and fallback：reasoning_extractionの拒否と適切な根拠の求め方を読む。

セルフチェック

2-1. 例が「教えたいこと」と「偶然教えてしまうこと」を、それぞれ2つ挙げてください。

2-2. 例を選ぶ元のデータと、評価セットを作る元のデータが、同じ1つのログしかありません。作業の順序をどう決めるべきかを書き、その順序を逆にした場合、どのような問題が生じるか説明してください。

2-3. 「以下のイベント問い合わせに返信の下書きを書け。雨なら屋内体育館へ移動する。問い合わせ：…」を、指示・方針・入力が分かれるようタグで書き直してください。

2-4. 同じ売上データを、（ア）役員報告画面、（イ）店内放送、（ウ）在庫システムへの取り込み用に出します。それぞれ適した形式と注意点を1つ書いてください。

2-5. 出張費精算書から「同行者名一覧」（文字列配列）を抽出します。同行者なしと明記、同行の有無の記載なし、文字がにじんで読めない、の3つをそれぞれどの値で表すか、理由とともに決めてください。

2-6. 構造化出力でもスキーマに合わない場合を2つ挙げ、解析前の確認事項を書いてください。

2-7. 最後のassistantメッセージを先に埋める3つのプロンプトがあります。用途は（ア）ラベル1つだけを出す、（イ）冒頭の挨拶をなくす、（ウ）中断した長文を続ける、です。最新Claudeへの移行時に何で代替するか書いてください。

実習課題