few-shot promptingと出力一貫性

Few-shot promptingは、CCA-F受験者が適用を期待される中で最もレバレッジの高いプロンプトエンジニアリング技法だ。Claude Certified Architect — Foundations（CCA-F）試験のタスクステートメント4.2——「出力の一貫性と品質を向上させるためにfew-shot promptingを適用する」——は、Domain 4（Prompt Engineering & Structured Output、配点20%）の中に、明示的基準設計（4.1）、tool useによる構造化出力（4.3）、検証/リトライループ（4.4）と並んで位置する。Few-shot promptingは、新しいコードを書いたり、モデルに触れたり、インフラを追加したりすることなく出力品質を最も確実に向上させる技法だ。だからこそ強力であり、試験はあなたがいつ、どのように、どれだけの例を含めるかを理解しているかを繰り返し探る。

この学習ノートでは、CCA-F受験者がアーキテクチャレベルで設計しなければならないfew-shot prompting の全表面を解説する。in-context learningとしてのfew-shot promptingの公式定義、zero-shot/one-shot/few-shotのスペクトラム、2〜5例のスイートスポットとそれを超えた逓減効果、例の選択基準（多様性、境界カバレッジ、肯定対否定ケース）、フォーマット一致の規律、例がスタイルとフォーマットを固定するメカニズム、否定的な例の役割、配置の決定（システムプロンプト対ユーザーメッセージ）、動的few-shotの取得、分類固有のパターン、3つの構造的限界（コンテキストコスト、例のドリフト、陳腐化）。罠のセクションとFAQが、few-shot promptingが最も多く出題される4つの試験シナリオにすべての概念を結びつける。

Few-Shot Promptingとは何か？ プロンプトのコンテキストに作業済みの例を提供する

Few-shot promptingとは、Claudeが指示だけではなく例から直接タスクのパターンを推論できるように、2つ以上の完全な入出力の例をプロンプト内に含める実践だ。例が学習シグナルだ。タスクの説明はそれらの周りの短いフレームになる。各例は対になったデモンストレーションだ——こんな種類の入力が来る。これがあなたが生成すべき正確な出力だ。Claudeは例から、後続の実際の入力へと一般化する。

Few-shot promptingはin-context learningの一形態だ。モデルは現在のリクエストの期間だけ一時的にパターンを習得し、重みの更新はない。何もトレーニングされず、何も保存されず、リクエスト間で何も永続しない。同じ振る舞いが必要な新しいリクエストはすべて、同じ例を再度含めなければならない。この一時性こそが、few-shotがfine-tuningの代替ではなく、CCA-Fがテストする大多数の本番パターンに対してはるかに安く、速く、柔軟な代替である理由の全体だ。

CCA-FがFew-ShotをDomain 4に置く理由

Domain 4は試験の20%を占め、6つのタスクステートメントに均等に分かれる。Few-shot prompting（4.2）は、すべての下流タスク——構造化出力（4.3）、検証ループ（4.4）、バッチ処理（4.5）、マルチパスレビュー（4.6）——がClaudeに一貫した出力形状を生み出させることに依存するため、明示的基準（4.1）に続いてドメイン内で2番目に最もテストされるタスクだ。Few-shotはその一貫性を強制する最も安く最も普遍的に適用可能なメカニズムだ。コミュニティの合格レポートは繰り返し「指示が機能しないときに例の使用が不足している」を繰り返す選択肢の誤りのパターンとして特定する。受験者は「より多くの指示を追加する」を選ぶが、正しい答えは「2つの作業済みの例を追加する」だ。試験は追加の散文の前に例に手を伸ばす受験者に報酬を与える。

Few-ShotはFine-tuningではない

Fine-tuningはキュレーションされたデータセットでモデルの重みを更新し、新しいモデルのチェックポイントを生み出す。Few-shot promptingは単一のリクエストのコンテキストに例を注入し、ベースモデルを変更しない。CCA-Fでは、few-shotを「あなたの例でClaudeをトレーニングする」またはfine-tuningの代替としてフレームする答えは誤りだ。試験はfine-tuningを範囲外として明示的にリストし、few-shot問題には常に2つを混同する選択肢の誤りが少なくとも1つある。正しいメンタルモデル：few-shotは速く、繰り返しが自由で、一時的だ。fine-tuningは遅く、高コストで、恒久的だ。

Zero-Shot対One-Shot対Few-Shot——各戦略が適切な場合

3つのプロンプティング戦略は例の密度のスペクトラムを形成する。それぞれに正しいユースケースがあり、スペクトラム上の間違った点を選ぶことが繰り返しCCA-Fの選択肢の誤りだ。

Zero-Shot Prompting

Zero-shot promptingには作業済みの例がゼロだ。プロンプトはタスクの指示と場合によっては参照資料、そして実際の入力で構成される。次の場合にzero-shotを使用する。

• タスクが短い自然言語の説明で明確に定義されている（例：「この記事を3文で要約する」）。
• 出力フォーマットがフリーフォームの散文または広く知られた構造だ（例：よく知られたスキーマの有効なJSONオブジェクト）。
• 例のコスト（コンテキストトークン、作成時間）が品質の向上によって正当化されない。

