説明だけでは解釈の余地が大きすぎる場合、求める出力の例をモデルに見せてください。代表的な入出力の組み合わせを少数示すことで、トーン、形式、分類の境界を、形容詞だけより具体的にできます。
この手法はFew-shotプロンプティングと呼ばれます。名前は機械学習研究に由来します。最初のGPT-3論文では、タスク固有のパラメータ更新を行わず、コンテキスト内にタスクと例を与えたときのモデル性能を研究しました（Brownほか、2020）。この論文ではFew-shotで苦戦するタスクも見つかっています。そのため、例は評価すべき手法であり、必ず改善する方法ではありません。
この記事では、Few-shotプロンプティングとは何か、いつ使うか、どのようにテストするかを実例とともに説明します。
説明より例が効果的な理由
思考実験をしてみましょう。会社のマーケティングコピーに合う語り口を誰かに再現してもらうとします。「親しみやすいがプロフェッショナル、温かみがあるがくだけすぎない、自信があるが決して傲慢ではない、平易な言葉だが幼稚ではない」と説明できます。この4つを聞いた相手は納得しても、実際に求めているものとは違う文章を作るかもしれません。
一方、その語り口をすでに表現できている短い段落を3つ見せれば、目標はより具体的になります。形容詞だけを解釈する代わりに、単語の選び方、文の長さ、構成を比較できます。
モデルも、このように例を使えます。「親しみやすい」「プロフェッショナル」「自信がある」といった形容詞には、妥当な解釈が複数あります。具体例は、指示で明記されていない選択を示します。OpenAIのプロンプトエンジニアリングガイドは、Few-shot学習を少数の入出力例でモデルを導く方法と説明し、多様な入力候補とそれぞれの望ましい出力を示すよう勧めています。結果が改善するかどうかは、モデル、タスク、例、評価基準によって異なります。
Few-shotを使う場面
次のような場面では、例を試す価値があります。
特定のトーンに合わせる。 「当社の語り口で書いてください」。短い説明だけでは解釈の余地が残る場合、採用済みの代表例も示します。
一貫した形式で生成する。 商品説明、エラーメッセージ、APIレスポンス、週次報告、状況報告など、毎回同じ見た目にする必要がある出力です。形式を説明するだけでなく、見せてください。
ニッチまたは珍しい出力。 「[a specific person you follow]と同じ書き方でXのスレッドを書いてください」「社内ツールのブログ向けに見出しを作ってください」「チームと同じ書き方でコードコメントを書いてください」。こうした出力には、言葉で表しにくい固有の慣例があります。
翻訳、要約、書き直しでスタイルを再現する。 「これから見せる3つの例と同じスタイルで書き直してください」。
毎回同じように修正しているもの。 モデルの出力を毎回同じ方向に編集しているなら、たとえば短くしたり、単語を置き換えたり、構成を引き締めたりしているなら、修正後の例を与えてください。
基本構造
実用的なFew-shotプロンプトには、短い指示、代表的な例の組み合わせ、新しいタスクという3つの部分があります。
B2B SaaSツールの商品説明を1行で作成してください。次の例のスタイルに合わせてください。
例1： 製品：ProjectHub 説明：1つの仕事をするために5つのツールを行き来することに疲れたプロジェクトチーム向けの共有ワークスペース。
例2： 製品：TimeFlow 説明：時間管理アプリが嫌いな人のための時間管理アプリ。
例3： 製品：ClearStack 説明：スプレッドシートを意思決定に変えるレポート作成ツール。
次の製品について作成してください。 製品：PromptDesk 説明：
求めるパターンは、短く、明確な意見があり、少し遊び心を持ち、特定の不満や対象者を軸とするものです。この基準に照らして結果を確認してください。例はパターンを導けますが、良い説明を保証するものではありません。
3つの実例
例によって目標を明確にできる3つの状況を見ていきましょう。
1. チームのスタイルに合ったバグ報告の記述
チームがJiraチケットを、簡潔で、ユーザーへの影響に焦点を当て、専門用語を使わないという固有の方法で書いているとします。AIに、そのスタイルに合うチケットの下書きを作らせたい場合です。
以下の形式に従って、Jiraチケットの説明を作成してください。
例1： Google経由でログインするユーザーには、UIが更新される前に誤った言語が一瞬表示されます。Chromeデスクトップ版で毎回発生します。操作を妨げるものではありませんが、ぎこちなく見えます。
手順：
- サインアウトする
- Googleで再度サインインする
- 最初にページがちらつくことを確認する
期待される結果：言語が一貫している 実際の結果：（標準設定と思われる）英語が一瞬表示される
例2： 1,000行を超える週次レポートで「CSVにエクスポート」ボタンを使うと、空のファイルが返されます。それより小さいレポートは正しくエクスポートされます。
手順：
- 1,000行以上ある週次レポートを開く
- エクスポート → CSVをクリックする
- ダウンロードしたファイルを開く
期待される結果：すべてのデータが入っている 実際の結果：ファイルが0バイト
次の問題について作成してください。 問題：Safariのユーザーから、リンクをタップした後にモバイルメニューが閉じないという報告があります。再読み込みすると直ります。フォーカストラップの問題と思われます。
下書きが求めた構成、トーン、事実への忠実さを満たすか確認してください。例によって目標は明確になりますが、モデルが項目を省いたり、与えられていない詳細を推測したりする可能性は残ります。
2. ブランドの語り口に合わせた書き直し
メールの下書きがあり、ブランドの語り口に合わせて書き直したいとします。「もっと温かみを出して」だけでは解釈の余地があります。例を使えば、意図する表現域をより具体的にできます。
以下のメールを、次の例の語り口に合わせて書き直してください。語り口は、率直で、企業的な空疎な表現を使わず、少し自覚的で、「synergy」や「leverage」とは決して言わないものです。
例1：「リリースを1週間延期しました。オートスケーリングの変更は、想定より大規模でした。新しいリリース日は22日金曜日です。」
例2：「ちょっとお願いがあります。この下書きに大きな問題がないか確認してもらえますか？特に2つ目のセクションです。言いすぎている気がしますが、判断がつきません。」
例3：「先にお知らせします。明日の会議で期限に異議を唱えるつもりです。計算が合いません。間に合わなくなってから伝えるより、今のうちに指摘したいと思います。」
同じ語り口で次の文章を書き直してください。
[paste your draft]
使用前に、書き直した文章を例と元の事実に照らして確認してください。利用中のChatGPTプランとワークスペースでGPTを作成できる場合、例をカスタムGPTの指示に入れられます。OpenAIは、指示だけでは実行ごとに同一の出力が保証されないため、設定したGPTをPreviewでテストするよう勧めています。
3. 構造化された抽出
承認済みのPDF請求書があり、利用可能なモデルでデータを整った形式に抽出したいとします。ツールとデータ経路が文書の処理を許可されていることを確認した後、1件をアップロードし、求める出力例を示してから、残りの処理を依頼します。
請求書PDFから、次のJSON形式どおりにデータを抽出してください。
例：
入力：[invoice PDF where vendor is “Lufthansa”, date is 2026-04-12, total is 423.50 EUR, line items are flight + bag fee]
出力：
{ "vendor": "Lufthansa", "date": "2026-04-12", "currency": "EUR", "total": 423.50, "line_items": [ {"description": "Flight TLL-LHR", "amount": 387.00}, {"description": "Checked bag", "amount": 36.50} ], "category": "Travel" }次の請求書から抽出してください：[attach new PDF]
この例は対象のスキーマを指定しますが、スキーマ検証と請求書との照合は引き続き必要です。もっともらしいJSONオブジェクトを、金額、日付、明細項目が正しく抽出された証拠と見なさないでください。
Few-shotでよくある間違い
注意すべき間違いは3つあります。
互いに矛盾する例。 例ごとにスタイルが異なる場合や、似た入力に異なるラベルを付けている場合、モデルはその曖昧さを再現する可能性があります。意味のある入力の違いを網羅しつつ、意図した規則は一貫させてください。
意味のある違いを網羅していない例。 あらゆるタスクに最適な個数はありません。パターンと重要な境界事例を示す最小限の組み合わせから始め、代表的なテスト結果に基づいて例を追加または削除してください。例は一つずつコンテキストを消費し、モデルが調整すべき別のパターンを持ち込む可能性があります。
コピーされたくない誤りを含む例。 モデルは、例に含まれる誤字、不自然な表現、意図しない構造を再現する可能性があります。使用前に例を整え、意図したパターンだけが移ったと決めつけず、新しい出力を確認してください。
特に見落としやすい間違いは、出力例を示さず、入力例だけを見せることです。「見出しを付けてほしい記事を3つ示します：[three articles]」。これはFew-shotではなく、Zero-shotです。モデルは良い見出しがどのようなものか見ていません。比較してみましょう。
希望する見出しと同じ種類の見出しが付いた記事を3つ示します。このスタイルに合わせてください。
例1：[article] → 見出し：「……」 例2：[article] → 見出し：「……」 例3：[article] → 見出し：「……」
次の記事の見出しを書いてください：[new article]
Few-shotの単位は、（入力 → 出力）の組み合わせです。出力側がなければ、モデルには従うべきパターンがありません。
例のライブラリを作る方法
Few-shotを使い始めると、「うまくいった例」の組み合わせが蓄積していきます。残しておきましょう。保存先には次のようなものがあります。
- Custom GPTs / Claude Projects：テスト済みの例を、確認、更新できる範囲の明確な指示に保存します。
- テキストスニペット管理ツール（TextExpander、Raycast、Espanso）：ショートカットから例を展開できるようにします。
- 用途別に整理したメモファイル（「ブランドの語り口の例」「チケット形式の例」「見出しの例」）：必要なときにすばやく貼り付けられます。
時間をかければ、チームが実際に採用した出力を基にする、タスク固有のライブラリになります。自分の仕事で試していない一般的なプロンプト集より実用的です。
形容詞より例
出力を正確に説明できるなら、説明してください。見れば分かっても完全には言葉にできないスタイルなら、代表的な入出力例を加えます。再利用可能なワークフローにする前に、通常のケースと境界事例でプロンプトをテストしてください。
例を使えば、形容詞で曖昧なまま残る部分を明確にできます。次にスタイルや形式が重要なプロンプトを使うとき、この手法を試し、テストした出力が改善した場合だけ使い続けてください。
