フューショット

Few-shot Prompting

ai beginner

生成AIへの指示に正解の見本を数個添え、出力の型をそろえる方法。

概要（サマリー）

フューショットとは、LLMへのプロンプトに、正解の見本を数個添えて出力の型をそろえる方法である。few-shot prompting の訳で、見本が複数あることからマルチショットとも呼ばれる。

口頭で「丁寧にまとめて」とだけ言うより、記入済みの見本を3枚見せるほうが、欄の位置が伝わる。Claudeのプロンプトガイドでは、形式、口調、構造を安定させる確実な方法のひとつとされ、3〜5個が目安になっている。

見本を足しても、モデルの中身は変わらない。ファインチューニングのように学習をやり直す方法とは別である。

見本を一つも入れない依頼は、ゼロショットと呼ばれる。説明だけでも、モデルが知っている型なら足りることがある。日付を抜き出す、既知の書式へ変換する、といった作業である。

判断がこちらのローカルルールに依存するときは、説明だけでは解釈が割れる。「緊急」の基準、社内の分類名、書いてよい文と書いてはいけない文は、見本がないとモデルの一般常識で補われる。

フューショットは、その補い方を見本で示す。モデルは見本の対応関係を、その場のプロンプトから読んで、次の入力へ適用する。

Claudeのガイドでは、見本に次の性質を求めている。

3〜5個は目安であり、すべてのモデルの最適値ではない。簡単な形式なら1個で足り、例外が多い分類なら、正常、境界、対象外をそれぞれ入れる。

次の問い合わせを「配送」「返品」「その他」のどれか一つに分類してください。

例1
入力: 荷物が届かない
出力: 配送

例2
入力: サイズが違うので返したい
出力: 返品

例3
入力: 店舗の営業時間を知りたい
出力: その他

入力: 届いた箱が潰れていた。交換か返金がしたい
出力:

3つ目の見本がないと、「店舗の営業時間」まで配送や返品へ寄せることがある。例外を見本に入れるのは、そのためである。

最後の問い合わせは、配送中の破損とも、返品の希望とも読める。こうした境目の例は、モデルに任せると答えが揺れる。どちらに振り分けるかを社内で決め、その答えを見本に加えておくと揃いやすい。

見本は説明より強く効くことがある。説明で「簡潔に」と書き、見本が長い文章だと、見本の長さに寄る。

古い分類名、個人情報、その場の冗談が見本に残っていると、新しい入力でもそれを真似る。見本は本番のデータから作るが、氏名、住所、鍵、内部URLはダミーへ置き換える。

見本同士が矛盾していると、モデルはどちらに従えばよいか決められず、答えが揺れる。似た入力に別の出力を付けない。

ファインチューニングは、例を大量に使ってモデルの重みを更新する。フューショットは、依頼のたびに見本をプロンプトへ載せるだけである。

例が数十を超え、毎回同じ作業をするなら、見本を載せ続ける費用とコンテキストウィンドウの占有が大きくなる。その段階で、ファインチューニングや、見本を検索して必要な数枚だけを足す方法を検討する。逆に、ルールが月ごとに変わる分類は、プロンプトの見本を差し替えるほうが直しやすい。

見本もトークンである。説明を短くしても、見本が長ければ毎回の費用は増える。

見本の出力が最終ラベルだけなら、モデルはラベルの対応を真似る。途中の根拠まで見本に書くと、思考の連鎖になる。計算や複数条件の判断では、答えだけより、途中の手順がある見本のほうが揃うことがある。

形式を合わせたいだけなら、手順まで書かせると出力が長くなる。目的がラベルなら、見本の出力もラベルだけにする。

「このプロジェクトの関数の書き方で」と頼むより、既存の関数を1つ見本として貼るほうが、命名と戻り値の形が揃いやすい。見本は、直してほしいファイルそのものではなく、すでに採用されている短い関数にする。

AIに見本つきプロンプトを書かせるときは、正常系だけでなく、空文字、対象外、情報が足りない場合の見本も依頼する。成功例だけだと、曖昧な入力をどれかに押し込める。

見本に本番の顧客データを貼らない。会話ログは、モデルへ送った時点で依頼の一部になる。

その依頼の中で真似るだけである。別のチャットを開くと、見本は残っていない。永続させたい型は、ルールファイルか、毎回のプロンプトへ戻す。

ある程度までは安定するが、似た見本を増やすと窓を使い、偶然の共通点までルールになる。例外をカバーする少数のほうが扱いやすい。

やっていることが違う。フューショットはプロンプトへ例を添える。ファインチューニングはモデルを追加学習する。

見本だけでは、なぜその出力なのかが伝わらないことがある。分類名の定義は短く書き、境界は見本で示す、と役割を分ける。