Few-shot を捨てたら精度が上がった話

この記事でわかること:

• Few-shotが逆効果になる構造的理由
• Zero-shotで精度を出すための条件
• 2026年のモデル進化と例示戦略の変化

結論: Few-shotは「使う場面」を選ぶ時代

長年プロンプトエンジニアリングのベストプラクティスとされてきたFew-shot prompting（数個の例を示してから本タスクを依頼する手法）が、2026年のモデルでは必ずしも有効ではないことが分かってきました。実際、Few-shotを捨てた結果、精度が10%以上上がったケースも珍しくありません。

Few-shotの基本

Few-shotは入力と出力のペアを2〜5個示してから、本来やってほしいタスクを依頼するテクニックです。たとえば「英語→日本語翻訳」なら、3組の翻訳例を示してから本文を依頼します。

2023〜2024年頃のGPT-3.5などでは劇的に効きました。しかし2026年の最新モデル（Claude Opus 4系、GPT-5、Gemini 2.5系など）では事情が変わっています。

なぜFew-shotが逆効果になるのか

1. モデルの基礎能力向上

最新モデルはZero-shot（例示なし）でも十分高い精度を出せます。例示が「冗長な制約」として働き、柔軟性を奪うことがあります。

2. 例示への過度な追従

LLMは示された例の表面的なパターンを模倣します。例示と異なる入力が来た時、無理に例示のフォーマットに合わせようとして誤った出力をします。

3. コンテキストの圧迫

例示を増やすほどトークンを消費し、本来の指示や入力データに使えるトークンが減ります。コスト・レイテンシも悪化。

4. バイアスの混入

例示の選び方に偏りがあると、その偏りが全体に波及します。3例すべてポジティブな例を示すと、ネガティブな判定がしにくくなります。

実測データ

あるテキスト分類タスクで、Few-shot（5例）とZero-shotを比較しました。

• Few-shot（5例）: 正答率 72%、平均トークン 2,400
• Zero-shot: 正答率 83%、平均トークン 600

Zero-shotの方が精度・コスト・速度すべてで上回りました。同様の結果が他タスクでも観察され、「Few-shot不要」が一つの結論です。

Few-shotがなお有効な場面

とはいえFew-shotが完全に不要なわけではありません。以下の場面では今でも有効です。

1. 出力フォーマットが特殊

独自のJSON構造や、業務固有のフォーマットを守らせたい時、例示が最も確実です。

2. 専門用語のニュアンス

「カジュアルな敬語」のような微妙なトーンは、説明より例示の方が伝わります。

3. エッジケースの明示

「空文字の場合はnullを返す」のようなエッジケースは、例示で確実に伝わります。

Zero-shotで精度を出すコツ

1. タスクを明確に言語化

「感情分析をしてください」では不十分で、「テキストの感情を positive/negative/neutral の3つに分類し、信頼度0〜1で返してください」のように具体化します。

2. 出力スキーマを示す

例示ではなく、出力フォーマットをJSON Schemaやテンプレート文字列で示します。例示よりトークン効率が良いです。

3. 評価基準を明示

「正確性を最優先」「不明な場合はunknownを返す」など、判断基準を言語化します。

4. Chain of Thoughtを促す

「まず○○を分析してから判断してください」と段階的思考を指示します。これだけで精度が大きく改善することが多いです。

2026年の例示戦略

2026年の現場では、以下のような使い分けが定着しています。

1. デフォルトはZero-shot: まず例示なしで試す
2. 失敗したらOne-shot: 1個だけ追加
3. それでも失敗したらFew-shot: 必要最小限の例を追加
4. 例示は最大3個: それ以上はFine-tuningを検討

事例

あるカスタマーサポートAIで、Few-shot 8例を含む2800字のプロンプトを使っていましたが、Zero-shot＋Chain of Thoughtに切り替えた結果、900字に圧縮しつつ精度が81%から89%に向上。コストは1/3、レイテンシは半分になりました。

まとめ

Few-shotはかつての必須テクニックでしたが、2026年のモデルでは「使う場面を選ぶ」スキルが求められます。デフォルトはZero-shotで始め、失敗時にだけ最小限の例示を加える戦略が、コスト・精度・柔軟性のバランスを最適化します。手癖でFew-shotを使っているなら、一度捨ててみてください。