ローカルLLMは業務で使えるのか｜社内に置く意味がある条件【2026年版】

「社内の情報をクラウドのAIに入れるのが怖いので、ローカルLLM（自社サーバーやPCで動かす大規模言語モデル）に切り替えたい」——2026年に入ってから、この相談が明確に増えました。ただ、実際に検討を進めると「思っていたのと違う」という結論になるケースも同じくらい多いのが実情です。

結論｜ローカルLLMが業務で「使える」のは3条件が揃うときだけ

先に結論を書きます。2026年8月現在、ローカルLLMは「試すレベル」ではなく「業務で実用に耐えるレベル」に届いています。OpenAIの gpt-oss-20b は Apache 2.0 ライセンスで公開され、公式に「16GBのメモリで動作する」と明記されています（Ollama公式のgpt-ossページ）。つまり、ハイエンドなノートPC1台でも動く水準まで来ました。

ただし「動く」と「業務で使える」は別の話です。実務で見ていると、ローカルLLMが正解になるのは次の3つが同時に成り立つときだけです。

1. データを外に出せない明確な理由がある（契約上の制約、業法上の要請、顧客との個別合意など。「なんとなく不安」は理由になりません）
2. 用途が狭く、求める精度が最高水準でなくてよい（社内文書の要約・分類・下書き生成など）
3. GPU・電力・保守・モデル更新を回し続ける担当者と予算がある

逆に言えば、この3つのどれかが欠けている場合、クラウドAIの方が総合的に有利になることがほとんどです。特に3つ目を軽く見た結果、半年後に「誰もメンテしていないサーバー」が社内に1台増えるだけ、という失敗をよく見ます。

2026年8月時点で候補になるオープンウェイトモデル

この分野はモデルの入れ替わりが非常に速いため、以下はすべて2026年8月8日時点で各社の公式ページ・公式リポジトリで存在と提供を確認した情報です。数か月後には前提が変わっている可能性があります。導入検討の際は必ずご自身で最新の公式情報をご確認ください。

ライセンスは「オープン」でも中身が違う

ここが実務で最も見落とされる点です。「オープンウェイト＝自由に商用利用できる」ではありません。

gpt-oss と Qwen3 は Apache 2.0 で、コピーレフトの制約なく商用利用できます。一方 Gemma は Gemma利用規約に基づく提供で、禁止用途ポリシーへの準拠、再配布時に規約の写しを添付する義務、改変ファイルの明示などが課されます（Google公式のGemma利用規約）。Llama も Llama Community License という独自ライセンスで、月間アクティブユーザー数のしきい値や表示要件があります。

自社利用にとどまるなら実害が出にくい条項も、外部に提供するサービスへ組み込むと話が変わります。顧客向けプロダクトに載せる場合は、モデルを選ぶ前に法務チェックを通してください。

ダウンロードサイズの実際

Ollama公式に掲載されているダウンロードサイズを挙げると、gpt-oss:20b が14GB、gpt-oss:120b が65GB、gemma4:12b が7.6GB、gemma4:26b が18GB、gemma4:31b が20GB です。ディスク容量としては現実的に見えますが、ダウンロードサイズと、快適に動かすために必要なVRAM・実効メモリは別物です。同時に何人が使うか、どれくらいの長さの文書を投げるかで必要量は変わります。公式が明記していない必要VRAMを断定している解説記事は、根拠を確認したうえで読んでください。

「社内に置けば安全」は単純化しすぎ

ローカルLLMを検討する最大の動機は情報漏洩の懸念です。その気持ちはよく分かりますし、実際にAI利用時の情報漏洩を防ぐための対策は、どの企業でも一度は整理しておくべきテーマです。ただ、「社内に置けば安全」という一言でまとめてしまうと、判断を誤ります。

まず、クラウド側の前提を正確に把握する必要があります。OpenAIの公式ドキュメントには「APIに送信されたデータは、明示的にオプトインしない限りモデルの学習には使われない」と明記されています。不正利用監視のログは最大30日保持され、条件を満たす顧客はゼロデータ保持（Zero Data Retention）の申請も可能です（OpenAI公式のデータ利用ガイド）。つまり「クラウドに入れた瞬間に学習に使われる」というよく聞く前提は、法人向けAPIに関しては正確ではありません。

一方、ローカルに置いたからといってリスクがゼロになるわけでもありません。実務で問題になるのはむしろ次のような点です。

• アクセス権限の設計：社内サーバーに全社の文書を投入したAIは、権限のない社員に他部署の情報を答えてしまう。クラウドかローカルかとは無関係の設計問題です
• ログと監査：誰が何を聞いたかを記録・監査する仕組みは、自前で構築しないと存在しません
• 端末に置いた場合の持ち出し：ノートPC上で動かす構成にすると、モデルもデータも端末とともに社外へ出ます
• 脆弱性対応：推論サーバーやWeb UIの更新を止めた瞬間、社内に穴の空いたサーバーが残ります

整理すると、ローカルLLMが解決するのは「データが自社の管理外のネットワークに出ること」だけです。それ以外のリスクは、クラウドでもローカルでも自分たちで設計する必要があります。

見落とされやすい5つの運用コスト

「クラウドAPIは従量課金だから、社内に置けば安くなるはず」——この期待が最も外れやすいところです。実際にかかるものを正直に並べます。

1. GPUの初期投資

