はじめに
前回は Chain-of-Thought（思考の連鎖） を扱いました。「ステップバイステップで考えて」がなぜ効くのか、という話です。
結論はこうでした。
CoTはAIを賢くする技術ではない。「暗算縛り」を解除して、計算のループを紙の上に外付けする技術である。
そして「ステップバイステップ」という指示が曖昧なのに効くのは、手順を教えているのではなく、出力する文章のジャンルを切り替えているから。
今回扱うのは Few-shot（フューショット） ——「例を見せてから頼む」という、これまた誰もが使っている技法です。
そして先に言っておくと、今回もほぼ同じ場所に着きます。まったく別の研究群をたどっているのに、です。
これは偶然ではないと思っています。その理由も最後に書きます。
1. そもそもFew-shotとは何か
いきなり研究の話に入る前に、用語をきちんと整理させてください。ここを曖昧にしたまま進むと、後半の話が全部ぼやけます。
「ショット（shot）」＝ お手本の個数
AIへの頼み方は、お手本を何個見せるかで名前が変わります。
Zero-shot（ゼロショット） ── お手本ゼロ。ただ頼むだけ。
次の問い合わせ文を「緊急」「通常」「対応不要」のいずれかに分類してください。
問い合わせ: 「決済画面で500エラーが出て購入できません」
分類:
One-shot（ワンショット） ── お手本1個。
問い合わせ: 「パスワードを忘れました」
分類: 通常
問い合わせ: 「決済画面で500エラーが出て購入できません」
分類:
Few-shot（フューショット） ── お手本を数個。
問い合わせ: 「パスワードを忘れました」
分類: 通常
問い合わせ: 「サービス全体にアクセスできません」
分類: 緊急
問い合わせ: 「営業時間を教えてください」
分類: 対応不要
問い合わせ: 「決済画面で500エラーが出て購入できません」
分類:
これだけです。難しい技術ではありません。お手本を並べて、最後に本番の問いを置く。 それだけ。
そしてこれが驚くほど効く。だからこそ、みんな使っています。
なぜ、わざわざ例を見せるのか
「言葉で説明すればいいじゃないか」と思うかもしれません。実際、Zero-shotでも指示を丁寧に書けばそれなりに動きます。
でも、実務では言葉で説明しきれないものが山ほどあります。
たとえば、社内の問い合わせ分類。「緊急」の定義を言葉で書こうとすると、こうなります。
「緊急」とは、サービスの継続に重大な影響を及ぼす、または多数のユーザーに
影響が及ぶ、あるいは金銭的損害が発生しうる、もしくは法令上の対応期限が
迫っている場合を指します。ただし単一ユーザーの操作ミスに起因する場合は
原則として通常とし、しかし当該ユーザーが法人契約かつ……
書けば書くほど例外が増えて、誰も読まない仕様書になります。しかも現場の人間は、この定義を読まなくても正しく分類できる。過去の事例を見てきているからです。
Few-shotは、この「事例を見て掴んでいる感覚」を、そのまま渡す方法です。
| Zero-shot（言葉で説明） | Few-shot（例を見せる） | |
|---|---|---|
| 得意 | 一般常識で判断できるタスク | 組織固有の暗黙ルール |
| 苦手 | 言語化しにくい基準 | 例が用意できない場面 |
| 例 | 「この文章を要約して」 | 「うちの会社の書式で議事録を書いて」 |
前の連載で「例は指示より強い」という話を何度かしましたが、その理由の一端がここにあります。指示は言語化の限界に縛られますが、例は縛られない。
……というのが一般に信じられている説明です。今回の記事は、この説明がどこまで正しいのかを、研究をたどりながら検証していきます。
先に予告しておくと、上の説明はかなり怪しいです。
用語ミニ辞典
この記事に出てくる言葉を先にまとめておきます。読み飛ばして、詰まったら戻ってきてください。
| 用語 | 意味 | 平たく言うと |
|---|---|---|
| Few-shot | 例をいくつか見せてから頼む方式 | お手本を並べる |
| デモンストレーション | 見せる例のこと（研究用語） | お手本そのもの |
| ラベル | 例の「答え」の部分 | 上の例だと「通常」「緊急」 |
| ラベル空間 | 答えとして使われる語の集合 | 答えの選択肢メニュー |
| In-Context Learning (ICL) | 文脈内学習。例から即席でやり方を掴む現象 | 後述。この言葉が曲者 |
| 分類タスク | 入力をいくつかのカテゴリに振り分ける仕事 | 仕分け作業 |
| 多肢選択タスク | 選択肢から正解を選ぶ仕事 | マークシート |
最重要：「学習」という言葉に騙されないでください
Few-shotで起きていることは、研究の世界では In-Context Learning（文脈内学習、ICL） と呼ばれます。
この「学習」という言葉が、この分野で一番誤解を生んでいると思っています。
普通、「AIが学習する」と言えば、モデルの中身（パラメータ、重み）が書き換わることを指します。訓練です。一度学習すれば、次回以降もその知識は残ります。
Few-shotでは、それは一切起きていません。
モデルの中身は1ビットも変わりません。例を見せている間だけ、その場の入力欄に書かれた文字として例が存在しているだけです。会話が終われば跡形もなく消えます。
人間で言えば、こうです。
勉強して覚えたのではない。
机の上に見本を置いて、それをチラチラ見ながら書いている。
見本を片付けたら、何も残らない。
この区別は、記事の後半で決定的に効いてきます。「教えた」のではなく「見せている」だけ。ここを押さえておいてください。
2. 最も不穏な実験：答えをデタラメにしても、性能が落ちない
さて、ここから本題です。
Few-shotの設計で、多くの人が一番気を遣うのは何でしょうか。おそらく「正しい例を用意すること」ですよね。間違った例を見せたら、間違ったことを覚えてしまいそうですから。
その常識を正面から破壊したのが、Min et al. (2022)（EMNLP 2022）という研究です。
実験の設定
まず何をやったかを、丁寧に説明します。
普通のFew-shotは、こういう形をしています。
入力: 「この映画は退屈だった」
感情: ネガティブ
入力: 「素晴らしい演技だった」
感情: ポジティブ
入力: 「時間の無駄」
感情: ネガティブ
入力: 「傑作」
感情:
研究チームがやったのは、この「感情:」の後ろの答えを、全部デタラメにすることでした。
入力: 「この映画は退屈だった」
感情: ポジティブ ← 間違い
入力: 「素晴らしい演技だった」
感情: ネガティブ ← 間違い
入力: 「時間の無駄」
感情: ポジティブ ← 間違い
入力: 「傑作」
感情:
お手本の答えが、全部でたらめ。普通に考えれば、性能はガタ落ちするはずです。
結果
ほとんど落ちませんでした。
GPT-3を含む12種類のモデルで、分類タスクと多肢選択タスクの両方で確認されています。答えをランダムに置き換えても、性能への打撃はごくわずかでした。
一方で、例を1個も見せない場合（Zero-shot）と比べれば、明確に性能は上がっている。
つまりこういうことです。
例を見せると効く。でも、例の答えが合っているかどうかは、ほとんど関係ない。
初めてこれを読んだとき、私は3回読み直しました。丁寧に正解ペアを作り込んできた努力は何だったのか、と。
では、何が効いていたのか
同じ研究が、答えも出しています。効いていたのは次の3つでした。
- ラベル空間 ── 「答えとして、どういう言葉を使うのか」
- 入力テキストの分布 ── 「どういう種類の入力が来るのか」
- 全体のフォーマット ── 「どういう形式で並んでいるのか」
さらに補強する実験もあって、入力テキストのほうをまったく無関係な文章に差し替えると、今度は性能が大きく落ちました。例を見せないほうがマシなレベルまで落ちる場合すらあった。
答えは壊しても平気。でも入力の質感を壊すと、致命的。
人間で言えば「過去問」です
これ、こう考えると腑に落ちます。
試験前に過去問を渡されたとします。ただし解答欄はデタラメ。全部間違った答えが書いてある。
それでも、あなたは過去問から膨大な情報を得ます。
- 記述式ではなく記号選択なんだな（＝フォーマット）
- 答えは「ア〜エ」で書くのか（＝ラベル空間）
- こういう感じの文章題が出るのか（＝入力の分布）
そして本番では、この「枠」に沿って自分の知識で答えます。解答欄が間違っていたことは、大した問題になりません。
モデルがやっているのも、これです。
例は教科書ではありません。答案用紙のテンプレートです。
3要素を、もう少し具体的に
抽象的な話が続いたので、それぞれが実務で何を指すのかを噛み砕きます。
① ラベル空間 ＝ 答えに使ってよい語彙のメニュー
例の中に「緊急」「通常」「対応不要」が登場していれば、モデルは「答えはこの3つの中から選ぶんだな」と読み取ります。
逆に言うと、例の中に一度も登場しないラベルは、選ばれにくくなります。4つ目の分類「エスカレーション」を用意していても、例に一度も出てこなければ、モデルの選択肢から事実上抜け落ちる可能性がある。
② 入力の分布 ＝ どういう質感の入力が来るのか
これは「文章の長さ」「使われる語彙」「文体」「専門用語の密度」といった、内容ではなく手触りの話です。
本番で扱うのが「システムログの抜粋」なのに、例が「丁寧なビジネスメール」だと、いくら内容が近くてもズレます。逆に、内容が多少的外れでも質感が合っていれば機能する。
③ フォーマット ＝ 並び方の型
これが一番地味ですが、実は効きます。
問い合わせ: 〇〇
分類: 通常
この「ラベル名 + コロン + 値」「例と例の間は空行1つ」といった構造そのものが信号になっています。
だからフォーマットが揺れると壊れます。1個目だけ「分類：」（全角コロン）、2個目は「分類:」（半角コロン）、みたいな不統一は、人間には誤差でもモデルには別の信号に見えうる。
COBOL→Java移行の現場で言うと
レガシー移行のドキュメント生成をAIにやらせるとき、私はよく数件の変換済みサンプルを例として渡します。
このとき効いているのは、実は「変換内容が正しいこと」より、
- 出力に使う見出し語が固定されること（＝ラベル空間）
- COBOLのコード片という特殊な見た目の入力を前提にできること（＝入力の分布）
- 「原文 → 論点 → 変換方針」という並びが型として定着すること（＝フォーマット）
のほうだった、ということになります。
実感としても、これは合っています。サンプルの変換内容に多少の粗があっても出力は安定するのに、サンプルの書式を統一し忘れた回だけ、出力がバラバラになる。経験的に知っていたことに、名前がついた感覚です。
そして、第1回とまったく同じ構造です
気づいた方もいると思います。
前回のCoTでは、こういう結論でした。
「ステップバイステップで考えて」が曖昧なのに効くのは、手順を教えているのではなく、出力する文章のジャンルを切り替えているから。
今回のFew-shotは、こうです。
例が効くのは、タスクを教えているからではなく、出力の枠（語彙・形式・入力の質感）を指定しているから。
別の研究群を、別の方向からたどって、同じ場所に着いた。
これは偶然ではないと思っています。両方とも、第1回で書いた「LLMは計算機ではなく直感マシンである」という前提から出てくる帰結だからです。
直感マシンは、教わって理解するのではなく、どのモードで振る舞うかを切り替えられる。プロンプトの技法とは、多くの場合「教育」ではなく「モードの選択」なのだと思います。
ポチョムキン理解との接続
第1回で書いたのは「正しく振る舞えることは、理解していることの証明にならない」でした。
Few-shotはその逆側から同じ壁に当たっています。間違った例を見せても正しく振る舞える。これは「例から学んでいない」ことの、かなり強い証拠です。
学んでいるように見えて、学んでいない。振る舞いだけが合っている。ポチョムキン理解そのものです。
3. 順番は効きます。しかも異常なレベルで
ここまでで「じゃあ例なんて適当でいいのか」と思った方、そうはいきません。
適当に作った例を、適当な順番で並べると、性能は壊滅します。
まず、「何の順番」の話なのかを確認します
ここで言う「順番」は、例のブロックそのものを並べる順番のことです。1つの例の中身（「入力: →分類:」という内部構造）は固定なので、対象外です。
[例1] → [例2] → [例3] → [例4] → [本番の問い]
この4つのブロックを、どういう順で並べるか。中身は一切変えず、この並びだけを変えます。
54% から 93% へ
Lu et al. (2022)（ACL 2022）の研究です。タイトルが洒落ていて「Fantastically Ordered Prompts（素晴らしく並べられたプロンプト）」といいます。
まったく同じ例を使って、並べる順番だけを変える。 それだけで何が起きるか。
「ほぼ最高性能」から「ほぼでたらめ回答」まで振れる。
別の研究（Zhao et al. 2021）でも、感情分析タスクで並び替えだけで正答率が 54%（ほぼ偶然の当てずっぽう）から 93%（ほぼ最高水準） まで動いたことが報告されています。
例の中身は同じ。順番だけ。それで40ポイント近く動く。
さらに厄介な3つの事実
Lu et al. は追加でこう報告しています。
① モデルが大きくなっても消えない。 「大規模モデルなら気にしなくていい」わけではありません。当時の最大級のモデルでも起きます。
② 特定の「悪い例」のせいではない。 「変な例が混じっているから」ではなく、良い例だけを集めても順番次第で壊れます。
③ 良い並び順は、他のモデルに転移しない。 あるモデル用に苦労して見つけた最適な並びは、別のモデルでは無意味になります。
③が実務的には一番痛い。プロンプトはモデル固有の設定ファイルである、ということだからです。モデルを乗り換えたら、並び順のチューニングはやり直しになります。
なぜ順番が効くのか：3つのバイアス
機構レベルの説明が Zhao et al. (2021)（ICML 2021）にあります。モデルには3つの偏りがある、というものです。
| バイアス | 内容 | 人間で言うと |
|---|---|---|
|
多数派ラベルバイアス (majority label bias) |
プロンプト内に多く出てくる答えを選びやすい | 会議で多数派の意見に流される |
|
直近バイアス (recency bias) |
プロンプトの終盤に出てきた答えを繰り返しやすい | 面接で最後の応募者の印象が強く残る |
|
頻出トークンバイアス (common token bias) |
事前学習でよく見た言葉を選びやすい | 珍しい国名より「アメリカ」と言ってしまう |
具体例で見ると分かりやすい。
例1: ... → ネガティブ
例2: ... → ポジティブ
例3: ... → ネガティブ
例4: ... → ネガティブ ← 末尾がネガティブ2連発
本番: ... → ???
この並びだと、モデルはネガティブと答えやすくなります。理由は2つ重なっていて、全体でネガティブが多い（多数派バイアス）＋末尾がネガティブ（直近バイアス）です。
例の中身とは無関係に、並べ方だけで答えが偏る。
3つ目の頻出トークンバイアスも実務では地味に効きます。ラベル名を「対応不要」ではなく「NoAction」のような珍しい表記にすると、それだけでモデルが選びにくくなる可能性がある、ということです。ラベルの名前選びも設計要素なんですね。
Lost in the Middle との接続——ただし、正確に言うと
連載第2回で扱った Lost in the Middle（長い文脈の真ん中の情報が無視されやすい現象）を覚えているでしょうか。
「位置によって情報の効き方が違う」という、あの話です。
引き継ぎ資料の段階では「これが例の並び順にも直撃しているはず」という仮説がありました。調べた結果、半分正しく、半分は言い過ぎでした。正確に書きます。
Lost in the MiddleとZhao et al.の直近バイアスは、実は別々の実験系列から出てきた別物です。
- Lost in the Middle（第2回）が測っていたのは、「大量の文書の中から、正解の書いてある1つを見つけられるか」という検索寄りの現象
- Zhao et al. の直近バイアスが測っていたのは、「末尾の例のラベルパターンを、そのまま繰り返しやすいか」という、自己回帰(直前の続きを継続しやすい性質)由来の現象
同じ現象だと断定するには、まだ足りません。 ただし、状況証拠はかなり揃っています。
Lost in the Middleは、近年の理論研究で、モデルを訓練する前の初期状態ですらすでに現れることが示されています。原因は特定のタスクの癖ではなく、注意機構(attention)とresidual connectionという、トランスフォーマーの構造そのものの幾何学的な性質だという説明です。文頭には強い影響力が対数的に積み上がり(Primacy Tail)、文末には孤立した強い影響力が生まれ(Recency Delta)、その谷間にあたる真ん中が構造的に不利になる。
これが正しいなら、対象が「文書の羅列」であろうと「Few-shotの例の羅列」であろうと、同じ谷間に落ちるはずです。検索タスクに固有の現象ではなく、並べられたもの全般に効く構造的な性質だからです。
一方で、これに水を差す最近の研究もあります。モデルは前の例を踏まえて各例の表現を作り直し、その場の文脈の中でより情報量が多く、紛れの少ない例に注意を再配分することが示されています。つまり、位置だけが全てではなく、内容の際立ちが位置の不利をある程度は覆せる可能性がある。
なので正確な言い方はこうなります。
位置だけで見れば、真ん中は構造的に不利。これはアーキテクチャレベルの根拠がある。
ただし、その例が十分に情報量が多く、他と紛れない内容であれば、位置の不利をある程度は覆せる可能性がある。
「真ん中の例は必ずLost in the Middleする」と言い切るのは、現時点では検証しきれていない外挿です。
はっきり確認できているのは、末尾（Recency側）の効果だけです。真ん中と先頭の関係は、まだそこまで確定していません。
結局、どう並べればいいのか
上記を踏まえた実務指針です。
| 優先度 | 指針 | 根拠 |
|---|---|---|
| 高 | 一番典型的で、フォーマットの手本にしたい例を先頭に置く | Primacy側。以降全体の型を決める土台になる |
| 高 | 末尾のラベルが特定のクラスに偏らないようにする | 直近バイアスは実証済み。末尾の答えに最終予測が引っ張られる |
| 高 | 埋もれさせたくない・見落とされたら困る例は、真ん中を避けて両端に置く | 位置による不利を避ける、最も確実な対策 |
| 中 | 例が3〜10個程度の少数なら順番の効果は大きい。16例を超えたあたりから急速に薄まる | 実測でも、少数例では並び替えによるばらつきが大きく、例数が増えると縮小することが確認されている |
| 中 | 埋もれさせたくない例が複数ある場合、両端に分散させ、真ん中は「平凡だが妥当な例」で埋める | Primacy・Recency両方を利用しつつ、真ん中のリスクを引き受けない例で埋める |
| 低 | 最適な並び順は結局モデルごとに違う。時間があれば複数の並びを実測して比較する | 前セクションの通り、良い並びは他モデルに転移しない |
一番シンプルな指針を1つだけ選ぶなら、これです。
一番大事な例を、最初と最後、両方に置く。（同じ例を2回使ってもいい）
真ん中は、あってもなくても大勢に影響しない、平凡だが妥当な例で埋める。
これなら「真ん中の例が本当にLost in the Middleするか」を厳密に知らなくても、真ん中に重要な情報を置かないことで、リスクごと回避できます。第2回で書いた「重要な情報は両端に」という対策と、発想はそのまま同じです。
実務での即効テクニック
もし分類タスクでFew-shotを使っていて、出力が特定のクラスに偏っていると感じたら、まず疑うべきは例の並び順とクラスバランスです。
- 各クラスの例の数を揃える（多数派バイアス対策）
- 末尾に同じラベルを連続させない（直近バイアス対策）
- ラベル名は自然で一般的な語にする（頻出トークンバイアス対策）
- 一番重要な例は先頭と末尾に置き、真ん中には平凡な例を置く（位置バイアス対策）
プロンプトの文言をいじる前に、これを確認したほうが早い場合が多いです。
4. 個数：多いほど良い、は途中まで正しい
次は「何個が最適か」です。
長らく、Few-shotの「Few」は文字通り数個でした。コンテキストウィンドウ（一度にモデルに渡せる文字数の上限）が小さかったので、物理的にそれしか入らなかったからです。
ところがコンテキストが100万トークン級まで伸びたことで、数百〜数千個の例を渡すことが可能になりました。これを many-shot（メニーショット） と呼びます。
結果：伸びます
Agarwal et al. (2024)（NeurIPS 2024）が体系的に調べています。Gemini 1.5 Pro（100万トークンのコンテキスト）を使って、few-shotからmany-shotへ移行したときに何が起きるか。
幅広いタスクで、大幅に性能が向上しました。 生成系のタスクでも、分類系のタスクでも。
面白いのは、この研究が「例を用意するコスト」という現実的な壁にも取り組んでいることです。数百個の高品質な例を人力で作るのは非現実的なので、2つの代替案を試しています。
- Reinforced ICL ── 人間が書いた例の代わりに、モデル自身が生成した推論過程を例として使う
- Unsupervised ICL ── 例から答えを取り除き、問題文だけを大量に並べる
どちらも、特に複雑な推論タスクでかなり有効だった、と報告されています。
「答えを取り除いても効く」というのは、セクション2のMin et al. の話と綺麗に整合しますね。やっぱり答えは本体ではない。
そして、順番問題が薄まる
後続研究では、もう一つ面白いことが報告されています。
例が非常に多い領域では、順番の入れ替えに対する感度が下がる。
考えてみれば自然です。例が4個なら、末尾の1個は全体の25%を占めます。でも例が400個なら、末尾の1個は0.25%です。直近バイアスの影響が相対的に薄まる。
つまり、セクション3で散々脅かした順番問題は、例をたくさん入れられるなら、ある程度は物量で解決できるということです。
ただし、無条件ではありません
ここは正直に書きます。many-shotには明確なコストがあります。
| コスト | 内容 |
|---|---|
| 課金 | 毎回、数百例ぶんのトークンを送ることになる |
| 応答速度 | 入力が長くなれば当然遅くなる |
| ノイズ | 例の数が増えるほど、質の低い例が混入しやすくなる |
| Context Rot | 長い文脈そのものが性能を劣化させる問題（連載第3回） |
特に最後の点。連載第3回で扱った Context Rot（文脈が長くなるほど性能が落ちる現象）と、many-shotは正面から衝突します。「例を増やせば伸びる」と「長いと劣化する」が同時に成立するので、どこかに最適点があるはずです。
そしてその最適点は、タスクによってもモデルによっても違う。測るしかありません。
5. 選び方：類似度検索という定番と、その正しい理解
最後の問い、「良い例とは何か」です。
定番の答え：似ている例を選ぶ
Liu et al. (2022) の研究が、この分野の定番手法を作りました。タイトルはそのものずばり「What Makes Good In-Context Examples for GPT-3?（GPT-3にとって良い例とは何か）」です。
やり方はシンプルで、これから解かせたい問題に意味的に近い例を、例のプールから検索して使うというもの。ランダムに例を選ぶより、一貫して性能が上がることが確認されています。タスクによっては40%以上の改善も報告されています。
「意味的に近い」を機械はどう測るのか
ここで 埋め込み（embedding） という技術が出てきます。
文章を、数百次元の座標（数字の並び）に変換する技術です。意味が近い文章ほど、座標上で近い位置に配置されるように作られています。
つまり「意味の地図」を作って、その地図上での距離を測る。地図上で一番近い例をk個選ぶので、kNN検索（k近傍法） と呼ばれます。
平たく言えば「似た問い合わせを、過去の対応履歴から引っ張ってくる」だけです。カスタマーサポートのFAQ検索と、やっていることは同じです。
ちょっと待って、これはMin et al. と矛盾しないか？
鋭い方は引っかかっているはずです。
セクション2では「答えの正しさは効かない」と言いました。でもここでは「良い例を選ぶと効く」と言っている。矛盾していませんか？
していません。そして、この矛盾を解くと理解が一段深まります。
思い出してください。効いていた3要素のうち2つ目は「入力テキストの分布」でした。そして、入力を無関係な文章に差し替えると性能が壊滅する、という実験もありました。
類似度検索が効くのは、「正解を教えているから」ではありません。
入力の分布を、これから解く問題に寄せているからです。
過去問の例えに戻りましょう。数学の試験前に、化学の過去問を渡されても意味がない。同じ数学の、しかも同じ単元の過去問だからこそ「こういう感じの問題が出るのか」という枠が正しく設定される。
類似度検索は、教師データの供給ではなく、分布合わせです。
この理解の違いは実務で効いてきます。「正しい模範解答を作らなきゃ」と気負うより、「本番と同じ質感の入力を並べる」ほうが優先度が高い、ということだからです。
6. 例外：ラベルが本当に効く場面
ここまで「答えは効かない」と繰り返してきましたが、正直に補足しなければならないことがあります。
Min et al. の結論には、反証と限定条件があります。
反証①：すべての設定で成り立つわけではない
後続研究（Ground-Truth Labels Matter）では、入力とラベルの対応への鈍感さはすべての実験設定で一貫しているわけではない、と指摘されています。実験条件によっては、ラベルの正しさが効く場面がある。
反証②：ラベルが「均質」だと壊滅する
もっと極端な現象も報告されています。
ラベルをランダムにしても平気なのに、すべての例のラベルを同じものに揃えると、精度が壊滅的に落ちる（複数のモデルとタスクで12%以下まで低下）という報告です。
さらに面白いことに、意味のない造語（foo, bar など）をラベルに使っても、モデルはその造語の集合の中から答えを選ぼうとする。本来の正解が候補から外れているのに、です。
つまり、正確な言い方はこうです
「ラベルは適当でいい」ではありません。正確には、
ラベルの「正しさ」より、ラベル集合の「見え方」のほうが支配的である。
モデルはラベル欄を見て、「答えとして許される語彙はこれだ」というメニューを読み取っています。
- メニューが多様（＝ラベル空間が正しく提示されている）→ 中身が間違っていても機能する
- メニューが単調（＝全部同じ）→ 選択肢が1つしかないと解釈して壊れる
答えの正誤ではなく、答えの多様性が情報だったわけです。
実務上の含意
これは「手を抜いていい」という話ではなく、手を抜く場所が違うという話です。
- 優先度・高：ラベルの種類を全部登場させる／クラスバランスを揃える／入力の質感を本番に寄せる／フォーマットを統一する
- 優先度・低：一つひとつの例の答えを完璧に検証する
もちろん、答えが正しいに越したことはありません。ただ、限られた工数をどこに投下するかという問いに対しては、上の順序のほうが効率的だ、ということです。
7. よくある疑問
ここまでの内容で湧きそうな疑問を、先回りして拾っておきます。
Q. 例を見せると、AIは賢くなっているんですか？
なっていません。同じ能力のまま、出力の枠が変わっただけです。
前回のCoTと対比すると分かりやすい。CoTは「暗算縛りを解除して、使える計算量を増やす」技法でした。あれは能力の解放です。
Few-shotは違います。計算量は変わりません。変わるのは「どういう形式で、どういう語彙で答えるか」という出力の設定です。
だから、根本的に解けない問題は、例を見せても解けません。例を100個並べても、モデルが知らない業務ルールを推測できるようにはならない。できるのは「知っていることを、正しい形式で出させる」ことまでです。
Q. 例を見せたことは、次の会話にも引き継がれますか？
引き継がれません。モデルの中身は変わっていないので、新しい会話では完全にゼロからです。
同じ会話の中であっても、文脈が長くなればContext Rot（第3回）で扱った劣化が起きますし、連載第9回で扱ったInstruction Drift（指示が徐々に効かなくなる現象）と同じように、例の効果が薄れていくこともあります。
例は「一度渡せば覚えてくれるもの」ではなく、毎回渡し直す消耗品だと考えたほうが実態に合っています。
Q. 悪い例をわざと見せて「こうするな」と教えるのは有効ですか？
危険です。 セクション2の話を思い出してください。モデルはラベル欄を「答えとして許される語彙のメニュー」として読みます。
つまり、悪い例を並べると、その悪い例の質感が「入力の分布」として、悪い出力の語彙が「ラベル空間」として登録されうる。「こうするな」という指示より、並んでいる実物のほうが強い信号になる危険がある。
どうしても悪い例を示したいなら、悪い例と良い例をペアにして、良い例のほうを出力位置（最後）に置く構成のほうが安全です。直近バイアス（セクション3）を味方につける形です。
Q. 結局、例は何個がいいんですか？
「測ってください」が正直な答えです。これは逃げではなく、セクション4で見た通り、最適点がタスクとモデルの両方に依存するからです。
ただし出発点としては、分類タスクなら「全ラベルが最低1回は登場する数」が下限になります。ラベルが5種類なら最低5個。そこから増やして、精度が頭打ちになる点を探すのが現実的です。
8. 実務チェックリスト
前回の記事で、最も強い対処法として「開いた問いを、数えられる閉じた集合に変換する」という話をしました。「もっと良くして」ではなく「このリストを全部消化しろ」に変える、というやつです。
その原則をここでも適用します。Few-shotの例を設計するとき、数えられる形でチェックできる項目に落とすと、こうなります。
+ [必須] 使いうるラベルが、例の中に全種類登場しているか
+ [必須] 各ラベルの例の数が、極端に偏っていないか
+ [必須] 例の入力の質感（長さ・語彙・文体）が本番と揃っているか
+ [必須] すべての例が同一のフォーマットで書かれているか
+ [推奨] 末尾に同じラベルが連続していないか
+ [推奨] ラベル名が自然で一般的な語になっているか
- [任意] 各例の答えが厳密に正しいか（優先度は意外と低い）
なぜチェックリストにするのか。理由は前回と同じです。
「良いFew-shotになっているか？」は開いた問いで、判定基準がありません。人によって答えが変わるし、自分でも判断がぶれる。
でも上のリストは閉じた集合です。1個ずつ、数えて確認できる。未消化のものが必ず1行として残る。
そして重要なのは、これらの項目が全部「ドメイン知識なしで判定できる」ことです。ラベルの種類が揃っているかは数えれば分かる。クラスバランスも数えれば分かる。フォーマットが揃っているかは見れば分かる。
対して「この例の答えが業務的に正しいか」はドメイン知識が要ります。だからこそ、そこに人間の限られた検証力を集中させるべきで、機械的に判定できる部分はチェックリストで潰す。
これは前回の結論の、そのまま応用です。
9. まとめ
長くなったので整理します。
用語の話
- Few-shotは「お手本を並べてから頼む」だけの技法。In-Context Learning（文脈内学習）とも呼ばれる
- ただしこの「学習」は誤解を招く。モデルの中身は一切変わっていない。机の上に見本を置いてチラ見しているだけで、会話が終われば何も残らない
機構の話
- 例の答えをデタラメにしても、性能はほとんど落ちない（Min et al. 2022）
- 効いているのは「ラベル空間」「入力の分布」「フォーマット」の3つ。例は教科書ではなく、答案用紙のテンプレート
- 前回のCoTとまったく同じ構造。プロンプト技法の多くは「教育」ではなく「モードの選択」
壊れ方の話
- 並び順だけで、正答率が54%から93%まで動く（Zhao et al. 2021）。原因は多数派バイアス・直近バイアス・頻出トークンバイアス
- 良い並び順は他のモデルに転移しない。プロンプトはモデル固有の設定ファイル
- これは第2回 Lost in the Middle の位置効果が、例の並び順に直撃している姿
設計の話
- 個数は増やすほど伸びるが、Context Rot（第3回）と正面衝突する。最適点は測るしかない。分類タスクの下限は「全ラベルが最低1回登場する数」
- 類似度検索が効くのは「正解を供給するから」ではなく「入力の分布を本番に寄せるから」
- 「ラベルは適当でいい」は不正確。正しくは「ラベルの正しさより、ラベル集合の見え方が支配的」。全部同じラベルにすると壊滅する
- 例はCoTと違って能力を解放しない。解けない問題は、例を何個見せても解けない
- 例は覚えてもらえない。毎回渡し直す消耗品
おわりに：なぜ毎回同じ場所に着くのか
冒頭で「今回もほぼ同じ場所に着きます」と書きました。実際そうなりました。
- CoT：手順を教えているのではなく、出力のジャンルを切り替えている
- Few-shot：タスクを教えているのではなく、出力の枠を指定している
まったく別の研究群を、別の方向からたどったのに、同じ結論に着く。
これは、私たちがプロンプトエンジニアリングという営みを、根本的に取り違えていた可能性を示しています。
私たちは「AIに教えている」つもりでいる。 手順を教え、例を見せ、正しい答えを示す。教師のように。
でも実際に起きているのは、「AIのどのモードを呼び出すか」の選択です。 モデルの中には既に膨大な振る舞いのパターンが眠っていて、プロンプトはその中から一つを選ぶスイッチとして機能している。
だから曖昧な指示でも効く。だから間違った例でも効く。内容ではなく、形式が信号だから。
そして——これが一番厄介なところですが——スイッチを押した結果、何が起動したのかは、出力を見ても分かりません。
ポチョムキン理解で書いた通り、正しく振る舞えることは理解の証明になりません。前回書いた通り、もっともらしい説明は判断根拠の記録ではありません。
そして今回、これが加わります。
例を見せて正しく答えたからといって、その例から何かを学んだ証拠にはならない。
私たちができるのは、スイッチの押し方を体系化することだけです。それでも十分に価値はあります。54%が93%になるのですから。
ただ、押しているのはスイッチであって、教えているわけではない。この自覚を持っているかどうかで、AIとの付き合い方はかなり変わると思っています。
次回は 温度・サンプリングパラメータ（temperature、top-p）を扱う予定です。
これまでの2回が「何を渡すか」の話だったのに対して、次回は「モデルが持っている確率分布そのものを、どう歪めるか」という、一段レイヤーの違う話になります。「temperature=0にすれば結果は完全に再現される」という広く信じられている通念が、実はいくつかの理由で完全には成立しない、という技術的な深掘りも入れる予定です。
参考文献
- Min, S. et al. (2022). Rethinking the Role of Demonstrations: What Makes In-Context Learning Work? EMNLP 2022. arXiv:2202.12837
- Lu, Y. et al. (2022). Fantastically Ordered Prompts and Where to Find Them: Overcoming Few-Shot Prompt Order Sensitivity. ACL 2022. arXiv:2104.08786
- Zhao, T. Z. et al. (2021). Calibrate Before Use: Improving Few-Shot Performance of Language Models. ICML 2021. arXiv:2102.09690
- Agarwal, R. et al. (2024). Many-Shot In-Context Learning. NeurIPS 2024. arXiv:2404.11018
- Liu, J. et al. (2022). What Makes Good In-Context Examples for GPT-3? DeeLIO 2022. arXiv:2101.06804
- Yoo, K. M. et al. (2022). Ground-Truth Labels Matter: A Deeper Look into Input-Label Demonstrations. arXiv:2205.12685