大企業こそローカルLLMとオンプレミス生成AIを検討すべき理由 クラウド一択にしない判断基準

なぜ大企業ほどローカル LLM の検討が必要なのか

大企業における AI ツール選定は、もはや単なる業務効率化ツールの比較では終わりません。顧客データ、設計資産、未公開の M&A 関連情報、法務文書、監査ログ、グループ会社間のデータ移転規制、海外子会社の輸出管理規制（EAR / 不正競争防止法）、閉域ネットワークとの整合性 ── 関係者と制約が一気に増えるからです。

クラウド型生成 AI の利便性は確かに高い一方で、すべての業務に同じ基盤を当てるのは危険です。「外部通信を前提とするのか、自社境界内に閉じるのか」で、データガバナンス設計も事故時の説明責任もまったく変わります。クラウドベンダーが「学習に使わない」と明記していても、社内規程上「外部通信を伴う処理」自体が禁止されている業務はそれだけで NG。

事故後に発生するコストは想像以上に大きい

情報漏えいが起きた場合、技術的な復旧だけでは終わりません。直接的なコストとして、顧客通知・規制当局対応・外部監査受入れ・社内再発防止策の策定・経営会議への報告・場合によっては取引先への通知まで発生します。間接的には、ブランド毀損・取引機会の損失・株価への影響まで波及します。

米 IBM の年次レポート「Cost of a Data Breach」では、データ侵害 1 件あたりの平均総コストは 446 万ドル（2023 年）。日本企業に限ってもインシデント単価は数億円規模が珍しくありません。「最初の基盤選定でリスクを 1 段下げておく」投資が、長期では圧倒的に安く済む構造になっています。

クラウド型生成 AI とローカル LLM の構造的な違い

「ローカル LLM」と一口に言っても、開発者の端末で llama.cpp を動かすのと、社内データセンターに GPU クラスタを構築するのとでは設計思想が大きく異なります。まずは、クラウドとローカルの構造的な違いを 6 軸で整理します。

比較軸	クラウド型（GPT-5 / Claude / Gemini 等）	ローカル LLM・オンプレミス
モデル性能	最新 SOTA。Opus 4.7 / GPT-5.5 等のフロンティアにアクセス可	Llama 3 70B / Qwen 2.5 / Mistral Large 等のオープン重みモデル。Tier 1 にはやや劣るがタスク特化では十分実用
データ統制	ベンダーの規約に依存。学習除外契約は必須	すべて自社境界内で完結。通信・保存・廃棄を物理的に制御
ネットワーク要件	外部通信前提（HTTPS）	閉域ネットワーク・エアギャップ環境でも動作可能
初期費用	低い（従量課金）	高い（GPU 8 基構成で 1 千万〜数億円）
運用費用	使用量に比例して増加	固定費中心。利用量を増やしても限界費用ゼロに近い
監査・説明責任	ベンダー任せの部分が残る	すべての処理を社内 SOC ログに統合可能

重要なのは、これは「どちらか」の二択ではなく「使い分け」の問題だということです。一般的な文書要約・社内通知文のたたき台作成にクラウドを使い、機密情報の含まれる業務にローカル LLM を使う、というハイブリッド構成が大企業では現実解になります。

ローカル LLM・オンプレミスが向く業務パターン

業務・条件	クラウドで悩みやすい点	ローカル LLM が効く理由
機密ソースコード解析・コード生成支援	repo 外への持ち出しに該当する判断が重い	自社境界内で完結。GitHub Copilot Enterprise 比較対象
個人情報を含む文書処理（人事・採用）	個人情報保護法 28 条で第三者提供の整理が必要	保存場所と通信先を制御。匿名化前段階のデータも扱える
閉域ネットワーク内の業務（金融・公共）	外部接続前提の設計とぶつかる	エアギャップ環境でモデル推論が可能
監査が厳しい部門（金融商品・医療機器）	ベンダー依存の説明が増える	自社の統制文書（J-SOX, FDA 21 CFR Part 11）に落とし込みやすい
長期運用の社内ナレッジ基盤	データ所在と契約条件の管理が重い。ベンダー変更時に再構築コスト	継続利用前提で基盤を固定化。組織独自の RAG 知識ベースを永続化
研究開発部門の未発表データ	特許出願前の発明開示に該当するリスク	知財管理規程との整合を取りやすい
製造業の設計図・BOM データ	競合・取引先への漏洩リスク	工場ネットワーク内に閉じた推論が可能

