ローカルLLMとは？クラウドとの違い・主要モデル・自社導入の判断基準

#LLM

公開日

2026.07.27

「ChatGPTのような生成AIを業務で使いたいが、社外秘の情報を外部のサービスに送るのは避けたい」。そうした要望にこたえる選択肢として、生成AIを自社の中だけで動かす「ローカルLLM」があります。

ローカルLLMは、文章を作る生成AI（大規模言語モデル＝LLM）を、外部のクラウドサービスに頼らず、自社のサーバーや手元のパソコンで動かすしくみです。データを外に出さない安全性と、利用が拡大してもコストを自社で管理できる点が評価される一方、動かすための機材、たとえばGPU（AIの計算に使う高性能な装置）などの準備や運用の手間もかかります。

この記事では、ローカルLLMの基本とクラウド型（外部のクラウドサービスを利用する形）との違い、導入のメリットと注意点、動かせる主なモデルと必要な機材、そして「自社で運用すべきか」を見極める判断軸までを、2026年6月時点の情報をもとに解説します。

※デロイトトーマツミック経済研究所「LLM（大規模言語モデル）を自律的に連携させ非定型業務を自動化するAIエージェントソリューションサービスの市場動向 2025年度版
※富士キメラ総研「2026 生成AI／AIエージェントで飛躍するAI市場総調査」＜2024年度実績・サードパーティ対話型生成AIアプリケーション・ベンダーシェア＞

ローカルLLMの基本とクラウド型との違い

ローカルLLMは、LLMを外部のクラウドに頼らず、自社のサーバーや手元の端末で動かすしくみです。クラウド型と大きく異なるのは、データと処理を自社の管理下に置く点です。

ローカルLLMのしくみと配置場所

ローカルLLMとは、公開されたモデルの「重み（パラメータ）」を自社の環境に取り込み、その中で文章の生成まで完結させる形態です。重みとは、モデルが学習した結果を保存したファイルを指します。入力した文章や社内データが外部に送られないため、情報が組織の中にとどめられます。

一方、クラウドLLMは、ChatGPTのように外部の基盤へデータを送って結果を受け取る形態です。手元に何も置かず、最新モデルをそのまま使える手軽さがあります。ローカルLLMは、この手軽さと引き換えに、データを外に出さずに済む安全性と、運用を自社で抱える負担の両方を持つ方式です。

動かす場所は、使う規模によって次のように分かれます。小さく試すところから全社利用まで、目的に応じて段階的に広げられます。

全社で使う：オンプレミス（自社内に設置したサーバー）
個人で検証する：業務用パソコン
現場の機器に組み込む：エッジデバイス（現場に置く小型の機器）

クラウド型との違い（比較表）

両者の違いを観点ごとに整理しました。微調整（ファインチューニング）とは、既存モデルに自社データを追加学習させ、用途に合わせて調整することです。

観点	ローカルLLM	クラウド型
データの所在	自社環境内で完結	外部基盤へ送信
コスト構造	初期投資（GPU等）＋運用費	利用量に応じた従量課金
カスタマイズ	重みを直接調整・微調整しやすい	提供範囲内での調整が中心
運用負荷	自社でハードと運用を担う	提供元が運用を担う
性能・スケール	自社のハード性能が上限	大規模なインフラを利用できる

どちらかが優れているわけではなく、データの機密性・利用量・運用体制によって適した形が変わります。使い分けの目安は次のとおりです。

クラウド型が向く：手軽さと最新モデルを重視する／利用が小規模・散発的
ローカルが向く：データを社外に出せない／大量に使うのでコストを抑えたい

二者択一にせず、社外秘の文書は自社環境、一般的な調べものはクラウド型というように、データの機密度で振り分ける使い方も考えられます。扱う情報を「外に出してよいもの」と「出せないもの」に仕分けるところから始めると、どの方式をどの業務に充てるかを決めやすくなります。

注目される背景

ローカルLLMが現実的になった背景には、無料で公開される高性能なモデル（オープンウェイトモデル）の存在があります。かつて大規模なモデルを動かせるのは一部の研究機関に限られていましたが、性能の高いモデルが誰でも入手でき、手元の機材で動かせるようになってきました。あわせて、データを国内や社内にとどめたいという要請を背景に、外部に送らず自社で処理する形が選択肢として意識されています。