公式情報のとおり、gpt-oss-20b クラスなら16GBメモリで動きます。ここは以前より格段に敷居が下がりました。一方、120bクラスを快適に動かそうとすると単一80GB GPUが前提になります。この差は金額にして数十倍のレンジです。「どのモデルを使うか」を決めないままGPUを買うと、ほぼ確実に過剰投資か性能不足のどちらかになります。

2. 電力

意外と語られないのが電気代です。全国家庭電気製品公正取引協議会の電力量料金の目安単価は31円/kWh（2022年7月改定）です。仮に消費電力400Wの推論サーバーを想定すると、1日8時間・月20日稼働で約64kWh、電気代にして月およそ2,000円。24時間常時稼働させると月288kWhで、およそ8,900円になります。

この試算はあくまで家庭用の目安単価を使った概算で、業務用の契約単価や空調・電源設備の負担は含みません。金額そのものより、「使っていない時間帯も電気を食う」という性質が重要です。クラウドAPIが使った分だけの課金なのに対し、自社設備は稼働率が低いほど単価が跳ね上がります。月に数十回しか使わない用途なら、ローカルにする経済合理性はまずありません。

3. 保守と可用性

OSとドライバの更新、推論サーバーの脆弱性対応、ディスク逼迫、障害時の復旧。クラウドAPIなら提供元が担っていた部分が、そのまま自社の仕事になります。「業務で使う」と決めた時点で、止まったときに誰が何分以内に直すのかを決めておく必要があります。

4. モデル更新への追随

これが最も過小評価されているコストです。オープンウェイトモデルの世代交代は速く、半年から1年で有力な選択肢が入れ替わります。クラウドAPIならモデル名を差し替えるだけで済むところが、ローカル運用では新モデルの検証、量子化形式の選定、プロンプトの再調整、場合によってはハードウェアの見直しまで発生します。「一度組んだら終わり」ではなく、継続的な運用業務が1つ増えると考えてください。

5. 精度差という見えないコスト

一般論として、同時点のフロンティアモデル（クラウドで提供される最上位モデル）と、単一GPUで動くサイズのローカルモデルの間には性能差があります。ここで具体的なベンチマーク数値を並べることもできますが、測定条件と量子化設定で結果が大きく変わるため、他社の比較値を鵜呑みにすることはおすすめしません。

実務での判断基準はもっと単純です。自社の実データで、自社の業務プロンプトを使って、両方に同じ仕事をさせて比べてください。20〜30件も試せば、その業務で使い物になるかどうかは判断できます。精度が落ちた分を人の確認作業で埋めるなら、それは人件費という形の運用コストです。

ローカルLLMが向く業務・クラウドで足りる業務

ここまで読んで「自社はどちらなのか判断がつかない」と感じられたなら、それが普通の反応だと思います。私たちも、独自AIの構築をご相談いただいたとき、まずこの線引きから一緒に整理しています。記事の途中で恐縮ですが、こうしたご相談も承っておりますので、よろしければ合わせてご覧いただけたら嬉しいです。

導入前に確認したい5つのチェックリスト

1. 外に出せない理由を文書で説明できるか：契約書の条項、業法、顧客との合意——具体的な根拠を1行で書けなければ、クラウドで足ります
2. 使う業務と想定件数を数字で出せるか：月何件の処理か。稼働率が低ければ設備投資は回収できません
3. 実データで精度比較をしたか：導入を決める前に、クラウドとローカルで同じ仕事を20〜30件やらせて比べる
4. ライセンスを法務が確認したか：特に顧客向けに提供する場合。Apache 2.0とGemma利用規約・Llama Community Licenseでは条件が違います
5. 1年後に誰がモデルを入れ替えるか決まっているか：担当者名が出てこないなら、その仕組みは1年後に陳腐化して放置されます

現実的な進め方｜ハイブリッドから始める

実務でうまくいっているのは、全社をローカルに寄せる方式ではなく、データの機微度で経路を分けるハイブリッド構成です。手順としては次の3段階が現実的です。

ステップ1：データを3段階に分ける。「外に出しても問題ないもの」「契約上・法令上出せないもの」「判断がつかないもの」に社内文書を仕分けます。この作業だけで、ローカルLLMが必要な範囲は想像よりずっと狭いことが分かるはずです。

ステップ2：狭い範囲で小さく検証する。1つの業務、1つの部署に絞って、まずは16GBメモリで動くサイズのモデルから試します。いきなり高価なGPUを買う必要はありません。ここで「使い物になるか」を実データで確かめます。

ステップ3：出せるデータはクラウドのまま残す。すべてをローカルに寄せると、精度と運用負荷の両方で損をします。出せるデータは高性能なクラウドモデルに任せ、出せないデータだけをローカルで処理する——この線引きが、コストと精度の両方で最も合理的です。

Mihataでは、こうした社内向けAIの構築を業務ごとの要件に合わせてご支援しています。ローカルとクラウドのどちらが適しているかの見極めから入りますので、「まだ決めきれていない」段階でも問題ありません。独自AI開発サポートのサービス内容もあわせてご覧ください。

まとめ

ローカルLLMは2026年時点で確実に実用段階に入りました。ただし「社内に置けば安全で安い」という単純な図式は成り立ちません。安全性はアクセス権限とログ設計の問題であり、コストは稼働率とモデル更新への追随で決まります。

判断の起点は「外に出せない理由が説明できるか」の一点です。そこが曖昧なまま設備を買うと、精度も低く誰もメンテしないサーバーが残ります。逆に理由が明確なら、狭い範囲から小さく始める価値は十分にあります。