生成AIにメール文の作成を頼んだところ、文章は整っているものの、社内で使うには長すぎた。商品名の分類を頼んだら、期待していた表記とは違う言葉が返ってきた。このような場面では、指示を長く書き足す前に、望ましい回答例を見せる方法が役立つかもしれません。



一言で答えるなら、「少数例プロンプティング」とは、複数のお手本を入力文に含め、生成AIに答え方を示す方法です。Google Developersの用語集では、複数の例によって大規模言語モデルの応答方法を示すプロンプトとして説明されています（出典: Google Developers）。難しそうな名前ですが、考え方は、記入済みの見本を横に置いて書類を作る場面とよく似ています。

たとえば「次の問い合わせを分類してください」とだけ頼むと、「質問」「苦情」「依頼」など、どの言葉を分類名に使うかは曖昧なままです。そこで「配送日はいつですか？ → 配送」「返品したいです → 返品」という架空のお手本を添えると、分類名の粒度や回答の形を示せます。例は正解の知識を後から詰め込むものではなく、その場の依頼で採用してほしい型を伝える材料です。

ただし、お手本を見せれば回答が必ず正しくなるわけではありません。例の内容が間違っていれば、望ましくない型まで伝えるおそれがあります。少数例プロンプティングの中心的な用途は、生成AIを万能にすることではなく、人とAIの間で「どんな答えを期待しているか」という認識のずれを小さくすることにあります。

生成AIは、利用者が入力したプロンプト、つまり依頼文や質問に応じて文章などを生成します（出典: IBM）。少数例プロンプティングでは、その入力の中に「問いと望ましい答え」の組み合わせを複数置きます。モデルは、説明文だけでなく、お手本に共通する並び方や表現も手掛かりとして、続く問いへの回答を組み立てます。



身近なたとえなら、初めて記入する申請書を思い浮かべると分かりやすいでしょう。「簡潔に書いてください」と言われるだけでは、どの程度の長さが適切か迷います。記入済みの見本が二つあれば、日付の書き方、名前の順序、理由の長さなどを推測しやすくなります。生成AIに見せる例も同様に、出力の長さ、項目名、言葉遣い、分類基準などを具体化します。

一つのお手本は、通常「入力」と「期待する出力」の組み合わせで作ります。続けて実際に処理してほしい入力を置けば、どこまでが見本で、どこからが本番なのかを区別しやすくなります。区切りや項目名を毎回そろえることも、例同士の関係を読み取りやすくする工夫です。

ここで変わるのは、その依頼に含まれる手掛かりです。少数例プロンプティングを使っただけで、基礎となるモデルの内部が再訓練されるわけではありません。そのため、別の依頼でも同じ形式を求めるなら、必要なお手本を再び示すという考え方になります。モデルそのものを作り替える方法ではなく、回答を受け取る場面で伝え方を具体化する方法だと捉えると、混同しにくいでしょう。

回答例の数による違いは、「説明だけで頼む」「見本を一つ見せる」「複数の見本から共通点を示す」という三つに分けると整理できます。専門用語では、それぞれゼロショット、一例プロンプティング、少数例プロンプティングなどと呼ばれます。ここでのショットは、回答の手掛かりとして示す例を指します。



| 方法 | 入力に含めるもの | 伝えやすい内容 | 注意点 |
| --- | --- | --- | --- |
| 例なし | 指示と本番の入力 | 単純な目的や一般的な条件 | 回答形式の解釈が分かれることがあります |
| 一例 | 指示、一つの例、本番の入力 | 基本的な書式や語調 | 一例だけの特徴を一般ルールと受け取る場合があります |
| 複数例 | 指示、複数の例、本番の入力 | 共通する形式や分類の境界 | 入力文が長くなり、例の整合性も必要です |