Zero-shotは探索的なプロトタイピングと、Claudeの事前学習された振る舞いがすでにターゲットに近いタスクの正しいベースラインだ。

One-Shot Prompting

One-shot promptingには正確に1つの作業済みの例が含まれる。次の場合に有用な中間点だ。

• タスクに1つのデモンストレーションが完全に説明する非常に特定の出力フォーマットがある（例：単一の請求書の明細項目）。
• コンテキストの予算が少なく、1つの例しか収まらない。
• 例が役立つかどうかをテストしてから、完全なfew-shot投資にコミットする。

1つの例はフォーマットを強く固定するが、境界ケースについてはほとんど情報を提供しない。Claudeはしばしば1つの例の正確な表現と構造を少し過剰に再現する——「one-shotの過剰模倣」と呼ばれることがある現象だ。

Few-Shot Prompting（2例以上）

Few-shot promptingには2つ以上の作業済みの例が含まれる。これはin-context learningが最も効果的に機能する領域だ。複数の例は以下を実現する。

• タスクが処理しなければならない入力の範囲を示す（1つのインスタンスだけではなく）。
• 変動を伝える——出力のどの部分が変わり、どの部分が固定されているか。
• 決定の表面を確立する——単純なケースの間に落ちる入力をどのように分類またはルーティングするか。
• 共通の構造が例の多様性から明確になるため、one-shotの過剰模倣を大幅に削減する。

決定ヒューリスティック

タスクの説明が明確でClaudeのベースライン振る舞いがすでに適合しているなら、zero-shotから始める。1つのデモンストレーションがフォーマットを完全に固定するなら、one-shotを試す。タスクに何らかの決定の表面、エッジケース、またはフォーマットの微妙さがある場合——ほぼすべてのCCA-Fシナリオにはそれがある——2〜5の例でfew-shotを使用する。

例の数のガイダンス——実用的なスイートスポットとしての2〜5例

Anthropicのmultishot promptingガイダンスは、ほとんどの本番タスクの実用的なスイートスポットとして3〜5の例を推奨する。コミュニティの合格レポートはタスクの複雑さに応じてやや広い2〜5の範囲に収束する。この範囲が機能する理由——そしてなぜ多ければ多いほど良いことはほとんどないか——を理解することがCCA-Fで繰り返しテストされる。

2例——最小限の実行可能なfew-shot

2つの例は共有された構造を示すのに十分だ。Claudeは2つの出力全体で何が一定か（フォーマット、フィールドの順序、トーン）と入力によって何が変わるかを見る。2つの例はone-shotの過剰模倣を避けるための最小限だ。

3〜5例——本番のスイートスポット

3〜5の例は共通ケース、1〜2のエッジケース、そして通常は少なくとも1つの対比ケースをカバーする。ここでin-context learningが最も強い品質の向上を示す。3番目の例の限界便益は2番目の例を大幅に上回ることが多い。6番目の例の限界便益は5番目の例を大幅に上回ることはほとんどない。

6例以上——逓減効果

おおよそ5例を超えると、追加の例は通常出力品質を意味のある形で向上させない。確実に追加するのは以下だ。

• すべてのリクエストでの入力トークンコスト。
• コンテキスト長に比例した入力処理レイテンシ。
• 追加の例が特定のパターンに偏っている場合の固着バイアスのリスク。
• 例のブロックが十分に長くなり、中間ブロックの例がアテンションを受けにくくなる**「ロスト・イン・ザ・ミドル」の圧力**。

なぜ質が量を上回るか

重要なエッジケースをカバーする1つの慎重に選ばれた例は、すべて同じ簡単な共通ケースを示す3つの冗長な例より多く貢献する。コミュニティの合格レポートは「出力がまだ誤っているときに似たような例を追加する」を一般的な行き詰まりとして特定する。品質が不十分なときの正しい動きは通常、別の種類の例を追加することだ——境界ケース、否定的な例、対比ペア——同じ簡単なケースの5回目の繰り返しではない。

例の選択基準——多様性、境界カバレッジ、肯定と否定のケース

どの例を含めるかを選ぶことは、多くの場合、何個含めるかを選ぶことより難しい。3つの基準が選択を推進する。

多様性

例は、タスクが本番で直面する入力空間をカバーすべきだ。実際の入力が4つの文書タイプにまたがっているなら、few-shotのブロックには1つの文書タイプの4つの例だけを含めるべきではない。多様性は、Claudeが入力分布の狭いスライスに対してin-contextのパターンをオーバーフィットすることから保護する。

実際には、多様性とは次を意味する。

• 入力の長さの多様性 — 本番がすべてを見るなら、短い、中程度、長い入力。
• 入力構造の多様性 — 異なるフォーマット、異なるフィールドの順序、異なるボイラープレート。
• 結果の多様性 — タスクが分類の場合、同じクラスの3つの例ではなく、複数のクラスの例を含める。
• ドメインの多様性 — タスクが複数のドメイン（医療、法律、小売）にまたがっているなら、ドメインごとに少なくとも1つの例を含める。

境界カバレッジ

エッジケースは費やされるコンテキスト単位あたりの価値が最も高い例だ。「入力が曖昧なときに何をするか」「入力が空のときに何をするか」「入力が矛盾するときに何をするか」を示す例は、Claudeが伝えられない決定ルールを教える。

