AIへの頼みごとがうまく伝わらないとき、最も強力な一手が「お手本を見せる」ことです。この使い方がFew-Shotです。ただし、例なら何でもよいわけではありません。例の質・そろえ方・数によって結果は大きく変わります。このページでは「どんな例を、どう見せるか」という例示の設計方法に焦点を当てて解説します(例なしで動く仕組みは項目k1-5-2のZero-Shotで扱っています)。
📖 ひと言でいうと
Few-Shot(フューショット)とは、プロンプトの中に少数(few)のお手本例を見せてから本番のタスクをやらせる使い方のことです。例が1つならOne-Shotと呼ぶこともあります。モデルは見せられた例のパターンを文脈から読み取り、同じ流儀で本番に取り組みます(コンテキスト内学習。項目k1-5-1)。
身近な例えでいうと、「記入例つきの申請書」です。空欄の書き方を言葉で説明されるより、記入例を1枚見るほうが、書式も粒度も一目で正確に伝わります。Few-Shotは、AIに渡す「記入例」を設計する技術だといえます。
🖼 1枚でわかるFew-Shot
🔍 しっかり理解する
例示は何を伝えているのか
Few-Shotの設計を考える出発点は、「例がモデルに何を伝えるのか」を分解することです。例は主に3つの情報を同時に運びます。
- 形式: 出力の書式・構成・長さ。「日付/金額/科目の順で、スラッシュ区切り」のような構造は、例を1つ見せれば正確に伝わります
- 粒度・スタイル: どのくらい詳しく、どんな口調で書くか。「簡潔に」という言葉より、簡潔な実例のほうが「どのくらい簡潔か」を正確に規定します
- 判断基準: 分類の境界線や重視するポイント。「クレームかどうかの微妙な問い合わせをどちらに分類するか」は、境界例を見せることで初めて伝わります
逆にいうと、この3つがすでに指示だけで伝わっているタスクに例を足しても、効果は限定的です。「言葉で説明しにくい何か」を特定し、それが伝わる例を選ぶ——これが例示設計の基本原則です。
良い例示・悪い例示
- 全例が同じ書式・同じ口調でそろっている
- 内容が正確で、望む出力水準を体現している
- 本番で出会う入力の種類をひととおりカバー
- 迷いやすい境界例・例外例も含む
- 例ごとに書式や口調がバラバラ
- 誤答や雑な出力が混ざっている
- 特定の種類・答えに偏っている(全部同じ分類など)
- 簡単な例ばかりで本番の難所を代表していない
特に注意したいのが偏りです。たとえば感情分類のタスクで、見せた例が3つとも「ポジティブ」だったら、モデルは「このタスクはポジティブと答えがちなものだ」というパターンまで読み取ってしまい、判定がポジティブ側に引っ張られることがあります。分類タスクでは答えの種類をバランスよく含めるのが鉄則です。また、例の中に誤りがあれば、モデルはその誤りも「お手本」として忠実に再現します。例は少数だからこそ、1つの悪例の影響が濃く出るのです。
設計の手順とチェックポイント
実務での例示設計は、次の流れで考えると迷いません。
各ステップのチェックポイントを表にまとめます。
| 観点 | チェック内容 |
|---|---|
| 一貫性 | 例同士の書式・口調・粒度がそろっているか |
| 正確性 | 例の中に誤り・雑な出力が混ざっていないか |
| 代表性 | 本番で出会う入力の種類(難しい例・境界例を含む)をカバーしているか |
| バランス | 分類系のタスクで、答えの種類が偏っていないか |
| 分量 | 例の数と長さが文脈の容量を圧迫していないか |
例の数については、「多いほど良い」とは限りません。まず2〜3例から始めて、失敗が残る種類の入力だけ例を追加するのが効率的です。例を増やすほどコンテキストウィンドウ(一度に読める入力量の上限)を消費し、本番の入力や指示に割ける余地が減ることも忘れないでください。また、モデルによっては例の並び順が結果に影響することも知られており、うまくいかないときは順序の入れ替えも試す価値があります。
最後に1つ、Few-Shot特有の落とし穴を。例は強力に働くため、例に含めたつもりのない癖まで学ばれます。たとえば例の出力がすべて同じ文字数だと、本番でも不自然にその長さへ寄せてくることがあります。例の題材が特定の商品名ばかりだと、本番の出力にその商品への言及が紛れ込むこともあります。「例はすべて意図どおりか」「余計なパターンを見せていないか」を疑う目が、設計の仕上げです。
なお、例示は指示の代わりではなく指示との併用が基本です。冒頭に「何をするタスクか」を一言で述べ、続けて例を並べ、最後に本番の入力を置く。この「指示+例示+本番」の三段構成にすると、モデルは例を「従うべきお手本」として明確に受け取れます。指示なしで例だけを並べると、例の意図の解釈をモデル任せにすることになり、せっかくの例が誤読される余地が残ります。
💡 具体例で考える
カスタマーサポート部門のCさんは、問い合わせメールを「質問/要望/クレーム」に自動分類させようとしました。指示だけ(Zero-Shot)では、「改善してほしい」という丁寧な文面のクレームが「要望」に分類されてしまいます。会社としては「不満の表明を含むなら丁寧でもクレーム」という基準だからです。この基準を言葉で書くのは意外と難しい——そこでCさんは、典型例に加えて「丁寧な文面だがクレームに分類した実例」という境界例を含む6件を、3分類2件ずつバランスよく見せました。すると、微妙な問い合わせも社内基準どおりに分類されるようになりました。境界例こそが判断基準を運ぶ、という好例です。
一方、同僚のDさんは「例は多いほど良い」と考えて過去メール30件を貼り付けましたが、精度はむしろ不安定になりました。例の中に分類ミスが2件混ざっていたうえ、大半が「質問」の例でバランスも崩れていたのです。厳選した6件のほうが、雑多な30件に勝る——「質と代表性が量に勝る」ことを示す実例です。
⚠️ よくある誤解・つまずきポイント
- 誤解:「例は多ければ多いほど精度が上がる」 → 正しくは、質の低い例や偏った例を増やすと逆効果です。厳選した少数から始めて、失敗に応じて足すのが定石です
- 誤解:「例を見せるとモデルがそのデータを学習(記憶)する」 → 正しくは、パラメーターは更新されず、効果はその文脈限りです。次の会話では改めて例が必要です
- 誤解:「例の形式が多少バラバラでも、内容が正しければ大丈夫」 → 正しくは、モデルは形式のパターンも忠実に読み取るため、例のブレはそのまま出力のブレになります
- 誤解:「簡単な例で十分。難しいケースはモデルが察してくれる」 → 正しくは、判断基準は境界例で伝わります。本番の難所を代表する例を含めることが重要です
📝 生成AIテストではこう出る
- 定義を問う形式。「プロンプト内に少数の例示を与えてからタスクを実行させる方法」を選ばせる問題が想定されます。例が1つの場合をOne-Shotと呼ぶ、という用語の対応も押さえておきましょう
- Zero-Shotとの区別を問う形式。プロンプト実例を見て「例の数」で判定させる問題が定番です
- 利点を問う形式。「出力の形式・粒度・スタイルを例で正確に伝えられる」というFew-Shotの強みの正誤判定が考えられます
- コンテキスト内学習との関係を問う形式。「Few-Shotはモデルを再学習させずに例示で能力を引き出す、コンテキスト内学習の一形態である」という位置づけが問われ得ます
📚 まとめ
- Few-Shotは少数の例示で形式・粒度・判断基準を「見せて伝える」使い方で、言葉で説明しにくいことほど例示が効きます
- 良い例示の条件は「一貫性・正確性・代表性・バランス」。誤りや偏りは例が少ないぶん濃く再現されます
- 数は少数精鋭が基本。失敗した種類の入力を例に追加していく反復改善が実務の定石です
- 例はその場限りの手本であり、モデルへの定着はしません。恒久的に覚えさせたい場合はファインチューニングとの使い分けを検討しましょう