架空の商品レビューを「肯定的」「否定的」に分ける場合、「短く分類してください」だけでも目的は伝わります。ただし、分類名だけを返すのか、理由も添えるのかは明確ではありません。一例を加えれば出力形式を示せますが、その例が極端だと、中間的な表現をどう扱うかまでは伝わらないでしょう。異なる言い回しの例を複数置くと、共通する判断の方向を示しやすくなります。

Google Developersの用語集では、少数例プロンプティングは例なしや一例の場合より一般に良い結果を得やすい一方、プロンプトが長くなると説明されています（出典: Google Developers）。ただし、例が多いほど常に良いという意味ではありません。簡単な依頼なら説明だけで十分なこともあり、数よりも「本番で迷いそうな違いを示せているか」が大切です。

使い分ける際は、最初から大量のお手本を用意する必要はありません。例なしで試し、形式がずれたら一例を加え、それでも判断基準が伝わらなければ異なる種類の例を足す、という順序なら、必要性を確かめながら調整できます。

少数例プロンプティングでは、立派な説明文を書くことより、例同士の形式をそろえることが重要です。入力の見出しが「問い合わせ」なら、すべての例で同じ見出しを使います。期待する回答を分類名だけにしたい場合は、ある例だけに長い理由を付けないほうが意図を伝えやすいでしょう。



次は、架空の問い合わせを担当窓口へ振り分けるための提案例です。実在する組織の分類基準ではなく、プロンプトの形を示すための例示です。

次の問い合わせを「配送」「返品」「商品情報」のいずれかに分類してください。
回答は分類名だけにしてください。

例1
問い合わせ: 注文した品はいつ届きますか。
回答: 配送

例2
問い合わせ: 届いた品を返したいです。
回答: 返品

例3
問い合わせ: この製品の重さを知りたいです。
回答: 商品情報

分類する問い合わせ
問い合わせ: 配達先の住所を変更できますか。
回答:

この例には、依頼の目的、使用できる分類名、回答形式、複数のお手本、本番の入力が含まれています。「短くしてください」のような程度が人によって変わる表現ではなく、「分類名だけ」と結果を確認しやすい条件にしている点も特徴です。

お手本を選ぶときは、同じ内容を言い換えただけの例を並べるより、迷いやすい境界を含めると判断基準が見えやすくなります。たとえば配送状況の確認と住所変更を同じ「配送」に含めたいなら、その違いを示す例が候補になります。反対に、社内でも分類が決まっていない内容を正解例として置くと、生成AI以前に基準が曖昧なままです。

実際の業務へ応用する場合は、個人情報や未公開情報を不用意に例へ入れず、まず架空の文章で形を確かめる方法が考えられます。例を作る作業は、AI向けの準備であると同時に、人が運用ルールを言葉にする機会にもなるでしょう。

「回答例を見せる」という説明から、AIがその場で新しく学習し、ずっと覚える姿を想像するかもしれません。しかし、少数例プロンプティングと、モデルを訓練する学習やファインチューニングは別の方法です。違いは、例をどこで使い、モデル自体を変更するかどうかにあります。



| 観点 | 少数例プロンプティング | ファインチューニング |
| --- | --- | --- |
| 例を使う場面 | 回答を依頼する入力文の中 | 事前訓練済みモデルへの追加訓練 |
| 主な目的 | その依頼で答え方を具体化する | 特定の用途にモデルを適応させる |
| モデルのパラメータ | この方法自体では更新しません | 用途に合わせて全部または一部を調整します |
| 初心者の捉え方 | 見本付きで一件の仕事を頼む方法 | 教材を使って専門向けの再訓練を行う方法 |

IBMは、生成AIの工程を訓練、用途に合わせた調整、生成や評価などに分け、ファインチューニングでは用途固有のラベル付きデータや、想定される質問と望ましい形式の正答を与えると説明しています（出典: IBM）。Google Developersの用語集でも、ファインチューニングは事前訓練済みモデルのパラメータを特定用途に合わせる二次的な訓練であり、通常は多数の例を用いる方法として整理されています（出典: Google Developers）。

