小さなAIモデルで十分なとき

2026年にAI機能を作るときの定番は、使える中で最大のモデルを呼び出して先に進むことです。それで動き、すぐに出荷でき、本当に自由度の高いアシスタントならそれが正しい選択です。しかし、はるかによくあるケース、つまり流入したリードを読んだり請求書から6つの項目を抜き出したりする処理を1日に数千回行うシステムでは、タスクが一度も使わない能力に、知らないうちに払いすぎています。

エージェントの仕事は繰り返しで、繰り返しの仕事は狭い

本番環境のエージェントが幅広い会話をすることはまれです。分類し、抽出し、振り分け、構造化された引数でツールを呼び出し、あるいは少数の次の手から選びます。同じ形のプロンプトが、中身だけ変えて何度も何度も実行されます。

NVIDIAのチームは、この主張をSmall Language Models are the Future of Agentic AIで正式に示しました。初版は2025年6月、同年9月に改訂されています。彼らの実務上の「小型」の定義は、一般的な消費者向け端末に載り、役に立つだけの速さで応答するモデルで、2025年時点ではおおむね100億パラメータ未満のものを指します。

具体的なのは経済面の主張です。70億パラメータのモデルの提供は、700億〜1,750億パラメータのモデルに比べて、レイテンシ、エネルギー消費、浮動小数点演算で測って10〜30倍安くなります。月に数百回しか呼ばれないワークフローなら、この差は誤差にすぎません。絶えず呼ばれるワークフローなら、元が取れるシステムか取れないシステムかの差になります。

能力については、27億パラメータのPhi-2のようなモデルが、同世代の300億パラメータのモデルに匹敵する常識推論とコード生成のスコアを出していることを挙げています。特定の仕事において、小さいことが自動的に弱いことを意味するわけではありません。

タスクに合わせたファインチューニングで比較はまるで変わる

より鮮明な結果は、必要とする狭い仕事に特化して小型モデルを訓練したときに現れます。

研究者たちは、3億5,000万パラメータのモデルfacebook/opt-350mを、エージェントによるツール呼び出し用のToolBenchデータセットでファインチューニングし、77.55%の合格率を報告しました。約1,750億パラメータで思考の連鎖(chain-of-thought)プロンプトを使ったChatGPTは26.00%でした。500分の1の大きさのモデルが、訓練したタスクで約3倍のスコアを出したことになります。

ここで、評価についての前回の記事の考え方をこの数字に当てはめてください。どのベンダーのグラフとも同じように精査に値するからです。

ファインチューニングしたモデルはToolBenchで訓練され、ToolBenchで測定されました。分布をすでに見ているのです。比較対象のフロンティアモデルは、その分布でプロンプトを与えられただけで、訓練はされていません。これは「特化した小型モデルは、特化したタスクで大型の汎用モデルに勝てるか」という問いに対して、手に入る中で最も公平に近い比較です。同時に狭い主張でもあり、そう読むべきです。3億5,000万パラメータのモデルがフロンティアモデルを全般的に上回るわけではなく、論文もそうは述べていません。

この結果が裏付けるのは運用上の論点です。訓練データを作れるほどタスクを厳密に定義できるなら、そのデータで訓練した小型モデルは、丁寧に頼まれた大型モデルと競い合い、しばしば勝ちます。条件は、定義の作業をやることです。

判断のルール

問うべきは、どのモデルが最良かではありません。タスクを仕様化できるかどうかです。

小型モデルを選ぶのは、タスクの入力が限定され出力を検証でき、ラベル付きの例を数百件集められ、単価が問題になるほど量が多く、ユーザーやキューがレイテンシを体感し、あるいはデータを自社のインフラの外に出せないときです。文書の抽出、明文化したルールに基づくリードのスコアリング、チケットの振り分け、構造化されたツール呼び出し、分類はすべてここに入ります。

フロンティアモデルを選ぶのは、入力が本当に自由で、列挙できない知識が仕事に必要で、呼び出しごとのコストがノイズになるほど量が少なく、あるいはタスクが何なのかをまだ探っているときです。初期の探索はフロンティアモデルの仕事であり、人が文章として読むものもすべてそうです。

両方を使うのは、仕事がきれいに分かれるときです。NVIDIAのポジションペーパーはこの理由から異種混成のシステムを勧めています。繰り返しの大部分を小型モデルに回し、本当に新しいケースを大型モデルに上げるのです。私たちが運用する本番システムの多くはこの形をしています。ほとんどのワークロードは大半が定型作業で、そうでない裾野が少し残るからです。

大きく始めて、証拠に基づいて小さくする

最初に小型モデルを選ぶのは間違いです。誰かが実際にこなすところを見たことのないタスクは、仕様化できないからです。うまくいく手順は次のとおりです。

1. フロンティアモデルで構築する。 ワークフローを正しく動かし、実際の入力にさらします。まだ何も最適化しません。
2. すべての呼び出しを記録する。 入力、出力、人による修正です。これが訓練データと評価データになり、初日から始めれば収集コストはかかりません。
3. タスクが変わらなくなるまで待つ。 まだ見直し中のワークフローは、特化させる準備ができていません。動く標的に合わせてファインチューニングすると、作業が二重に無駄になります。
4. 評価用の保留データを作る。 チーム内で意見が割れるものも含め、実際のケースに手でラベルを付け、一部は見せずに取っておきます。
5. そのデータで小型モデルをテストする。 基準を満たせば、コスト曲線は1桁変わります。満たさなくても、失うのは数日で、どのみち必要だった評価が手に入ります。

ステップ5で失敗しても、無駄な作業ではありません。ラベル付きのデータこそ、どのモデルであれ、システムがそもそも機能しているかを教えてくれるものです。

小型モデルが向かない場面

コストの議論は魅力的なので、いくつかははっきり述べておく価値があります。

小型モデルは一般に、訓練したものと似ていない入力への対応が苦手で、本番環境はそうした入力を確実に生み出します。プロンプトの指定が不十分なときに頼れる世界知識も少なめです。そして前四半期の分布でファインチューニングしたモデルは、分布が移るにつれて劣化します。つまり、再訓練の担当者と、それに気づく担当者が必要です。

節約は本物であり続けますが、条件付きでもあり続けます。条件はいつもと同じで、自社のデータで測り、測り続けることです。誰も見ていないシステムは、どんなモデルサイズでも安くはありません。

私たちの適用方法

モデルの選択は、ワークフローを理解した後、構築の中で行います。私たちのAIシステムのカタログにあるシステムはすべて、開発前に合意した書面の成功指標を持つ、範囲を限ったひとつのワークフローとして設計されています。これはまさに小型モデルが必要とする仕様です。本番運用リテイナーがあるのは、測定がローンチで終わらないからです。出力は毎月ベースラインと照らして検証され、それが、動くタスクから離れていく特化モデルを捉えます。

ワークフローがまだ探索段階なら、フロンティアモデルで構築し、そう明言します。節約は後から、証拠に基づいて手に入ります。

出典

• Small Language Models are the Future of Agentic AI、Belcak、Heinrich、Diao、Fu、Dong、Muralidharan、Lin、Molchanov: arxiv.org/abs/2506.02153
• Small Language Models for Efficient Agentic Tool Calling: Outperforming Large Models with Targeted Fine-tuning、Jhandi、Kazi、Subramanian、Sendas: arxiv.org/html/2512.15943v2