なぜ「パラメータ数」と「例示数」の関係を見落とすと失敗するのか
「プロンプトエンジニアリングといえば、まずはFew-shot学習（いくつかの例示を与える手法）だ」
もし、使用するAIモデルの規模に関わらず、とりあえず10個程度の例示をプロンプトに詰め込んでいるとしたら、それは非常にもったいないアプローチかもしれません。場合によっては、それが原因でモデルの精度を下げている可能性すらあります。
生成AI導入の現場で頻繁に見られる誤解の一つがこれです。多くのケースで、最新の超巨大モデルでの成功体験や、ウェブ上の一般的なベストプラクティスをそのまま、パラメータ数の少ない軽量モデル（7Bクラスなど）に適用しようとしています。
しかし、モデルのパラメータ数は、人間で言えば「短期記憶の容量」や「文脈理解の深さ」に直結する要素です。小学生に大学院レベルの大量の参考資料を一度に渡しても処理しきれないように、モデルの規模に合わない例示量はノイズとなり、混乱を招いてしまいます。
In-context Learningの黒魔術的性質
コンテキスト内学習（プロンプト内で学習させる手法）は、大規模言語モデル（LLM）の最も強力な機能の一つですが、その挙動はパラメータ規模によって劇的に変化します。
パラメータ数が多いモデルは、例示の中から「抽象的なルール」を見つけ出す能力に長けています。一方、パラメータ数が少ないモデルは、例示の「表面的なパターン」だけを模倣しようとする傾向があります。
最近の実証データや実務での知見では、思考プロセスを記述させる手法（Chain-of-Thought）と例示（Few-shot）を組み合わせるアプローチがスタンダードになりつつあります。しかし、この違いを理解せずに一律に「例示は多ければ多いほど良い」と考えてしまうと、以下の2つの痛手を受けることになります。
- 精度の低下: モデルが情報を処理しきれず、事実と異なる内容（ハルシネーション）を出力したり、指示を無視したりする。
- コストの増大: 不要な入力データ（トークン）が増えることで、API課金や自社GPUの計算リソースを浪費する。
本記事では、Llama、Mistral、Qwenといった主要なオープンソースLLMの最新モデルを念頭に、モデルサイズごとの「学習特性の癖」と、それに基づいた「最適な例示戦略」について論理的に解説します。
単にベンチマークのスコアを上げるための理論ではなく、実務でコストを抑えつつ安定した出力を得るための、実証に基づいたアプローチを持ち帰っていただければと思います。
1. 7Bクラス（小規模）：キャパシティオーバーと「Recency Bias」の壁
まずは、エッジデバイスやコスト重視のプロジェクトで採用されることが多い7B〜8Bクラス（Llamaモデル, Mistral 7Bなど）について見ていきましょう。
結論から言えば、このクラスのモデルに対して過剰な例示を与えることは、かえって逆効果になりがちです。
情報過多による混乱
7Bクラスのモデルは非常に優秀ですが、一度に処理できる情報の複雑さには限界があります。最近のモデルは一度に入力できる文章量（コンテキストウィンドウ）自体は長くなっていますが、「入力できること」と「正しく理解して活用できること」は別問題です。
7Bモデルに5個以上の複雑な例示を与えた際、以下のような現象が頻発するデータがあります。
- 指示の忘却: プロンプトの冒頭に書いた「システムへの基本指示」よりも、例示の中身を優先してしまう。
- フォーマット崩れ: 例示の中に含まれる微妙な揺らぎを過敏に拾ってしまい、指定したデータ形式（JSONなど）を守らなくなる。
これは、モデルの処理能力が例示の読み込みだけで手一杯になり、肝心の推論タスクに割くリソースが不足している状態と考えられます。
最適なのは0-shotか1-shotか
さらに顕著なのが「直近効果（Recency Bias）」です。7Bモデルは、プロンプトの最後の方にある情報に強く引きずられる傾向があります。
例えば、感情分析タスクで10個の例示を与え、その最後の例示が「ネガティブ」だった場合、入力文が何であれ「ネガティブ」と判定する確率が高まる現象が確認されています。パラメータ数が少ないモデルほど、長い文脈全体を俯瞰して判断するよりも、直近のパターンに反射的に反応してしまうのです。
【推奨戦略】
このクラスでは、例示なし（0-shot）または最も代表的な例を1つだけ（1-shot）にするアプローチが、精度と安定性のバランスにおいて有効です。
もし1つの例示でうまくいかない場合は、例示を増やすのではなく、「指示」をより具体化することに注力してみてください。モデルに推測させるのではなく、やるべきことを平易な言葉で明確に定義する方が、7Bモデルには効果的です。
2. 13B-30Bクラス（中規模）：3-5 shotが導く「安定性のスイートスポット」
次に、Mixtral 8x7B、Gemma 27B、Yi-34Bなどの中規模モデルです。企業内での自社運用において、性能とリソースのバランスが良いのがこのゾーンです。
ここでは、教科書通りの例示学習（Few-shot）が最も効果を発揮します。
パターン認識能力の開花
パラメータ数が100億を超えてくると、モデルは例示の中から「隠れた法則性」を抽出する能力が飛躍的に向上します。単語の並びだけでなく、タスクの意図や文体のニュアンスを、数個の例示から学習できるようになります。
このクラスにおいて、例示は単なるパターンのコピーではなく、「タスク定義の補完」として機能します。言葉で説明しきれない微妙なニュアンス（例：カスタマーサポートの丁寧さの度合いや、要約の粒度）を伝えるには、例示が非常に有効です。
フォーマット遵守のための必要最低限
特に効果的なのが、構造化データ（JSON, XML等）の生成タスクです。
7Bモデルでは不安定だったJSON出力も、13B以上のモデルに3〜5個の成功例を与えることで、構文エラー率を劇的に下げることができます。
- 1つの例示: まだ不安定。キー名を間違えることがある。
- 3つの例示: 安定し始める。例外的なケース（値が空の場合など）の対応も学習する。
- 5つの例示: ほぼ完璧にフォーマットを遵守する。
しかし、ここでも「多ければ良い」わけではありません。実証データに基づくと、5個を超えると精度向上は頭打ちになる傾向があります。10個入れても精度は変わらず、推論コストと待ち時間だけが増えていく可能性が高いのです。
【推奨戦略】
このクラスの最適な例示数は3〜5個です。特に、正解例だけでなく、やってはいけない失敗例を1つ混ぜることで、モデルの挙動をより強力かつ論理的に制御できます。
3. 70Bクラス（大規模）：早期に訪れる「精度の収穫逓減」
最後に、Llamaシリーズの70Bモデル、Qwen、Mistralの最新モデルなどの大規模モデルです。これらは最先端の商用モデルに匹敵する処理能力を持っていると考えられています。
ここで重要なのは、「賢いモデルほど、例示は少なくて済む」という実践的な事実です。
事前学習知識の優位性
70Bクラス以上のモデルは、事前学習の段階で膨大なテキストデータを読み込んでおり、一般的なタスク（翻訳、要約、コード生成、感情分析）については、すでに高いレベルの知識を持っています。
そのため、改めて例示で「翻訳とは何か」を教える必要はありません。必要なのは、「今は翻訳のタスクを実行するタイミングですよ」というスイッチを入れることです。
実際、多くの検証において、大規模モデルは例示なし（0-shot）ですでに非常に高いスコアを叩き出すことがあります。そこに例示を加えても、スコアの上昇幅はごくわずかです。これを経済学用語で「収穫逓減」と呼びます。
コンテキストウィンドウの無駄遣い
大規模モデル運用における最大の課題は、その推論コストです。70Bクラスのモデルを動かすには、高価なGPUが複数枚必要になります。
ここで無駄に10個、20個と例示を入れてプロンプトを長くすることは、計算リソースの浪費につながります。入力するデータ量が増えれば、それだけ処理時間は長くなり、従量課金であればコストも跳ね上がります。
【推奨戦略】
基本は例示なし（0-shot）でスタートしてください。特殊な専門知識や、非常に特殊なフォーマットが必要な場合のみ、1〜2個の例示を加えます。大規模モデルにとって、質の高い1個の例示は、10個の一般的な例示よりもはるかに効果的です。
インストラクションモデルにおける例示なしの効果
ここで、パラメータ数とは別の軸、すなわち「モデルの調整手法」についても触れておきましょう。
最近のオープンソースモデルは、人間のフィードバックを用いた学習などによって、「指示に従う能力」が大幅に高められています。
Chatモデルの特性変化
初期の言語モデルは、続きの文章を予測するだけの仕組みだったため、例示で誘導する必要がありました。しかし、現在の対話型モデルは、指示をこなす「エージェント」として設計されています。
これらのモデルに対しては、「例示を見せる」よりも「論理的に言葉で説明する」方が精度が高くなることが実証されています。
Few-shotが逆効果になるケース
特に注意が必要なのは、最新の対話型モデルに古いスタイルの例示プロンプト（例：入力と出力を延々と繰り返す形式）を与えると、モデルがそれを「チャットの履歴」と誤認したり、調整された対話スタイルと衝突して、出力品質が下がることがある点です。
「例示がないと不安」というのは、私たち人間の側の心理的な思い込みかもしれません。常に仮説を立て、実際の出力結果で検証することが重要です。
5. コストとレイテンシ：プロンプトトークン肥大化の「隠れた代償」
ここまでは「精度」の話をしてきましたが、ビジネス実装においては「コスト」と「速度」も同等に重要です。特に自社でGPUサーバーを構築して運用する場合、プロンプトの長さはシステム全体のパフォーマンスに直結します。
入力トークン増によるスループット低下
AIモデルの推論プロセスは、大きく「入力処理」と「出力生成」の2段階に分かれます。
例示を増やして入力する文章が長くなると、この入力処理にかかる計算量が飛躍的に増加します。これは、ユーザーがリクエストを送ってから最初の文字が表示されるまでの待ち時間の遅延に直結します。
「精度をわずかに上げるために例示を増やしたら、応答開始まで数秒待たされるようになった」のでは、実用的なシステムとは言えません。
KVキャッシュのメモリ圧迫
さらに技術的な仕組みを噛み砕いて説明すると、長い入力文章はGPUメモリ上の一時記憶領域（KVキャッシュ）を大量に消費します。
この領域がメモリを圧迫すると、一度に並列処理できるリクエスト数を減らさざるを得なくなります。つまり、システム全体の処理効率が低下するのです。
自社インフラでモデルを稼働させている場合、例示を10個から3個に減らすだけで、同じハードウェア構成でも同時接続数を倍にできる可能性があります。これは、効率的な解決策を追求する上で非常に重要な視点です。
まとめ：自社タスクの「マジックナンバー」を見つける3ステップ検証法
モデルの規模や特性によって、最適な例示数は変わります。「とりあえず10個」という固定観念から脱却し、以下の3ステップで自社タスクにおける最適解を見つけてみてください。
- ベースライン設定（例示なし）: まずは例示なし、詳細な指示のみでテストします。最近の高性能モデルならこれだけで十分なことも多いです。
- スケールアップ検証: モデルサイズに合わせて例示を追加し、仮説検証を行います。
- 7Bクラスなら +1個
- 13B-30Bクラスなら +3個
- 70Bクラス以上なら +1個
- 費用対効果の判断: 例示追加による「精度の向上分」と「遅延・コストの増加分」を天秤にかけます。精度が誤差レベルしか上がらないなら、例示を減らすことを検討します。
プロンプトエンジニアリングは、単に情報を足すだけでなく、実証データに基づいて無駄を削ぎ落とすアプローチが求められるフェーズに入っています。
コメント