オンプレミスLLMとモデル蒸留の組み合わせとは、大規模言語モデル（教師）が持つ知識を小型モデル（生徒）へ圧縮し、外部クラウドに依存せず社内サーバー内で完結して運用するための手法である。クラウドAPIにデータを送れない情報システム担当者・AIエンジニアに向けて、本記事では環境構築から蒸留済みモデルの本番運用までを、モデル選定・データ構築・トレーニング・失敗回避の順に解説する。専門用語は逐次補足するため、機械学習の専門家でなくても全体像をつかめる構成とした。

社内データを社外に出せないという制約と、オンプレで大型モデルを動かすコストの高さ——この2つを同時に解く手段がモデル蒸留である。 蒸留で小型化した生徒モデルなら自社のGPUでも現実的に動かせ、入力したデータは一歩も社外に出ない。ここではまず、クラウド利用のリスクと蒸留が解決する課題を整理する。

クラウドのLLM APIを使うと、プロンプトに含めた社内文書や顧客情報が外部のサーバーに送信される。ここには複数のリスクが伴う。入力データが提供事業者側で学習や品質改善に利用される可能性（契約プランによる）、ログが一定期間保管されること、データが国外のデータセンターに保管されること、そして利用規約が将来変更される可能性などである。

金融・医療・製造のように図面やソースコード、規制対象の個人データを扱う企業では、たとえ事業者が「学習には使わない」エンタープライズ契約を結んでいても、「データが物理的に社外へ出る」という事実自体が監査・規制対応の説明責任を残す。オンプレミス運用であれば、推論をネットワークから物理的に切り離し、データが社内に留まることを構造的に保証できる。これが、セキュリティ要件の厳しい現場でオンプレが選ばれる根本的な理由である。

「社内に閉じたいならオンプレで大型モデルを動かせばよい」と考えると、今度はコストの壁にぶつかる。最前線級の大規模モデルをそのままオンプレで動かすには、数百GB規模のVRAMを備えた高価なGPUを複数台そろえる必要があり、多くの企業にとって現実的ではない。

モデル蒸留は、この大型モデル（教師）の知識を数十億パラメータ規模の小型モデル（生徒）へ圧縮することで、必要なハードウェアを大幅に小さくする。トレードオフとして汎用的な性能は教師より落ちるが、自社が使う特定タスクに絞れば実用的な精度を保ちやすい。固定費としてGPU購入費はかかるものの、トークン単位の従量課金が消えるため、利用頻度が高いほど総コスト（TCO）で有利になりやすい。損益分岐点は選ぶモデルと利用量に依存するため、自社の利用量で試算することが重要だ。

小型言語モデル（SLM: Small Language Model、数億〜十数B規模）は、パラメータが少ない分だけ推論が速く、応答までの遅延（レイテンシ）も小さい。オンプレ環境でバッチ処理や同時リクエストをさばきやすく、量子化を併用すればさらに軽くなる。

精度については、分類・抽出・要約・社内文書QAのような範囲の狭いタスクであれば、蒸留した小型モデルでも大型モデルに近い品質に届くことが多い。一方、自由な発想や長い推論を要する用途では、小型モデルと大型モデルの差は残りやすい。ここで大切なのは、汎用ベンチマークのスコアの高さを追うのではなく、「自社のタスクに必要な精度水準」を先に定義し、自社の評価データで測ることだ。速度と精度のどちらをどこまで優先するかは、用途ごとに異なる。

蒸留を「とりあえず試す」前に、ハードウェア・ライセンス・データ品質の3点を固めておく必要がある。 ここを曖昧にすると、トレーニング後に法務でストップがかかったり、精度が出ずにやり直しになりやすい。

蒸留のトレーニングでは、教師モデルの推論（ソフトラベル生成）と生徒モデルの学習の両方でGPUを使う。本番運用（推論のみ）はトレーニングより負荷が軽く、量子化で要件をさらに下げられる。