少数例プロンプティングは、入力欄で試せる伝え方です。お手本を直せば、その場で指示の内容も直せます。これに対してファインチューニングは、モデルを用途に合わせて調整する開発側の工程であり、一般の利用者が日々の質問で回答例を添えることとは規模も目的も異なります。

したがって、「例を見せたのでAIが永久に覚えた」「この会話でモデルそのものを訓練した」と考えるのは適切ではありません。少数例プロンプティングは、その入力の中で参照できる見本を渡す方法です。この区別を知っておけば、回答形式を直したいだけの場面で、学習という大きな言葉に戸惑わずに済みます。

お手本は、良い形式だけでなく、誤りや曖昧さも具体的に伝えてしまいます。たとえば、三つの例で日付を異なる形式にしておきながら「同じ書式で」と頼めば、どれを基準にすべきか分かりません。分類名に「契約」と「契約関連」が混在していれば、二つを別の分類として扱うのか、単なる表記揺れなのかも曖昧です。



よくある失敗は、見た目の形式だけを整え、内容の正しさを確認しないことです。少数例プロンプティングは答え方を示す方法であり、お手本にない事実を自動的に検証する仕組みではありません。生成AIの回答は、例を付けた場合でも正しいとは限らないため、日付、固有名詞、金額、規則などは別途確認する必要があります。Google Developersの用語集でも、事実性は出力が現実のデータに基づく性質として説明されており、創作を求める依頼とは評価の観点が異なります（出典: Google Developers）。

例の偏りにも注意が要ります。肯定的な問い合わせだけを見せれば、苦情や判断が難しい文章に対する基準は伝わりません。長文と短文、明確な例と迷いやすい例など、本番で現れそうな違いを少しずつ含める方法が考えられます。ただし、例を増やすほど入力は長くなるため、重複するお手本は削る判断も必要でしょう。

確認するときは、「例の答えは人が見ても正しいか」「表記は統一されているか」「例同士でルールが衝突していないか」「本番の入力と離れすぎていないか」を見ます。回答を受け取った後も、期待する形式になったかだけでなく、中身を人が確認してください。例を提示することと、結果を承認することは別の作業です。

少数例プロンプティングを使うか迷ったら、「生成AIが知らないことを教えたいのか」「知っていそうな作業の答え方をそろえたいのか」を分けて考えます。今回扱った方法が向いているのは、主に後者です。分類名、文章の長さ、箇条書きの形、言葉遣いなど、望ましい出力を実例で示したい場面が候補になります。



試す際は、次の順序なら複雑にしすぎず進められます。

- 期待する回答を一文で決めます。
- 例を付けずに依頼し、どこが期待と違うかを確認します。
- 望ましい入力と回答の組み合わせを一つ作ります。
- 判断基準が伝わらなければ、性質の異なる例をもう一つ加えます。
- 例同士の表記と内容を見直し、本番の入力を最後に置きます。
- 生成された内容は、形式と事実を分けて確認します。

たとえば会議メモを「決定事項」「保留事項」「担当者」に整理したいという架空の用途なら、理想の短いメモと整理後の形を二組用意する提案ができます。生成AIが長い説明を付けてしまう場合は、お手本の回答も必要な項目だけにします。逆に、理由を求めるなら、すべての例で理由の書き方をそろえると意図が明確になります。

大切なのは、例の数を競うことではありません。「期待と実際の差がどこにあるか」を観察し、その差を説明できる最小限のお手本を加えることです。明日一つ試すなら、繰り返し頼んでいる簡単な文章作業を選び、理想の回答を一例だけ書いてみてください。それでもずれる部分があれば、異なるケースをもう一例加えます。この小さな比較から、言葉だけの指示と、見本を伴う指示の違いを自分の用途で判断できます。

- What Is Artificial Intelligence (AI)?｜IBM — 2024年8月9日公開、2026年10月2日更新、2026年11月3日取得
- 機械学習用語集：生成AI｜Google Developers — 公開日の記載なし、2026年11月3日取得