SLM（小規模言語モデル）とは｜選び方とオンプレ・エッジ活用

SLMとは｜LLMとの違いと「小規模」の線引き

SLMは、少ないパラメータ数で動作する言語モデルの総称です。定義上の下限・上限は決まっていません。数億パラメータのモデルをSLMと呼ぶ文献もあれば、10B前後まで含める整理もあります。

定義があいまいな理由と、実務での線引き

結論から言えば、SLMかどうかは相対的な呼び方です。業界共通の閾値はありません。

ただ、案件の現場では判断に困りません。「このモデルは、顧客が用意したサーバーのGPUメモリに収まるか」という問いに置き換わるからです。32GBのGPUが1枚しかない環境なら、7B〜8Bクラスが上限になります。CPUだけで動かす要件なら、1B〜3Bまで落とす判断になるでしょう。

パラメータ数ではなく、配置先のハードウェア制約から逆算する。これが実務的な線引きです。

LLMとの違いを5つの観点で比較する

性能差をどう埋めるかが設計の肝になります。SLM単体で汎用的な質問応答をさせると、知識の不足がそのまま誤回答に出ます。外部知識をRAGで補う、タスクを絞り込む、といった前提とセットで検討するものです。RAG側の構成はRAG構築案件の実情｜単価相場・必要スキル・獲得方法が参考になります。

SLMが選ばれる3つの理由

1. データを外に出せない。医療・金融・公共系では、入力データの外部送信そのものが契約上の制約になるケースがあります

2. 応答速度。モデルが小さいほど初回トークンまでの待ち時間が短くなります。工場の制御画面や店舗端末のように、数百ミリ秒の遅延が体験を左右する用途で効きます

3. コスト構造が読める。従量課金ではなく、ハードウェアの償却に置き換わります。呼び出し回数が多いほど有利になる構造です

NVIDIAの研究チームは、エージェント型AIの多くの呼び出しは繰り返し性の高い定型タスクであり、そうした用途ではSLMで十分だと論じています（Small Language Models are the Future of Agentic AI）。すべてをLLMで賄う前提を疑う、という考え方です。

ミニFAQ：SLMはLLMの劣化版ですか。

いいえ。用途を絞れば同等以上の結果を出すケースがあります。たとえば「問い合わせメールを5カテゴリに分類する」ような定型タスクでは、巨大モデルの汎用性は過剰になりがちです。

主要なSLMの系統と特徴

ここで挙げるモデル名とサイズは、執筆時点で各社の公式ページから確認できる情報です。この領域は更新が速いため、採用前に必ず公式のモデルカードで最新のラインアップとライセンスを確認してください。

Microsoft Phi系

小さいサイズで推論性能を出すことを狙った系統です。Phi-4-mini-instructは38億パラメータ（3.8B）・コンテキスト長128Kトークンで、公式のモデルカードではライセンスがMITと明記されています。日本語を含む22言語をサポート対象として挙げています。

MITライセンスは制約が少なく、商用案件で検討しやすい部類です。数学・論理推論を重視したチューニングが特徴として説明されています。

Google Gemma系

Gemmaの公式ページでは、モバイル・IoT向けの軽量版や、270Mクラスの超小型モデルまで幅広いサイズが公開されています。関数呼び出しに特化した派生モデル、オンデバイス埋め込み向けのモデルなど、用途特化の派生が多いのも特徴です。

注意したいのがライセンスです。Gemmaは独自の利用規約で配布されており、商用利用は可能なものの、禁止用途ポリシーの順守や、再配布時の規約添付・改変明示といった義務が課されます。「オープンだからApache 2.0相当だろう」と読み替えないでください。

Meta Llama系・Alibaba Qwen系

Llamaはコミュニティライセンスでの配布です。Llama 3.2 Community Licenseでは、月間アクティブユーザーが7億を超えるサービスは別途Metaの許諾が必要と定められています。大半の受託案件では問題になりませんが、エンドクライアントが大規模消費者サービスを運営している場合は確認が要ります。

Qwenは、公式ブログによればQwen3世代で0.6B・1.7B・4B・8B・14B・32BのデンスモデルをApache 2.0で公開しています。ライセンス面の自由度は高い部類です。小さいサイズのコンテキスト長は32K、大きいサイズは128Kまでという違いがあります。

日本語を重視する場合の選択肢

日本語性能は、英語ベンチマークの順位とは必ずしも一致しません。国内開発のモデルも候補に入れて比較する価値があります。

SB IntuitionsはSarashina2.2-Instructとして0.5B・1B・3Bの指示チューニング済みモデルをMITライセンスで公開しています。同社の記事では、3Bクラスが日本語の数学・コーディングタスクで、以前に公開した70Bモデルを上回るスコアを示したと報告されています。

モデルの入手・比較はHugging Faceとは？AIモデル共有プラットフォームの基本と業務活用をフリーランスエンジニア視点で解説で解説したプラットフォームが起点になります。

モデル選定の5つの判断軸

