2026.09.26 AI

few shotとは？Few-shotプロンプトの例示の選び方・並べ方とAPI実装・評価手順を解説【2026年版】

few shot（Few-shotプロンプト）は、指示文に入力と正解の組を数件添えて、モデルに作業の型を示す書き方です。書き方そのものは単純ですが、同じ5件の例示でも並べる順番を変えただけで、分類の正答率がランダムな推測に近い水準まで落ちることが論文で報告されています。この記事では、zero-shot・one-shotとの違いを整理したうえで、例示の件数・並び順・選び方をどう決めるか、Claude APIでどう組み込むか、ぶれをどう測るか、費用をどう見積もるかを、そのまま動かせるコードと一次情報のリンク付きで解説します。

まとめ：few shotを入れる条件と、例示の件数・並び順・選び方の結論

few shotは、出力の形式や判定の基準を言葉で説明しきれないときに、実例で示す手段です。モデルの重みは変わらず、プロンプトの中だけで挙動が変わります。実装の起点は、例示を3〜5件、タグで指示と入力から分けて置く形です。Anthropicの公式ガイドもこの件数を出発点として示しています。

効きを左右するのは件数より中身と並べ方です。例示のラベルが正しいかどうかより、ラベルの種類・入力の分布・書式がそろっているかのほうが効く、という実験結果があります。並び順とラベルの偏りも、答えが寄る要因です。したがって例示は固定で置きっぱなしにせず、評価用データで順序を入れ替えて正答率の幅を測り、幅が大きければ入力に近い例示を検索で選ぶ動的few-shotへ移る、という順で詰めていきます。

見送る判断もはっきりさせておきます。指示文だけで業務要件の正答率を満たしている処理に例示を足しても、入力トークンが増えるだけです。逆に、誤答の型を潰すために例示が50件、100件と膨らんでいくなら、プロンプトで抱える段階を過ぎています。その場合はファインチューニングか、判定の一部をルールへ移す設計を比べてください。

few shotの定義と、zero-shot・one-shot・many-shotとの違い

用語の出どころと、何件から何と呼ぶかを先に固定します。ここがずれると、社内でプロンプトを比べる議論がかみ合いません。

few shotの定義と、GPT-3論文が示した勾配更新なしの学習

few shotという呼び方を広めたのは、GPT-3を発表したBrown et al.「Language Models are Few-Shot Learners」（arXiv:2005.14165・v1は2020年5月）です。同論文は、175B（1,750億）パラメータのモデルに対して、勾配更新もファインチューニングも行わず、テキストで示した例示だけでタスクを指定する使い方を評価しました。

この「重みを変えずに、入力の中の例から作業を読み取らせる」性質を、文脈内学習（in-context learning）と呼びます。few shotはその使い方の一形態です。学習と呼ばれてはいるものの、モデルは何も覚えません。リクエストが終われば例示の影響は消え、次のリクエストでは毎回送り直すことになります。この性質が、後で扱う費用とキャッシュの話に直結します。

zero-shot・one-shot・few-shot・many-shotの件数比較

呼び分けの基準は、プロンプトに含める例示の件数です。

呼び方	例示の件数	向く場面	主な弱点
zero-shot	0件	指示で足りる処理	書式が揺れる
one-shot	1件	書式だけ示したい	その1件に寄る
few-shot	数件（2〜10件程度）	判定基準を示す	順序と偏りに敏感
many-shot	数百〜数千件	長文脈モデルでの難題	入力費用が大きい

many-shotは、長いコンテキストを持つモデルの登場で試せるようになった領域です。Agarwal et al.「Many-Shot In-Context Learning」（arXiv:2404.11018・v1は2024年4月）は、例示を数百から数千件に増やすと生成・判別の両タスクで性能が伸び、事前学習のバイアスを上書きできる場合があると報告しています。ただし実務で最初に試すのはfew-shotの範囲です。

例示から読み取られるのはラベルの正しさより形式と分布という実験結果

few shotの設計で最も誤解されやすいのが、例示の役割です。Min et al.（arXiv:2202.12837・v1は2022年2月）は、分類と多肢選択のタスクで例示のラベルをランダムに入れ替えても、性能がほとんど落ちないことを示しました。効いていたのは、ラベルの種類（何を答えとして返すか）、入力テキストの分布、例示全体の書式の3点です。

