ローカルLLMは手元でモデルを動かしデータを外に出しません
ローカルLLMとは、組織が自社のサーバーや端末にモデルをインストールして動かすLLMです。ChatGPTのようなクラウドLLMは、入力をインターネット越しに事業者のサーバーへ送り、そこで処理した結果を返します。両者の違いは「モデルを動かす場所」と「データが流れる先」にあります（AIMultiple）。
この違いが効くのは、扱うデータが機微なときです。クラウドLLMは多くが従量課金で、使うほど費用が積み上がり、機密データを外部に送ることにともなうリスクや、特定事業者への依存も生まれます。ローカルLLMの強みは、データと処理を自社の管理下に置き、機密情報を組織の外に出さずに済む点です。データ保護規制や社内のセキュリティ方針への準拠を、構造として担保しやすくなります。
つまりローカルLLMは、性能を競うための選択肢というより、「外に出せないデータでAIを使う」ための選択肢です。ここを取り違えると、判断を誤ります。
データ主権と規制が導入判断の起点になりました
規制のある業界でAIを導入するとき、難しいのは技術ではなく、法的な説明責任と監査の負担です。要点は「データがどこへ行き、その移送が認可されていたか」に尽きます。実装がどれだけ洗練されていても、規制対象のデータを外部のAPIへ送れば違反になりえます（TrueFoundry）。
- 医療（米国HIPAA）: 保護対象の医療情報を扱う事業者には事前の契約（BAA）が必要で、一般公開のAPIは既定でその対象外のことが多く、契約なしに送れば違反になりえます。
- 個人データ（EU GDPR）: EU居住者の個人データを域外のAI基盤へ送るには承認された移転手続きが要り、制裁金は全世界売上高の最大4%に達します。
こうした要件のもとでは、データを企業の境界内に留める配置が現実解になります。日本でも同じ動きが起きています。NTTは2025年10月、純国産LLM「tsuzumi 2」の提供を始めました。1GPUで推論できる軽量モデルで、オンプレミスやプライベートクラウドでの運用と機密情報の取り扱いを特徴に掲げています（NTT）。東京通信大学は「学生・教職員のデータを学内に留める」要件から、クラウドに依存しない国産LLMを核に学内基盤を整えています。政府も、共通の生成AI環境「源内」で試用する国産LLMを2026年3月に選定し、国内開発かつガバメントクラウド上で動くことを要件にしました（Impress Watch）。データを外に出さないことが、選定の起点になっています。
総務省の令和7年版情報通信白書によると、生成AIを活用する方針の日本企業は2024年度で49.7%。前年の42.7%から増えています。関心は高まる一方で、どのデータをどこで扱うかの設計は、これから各社が向き合う論点です。
ツールと量子化で普通のPCでも動きます
ローカルLLMは、専用の大規模設備がなくても動かせる裾野が広がっています。中心にあるのが推論エンジンと量子化です。
- llama.cpp: 依存関係のないC/C++実装で、幅広いハードウェアでの推論を目標にします。Apple SiliconのMetal、NVIDIAのCUDA、AMDなどに対応し、モデルはGGUFという単一ファイル形式で扱います（llama.cpp）。
- Ollama / LM Studio: llama.cppを土台に、モデルの取得・実行・API提供を簡単にするツールです。LM Studioはネット接続なしでも動き、OpenAI互換のエンドポイントも出せます（Ollama / LM Studio）。
- vLLM: 複数ユーザーへ高速に配信するためのサービング基盤で、KVキャッシュを効率化するPagedAttentionを備えます（vLLM）。
量子化は、モデルの重みをFP16（パラメータあたり2バイト）から4bitや8bitへ圧縮し、必要なメモリを減らす技術です。動かせるモデルには、Meta のLlama、Google のGemma、Alibaba のQwen、Mistral などのオープンウェイトモデルがあり、規模を選べます。必要なメモリの目安は次のとおりです。
| モデル規模 | FP16の重み | INT4量子化の重み | 動かす環境の目安 |
|---|---|---|---|
| 7〜8B | 約14〜16GB | 約6〜7GB | RTX 4090（24GB）や統合メモリのMac |
| 14〜32B | 約28〜64GB | 約10〜24GB | RTX 4090／5090（24〜32GB） |
| 70B | 約140〜168GB | 約46GB | L40S 48GB・A100 80GB級 |
| 405B〜671B | 数百GB以上 | 数百GB規模 | 複数GPUやMac Studioクラスタ（単機では困難） |
実運用では、重みに加えてKVキャッシュなどが乗るため、重みの1.3〜1.5倍のメモリを見込むのが安全です。量子化による品質の劣化は、INT8ならほぼ無視でき、INT4でも多くの場合わずか（複数の指標で1〜3%程度）で、対話用途では体感しにくい水準です。ただしINT2やINT3まで下げると劣化が目立ち、本番には向きません（Spheron Network）。
限界を誇張せずに直視する
手元で動く手軽さの裏に、越えられない制約があります。見落とすと、稼働後にGPUの追加投資や再設計を迫られます。
まず引っかかるのが規模の壁です。数千億から兆パラメータ級の最上位モデルは、24〜32GBの消費者向けGPU1枚では動きません。量子化しても数百GB規模のメモリが要り、複数GPUや高価な構成が必要になります。最高性能を求めるほど、ローカルの土俵から外れます。
同時利用にも弱さがあります。1台のマシンは1人で使う分には十分でも、アクセスが重なると性能が急落します。速度はハード構成に左右されますが、ローカルはおおむね毎秒15〜30トークン、クラウドの同等モデルは40〜80以上とされ、チームや本番配信ではクラウドが容易にスケールします（Sovereign Systems AI）。
そしてもう一つ、運用を自社で背負う点があります。モデルの更新、量子化、監視、障害対応を自前で回す必要があります。クラウドAPIなら事業者が担う部分を、社内の体制で引き受けることになります。
費用の判断とハイブリッドという現実解
ローカルは固定資産、クラウドは従量課金です。どちらが安いかは、使い方で逆転します。
軽い利用（1日あたり数十リクエスト規模）では、クラウドAPIのほうがローカルより大幅に安く済みます。ローカルが経済的に見合うのは、GPUを高い稼働率で使い続ける重いワークロードに限られ、損益分岐はおおむね半年から1年半とされます。カーネギーメロン大学の費用便益分析でも、GPUが遊べばAPIが安く、6〜8割以上の稼働で初めて自己ホストが有利になると示されています。
そこで有力なのが、両者を組み合わせるハイブリッドです。機微なデータを扱う処理や日常の高頻度な推論は手元のオープンモデルで受け、難易度の高い一部だけをクラウドの最上位モデルへ回します。こうすると、クラウドAPIの費用を抑えつつ、必要なときに最高性能へ手を伸ばせます（Sovereign Systems AI）。「全部ローカル」でも「全部クラウド」でもなく、データの機微さと負荷で振り分けるのが現実的です。
導入判断は「何を外に出せないか」から始めます
ローカルLLMを検討するなら、最初に決めるのはモデルでもGPUでもありません。「どのデータを外に出せないか」です。ここが決まると、ローカルで扱う範囲、クラウドに任せる範囲、そのあいだの設計が定まります。
社内文書を扱う場合は、検索拡張生成（RAG）で自社データをモデルに参照させる構成が一般的です。ただしRAGは、アクセス制御の不備による情報漏えいや、複数部門でデータストアを共有した際の混線といったリスクを持ちます。OWASPは、権限を意識したデータの分離や、検索操作の改ざん不能なログを推奨しています（OWASP LLM08）。ローカルに置けば安全、という単純な話ではなく、権限設計とガバナンスをセットで組む必要があります。
端末やエッジ機器の上でモデルを動かす発想は、ロボットや現場機器へ基盤モデルを載せるフィジカルAIとも地続きです。私たちは生成AIを開発プロセスに組み込む立場から、「どこまでを手元で閉じ、どこからクラウドに委ねるか」という設計を、費用と運用体制まで含めて一緒に決めます。データを外に出せない制約があるほど、AIをあきらめる前に取れる選択肢は残っています。まずは対象業務と、外に出せないデータの範囲を洗い出してください。セキュアなAI活用のご相談は、お問い合わせからお聞かせください。基盤モデルを業務に組み込む考え方は、AIネイティブ開発でも整理しています。