Few-shotプロンプティングとは?例を見せると精度が上がる仕組み

Few-shotプロンプティングとは?例を見せると精度が上がる仕組み

生成AIにメールの分類や議事録の整形を頼んでみたものの、毎回出力の形式がバラバラで、結局自分で体裁を整え直していないでしょうか。

「もっと具体的に指示すればいいはず」と指示文を長くしても、狙った形式にならないまま時間だけが過ぎていく。

こうした揺れは、指示文の長さではなく『AIに見せている情報の種類』が原因であることが多くあります。

生成AIの業務利用が広がったこの数年で、指示文だけで動かす方法(Zero-shot)に加えて、出力させたい例そのものを見せる方法(Few-shot)が実務でよく使われるようになりました。

この記事では、業務自動化の構築設計で使っているプロンプトの組み立て方をもとに、Few-shotプロンプティングの仕組みと、Zero-shot・One-shotとの使い分け基準、メール分類・議事録整形・データ抽出でそのまま使えるプロンプト例を整理しています。

Few-shotプロンプト設計を相談する

Few-shotプロンプティングとは?例を示すことで精度が上がる仕組み

Few-shotプロンプティングとは、AIに実行させたいタスクの『入力と出力の組み合わせ』を複数個プロンプト内に示してから、本番の入力を渡す指示方法です。

指示文で「丁寧に」「簡潔に」と言葉で条件を説明する代わりに、望む出力そのものを見本として渡します。

LLM(Large Language Model:大規模言語モデル)は、プロンプト内に並んだ入力と出力の対応関係からパターンを読み取り、次に来る入力にも同じ対応関係を当てはめようとします。

この『パターンの当てはめ』が起きるため、言葉での説明より実例のほうが出力形式を狙い通りに固定しやすくなります。

例えば「メールの緊急度を分類してください」とだけ指示すると、AIは緊急度の基準を自分で解釈します。

ある日は「至急」「通常」に分け、別の日は「高」「中」「低」に分けるというように、分類のラベル自体が回によって変わることがあります。

ここに『メール本文』と『分類ラベル』のペアを3つほど示しておくと、AIはラベルの語彙も分類基準もその見本に揃えて出力するようになります。

言葉で説明しにくい『体裁』や『粒度』を伝えたいときほど、Few-shotの効果が出やすい場面です。

この『例を見せるだけで、モデルを学習し直さずにタスクを実行させる』という方式は、Few-shotプロンプティングの名称が広まった元論文でも次のように示されています。

For all tasks, GPT-3 is applied without any gradient updates or fine-tuning, with tasks and few-shot demonstrations specified purely via text interaction with the model.
(訳)すべてのタスクにおいてGPT-3は勾配更新やファインチューニングを一切行わずに適用され、タスクとFew-shotの例示はモデルとのテキストのやり取りのみによって指定される。
出典: Brown et al.「Language Models are Few-Shot Learners」

Zero-shot・One-shotとFew-shotプロンプティングの違いはどこにあるか?

3つの手法の違いは、AIに見せる例の数だけです。

Zero-shotは例を1つも見せずに指示文だけでタスクを実行させる方法で、One-shotは例を1つだけ、Few-shotは複数(目安として2~5個程度)の例を見せる方法を指します。

例の数が増えるほどAIが読み取れるパターンの手がかりは増えますが、その分プロンプト自体は長くなります。

どの手法を選ぶかは、タスクの自由度と、AIに既に備わっている知識でどこまで対応できるかで決まります。

手法

見せる例の数

向くタスク

プロンプトの長さ

Zero-shot

0個

一般的な知識で答えが決まるタスク(要約・翻訳など)

短い

One-shot

1個

出力の形式だけを1つの型で伝えたいタスク

やや短い

Few-shot

2~5個程度

分類ラベルの語彙や抽出項目の粒度をそろえたいタスク

やや長い

Zero-shot、One-shot、Few-shotの違いをカードで並べた図

Zero-shotで足りる場面

Zero-shotが向くのは、一般的な知識だけで答えが決まるタスクです。

「この文章を要約してください」「この英文を日本語に訳してください」のように、多くの人が同じ答えにたどり着くタスクでは、例を見せなくても十分な精度が出ます。

例を用意する手間がかからないため、まず指示文だけで試し、出力にばらつきが出た場合にFew-shotへ切り替えるという順番で使うと無駄がありません。

One-shotが有効な場面

One-shotは、出力の『形式』だけを1つの見本で伝えたいときに向いています。

例えば「この形式で商品名と価格を書き出してください」と、見本を1件だけ示すケースです。

ただし見本が1つしかないと、AIはその見本に含まれるたまたまの特徴(文体や項目の並び順など)まで規則だと誤解することがあります。

分類のように判断基準そのものを学ばせたいタスクでは、見本を1つ増やすだけでも判断のブレが目に見えて減ることが多くあります。

Few-shotが効く理由

Few-shotが効くのは、複数の見本を比べることで『何が変化していて何が変化していないか』をAIが切り分けられるようになるためです。