考慮すべき境界ケース：

• 欠落フィールド — 必要な情報が欠けている入力。
• 競合するシグナル — 2つの方向に引く入力。
• 近似マッチ入力 — タスクに一致するように見えるが実際はそうでない入力。
• 退化した入力 — 空文字列、空白のみ、繰り返しトークン。

1つの境界例は3つの追加の典型的な例より多くの本番バグを修正することが多い。

肯定的と否定的なケース

肯定的な例はターゲットの振る舞いを示す。否定的な例はすべきでないパターンを示す。通常、修正と対にされる。否定的な例は分類、コンテンツモデレーション、構造化抽出において強力だ——「含める」と「除外する」の間の境界線が重要なすべてのタスクで。

否定的な例は単に誤った答えではない。Claudeに望ましくない出力を明示的に示すラベル付きの例だ。これにより、Claudeは境界線の感覚を研ぎ澄ますことができる。セクション7で否定的な例をより深くカバーする。

例のフォーマット一貫性——所望の出力フォーマットに正確に一致させる

Claudeはあなたの例の正確なフォーマットを再現する。これはfew-shotが出力の一貫性を強制する主要なメカニズムだ——そしてそれはあなたの例のすべての表面的な詳細が重要であることを意味する。

正確なフォーマット一致が意味すること

あなたの例がフィールドの順序 id、name、amount のJSONを使用しているなら、Claudeは出力でその正確なフィールドの順序を強く好む。あなたの例がsnake_caseのキーを使用しているなら、Claudeはcamelに切り替えない。あなたの例が <result>...</result> XMLタグで出力を包んでいるなら、Claudeは同じタグを生成する。あなたの例が小文字のenum値を使用しているなら、Claudeは大文字を発行しない。

なぜこれが機能なのか

強制されたマッチはまさにfew-shotを一貫性に有用にするものだ。「snake_caseのキーと小文字のenum値とこの正確なフィールドの順序を使ってください」と言う散文の指示を書くことは、冗長で脆く、しばしば不完全だ。ターゲットのフォーマットで2つの例を示すことは、コンパクトで正確で解釈の余地を残さない。

なぜこれがまた罠なのか

自分の例全体での非一貫性はClaudeの出力に漏れ込む。例1が customer_id を使用し、例2が customerId を使用しているなら、Claudeは本番で2つを一貫性なく交互に使う。例1に末尾の改行があり例2にない場合、本番の出力は両方を混在させる。1つの例の単一のタイポが、Claudeが複製するかもしれないパターンになる。

規律のチェックリスト

few-shotのプロンプトを出荷する前に、すべての例を以下に対して確認する。

• 同一のフィールド名 — 同じ大文字小文字、同じスペル、同じ順序。
• 同一の空白規則 — 同じインデント、同じ末尾の改行ポリシー。
• 同一のラッパーマークアップ — 同じXMLタグ、同じMarkdownフェンス、同じデリミタ。
• 同一のトーン — 丁寧さ、冗長さ、挨拶の存在がすべて一貫している。
• 同一のnullの処理 — 欠落データの規則がすべての例で同じでなければならない。

出力一貫性メカニズム——例がフォーマットとスタイルを固定する方法

few-shot promptingからの一貫性の向上は魔法ではない。それはトランスフォーマーモデルが先行するコンテキストに条件付ける方法の直接的な結果だ。メカニズムを理解することで、few-shotが修正する問題とそうでない問題が明確になる。

大規模なパターン補完

トランスフォーマー言語モデルは先行するコンテキストが与えられた次のトークンを予測するように訓練される。プロンプトが例の入出力ペアのシーケンスに続いて新しい入力を提供するとき、最も確率の高い続きは同じ形状の別の出力だ——それがコンテキスト内のパターンが予測するものだからだ。Claudeは効果的に [input1 → output1, input2 → output2, ..., inputN → ?] というパターンを補完しており、? は前の出力の構造的な規則性によって強く偏っている。

例が確実に固定するもの

• 構造的フォーマット — JSON対XML対散文、フィールド名、フィールドの順序、ラッパータグ。
• 長さの分布 — 短い出力は短いままで、長い出力は長いままだ。
• トーンと文体 — 形式的、非公式、臨床的、友好的。
• 語彙の好み — 専門用語、略語、ブランドボイス。
• nullの処理規則 — 空文字列、nullリテラル、欠落キー、プレースホルダー。
• 分類の境界 — どの入力の特徴がどの出力ラベルにマップするか。

例だけでは修正できないもの

• ドメイン知識の事実の誤り — Claudeが事実を知らない場合、例はその事実を追加しない。
• ハードスキーマの検証 — few-shotはスキーマに向けて出力を強く偏らせるが保証しない。保証されたスキーマの適合性には、厳格なtool use（タスク4.3）と組み合わせる。
• 長文書の理解 — 入力が正確な処理には長すぎる場合、出力の例を追加しても入力側の問題は修正されない。
• 未見の入力分布での推論エラー — 例はそれらが表す分布でのみClaudeを導く。

CCA-Fへの含意

