Few-shotプロンプトの設計｜例の選び方・件数・順序と、効かなくなる場面

「例を2つ貼ったら急に精度が上がった」「例を1つ増やしたらむしろ悪くなった」。Few-shot(少数事例)プロンプトは、効くときの効き方が分かりやすい反面、なぜ効いたのか・なぜ効かなくなったのかが説明しづらい手法でもあります。この記事では、例をどう選び、何件、どの順序で並べるのか、そしてどんな場面で例示が効かなくなるのかを、公式ガイドと原典論文にあたりながら実務用に整理します。

zero-shot / one-shot / few-shotの区別#

用語の出どころは、GPT-3を発表したBrownらの論文「Language Models are Few-Shot Learners」(arXiv:2005.14165、2020年5月投稿)です。同論文は、重みを更新せずにプロンプト内の実演(demonstration)だけでタスクを伝える設定を、実演の数によってzero-shot・one-shot・few-shotの3つに区別しています。ただし論文が定義しているのは評価上の条件までで、それぞれの用途までは述べていません。論文の定義に、実務での使いどころを筆者が補って整理すると次のようになります。

論文中では、few-shotの実演数Kについて「典型的には10から100の範囲に設定する。これはモデルのコンテキストウィンドウ(nctx = 2048)に収まる件数だから」と述べられています。当時の制約を前提にした数字であり、コンテキスト長が桁違いに伸びた現在にそのまま持ち込む数値ではありません。ここで押さえておきたいのは、few-shotが「学習」ではなく「推論時に文脈で条件づける」手法だという点です。重みは変わらないので、例を外せば効果も消えます。

例示が効く仕事と、効きにくい仕事#

例示が効くかどうかは、タスクの性質でおおよそ見当がつきます。

効きやすいのは、出力の形が決まっていて、言葉で説明するより見せたほうが速いタイプの仕事です。

• 分類・ラベル付け(問い合わせのカテゴリ分け、優先度判定)
• 定型フォーマットへの変換(議事録メモから決定事項テーブルへ)
• 文体・トーンの再現(既存のリリース文と同じ温度感で書く)
• 抽出タスク(契約書から項目を抜き出して同じキー名で返す)

効きにくいのは、次のようなタスクです。

• 入力ごとに求められる推論の筋道が違う問題(例をなぞると、逆に当てはまらない型に引きずられます)
• 正解が事実知識に依存する問い(例を見せても、モデルが知らない事実は埋まりません)
• 出力が長く一点ものの文章(長文の例を数件入れるとコストが跳ね上がる割に、形式以外の再現度は上がりにくい)

Anthropicの現行のプロンプト設計ガイドは、例について「Claudeの出力形式・トーン・構造を導く最も信頼できる方法のひとつ」と位置づけています。逆に言えば、形式・トーン・構造が争点でないタスクでは、例示の投資対効果は下がります。

例の選び方:典型例だけでなく境界を見せる#

Minらの研究「Rethinking the Role of Demonstrations」(arXiv:2202.12837、2022年2月投稿)は、in-context learningで何が効いているのかを調べたものです。同論文は、分類および多肢選択タスクにおいて、実演のラベルをランダムなものに置き換えても性能がほとんど落ちなかったと報告し、性能を駆動しているのは(1)ラベル空間、(2)入力テキストの分布、(3)全体のフォーマットを示していることだと述べています。

この観点に立つと、例の選び方の指針が定まります。

Anthropicのガイドは、良い例の条件として「関連性がある(実際のユースケースを忠実に写す)」「多様である(エッジケースを含み、意図しないパターンを拾わせない)」「構造化されている(<example>タグで囲み、指示と区別できるようにする)」の3点を挙げています。多様であることがわざわざ条件に挙がっているのは、似た例ばかり並べるとモデルが本来関係のない共通点(たとえば例がすべて短文である、すべて同じ書き出しである)を規則として学んでしまうためです。

以下のタグ内が分類の例です。入力の形式と、判定の境界を参考にしてください。