技術検討の順序としては、サイズ → 量子化 → 日本語性能 → コンテキスト長で絞ると手戻りが減ります。ただしライセンス確認だけは別枠で、候補を数本に絞った時点から並行して進めてください。最後にまとめて見ると、条件に引っかかって作り直しになります。

1. パラメータ数からメモリ必要量を見積もる

重みのサイズは、パラメータ数×1パラメータあたりのバイト数で概算できます。

これは重みだけの理論値です。実際にはKVキャッシュ、アクティベーション、推論ランタイムのオーバーヘッドが上に乗ります。目安として重みの1.3〜1.5倍から見積もりを始めると検討しやすくなりますが、この倍率は固定値ではありません。同時接続数・入力長・推論エンジンの実装で変わるため、最終的には実機での実測が必要です。長いコンテキストを扱う設計では、KVキャッシュが重みを上回ることもあります。

2. 量子化の精度をどこまで落とすか

量子化は、重みの数値表現を粗くしてサイズを縮める手法です。4bitまで落とすと容量は4分の1近くになりますが、出力品質は少し下がります。

判断の目安は用途です。分類・抽出・定型応答なら4bitでも実用に耐えるケースが多く見られます。一方、長文の要約や論理的な手順生成では、8bitに戻したほうが安定することがあります。量子化の影響は、タスク固有の評価セットを作って測るしかありません。感覚で決めないことです。

評価の組み立て方はLLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説で整理しています。

3. ライセンス条件を契約前に確認する

ここが一番の落とし穴です。オープンウェイトのモデルでも、条件は系統ごとにばらばらです。

受託案件では、納品先がモデルをどう再配布するかまで確認が要ります。社内利用だけなのか、顧客の顧客に提供するSaaSに組み込むのかで、必要な条件が変わります。

なお、上の表は原文を読む前の当たりをつけるための整理です。ライセンスの解釈は利用形態・配布形態・派生物の扱いによって変わり、エンジニア単独で確定させる領域ではありません。候補を絞った段階で原文を取得し、発注元の法務部門や顧問弁護士の確認を通す前提で進めてください。モデル提供元が規約を改訂することもあるため、採用時点の版を控えておくと後の確認が楽になります。

4. 日本語性能は日本語の評価データで測る

英語中心のベンチマークスコアが高くても、日本語の敬語表現や業界用語で崩れることがあります。実案件のログから50〜100件程度のサンプルを作り、候補モデルを横並びで比べる。評価観点が少ない小規模PoCであれば1〜2日で回せる工程ですが、観点が多い案件や複数業務をまとめて扱う場合はさらに時間を見てください。

5. コンテキスト長は「実際に使う長さ」で選ぶ

カタログ上の128Kという数字と、実用的に品質を保てる長さは別物です。長い入力を詰め込むほどKVキャッシュがメモリを圧迫し、応答も遅くなります。社内文書を扱うならRAGで必要な箇所だけ渡す設計のほうが、短いコンテキストで済みます。

ミニFAQ：ファインチューニングは必要ですか。

最初からは不要なケースが多いです。プロンプト設計とRAGで届かない場合に検討する順序が無難です。追加学習まで踏み込む案件の実像はLLMファインチューニング案件の全体像｜必要スキル・単価目安・参画ルートを参照してください。

オンプレ・エッジでの配置パターン

配置は大きく3つに分かれます。要件のうち「どのデータが、どこまで出てよいか」を先に確定させると、パターンは自然に決まります。

パターン1：社内サーバー集約型

GPUサーバーを社内に置き、業務システムから推論APIを呼ぶ構成です。モデル更新や監視を1カ所で管理できます。利用者数が数十〜数百人規模の社内アシスタント用途で採りやすい形です。

ハードウェア調達のリードタイムが読みにくい点が難所になります。GPU搭載機は発注から納品まで数週間かかることもあり、PoCのスケジュールに響きます。

パターン2：端末・エッジ常駐型

タブレット、産業用PC、組込機器の上でモデルを動かす構成です。ネットワークが不安定な現場や、通信そのものを遮断している環境で選ばれます。

制約は厳しくなります。使えるメモリが数GB、電力やサーマル制約もある。モデルサイズは1B〜3Bが現実的な範囲になりやすいでしょう。ハード寄りの知見が要るため、組込系の経験が効いてきます。この領域の案件傾向は組込・制御エンジニアのフリーランス単価相場｜SDV・IoT案件動向にまとめています。

パターン3：SLMとLLMのハイブリッド

定型処理はSLM、難しい問い合わせだけクラウドのLLMへ回すルーティング構成です。コストと品質のバランスを取りやすい反面、どこで分岐させるかの判定ロジックが新たな設計課題になります。

機密データを含む入力はLLM側に流さない、という条件を入れるなら、判定そのものをローカルで完結させる必要があります。コスト設計の考え方はLLMコスト最適化案件の単価相場｜トークン削減・推論設計のフリーランス実務が参考になります。