ここから実装上の指針が2つ出ます。ひとつは、例示は「正解を教える」より「答え方の枠を見せる」道具だと理解することです。もうひとつは、本番の入力と似た文体・長さの例示を選ぶことです。問い合わせメールを分類するのに、短い整った文だけを例示に使うと、長く崩れた実メールで型が外れます。

few-shotプロンプトの書き方とClaude APIで動かす実装コード

ここからは手を動かす部分です。書き方の基本形を決め、Pythonで分類処理を組み、例示の渡し方を選びます。

例示をタグで区切り、指示と本番の入力から分離する書き方の基本形

例示は、指示文や本番の入力と混ざらない形で置きます。Anthropicの Prompting best practicesは「Use examples effectively」の節で、例示を実際の用途に近づけること、境界の事例まで含めて多様にすること、<example>タグ（複数なら<examples>タグ）で囲むことの3点を挙げ、件数は3〜5件を推奨しています。

OpenAIのPrompt engineeringガイドも、例示はAPIリクエストの developer メッセージに含めるのが通常の形だとし、入力と出力をXML風のタグで区切った例を載せています。ベンダーをまたいでも骨格は同じで、「指示」「例示群」「本番の入力」を別の区画に置き、出力の形だけを例示でそろえます。

Python SDKで問い合わせ分類をfew-shotで動かす最小コード

問い合わせ文を「請求」「障害」「解約」「その他」の4区分に振り分ける処理を、固定の例示5件で組んだ例です。モデルIDとoutput_configの書式は、2026年9月時点のAnthropic Models overviewとeffortの公式ドキュメントに合わせています。

# pip install anthropic  （環境変数 ANTHROPIC_API_KEY を設定しておく）
import anthropic

client = anthropic.Anthropic()

INSTRUCTION = """あなたは問い合わせの分類器です。
入力を「請求」「障害」「解約」「その他」のいずれか1語だけで答えてください。
"""

EXAMPLES = [
    {"input": "先月の請求額が二重に引き落とされています", "output": "請求"},
    {"input": "管理画面にログインすると500エラーが出ます", "output": "障害"},
    {"input": "来月末で契約を終了したいので手続きを教えてください", "output": "解約"},
    {"input": "請求書の宛名を部署名入りに変えられますか", "output": "請求"},
    {"input": "API仕様書の最新版はどこで見られますか", "output": "その他"},
]


def build_examples_block(examples):
    parts = [
        f"<example>\n<input>{e['input']}</input>\n"
        f"<output>{e['output']}</output>\n</example>"
        for e in examples
    ]
    return "<examples>\n" + "\n".join(parts) + "\n</examples>"


def ask(system, text):
    resp = client.messages.create(
        model="claude-sonnet-5",
        max_tokens=1024,
        system=system,
        messages=[{"role": "user", "content": f"<input>{text}</input>"}],
        output_config={"effort": "low"},  # 一手で決まる分類なので思考量を抑える
    )
    # 思考ブロックが混ざる場合があるため text ブロックだけを連結する
    return "".join(b.text for b in resp.content if b.type == "text").strip()


SYSTEM = INSTRUCTION + build_examples_block(EXAMPLES)
print(ask(SYSTEM, "請求書PDFがダウンロードできません"))

最後の入力は、あえて「請求」と「障害」の境目に置いた文です。こうした境界の入力でどちらに倒すかは、指示文で言葉を足すより、同じ型の例示を1件入れて答えを見せるほうが安定します。例示群の書き方は関数に切り出してあるので、後述の動的選択と評価でもそのまま使い回せる構成です。回答を後段のプログラムで受けるなら、1語で答えさせるだけでなくLLM構造化出力とは？JSON Schemaで出力形式を保証する仕組みで型を固定しておくと、想定外の語が返ったときに検知できます。

例示を会話ターンで渡すか、1通のメッセージに埋め込むかの判断

例示の渡し方には、上のコードのようにsystemへまとめて埋め込む形と、user と assistant の往復として会話履歴に並べる形の2通りがあります。