たとえばOpenAIは2025年8月、無料で使えるモデル「gpt-oss」を公開しました。小さいモデルは高性能なPC相当のメモリで、大きいモデルも高性能GPUが1枚あれば動く規模とされています。商用利用も認められている点が特徴です。

こうしたモデルの利用は世界的に広がっています。投資会社a16zとOpenRouterの調査では、2025年の一部の週で、中国製のオープンモデルがAI利用の約3割を占めたと報告されています。無料で高性能なモデルが、提供元を問わず実際の利用に入ってきていることを示す動きです。

企業の選び方も変わってきました。同社が大企業のIT責任者100社規模に行った調査では、性能とコストの両面を最適化するために複数のモデルを使い分ける動きが広がり、調達でも評価やデータの扱い、コストを慎重に見極めるようになったとされています。モデルの種類だけでなく、どこにデータを置きいくらかかるかが選定の軸になり、ローカルも比較対象に入りやすくなっています。

出典：OpenAI「Introducing gpt-oss」（2025年8月）／a16z「Asserting American Leadership in Open Source AI」（2026年）／a16z「How 100 Enterprise CIOs Are Building and Buying Gen AI in 2025」（2025年）

ローカルLLMを導入するメリット

企業がローカルLLMに注目する理由は、大きく次の3点です。いずれも、クラウド型では満たしにくい要件にこたえるものです。以下で実務の視点から確認します。

安全性：データを社外に出さずに使える
コスト：使用量が拡大しても従量課金が膨らまない
柔軟性：自社の業務やデータに合わせて調整しやすい

データを社外に出さない安全性

主な利点は、入力したデータが組織の外に出ないことです。機密情報や個人情報、設計データなどを、外部に送らず自社の中で処理できます。特にデータの扱いに厳しい業種では、これが導入の前提になります。

規制の厳しい業種：金融・医療・公共・製造など
データの所在要件：海外にデータを渡さない構成を組める（データレジデンシー＝データの保存場所を指定する考え方への対応）

インターネットに接続しない閉じた環境でも動かせるため、外部との通信を遮断したい現場にも適します。利用の記録も自社内に残せるため、監査やコンプライアンスの観点で説明しやすくなります。

コストを自社で管理できる

クラウド型は使った分だけ支払う従量課金です。ローカルは初期に設備費がかかる代わりに、使用量が拡大しても1件ごとの追加料金は発生しません。

ローカルが有利：常時・大量に使う用途（追加課金がない）
クラウドが有利：利用が散発的（設備投資が要らない）

大量に使うならローカルが総額で有利になりやすく、利用が少なければ設備費を回収できず割高になります。クラウド型の料金改定に左右されにくく、費用を自社で見通しやすい点も、予算を立てるうえでの利点です。

自社の業務に合わせやすい

重みを自社で管理するため、社内の文書やデータに合わせた調整がしやすくなります。代表的な方法は2つです。

RAG（検索拡張生成）：社内文書を検索し、その内容を根拠に回答させる。社内規程やマニュアルを参照させたいときに使う
微調整（ファインチューニング）：モデル自体に追加学習させ、出力の表現や形式まで合わせる

社内文書を根拠に答えさせたいならRAG、文体や形式まで覚えさせたいなら微調整、というように使い分けます。自社の専門用語や独自の業務フローに合わせ込めるため、汎用のサービスでは精度が出にくい領域でも調整の余地があります。

導入前に押さえる注意点

メリットの裏側には、見落としやすい注意点もあります。導入前に次の3点を確認しておくと、後からの手戻りを防げます。

社内の権限管理：データを外に出さなくても、社内の設定が甘いと情報は漏れる
損益分岐：小規模な利用では設備費を回収できず割高になりやすい
運用の責任：更新や障害対応をすべて自社で担う

社内の認証・権限管理

データを外部に出さないことは、情報漏えいリスクをゼロにすることではありません。社内の認証や権限管理が甘ければ、アクセスすべきでない社員が機密情報を見られる状態が残ります。

外部送信を止めることと、社内の権限設計を整えることは別の課題です。RAGで社内文書を連携する場合は、文書ごとのアクセス権を踏まえた設計が欠かせません。具体的には、部署ごとに参照できる文書を分ける、退職者のアカウントを速やかに止める、といった基本的な管理が前提になります。

