オンプレLLMは、自社が管理するサーバーで大規模言語モデル（LLM）を動かす使い方だ。社内のデータセンターに置くこともあれば、自社だけが使える閉じたクラウドの環境に置くこともある。ChatGPTやClaudeのような外部のサービスを使う場合と違い、入力した文章が社外のAPIに出ていかない。ローカルLLMという言葉もほぼ同じ意味で使われる。ここでは、手元のPCで動かす場合をローカルLLM、社内のサーバーで業務の仕組みとして動かす場合をオンプレLLMと呼び分ける。
この使い方が現実の選択肢になったのは、性能の高いモデルが重みごと公開されるようになったからだ。OpenAIはgpt-ossという2つのモデルをApache 2.0で公開し、大きいほうのgpt-oss-120bはモデルカードで80GBのGPU 1枚に収まると書いている。
ここでは、AIの導入を検討している会社の担当者に向けて、クラウドのAPIとの違い、オンプレLLMが向く業務と向かない業務、動かすのに必要なもの、ライセンスと安全の確認点、社内での進め方と外部に頼むときの確認点を順に書く。外部のエンジニアが現場に入ってAIを作る働き方そのものはFDEとはにまとめてある。
オンプレLLMとクラウドのAPIの違い
違いは性能よりも、データの置き場所と、運用を誰が受け持つかにある。私の見方では、次の表の5つの観点で比べると、社内での議論がまとまりやすい。
| 観点 | オンプレLLM | クラウドのAPI |
|---|---|---|
| データの置き場所 | 自社のサーバーの中で処理が終わる | 提供会社のサーバーに送って処理する |
| 使えるモデル | 重みが公開されたモデルに限られる | 提供会社の最新のモデルを使える |
| 費用の形 | GPUの購入や借用、電気代、保守の人件費が先にかかる | 使った量に応じて払う |
| 運用の手間 | モデルの更新、監視、障害の対応を自社で受け持つ | 提供会社が受け持つ |
| 社内の審査 | 社外にデータを出さない分、確認する項目が減る | 契約と設定の確認が要る |
クラウドのAPIを使う場合も、法人向けの契約と設定で入力の扱いを確かめられる。Claudeを例にした法人向けの扱いはClaudeのセキュリティに書いた。社外に出すこと自体が規程で禁じられているのか、設定と契約で足りるのかを先に確かめないと、オンプレにする必要がないのに大きな投資をすることになる。
オンプレLLMが向く業務と向かない業務
私の見方では、オンプレLLMが向くのは、扱う文書を社外に出せない業務で、かつ求める答えの形がある程度決まっている業務だ。
| 向く業務 | 理由 |
|---|---|
| 設計書・図面・研究資料の検索と要約 | 社外に出せない文書が多く、答えの根拠が社内の文書にある |
| 診療記録・顧客情報を含む文書の下書き | 個人情報を外部に送らずに済む |
| 工場や拠点など、ネットにつながらない場所での利用 | 外部との通信を前提にできない |
| 決まった書式への分類・抽出 | 小さいモデルでも精度を出しやすい |
| 向かない業務 | 理由 |
|---|---|
| 幅広い知識や高度な推論を毎回求める業務 | 最新の大きいモデルとの差が出やすい |
| 使う量が少なく、波が大きい業務 | GPUを持つ費用に対して使う量が見合わない |
| 社内にGPUとモデルを保守する人がいない業務 | 更新と障害の対応が止まる |
社内の文書を検索させて答えさせる使い方は、オンプレでもクラウドでも作り方の中心は同じで、権限と検索の精度が決め手になる。手順はRAG構築の進め方に書いた。
動かすために必要なもの
オンプレLLMは、モデル、GPU、推論サーバーの3つがそろって動く。
1つ目のモデルは、重みが公開されたものから選ぶ。OpenAIのgpt-ossは2種類あり、gpt-oss-120bは全体で117B（1,170億）のパラメータのうち一度に使うのは5.1Bで、80GBのGPU 1枚（NVIDIA H100やAMD MI300Xなど）に収まるとされる。gpt-oss-20bは21Bのパラメータで、16GBのメモリで動き、モデルカードは低い遅延や手元・特定用途での利用を想定に挙げている。
2つ目のGPUは、モデルの大きさと、同時に何人が使うかで決まる。モデルカードに書かれているのは1台で動くための目安で、社内の数百人が同時に使う前提の数字ではない。私の見方では、GPUを買う前に、借りたGPUで業務の質問を流して、応答の速さと同時に使える人数を測っておくべきだ。
3つ目の推論サーバーは、モデルを読み込んで社内のアプリから呼べるようにするソフトだ。vLLMは公式の説明で「LLMの推論とサービングのための、速く使いやすいライブラリ」とされ、OpenAI互換のAPIサーバーを持つ。OpenAI互換で立てておくと、クラウドのAPI向けに作ったアプリを、呼び先を変えるだけで試せる。手元のPCで試すときはOllamaがよく使われる。
モデルを入れ替えたときに精度が下がっていないかは、業務の質問と正解の組で確かめる。その作り方はLLMの評価（Eval）の作り方に書いた。
ライセンスと安全で確かめること
オープンなモデルでも、商用での使い方はライセンスで決まる。gpt-ossはApache 2.0で、モデルカードはコピーレフトの制約や特許のリスクなしに使えると書いている。一方、Llama 3.1のライセンスには、リリース日の前月に月間アクティブユーザーが7億人を超えていた会社は、Metaに別途ライセンスを申請し、許諾を得るまで権利を使えないという条項がある。多くの日本企業には当たらない条件だが、ライセンスごとに条件が違うこと自体は押さえておく必要がある。
安全の面では、外部のAPIにデータを送るリスクの代わりに、モデルそのものの出どころが問題になる。OWASPのLLMのリスク一覧（LLM03:2025 Supply Chain）は、モデルは中身を静的に調べにくい「バイナリのブラックボックス」だとし、改ざんしたモデルを公開して誤情報を広める例を挙げている。対策として勧めているのは、出どころを確かめられるモデルだけを使い、署名やファイルのハッシュで確かめることだ。ほかのリスクはOWASP Top 10 for LLMにまとめた。
推論サーバーの公開範囲も確かめる。Ollamaは標準では127.0.0.1の11434番ポートで待ち受け、外から呼べるようにするにはOLLAMA_HOSTで待ち受ける場所を変える。手元で試すときは自分のPCからしか呼べないが、社内のサーバーで公開するときは、認証と通信の制限を別に用意する必要がある。
| 確かめること | 見る資料 |
|---|---|
| 商用で使えるか、利用者数などの条件はないか | モデルのライセンス本文 |
| 出どころを確かめられるか | 配布元、ファイルのハッシュ |
| 推論サーバーを誰が呼べるか | 待ち受けの設定、認証、ネットワークの制限 |
| 入力と出力のログをどこに残すか | 社内の情報管理の規程 |
社内での進め方
私の見方では、オンプレLLMの導入は、GPUを買うところからではなく、業務を1つ決めるところから始めるのがよい。順番は次のとおりだ。
| 段階 | やること | 決める人 |
|---|---|---|
| 1. 業務を決める | 社外に出せない文書を使う業務を1つ選び、成功とみなす数字を決める | 業務の責任者 |
| 2. 出せない理由を確かめる | クラウドのAPIの契約と設定では足りない理由を、規程と照らして書き出す | 情報システム・法務 |
| 3. 借りたGPUで試す | 小さいモデルから順に、業務の質問と正解の組で精度と速さを測る | 開発の担当 |
| 4. 構成を決める | モデル、GPUの台数、推論サーバー、認証、ログの置き場所を決める | 情報システム |
| 5. 運用を決める | モデルの更新、監視、障害の連絡先を決めてから公開する | 情報システム・業務の責任者 |
2の段階で、クラウドのAPIで足りると分かることもある。その場合は、GPUとその保守に使うはずだった費用を減らせる。公開したあとの監視と更新の仕組みはLLMOpsとはに、試行から本番に進めない理由と対策はAIのPoC止まりを抜け出すに書いた。
外部に頼むときに確かめること
オンプレLLMは、モデルを動かすところまでは短い期間で作れる。難しいのは、業務で使える精度を出すことと、公開したあとも更新と監視を続けることだ。外部に頼むときは、私の見方では次の3つを聞けば、その会社が最後まで受け持てるかが分かる。
1つ目は、オンプレにする理由を一緒に確かめるかだ。最初からGPUの見積もりを出す会社より、クラウドのAPIで足りないかを先に確かめる会社のほうが、自社の費用を考えている。2つ目は、業務の質問と正解の組で精度を測る段取りがあるかだ。3つ目は、公開したあとのモデルの更新と監視を、誰がどの頻度で受け持つかが書面にあるかだ。
社内の閉じた環境でAIを作り、現場で使われるところまで受け持つ支援を検討している場合は、FDE Consultingのサービスに支援の中身と進め方を載せている。