特に検討価値が高い業界

• 金融（銀行・証券・保険）：金融庁ガイドライン・FISC 安全対策基準への準拠。顧客資産情報を扱う業務での外部送信制約が厳しい
• 製造（大手メーカー・素材・自動車）：設計図・BOM・サプライチェーン情報が競争力の源泉。輸出管理規制への対応も必要
• 医療（病院・製薬・医療機器）：患者情報・治験データ・規制申請文書。HIPAA 相当の取扱いが日本でも求められる
• 公共・防衛：自治体住民情報・国防関連業務。クラウド利用そのものに制約があるケース
• 法務・知財コンサル：未公開 M&A 案件・特許出願前発明の情報を日常的に扱う

代表的なオープンモデルとライセンス

ローカル LLM 構築の選択肢は急速に広がっており、2026 年時点でビジネス利用に耐えうるオープン重みモデルは多数存在します。主要なものを整理しておきます。

モデル	サイズ	ライセンス	特徴・用途適性
Llama 3.3 70B / Llama 3.1 405B	70B / 405B	Llama Community License（年商 7 億ドル超の企業は別途交渉）	汎用性能が高く、日本語チューニング派生も多い。標準選択肢
Mistral Large / Mistral Nemo	123B / 12B	Mistral Research License（商用は別ライセンス）	欧州系。Apache 2.0 系のミドルサイズも有力
Qwen 2.5 / Qwen 3	0.5B – 110B	Apache 2.0（一部モデルを除く）	中国 Alibaba 系。日本語精度が向上。サイズの選択肢が豊富
Phi-4 / Phi-3.5	3.8B – 14B	MIT	Microsoft 製。小型で 1 台 GPU でも動作。エッジ用途
Cohere Command R+	104B	研究用は CC-BY-NC、商用は Cohere ライセンス	RAG 用途に特化したチューニング
ELYZA-Japanese-Llama	7B – 70B	Llama Community License 準拠	日本語特化チューニング。法務・社内 FAQ 等の日本語タスクに強い
Stockmark-13b 等の和製 LLM	13B	独自ライセンス（要確認）	金融・ビジネス文書チューニング

ライセンスは見落としやすい論点です。Llama 系は「Llama Community License」で、月間 7 億ユーザーを超える商用利用には Meta 側との別途交渉が必要。Qwen 系も一部モデルは Apache 2.0 ではありません。法務確認をスキップしてデプロイすると、後から差し止めリスクが発生します。

構成パターン 3 種類と判断軸

パターン A: 個別端末型（軽量・部分導入）

開発者やナレッジワーカーの端末に Ollama / LM Studio / llama.cpp を入れ、7B – 14B サイズのモデルを動かす方式。1 台あたり 30〜50 万円の Mac Studio / MacBook Pro M4 Max クラスでも実用速度が出る。

向いている場面：限定用途で素早く試したい・コードレビュー支援・個人作業の文書要約。

注意点：運用統制が弱くなりがち。誰がどのモデルを使っているか、どのデータを投入したかが追跡できない。シャドー IT 化のリスクがある。

パターン B: 社内共通推論基盤型（標準形）

社内データセンターまたは自社契約のプライベートクラウド（VMware / Nutanix / OCI Dedicated 等）に GPU サーバーを構築し、vLLM / Text Generation Inference / OpenAI 互換 API を提供する方式。Llama 3.3 70B を 8 GPU（H100/H200 構成）で運用するのが標準。

