ブログ一覧へ戻る
判断プロセスを示すフローチャート:まずZero-shotを試し、結果を評価し、必要な場合のみ例を追加する 
プロンプトに例カードが追加されていく様子のイラスト。最初の数個以降は効果が逓減することを表現
Few-shotとZero-shotプロンプティング:使い分けの実践ガイド
タスクに合った手法を選ぶための実践的なガイド。コピペで使えるサンプルとシンプルな判断フレームワーク付き。
ChatGPTにプロンプトを貼り付ける。出力は……まあ悪くない。でも、プロンプトに「例」を加えるだけで圧倒的に良い結果を出している人を見たことはないだろうか。自分もそうすべきなのか?例はいくつ必要なのか?そもそも、自分のタスクで違いが出るのか?
こうした疑問は絶えず出てくるが、用語自体がわかりにくい。「Zero-shot」「Few-shot」「One-shot」——どれも写真用語のようで、実用的な指針には聞こえない。本記事ではその専門用語を整理し、どちらを使うべきかを判断するための明確なフレームワークと、実際に試せる完全なプロンプト例を紹介する。
Zero-shotプロンプティングとは何か
Zero-shotプロンプティングとは、AIに何の例も示さずにタスクを与える方法だ。やりたいことを説明するだけで、モデルが学習した知識をもとに自力で対応する。
会議メモを要約するZero-shotプロンプトの例:
以下の会議メモを、決定事項を中心に3〜5個の箇条書きで要約してください。
会議メモ:
{{meeting_notes}}
これだけだ。「良い要約」のサンプルも、入力と出力のペアもない。要約とは何か、「主な決定事項」が何を指すのかをモデルが理解していると信頼している。多くのタスクでは、これが意外なほどうまく機能する。
Few-shotプロンプティングとは何か
Few-shotプロンプティングとは、AIに従ってほしいパターンを示す2〜5個の例をプロンプトに含める方法だ。実際のタスクを与える前に「こうやって処理してほしい」と伝えているようなものだ。
同じ会議要約タスクを、例付きで書くとこうなる:
会議メモを、決定事項を中心に3〜5個の箇条書きで要約してください。
例1:
入力: 「チームでQ3の目標を議論。Sarahが営業目標を15%引き上げる案を提示。Markは現在のパイプラインを考えると10%が現実的だと反対。投票の結果、12%で合意。WebサイトリニューアルはQ4に延期することも決定。」
出力:
- Q3の営業目標を12%引き上げで合意(15%案と10%案の折衷)
- Webサイトリニューアルを Q4に延期
例2:
入力: 「予算レビュー会議。現在の支出は予測を8%超過。CFOが出張予算を50%削減し、新規採用を60日間凍結することを提案。CEOが両措置を即時承認。」
出力:
- 出張予算を50%削減(即時適用)
- 60日間の採用凍結を承認
- 8%の予算超過への対応
それでは次を要約してください:
{{meeting_notes}}
違いに注目してほしい。例を見せることで、求めるフォーマット(括弧内に補足を入れた箇条書き)、含めるべき詳細さ、複数の決定事項の扱い方を、モデルが正確に把握できる。ファインチューニングなしで、文脈の中(in context)で好みを学習させているわけだ。
両者の違いをひと目で比較
重要な観点で2つの手法を比較するとこうなる:
- 速度: Zero-shotの方が速い。処理するトークンが少ないので応答も速い。
- コスト: Zero-shotの方が安い。トークン単位の課金で、例を増やすと積み上がる。
- 準備の手間: Zero-shotはほぼ不要。Few-shotは良い例を探すか作る手間がかかる。
- シンプルなタスクの精度: ほぼ同等。最近のモデルはどちらでも素直なリクエストには十分対応できる。
- 複雑/カスタムなタスクの精度: Few-shotの方が有利なことが多い。特定のフォーマットや業界用語が必要な場合、例があると目に見えて差が出る。
トレードオフは明確だ。Zero-shotはシンプルで安い、Few-shotは出力をより細かくコントロールできる。問題は、その追加のコントロールが手間に見合うかどうかだ。
Zero-shotが向いている場面
Zero-shotプロンプティングは、モデルが学習データから既に「理解している」タスクで真価を発揮する。たとえば次のようなものだ:
一般知識の質問: 説明、定義、事実情報の要求。モデルは「良い説明」がどんなものかを知っている。
創造的なブレインストーミング: アイデア出し、ドラフト執筆、選択肢の提示。ここではむしろ多様性が欲しいので、特定のパターンへの忠実さは不要。
標準的な要約: 特定のフォーマットが要らない、記事・メール・文書の凝縮。
翻訳: モデルが学習した言語間でのテキスト変換。
シンプルな分類: カテゴリが自明な場合の仕分け(ポジティブ/ネガティブ、緊急/非緊急など)。
創造的なブレインストーミング: アイデア出し、ドラフト執筆、選択肢の提示。ここではむしろ多様性が欲しいので、特定のパターンへの忠実さは不要。
標準的な要約: 特定のフォーマットが要らない、記事・メール・文書の凝縮。
翻訳: モデルが学習した言語間でのテキスト変換。
シンプルな分類: カテゴリが自明な場合の仕分け(ポジティブ/ネガティブ、緊急/非緊急など)。
目安はこうだ:平易な言葉で要件を説明できて、人間が例なしでも理解できる内容なら、Zero-shotで十分通用する可能性が高い。
Few-shotが追加トークンに見合う場面
Few-shotプロンプティングが本領を発揮するのは、指示だけではモデルが推測しきれないパターンに沿った出力が必要な場面だ:
カスタムフォーマット: 特定のフィールドを持つJSON、決まった列の表、特定スタイルの箇条書きなど、構造が決まっている出力が必要なとき。例で見せた方が、文章で説明するよりフォーマットを正確に伝えられる。
独自の分類カテゴリ: 顧客メールを「請求関連」「機能要望」「不具合報告」「一般問い合わせ」のような独自カテゴリに振り分けたい場合、各カテゴリの例を見せると定義が伝わりやすい。
ブランドボイスやトーンの再現: 自社の既存コンテンツのような文章を書かせたいなら、そのボイスの例を2〜3個見せる。「プロフェッショナルだがフレンドリーな調子で」のような指示は曖昧だが、例なら具体的だ。
業界特有の用語: 業界によって意味が変わる専門用語や略語があるなら、例を通じてモデルに文脈を教えられる。
エッジケースとニュアンス: 皮肉の検出、アイロニー、Zero-shotがつまずきがちな微妙な区別。研究によると、Few-shotプロンプティングは否定や皮肉のような感情分析のエッジケースの処理を大きく改善することが分かっている。
独自の分類カテゴリ: 顧客メールを「請求関連」「機能要望」「不具合報告」「一般問い合わせ」のような独自カテゴリに振り分けたい場合、各カテゴリの例を見せると定義が伝わりやすい。
ブランドボイスやトーンの再現: 自社の既存コンテンツのような文章を書かせたいなら、そのボイスの例を2〜3個見せる。「プロフェッショナルだがフレンドリーな調子で」のような指示は曖昧だが、例なら具体的だ。
業界特有の用語: 業界によって意味が変わる専門用語や略語があるなら、例を通じてモデルに文脈を教えられる。
エッジケースとニュアンス: 皮肉の検出、アイロニー、Zero-shotがつまずきがちな微妙な区別。研究によると、Few-shotプロンプティングは否定や皮肉のような感情分析のエッジケースの処理を大きく改善することが分かっている。
ある研究では、Twitterの感情分類において、わずか20〜50個の例によるFew-shotプロンプティングが、1万件以上のデータでファインチューニングしたモデルに匹敵する性能に達したという。これが、適切に選ばれたデモンストレーションの威力だ。
もしタスクごとにFew-shotプロンプトのライブラリを作っているなら、PromptNestのようなツールを使えば、
{{meeting_notes}}のような変数付きで保存しておける。コピー時に空欄を埋めれば、完成したプロンプトをそのまま貼り付けられる。「まずはZero-shot、必要なら格上げ」ワークフロー
時間とトークンの両方を節約できる、実践的なアプローチを紹介する:
ステップ1:まずZero-shotを試す。 求めるものを明確に説明したプロンプトを書く。タスクは具体的に、ただし例はまだ含めない。
ステップ2:出力を評価する。 必要なものが得られているか?Yesなら完了。Noならどこが間違っているかを特定する——フォーマットか?トーンか?足りない情報か?それともタスクそのものを誤解しているのか?
ステップ3:狙いを定めた例を追加する。 モデルが間違えた点を具体的に示す例を2〜3個作る。フォーマットがズレていたなら正しいフォーマットを、トーンが違っていたなら正しいトーンを見せる。
ステップ2:出力を評価する。 必要なものが得られているか?Yesなら完了。Noならどこが間違っているかを特定する——フォーマットか?トーンか?足りない情報か?それともタスクそのものを誤解しているのか?
ステップ3:狙いを定めた例を追加する。 モデルが間違えた点を具体的に示す例を2〜3個作る。フォーマットがズレていたなら正しいフォーマットを、トーンが違っていたなら正しいトーンを見せる。
このワークフローが効く理由は、例が必要かどうかを当てずっぽうで決めずに、実際のギャップに対処しているからだ。Zero-shotプロンプトに「ステップごとに考えてみよう」と一言加えるだけで、例なしに推論の問題が解決することもある。研究でも、推論タスクではZero-shotのChain-of-ThoughtがFew-shotを上回ることが多いと確認されている。
実際に必要な例の数は?
研究は一貫して、ほとんどのタスクでは2〜5個がスイートスポットだと示している。データから見えてくるのは次のような傾向だ:
- 最初の2〜3個で精度が最も大きく伸びる
- 4〜5個を超えると効果は急激に逓減する
- 例が多すぎると、矛盾するパターンを持ち込んでかえって性能を下げることがある
- 量より質——優れた3つの例は、平凡な10個の例より効果が高い
もう一つ重要な発見が、例の順序だ。研究によれば、例の並び順が結果に影響し、最適な順序が良い結果と悪い結果の分かれ目になることもある。Few-shotプロンプトがうまく機能しないときは、例を増やす前に並び順を変えてみよう。
ほとんどのケースでは、例を2個から始めるのが良い。精度が足りないなら、別パターンをカバーする3個目を追加する。4個より多く必要になることはまずない。
Chain-of-Thought:推論タスクの中間的な選択肢
数学、論理、複数ステップの問題で特に有効な、3つ目の選択肢がある——Chain-of-Thoughtプロンプティングだ。入出力の例を見せる代わりに、モデルに「ステップごとに考えて」と指示する。
Zero-shotのChain-of-Thoughtはこんな感じだ:
ある店にりんごが45個あります。午前中に12個売れ、その後30個の追加入荷がありました。午後にさらに18個売れました。閉店時にりんごは何個残っているでしょうか?
ステップごとに順番に考えてみよう。
「ステップごとに順番に考えてみよう」というシンプルなフレーズが、モデルにすぐ答えを出させずに思考プロセスを示させるトリガーになる。複雑な推論では、これがZero-shotとFew-shotの両方を上回ることが多い。
arXivの最近の研究によると、GPT-4やClaudeのような高性能モデルでは、推論タスクにおいてZero-shotのChain-of-ThoughtがFew-shotプロンプティングをしばしば上回る。例があるとむしろモデルの思考を縛ってしまい、助けるどころか足を引っ張ることがあるのだ。
Chain-of-Thoughtを使うべきなのは:
- タスクが複数の論理ステップを必要とするとき
- モデルに推論過程を説明させたいとき(誤りの発見に役立つ)
- 数学、コーディングロジック、分析的な問題が絡むとき
- 答えだけでなく、モデルのアプローチを検証したいとき
そのままコピーできる完全なプロンプト例
実際のタスクで3つのアプローチを並べて見てみよう。すべてのプロンプトはGPT-4とClaudeで動作確認済みで、すぐに使える。
タスク1:メールのトーン分類
Zero-shot版:
次のカスタマーメールのトーンを分類してください:不満、満足、ニュートラル、緊急のいずれか。
メール:
{{email_text}}
トーン:
Few-shot版(エッジケースに強い):
カスタマーメールのトーンを分類してください:不満、満足、ニュートラル、緊急のいずれか。
メール: 「注文してから3週間も待っています。ありえません。今すぐ返金してください。」
トーン: 不満
メール: 「お礼を言いたくて。商品が予定より早く届いて、とても気に入っています!」
トーン: 満足
メール: 「こんにちは。注文が発送されたか確認できますか?注文番号#12345です。」
トーン: ニュートラル
メール: 「システムが停止していて、本日中に交換部品が必要です。さもないと契約を失います。」
トーン: 緊急
メール: {{email_text}}
トーン:
Few-shot版は、こちらの定義をモデルに正確に伝える助けになる。「緊急」と「不満」は曖昧になりがちだが、例があると境界が明確になる。
タスク2:商品説明のリライト
Zero-shot版:
この商品説明を、より魅力的で、ベネフィットに焦点を当てた文章にリライトしてください。100語以内に収めてください。
元の文: {{product_description}}
リライト後:
Few-shot版(ブランドボイスの一貫性に強い):
商品説明を、魅力的でベネフィット中心の文章にリライトしてください。次のスタイルに合わせてください:
元の文: 「ステンレススチール製ウォーターボトル。容量24オンス。24時間冷たさをキープ。」
リライト後: 「スリムな24オンスのスチールボトルで、一日中しっかり水分補給。朝のコーヒーは通勤中もアツアツのまま。午後の水分補給はジムでも氷のように冷たく。1本で、可能性は無限大。」
元の文: 「ワイヤレスイヤホン。8時間バッテリー。ノイズキャンセリング機能。」
リライト後: 「お気に入りのポッドキャストを8時間、途切れずに。ノイズキャンセリング搭載のワイヤレスイヤホンが雑音を遮断するから、深い集中、ワークアウトのプレイリスト、ずっと聴き終えていなかったオーディオブックに、思いっきり没頭できる。」
元の文: {{product_description}}
リライト後:
Few-shot版は、ベネフィット重視・会話調・具体的な利用シーンといった特定のコピーライティングスタイルを教え込む。Zero-shotでもなんらかのリライトは返ってくるが、必ずしもあなたのボイスにはならない。
タスク3:バグレポートの構造化
Zero-shot版:
このバグレポートを、概要、再現手順、期待される動作、実際の動作という構造化フォーマットに変換してください。
バグレポート: {{bug_report}}
Few-shot版(フォーマットの一貫性に強い):
バグレポートを構造化フォーマットに変換してください。
入力: 「PDFをアップロードしようとするとアプリがクラッシュします。ダッシュボードを開いてアップロードをクリックし、5MBのPDFを選択したらアプリがそのまま落ちました。本来ならアップロード一覧にファイルが表示されるはずですが、代わりにアプリ全体が落ちます。」
出力:
**概要:** PDFファイルのアップロード時にアプリがクラッシュする
**再現手順:**
1. ダッシュボードに移動
2. アップロードボタンをクリック
3. PDFファイルを選択(5MBファイルで確認)
**期待される動作:** ファイルがアップロード一覧に表示される
**実際の動作:** アプリが予期せずクラッシュ/終了する
---
入力: {{bug_report}}
出力:
技術ドキュメントでは一貫性が重要だ。Few-shot版なら、すべてのバグレポートが同じ構造、同じ詳細レベルで揃う。
簡単な判断フレームワーク
新しいタスクを前にしたとき、次の質問を順に確認しよう:
1. タスクは単純で定義が明確か? → Zero-shotから始める
2. モデルが推測できなさそうな特定フォーマットが必要か? → Few-shotを使う
3. 複数ステップの推論が必要か? → まずZero-shot Chain-of-Thoughtを試す
4. 一貫したブランドボイスや業界用語が必要か? → そのボイスの例を使ったFew-shotを採用する
5. Zero-shotで必要なものの80%は得られたか? → そのまま使う。残りの完璧さは、3倍のトークンに見合わない。
目的は最も凝った手法を使うことではなく、効率的に良い結果を出すことだ。Zero-shotがデフォルト。シンプルなアプローチでは足りないときだけ、複雑さを足していこう。
実践に落とし込む
これを身につける最善の方法は、実際に試すことだ。日常的にやっているタスク——レポートの要約、メールのドラフト、フィードバックの分類など——を選び、両方のアプローチで試してみよう。Zero-shotで物足りない場面と、Few-shotで本当に違いが出る場面を体感できる。
うまくいくプロンプトを見つけたら、後から確実に取り出せる場所に保存しておこう。例と変数を含むプロンプトのコレクションを作るなら、PromptNestはネイティブのMacアプリ(Mac App Storeで$19.99の買い切り、サブスクなし、アカウント不要、ローカルで動作)で、整理・検索・どのアプリからでもキーボードショートカットで呼び出せる。3週間前に書いたあの完璧なFew-shotプロンプトを、散らかったメモから探し回る必要はもうない。
シンプルに始める。必要に応じて複雑さを足す。うまくいったものを保存する。戦略はそれだけだ。