最低基準は生徒モデルのサイズで決まり、数十億パラメータ規模なら24GB級GPU 1枚から検討できることが多い。メモリとストレージはデータセット規模に応じる。具体的な必要VRAMはモデルとバッチサイズで大きく変わるため、まず小規模なPoC（概念実証）で実測し、その結果をもとにスケールさせるのが安全だ。最初から大規模な構成を買い込むのは避けたい。

教師モデルの選び方ひとつで、法的リスクの有無が分かれる。最初に押さえるべき落とし穴は、商用APIで提供されるモデルの出力をそのまま教師信号にして自社モデルを訓練する行為だ。主要な提供事業者は、出力を「競合するモデルの開発」に使うことを利用規約で明示的に制限しており、これに該当すると規約違反になり得る（OpenAI・Anthropic はいずれも、出力を競合・模倣モデルの訓練に用いることを禁じている）。実際に、大規模な規約違反として問題化した事例も報じられている。

このリスクを避ける現実的な方法は、商用蒸留を許容するライセンスのオープンソースモデルを教師に使うことだ。ただしオープンソースでもライセンスは一様ではない。MIT や Apache 2.0 系（DeepSeek・Qwen・Mistral・Phi など）は比較的寛容で商用利用しやすい一方、Llama 系は Meta 独自のコミュニティライセンスで、月間アクティブユーザーが極めて大きい事業者には別途許諾が必要で地域制約もある。Gemma は Google の利用規約への同意が前提となる。選定時は必ず各モデルのライセンスページ（公式リポジトリや配布元）を一次ソースとして確認し、法務レビューを通すこと。ライセンス条件は更新されるため、過去の情報をそのまま流用しない。

蒸留後の精度は、教師信号の質そのものより「生徒に何を学ばせるか」というデータ設計に左右される部分が大きい。前処理では、重複の除去、ノイズや明らかな誤記の除去、機密度ラベルの付与、フォーマットの統一を行う。

品質基準として重視したいのは、データが実際の業務分布を反映しているか（代表性）と、ラベルや書式が一貫しているかの2点だ。量を集めることに意識が向きがちだが、少量でも質の高いデータが、大量の雑多なデータに勝ることは珍しくない。実務では、自動処理だけに任せず、サンプルを人手で目視して「業務で本当に来る入力か」を確認する工程を必ず挟みたい。個人情報を含むデータの匿名化については、後のステップで詳しく扱う。

教師は「自社で使えるライセンスの、タスクに強いモデル」、生徒は「自社GPUで本番運用できるサイズ」から逆算して選ぶ。 性能の最大化ではなく、制約の中での最適化が選定の軸になる。

結論として、ライセンスの寛容さを最優先のゲートにし、その上でタスク適性とサイズで絞り込むのが安全だ。

※ライセンスや条件は更新されるため、選定時に必ず最新の一次情報を確認すること。

選定基準は、①ライセンス（商用蒸留が可能か）②自社タスクでの精度（自社データで評価）③サイズ（本番GPUに収まるか）④日本語・多言語対応 ⑤コミュニティの活発さ（情報と更新の入手しやすさ）の順で見ると判断しやすい。スコアの絶対値より、自社制約への適合を優先する。

生徒モデルは、汎用の大型モデルを丸ごと縮小するより、用途を絞った小型モデルとして仕立てるほうが向く。代表的な用途と規模感の対応は次のとおりだ。文書の分類やキー情報の抽出なら、数億〜数B規模で十分なことが多い。社内文書のQAは、RAG（検索拡張生成）と組み合わせ、生成部分を中規模の生徒に任せる構成が現実的だ。要約は中規模、コード補完はコードに特化した事前学習モデルを土台にする。

ここでいう「特化型」とは、既存の小型モデルを自社タスクで蒸留・微調整したものを指す。汎用チャットの能力を全部再現しようとせず、業務で実際に使う1〜2のタスクに絞ることで、小型でも実用水準に届きやすくなる。欲張らない設計が、結果的に運用コストと精度の両立につながる。

