Few-shot（少数例プロンプト）とは？AIへの依頼にお手本を添える書き方

AIに社内向けの問い合わせ分類を頼むと、内容は近くても、分類名や書き方がそろわないことがあります。依頼文にどこまで基準を示せばよいか、指示だけで足りるのかが引っかかります。

ただし、例は多ければよいわけではなく、実際の依頼に近い例を選び、利用中の製品で出力を比べて確かめます。例に業務データを含める場合は、使うサービスの案内と会社のルールも確認が必要です。

この記事では、Few-shotの基本、例を見せない依頼との違い、例の選び方、業務で確認する点を整理します。出力をそろえるために、お手本と別の仕組みをどう使い分けるかも分かります。

Few-shotとは何か

Few-shotは、AIへの依頼文に少数の入出力例を添え、新しい入力にも同じ型で答えるよう示す書き方です。少数例プロンプトとも呼ばれ、例は依頼の補足ではなく、お手本として置きます。

お手本は入力と出力を対にする

お手本は「この入力なら、この出力にする」という対で作ります。入力だけを並べるより、望む分類名、文の長さ、項目の順番まで示せます。

たとえば問い合わせを分類する場合は、次のように置けます。社内の実データを使うかは、後で説明する確認点を踏まえて決めます。

• 依頼: 問い合わせを「設定」「請求」「障害」のいずれかに分類する
• お手本の入力: 請求書の宛名を変えたい
• お手本の出力: 分類は「請求」
• 新しい入力: パスワードを変更できない

OpenAIは、少数の入力・出力例でモデルに新しいタスクのパターンを示す方法をFew-shot learningと説明しています。例は、実際に起こり得る入力と、望む出力を組にするのが基本です。

できるのは出力の型を示すこと

Few-shotは、依頼の内容や書き方を伝える方法です。プロンプトとは何かでは、AIに渡す依頼文そのものを詳しく説明しています。

システムプロンプトとは何かは、あらかじめ設定しておく指示です。Few-shotは、その都度の依頼文にお手本を添える点で役割が異なります。

例を見せない依頼と何が違うのか

例を見せず、指示と新しい入力だけで頼む書き方はZero-shotと呼ばれます。Few-shotとの違いは、AIに望む答え方の実例を先に見せるかどうかです。

同じ依頼でも示せる基準が変わる

「問い合わせを分類してください」だけでは、分類名の候補、迷う場合の扱い、出力の書式をAIが補うことになります。Few-shotでは、その補いたくない部分を例で見せます。

Googleは、Few-shotを出力の書式、表現、範囲、一般的なパターンを調整する用途として案内しています。お手本は、正解を丸写しさせるためではなく、今回の依頼で採用する型を伝えるものです。

Zero-shotの詳細は別記事で扱う

Zero-shotは、例を見せず、指示と新しい入力だけで頼む書き方です。Few-shotとの違いは、お手本の入出力例を先に置くかどうかです。

このページでは、Zero-shotをFew-shotとの対比に必要な範囲だけにとどめます。例を見せない依頼の詳しい使い方は、別記事で扱う予定です。

どんな例をいくつ入れるとよいのか

例は、実際にAIへ頼む仕事に近い入力と、望む出力の組で選びます。見た目だけが似た例より、分類や要約で迷いやすい条件を含む例の方が、確認したい型を示しやすくなります。

実際の依頼に近い例を選ぶ

Anthropicは、例を実際の用途に近づけ、多様な例で意図しないパターンを拾わせないことを案内しています。通常の入力だけでなく、判断が分かれやすい入力もお手本に入れると、どこを見て分類するかを示せます。

たとえば「請求」と「設定」が混ざる問い合わせなら、どちらを優先するかが分かる例を用意します。例にない新しい例外まで正しく扱えることを約束するものではないため、出力を比べて確認します。

例数は少なく試してから増やす

Anthropicの公式ガイドは、3〜5例を開始目安として示しています。これは同社の案内であり、すべてのAIや業務で固定すべき数ではありません。

