社内向けのお知らせを生成AIに頼んだところ、内容は合っていても文章が長すぎたり、見出しの付け方が想定と違ったりすることがあります。「簡潔に」「読みやすく」と書き足しても、思い描いた形式がうまく伝わらない場面は珍しくありません。そんなときに役立つのが、完成形に近いお手本を指示の中へ入れる方法です。

一言で答えるなら、AIにお手本を見せると、言葉だけでは曖昧だった回答の形式や分類の基準を具体的に示せます。複数の少数例を含める指示は、Few-shot prompting（フューショット・プロンプティング、少数の例を含める指示）と呼ばれます。ここでいうプロンプトとは、生成AIへ渡す質問や依頼、条件などをまとめた入力文です。

IBMは、生成AIを、利用者のプロンプトや依頼に応じて文章・画像・音声などのコンテンツを作る深層学習モデルとして説明しています（出典: IBM）。ただし、AIが人と同じ意味で依頼を理解し、意図を察していると考えるのは適切ではありません。生成される回答は、学習したデータの表現やパターンをもとに組み立てられます。曖昧な指示だけを渡せば、考えられる多くの形式から一つが選ばれるため、利用者の期待とずれることがあります。

料理を頼む場面に置き換えると、「軽めの朝食をお願いします」と伝えるだけの場合と、「この写真のように、パンと果物を一皿にまとめてください」と見本を示す場合の違いに近いでしょう。見本があれば、量や配置のイメージを共有しやすくなります。それでも味や栄養が自動的に正しくなるわけではありません。Few-shot promptingも同様で、答え方をそろえる助けにはなりますが、内容の正しさまで保証する仕組みではない点が、この記事の中心となる見方です。

プロンプトに入れるお手本の数によって、呼び方が変わります。例を付けずに依頼する方法がZero-shot prompting（ゼロショット・プロンプティング）、一つだけ示す方法がOne-shot prompting（ワンショット・プロンプティング）、複数の少数例を示す方法がFew-shot promptingです。Google for Developersの用語集では、Few-shot promptingを、大規模言語モデルに応答方法を示す複数の例を含んだプロンプトと定義しています（出典: Google for Developers）。

| 方法 | お手本の数 | 向いている場面 | 注意点 |
| --- | --- | --- | --- |
| Zero-shot | 例なし | 一般的な質問や自由な発想を求める依頼です | 形式や判断基準が曖昧になりやすいです |
| One-shot | 1例 | 出力形式を手短に示したい依頼です | 一つの例の特徴に引っ張られる可能性があります |
| Few-shot | 複数の少数例 | 分類や定型文などの規則を具体化したい依頼です | 入力が長くなり、例の偏りも影響し得ます |

たとえば、架空の店舗に届く問い合わせを「配送」「返品」「その他」に分けたいとします。例なしで分類名だけを指定しても、AIがどこまでを配送に含めるかは明確ではありません。「荷物はいつ届きますか？ → 配送」という1例を入れれば、回答の形は伝わります。しかし、配送先変更や追跡番号に関する質問をどう扱うかは、まだ読み取れません。性質の異なる複数例があれば、分類の範囲をもう少し具体的に示せます。これはあくまで架空の活用例であり、実際の業務では自社の分類基準と照らして確認する必要があります。

Googleの用語集では、Few-shot promptingは一般にZero-shotやOne-shotより良い結果につながる一方、プロンプトが長くなると説明されています（出典: Google for Developers）。ただし、複数例が何個なら必ず十分になるという固定的な数を意味するわけではありません。単純な書式指定なら一つの例で足りることもあり、境界が曖昧な分類では複数の見本が必要になることもあります。数を増やすこと自体ではなく、依頼で迷いやすい違いを例によって見せられているかが判断の軸になります。

プロンプトは、単なる質問文ではなく、AIが回答を作る際に参照する文脈のまとまりです。依頼の目的、守ってほしい条件、入力する内容、お手本、今回処理してほしい対象が一緒に渡されます。AIはその中から、どのような文章や並びが求められているかを推測します。お手本に「入力 → 分類名」という組み合わせが続いていれば、今回の入力にも分類名を続ける形式が期待されていると判断しやすくなる、という捉え方です。

Google for Developersの用語集は、Transformerを基盤とする大規模言語モデルを、以前に予測されたトークンをもとに次のトークンを予測する自己回帰モデルとして説明しています。トークンとは、モデルが文章を処理する際の文字や単語に相当する細かな単位です（出典: Google for Developers）。この仕組みを踏まえると、お手本はAIの頭の中へ新しい規則を恒久的に書き込むものではなく、その回答を作るための文脈として働くものと整理できます。

見本の形式が影響する理由も、ここから考えられます。すべての例が「分類名だけ」で終わっていれば、今回の回答も短い分類名になりやすいでしょう。反対に、一つの例だけ長い理由説明を添えていると、分類名だけが欲しいのか、説明も必要なのかが曖昧になります。見出し、句読点、項目の順番、文章量などもお手本の一部です。内容だけでなく、見た目の構造をそろえることが大切になります。

