Few-shotプロンプティング：3〜5個の例を見せてフォーマットを取得する

チケットボットは billing、bug、other のいずれか一語で答えるべきです。ほとんどの返信はまさにそれです。ところが「Label: billing — the customer seems upset about a refund」という返信が届き、ラベルを読み取るコードが詰まります。

通常の解決策は、より長い指示ではありません。いくつかの例です。完成したチケットをラベル付きで3〜5個プロンプトに入れると、モデルはそのパターンをコピーします。これがfew-shotプロンプティングです。Anthropicのプロンプティングガイド（「Use examples effectively」セクション、2026年11月3日確認）は、例をフォーマット・トーン・構造を誘導する最も信頼できる方法の一つと呼び、3〜5個を推奨しています。注意点は、すべての例がリクエストごとに再び支払う入力になることです。以下のコストセクションでは、1日2,000件のチケットを処理するボットについて計算します。

「few-shot」とは#

サポートデスク初日の新しい同僚を想像してください。「各チケットにbilling、bug、otherのタグを付けて」と言って立ち去ります。タグのいくつかはあなたの考えと一致し、いくつかは一致しません。そこで、すでにタグ付けされたチケットを3枚残し、「こんな感じで」と言います。同じ同僚でも、驚きははるかに少なくなります。

モデルも同じように振る舞います。指示だけをzero-shotと呼びます。指示にいくつかの実例を加えたものがfew-shotです（Anthropicのページではmultishotとも呼んでいます）。「shot」は単なる例のことです。

Label the support ticket as billing, bug or other.

Label the support ticket with one word: billing, bug or other.

Ticket: I was charged twice for one top-up.
Label: billing

Ticket: The export button does nothing.
Label: bug

Ticket: Do you have a dark theme?
Label: other

2番目のプロンプトはbillingが何を意味するかを決して説明していません。例が示すことでそれを伝え、意味とともにフォーマットも運びます。明示的な指示の一行があっても害はないので、以下のバージョンではそれを残しています。

機能する例のための3つのルール#

Anthropicのページは、良い例を3つの言葉に要約しています。

• 関連性: 他のタスクではなく、実際に受け取るチケットに近いこと。
• 多様性: エッジケースをカバーし、互いに異なること。そうすればモデルが偶発的なパターンに固執しません。
• 構造化: タグ（<example>、および<examples>内に複数）で囲み、モデルが例と指示を区別できるようにすること。同じページはタグ名を一貫させるよう述べています。

そのようにして作られた完全なプロンプトを以下に示します。prompt.txtとして保存してください。

<instructions>
Label the support ticket with exactly one word: billing, bug or other.
Reply with the label only.
</instructions>

<examples>
<example>
<ticket>I was charged twice for the same top-up.</ticket>
<label>billing</label>
</example>
<example>
<ticket>The export button does nothing when I click it.</ticket>
<label>bug</label>
</example>
<example>
<ticket>Do you have a dark theme?</ticket>
<label>other</label>
</example>
<example>
<ticket>Please refund me. Also, the page crashes on login.</ticket>
<label>billing</label>
</example>
<example>
<ticket>Is there an API for exporting reports?</ticket>
<label>other</label>
</example>
</examples>

4番目の例を見てください。クラッシュにも言及した返金リクエストです。指示では混在したチケットを解決できませんが、例ならできます。ここではお金が優先されるので、ラベルはbillingです。どのルールを選ぶにせよ、一度は示してください。

API経由で送信する#

プロンプトはどのリクエストでも同じテキストで、変わるのは新しいチケットだけです。各チケットは同じ短い旅をします。

openaiパッケージを使ったPythonの例です。アドレスはCheapTokens API、キーは環境変数に置き（キーを安全に保存する方法を参照）、モデルIDはドキュメントにある完全なものです。

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.cheaptokens.dev/v1",
    api_key=os.environ["CHEAPTOKENS_API_KEY"],
)