案件全体の構成パターンや要件定義の論点は、社内LLM導入案件とは｜構成・要件・単価とフリーランスの参画実務で詳しく扱っています。

ケース別の選び方

業界ごとに効いてくる制約が違います。代表的な4パターンを挙げます。

• 製造業の現場端末：オフライン動作が前提になりやすい領域です。1B〜3Bクラスを4bit量子化し、用途を異常検知のログ要約や作業手順の照会に絞る形が噛み合います。日本語の専門用語辞書をRAG側に持たせる設計が効きます

• 医療・ヘルスケア：患者データの取り扱いが最優先の制約になります。閉域での完結が要件化されやすく、モデル選定よりも監査ログとアクセス制御の設計に工数が寄ります

• 金融：既存の勘定系・基幹系との接続要件が重くなりがちです。推論結果をそのまま業務判断に使わせない、人のレビューを挟む運用設計がセットで求められます

• 官公庁・公共系：調達要件にライセンス条件や供給元の情報が含まれることがあります。独自規約型のモデルは、条件の読み合わせに時間がかかる前提で見ておくと安全です。この領域の契約・セキュリティ要件は官公庁・公共系のフリーランスエンジニア案件｜単価相場・契約形態・セキュリティ要件を徹底解説で整理しています

SLM導入でつまずきやすい失敗と対策

実際のPoCで繰り返し見られるパターンを挙げます。

• LLMと同じ期待値で評価してしまう：汎用的な雑談性能で比べると、SLMは必ず負けます。評価軸を「対象タスクの正答率」に限定してから比較してください

• メモリ見積もりでKVキャッシュを忘れる：重みのサイズだけで調達し、同時接続を増やした途端にOOMで落ちる。最初から重みの1.3〜1.5倍を確保しておきます

• ライセンス確認が契約後になる：モデルを決めてから再配布条件に引っかかり、作り直しになるケースです。候補を3つに絞った段階で原文を法務に共有し、技術検証と並行して確認を進めておくと安全です

• 誤回答の責任分界が曖昧なまま運用に入る：知識不足に起因する誤りは、SLMでは相対的に起きやすくなります。対策の考え方はハルシネーション対策｜LLMの誤回答を減らす実装と運用設計にまとめました

• 更新計画がない：モデルの世代交代は速い領域です。入れ替え手順と評価セットを運用設計に含めておかないと、2年後に動かせない資産になります

SLM選定チェックリスト

候補を絞る段階で、この順に埋めていくと抜けが出にくくなります。

このチェックリストは、PoCの提案書にそのまま載せられる粒度で作っています。顧客との認識合わせの材料としても使えるはずです。

フリーランス案件でSLMの知識がどう効くか

SLMそのものを指名条件にした募集は、まだ多くありません。実際には「社内LLM導入」「オンプレAI基盤構築」といった案件名の中に、モデル選定の工程として含まれているのが実情です。公開されている募集要項を見る限りでは、オンプレ・閉域の要件が書かれた生成AI案件で、この知識が問われる形になります。

評価されやすいのは、モデルを動かせることよりも選定理由を説明できることです。なぜ3Bにしたのか、なぜ4bitで足りると判断したのか、ライセンスをどう確認したのか。この3点を資料化できる人は、要件定義フェーズから入りやすくなります。

単価レンジは案件の商流やフェーズで大きく変わるため、ここでは断定しません。生成AI周辺の案件単価の考え方は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？で整理しています。自分の経歴でどのくらいを狙えるか把握しておきたい方は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。実際の募集内容は案件一覧から確認してください。

まとめ

SLM選定は、配置先のハード制約からサイズと量子化で候補を絞りつつ、ライセンス確認を早い段階から並行して進めるのが最短です。モデルの性能比較から入ると遠回りになります。

• SLMに定義上の境界はなく、実務では対象ハードに載るかどうかで線を引く

• メモリ見積もりは重みの1.3〜1.5倍から出発し、実機での実測で確定させる

• ライセンスはMIT・Apache 2.0・独自規約・コミュニティ型で条件が大きく異なる。最終判断は法務確認を通す

• 日本語案件では、英語ベンチマークではなく実データ50〜100件での横並び比較を行う

• 配置は社内サーバー集約・端末常駐・ハイブリッドの3パターンから要件で選ぶ

• 評価セットを先に作っておくと、モデルの世代交代に数日で追従できる

次の一歩としては、手元の環境で3Bクラスのモデルを4bitと8bitの両方で動かし、自分で用意した評価セットを回してみることをおすすめします。差が出る箇所を体感しておくと、提案の説得力が変わります。

参照した一次情報は以下のとおりです。

• Small Language Models are the Future of Agentic AI（arXiv）

• Phi-4-mini-instruct モデルカード（Hugging Face）

• Gemma 公式ページ（Google DeepMind）

• Gemma Terms of Use

• Llama 3.2 Community License Agreement

• Qwen 公式ブログ

• Sarashina2.2-Instruct（SB Intuitions TECH BLOG）