コストの損益分岐

設備費を回収できるかは、利用量によって決まります。総額を見積もるときは、次の費用をまとめて月額に換算て考えます。

初期費用：GPUなどの機材
運用費：電力・設置・保守
人件費：選定・更新・障害対応にあたる担当者

従量課金の利用料が一定額を超え、かつ常時使う見込みなら、ローカルとの比較に入る段階です。利用が一部にとどまるうちは、クラウド型のほうが総額を抑えやすくなります。

判断の目安として、月々の利用料が安定して高水準で続く見通しがあれば、設備投資の回収が視野に入ります。逆に、月によって利用量が大きく変わる場合は、固定費が重荷になりやすいため従量課金のほうが無難です。初期費用の重さが気になる場合は、まず小規模なGPUで始め、利用の伸びに応じて増強する進め方もあります。

導入後の運用責任

クラウド型と違い、導入後の保守は自社の責任になります。次のような作業が継続的に発生します。

モデルやライブラリ（プログラムの部品）の更新
脆弱性（セキュリティ上の弱点）への対応
利用ログの監視とアクセス権の管理

これらは生成AIのガバナンス（全社的な管理・統制）として、技術面と同じ重みで体制を整える必要があります。

導入でつまずきやすい点と対策は次のとおりです。

目的が曖昧なまま機材を用意する：先に解決したい業務と要件を決める
全社へ一斉導入して使われない：小さく試して効果を確かめてから広げる
権限設計を後回しにする：社内文書を扱う前にアクセス権を設計する

ローカルで動かせる主なモデル（2026年時点）

どのモデルを動かせるかは、導入時にまず気になる点です。オープンウェイトモデルとは、重みが公開され、誰でもダウンロードして自社の環境で使えるモデルを指します。

代表的なオープンウェイトモデルを、提供元・ライセンス（利用条件を定めた規約）・特徴とあわせてまとめました。表の「推論」は、複雑な問いに答えを導く処理を指します。各モデルは更新が速いため、最新版は提供元の公式情報で確認してください。

代表的なモデルと選び方

モデルと提供元	ライセンス	特徴と用途
gpt-oss（OpenAI）	Apache 2.0	推論に強い。高性能GPU1枚で動く規模。商用利用しやすい
Llama（Meta）	Llamaコミュニティライセンス	大規模なエコシステムと派生モデル。利用条件に独自の制約あり
Qwen（Alibaba）	Apache 2.0が中心	多言語・コーディングに強み。世界的に普及
Gemma（Google）	Gemma利用規約	単一GPUでも動く軽量〜中規模。文章に加え画像なども扱える版もある
DeepSeek（DeepSeek）	MIT（重み）	推論・数学・コーディング向け。効率重視の設計
Mistral（Mistral AI）	一部Apache 2.0	欧州発。軽量モデルが扱いやすい

選び方の実務的なコツは次のとおりです。

小さく始める：いきなり大規模モデルを選ばず、自社の機材で動く規模から試す
用途で選ぶ：コーディング中心か、文書処理か、多言語かで適したモデルが変わる
日本語を確かめる：多言語対応モデルを選び、実際の業務文書で日本語の品質を試す

試すときは、Ollama（手元のパソコンで生成AIを動かす無料ツール）などでまず小さいモデルを入れ、自社の代表的な業務で精度を見ます。たとえば会議の文字起こしを貼り付けて議事録に整形できるか、社内規程について質問してマニュアルどおりに答えられるかを確かめると、ベンチマークの数値だけでは分からない自社業務との相性が見えてきます。

商用利用とライセンスの確認

商用利用の可否はライセンスによって決まります。ローカルで使う場合も、製品に組み込む前に法務での確認が必要です。

自由度が高い：gpt-oss・Qwenの主要モデル（Apache 2.0）、DeepSeekの重み（MIT）。商用利用や改変がしやすい
独自条件あり：Llama（Metaコミュニティライセンス）。月間アクティブ利用者が7億を超える事業者は別途申請が必要で、「Built with Llama」の表示などの条件がつく

7億という条件に該当する企業は限られますが、利用条件が一般的なオープンソースとは異なる点は押さえておく必要があります。性能やライセンスに加えて、提供元の継続性やサポート体制、自社のセキュリティ方針との整合も選定時の確認対象です。

