2026.08.08
オンプレLLMで実現する安全な社内AI基盤
IT関連
オンプレLLMとは、自社のサーバーや閉域環境で大規模言語モデルを動かす仕組みです。外部APIへ機密情報を送らずに生成AIを業務利用したい企業にとって、データ主権と統制を両立できる有力な選択肢になります。
一方で、モデルをダウンロードして動かすだけでは業務システムになりません。GPU容量、文書の権限管理、検索精度、監査ログ、更新手順までを一つの設計として扱わなければ、PoCだけで止まるリスクがあります。
本記事では、クラウドとの選び分けからAI推論基盤の設計、社内文書を使うRAG構築、ベクトル検索RAGの精度改善、LLMOps運用までを順に解説します。導入担当者が判断材料として使える数値と実務上の確認項目も示します。
オンプレLLMは機密業務を安全に支える選択肢
オンプレミスで動かすLLMとは何か
オンプレLLMは、モデル、推論サーバー、データベースを自社管理の設備または専用環境に配置する方式です。利用者の質問と参照文書を外部サービスへ送らずに処理できるため、重要情報の取り扱い範囲を明確にできます。
クラウドLLMは導入速度とモデル更新の速さが魅力ですが、通信経路、保存設定、契約条件を精査する必要があります。対してオンプレミスは統制を強めやすい反面、性能設計、障害対応、脆弱性対策を自社または支援会社が担います。
重要なのは「社内に置くこと」自体ではなく、データの流れを制御することです。入力、検索対象、生成結果、キャッシュ、ログの全経路を棚卸しし、どの情報を誰が閲覧できるかを設計段階で定義します。
- 閉域ネットワークやエアギャップ環境でも利用しやすい
- モデル・プロンプト・ログの保持場所を自社で決められる
- ハードウェア調達と保守体制まで含めた責任分界が必要
向いている企業とユースケース
オンプレミスが特に適するのは、個人情報、設計図、契約書、診療情報、行政文書などを日常的に扱う組織です。金融、医療、公共、製造では、外部送信の制約や部門ごとの閲覧権限が導入要件になりやすい領域です。
代表的な用途は、社内規程の検索、問い合わせ一次回答、設計・品質文書の要約、議事録の整理、報告書の下書きです。回答を自動実行に直結させる前に、まず参照元を提示する支援用途から始めると、利用者が検証しやすくなります。
例えば製造現場では、保全手順と過去の障害記録を横断して候補を示し、最終判断は担当者が行う形が現実的です。生成文を正解として扱わず、現場の承認工程に組み込むことが安全な定着につながります。
- 機微情報を含むナレッジ検索
- ネットワーク分離された現場での支援
- 低遅延が求められる社内対話アプリ
導入効果と見落としやすい制約
オンプレLLMの主な利点は、データ所在の管理、社内システムとの柔軟な連携、安定利用時の費用予測です。安定したワークロードでは3年間で30〜50％のコスト削減が見込める場合もありますが、利用量が小さい段階では逆に固定費が重くなります。
導入効果はモデルの大きさだけで決まりません。社内FAQや定型文書の支援では、検索品質と業務画面への組み込みが利用価値を左右します。問い合わせ対応工数を50%削減、ドキュメント作成時間を1時間→10分に短縮したような成果は、対象業務を絞った設計で生まれます。
制約として、GPU故障、電力、冷却、モデル更新、担当者不足を見過ごしてはいけません。小規模ユーザ数（～十数名）なら共有GPUで始められても、利用部門の拡大時には同時接続数と応答時間を基に再設計が必要です。
- 効果は削減時間・回答根拠・利用率で測定する
- 固定費だけでなく運用人件費もTCOに入れる
- 業務影響の小さい範囲から段階的に広げる
導入可否は要件と費用を先に見極める
最初に決めるべき四つの要件
導入判断は、利用者数、同時接続数、回答に必要な品質、扱うデータの機密度という四つから始めます。これらを決めずにGPUやモデルを選ぶと、性能過剰による投資増、あるいは応答遅延による利用停止のどちらかに陥りやすくなります。
次に、許容レイテンシと稼働時間を業務単位で定義します。対話用途なら3秒以内が一つの基準ですが、夜間に文書を要約するバッチ処理では別の設計が合理的です。一律の性能目標ではなく、利用シーンに応じて優先順位を分けます。
要件は「質問できる」ではなく、権限のない資料を出さない、根拠を示す、障害時に代替手段がある、といった受入条件に変換します。これによりPoCの評価がデモの印象論ではなく、業務適合性の検証になります。
- 利用者・同時接続・稼働時間
- データ区分とアクセス権限
- 品質指標・応答時間・障害時の対応
GPUとモデルサイズを対応させる
モデル規模に応じて必要なVRAMは大きく変わります。7B（70億）クラスでは16GB以上、13B（130億）クラスでは24GB以上が一つの目安であり、量子化方式、コンテキスト長、同時実行数によって実際の必要量は増減します。
70B（700億）クラスを本格運用する場合は、48GB x 2枚以上の構成が検討対象になります。NVIDIA L40S、NVIDIA A100、NVIDIA H100のような高性能GPUは選択肢ですが、性能だけでなく保守契約、供給、電力設備も調達条件に含めるべきです。
小規模な検証では、TinyLlamaやphi-2のような小型モデルで画面、認証、検索連携を先に確認できます。TinyLlamaは11億パラメータであり、phi-2は27億パラメータです。モデルの能力検証と基盤検証を分けると、投資判断がしやすくなります。
- 7B以上のモデルは16GB以上のGPUメモリが必要
- 13B: 24GB+, 70B: 80GB×複数
- 量子化はVRAM削減と応答品質の両面で検証する
TCOは電力と人件費まで比較する
TCO比較では、サーバー価格だけでなく、電力、冷却、ラック、保守、監視、人件費、予備機を合算します。最新のH100 GPUを8基積んだ企業向けサーバは約80万ドル（約833,000ドル）とされ、大規模モデルを常時稼働させる場合は初期投資が大きくなります。
電力費も継続支出です。NVIDIA A100 GPUの場合、1基で最大300W程度を消費します。GPUを8基搭載したサーバを24時間運用すれば月十数万円以上の電力コストとなり、利用が少ない時期にも固定費が発生します。
比較表では、クラウド、オンプレミス、プライベートクラウド、ハイブリッドを同じ質問数と同時接続条件で並べます。利用量が変動する業務はクラウド、機微情報を常時処理する定常業務は自社設備というように、併用も現実的な選択です。
- 初期費用・月額費用・3年累計を分けて算出する
- ピーク時だけでなく通常時の稼働率も確認する
- GPU台数、電力、保守、人件費を同じ前提で比較する
AI推論基盤は性能と統制を両立させる
推論サーバーの役割を分離する
AI推論基盤は、モデルを読み込み、APIで応答し、複数利用者の要求を安全かつ効率的に処理する土台です。モデルそのものとアプリケーションを密結合にせず、推論層を独立させることで、モデル交換や性能調整を進めやすくなります。
検証環境ではOllamaが扱いやすく、本番の高並列処理ではvLLM、TensorRT-LLM、TGIなどが候補になります。選定時は対応モデル、ストリーミング、バッチ処理、GPU分散、観測機能、サポート体制を要件表で比較します。
推論APIの前段にLiteLLMなどのゲートウェイを置けば、アプリ側は共通APIで複数モデルを扱えます。利用部門が直接GPUサーバーに接続する構成を避け、認証、レート制限、モデル選択を一元化することが運用上の要点です。
- 推論層と業務アプリを分離する
- APIの認証・制限・記録をゲートウェイに集約する
- モデルごとの性能差を同一条件で測定する
閉域環境でもアクセス制御を徹底する
閉域ネットワークは重要な防御層ですが、それだけで安全にはなりません。利用者認証にはSSOを採用し、部門、役割、案件に応じたRBACを適用して、モデルAPIとナレッジの両方を制御する必要があります。
通信は内部であっても暗号化し、管理者操作と回答生成の監査ログを残します。ログには質問文が含まれる可能性があるため、閲覧権限、マスキング、保管先を定めます。ログ保持期間を90日程度とする場合も、法令や社内規程と照合して決めます。
バックアップでは、モデル重みだけでなく、設定ファイル、プロンプト、ベクトルDB、認可ポリシー、評価データを対象にします。復旧手順を文書化し、実際に復元テストをすることで、障害時の属人化を防げます。
- SSOとRBACをAPI・検索・管理画面に適用する
- 監査ログの内容と閲覧者を最小化する
- 復元可能なバックアップを定期検証する
性能監視は利用体験から逆算する
AI推論基盤の監視では、GPU使用率だけでなく、要求数、待ち行列、トークン生成速度、エラー率、利用者ごとのレイテンシを確認します。GPUが空いていても、検索処理やネットワークが遅ければ、利用者は回答が遅いと感じます。
負荷試験は、想定ユーザーが一斉に使う時間帯を再現して実施します。平均値だけで判断せず、遅いケースの応答時間、タイムアウト、再試行時の振る舞いまで測ると、業務開始後の不満を減らせます。
性能改善では、まずプロンプトと取得文書を短くし、次にキャッシュ、バッチ処理、モデル量子化を検討します。いきなりGPUを増やすより、要求の内容と処理経路を可視化してボトルネックを特定する方が投資効率は高まります。
- 利用者視点のレイテンシを主要指標にする
- ピーク負荷と障害時の挙動を事前検証する
- 計測結果をモデル・設定の変更履歴と結び付ける
RAG構築で社内知識を回答の根拠にする
RAGは学習ではなく検索を組み合わせる仕組み
RAG構築は、質問に関係する社内文書を検索し、その抜粋をLLMへ渡して回答を生成する方法です。モデルを再学習させずに規程やマニュアルの更新を反映しやすく、回答に出典を添えられる点が業務利用に向きます。
基本工程は、データ取り込み・変換・Embedding・索引化・検索・生成です。ファインチューニングがモデルの応答傾向を変える手法であるのに対し、RAGは都度参照する知識を変える仕組みであり、両者の目的は異なります。
最初の対象は、更新責任者が明確で、利用頻度が高く、正解を判定しやすい文書に絞ります。社内規程200ファイルのようなまとまったデータでも、古い版や重複を含んだまま登録すると、もっともらしい誤回答の原因になります。
- 文書更新をモデル再学習なしで反映しやすい
- 回答に引用元とリンクを表示できる
- 対象文書の責任者と更新頻度を明確にする
前処理とチャンク設計が回答品質を左右する
RAG構築で最初に改善すべきなのは、LLMの指示文よりも原文データです。PDF、表、画像、スキャン文書では抽出誤りが起きるため、OCR結果、見出し階層、表の列関係を確認し、原本へ戻れる識別子を保持します。
チャンクは文書を検索可能な単位に分ける処理です。一般的には500〜1,000トークン程度を出発点にしますが、FAQなら短め（200〜400文字）、技術マニュアルなら長め（500〜1000文字）が読み取りやすい場合があります。
分割時には、文書名、改訂日、部門、機密区分、閲覧権限、原本URLをメタデータとして付与します。これにより、回答時に引用を表示できるだけでなく、規程の改訂や削除時に古いチャンクを追跡して無効化できます。
- 抽出品質を原本と照合する
- 用途別にチャンク長を検証する
- 検索・回答・ログまで権限メタデータを継承する
PoCは業務質問で合否を判定する
PoCでは、実際の問い合わせログを匿名化して評価セットにします。評価セット50問を用意し、質問タイプ、部門、参照文書ごとに分けると、どの利用場面で検索漏れや誤回答が起きるかを把握できます。
検索ではRecall@5で0.8以上を目安にしつつ、最終的には根拠に忠実かを確認します。faithfulness 0.9以上・致命的誤回答ゼロを受入条件に置けば、単に流暢な文章を返すだけのデモから脱却できます。
費用と期間は範囲で大きく変わります。PoC 50〜200万円・本開発500〜3,000万円という目安を参照しながら、対象部門、データ整備、既存認証との連携、運用支援の範囲を明文化して見積もることが重要です。
- 本番に近い質問で評価セットを作る
- 検索精度と根拠忠実性を別々に測る
- PoCの出口条件を開始前に合意する
ベクトル検索RAGは精度と権限を設計する
検索方式は一つに固定しない
ベクトル検索RAGでは、質問と文書を数値ベクトルに変換し、意味が近い文章を取り出します。ただし、製品名、型番、規程番号、固有名詞は完全一致が重要なため、ベクトル検索だけでは取りこぼす場合があります。
実務では、BM25などのキーワード検索とベクトル検索を組み合わせるハイブリッド検索が有効です。alpha パラメータ（既定0.5、1に近いほどベクトル重視、0に近いほどキーワード重視）を調整し、質問群ごとに最適な比率を測定します。
さらに上位候補をre-rankingで並べ替えると、LLMへ渡す文脈を絞れます。検索件数を増やし過ぎると無関係な情報も混ざるため、正解文書が上位に入るか、不要な文書が混ざらないかを評価セットで確認します。
- 意味検索とキーワード検索を併用する
- 型番・条文番号・人名は完全一致の評価を行う
- 再順位付けでLLMに渡す根拠を絞り込む
ベクトルDBは規模と運用要件で選ぶ
ベクトルDBにはPinecone、Weaviate、Qdrant、pgvectorなどの選択肢があります。既存のPostgreSQL運用に寄せたい場合はpgvector、専用検索機能や高い拡張性を重視する場合は専用DBというように、技術力と保守体制で判断します。
Embeddingモデルの次元数は、検索精度と保存容量、検索速度に影響します。text-embedding-3-small は既定1536次元、text-embedding-3-large は既定3072次元であり、モデル変更時には既存データを再ベクトル化する計画が必要です。
オンプレミス環境では、Embeddingも外部APIへ送らない構成を検討します。日本語文書の表記ゆれ、略称、英数字の混在を含む実データで比較し、単純なベンチマークではなく自社の質問に対する検索結果で選定します。
- データ量・既存基盤・保守スキルでDBを選ぶ
- Embedding変更時の再索引化を計画する
- 日本語の実質問で検索品質を比較する
権限継承と差分更新を実装する
ベクトル検索RAGで最も重要な安全策は、検索時に閲覧権限を必ず絞り込むことです。文書を登録する時点で部署、役職、案件、機密区分を持たせ、質問者の属性に応じて検索フィルターを強制適用します。
この権限は、Embedding、検索、生成、キャッシュ、ログのすべてで一貫させます。検索結果を制御しても、共通キャッシュに別利用者の回答が残れば情報漏洩になります。アプリ、DB、監視基盤をまたぐ設計レビューが欠かせません。
改訂・削除された文書を検知し、該当チャンクを再作成または無効化する差分更新パイプラインも必要です。削除済み規程を回答し続ける状態を避けるため、原本の版、登録時刻、失効状態を記録し、定期的に整合性を検査します。
- 質問者の属性で検索対象を必ず制限する
- キャッシュとログにも認可設計を適用する
- 改訂・削除をベクトルDBへ確実に反映する
LLMOps運用で品質と安全性を継続改善する
本番運用は変更管理から始める
LLMOps運用とは、モデル、プロンプト、検索設定、データ、インフラの変更を追跡し、品質を維持する運用プロセスです。本番稼働後も回答は変化するため、初回の精度評価だけで安全性を保証することはできません。
モデルの更新時には、モデル名、量子化方式、推論設定、プロンプト、Embedding、インデックスの版を記録します。変更前後で同じ評価セットを実行し、正答性、根拠忠実性、回答不能率、レイテンシを比較してから切り替えます。
本番への反映は、検証、限定公開、段階展開、ロールバック可能な全体公開という流れにします。利用者からの指摘を受け付ける画面を設ければ、数値だけでは捉えにくい言い回しや業務文脈の不備も改善材料になります。
- モデル・データ・設定を版管理する
- 同一評価セットで変更前後を比較する
- 段階公開とロールバック手順を準備する
監視指標を品質とリスクに分ける
LLMOps運用では、技術指標と業務指標を混同しないことが重要です。技術面ではエラー率、GPU使用率、応答時間、検索ヒット率を見ます。品質面では根拠付き回答率、利用者評価、訂正率、回答不能率を追跡します。
特に、回答不能を失敗として隠さない設計が大切です。根拠が不足する質問には「該当資料を確認できません」と返し、担当窓口へ誘導する方が、推測で回答するより業務リスクを抑えられます。
監査では、誰がどのモデルに何を尋ね、どの文書を根拠にしたかを後から確認できる状態を保ちます。ただし質問ログ自体が機密情報になり得るため、マスキング、保存期限、アクセス審査を同時に運用します。
- 可用性・性能・回答品質・安全性を分けて計測する
- 回答不能を安全な行動として設計する
- 監査可能性とログの機密性を両立する
内製と伴走支援の役割を明確にする
運用を定着させるには、業務部門、情報システム、セキュリティ、AI開発担当の役割を分けます。業務部門は正解と更新対象を定義し、情報システム部門は基盤と認証を担い、開発担当は検索・モデル・評価の改善を進めます。
ALION株式会社のように専属チームで伴走する開発体制を活用する場合も、文書の責任者と受入判断を顧客側に残すことが重要です。外部支援は設計と実装を加速できますが、業務知識とガバナンスを代替するものではありません。
教育では、プロンプトの書き方だけでなく、回答を鵜呑みにしないこと、出典を確認すること、機密情報の扱い、誤回答の報告方法を伝えます。利用ルールを画面内にも示すことで、研修後の実務でも判断基準を維持できます。
- 業務・基盤・セキュリティ・開発の責任を分離する
- 外部支援の範囲と最終責任を明文化する
- 利用者教育に検証方法と報告手順を含める
まとめ
オンプレLLMの価値は、モデルを社内で動かすことだけではありません。データの統制、適切なAI推論基盤、根拠を示す検索、継続的な評価と運用をつなげることで、機密業務でも使える生成AI環境になります。
要点
- 導入判断は、機密度・同時接続数・応答時間・TCOを起点に行う。
- RAG構築では、文書品質、権限継承、改訂時の差分更新を優先する。
- ベクトル検索RAGは、ハイブリッド検索と実業務の評価セットで精度を高める。
- LLMOps運用では、モデル・データ・設定の変更管理と監査を継続する。
- 小さな対象業務でPoCを行い、定量評価を通過してから展開する。
まずは、対象業務を一つ選び、利用者、データ区分、質問例、受入条件を一覧化してください。その要件を基に、必要なGPU、検索方式、認証連携、運用体制を比較すれば、自社に適した導入方式を具体的に判断できます。
よくある質問
Q1. オンプレLLMとクラウドLLMは、どちらを選ぶべきですか？
機密データを外部に出せない、閉域環境で使う、利用量が安定している場合はオンプレミスが候補です。一方、短期間の検証、利用量の変動が大きい業務、最新モデルを迅速に試したい場合はクラウドが適します。要件ごとに併用する方法も有効です。
Q2. オンプレLLMは小型モデルでも業務で使えますか？
使えます。定型FAQ、要約、分類、検索結果に基づく回答では、小型モデルでも実用的なケースがあります。ただし、モデル単体の能力だけで判断せず、RAGの検索精度、プロンプト、出典表示、業務担当者による検証を組み合わせて評価してください。
Q3. RAG構築で最初に準備すべきものは何ですか？
更新責任者が明確な文書、実際の質問例、利用者の権限情報、受入基準の四つです。PDFを大量に登録する前に、正しい原本か、抽出品質に問題がないか、改訂や削除をどう反映するかを確認すると、後工程の手戻りを抑えられます。
Q4. ベクトル検索RAGで誤回答を減らす方法はありますか？
ハイブリッド検索、re-ranking、権限フィルター、出典表示を組み合わせることが有効です。さらに、実際の問い合わせから作った評価セットで検索漏れと根拠忠実性を測り、回答できない質問には推測せず担当窓口へ誘導する設計にしてください。
Q5. LLMOps運用で最低限必要な管理項目は何ですか？
モデルとプロンプトの版管理、文書更新の反映、品質評価、応答時間とエラーの監視、監査ログ、障害時の復旧手順が基本です。変更のたびに同じ評価セットで結果を比較し、問題があれば元の構成へ戻せる状態を維持します。
参考文献・出典
 # RAG構築とは？仕組み・作り方・社内導入の注意点を実演付きで解説   #…
aitip.jp
[](https://japan-ai.co.jp/media)…
japan-ai.co.jp