シナリオが出力フォーマットの問題（一貫性のないJSONの形状、一貫性のないトーン、ドリフトするフィールドの順序）を説明するとき、few-shotは通常正しい答えだ。シナリオが出力正確性の問題（誤った事実、保証されなければならない無効なスキーマ、幻覚されたコンテンツ）を説明するとき、few-shotは部分的な解決策であり、明示的基準（4.1）、厳格なtool use（4.3）、または検証ループ（4.4）と組み合わせなければならない。

否定的な例——所望しない出力を示してコントラストを研ぎ澄ます

否定的な例はClaudeがすべきでないことのラベル付きのデモンストレーションだ。ラベルのない誤った答えではない。修正または明確な「これではない」フレームと対にされた明示的にマークされた反パターンだ。否定的な例は許容できる出力と許容できない出力の間の境界線が重要なタスクに対するfew-shot promptingで最もレバレッジの高い技法の1つだ。

否定的な例が効果を発揮する場合

• コンテンツモデレーション — 微妙なポリシー違反を良性のコンテンツから区別する。
• ファジーラベルの分類 — 「スパム」と「プロモーションだが望まれている」、または「緊急」と「高優先度」を分離する。
• 曖昧さのある構造化抽出 — 入力がそれをサポートしていないときに値を抽出しないようClaudeを教える（「幻覚しない」境界）。
• トーン制御 — ターゲットが特定のレジスターのとき、過度に形式的または過度にカジュアルな出力を望ましくないとマークする。
• フォーマットの規律 — 微妙なルールで失敗する「ほぼ正しい」出力にフラグを立てる（迷い込んだ末尾のカンマ、間違った大文字小文字のキー）。

否定的な例の構造パターン

2つの一般的なフォーマット：

1. 対比ペア — 各例に誤った出力と正しい出力の両方が含まれ、明示的にラベル付けされる。

<example>
<input>Customer: "I want to speak to a human."</input>
<wrong_output>Have a nice day!</wrong_output>
<correct_output>I understand — connecting you to a human agent now.</correct_output>
</example>

2. 専用の否定的なブロック — いくつかの肯定的な例に続いて明確にフラグ立てられた否定的なもの。

<negative_examples>
<example>
<input>...</input>
<output>This output is wrong because it misses the escalation signal.</output>
</example>
</negative_examples>

比率のガイダンス

否定的な例はfew-shotのブロックの少数派であるべきだ——肯定的な例2〜3個につき否定的な例1個が合理的な比率だ。否定的な例が多すぎると、Claudeが入力を過剰に拒否するよう偏ることがある。目標はコントラストを研ぎ澄ますことであり、タスクを「悪い出力を避ける」と再フレームすることではない。

例の配置——few-shotの例のシステムプロンプト対ユーザーメッセージ

プロンプト内で例を物理的にどこに配置するかが、Claudeがそれらをどのように扱うかを形成する。CCA-Fはこの区別を繰り返しテストし、通常はシステムプロンプトの配置とユーザーメッセージの配置の選択として。

システムプロンプトの例

次の場合にシステムプロンプトに例を配置する。

• 例が会話のすべてのターンにわたってエージェントが使用すべき持続的なペルソナまたはスタイルを定義する場合。
• 例がセッション全体に適用されるツール呼び出しパターンを説明する場合。
• 例のコストをセッションごとに1回支払い（プロンプトキャッシングで）、多くのユーザーターンにわたって再利用したい場合。
• 例が任意の特定のユーザー入力から独立して再利用可能なテンプレートの一部である場合。

ユーザーメッセージの例

次の場合にユーザーメッセージに例を配置する。

• 例がタスク固有で特定のリクエストに付随する場合。
• 例が現在の入力に基づいて動的に選択される場合（セクション9参照）。
• 会話状態を償却する会話のない単一ターン呼び出しにMessages APIを使用している場合。
• 例が「タスクの作業済みの例はここにある、次はこの本物をする」というフレームを含む——古典的な単一ターンfew-shotパターン。

両方の配置のXMLタグ

Anthropicのプロンプトエンジニアリングガイダンスは、配置に関係なく明示的なXMLタグ（<examples>、<example>、<input>、<output>）で例のブロックを包むことを推奨する。XMLタグはClaudeに例の境界を明確にし、Claudeが例を指示や実際の入力から区別しやすくする。XMLタグを省略することは「Claudeが答える代わりにより多くの例を生成し始めた」バグのよくあるソースだ。

例の順序での固着バイアス

例の順序は重要だ。Claudeは以前の例より（実際の入力に最も近い）最も最近の例をより重く重み付けする。実際的な含意：

• 最も代表的な例を最後に置く、最初ではなく。
• 同じクラスの例を最後にクラスタリングするのを避ける——それは分類器を偏らせる。
• 分類については、グループ化するのではなくクラスをインターリーブする。
• 抽出については、期待される実際の入力構造に最も近い構造の例で終わる。

動的Few-Shot——入力の類似性に基づいてプログラム的に例を選択する

静的なfew-shotブロックはすべてのリクエストで同じ3〜5の例を使用する。動的few-shotは現在の入力への類似性に基づいて、各リクエストに異なる例を選ぶ。動的few-shotは、すべての呼び出しで20例のブロックを支払うことなく、最高品質の本番システムがfew-shotからより多くを絞り出す方法だ。