PROMPT = open("prompt.txt", encoding="utf-8").read()


def label(ticket: str) -> str:
    response = client.chat.completions.create(
        model="deepseek-ai/DeepSeek-V4-Flash-0731",
        max_tokens=64,
        messages=[
            {"role": "system", "content": PROMPT},
            {"role": "user", "content": f"<ticket>{ticket}</ticket>"},
        ],
    )
    print(response.usage.prompt_tokens, response.usage.completion_tokens)
    return response.choices[0].message.content.strip()


print(label("The app shows a blank screen after the update."))

うまくいけば、1行に2つのトークン数が表示され、その後にラベル自体、bugのような一語が続きます。代わりに文が返ってきたら、例がまだ役割を果たしていません。タグを確認し、スキームのすべてのラベルが少なくとも1回は現れていることを確認してください。

最初の数字が注目すべきものです。それはプロンプト全体、つまり指示＋例＋チケットであり、例を追加するたびに増えます。スクリプトを完全なprompt.txtで一度、<instructions>部分だけで一度実行してください。2つの最初の数字の差が、例がリクエストごとに費やすコストです。

DeepSeek-V4-Flashはこの種の大量ラベリングに適しています。時間帯を問わず1つの価格、380Kトークンのコンテキスト（長い例のブロックも簡単に収まる）、回答あたり最大32,768トークンです。GLM-5.3-Flashは390Kコンテキストで、短いラベリングタスクにも使えます。どちらもモデルページにあり、1つの残高で利用できます。

5つの例が請求に加えるもの#

ボットが1日2,000件のチケットを処理するとします。チケットは約120トークン、指示は約80トークンと仮定すると、例なしのリクエストは80 + 120 = 200入力トークンです。5つの例がそれぞれ約60トークンなら5 × 60 = 300を加え、例ありのリクエストは200 + 300 = 500になります。回答は一語で、どちらも3出力トークンとします。これらは仮定です。スクリプトが出力したprompt_tokensに置き換えてください。

1日で、200 × 2,000 = 400,000入力トークンが500 × 2,000 = 1,000,000になり、出力は3 × 2,000 = 6,000トークンのままです。DeepSeek-V4-Flashでは、例なしで1日$0.0066、例ありで$0.0156です。例のコストはこれら2つの数字の差であり、Anthropicによればより一貫した出力が得られます。

この図は有用な詳細を隠しています。例のブロックはどのリクエストでも同一で、まさにプロンプトキャッシングが扱う繰り返しの開始部分です。プロンプトキャッシングとはでその仕組みを説明しています。

同じ負荷、リクエストあたり500入力トークンと3出力トークン、2,000リクエストをモデル間で比較します。表は現在の価格から再計算されます。

入力と出力を合計すると、この負荷ではDeepSeek-V4-FlashとGLM-5.3-FlashがOpenRouterより安くなります。完全な価格表は価格ページにあります。

JSON、トーン、例の確認#

同じトリックは、遭遇する他の2つのケースもカバーします。毎回同じJSONフィールドが必要ですか？例の回答をJSON自体にしてください。

<example>
<ticket>I was charged twice for the same top-up.</ticket>
<output>{"label": "billing", "urgent": true}</output>
</example>

response_formatと、返信がまだ有効でない場合の対処については、LLM APIから有効なJSONを取得するを参照してください。テキストを1つのトーンで書き直したいですか？「friendly but brief」のような形容詞は曖昧です。2つのビフォーアフターのペアの方がよく示します。

どの例のセットも信頼する前に、手作業でラベル付けした20件のチケットを実行して比較してください。1回の実行はどんなルールよりも多くを教えてくれます。Anthropicのページは近道を追加しています。モデルに例の関連性と多様性を評価させるか、手持ちの例からさらに書かせてください。

例が機能したら、次の問題は複数のドキュメントが1つのプロンプトで混ざらないようにする方法です。プロンプト内のすべてのドキュメントにラベルを付けるでそれを扱っています。