2026.09.13
ローカルLLMで実現する安全な社内AI基盤
IT関連
ローカルLLMは、生成AIを自社PC・社内サーバー・閉域網で動かし、入力データと推論処理を管理下に置く選択肢です。機密文書を外部APIへ送れない組織でも、検索、要約、文書作成、コード支援を現実的な範囲で活用できます。
ただし、ローカル実行は「安全なAI」を自動的に保証するものではありません。プロンプトログ、埋め込みデータ、バックアップ、管理者権限までを対象に、モデル・データ・インフラを一体で設計する必要があります。
本記事では、クラウドとの使い分け、GPUと量子化の考え方、社内文書を扱うRAG、安全な運用手順を整理します。小規模な検証から本番展開まで、判断に必要な基準を順番に確認しましょう。
ローカルLLMとは何か、まず仕組みを理解する
端末や社内基盤で推論するAI
ローカルLLMとは、モデルの重みを自分で保持し、端末または自社管理のサーバーで推論する大規模言語モデルです。質問文を外部の生成AI APIへ送らずに済むため、閉域ネットワークやオフライン環境にも配置できます。
利用者はチャット画面から質問し、実行環境がモデルへプロンプトを渡して回答を生成します。文書検索を組み合わせる場合は、検索対象をベクトル化し、関連箇所だけを回答時の文脈として渡す構成が基本です。
個人のPCで試す小規模な利用と、部門横断で共有するサーバー利用は分けて考えます。後者では認証、利用者別の権限、監査ログ、冗長化を加え、単なるデスクトップアプリから業務基盤へ設計を広げます。
- 端末内での個人利用：試作、要約、開発補助に向く
- 社内サーバー利用：部門共有、文書検索、業務連携に向く
- 閉域利用：ネットワーク分離が必要な領域で検討する
クラウドLLMと競合させずに使い分ける
ローカルLLMは、機密性・低遅延・接続制約を優先する業務に向き、クラウドLLMは最新性能や大規模な処理を優先する業務に向きます。すべてを一方へ寄せるのではなく、データ区分と用途で振り分けることが実務的です。
たとえば公開済みの文章案や一般的な調査はクラウド、顧客情報を含む議事録や設計書の検索は社内環境、という分離ができます。入力禁止ルールだけに頼らず、送信経路そのものを設計で分けることが重要です。
AIソブリンティの観点でも、モデル、データ、鍵、ログをどこに置き、障害時にどこへ切り替えるかを明確にします。可搬性を確保すれば、特定ベンダーの価格改定やサービス変更への依存を抑えられます。
| 比較軸 | ローカル実行 | クラウド利用 |
|---|---|---|
| 機密データ | 社内管理しやすい | 契約・送信設定を要確認 |
| 最新モデル | 更新作業が必要 | 利用開始が速い |
| 閉域・オフライン | 対応可能 | 通常は困難 |
| 運用負荷 | 自社で負担 | サービス側が負担 |
- 公開情報と機密情報をデータ分類で分ける
- 高難度推論は外部サービスも選択肢に残す
- モデル切替とデータ移行の手順を文書化する
メリットと制約を先に認める
最大の利点は、データの送信先と処理経路を自組織で制御できることです。通信遮断時にも動かせるため、現場ネットワークが不安定な拠点や、外部接続を制限する環境でも業務支援を継続しやすくなります。
一方で、モデル取得、GPU調達、脆弱性対応、容量監視、障害復旧は自社の責任になります。モデルが出力した内容の正確性も保証されないため、重要な判断では根拠文書の提示と人による確認を組み込みます。
導入効果は、回答の賢さだけで評価しません。検索時間、文書作成時間、回答の根拠提示率、誤回答率、利用率、問い合わせ件数を測り、業務プロセスが改善したかで継続判断することが大切です。
- 外部送信を減らせるが、内部管理責任は増える
- 閉域で動かせるが、モデル更新の搬入手順が要る
- 品質評価は正答率だけでなく業務KPIで行う
モデルとハードウェアを用途から選ぶ
VRAMはモデル規模と量子化で決める
必要なVRAMは、モデルのパラメータ数、量子化方式、同時利用者数、長い入力文によって変わります。目安として「B数の半分（GB）がVRAMの目安」とされ、14Bモデル≒7GB以上のVRAMが必要です。
実務で日本語品質を重視するなら、14B〜32BモデルはVRAM 16GB以上で高品質な日本語生成が可能です。軽量な量子化モデルであれば、VRAM 8GBでも高い性能を発揮するため、まずは小規模PoCから検証できます。
ただしVRAMだけで判断してはいけません。コンテキスト長を増やすとKVキャッシュがメモリを消費し、複数人の同時アクセスでは待ち時間も増えます。実データで入力長、応答時間、メモリ使用量を測定して決めます。
| VRAMの目安 | 想定GPU例 | 扱いやすいモデル規模 |
|---|---|---|
| 8GB | RTX 3070等 | 〜7Bパラメータ（量子化モデル） |
| 16GB | RTX 4080等 | 〜14Bパラメータ |
| 24GB以上 | RTX 4090・A100等 | 30B〜70Bパラメータ |
| 48GB程度 | 業務用GPU | 70Bモデルの4bit量子化 |
- モデル本体に加え、KVキャッシュの余裕を見込む
- 量子化は容量を抑える一方、用途別に品質検証する
- 同時接続数は単独利用時より大きな設計要因になる
日本語、長文、ライセンスでモデルを絞る
モデル選定では、ベンチマーク順位よりも日本語の業務文書での再現性、コンテキスト長、商用利用条件を優先します。評価用の質問を用意し、要約、検索回答、分類、コード生成を同じ条件で比較してください。
Gemma 3は1B、4B、12B、27Bのサイズ展開があり、4B以上では128Kコンテキストに対応しています。長い規程集を一度に扱いたくなる場面でも、実際には検索で対象範囲を絞る設計が安定します。
Qwen2.5-7B-Instructは29以上の言語に対応し、128Kコンテキストをサポートしています。候補にはGPT-OSS-20B（gpt-oss）やDeepSeek-V3.2もありますが、利用前に重みのライセンス、再配布条件、社内審査要件を確認します。
- 実データを匿名化した評価セットで比較する
- モデルカードとライセンスを調達前に確認する
- 長文対応でも検索・分割・引用表示を併用する
個人検証と共有基盤で実行環境を分ける
個人の検証にはOllamaやLM Studioが始めやすく、部門共有には推論サーバーとWeb UIを分離した構成が適しています。モデルのダウンロード、API公開、利用者管理を同じPCへ混在させないことが運用上の基本です。
共有環境では、vLLMやSGLangなどで推論APIを提供し、Open WebUIのような画面から認証付きで利用させる構成を検討します。アプリごとの接続先を統一するには、APIゲートウェイの設置も有効です。
Llama 3.1-8Bは約16GB、70Bは約141GB、405Bでは812GBものVRAMが必要となり、規模を上げるほど設備と運用が重くなります。性能への期待だけで大型モデルを選ばず、用途ごとに軽量モデルも併用します。
- 検証端末と本番サーバーの責任範囲を分離する
- API公開時は認証とネットワーク制限を必須にする
- 大型モデルは設備費・電力・保守まで含めて判断する
社内AIセキュリティはデータ経路から設計する
ローカルでも漏えい面は残る
社内AIセキュリティでは、外部APIを使わないことだけで満足せず、入力・出力・ログ・バックアップの全経路を保護します。ローカル環境でも、管理者権限の乱用、共有フォルダの誤設定、端末盗難、画面ののぞき見は起こり得ます。
特に会話履歴、推論ログ、RAG用の埋め込み、監視基盤のログには、元文書の内容や利用者の意図が残ります。保存先、暗号化、閲覧権限、削除方法を台帳化し、データ分類に応じて保持期間を決めます。
共有基盤では、利用者認証をID管理基盤と連携し、部署や案件ごとにアクセス範囲を制限します。モデルAPIを直接公開せず、社内ネットワーク、リバースプロキシ、認可層を経由させることで統制を取りやすくなります。
- プロンプト、応答、埋め込み、バックアップを資産として棚卸しする
- 最小権限と部署・案件単位の認可を適用する
- ログ閲覧者も監査対象として記録する
RAGセキュリティは検索前後の制御が要点
RAGセキュリティの要点は、検索対象の権限を回答生成時にも引き継ぎ、取得文書を無条件に信頼しないことです。閲覧権限のない文書が検索結果に混ざれば、生成AIが要約して情報を返す危険があります。
文書登録時には、所有者、機密区分、更新日、閲覧可能な部署をメタデータとして付与します。検索時は利用者IDで事前フィルタリングし、その後に関連度で並べ替えることで、権限漏れを防ぎます。
また、文書内に「前の指示を無視せよ」といった命令が含まれるプロンプトインジェクションも想定します。取得文書は命令ではなく参考情報として扱い、出典リンクと引用箇所を画面へ表示して人が検証できるようにします。
- 検索前にACLで候補文書を絞り込む
- 文書メタデータの更新・削除を同期する
- 回答には根拠文書と引用箇所を添える
監査とインシデント対応を運用に組み込む
安全な運用には、誰が、いつ、どのモデルに、何を問い合わせたかを追跡できる監査証跡が必要です。ただしプロンプトを無制限に残すと機密情報の二次保管になるため、マスキング、アクセス制限、削除手順をセットで設計します。
オンプレLLMの共有環境では、ログ保持期間を90日程度とする運用例があります。これは固定の正解ではなく、調査可能性、法務要件、保存コスト、個人情報の最小化を比較して、自社の保持ポリシーとして決めるべきです。
誤送信や権限逸脱を検知したら、APIキーの失効、該当インデックスの隔離、会話履歴の保全、影響範囲の調査を順に行います。停止基準と連絡先をRunbookへ明記し、机上演習で動作を確かめます。
- 監査ログは保護対象データとして扱う
- 検知・遮断・保全・報告の順序をRunbookにする
- 復旧後は原因、再発防止、権限見直しを記録する
AIソブリンティを支えるオンプレミス設計
主権はデータ所在地だけではない
AIソブリンティとは、データの保管場所だけでなく、モデル、計算資源、暗号鍵、運用ルールを自組織が意思決定できる状態です。海外サービスを使うかどうかの二択ではなく、どの資産を誰が管理し、代替できるかを定義します。
AIソブリンティの重要性は経営課題にもなっています。調査では企業経営者の93%が関連する課題を重視し、市場は2025年の128億ドルから2030年には580億ドル、年平均成長率35.2%で拡大する見通しが示されています。
この概念を実装するには、データ所在地、モデルの切替時間、代替GPUの有無、暗号鍵の管理者、監査証跡、復旧時間を棚卸しします。少なくとも年1回は、代替環境で代表的な業務フローを再現する訓練も必要です。
- データ主権：保存・利用・越境の管理
- モデル主権：重み、更新、切替の管理
- 基盤主権：計算資源、鍵、監査、復旧の管理
オンプレLLMは高統制のための選択肢
オンプレLLMは、自社施設または自社専用設備にモデルと推論基盤を置き、ネットワークと運用を統制する構成です。ローカルLLMのうち、複数部署が使う共有基盤や厳格な閉域環境を想定する場合に有力です。
70Bパラメータ規模のモデルをFP16（半精度）で動作させるには140GB前後のVRAMが必要で、H100 80GBであれば2基以上の並列構成が求められます。一方、70Bモデルを4bit量子化すれば、48GB VRAM程度のGPU 1基でも推論が可能です。
設備投資には電力と冷却も含めます。NVIDIA H100は1基あたり最大700W、B200は空冷構成で1,000W、液冷を前提とするGB200構成では1,200Wに達するため、サーバー室の受電容量と空調設計を先に確認します。
- 閉域利用ではモデル搬入・更新媒体の統制も必要
- 量子化は設備要件を下げるが品質検証が欠かせない
- 電力・冷却・保守をTCOに含めて稟議する
コストと規制を中長期で判断する
オンプレLLMの採算性は、GPU価格だけでなく、利用量の安定性、保守人員、電力、クラウド回避コストを含めて判断します。安定したワークロードでは3年間で30〜50％のコスト削減が見込まれる一方、利用が少ない段階では共有型サービスが有利な場合もあります。
ソブリン環境は一般的なクラウドより費用が上がることがあります。標準AWSの20〜35%増、標準Azureの15〜30%増、構成によっては30〜80%増という見積もりを前提に、統制によって得る価値を可視化します。
2026年3月に総務省と経済産業省が公表した「AI事業者ガイドライン（第1.2版）」も参照し、説明責任、リスク管理、利用者への配慮を運用要件へ落とし込みます。2027年末までにグローバル企業の75%が主権関連の要件に直面するという見通しも、早期の棚卸しを促します。
- 初期費用と年間運用費を別に見積もる
- 規制・契約・監査を技術設計と同時に進める
- 利用量が読めない段階はPoCで測定する
小さく検証し、継続運用へ進める手順
PoCは業務課題と評価基準から始める
導入の最初の一歩は、モデル選びではなく、削減したい業務時間と扱うデータの範囲を決めることです。対象を「規程検索」「問い合わせ下書き」「設計書要約」のように一つへ絞り、現状の所要時間と品質を計測します。
検証データは本番の特徴を持ちながら、必要に応じて匿名化・マスキングしたものを使います。正答率だけでなく、根拠提示率、幻覚率、平均応答時間、利用者の修正時間を記録すれば、本番化の判断が主観に偏りません。
オンプレLLMでは、PoCフェーズで1〜3か月、本番環境の構築・テストで3〜6か月が一般的です。拡張前に、目標未達なら停止する条件、クラウドへ戻す条件、データ削除の確認方法まで合意しておきます。
- 対象業務は一つに絞り、現状値を先に測る
- 品質・速度・安全性の評価軸を事前合意する
- 撤退基準とロールバック手順をPoC計画に含める
本番構成は責任分界を明確にする
本番では、モデル、推論API、文書保管、ベクトルDB、認証、監視を分離し、各コンポーネントの管理者を明確にします。一台にすべてを置く構成は検証では便利でも、障害時の切り分けと権限統制が難しくなります。
社内の業務システムやAIエージェントと接続する際は、ツール実行権限を最小化します。外部ツールとの接続設計は、MCPサーバーと社内AI連携の導入・セキュリティ設計も参照し、認可範囲と監査ログを先に定義してください。
バックアップはモデル重みだけでなく、設定、インデックス、アクセス制御情報、評価データを対象にします。復元手順を実際に試し、モデル破損、GPU故障、ネットワーク断、電源停止でも復旧できるかを確認します。
- コンポーネント別に所有者と変更手順を定義する
- AIから実行できる操作を最小権限に限定する
- バックアップは復元試験まで行って初めて有効になる
更新と改善を止めない運用にする
ローカルLLMの価値は、導入時のモデル性能ではなく、更新・評価・監査を繰り返して業務適合性を維持することにあります。モデル更新時は同じ評価セットを再実行し、精度、安全性、速度、ライセンス条件の差分を記録します。
運用会議では、利用率、問い合わせ削減、回答の修正率、セキュリティイベント、GPU使用率を確認します。公開事例には「問い合わせ対応工数を50%削減」「ドキュメント作成時間を1時間→10分に短縮」といった成果もありますが、自社の基準値で検証する姿勢が不可欠です。
AIソブリンティを高める施策は、常にコストとの均衡が必要です。その後の年間運用コストは初期投資の約30〜45%とされるため、使われない高性能基盤を抱えないよう、用途・利用量・品質を定期的に見直します。
- 更新前後を同一評価セットで比較する
- 業務KPIと技術KPIを同じ会議で確認する
- 利用実態に合わせてモデル規模と基盤を見直す
まとめ
ローカルLLMは、機密データを扱う業務に生成AIを取り込むための有力な基盤です。ただし成功の条件は、GPUを用意することではなく、用途を絞り、RAGの権限設計、ログ統制、評価、復旧までを継続運用できる形にすることです。
要点
- ローカルLLMは閉域・高機密業務に適するが、内部統制まで含めて設計する
- VRAM、量子化、同時接続数を実測し、用途に必要なモデル規模を選ぶ
- RAGでは文書権限を検索時に適用し、根拠表示と注入対策を行う
- AIソブリンティはデータだけでなく、モデル・鍵・基盤・代替性の統制で考える
- PoCでは業務KPIと撤退条件を定め、本番後も更新評価を続ける
まずは、外部送信できない文書を使う業務を一つ選び、データ分類、利用者、評価指標を整理してください。その結果を基に、個人検証、共有サーバー、オンプレLLMのどこから始めるべきかを判断すると、投資とリスクを抑えられます。
よくある質問
Q1. ローカルLLMはインターネットに接続しなくても使えますか？
モデルと実行環境をあらかじめ配置すれば、推論自体はオフラインや閉域網でも可能です。ただし、モデル更新、脆弱性情報の取得、外部検索連携には別途統制された接続経路が必要です。
Q2. ローカルLLMなら機密情報を入力しても安全ですか？
外部送信のリスクは抑えられますが、会話履歴、ログ、埋め込み、バックアップ、権限設定が不適切なら漏えいします。データ経路の棚卸しと最小権限、監査、削除ルールを設計してください。
Q3. RAGとファインチューニングはどちらを先に行うべきですか？
社内文書を根拠として回答させたい場合は、更新・削除・権限制御をしやすいRAGから始めるのが一般的です。口調や分類など恒常的な振る舞いを変える必要が明確になってから、ファインチューニングを検討します。
Q4. オンプレLLMはどのような企業に向いていますか？
高機密データを扱い、閉域利用、監査証跡、データ所在地、モデルの可搬性を重視する組織に向きます。利用量が不安定な場合は、まず小規模PoCで性能、運用負荷、費用を測定することが重要です。
Q5. GPUがないPCでもローカルLLMを試せますか？
CPUや統合メモリでも軽量・量子化モデルを試せますが、応答速度は低下しやすくなります。まずは小型モデルで用途適合性を確かめ、必要な品質と同時利用者数が見えてからGPU構成を検討します。
参考文献・出典
[跳至主要內容](#main) [ニュース](/ja/news) [インサイト](/insights) [会社概要](/ja/#about) [技術力](/ja/#capabilities) [導入事例](/ja/#cases) [研究・出版](/ja/#papers) [ギャラリー](/ja/gallery)…
www.meta-intelligence.tech
[](https://eques.co.jp)…
eques.co.jp
[Dify](/ai/service/dify/) [Difyに関する お問い合わせ](/ai/contact/) * [リコーのAI：HOME](/ai/) * [コラム](/ai/column/) * ローカルLLMとは？導入のメリットとデメリット、方法、注意点までを詳しく解説 #…
promo.digital.ricoh.com