---
title: "SLMとは？小規模言語モデルの仕組み・LLMとの違いと実装判断を解説"
url: "https://www.issoh.co.jp/tech/details/13392/"
published: 2026-07-10
updated: 2026-09-27
categories: ["LLM・RAG"]
publisher: "株式会社一創"
---

# SLMとは？小規模言語モデルの仕組み・LLMとの違いと実装判断を解説

SLM（Small Language Model・小規模言語モデル）とは、パラメータ数を数百万〜数十億規模に絞り、特定の用途やドメインに特化させた言語モデルです。数千億から数兆のパラメータを持つLLM（大規模言語モデル）と同じくTransformerを土台にしながら、規模を意図的に小さくすることで、少ない計算資源で動かせる点に特徴がある。本記事は、受託開発でAIシステムを実装する立場から、SLMの仕組みとLLMとの役割分担、蒸留・量子化・ファインチューニングによる作り方、手元のGPU1台へ載せるまでのコマンド、そしてオンプレミスや端末側へ配備すべき判断基準を整理します。用語解説にとどまらず、公式ドキュメントの実寸とそのまま打てるコマンド、採用と見送りの条件までを条件付きで言い切る構成で進めていきます。

## まとめ：SLMは用途を絞って軽量化した特化型モデルで、オンプレ・低コスト・低遅延を取りにいく設計判断である

SLMの本質は、汎用性を一部あきらめる代わりに、特定タスクへ絞ってモデルを小型化し、運用コストと応答速度、そして機密保持を得る役割分担にある。数十億パラメータ級までなら、GPUを積んだ1台のサーバーや、NPUを備えた端末でも実用速度で推論できます。データを外へ出さずオンプレやエッジで完結させたい、推論コストを継続的に抑えたい、特定業務の問い合わせ応答だけを高精度でさばきたい、という要件が明確ならSLMの採用価値が高いといえます。逆に、幅広い話題への汎用対話や複雑な多段推論を精度優先で求める段階では、いったんクラウドのLLMに寄せた方が無難だ。実務では、狭く確実なタスクはSLM、広く難しいタスクはLLMという分担で組み合わせるのが着地点になります。

検証の入口は驚くほど短い。公開済みの小型モデルは配布物がそろっており、Ollamaで1コマンド起動、llama.cppで1コマンド量子化まで進められます。以下では仕組みと作り方を押さえたうえで、実際に打つコマンドと、そこで見るべき数値を順に示していきます。

## SLMとは何か──パラメータ規模とLLMとの違いを実装判断の観点で整理する

言語モデルの規模は、学習で調整される重みの数であるパラメータ数でおおまかに測れます。LLMがGPTやClaudeのように数千億〜数兆規模なのに対し、SLMは数百万〜数十億に収まる。両者はディープラーニングとTransformerという同じ系譜にありますが、SLMは学習データと規模を絞り、特定分野の語彙や様式に寄せて訓練する点が異なります。汎用的に何でも答えられる方向ではなく、対象業務で確実に答えられる方向へ力点を寄せたモデルだ。

