ClaudeのFew-shot例を選ぶ：正解例だけでなく境界例を入れる

似た例を増やす前に境界を探す

問い合わせ分類なら、障害報告と使い方相談の境界を考えます。「ログインできない」は障害かもしれませんが、必要な権限を持っていないだけかもしれません。入力にない原因を決めつけず、追加確認へ回す例を含めると、保留の使い方を示せます。

例示は分類規則の代わりではありません。ラベルの定義が曖昧なまま例だけ増やすと、担当者の過去の判断のばらつきまで学習させる形になります。先に規則を言語化します。

内容と表現の偶然を切り離す

ある部署名や語尾が毎回同じラベルに付くと、本来の意味ではなく表面的な手掛かりに頼る可能性があります。短文と長文、丁寧語と口語、誤字のある入力を混ぜ、同じ意味なら同じ扱いになるか確認します。

出力例にも理由の長さや欠損値の扱いをそろえます。ただし個人名や実顧客の情報をそのまま教材化せず、判断条件を保った架空例へ置き換えます。

調整に使った例とは別で評価する

プロンプトに載せた例で高得点が出ても、未知の入力に対応できる証拠にはなりません。例示用、調整用、確認用を分け、確認用を何度も見て改良した場合は新しい確認例を用意します。難しい例だけでなく、普通の入力を壊していないかも見ます。

例の一部を抜いて感度を確認する

例示の数を増やす前に、境界例を一つ外した場合と、似た通常例を外した場合を比較する計画を作ります。どの例がどの入力へ効くかを考えると、役割が重複した例を大量に抱えずに済みます。この比較で得た傾向も、少ない入力だけから一般化しすぎず、確認用の入力群で確かめます。例の多さをそのまま改善の根拠にはしません。

ラベルと一緒に理由を書く場合、理由が本当に判断規則と対応しているかも確認します。正しいラベルへ後付けした説明を増やしても、未知の入力への適用が安定するとは限りません。同じ表面的な単語で別のラベルになる例と、違う表現でも同じラベルになる例を組にし、意味の境界を伝えるために使います。

具体例で考える

説明用の分類：住所変更は手続き、宛先不明は確認待ちと定義します。

例A：「配送先を大阪へ変えたい」→手続き
例B：「どこに送ったか分からない」→確認待ち
境界例：「住所を変えたはずだが届かない」→確認待ち（配送状態が未確認）

境界例では「住所」という単語だけで分類しません。必要な状態が足りないことが理由です。同じ構造で語彙を変えた確認用の例を作り、ルールが意味に対して働くかを確認します。

確認課題と合格の目安

二つの近いカテゴリに、通常例、境界例、保留例を一つずつ作ってください。

• カテゴリ定義を例から独立して説明できる。
• 同じ意味の言い換えを扱える。
• 評価用の例をプロンプトへ混ぜていない。