モデルは新しい版が次々と公開されるため、特定の版に固定せず、定期的に新しいモデルへ乗り換えられる状態にしておくと、性能の向上を取り込みやすくなります。

出典：Meta「Llama 4 Community License Agreement」（2025年）

導入に必要なもの（設備・ツール・運用体制）

ローカルLLMを自社で動かすには、設備・実行ツール・運用体制の3つが必要です。規模に応じて、求められる水準は変わります。

必要な設備（GPUとメモリ）

モデルを動かす中心になるのは、GPUのメモリ（VRAM）容量です。大きなモデルほど必要なメモリも増えます。細かい計算よりも、「動かしたいモデルの規模に見合うGPUを用意する」という考え方を押さえれば十分です。

モデルが大きいほど大容量のGPUが必要：70億パラメータ（モデルの規模を表す数）級で十数GB程度が目安
量子化で必要メモリを抑えられる：モデルを軽量化する技術。精度への影響は用途ごとに確認する
規模で機材が変わる：個人の検証は高性能PCで足りるが、複数人の本番利用は大容量GPUや複数台が必要

規模別の目安は次のとおりです。自社の利用人数と扱うモデルの大きさから、必要な機材のあたりをつけられます。

利用の規模	メモリの目安	機材の例
個人での検証・軽量モデル	十数GB程度	高性能なPC・ワークステーション
部門での利用	数十GB	サーバー向けGPU 1枚
全社・高精度を求める用途	80GB級以上	サーバー向けGPU 複数枚

実行ツール

モデルを動かすツールは目的で選びます。試す段階と本番運用で使い分けるのが基本です。

試す段階：Ollama、LM Studio（手元のPCで手軽に動かせる）
本番運用：llama.cpp、vLLM（処理性能や安定運用を重視する）

運用体制

動かした後の保守は自社で担う必要があります。導入を始めるときは、いきなり全社展開せず小さく試すのが現実的です。

小さく試す：限られた業務・少人数で、精度・速度・運用負荷を実データで確認する
段階的に広げる：試行の結果をもとに対象業務とモデル規模を決める
継続して保守する：更新・脆弱性対応・ログ監視・権限管理を続ける

運用は情報システム部門だけで完結しにくいため、現場の担当者と役割を分け、誰が更新や問い合わせ対応を担うかを決めておく必要があります。ツールを用意しても、使われ続ける工夫がなければ成果にはつながりません。利用ルールの周知や、使い方の相談先を整えることが、定着の前提になります。

ここまでが、自社でローカルLLMを運用する場合に必要な要素です。設備の調達と運用体制の確保は、実務で大きなハードルになります。データを社外に出さないという目的は譲れないが、自社でGPUを抱えて運用するところまでは踏み込みたくない、という場合には、国内で処理するマネージドサービスを使う選択肢もあります。当社が提供する法人向けの「エクサベース AI」は、データ処理を国内サーバーで行い、入力情報をモデルの学習に使わない構成で、GPT・Gemini・Claudeなど複数のモデルを管理者が選んで使えます。

自社に向くかを見極める判断軸

最後に、自社がローカルLLMを運用すべきかを見極める視点を整理します。次の5つの軸で、自社運用と別の手段のどちらに寄るかを確認します。

そもそも選択肢は、ローカルの自社運用とマネージドサービスだけではありません。社外に出せるデータであれば、クラウド型がもっとも手軽です。「そのデータを社外に出せるか」をはじめに切り分けると、検討がぶれにくくなります。

判断軸	フル自社運用が向く	別の手段が向く
データ要件	社外に一切出せない強い制約がある	国内・限定範囲で処理できれば足りる
利用量	常時・大量に処理する	利用が散発的・小規模
運用力	GPUと運用体制を社内に持てる	情シスのリソースが限られる
カスタマイズ	重みレベルの微調整が必要	既存モデル＋RAGで足りる
応答・オフライン	低遅延やオフライン動作が必須	通常のネットワーク利用で問題ない

自社運用が向くケース

次の条件が重なるほど、自社で運用する利点が大きくなります。

データを社外に一切出せない強い制約がある
常時・大量に処理し、追加課金を避けたい
GPUと運用体制、扱える技術者を社内に確保できる