ここで「AIがお手本から学習した」と表現すると、二つの意味が混ざりやすくなります。モデルを作る段階の学習では、大量のデータを使ってモデル内部のパラメーターと呼ばれる値を調整します。IBMは生成AIの工程を、基盤モデルの訓練、用途に合わせた調整、生成と評価などの段階に分けて説明しています（出典: IBM）。それに対してFew-shot promptingは、利用者が現在の入力に例を添える方法です。普段の入力欄でお手本を追加しただけで、基盤モデルそのものを再訓練したことにはなりません。「今回の回答で参照する見本を渡した」と考えると、違いをつかみやすいでしょう。

Few-shot promptingを試すときは、先に「どんな答えなら使えるのか」を決めます。目的が曖昧なまま例を集めると、お手本同士の書き方がばらばらになり、かえって判断しにくくなります。架空の問い合わせ分類を例にすれば、目的は「担当部署へ振り分けること」、入力は「顧客からの短い文章」、出力は「配送・返品・その他のいずれか一語」と整理できます。この三点が決まれば、必要な例も選びやすくなります。

一つ目の着眼点は、入力と出力の対応を明瞭にすることです。次のような形は、提案用の架空例です。

> 次の問い合わせを「配送」「返品」「その他」のいずれかに分類してください。回答は分類名だけにしてください。
>
> 例1 入力: 荷物の追跡番号を知りたいです。 出力: 配送
>
> 例2 入力: 届いた商品を返したいです。 出力: 返品
>
> 今回の入力: 領収書を再発行できますか。

二つ目は、すべてのお手本で形式をそろえることです。「出力: 配送」と書く例と、「これは返品のお問い合わせです」と文章で答える例が混在すると、何をまねるべきかが不鮮明になります。回答を一語にするなら全例を一語にし、箇条書きにするなら項目の順序まで合わせます。人が見ても規則をすぐ説明できる状態が目安です。

三つ目は、似た例ばかりを並べないことです。配送の例を三つ示して返品を一つも示さなければ、分類全体の境界を十分には伝えられません。よくある典型例に加え、迷いやすい境界の例を選ぶと、何を区別したいのかが見えやすくなります。ただし、実際の運用基準が決まっていない問題を、お手本だけで解決しようとしてはいけません。先に人が基準を定める必要があります。

四つ目は、お手本と矛盾しない言葉で今回の依頼を書くことです。「回答は分類名だけ」と指定しながら「理由も詳しく説明してください」と加えれば、条件同士が衝突します。例を増やす前に、目的、出力形式、禁止事項が一貫しているかを読み返すほうが有効でしょう。Few-shot promptingは、長い指示を書く競争ではありません。短くても、判断に必要な差が見えるお手本を選ぶことが基本です。

お手本は回答の方向を具体化しますが、その働きは良い方向に限られません。例の選び方が偏っていれば、その偏りも回答のパターンとして参照される可能性があります。たとえば、架空の商品レビューを「好意的」「中立」「否定的」に分類する際、強い苦情だけを否定的な例として示すと、遠回しな不満を中立と扱うかもしれません。反対に、少しでも不満を含む文章をすべて否定的とする例を並べれば、分類範囲が広がりすぎる可能性があります。

形式にも偏りがあります。お手本がすべて一文の短い入力なら、複数の論点を含む長い入力に同じ規則を適用できるかは分かりません。特定の商品名、年代、職種などが例に集中していれば、それ以外の対象でも適切に扱えるかを別途確認する必要があります。AIに公平さや常識を任せるのではなく、「この例の集まりは、実際に扱う範囲を代表しているか」と人が問い直すことが欠かせません。

間違ったお手本も注意が必要です。「荷物を返品したいです」という入力へ「配送」と付けた例を入れれば、AIにとっては誤りだと自動的に判定できるとは限りません。利用者が期待する規則として参照される可能性があります。例を追加する前に、人が正解ラベルや文章表現を確認してください。過去の回答をそのまま見本に使う場合も、誤りや古い社内ルールを含んでいないかを点検したほうがよいでしょう。

例の数をむやみに増やすことも避けたいところです。Googleの用語集によると、モデルが一度のプロンプトで扱えるトークン数にはコンテキストウィンドウという範囲があり、Few-shot promptingは例なしの方法より長いプロンプトを必要とします（出典: Google for Developers）。長いほど良いとは限らず、重複した例は重要な違いを見えにくくします。典型例、境界例、異なる形式の入力を少数ずつ選び、不要な重複を外すという考え方が実用的です。