動的Few-Shotのパターン

1. キュレーションされた例ライブラリを維持する——本番入力分布全体をカバーする50〜500の作業済みの入出力ペアのセット。
2. リクエスト時に、現在の入力とライブラリ内のすべての例の間の類似度スコアを計算する（ベクトル類似度、BM25キーワードスコアリング、メタデータベースのルーティング）。
3. 上位K（通常3〜5）の最も類似した例を選択する。
4. その例を通常通りプロンプトに注入する。
5. リクエストを送信する。

なぜ動的Few-Shotが静的を上回るか

• より高い関連性 — Claudeが見る例は現在の入力に最も似ているもの。入力分布の固定されたサンプルではない。
• より良いエッジケースのカバレッジ — ライブラリは500のエッジケースをカバーでき、現在の入力に一致するものだけを浮上させる。
• より小さなアクティブコンテキスト — 巨大なライブラリを維持しながらも、リクエストごとに3〜5の例だけを支払える。
• より簡単なメンテナンス — 新しい例を追加することはライブラリへの追記を意味し、静的ブロックの再調整ではない。

動的Few-ShotがエンジニアリングコストのCOO収益に値する場合

動的few-shotは例のストア、類似度エンジン、すべてのリクエストでの取得ステップを必要とする——本物のエンジニアリング投資だ。次の場合に恩恵をもたらす。

• 各リクエストでの品質の向上が複利になる高ボリュームの本番ワークロード。
• 5例の静的ブロックが代表的でない非常に変動する入力分布を持つタスク。
• ユーザーフィードバックとともに例ライブラリが成長できる長寿命のプロダクト。

プロトタイプ、短命のツール、または低ボリュームのバッチ作業には、静的few-shotが正しいトレードオフだ。

範囲外の注記

CCA-Fは埋め込みモデルの内部とベクターデータベースの実装の詳細を範囲外としてリストする。試験は動的few-shotパターンを認識するかどうかと、それが適切な場合をテストする。ベクター検索エンジンを実装できるかどうかはテストしない。深いリトリーバルエンジニアリングの知識を必要とする答えは選択肢の誤りだ。「入力の類似性に基づいて例を選択する」を正しいアーキテクチャパターンとして特定する答えは通常正解だ。

分類のためのFew-Shot——暗黙の決定境界定義としての例

分類はfew-shot promptingが最も輝くタスクだ。例は文字通り決定境界だ。Claudeは明示的なルールなしに例だけからラベルのマッピングを推論する。

分類のFew-Shotパターン

K個のラベルを持つ分類器には、ラベルあたりおよそ1〜2の例を含める（したがって、小さな分類器で合計3〜8の例）。各例は (入力, ラベル) ペアだ。オプションの追加：

• ラベルの背後にある推論を示す簡単な rationale フィールド——ニュアンスのあるクラスに役立つ。
• ラベルに自然な順序がある場合の信頼度のヒント（低/中/高）。
• 隣接するラベル間の近似マッチケースの否定的な例。

なぜ例が分類でルールを上回るか

分類のルールは完全に書くのが難しい。「メッセージがアウタージまたはエンタープライズ顧客または怒りのトーンを言及する場合はurgentだ」は符号化できるルールだ。しかし実際の本番タクソノミーの「チケットが緊急なのは...」は通常、誰も列挙したくない何十もの曖昧な条件を持つ。代表的な例のひとつがページのルールでは捉えられない決定の表面を捉える。

順序バイアスを避けるためにクラスをインターリーブする

常に例のブロックでクラスをインターリーブする：

• 良い： urgent, normal, urgent, low, normal, low。
• 悪い： urgent, urgent, urgent, normal, normal, low。

最後にクラスをグループ化するとClaudeが最後のクラスに偏る。インターリーブはすべてのラベルにわたって順序効果のバランスを取る。

構造化出力との組み合わせ

分類には、Claudeが許可されたセットからラベルを返さなければならないように、tool useスキーマ（タスク4.3）とfew-shotを対にする。Few-shotはClaudeにマッピングを教える。厳格なtool useは答えが有効なラベルの1つであることを強制する。この組み合わせは、「分類を正確かつスキーマが保証されたものにする」ためのCCA-F試験の標準的な答えだ。

Few-Shotの限界——コンテキストウィンドウのコスト、例のドリフト、陳腐化

Few-shot promptingは無料でなく、万能薬でもない。CCA-Fでは受験者が3つの構造的限界を認識することを期待する。

コンテキストウィンドウのコスト

すべての例はすべてのリクエストで入力トークンを支払う。例あたり300トークンの5例のブロックは、実際の入力が届く前に1500の入力トークンを使う。低レイテンシの高ボリュームワークロードでは、このコストは本物だ。緩和策：

• プロンプトキャッシング — Anthropicのプロンプトキャッシング機能は繰り返しのリクエストにわたって例のブロックのコストを償却する。システムプロンプト内の静的なfew-shotブロックには、例はキャッシュヒットごとに1回支払われ、呼び出しごとではない。
• 動的few-shot — 毎回すべての例を送信するのではなく、より少なく、より関連した例を取得する。
• 例の圧縮 — パターンを伝えるのに必要な最小限に各例をトリムする（ボイラープレートを削除し、散文を短縮する）。