たとえば、外部に出せない研究データを大量に扱う部門や、ネットワークから切り離した環境が必要な現場が当てはまります。金融機関の審査資料や、製造業の設計データなど、社外に出せない情報を日常的に大量に扱う領域が典型例です。

ただし、設備と人員の負担を回収できる利用規模かは事前に確認する必要があります。これらの条件がそろわないまま自社運用を選ぶと、負担だけが大きくなるおそれがあります。

別の手段が向くケース

一方、次のような場合は、国内処理のマネージドサービスが現実的です。

目的の中心が「データを社外・海外に出さない」ことにある
GPUの調達や日々の運用までは抱えたくない
情報システム部門のリソースが限られている

社外に出せないデータは限られた範囲で、まずは生成AIを幅広い業務で使いたい、という段階の企業にも向いています。

最新モデルへの追従や脆弱性対応を提供元に任せられるため、運用の負担を抑えながらデータの所在の要件を満たせます。判断の出発点は、技術として何ができるかではなく、自社の要件で何が譲れないかを決めることです。そのうえで、譲れない条件を最小の運用負荷で満たす手段を選びます。

3つの選択肢を整理すると、次のように比較できます。

選択肢	データの所在	手軽さ	コスト	運用負担
クラウド型	外部に送信	高い	従量課金	提供元が担う
国内マネージド	国内で処理	中程度	月額が中心	提供元中心
フル自社運用	自社内で完結	低い	初期投資＋運用費	自社で担う

迷ったときは、まずクラウド型やマネージドサービスで小さく始め、データ要件と利用量がはっきりしてから自社運用を検討する、という順序が現実的です。最初から自社運用に踏み込むより、要件を見極めながら段階的に判断するほうが、過剰な投資を避けられます。

汎用ツールで足りない部分を埋める：エクサベース AIという選択肢

ローカルLLMを検討する動機の中心にあるのは、データを社外に出さずに生成AIを業務で使いたいという点です。その目的を、自社でGPUを抱えずに満たす選択肢が、当社が提供する法人向けの「エクサベース AI」です。データを社外に出さないという要件を満たしながら、GPUの調達や運用が要らないため、自社運用のハードルを越えにくい場合の現実的な代替になります。

※2026年7月時点

エクサベース AI は、データ処理を国内サーバーで行い、入力情報をモデルの学習に使わない構成です。主な特徴は次のとおりです。

複数モデルの使い分け：GPT・Gemini・Claudeなどを管理者が用途に応じて選べる
管理機能：IPアドレス制限、利用ログ、禁止ワード登録など
セキュリティ認証：クラウドサービスとしてISMSクラウドセキュリティ認証（情報セキュリティの国際的な認証）を取得（提供元のExa Enterprise AIはISMS認証とPIMS〈個人情報保護の国際的な認証〉を取得）
定着支援：プロンプトテンプレートやAIエージェント（指示に沿って作業を自動で進めるAI）など、業務での活用を支える機能
導入から定着までの伴走：当社の専門家が、課題の特定からプロンプト作成、効果測定までを支援

当社がご支援した導入では、現場の業務に合わせてプロンプトや社内データ連携を整えるところまで伴走しています。

ローカルLLMの判断軸に当てはめると、社外にデータを出さない・複数モデルを使い分ける・社内文書をRAGで活用するという要件を、自社運用の負担なしに満たせる位置づけです。RAGで社内文書を扱う際も、権限やログをまとめて管理できるため、ローカルで自前に作り込む手間を省けます。提供開始から2年で、利用ユーザー数は10万人を超えています。

出典：エクサウィザーズ「exaBase 生成AI」サービスサイト／エクサウィザーズ「exaBase 生成AI、提供開始2年で利用ユーザー数10万人突破」（2025年7月）

導入事例：西武鉄道

西武鉄道は、車両部や建設部など6部門で、車両に関わる設備の保守・管理業務で生じる社内問い合わせ対応にエクサベース AI を導入しました。規程・マニュアル類をRAGで連携し、必要な情報をすぐに参照できる状態を整えることで、業務の効率化を図っています。高い回答精度が求められる部門では、AI開発環境「exaBase Studio」を用いたデータ連携の実証にも取り組んでいます。

出典：エクサウィザーズ「西武鉄道株式会社が『exaBase 生成AI』を導入」（2024年9月）