<examples>
<example>
<input>領収書の再発行をお願いできますか。先月分です。</input>
<output>{"category":"手続き依頼","priority":"中","reason":"再発行の依頼"}</output>
</example>
<example>
<input>ログインできません!!! 昨日から3回目です。いい加減にしてほしい</input>
<output>{"category":"障害報告","priority":"高","reason":"継続する不具合と強い不満"}</output>
</example>
<example>
<input>プランAとBって、同時に契約できるんでしたっけ</input>
<output>{"category":"仕様の質問","priority":"低","reason":"苦情ではなく仕様確認"}</output>
</example>
<example>
<input>先日の件、その後どうなっていますか。よろしくお願いします</input>
<output>{"category":"その他","priority":"低","reason":"対象を特定できる情報がない"}</output>
</example>
</examples>

上記と同じJSON形式で、次の入力を分類してください。
カテゴリは 手続き依頼 / 障害報告 / 仕様の質問 / その他 の4つから選びます。
判断材料がない場合は category を "その他" とし、reason に不足している情報を書いてください。

3件目のように「苦情に見えるが仕様の質問」という境界例を入れておくと、感情的な語尾に引きずられた誤分類が減らせます。4件目は、判断材料が足りない入力をその他に寄せる例です。使うカテゴリを一度ずつ登場させたうえで、カテゴリ一覧を指示側にも書いておくと、例と指示の両方から選択肢の範囲が伝わります。

何件並べるか:コストと相談して決める#

件数について、公開されている公式ガイドの記述はおおむね次のとおりです。

• Anthropic: 最良の結果を得るには3〜5件の例を含めることを推奨(Claudeに例の関連性と多様性を評価させたり、追加の例を生成させたりする使い方も挙げています)
• Google(Gemini API): 少数事例は常に入れることを推奨する一方、「例を入れすぎるとモデルが例に過剰適合することがある」と注意。最適な件数は実験して決めるよう促しています
• OpenAI(推論モデル向けの推奨): まずは例なしのプロンプトを書いてみることを推奨。複雑な出力要件がある場合に例を足す

まとめると、出発点は3〜5件、上限は「増やしても評価スコアが伸びなくなるところ」です。件数を増やすときは、次のコストが同時に増えることを前提に判断します。

• 入力トークン: 例はリクエストのたびに毎回送られます。1件500トークンの例を5件入れれば、全リクエストに2500トークンが固定で乗ります
• レイテンシ: 入力が長くなるほど最初のトークンが返るまでの時間が延びます。対話UIでは体感差が出ます
• 過剰適合: Googleのガイドが挙げるとおり、例に寄りすぎて、例と少し違う入力への一般化が落ちることがあります

一方で、例は「毎回同じ内容が先頭付近に置かれる」という性質を持つため、プロンプトキャッシュとの相性は良い部類です。システム指示と例をプロンプトの前方に固定し、可変の入力を末尾に置く構成にすれば、キャッシュが効く条件を満たしやすくなります。ただしキャッシュの仕様・最小トークン数・課金は提供各社で異なるため、必ず自社が使うAPIの現行仕様を確認してください。

順序とラベル分布という落とし穴#

順序の影響を正面から検証したのが、Luらの「Fantastically Ordered Prompts and Where to Find Them」(arXiv:2104.08786、2021年4月投稿)です。同論文は、例を並べる順序の違いだけで、最先端に近い性能とほぼ当てずっぽうの性能の間で結果が変わりうることを示しました。さらに、この現象がモデルサイズを問わず現れること、特定の例の集合に起因するものではないこと、あるモデルにとって良かった並び順が別のモデルには転用できないことを報告しています。同論文は対策として、モデル自身の生成で人工的な検証セットを作り、順列候補のエントロピー統計から良いプロンプトを選ぶ手法を提案し、GPT系モデルにおいて11のテキスト分類タスクで13%の相対的改善を得たとしています。

これに先行するZhaoらの研究「Calibrate Before Use」(arXiv:2102.09690、2021年2月投稿)も、プロンプトの形式・使う例・例の順序によって精度がほぼ当てずっぽうから最先端近くまで振れうると報告しています。同論文は、この不安定さの原因として3つの偏りを挙げています。