例のドリフト

例のドリフトは、タスクが時間とともに微妙に変わり、元の例がもはや現在のターゲットに一致しないときに起こる。症状：

• 本番の出力が少し古くなって見え始める——古いフィールド名、古いトーン、古いフォーマット規則。
• Claudeが古い例に正確に一致するが新しい仕様に違反する出力を時々生み出す。
• 例は1つのことを言い、ドキュメントは別のことを言う。

ドリフトはメンテナンスの問題だ。修正は例のブロックを第一級のアーティファクトとして扱うことだ。バージョン管理し、出力の形状に影響するすべての製品の変更でレビューし、評価の実行に含めて回帰が捕まえられるようにする。

陳腐化した例

陳腐化した例は、もはや現実と一致しないコンテンツを持つものだ——古いティアを参照する価格設定の例、古い住所を持つ場所の例、廃止されたSKUの製品の例。陳腐化した例はメンテナンスの問題だけでなく、Claudeが陳腐化したコンテンツを再現する。

• 具体的なものより抽象的なものを好む — 可能な場合、揮発性の事実に依存しないように例を構成する。「2024年のGoldプランのAcme Corp」より「ティアYの顧客X」。
• すべてのリリースで監査する — 陳腐化の検出は例を含むシステムプロンプトやスキルのリリースチェックリストに属する。

Few-ShotはFine-tuningではない（再び）

Few-shotのすべての限界は最終的に同じ根本に遡る。例はコンテキストに存在し、重みには存在しない。リクエストごとに支払われ、すべての呼び出しで再送信されなければならず、永続性がない。例のリクエストごとのコストが特定のワークロードで本質的に高すぎるとき、より広いClaudeエコシステムでの正しいエスカレーションパスは通常fine-tuning（CCA-Fで明示的に範囲外）ではなく、プロンプトキャッシング、動的few-shot、よりタイトな例の組み合わせだ。Few-shotのコストへの修正としてfine-tuningを推奨するCCA-Fの答えは定義上誤りだ。

やさしい解説: 抽象的なfew-shotの仕組みは、受験者がすでに知っている物理的なシステムに固定することで直感的になる。3つの異なる類比が技法の全範囲をカバーする。

類比1：料理場の修行生——作業済みの皿から学ぶ

1日目にラインクックが新人として入った。ヘッドシェフは20ページのルールブックを渡さない。シェフは彼らの前で2〜3皿を作り「こうやって皿に盛り付けろ」と言う。修行生は最初の皿を見て（例1）、2皿目を見て（例2）、そして自分でチケットを盛り付け始める。シェフが作る各皿は作業済みの例だ——同じガーニッシュの配置、同じソースのひと流し、同じ正確なポーション。3皿目までに、修行生の盛り付けはシェフと区別がつかない。シェフが「うまく盛り付けろ」と言って修行生に即興させたなら、すべての皿が違って見えるだろう。作業済みの皿がfew-shotの例だ。修行生がClaudeだ。一貫した盛り付けがfew-shotが提供する出力の一貫性だ。1皿では十分でないことに注目してほしい——修行生が過剰模倣する。20皿は無駄だ——修行生は3皿で学んだ。シェフの2皿がソースをどこに置くかで意見が合わない場合、修行生は永遠に2つのスタイルを交互にする。それがまさに例全体のフォーマットのドリフトがClaudeに行うことだ。

類比2：図書館の目録担当者——例によって示された分類

図書館で新しい目録担当者を訓練することを想像してほしい。タスクは入ってくる各本を5つのデューイ範囲のいずれかに割り当てることだ。完全なデューイ十進分類法を説明する代わりに、先輩司書は既に目録された5冊を渡す——デューイ範囲ごとに1冊——そして「これらが分類されたように入ってくる本を分類しろ」と言う。新入は規則を暗記しない。5つの例から一般化する。2つの範囲の間に落ちる本が来たとき、例と比較してより近いものを選ぶ。図書館にはバックルームに500冊の目録済みの本があり、難しいケースには先輩司書が現在のものに似た3冊を新入に参照させる。それが動的few-shotだ。同じ範囲の例5つより5つのインターリーブされた例の方が良い。悪い例——ずっと前に間違った範囲にファイルされた本——が新入に同じ間違いを犯すよう訓練する。Few-shotの分類は、暗記したルールではなく例によって示された図書館の目録担当者だ。

類比3：レシピカード——指示なしのフォーマットの一貫性

家族のレシピカードは例に偽装した仕様だ。「バターと砂糖をクリームにして、卵を1つずつ追加し、小麦粉を折り込む」と言う。そのカードを読んだ新しい料理人は、そのカードから作られたすべてのケーキと同じように見えるケーキを作る——同じ質感、同じ形、同じ食感。カードは「9インチの丸いパンを使う」と言う必要がない。棚に隣接するカードの例の出力が静かにパンのサイズを強制する。カードが「ケーキを焼く」とだけ言っていれば、出力は大きく変動するだろう。レシピカードは指示＋one-shotの例だ。同じケーキの3つのバリエーション（プレーン、レモン、チョコレート）を持つ料理本はfew-shotのブロックだ。料理本はレシピのどの部分が固定（方法）でどの部分が変動するか（風味付け）を教える。4番目のバリエーションを即興できる料理人がその料理本から出てきたとき、few-shotは機能した。その料理本を使う料理人がカード上の1つのケーキしか作れないとき、one-shotの過剰模倣が起きた。「呼び出し間で出力の形状が大きく変動する」と不平を言うCCA-Fシナリオはルールブックが欠けているのではなく料理本が欠けていることを説明している。