結論として、「許容できるレイテンシ」と「必要な精度」の2軸で、要件を満たす最小サイズを選ぶのが定石だ。

マッピングの手順は、①自社で使うタスクを列挙し、②各タスクの精度・レイテンシ要件を可能な限り数値化し、③最小サイズからPoCで段階的に上げていく、という流れになる。最初から大きいモデルを選ぶと、コストとレイテンシの両方を無駄に抱え込む。要件を満たした時点でサイズを止めるのが、実運用では効いてくる。

蒸留用データは「教師の出力（ソフトラベル）」と「自社の正解データ」の2層で作る。 どちらも、本番で実際に来る入力の分布を反映していることが品質の生命線になる。

ソフトラベルとは、教師モデルが各クラスやトークンに与える確率分布のことだ。「正解は1つ」と決めつけるハードラベルと違い、教師がどの選択肢をどれくらいの確信度で見ているかという情報を含む。

生成手順は次のようになる。①代表的な入力データを用意する。②教師モデルで推論し、出力のロジットや確率分布を保存する（このとき後述の温度パラメータを上げて分布をなだらかにする）。③これを生徒の学習ターゲットとして使う。ソフトラベルには「教師がなぜそう判断したか」に近い情報が含まれるため、ハードラベルだけで学習するより生徒の汎化性能が高まりやすい。ただしソフトラベル生成には教師の推論コストがかかるため、必要なデータ量と計算資源のバランスを見て進める。

社内に散らばる文書（PDF、Office、社内Wiki、問い合わせチケットなど）を学習データに変換するには、段階的なパイプラインを組む。①抽出：パーサやOCRでテキスト化する（画像として保存されたPDFはLLMでテキスト化する方法が有効だ）。②クレンジング：ヘッダ・フッタ・重複を除去する。③構造化：QA形式や「指示—応答」形式へ整形する。④機密度ラベル付け：データ区分を付与する。⑤分割：学習用と検証用に分ける。

RAG用途ならチャンク分割と埋め込み生成、蒸留用途なら指示応答ペアへの整形が中心になる。工程は自動化しつつ、出来上がったデータのサンプルは人手で必ず目視確認したい。経験的に、精度を最も下げる原因は高度なアルゴリズムの欠陥ではなく、ゴミデータの混入であることが多いからだ。

オンプレで完結していても、学習データに個人情報や機密が含まれれば、モデルがそれを記憶し、後で出力してしまうリスクが残る。対応は3段階で考える。①PII（氏名・連絡先・口座番号など）を検出してマスキング・仮名化する。②機密区分に応じて、そもそも学習対象に含めるかを取捨選択する。③学習後に、モデルが機密を吐き出さないかをレッドチーム的にテストする。

タイのPDPAをはじめとする地域のデータ保護法では、個人データの目的外利用や保管に制約があるため、「収集時の目的の範囲でAI学習に使ってよいか」を法的根拠とあわせて整理しておく必要がある。匿名化したつもりでも、断片を組み合わせると個人を再識別できる場合があるため、再識別リスクの評価まで含めて対応するのが望ましい。

トレーニングの肝は、蒸留ロス（教師に似せる損失）の設計と、過学習を止めるためのモニタリングの2つにある。 コマンドを回すこと自体より、ここの設計で最終的な精度が決まる。

蒸留の損失関数（ロス）は、一般に2つの項を組み合わせて設計する。1つ目は、生徒の出力を教師のソフトラベルに近づける項で、確率分布どうしの距離を測るKLダイバージェンスがよく使われる。2つ目は、生徒の出力を正解（ハードラベル）に近づける通常のクロスエントロピーだ。