選ぶ基準は、例示と本番の入力を明確に分けたいかどうかです。会話ターン形式は「過去にこう答えた」という履歴として読まれるため、口調や長さの模倣は強く出ます。一方で、例示の中身を本番の入力と取り違える余地も残る形式です。業務処理ではsystemにタグで区切って置く形を基本にし、チャットの応答トーンを合わせたいときだけ会話ターン形式を試す、という使い分けで迷いは減ります。

例示の件数・並び順・選び方で正答率が揺れる箇所と評価に基づく設計

few shotが扱いにくいと言われる理由の大半は、この章の3点に集まっています。どれも論文で数値が出ている現象です。

例示は3〜5件から始め、評価で誤答の型を見て1件ずつ足す進め方

件数は3〜5件から始めます。増やすのは、評価で誤答が出て、その誤答に共通する型が見えたときだけです。たとえば「解約の相談」と「プラン変更の相談」を取り違えるなら、プラン変更を「その他」に振る例示を1件足します。まとめて10件足すと、どの例示が効いたのか切り分けられません。

ラベルごとの件数の釣り合いも見ておきます。上のコードは「請求」が2件で他が1件ずつです。この偏りが、次に述べる多数派ラベルへの寄りを生む原因になります。本番の入力で「請求」が実際に多いなら偏りは意図どおりですが、そうでないなら各ラベル1件ずつにそろえてから測り直してください。

並び順とラベルの偏りで答えが寄るバイアスと、順序を散らす対策

Lu et al.（arXiv:2104.08786・v1は2021年4月）は、同じ例示でも並べる順番によって、最先端の性能とランダムな推測ほどの差が出ることを示しました。この現象はモデル規模を問わず現れ、良い順序はモデル間で使い回せない、とも報告しています。

Zhao et al.「Calibrate Before Use」（arXiv:2102.09690・v1は2021年2月）は、その原因を、プロンプト末尾に近い答えや事前学習で頻出の答えへ予測が寄るバイアスに求めました。同論文が提案した補正手法は、GPT-3とGPT-2の平均精度を最大30.0ポイント押し上げています。

実装での対策は3つに絞れます。末尾に同じラベルの例示を連続させないこと。ラベルの出現回数を意図した比率に合わせること。そして、順序を固定する前に複数の並びで正答率を測ることです。3つめのためのスクリプトは次の章で示します。

本番の入力に近い例示を検索で選ぶ動的few-shotの実装コード

固定の例示で順序のぶれが大きい、あるいは入力の種類が広くて5件では代表しきれない場合は、入力ごとに近い例示を選び直す方式へ移ります。Liu et al.（arXiv:2101.06804・v1は2021年1月）は、テスト入力と意味の近い例示を検索して並べる方式が、ランダムに選ぶ方式を一貫して上回り、表からの文生成で41.9%、オープンドメイン質問応答で45.5%の改善が出たと報告しています。

# pip install scikit-learn
from sklearn.feature_extraction.text import TfidfVectorizer
from sklearn.metrics.pairwise import cosine_similarity

# 例示の候補プール（実運用では数十〜数百件を用意し、評価用データとは重ねない）
POOL = EXAMPLES + [
    {"input": "クレジットカードの登録を変更したい", "output": "請求"},
    {"input": "通知メールが今朝から届きません", "output": "障害"},
    {"input": "年間契約を途中で解約すると違約金はかかりますか", "output": "解約"},
    {"input": "操作説明会の日程を知りたいです", "output": "その他"},
]

# 日本語を分かち書きせずに比べるため、文字2〜3グラムで特徴量を作る
vectorizer = TfidfVectorizer(analyzer="char_wb", ngram_range=(2, 3))
pool_matrix = vectorizer.fit_transform([e["input"] for e in POOL])


def select_examples(text, k=4):
    sims = cosine_similarity(vectorizer.transform([text]), pool_matrix)[0]
    top = sims.argsort()[::-1][:k]
    return [POOL[i] for i in top]


def ask_dynamic(text):
    system = INSTRUCTION + build_examples_block(select_examples(text))
    return ask(system, text)


print(ask_dynamic("領収書の発行はできますか"))

ここでは依存を減らすために文字n-gramのTF-IDFで近さを測りましたが、本番では埋め込みモデルで測るほうが言い換えに強くなります。LangChainを使っているなら、langchain_core.example_selectorsのSemanticSimilarityExampleSelectorがベクトルストアを介して同じ役割を担う仕組みです。例示の選定そのものを評価指標に沿って自動で探す方向へ進めるなら、DSPyのチュートリアル（シグネチャとモジュールの使い方）で扱う例示の自動探索が次の選択肢になります。