向いている場面：部門横断で生成 AI を提供したい・利用ログ統制・モデル配布を一元化したい・社内 RAG ナレッジベースを長期運用したい。

注意点：初期構築コスト・GPU 調達のリードタイム（半年〜1 年）・MLOps 人材確保が課題。社内に SRE・ML プラットフォームチームを置けない組織は、SIer のマネージドサービス活用も視野に。

パターン C: ハイブリッド型（推奨）

機密度に応じてクラウド型とオンプレを使い分ける構成。例：マーケティング部門の文書ドラフトは Claude API、研究開発部門の特許関連文書はオンプレの Llama 3、財務部門の月次レポート要約はオンプレ + 経理データ RAG。アクセスゲートウェイで「どの用途には何を使うか」をルールで強制する。

向いている場面：大企業のほぼ全ケース。社内すべての業務を一律のポリシーで扱うのは現実的でないため、業務単位の使い分けが必須。

GPU・ハードウェア要件と概算コスト

「ローカル LLM はいくらかかるのか」は最初の関門。モデルサイズと量子化レベルで GPU メモリ要件が変わります。

モデルサイズ	量子化	必要 VRAM	代表的なハードウェア	同時接続想定
7B	4bit	6 GB	RTX 4090 / Mac Studio M4	1〜2 人（個人検証）
13B	4bit	10 GB	RTX 4090 / A6000	1〜3 人
70B	4bit	40 GB	A100 80GB / H100 80GB ×1	3〜10 人
70B	fp16	140 GB	H100 80GB ×2 / H200 ×1	10〜30 人
405B	fp16	800 GB	H100 80GB ×8 / H200 ×4	30〜100 人

H100 80GB の市場価格は 1 基あたり 400〜500 万円。8 基構成のサーバーは本体・ネットワーク・冷却込みで 5,000 万〜1 億円規模になります。これに加えて運用人件費（ML エンジニア 1〜2 名）、電力費（年間 200〜400 万円）、保守料を見込むのが現実的です。

「高い」と感じるかもしれませんが、社員 1,000 人規模の企業で月間 100 万トークン × 1,000 人を ChatGPT Enterprise で消費すると、年間のクラウド利用料も数千万円規模になります。利用量が一定を超えるとオンプレが TCO で有利になる損益分岐点が現れます。

セキュリティとガバナンスの設計要素

オンプレ化するだけで安全になるわけではありません。最低限、次の要素を統合的に設計する必要があります。

• 認証・認可：社内 IdP（Azure AD / Entra ID 等）と統合し、SSO・MFA を強制。部署単位の権限制御
• 監査ログ：プロンプト・応答・利用者・タイムスタンプを社内 SOC（SIEM）へ常時転送。コンプライアンス監査対応
• プロンプト DLP：投入されたプロンプト内に PII / 機密ラベル付き情報があるか検知し、ブロックまたはマスキング
• レート制限：個人・部門単位の利用量上限。コスト管理と暴走検知を兼ねる
• モデル更新ポリシー：重みファイルのバージョン管理・脆弱性アップデートの追従ルール
• RAG データのライフサイクル：ベクター DB 上の社内ナレッジの保持期間・削除権利対応

失敗しにくい進め方（5 ステップ）

ローカル LLM やオンプレミスを検討する際にありがちな失敗は、最初から大規模構築に入ることです。「H100 8 基をいきなり購入したが、誰が使うかが整理されていない」というプロジェクトを何度も見てきました。先に整理すべきは、どの業務を社内閉域へ寄せるべきか、どの部門が管理責任を持つか、クラウドとの役割分担をどうするかです。