ここで効いてくるのが温度パラメータT である。Tはソフトマックスのなだらかさを調整するもので、値を上げるほど教師の確率分布が平滑化され、クラス間の関係性という「暗黙の知識」が生徒に伝わりやすくなる。実務では、このTと2項の重み係数（αなど）をハイパーパラメータ探索で調整する。Tが高すぎると情報が薄まり、低すぎると硬いラベルに近づいてしまうため、検証セットでの精度を見ながら最適点を探る。理論を完全に理解していなくても、「Tと重みは調整対象」と押さえておけば実装に着手できる。

オンプレでのトレーニングは、一般的にPyTorchとHugging Faceのライブラリ群を土台に組むことが多い。分散学習には accelerate や DeepSpeed といったツールを併用する。処理の骨子は次のようになる。

1. 教師モデルと生徒モデルをロード
2. ソフトラベルを事前生成（またはオンザフライで蒸留）
3. KLダイバージェンス＋クロスエントロピーのカスタム蒸留ロスを定義
4. 学習ループを実行し、検証指標でチェックポイントを保存

設定の考え方としては、学習率は小さめから始め、バッチサイズはVRAMに合わせて勾配累積で実効バッチを確保し、混合精度（fp16/bf16）でメモリを節約する。生徒の微調整コストを抑えたいなら LoRA などのPEFT手法を組み合わせる。完全オフライン環境では、モデルや依存パッケージを事前に社内ミラーへ取得しておく必要がある。具体的なコマンドや引数はフレームワークのバージョンで変わるため、実装時は必ず公式ドキュメントの該当バージョンを参照すること。

トレーニング中は、複数の指標を並行して見る。学習・検証それぞれのロス、蒸留ロスとタスクロスの内訳、そして自社の評価データでのタスク精度（accuracyやF1など）だ。

早期停止（early stopping）の判断は、検証ロスが下げ止まり、上昇に転じる手前で止めるのが基本になる。上昇は過学習の兆候だからだ。ただしロスだけを見るのは危うい。ロスが下がっていても、実際の出力サンプルを見ると品質が劣化していることがあるため、毎エポックで実タスク指標と出力例を目視する習慣をつけたい。チェックポイントは複数保持し、最終的に検証指標が最良だったものを採用する。「最後のエポックが最良とは限らない」点は、地味だが取り違えやすい。

蒸留でつまずく典型は「精度が出ない（教師とのギャップ）」と「社内データに寄りすぎる（過学習）」の2つに集約される。 先に知っておけば、その多くは設計段階で避けられる。

生徒が小さすぎる、あるいは教師が大きすぎると、生徒が知識を受け止めきれず精度が大きく落ちることがある。これは「容量ギャップ」と呼ばれる現象だ。対処の選択肢は複数ある。①生徒のサイズを一段上げる。②タスクを絞り、汎用性を諦めて特化させる。③中間サイズのモデルを挟む段階的蒸留（ティーチャーアシスタント）を使う。④蒸留データを増やす、または質を上げる。⑤出力だけでなく中間層の特徴も合わせる手法を取り入れる。

重要なのは、闇雲に手を打つ前に「どのタスクで」精度が落ちているかを評価データで切り分けることだ。全タスクが一律に劣化しているのか、特定タスクだけが落ちているのかで、有効な打ち手はまったく変わってくる。

限られた社内データに寄せすぎると、訓練データには強いが、少し違う入力で崩れるモデルになる。これが過学習だ。兆候としては、検証ロスの上昇や、訓練データにない言い回しでの精度低下が現れる。

回避策は、①データの多様性を確保する（実業務の入力分布を幅広く網羅する）、②正則化を効かせる（dropout、weight decay、early stopping）、③汎用データと社内データを混ぜて学習し、基礎的な言語能力を保持する、④定期的に再評価し、必要なら再学習する、といったものだ。本番投入後も、入力傾向の変化で精度が落ちる「ドリフト」を監視する。最後に運用面の要点を一つ。蒸留モデルは作って終わりではなく、評価データの更新と再蒸留を回し続ける前提で体制を組むことが、長く使えるオンプレAIの条件になる。