確認するときは、「各分類や出力パターンが含まれているか」「例同士に矛盾がないか」「今回扱う入力と極端に離れていないか」を見ます。これは万能なチェックリストではなく、お手本の偏りへ気付くための提案です。高い影響を伴う判断では、Few-shot promptingだけに任せず、担当者による確認や既存の審査手順を残す必要があります。

Few-shot promptingで改善しやすいのは、主に「どのように答えるか」の共有です。「何が事実か」を自動的に確定する仕組みではありません。Google for Developersの用語集では、現実に基づく出力の性質をファクチュアリティ、つまり事実性として説明しています。また、創作を求める依頼では、事実性より創造性が求められる場合もあるとされています（出典: Google for Developers）。目的に応じて評価の観点を変える必要があります。

たとえば、文章の語調をそろえる依頼では、良い見本があれば期待する書き方を伝えやすくなります。しかし、「ある商品の返品期限を答えてください」という依頼に回答例を付けても、期限の最新情報が正しいとは限りません。商品や制度の情報は、公式ページや手元の規程など、確認できる一次資料と照らす必要があります。見た目が整った回答ほど正しく感じられることがありますが、文章の自然さと事実の正確さは別々に評価したほうが安全です。

確認は三つに分けると進めやすくなります。形式の確認では、文字数、項目順、分類名などがお手本どおりかを見ます。内容の確認では、日付、名称、数値、引用元などを信頼できる資料と照合します。判断の確認では、例外を含む入力や、どちらとも取れる入力を人が見直します。すべての用途で同じ厳しさが必要なわけではありませんが、誤りが人や業務へ与える影響が大きいほど、人による確認を厚くするのが妥当でしょう。

AIへ「分からない場合は分からないと答えてください」と指示する方法も、提案の一つにはなります。ただし、その一文だけで誤回答を完全に防げるわけではありません。お手本の中に「判断材料が不足している入力 → 確認が必要です」という例を含めれば、期待する形式は示せますが、AIが不足を必ず正しく検出する保証はありません。最終的な確認責任までAIへ渡したと考えないことが大切です。

Few-shot promptingの成果を「正答したか」だけでなく、「指定形式を守ったか」「迷う入力を適切に保留できたか」「人が確認しやすい形か」に分けて見ると、改善点を探しやすくなります。お手本は回答を導く手がかりであり、正しさを証明する証拠ではありません。この区別を覚えておけば、整った文章を無条件に信じる失敗を避けやすくなります。

Few-shot promptingを理解する近道は、影響の小さい身近な作業で三つの方法を比べることです。候補としては、個人用メモの分類、架空のお知らせ文の整形、自由に作った商品名のカテゴリ分けなどがあります。医療、法律、採用、金銭に関わる判断のように、誤りの影響が大きい用途を最初の練習台にする必要はありません。実在する個人情報や社外秘情報を使わず、架空の材料で試す方法が無理のない出発点です。

同じ依頼を、例なし、1例、複数例の順で試します。この比較は効果を保証する実験ではなく、お手本の有無による違いを観察するための提案です。回答を見比べる際は、「指定した形式になっているか」「分類基準が一貫しているか」「不要な説明が加わっていないか」「事実確認が必要な内容を断定していないか」を記録します。良い回答だけを眺めるのではなく、どの入力で崩れたかを残すと、次に追加すべき境界例が見つかります。

使い回せる基本形は、目的、規則、お手本、今回の入力という順序です。たとえば、「目的は問い合わせの仮分類です」「回答は三つの分類名のいずれか一語です」と書き、入力と出力の組を複数示してから、今回の文章を置きます。これは提案用の型であり、特定の製品に依存する操作手順ではありません。利用するサービスの入力可能な長さや利用条件は、それぞれの公式案内で確認してください。

結果が期待と違ったときは、例を際限なく足すのではなく、原因を一つずつ切り分けます。形式が崩れたなら、お手本の書式を統一します。分類がぶれたなら、境界例と判断基準を見直してください。事実が誤っているなら、お手本の数ではなく、参照資料と人による検証方法を整える必要があります。目的の異なる問題を同じ修正で解決しようとしないことがポイントです。

Few-shot promptingを使うか迷ったら、「言葉だけでは完成形を説明しにくいか」と自問してみてください。答えが「はい」なら、まず一つのお手本を作り、それでも判断基準が伝わらない部分へ別の例を加えます。明日試す一歩は、繰り返し行っている低リスクな作業を一つ選び、例なしの回答と、確認済みのお手本を添えた回答を並べて見ることです。その差を自分の目で確かめれば、お手本が必要な場面と、通常の指示だけで足りる場面を判断しやすくなるでしょう。

- What Is Artificial Intelligence (AI)? | IBM — 2024年8月9日に公開され、2026年10月2日に更新された資料を、2026年10月31日に取得しています。
- Glossar für maschinelles Lernen: Generative KI | Google for Developers — Few-shot prompting、自己回帰モデル、コンテキストウィンドウ、事実性などの項目を、2026年10月31日に取得しています。