どの類比がどの試験問題に当てはまるか

• なぜ例が指示を上回るかに関する質問 → 料理場の修行生の類比。
• few-shotによる分類に関する質問 → 図書館の目録担当者の類比。
• 例からのフォーマット一貫性の向上に関する質問 → レシピカードの類比。

よくある試験の罠

CCA-F Domain 4はfew-shot promptingに関して6つの繰り返しの罠のパターンを一貫して悪用する。すべて6つがコミュニティの合格レポートで「もっともらしいが誤り」の選択肢の形として現れる。

罠1：Few-ShotとFine-tuningを混同する

Few-shot promptingはin-context learningだ——プロンプト内の例、重みの更新なし、永続性なし。Fine-tuningはキュレーションされたデータセットでモデルの重みを更新し、新しいチェックポイントを生み出す。CCA-F試験はfine-tuningを明示的に範囲外としてリストする。few-shotを「あなたのデータでClaudeをトレーニングする」または「Claudeに新しい振る舞いを永続的に教える」とフレームする答えは誤りだ。Few-shotは速く、繰り返しが自由で、一時的だ。Fine-tuningは遅く、高コストで、恒久的だ。

罠2：より多くの例は常により少ない例を上回る

Anthropicのガイダンスは実用的なスイートスポットとして3〜5の例を特定する。おおよそ5例を超えると、限界的な品質の向上は小さくなり、コンテキストコスト、レイテンシ、ロスト・イン・ザ・ミドルのリスクが増大する。「できるだけ多くの例」または「少なくとも10例」を推奨する答えは誤りだ。例の質が量を上回る——重要なエッジケースの例1つが3つの冗長な肯定的な例より多くのバグを修正できる。

罠3：例のフォーマットの一貫性を無視する

Claudeは例の正確な表面フォーマットを再現する。例がフィールドの大文字小文字、フィールドの順序、nullの処理、またはラッパーマークアップについて意見が合わない場合、本番の出力は競合する規則を交互に使用する。試験シナリオが「出力フォーマットが実行間で一貫性がない」と説明するとき、正しい答えはしばしば「few-shotの例全体の非一貫性を監査して修正する」だ——「より多くの指示を追加する」ではない。

罠4：例のブロックの周りのXMLタグが欠落

Anthropicのプロンプトエンジニアリングガイダンスは明示的な <examples> と <example> タグで例を包むことを推奨する。XMLタグがないと、Claudeは指示、例、入力を混同し、答える代わりにより多くの例を生成し続けることがある。例の注入を構造的なタグなしで説明する答えは不完全だ。XMLタグはタスク4.1と4.2の両方でテストされるDomain 4の横断的な期待だ。

罠5：幻覚に傾くタスクの否定的な例を省略する

入力に存在しないフィールドの値をClaudeが時々作り上げる構造化データ抽出シナリオには、1つのラベル付きの否定的な例（「フィールドが入力にない場合、nullを返す。推測しない」）が通常正しい修正だ。幻覚が続く中で肯定的な例を追加し続ける受験者はこれを見逃す。否定的な例は「抽出する」と「抽出しない」の境界を研ぎ澄ます高レバレッジのツールだ。

罠6：動的が明らかに必要なときに静的Few-Shot

シナリオが5例の静的ブロックでは表現できない広い入力分布を説明するとき——例えば30カテゴリーにわたる分類器または20文書タイプにわたる抽出器——正しい答えは動的few-shot（類似性でリクエストごとに例を取得）であり、「より多くの静的な例を追加する」ではない。高度に変動する入力空間に単一の静的ブロックを主張する答えは誤りだ。

練習アンカー

Few-shot promptingはDomain 4に触れる4つすべてのシナリオに現れるが、2つのシナリオが最も重点的に練習する。

構造化データ抽出シナリオ

これはタスク4.2のCCA-Fのフラグシップシナリオだ。エージェントは非構造化入力——請求書、契約、サポートチケット、医療メモ——から構造化フィールドを抽出する。テストする質問を期待する。（a）単一の例または20例のブロックより3〜5の多様な例を選ぶ。（b）Claudeが欠落フィールドを幻覚するとき否定的な例を追加する。（c）例のフォーマットの一貫性を通じて厳格なJSONフィールドの順序を強制する。（d）保証されたスキーマの適合性のためにfew-shotと厳格なtool use（タスク4.3）を対にする。（e）例が大文字小文字またはnullの処理で意見が合わないとき、フォーマットのドリフトを診断する。（f）持続的な抽出ペルソナのためにシステムプロンプトの配置を選択するのと動的なリクエストごとの例のためのユーザーメッセージの配置を選択する。このシナリオは試験でfew-shotの最も高密度な使用だ。