Googleも、例を増やしすぎると例に過度に合わせるおそれがあると説明しています。最初は必要な型を示す少数例で比べ、足りない判断の型が見えたときに例を加えます。

業務で使うときは何に気をつけるのか

Few-shotのお手本も、AIへ渡す依頼文の一部です。実際の業務に近づけようとして、顧客名、連絡先、社内資料の文面を例へそのまま入れると、入力する情報の扱いを確認する必要が出ます。

例も入力データとして確認する

確認する対象は、新しい依頼だけではありません。お手本に含める入力、出力、添付する資料のそれぞれを、利用中のサービス・プランの案内と会社のルールに照らして見ます。

• どのサービス・プランへ入力するか
• 入力・出力の保持や利用に関する案内はどうなっているか
• 社内で扱ってよい情報の範囲や承認手順はどうなっているか

OpenAIは、Business、Enterprise、APIなど対象の組織向けサービスでは、入力・出力を既定で学習に使わないと説明しています。これはOpenAIの対象サービスの説明であり、他社製品や個人向けプランの扱いを示すものではありません。

デジタル庁の政府情報システム向けガイドラインでも、生成AIへの入出力データの取り扱いを管理する観点が示されています。民間企業への適用をここで判断するものではありませんが、例も確認対象に含める考え方の参考になります。

理由欄は説明の型であって証明ではない

理由の説明を求められる業務では、お手本に「分類」と「判断理由」を並べ、同じ項目で返すよう頼めます。これにより、確認する人が見る順番をそろえやすくなります。

ただし、その理由欄はお手本に沿って生成された出力です。AIの内部処理を開示するものでも、分類や結論の正しさを証明するものでもありません。

根拠が必要な場面では、理由欄に加えて、参照した社内資料や一次資料を人が確かめられる形で残します。説明が読みやすいことと、内容が正しいことは分けて確認します。

出力の形をそろえたいときはどうするのか

Few-shotでは、メールの下書き、議事録の見出し、分類結果の書き方のように、読みやすい型を示すお手本を置けます。お手本の出力に項目名や順番を置き、実際の出力でその形を確かめます。

読みやすい型をお手本で示す

たとえば「要点」「対応案」「確認事項」の順に短くまとめる例を置き、望む文章の構成を示します。書式がぶれたときは、望む形の例が不足していないかを先に見直します。

ただし、お手本は出力の型を示す手段です。後続の業務で決まった項目を受け取る必要がある場合は、見た目をそろえることだけでは足りないことがあります。

決まった項目を扱うなら別の仕組みも確認する

次の処理で必須の項目名やデータの形がある場合は、Few-shotに加え、利用中の製品が提供する形式指定の機能を確認します。構造化出力とは何かでは、この考え方を詳しく説明しています。

Few-shotと構造化出力は、どちらか一方だけを選ぶ話ではありません。前者は見せたい例、後者は扱いたいデータの形という、別の目的で検討します。

まとめ

Few-shotは、AIへの依頼文に少数の入出力例を添え、望む出力の型を見せる書き方です。例を見せないZero-shotとは、手本を先に渡すかどうかが異なります。

まずは公開してよい題材で型を比べる

最初は、会社のルール上扱える題材で、お手本あり・なしの出力を比べます。そろえたい分類名、見出し、理由欄を一つ決めると、例を足す必要があるか確かめやすくなります。

例を増やす前に、実際の依頼に近いか、例の中に確認が必要な情報がないかを見直します。理由欄を使う場合も、根拠資料と人の確認を置き換えないことが大切です。

会社で試す業務、確認すべき情報、出力の基準を整理したい場合は、お問い合わせはこちらからご相談ください。

この記事の出典

• Prompt engineering（OpenAI、2026年9月13日確認）
• Prompting best practices（Anthropic、2026年9月13日確認）
• Prompt design strategies（Google、2026年9月13日確認）
• Business data privacy, security, and compliance（OpenAI、2026年9月13日確認）
• 行政の進化と革新のための生成AIの調達・利活用に係るガイドライン（デジタル庁、2026年9月13日確認）