few shotの効果を測る評価スクリプトと、例示トークンの費用見積もり

例示を入れるかどうか、どの並びで固定するかは、感覚ではなく数字で決めます。測るのは正答率の幅と、例示が上乗せする費用の2つです。

同じ例示の順序を入れ替えて正答率のぶれを測るPython評価スクリプト

前章のaskとbuild_examples_blockをそのまま使い、例示5件の並びを乱数で5通り作って、それぞれの正答率を出すスクリプトです。例示なしの正答率も同じデータで測り、few shotを入れる意味があるかを同時に確かめます。

import random
import statistics

# 評価用データ（本番の入力から30〜50件を抜き出し、例示プールとは重ねない）
EVAL = [
    ("請求書の再発行をお願いします", "請求"),
    ("ファイルのアップロードが途中で止まります", "障害"),
    ("今月で利用をやめたいです", "解約"),
    ("導入事例の資料をもらえますか", "その他"),
    # ... 以下、実データで30件以上に増やす
]


def accuracy(system):
    hits = sum(ask(system, text) == gold for text, gold in EVAL)
    return hits / len(EVAL)


zero = accuracy(INSTRUCTION)
scores = []
for seed in range(5):
    order = EXAMPLES[:]
    random.Random(seed).shuffle(order)
    scores.append(accuracy(INSTRUCTION + build_examples_block(order)))

print(f"zero-shot: {zero:.3f}")
print(f"few-shot : 平均 {statistics.mean(scores):.3f}"
      f" / 最小 {min(scores):.3f} / 最大 {max(scores):.3f}")

読み方は単純です。few-shotの平均がzero-shotを上回らないなら、例示は外します。平均は上回るのに最小と最大の開きが大きいなら、並びに結果が左右されている状態なので、前章の動的選択か、例示の入れ替えが検討の対象です。開きが小さく平均も高い並びが見つかったら、その順序で固定し、モデルを差し替えたときに測り直します。良い順序はモデル間で使い回せないという前述の報告があるためです。評価データの集め方と、正答率以外の指標の置き方はLLM評価とは？指標・データセット設計・評価ツールの選び方にまとめています。

固定の例示トークンの月額費用と、プロンプトキャッシュで下げる設計

例示は毎回のリクエストで入力トークンとして課金されます。2026年9月時点のAnthropic Models overviewでは、Claude Sonnet 5の入力は100万トークンあたり2ドルです。仮に例示部分が400トークンで月10万件を処理すると、例示だけで月4,000万トークン、約80ドルが上乗せされます。

固定の例示なら、プロンプトキャッシュで下げられます。Anthropicの Prompt cachingでは、キャッシュの読み出しは基本入力単価の0.1倍、5分保持の書き込みは1.25倍です。注意点は2つあります。Sonnet 5でキャッシュできるのは1,024トークン以上の区画からなので、例示400トークンだけでは対象になりません。指示文と固定の例示を合わせて先頭に置き、その長さを確かめてください。もう1点、キャッシュの判定条件は先頭からの完全一致です。動的few-shotのように入力ごとに例示が変わる区画はキャッシュが効かないため、変わらない指示文を前に、変わる例示を後ろに置く順番にします。仕組みの詳細はプロンプトキャッシュ（Prompt Caching）とは｜仕組みと主要APIの使い方で解説しています。

few shotを採用する条件と、ファインチューニングやCoTへ切り替える判断

ここまでの測り方を前提に、採用と見送りの線を条件付きで言い切ります。

few shotを採用してよい処理と、例示を入れずに済ませる処理の境界

次のどれかに当てはまるなら、few shotを試す価値があります。

出力の書式や語彙を、社内の既存データと完全にそろえる必要がある（分類ラベル、定型の返信文、決まった項目名）
判定の基準が暗黙知で、言葉にすると長くなるが、実例なら数件で示せる
zero-shotで測った誤答が、知識不足ではなく境界事例の倒し方の違いに集中している