カスタマーサポート解決エージェントシナリオ

このシナリオでは、サポートエージェントがインバウンドチケットを分類し、応答を作成し、エスカレーションをルーティングする。Few-shotは次に出てくる。（a）クラス全体でインターリーブされたラベルあたり1〜2の例を持つ分類プロンプト。（b）いくつかの作業済みの例がトーンとブランドボイスを確立するドラフトのテンプレート。（c）範囲外のクエリを解決しないようエージェントを教える否定的な例。（d）現在のチケットの例として過去の類似したチケットが取得される動的few-shot。（e）マルチエージェント調査システムとdeveloper-productivity-with-claudeシナリオもfew-shotを練習するが、それぞれオーケストレーションとコード生成パターンに主要な比重が移る。

FAQ — Few-Shot Prompting上位6問

Few-shot promptingとは何か、zero-shotとどう違うか？

Few-shot promptingとは、Claudeが指示だけではなくデモンストレーションからタスクパターンを推論できるように、2つ以上の作業済みの入出力の例をプロンプト内に含める実践だ。Zero-shot promptingには例がない。プロンプトは指示＋入力で構成される。Few-shotは特定のフォーマット要件、エッジケース、またはファジーな決定境界を持つタスクの出力の一貫性を劇的に向上させる。これはin-context learningの一形態だ——パターンは単一のリクエストの期間だけ一時的に習得され、リクエスト間で重みの更新も永続性もない。

Few-shotのプロンプトにはいくつの例を含めるべきか？

Anthropicのmultishot promptingガイダンスは、ほとんどのタスクの実用的なスイートスポットとして3〜5の多様で関連した例を特定する。2例が最小限の実行可能なfew-shotだ。おおよそ5例を超えると、限界的な品質の向上は小さくなり、入力トークン、レイテンシ、ロスト・イン・ザ・ミドルのリスクを余分な例に対して支払う。質が量を上回る——慎重に選ばれた1つのエッジケースの例が3つの冗長な例より多く貢献する。「できるだけ多く」または「少なくとも10」を推奨する答えはCCA-Fで誤りだ。

Few-shot promptingはfine-tuningと同じか？

いや。Few-shot promptingはin-context learningだ——例はプロンプトに存在してリクエストごとに支払われる。Fine-tuningはキュレーションされたデータセットでモデルの重みを更新し、新しいモデルのチェックポイントを生み出す。Few-shotは速く、繰り返しが自由で、一時的だ。Fine-tuningは遅く、高コストで、恒久的だ。CCA-F試験はfine-tuningを明示的に範囲外としてリストし、質問には常に2つを混同する選択肢の誤りが含まれる。zero-shotで品質が不十分のとき、CCA-FでほぼT常に正しい次のステップは作業済みの例を追加することであり、fine-tuningすることではない。

few-shotの例はシステムプロンプトとユーザーメッセージのどちらに置くべきか？

例がセッションのすべてのターンにわたって適用される持続的なペルソナ、スタイル、またはツール呼び出しパターンを定義するときはシステムプロンプトに置く——これはプロンプトキャッシングが多くのユーザーターンにわたってコストを償却することも可能にする。例がタスク固有または入力の類似性に基づいて動的に選択されるときはユーザーメッセージに置く。配置に関係なく、例のブロックを明示的なXMLタグ（<examples><example><input>...</input><output>...</output></example></examples>）で包んで例を指示と実際の入力から明確にする。

いつ否定的な例を含めるべきか？

許容できる出力と許容できない出力の間の境界が重要なタスク——コンテンツモデレーション、ファジーラベルの分類、欠落フィールドの幻覚が問題の構造化抽出、トーン制御——に否定的な例を含める。1つのラベル付きの否定的な例がしばしば3つの追加の肯定的な例より多くの本番バグを修正する。否定的なものを少数に保つ（おおよそ2〜3の肯定に対して1つの否定）。構造パターンには対比ペア（同じブロックに誤った出力と正しい出力）と専用の <negative_examples> ブロックが含まれる。否定的なものを使いすぎることはClaudeが過剰に拒否するよう偏らせる。

数百のエッジケースを持つタスクをどう扱うか——すべてのプロンプトに数百の例が必要か？

いや——それが動的few-shotの正しいユースケースだ。本番の入力分布全体をカバーする50〜500の作業済みペアのキュレーションされた例ライブラリを維持する。リクエスト時に現在の入力に最も類似した上位3〜5の例を取得し（ベクトル類似度、キーワードスコアリング、またはメタデータルーティング）、それらだけをプロンプトに注入する。これでリクエストごとのコンテキストコストを3〜5の例に抑えながら、ライブラリ内の数百のケースをカバーできる。動的few-shotは5例の静的ブロックが表現できない広い入力分布をシナリオが説明するときのCCA-Fで正しい答えだ。

さらに読む

• Use examples (multishot prompting) to guide Claude's behavior: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
• Prompt engineering overview: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• Use XML tags to structure your prompts: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Claude 4 prompting best practices: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices

関連するExamLabのトピック：Explicit Criteria Prompt Design、Structured Output with Tool Use and JSON Schemas、Validation, Retry, and Feedback Loops for Extraction、Multi-Instance and Multi-Pass Review Architectures。