Few-shotプロンプティング
読み: フューショットプロンプティング
Few-shotとは少数例示で精度向上
Few-shotプロンプティングは、LLMに対して少数の入出力例を提示することで、追加学習なしに所望の出力形式や判断基準を伝える手法である。プロンプトエンジニアリングの中核テクニックの一つに位置づけられる。
かんたんに言うと
新しく入った部下に仕事を頼むとき、「こういう入力が来たらこう返して」と2〜3件のサンプルを見せて覚えさせるようなものである。マニュアル全体を読ませるのではなく、実例で伝える。
ゼロショットとの違いから理解するFew-shotの基本
LLMへの指示の出し方は、例示の数によって分類される。
ゼロショットは例を一切見せず、指示文だけでタスクを実行させる方法である。「以下のテキストの感情をポジティブかネガティブで分類せよ」とだけ書く。LLMの汎用的な能力に頼る形になるため、出力の形式が安定しないことがある。
Few-shotは2〜5件程度の具体例を指示文に含める。「入力：この映画は最高だった → 出力：ポジティブ」「入力：二度と行かない → 出力：ネガティブ」といった例を添えることで、LLMは出力の形式と判断基準を推測できる。
One-shotはFew-shotの最小形で、例が1件だけのケースを指す。例が多いほど精度は上がる傾向にあるが、トークン数も増えるため、コストとのバランスが求められる。
効果的な例示の設計
例を増やせば精度が上がるわけではない。例の「質」がモノを言う。
まず、例示はタスクの多様性をカバーする必要がある。感情分類であれば、明確にポジティブな例とネガティブな例だけでなく、判断が微妙なグレーゾーンの例も含めると精度が安定する。すべてポジティブの例だけを見せると、LLMがポジティブに偏った出力をするようになる。
例示の順番も影響する。LLMは最後に見た例に引きずられる傾向があるため、特定のカテゴリの例を末尾に固めないほうがよい。ランダムに並べるか、カテゴリを交互に配置するのが安全である。
出力形式を厳密に制御したい場合は、例示にJSON形式やCSV形式の出力を含める。LLMは例のフォーマットを忠実に模倣しようとする性質があるため、構造化データの抽出タスクで特に有効となる。
実務での活用パターン
Few-shotプロンプティングが効果を発揮する代表的な場面は4つある。
まず、分類タスク。問い合わせメールを「技術質問」「料金質問」「クレーム」「その他」に振り分けるとき、各カテゴリの典型例を2件ずつ見せるだけで実用的な精度に達する。
次に、データ抽出。請求書のPDFから金額、日付、宛先をJSON形式で抜き出す処理である。例示で入力と出力のペアを示しておけば、LLMはフォーマットを正確に守ろうとする。
さらに、文体の統一。社内のナレッジベースに投稿する記事の文体を揃えたいとき、理想的な記事の例を数件添えることで、LLMの出力トーンを制御できる。
最後に、コード生成。「この関数の入力と出力はこう」という例を見せることで、LLMが生成するコードの品質が上がる。
ファインチューニングとの境界
Few-shotプロンプティングは、モデルの重みを一切変更しない。プロンプトの中に例を詰め込むだけである。このため、導入コストはほぼゼロで、すぐに試せる。
一方、ファインチューニングはモデル自体を特定のタスクに特化させる。大量の訓練データと計算リソースが必要になるが、プロンプトに例を含める必要がなくなるため、推論時のトークンコストが下がる。
判断の分かれ目は処理量である。同じタスクを月に数百回実行する程度ならFew-shotで十分なことが多い。月に数万回を超える場合、毎回のプロンプトに例を含めるトークンコストが積み上がるため、ファインチューニングのほうが経済的になるケースがある。
とはいえ、まずFew-shotで精度を検証し、ビジネス要件を満たすか確認してからファインチューニングに進むのが堅実な進め方である。
陥りやすい失敗と対処法
最も多い失敗は、例示が偏っていることに気づかないまま運用を始めてしまうパターンである。英語のテキストだけで例を作り、日本語のテキストを処理させると精度が落ちる。例示と実際の入力データの分布が乖離していないか、定期的な検証が欠かせない。
もう一つの落とし穴は、例示の数を増やしすぎてコンテキストウィンドウを圧迫することである。LLMにはトークン数の上限があり、例示にトークンを使いすぎると、肝心の入力データを処理するスペースが足りなくなる。
対処法はシンプルで、例示の数は3〜5件に絞り、代わりに例の多様性と代表性を高めることに注力する。10件の似た例より、3件の多様な例のほうが効果は高い。
当社の見解
技術の選定で最も避けるべきは「流行っているから」という理由で導入することだ。当社は複数のAIツール・フレームワークを実際に検証した上で、自社の用途に合うものだけを採用している。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。実装指示した人間側が実装したことも忘れて、気が付けば動いていない機能があった、ということも起きる。さらに、MCPやフックやルールを増やしすぎてAIが情報過多で機能しなくなった経験もある。どんなにルールや機能を付け足しても機能しなければ意味がない。足し算より引き算。1週間の検証期間が、3か月の手戻りを防ぐ。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。