• 多数ラベルバイアス: プロンプト内に多く出てくるラベルを答えたがる。分類の例が正例に偏っていれば、正例と答えがちになる
• 直近バイアス: プロンプトの末尾近くに置かれたラベルを答えたがる。例の件数が均等でも、最後の2件が同じラベルなら、そのラベルに寄る
• 共通トークンバイアス: 事前学習データに頻出する語を答えとして選びやすい

これらの検証は2021年から2022年の論文で、対象は当時のGPT系モデルと分類系タスクが中心です。現行のモデルで同じ大きさの揺らぎが出るとは限りません。ただし「例の並べ方とラベルの偏りは結果に影響しうる変数である」という設計上の含意は、いまも点検の価値があります。

実務での対処は、原因を知っていればさほど難しくありません。

とくに最後の項目は見落とされがちです。Luらの論文が示すとおり、良い並び順はモデル間で転用できるとは限りません。モデル移行のときには、プロンプト本文だけでなく例の構成も再検証の対象に入れてください。

推論モデルと長文コンテキストでは、例を減らす判断もある#

few-shotは常に足し算で効くわけではありません。使うモデルによっては、むしろ「まず引いてみる」ほうが合う場面があります。

OpenAIの推論モデル向けのベストプラクティスは、「推論モデルは良い結果を出すのに少数事例を必要としないことが多いので、まずは例のないプロンプトを書いてみてください」と述べています。そのうえで、出力に対する要件が複雑な場合には入出力の例を入れるとよいこと、その際は例と指示が食い違わないようにすることを条件として挙げています。なお、この「まず例なしで」という順序を明記しているのはOpenAIの推論モデル向けガイドで、GoogleのGemini APIガイドは少数事例を常に入れることを、Anthropicのガイドは3〜5件を含めることを勧めています。どのガイドに従うかは、使うモデルに合わせて判断してください。

減らす判断が向く場面を整理すると、次のようになります。

• 推論モデルを使っていて、出力形式が単純(自由文、あるいはスキーマ指定で足りる)
• 構造化出力の機能でJSONスキーマを強制できる。形式を教えるための例が不要になる
• 例が長大で、コストとレイテンシが実用上の問題になっている
• 例に引きずられた画一的な出力が問題になっている(文章生成でよく起きます)

逆に、推論モデルであっても例を残したほうがよいのは、言葉で書き切れない判断基準がある場合です。「どこまでを軽微な不具合とみなすか」のような社内固有の線引きは、定義文を長々と書くより境界例を2〜3件見せたほうが伝わります。

なお、思考の道筋を例で見せるfew-shot CoTは、いまも有効な場面がありますが、推論が組み込まれたモデルでは扱いが変わります。Anthropicのガイドは、少数事例の中で<thinking>タグを使って推論の型を見せるとそのスタイルが拡張思考にも一般化する、という使い方を挙げています。詳しくは以下の記事で整理しています。

例を変えたら測る:小さな評価セットの作り方#

ここまでの論点は、すべて「試して測る」ことでしか決着しません。few-shotは変更のコストが低い(テキストを差し替えるだけ)ぶん、感触だけで良し悪しを判断してしまいやすい領域です。20〜50件程度の小さな評価セットがあれば、判断の質は大きく変わります。

指標は、分類なら正解率と、業務上とくに避けたい誤りの発生率(たとえば「障害報告を仕様の質問と誤る率」)の2本立てにすると、実務判断に使えます。全体の正解率が上がっても、致命的な誤りが増えているなら採用できません。評価の設計そのものは、以下の記事で詳しく扱っています。

よくある質問#

まとめ#

Few-shotプロンプトは、書き足すのが簡単なぶん、設計せずに増やしてしまいがちな要素です。押さえるべき点はそれほど多くありません。

例示は、言葉で説明しにくい基準を短く伝えられる、コストパフォーマンスの良い手段です。同時に、順序や偏りといった目に見えにくい変数を持ち込む手段でもあります。増やす方向だけでなく、減らす・差し替えるという選択肢を常に手元に置いて、測りながら調整していってください。プロンプト全体をどう組み立てるかについては、コンテキスト設計の観点もあわせて参考になります。