逆に、zero-shotの時点で業務要件の正答率を満たしているなら入れません。例示が増やすのは入力費用と、並び順に結果が左右される不安定さの2つだからです。正答率が足りない原因が知識の欠落にある場合も、例示ではなく参照情報を渡す設計のほうが早く解決します。

例示が50件を超えて膨らむならファインチューニングを比べる判断基準

誤答を潰すたびに例示を足していくと、いずれ数十件に達します。本記事では、例示が50件を超えた時点をひとつの目安に置き、プロンプトに抱え続けるか、追加学習へ移すかを比べ直すことを勧めます。例示が多いほど毎回の入力費用が増え、並び順の検証も重くなるためです。

比べる材料は、月間の処理件数と例示トークンから出した入力費用、例示の入れ替え頻度、そして判定基準がどれだけ固まっているかです。基準が月単位で動くならプロンプトのほうが直しやすく、基準が固まっていて処理件数が多いなら追加学習の固定費が回収できる見込みが立ちます。追加学習とRAGを含めた使い分けはファインチューニングとは？LLMの追加学習の仕組み・RAGとの違いと使い分けで整理しています。

推論モデルでfew shotとChain of Thoughtを組み合わせるときの注意点

思考機構を備えたモデルでも、few shotは有効です。Anthropicの Prompting best practicesは、few-shotの例示の中に<thinking>タグで考え方の型を書いておくと、モデルがその型を自分の思考に一般化すると説明しています。同じ文書は、手書きの細かい手順より「よく考えて」といった一般的な指示のほうが良い推論を生むことが多い、とも述べています。

実装上は、例示に書くのは解き方の細部ではなく、確認する項目と順番に留めるのが無難です。途中式まで含めた例示の作り方と、推論モデルでCoT指示をどう扱うかはChain of Thoughtとは？CoTプロンプトの書き方・推論モデルでの扱いと限界で詳しく扱っています。例示の設計から評価データの整備、本番の業務フローへの組み込みまでを一体で進めたい場合は、生成AI導入支援で、どの処理にfew shotを載せるかの切り分けから相談を受け付けています。

よくある質問

few shotの導入検討で挙がりやすい論点を、実装判断に直結する5つに絞って回答します。

few shotとfew-shot learningは同じものですか？

文脈によって指すものが違います。LLMのプロンプトの話であれば、指示に例示を数件添える書き方を指し、モデルの重みは変わりません。画像認識などの機械学習の文脈では、少数のラベル付きデータから新しいクラスを識別できるようモデルを訓練する研究分野を指すことが多く、こちらは学習を伴います。社内の議論では、プロンプトの話なのか学習の話なのかを最初に確認すると混乱を防げます。

例示は何件入れるのがよいですか？

3〜5件から始めるのが扱いやすい出発点で、Anthropicの公式ガイドもこの件数を推奨しています。増やすのは、評価データで誤答が出て、その誤答に共通する型が見えたときだけにしてください。まとめて増やすと、どの例示が効いたのか切り分けられなくなります。件数を増やしても正答率が頭打ちなら、例示の選び方か並び順を疑うほうが先です。

例示のラベルが間違っていたらどうなりますか？

分類や多肢選択では、ラベルをランダムに入れ替えても性能がほとんど落ちなかったという研究があります（Min et al.・2022年）。効いているのは、ラベルの種類・入力の分布・書式のほうだからです。ただし、これは誤ったラベルを放置してよいという意味ではありません。境界事例の倒し方を示す例示でラベルを誤れば、その型の入力で誤答を招きます。

zero-shotとfew-shotはどちらから試すべきですか？

zero-shotから試してください。指示文だけで業務要件を満たせるなら、例示を足す理由がありません。zero-shotの正答率を測っておけば、few-shotを入れたときの改善幅を同じデータで比べられます。誤答の中身を見て、書式の揺れや境界事例の倒し方に集中しているとわかった段階で、few-shotへ進むのが無駄のない順番です。

例示を入れると費用はどれくらい増えますか？

例示のトークン数×処理件数×入力単価で見積もれます。2026年9月時点のClaude Sonnet 5（入力2ドル/100万トークン）で、例示400トークン・月10万件なら約80ドルが上乗せされます。固定の例示はプロンプトキャッシュで読み出し単価を0.1倍に下げられますが、キャッシュには最小トークン数の条件があり、入力ごとに例示が変わる動的few-shotの区画には効きません。