1. 対象業務の棚卸し：全業務を「機密度」「外部通信可否」「監査要件」の 3 軸で分類。クラウド OK / クラウド NG / グレーの 3 グループに分ける（2〜4 週間）
2. 役割分担の設計：「クラウド OK」群はマーケや一般業務に開放、「クラウド NG」群をローカル LLM の候補に。グレーは個別判断のガバナンスを設計
3. 小規模 PoC：ローカル LLM 候補業務の中から 1〜2 件を選び、A6000 1 基や Mac Studio 等の小構成で 3 ヶ月 PoC。性能・運用負荷・ユーザー受容度を測定
4. 本番設計：PoC の手応えに応じて、社内共通基盤 or ハイブリッドの構成を決定。GPU 調達・社内 SOC 連携・運用体制を整備（6〜12 ヶ月）
5. 段階展開：1 部門・10 名から開始し、運用負荷を見ながら段階拡大。3〜6 ヶ月で全社展開を目指す

よくある失敗パターン 5 つ

• 失敗 1: 価格比較だけで意思決定する。初期費用だけ見ると確かにオンプレは高いが、監査対応コスト・利用禁止による機会損失まで含めるとクラウド一択が高くつくこともある
• 失敗 2: 最新フロンティアモデルとの直接比較。Llama 3.3 70B は GPT-5.5 や Claude Opus 4.7 と「同等」ではない。タスク特化で十分なケースかを見極める
• 失敗 3: MLOps 体制を後回しにする。モデル更新・脆弱性対応・利用ログ管理は継続的な人的リソースが必要。SIer 委託する場合の契約形態も事前設計
• 失敗 4: PoC をスキップして本番展開。GPU を一括購入してから「実は使われない」事例が後を絶たない
• 失敗 5: クラウドを完全排除する。一般業務までオンプレにすると、利便性が劣化して結局シャドー IT 化する

よくある質問（FAQ）

Q. クラウド型生成 AI の「学習に使わない」契約があれば、それで十分ではないですか？

A. 不十分なケースが多いです。「学習に使わない」と「外部通信が発生しない」は別物。社内規程上、機密情報を外部送信すること自体が禁止されている業務では、ベンダー側の学習除外契約があっても運用できません。とくに金融・公共・医療では、この線引きが厳格です。

Q. オープンモデルの精度は ChatGPT に比べてどれくらい劣りますか？

A. 業務タスクによって大きく異なります。一般的な要約・分類・社内 FAQ では Llama 3.3 70B 級で実用十分。高度な推論・複雑なコード生成では GPT-5.5 / Claude Opus 4.7 と差が残ります。「使えるタスクから始める」のが鉄則です。

Q. SIer に丸投げできますか？

A. インフラ構築は委託できますが、「何を社内閉域で扱うか」の意思決定は自社で行う必要があります。SIer は技術選定はできても、業務ごとの機密度判断はできません。社内 CISO / CIO 配下に意思決定の場を作るのが先です。

Q. 中小企業でもローカル LLM は検討すべきですか？

A. 一般的にはクラウド型で十分です。中小企業向けに導入コストが見合うのは、設計情報・顧客名簿が競争力の源泉になっているケース（製造業・士業・コンサル等）に限られます。中小企業の AI 導入については別記事の「AI コーディングエージェントを安全に導入するための社内ルール設計」もご参照ください。

まとめ

大企業にとって、生成 AI 基盤の選定は単なる IT 選定ではなく、情報統制と経営リスクの設計です。クラウド型生成 AI は非常に有力ですが、すべての業務に適しているわけではありません。

だからこそ、ローカル LLM やオンプレミス生成 AI を早い段階から比較対象に入れるべきです。とくに機密性の高い業務では、自社境界内で通信・保存・認証・監査を設計できることが、そのまま安心材料になります。重要なのは「クラウド or オンプレ」の二択ではなく、業務単位の使い分けというハイブリッド設計です。

はてなベースでは、御社の業務棚卸しから始まり、クラウド／オンプレの切り分け設計・GPU 構成見積もり・PoC 実行・運用ガバナンス整備までを伴走支援しています。「クラウド一択で進めてよいのか不安」という段階でも、無料相談（90 分）から始めていただけます。