代表的なSLMには、MicrosoftのPhi系、GoogleのGemma系、MetaのLlamaの小型版、AlibabaのQwenの小型版などがあり、数億〜数十億パラメータの層が実装の主戦場になっています。これらは重みが公開され、自社環境へ持ち込んで追加学習や推論に回せるものが多い。なかでもMicrosoftのPhi系は3.8B〜14Bで派生が多く、モデルごとの仕様差と選び分けは[Phiの系譜と実行要件・選び分けの解説](https://www.issoh.co.jp/tech/details/15838/)で整理しています。SLMとLLMの差分を、実装判断に効く観点で並べると次のように整理できます。

| 観点        | SLM（小規模言語モデル）  | LLM（大規模言語モデル） |
| --------- | -------------- | ------------- |
| パラメータ規模   | 数百万〜数十億        | 数千億〜数兆        |
| 得意領域      | 特定タスク・特定ドメイン   | 広範な汎用タスク      |
| 実行環境      | 1台のサーバー・端末で可   | 大規模GPUクラスタ前提  |
| 推論の速さ・コスト | 低遅延・低コスト       | 高負荷・従量課金が主    |
| データの置き場所  | オンプレ・端末で完結可    | クラウドAPIが主流    |
| 汎用知識・複雑推論 | 限定的            | 強い            |
| カスタマイズ    | 自社データで追加学習しやすい | 基盤モデルは改変困難    |

この対比の要点は、SLMが「小さいから劣る」のではなく「狭くして強くした」モデルだという捉え方にある。汎用ベンチマークではLLMに及ばなくても、対象を絞った業務では同等以上の精度を、桁違いに軽い資源で出せる場面があります。上位概念であるモデル全体の仕組みは[LLMとは（大規模言語モデル）](https://www.issoh.co.jp/column/details/12962/)で整理しているため、規模による役割分担をつかむ土台として先に押さえておくと判断しやすくなります。

### Phi・Gemma・Qwenの実寸を規模と文脈長・配布形態で見比べる基準

「数十億パラメータ」という括りは粗すぎて、配備先の見当がつきません。公開されているモデルカードの実寸を並べると、どの階層がどのハードウェアを狙って作られているかがはっきりします。MicrosoftのPhi-4-mini-instructは、モデルカード上で3.8Bパラメータ・文脈長128Kトークン・語彙サイズ200,064・学習トークン5T・MITライセンスと明示されています（[Phi-4-mini-instructのモデルカード](https://huggingface.co/microsoft/Phi-4-mini-instruct)／2026年9月時点）。ライセンスがMITである点は、社内システムへ組み込む際の法務確認を軽くする実利があります。

Googleの[Gemma 4のモデルカード](https://ai.google.dev/gemma/docs/core/model%5Fcard%5F4)（2026年7月30日更新時点）は、配備先を明記して階層を切り分けている点が参考になる。実効パラメータという考え方や世代ごとの差分は[Gemma 4のモデル一覧とVRAM要件の解説](https://www.issoh.co.jp/tech/details/11888/)でも扱っています。主要な公開SLMの実寸は次の通りです。

| モデル                 | パラメータ         | 文脈長      | 想定する配備先     |
| ------------------- | ------------- | -------- | ----------- |
| Phi-4-mini-instruct | 3.8B          | 128Kトークン | 単一GPUサーバー   |
| Gemma 4 E2B         | 実効2.3B        | 128Kトークン | 高性能スマホ・エッジ  |
| Gemma 4 E4B         | 実効4.5B        | 128Kトークン | モバイル・エッジ端末  |
| Gemma 4 12B         | 11.95B        | 256Kトークン | ノートPC・民生GPU |
| Gemma 4 26B A4B     | 総25.2B・稼働3.8B | 256Kトークン | 民生GPU・WS    |
| Gemma 4 31B         | 30.7B         | 256Kトークン | サーバー・WS     |

読み取るべきは二点だ。ひとつは、E2B・E4Bの「E」が実効パラメータを指し、Per-Layer Embeddingsによって端末側の資源効率を上げる設計になっていること。もうひとつは、26B A4BのようなMoE構成では総パラメータ25.2Bに対して推論時に稼働するのが3.8Bであり、必要メモリは総パラメータ、必要演算量は稼働パラメータでおおむね効いてくることです。配備先の見積もりを総パラメータだけで出すと、MoEモデルでは演算量を過大に、メモリを過小に読み違えます。

## SLMを作る技術要素──蒸留・量子化・ドメイン特化学習を実装目線で押さえる

SLMの入手経路は二つに分かれます。ひとつは公開済みの小型モデルをそのまま使う道、もうひとつは大きなモデルから小さなモデルを作り出す道だ。後者で中心になるのが知識蒸留で、大きな教師モデルの出力の振る舞いを、小さな生徒モデルへ写し取る手法です。教師の予測分布を学習目標に据えることで、単に小さく学習し直すより精度を保ちやすくなります。損失関数の組み方や実装の順序は[知識蒸留（Model Distillation）の仕組みと実装手順](https://www.issoh.co.jp/tech/details/5364/)で詳しく分解しました。蒸留と併せて、重みのビット幅を落とす量子化を掛けると、メモリ使用量と演算量をさらに削れる。数十億パラメータのモデルを4ビットや8ビットへ量子化し、[GGUF形式](https://www.issoh.co.jp/tech/details/13788/)で配布して端末に載せる流れが定着しつつあります。方式ごとの精度劣化の出方は[LLM量子化とGPTQ・AWQ・GGUFの違い](https://www.issoh.co.jp/tech/details/13791/)にまとめています。

SLMを業務で使えるモデルへ仕上げる作業は、規模の縮小だけでは終わりません。対象ドメインの文書や対話ログでファインチューニングし、社内用語や回答様式へ寄せる工程が精度を左右する。ここでベースモデルの一般知識を土台に、少量の自社データで振る舞いを寄せる進め方は、[転移学習とは](https://www.issoh.co.jp/tech/details/13301/)で解説した考え方と地続きです。全パラメータを更新せず、量子化した重みへ低ランクの差分だけを学習させる[QLoRAの手順とVRAM目安](https://www.issoh.co.jp/tech/details/15944/)を採れば、数十億パラメータ級の追加学習を民生GPU1枚で回せる場合もある。さらに、モデル内部に知識を詰め込みきれない分は、外部の文書を検索して回答に足すRAGで補うのが定石になっている。SLMは記憶容量が小さいぶん、最新情報や大量の固有知識はRAGに任せ、モデル側は言語運用と定型処理に徹する分担が噛み合います。

### SLMの軽量化は量子化・蒸留・ファインチューニングをどの順で組むかを整理する

実務では、まず公開済みSLMを量子化して手元の端末に載り、要求速度を満たすかを試すのが起点になります。8ビット量子化は多くの推論ランタイムが標準対応しており、精度低下を抑えつつ資源を大きく削れるためだ。載る見込みが立ったら、対象業務のデータでファインチューニングして精度を引き上げます。公開モデルでは端末に収まらない、あるいは要件を満たす軽さにならない場合に、蒸留で専用の小型モデルを作り直す選択へ進む。順序を飛ばして最初から強い圧縮と専用学習を同時にかけると、精度がどこで崩れたか切り分けられなくなるため、一手ずつ実測しながら進めるのが安全です。

## 手元のGPU1台でSLMを起動し量子化まで通す作業手順とコマンド例

ここからは実際に打つコマンドを示します。目的は「載るか」「速度が出るか」「容量がどこまで落ちるか」の三点を、検討の初日に数値で押さえることだ。以下のコマンドは公式ドキュメントに記載された形式にそろえてあり、モデル名とファイル名を差し替えればそのまま実行できます。

### OllamaでSLMを起動しAPI経由で応答と生成速度を測る手順

公開SLMを最短で動かす経路がOllamaです。[Ollamaのgemma3ライブラリページ](https://ollama.com/library/gemma3)（2026年9月時点）には、270m・1b（文脈長32K）、4b・12b・27b（文脈長128K）に加え、量子化を前提に学習した`gemma3:4b-it-qat`のようなQATタグが並んでいます。まず小さいタグで動かし、精度が足りなければ一段上げる進め方が無駄がない。起動後は[Ollamaの公式APIドキュメント](https://github.com/ollama/ollama/blob/main/docs/api.md)に従い、`localhost`の11434番ポートへHTTPで投げれば、既存の業務システムから同じ形で呼べます。

```
ollama pull gemma3:4b
ollama list

curl http://localhost:11434/api/generate -d '{
  "model": "gemma3:4b",
  "prompt": "社内規程の該当箇所を200字で要約してください",
  "stream": false,
  "options": { "num_ctx": 4096, "temperature": 0.2 }
}'
```

見るべきは応答本文ではなく、返却JSONに含まれる評価トークン数と所要時間です。`stream`をfalseにすると1回の応答としてまとめて返るため、同じプロンプトを数回投げて所要時間のばらつきまで確認できる。ここで要求速度に届かないなら、モデルを一段小さくするか、`num_ctx`を業務で実際に必要な長さまで絞ります。文脈長を最大値のまま放置するのは、メモリを無駄に食う代表的な設定ミスだ。推論基盤そのものの選択肢は[LLM推論の仕組みと推論基盤の選び方](https://www.issoh.co.jp/tech/details/15363/)で比較しています。

### llama-quantizeでGGUFへ量子化しファイル容量を比べる手順

公開モデルをそのまま使わず、自前でファインチューニングした重みを配布する段になると、量子化を自分で掛ける工程が入ります。llama.cppの[quantizeツールのREADME](https://github.com/ggml-org/llama.cpp/blob/master/tools/quantize/README.md)（2026年9月時点）は、入力GGUFと量子化タイプ、スレッド数を渡す形式を示しています。出力の重み行列だけ量子化から外す、既に量子化済みのテンソルを再量子化する、全テンソルを同一タイプにそろえる、といった調整はオプションで切り替える仕組みです。

```
./llama-quantize input-model-f32.gguf q4_k_m 8

./llama-quantize --allow-requantize --leave-output-tensor --pure \
    input-model-f32.gguf q4_k_m 8
```

量子化後にまず確認するのはファイル容量の変化と、同じ評価用プロンプト集での出力の崩れ方です。`--leave-output-tensor`は出力層を量子化せずに残すため容量削減幅は縮みますが、生成の破綻が減る場合がある。`--allow-requantize`は既に量子化されたテンソルへさらに量子化を掛ける指定で、READMEにも16ビットや32ビットから量子化する場合に比べて品質が大きく下がりうると注意書きがあります。配布物として量子化済みGGUFしか手元にないときの逃げ道であって、常用する設定ではありません。精度の実測を挟まずにビット幅だけ下げる進め方は、極端な低ビット化の限界を扱った[1bit LLM「Bonsai」の三値量子化の解説](https://www.issoh.co.jp/tech/details/15606/)と同じ落とし穴を踏みます。

## SLM導入で解けるコスト・機密の課題と、割り切れない制約を見極める

SLMが効くのは、第一にコストと処理速度が課題になる場面だ。問い合わせ応答や文書分類、要約といった定型的なタスクを大量にさばく用途では、LLMのAPIを毎回叩くより、軽量なSLMを自前で回した方が推論単価と応答時間の両面で有利になります。第二にデータの置き場所が制約になる場面が挙げられる。個人情報や設計情報を外部のクラウドへ送れない業種では、オンプレやエッジ端末で完結するSLMが現実的な選択肢に入ります。第三は狭い領域での安定性で、対象を絞って学習したSLMは、想定外の話題へ引きずられにくく、ハルシネーションの余地を狭められる点が挙げられます。

適用例を挙げると、効きどころの輪郭がつかめます。社内ヘルプデスクでは、製品マニュアルとFAQに特化したSLMへRAGを組み合わせ、定型質問をオンプレで即答させる構成が採れる。製造や医療の現場端末では、通信を挟まず現場データを判定・要約させる用途で、[エッジAIとは](https://www.issoh.co.jp/tech/details/13390/)で整理した端末側推論の枠組みにSLMを載せる形が広がっています。開発現場では、コード補完や定型文の生成といった限定タスクを、機密を外へ出さず手元で回す使い方も定着してきました。いずれも、扱う範囲が明確で、コストか機密が壁になる領域でSLMの投資対効果が出やすい共通点を持ちます。

反面、割り切れない制約もあります。SLMは汎用知識と複雑な多段推論が弱く、対象を外れた質問や込み入った論理には力不足になりがちだ。学習データに無い最新情報も苦手で、そこはRAGで補わない限り精度が落ちます。特定業務へ寄せるほど汎用性は下がるため、扱う話題が広く読めない用途には向きません。SLMは万能なLLMの廉価版ではなく、狭く確実な仕事を軽く速くこなす部品だと捉えるのが実装者の現実解になります。

## SLMを採用すべき条件と、見送ってLLMに寄せる場面の判断基準

ここは一般記事が踏み込まない独自の判断軸として、採用条件と見送り場面を言い切ります。次の条件が二つ以上重なるなら、SLMを主軸に据える価値が高い。ひとつ、扱うタスクが問い合わせ応答・分類・要約など範囲を絞れる定型処理である。ふたつ、データを外部クラウドへ送れず、オンプレや端末で完結させたい要件がある。みっつ、推論を大量に回すため従量課金のLLM APIではコストが読めない。よっつ、自社に対象ドメインの文書や対話ログが蓄積しており、ファインチューニングやRAGで精度を寄せられることです。

逆に、次のいずれかが強く当てはまるなら、初手はLLMに寄せる判断を推奨します。扱う話題が広く、どんな質問が来るか読めない汎用対話が主目的である。あるいは、企画立案や長文の論理的な推論など、幅広い知識と多段思考が精度の要になるケースだ。利用頻度が低く、自前でモデルを保守する運用コストの方が割高になる場合も同様になります。これらの場面では、まずクラウドのLLM APIで価値と精度を検証し、コスト・機密・遅延の壁に当たった機能だけを後からSLMへ移すのが堅実な進め方です。判断を白黒で固定せず、汎用な入口はLLM、確定した定型処理はSLMと機能単位で分けるハイブリッド設計が、最も現実的な着地になります。特定業務向けの軽量な対話システムを、モデル選定から社内データでのチューニング、オンプレ運用まで一貫して組みたい場合は、[AIチャットボット開発](https://www.issoh.co.jp/service/ai/chatbot/)として要件整理の段階から支援しています。

## SLM実装の進め方──モデル選定から評価・運用までの設計手順とつまずき所

実装は、対象タスクと精度・速度・コストの目標値を数値で置くところから始まります。この三つを言語化せずに開発へ入ると、後段のモデル選定がすべて主観になるためだ。次に、Phi・Gemma・Llama小型版・Qwen小型版といった公開SLMの中から、対象言語と規模の候補を絞り、手元の環境で量子化して推論速度を実測します。ここで基準の速度と土台の精度が出なければ、モデル規模の見直しに戻る。候補が定まったら、自社データでファインチューニングし、モデルに載せきれない知識はRAGで外付けして、対象業務の質問セットで精度を評価していきます。

本番運用で成否を分けるのは、モデル開発そのものより評価と運用の作り込みだ。SLMは汎用ベンチマークの点数が当てにならないため、対象業務の実際の質問を集めた評価データで合否を測る仕組みを、初期設計から用意しておきます。加えて、誤答を収集して再学習やRAGの文書追加へ回すデータループ、オンプレ環境での推論監視の二点も織り込んでおく。ここを後回しにすると、リリース後に精度の劣化へ気づけず、改善も回らなくなります。扱うモデルを手元のGPU一台やオンプレサーバーで動かす際の構成や必要スペックは、[ローカルLLMとは](https://www.issoh.co.jp/column/details/12964/)で整理した実行環境の考え方が土台になるため、SLM選定とあわせて確認しておくと配備の判断を描きやすくなります。

つまずき所は三つに集約されます。第一に、モデルサイズの見積もりを総パラメータだけで出し、量子化後の実容量とKVキャッシュ分のメモリを勘定に入れていないこと。第二に、文脈長を公称値のまま設定し、必要のない長さでメモリを圧迫していること。第三に、評価用の質問セットを用意しないまま体感で良否を判断し、モデル差し替えのたびに議論が振り出しへ戻ることです。いずれも実装前の準備で潰せる項目であり、後から取り返すコストの方がはるかに大きくなります。

## よくある質問

SLMの導入検討でよく挙がる質問を、実装目線で簡潔に整理します。

### SLMとLLMはどちらを選べばよいですか？

扱うタスクの幅で決めます。問い合わせ応答や分類など範囲を絞れる定型処理で、オンプレ運用やコスト圧縮が要件ならSLMが向きます。逆に、話題が広く読めない汎用対話や、複雑な推論が精度の要になるならLLMが有利です。両者を機能単位で分担させる構成も現実的になります。

### SLMは具体的にどのくらいのパラメータ数ですか？

数百万〜数十億パラメータの範囲を指すのが一般的です。実装の主戦場は数億〜数十億級で、モデルカード上ではPhi-4-mini-instructが3.8B、Gemma 4のE2Bが実効2.3B、E4Bが実効4.5Bと公開されています（2026年9月時点）。数千億以上のLLMと比べ、1台のGPUサーバーやNPUを備えた端末でも動かせる軽さが目安になります。

### SLMを自社データに合わせて使うにはどうしますか？

二段構えが基本です。対象ドメインの文書や対話ログでファインチューニングして回答様式を寄せ、モデルに載せきれない最新情報や固有知識はRAGで外部検索して補います。全パラメータを更新せずQLoRAのような低ランク学習を使えば、民生GPU1枚でも追加学習を回せる場合がある。知識はRAG、言語運用はモデルという分担が噛み合います。

### SLMにすると精度は必ず下がりますか？

対象を絞った業務では、必ずしも下がりません。汎用ベンチマークではLLMに及ばなくても、特定タスクへファインチューニングしたSLMが同等以上の精度を、はるかに軽い資源で出す場面があります。逆に想定外の広い話題では精度が落ちるため、範囲設計が前提になります。

### SLMはオフラインの端末でも動きますか？

動きます。量子化して軽量化したSLMを端末に載せれば、通信を挟まずローカルで推論が回せる。Gemma 4のモデルカードはE2B・E4Bの配備先として高性能スマートフォンやエッジ端末を挙げており、端末側での実行を前提に設計された階層が存在します。ただし端末の演算資源に収まる規模へ圧縮する必要があり、載せられるモデルサイズと要求速度の兼ね合いで設計します。

## 関連記事

- [LLMとは？大規模言語モデルの仕組み・生成AIとの違いと企業導入の判断基準を解説](https://www.issoh.co.jp/column/details/12962/)：SLMの上位概念。規模による役割分担を押さえる土台になります。
- [ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説](https://www.issoh.co.jp/column/details/12964/)：SLMを手元のサーバーや端末で動かす実行環境の考え方を補完します。
- [エッジAIとは？クラウドAIとの違い・仕組み・実装の判断基準を解説](https://www.issoh.co.jp/tech/details/13390/)：SLMを端末側へ載せるエッジ生成AIの設計と地続きです。
- [知識蒸留（Model Distillation）とは？仕組み・実装手順とLLM軽量化の判断基準](https://www.issoh.co.jp/tech/details/5364/)：大きなモデルから小さなモデルを作る工程を実装手順まで分解しています。
- [LLM量子化とは？仕組みとGPTQ・AWQ・GGUFの違い・企業の採用判断を解説](https://www.issoh.co.jp/tech/details/13791/)：量子化方式ごとの精度劣化と採用条件を比較しています。

---

出典: [SLMとは？小規模言語モデルの仕組み・LLMとの違いと実装判断を解説](<https://www.issoh.co.jp/tech/details/13392/>)（株式会社一創）