見本が1つだと、AIはその見本の細部すべてを規則だと解釈しがちです。

見本が2つ以上あると、見本同士で共通している部分(分類ラベルの語彙・出力のフォーマット)と、見本ごとに違う部分(本文の内容)を分けて認識できるようになります。

この『共通点の抽出』が、出力を安定させる仕組みの中心です。

Zero-shot・One-shot・Few-shotの使い分けは、指示文をどう設計するかというプロンプトエンジニアリング全体の一部です。

考え方の全体像は、以下で整理しています。

業務でそのまま使えるFew-shotプロンプトの例

Few-shotプロンプティングは、判断基準や体裁を言葉で説明しにくい業務ほど効果が出ます。

以下はメール分類・議事録整形・データ抽出の3つの場面で、そのままコピーして使えるプロンプトです。

見本部分の本文と分類先だけ書き換えれば、別の業務にもそのまま応用できます。

メールの緊急度を分類する

以下のメールを「至急対応」「通常対応」「返信不要」のいずれかに分類してください。

メール: 明日の会議の資料を今日中にご確認いただけますか。
分類: 至急対応

メール: 先月のご報告、ありがとうございました。特に返信は不要です。
分類: 返信不要

メール: 来週の定例会議の時間変更は可能でしょうか。
分類: 通常対応

メール: 【至急】システム障害が発生しています。至急ご確認ください。
分類:

このプロンプトでは、3件の見本を通して「メール本文」と「分類ラベル」の対応関係をAIに読み取らせ、4件目の分類ラベルだけを埋めさせています。

自分の業務に合わせて変える場所は次の2つです。

分類ラベル(「至急対応」「通常対応」「返信不要」の部分)は、自社の運用に合わせた区分名にそのまま置き換えられます。

見本のメール本文は、実際に届いた過去のメールから典型的な3パターンを選んで貼り付けると、AIが読み取る基準がより実態に近づきます。

会話ログから議事録を整形する

以下の会話ログを「決定事項」「保留事項」「次回までのタスク」の3項目に整形してください。

会話ログ: Aさん「新機能のリリース日は来月10日で確定しましょう」Bさん「はい、それで進めます」Aさん「予算の件はまだ結論が出ていないので次回持ち越しですね」Bさん「資料は私が来週までに準備します」

決定事項: リリース日は来月10日
保留事項: 予算の件
次回までのタスク: Bさんが資料を準備(来週まで)

会話ログ: [ここに新しい会話ログを貼り付け]

決定事項:
保留事項:
次回までのタスク:

見本の会話ログには、決定事項・保留事項・タスクの3種類がすべて含まれるものを選んでいます。

3種類のうち1つでも欠けた会話ログを見本にすると、AIがその項目の抽出基準を学習できず、本番の議事録でも同じ項目が漏れやすくなります。

自分の会議に合わせて変える場所は、見本の会話ログと整形後の3項目です。

決定事項・保留事項・タスク以外の項目(例えば「懸念事項」)を追加したい場合は、見本側にもその項目を1行加えておくと、本番の出力にも同じ項目が反映されます。

文章から氏名・日付・金額を抽出する

以下の文章から「氏名」「日付」「金額」をJSON形式で抽出してください。

文章: 山田太郎様より、2026年5月10日に30,000円のお支払いがありました。
抽出結果: {"氏名": "山田太郎", "日付": "2026-05-10", "金額": 30000}

文章: 佐藤花子様から、2026年6月1日付で15,000円のご入金を確認しました。
抽出結果: {"氏名": "佐藤花子", "日付": "2026-06-01", "金額": 15000}

文章: [ここに新しい文章を貼り付け]
抽出結果:

この例では、日付の書式(西暦とハイフン区切り)と金額の書式(カンマなしの数値)を見本の時点で統一しています。

AIは見本の書式をそのまま踏襲するため、Excelなど別のシステムに読み込ませたい書式があれば、見本の時点でその書式に揃えておく必要があります。

抽出する項目を増やしたい場合は、見本のJSONにキーを1つ追加し、対応する値も文章側に含めておいてください。

Few-shotプロンプティングで例を用意するときの判断基準

Few-shotの効果は、見せる例の数と質で決まります。

例を増やせば増やすほど精度が上がるとは限らず、多すぎる見本がかえって出力を乱すこともあります。

以下では、例の数・多様性・向かない場面という3つの基準で、見本の作り方を整理します。

例の数の目安

見本の数は2~5個程度から始め、出力が安定しない場合に1つずつ増やす進め方が扱いやすい方法です。

見本を1つ増やすたびにプロンプト全体が長くなるため、AIが読み込む量が増え、処理にかかる時間や利用コストも増えます。

分類のように答えが数種類に決まっているタスクでは、各分類ラベルにつき見本を1つずつ用意すると、ラベルの数だけ見本があることになり判断基準が伝わりやすくなります。

例えば分類先が5種類ある業務なら、まず各ラベルに1つずつで5個の見本を用意し、AIが迷いやすい2つのラベル(内容が近い組み合わせ)にはもう1つずつ見本を足して6~7個にする、という増やし方が実務では扱いやすい進め方です。

見本を増やすほどプロンプト全体が長くなり、AIが一度に読み込める情報量の上限にも近づいていきます。

この上限の仕組みは、以下で解説しています。

見本の多様性を確保する

見本を選ぶときは、内容が似た例を並べるより、判断が分かれる境界線上の例を含めるようにします。

先ほどのメール分類の見本では、「至急対応」「通常対応」「返信不要」という3つの分類すべてに1件ずつ見本を割り当てています。

もし見本を「至急対応」の例ばかり3件にしてしまうと、AIは「至急対応」以外のラベルをほとんど使わなくなる傾向が出ます。

分類先の数だけ見本の種類をそろえることが、実務で最も効果が出やすい調整です。

分類先が2つしかない単純な判定でも、両極端な例だけでなく境界に近い微妙な例を1件加えて計3件にすると、AIが極端な特徴だけで判断する傾向を抑えられます。

【よくある誤解】例は多いほど精度が上がるわけではない

「見本を増やせば増やすほど精度が上がる」と考えがちですが、実際には見本の数より見本同士の対応関係の明確さのほうが精度に影響します。

似た内容の見本を10件並べても、AIが読み取れる新しい情報は増えず、プロンプトが長くなって処理コストが増えるだけに終わることがあります。

反対に、分類の境界線をまたぐ見本を3件そろえるほうが、似た見本を10件並べるより出力が安定するケースが多くあります。

Few-shotが向かない場面

Few-shotプロンプティングは、判断基準やパターンを例から読み取らせる手法のため、答えを導くのに複数の手順を踏む必要がある推論タスクにはあまり向きません。

数値計算や条件分岐が絡む複雑な判断では、見本を並べるより「手順を順番に考えてください」と考え方の手順そのものを指示する方法のほうが精度が出ることがあります。

例えば経費精算の妥当性を1件ずつ判断させたい場合、見本の金額や品目が本番の申請と表面的に似ているだけで『承認』と出力してしまうことがあります。

金額の上限や部署ごとの規定など、複数の条件を組み合わせて判断させたいタスクには、見本を並べるより判断の手順そのものを指示文で明示する方法が向いています。

また、氏名や取引先名など個人情報や機密情報を含む文章を見本にすると、その情報がプロンプトの一部としてAIサービス側に送信される点にも注意が必要です。

見本には実在のデータをそのまま使わず、内容を保ったまま架空の氏名や数値に置き換えたものを使うと、この懸念を避けられます。

見本と表面的に似ているというだけの理由でAIが誤った判断を下すケースは、ハルシネーションと呼ばれる問題の一種でもあります。

対策の考え方は、以下にまとめています。

自社の状況に当てはめて判断に迷う場合は、 個別相談 で一緒に整理することもできます。


Few-shotプロンプティングを試しても出力が安定しませんか。

「見本をいくつ用意すればいいかわからない」「分類ラベルの揺れが直らない」「そもそも自社のどの業務に使えるのかわからない」。

少しでもお心当たりがあれば、お気軽にご相談ください。

現在、AI業務自動化に関するお悩みをお伺いする 無料の個別相談 を実施しています。

よくある質問

Q. Few-shotプロンプティングに使う見本は毎回同じものを使い回してよいですか?

同じ業務であれば使い回して問題ありません。

ただし分類ラベルを追加したり、抽出したい項目を変えたりした場合は、見本側にもその変更を反映してから使ってください。

見本と本番で求める形式が食い違っていると、AIはどちらの形式を優先すべきか判断できず、出力が不安定になります。

Q. 見本の数を増やしてもプロンプトの文字数制限に引っかかりませんか?

多くの生成AIサービスには1回のやり取りで扱える文字数の上限があり、見本を増やすほどこの上限に近づきます。

数個程度の見本であれば普段のチャット画面での利用で上限に達することはまれですが、見本1件あたりの文章が長い場合は見本の数を絞るか、見本の文章自体を短く要約してから使ってください。

Q. Few-shotプロンプティングとプロンプトエンジニアリング全体はどう違いますか?

プロンプトエンジニアリングは、AIへの指示文を設計する取り組み全体を指す言葉で、Few-shotプロンプティングはその中の一つの手法です。

指示文の構成や役割設定なども含めた設計全体を見直したい場合は、プロンプトエンジニアリング全体の考え方から確認すると整理しやすくなります。

Q. 見本と本番の入力の形式が微妙に違う場合はどうすればよいですか?

見本と本番で文章の長さや文体が多少違っていても、分類ラベルや抽出項目の対応関係さえ一貫していれば大きな問題にはなりません。

ただし見本が短文ばかりで本番が長文の場合など、極端に形式が離れていると精度が下がることがあるため、本番でよく扱う文章の長さに近い見本を選んでください。