「クラウド禁止」を突破せよ：機密情報を守るオフラインLLM構築・6ヶ月の全記録

はじめに

「OpenAIの公式情報によると、GPT-4o等のレガシーモデルが廃止され、長い文脈理解や高度な汎用知能を備えたGPT-5.2が新たな標準モデルへと移行するなど、ChatGPTは急速な進化を続けています。こうした最先端のAIを使えば業務効率が上がるのは分かっている。でも、うちはセキュリティ規定でクラウドへのデータアップロードが一切禁止されているんだ」

ここ数年、製造業や金融機関のDX推進担当者が、このような悩みを抱えるケースは珍しくありません。目の前に便利な道具があるのに、ガラスの壁に隔てられて触れることができない。そんなもどかしさを抱えている現場が日本中にどれほどあるでしょうか。

近年、クラウドAIの利用制限に対する代替手段として、「完全オフライン環境でのLLM（大規模言語モデル）構築」へのニーズが高まっています。

本記事では、厳格なセキュリティ規定を持つ組織を想定し、「クラウド禁止」というルールの下で、いかにして社内の膨大な技術文書をAIに読ませ、要約させ、技術継承の武器に変えるか、その実践的かつ論理的なアプローチを解説します。

セキュリティ審査の壁、ハードウェアリソースの限界、そして「嘘をつくAI」への不信感。これらを一つずつ乗り越えていくための具体的なステップを、技術的な裏付けとともに共有します。もしあなたが、セキュリティと利便性の狭間で悩んでいるなら、この実証に基づいたアプローチが「自社でも導入できるかもしれない」という希望の灯火になるはずです。

プロジェクト概要：なぜ「SaaS型」ではなく「自前構築」だったのか

創業50年の製造業が抱えていた「埋没する技術資産」

従業員数2,000名規模の精密機器メーカーの事例を考えてみましょう。高い技術力を誇る組織であっても、そのノウハウの多くは、社内ファイルサーバーの深層に眠る多数のファイルの中に埋もれがちです。

設計書、トラブルシューティング報告書、実験データ。これらは本来、企業の競争力の源泉となる「資産」です。しかし、検索性の低さがその価値を殺してしまっているケースが多々あります。若手エンジニアが過去の不具合事例を探そうとしても、キーワード検索では多数のファイルがヒットし、必要な情報を見つけるまでに時間がかかってしまいます。結果として、ベテラン社員に直接質問するケースが多くなり、ベテラン社員の貴重な時間が奪われ続けるという状況に陥りやすいのです。

社内セキュリティ規定という高く厚い壁

「それなら、今流行りのRAG（検索拡張生成）を使って、社内版ChatGPTを作ればいいじゃないか」

経営層からはそんな声もよく上がります。しかし、情報システム部門からはセキュリティ上の懸念が示されるのが一般的です。取り扱う製品図面や技術データは機密性が高く、外部クラウドサービスへのデータ送信は許可されません。

「インターネットにデータを出してはならない」

これは、オンプレミス環境での構築プロジェクトにおいて、よく提示される絶対条件です。クラウドサービスが利用できないため、社内のサーバルームに自前のGPUサーバーを立て、そこでオープンソースのLLMを動かす「オンプレミス・オフラインLLM」を構築するという選択肢が浮上します。

直面していた課題：検索だけでは辿り着けない「知の共有」

キーワード検索の限界と若手エンジニアの疲弊

既存の全文検索システムでは、必要な情報にたどり着くまでに時間がかかるという課題が実証データからも明らかになっています。現場のエンジニアからは、「ドキュメントが見つからないこと」ではなく、「見つかりすぎること」に課題があるという声が多く聞かれます。

例えば「温度センサー 異常値」で検索すると、過去の議事録から日報まで、多数のファイルがヒットします。彼らが本当に知りたいのは、「過去に同様の異常値が出た際、最終的に何が原因で、どう対処したのか」という結論と文脈です。

従来の検索エンジンは単語の一致を見つけることは得意ですが、文脈を理解して要約することはできません。一つ一つのファイルを開き、読み込み、関係ないファイルを閉じる。この作業に膨大な時間がかかっているのが実態です。

ベテランの暗黙知がドキュメントの山に埋もれるリスク

さらに深刻なのが、技術伝承の問題です。ベテランエンジニアが作成した過去の技術報告書には、数値データには表れない「考察」や「試行錯誤の経緯」が記されています。これらは、特定のキーワードで検索しにくいニュアンスを含んでいます。

AIには、単なる検索結果のリストアップではなく、「この現象に関連する過去の事例を要約して教えて」という問いに答えてくれることが期待されます。

目指すべきゴールは、「社内ドキュメントを読み込み、文脈を理解して回答を生成する、完全オフラインのAIアシスタント」となります。

選定プロセス：限られたリソースで動く「最適解」を探して

Llama vs Mistral vs Gemma：日本語性能と軽量化のバランス

オンプレミス環境構築において、最初にして最大の技術的ハードルはモデルの選定です。クラウドAPIとは異なり、自社のハードウェアリソースで動作し、かつ実用的な日本語性能を持つモデルを論理的に見極める必要があります。

主な検討候補となるのは、Metaの「Llamaシリーズ」、Mistral AIの「Mistralシリーズ」、そしてGoogleの「Gemmaシリーズ」といったグローバルなオープンモデルです。これに加え、日本語能力を強化した国産モデルや、Alibabaの「Qwenシリーズ」なども有力な選択肢に入ります。

選定において重視すべき軸は、一般的に以下の3点です。

1. 日本語の流暢さと読解力（特に社内文書や技術用語の理解）
2. 推論効率（限られたVRAMでの動作とレスポンス速度）
3. ライセンスと商用利用の可否

近年のトレンドとして、Mistral AIからはコード生成に特化した「Devstral 2」モデルを搭載したターミナルベースのコーディングエージェント「Mistral Vibe 2.0」や、高速高精度な文字起こしを行う「Voxtral」、さらには128kの長文脈と画像入力に対応した24Bパラメータの中型モデル「Mistral Small 3.2」などが登場しており、用途に応じた選択肢は多様化しています。

一方で、MetaのLlamaシリーズも大きな進化を遂げています。汎用チャット向けの「Llama 3.3」は1Bから405Bまでの幅広いサイズ展開と128kコンテキスト対応を実現しました。さらに「Llama 4」では、MoE（Mixture of Experts：専門家モデルの組み合わせ）アーキテクチャの導入による推論効率の向上や、マルチモーダル対応、最大1,000万トークンという超長文脈処理が可能になっています。

ただし、モデル選定時には注意すべき点もあります。Llama 4では対応言語がLlama 3の30言語から12言語へと縮小されており、Llama 3.3も英語中心の設計であるため、そのままでは日本語性能が十分とは言えないケースがあります。そのため、日本語の処理を最優先する場合は、Llamaをベースに日本語能力を強化した「Llama Swallow」やELYZAの派生モデル、あるいは日本語性能に定評のある「Qwen3」シリーズを優先的に検証することをお勧めします。

RAG（検索拡張生成）システムを構築する際、初期段階では「日本語特化モデル」が有利と考えられがちです。しかし、多くの検証事例において、基礎的な推論能力が高いグローバルな汎用モデル（LlamaやMistralの上位モデル）に、適切な日本語プロンプトを与えるアプローチの方が、結果として複雑な指示を正確に遂行できる傾向にあります。特に、誤った情報の生成（ハルシネーション）を抑制し、指示に対する忠実度（Instruction Following）を保つ点では、パラメータ規模の大きいベースモデルが有利なケースが少なくありません。

GPUサーバー調達の予算制約とサイジングの現実

モデルの方針が決まれば、次はそれを動かすためのハードウェア選定です。データセンタークラスのGPU（H100やA100など）を潤沢に用意できれば理想的ですが、オンプレミス環境構築においては予算の制約が常につきまといます。

ここで鍵となるのが、「量子化（Quantization）」技術の活用です。
通常、LLMのパラメータは16ビット（FP16/BF16）や32ビット（FP32）といったデータ形式で表現されますが、これを4ビットや8ビットに圧縮することで、モデルの精度劣化を最小限に抑えつつ、メモリ使用量を劇的に削減できます。

例えば、700億（70B）パラメータクラスの高性能モデルであっても、4ビット量子化を適用することで、VRAM 48GB程度のメモリ容量があれば動作可能です。これは、NVIDIA RTX 6000 Ada世代や、複数枚のRTX 4090（24GB x 2）といったワークステーションレベルの構成で実現できる範囲です。また、MoEアーキテクチャを採用した最新モデル（Llama 4など）の場合、パラメータの総数は多くても推論時にアクティブになるパラメータは一部に限定されるため、量子化と組み合わせることでさらに効率的な運用が期待できます。

「高額な専用サーバーではなく、ハイスペックなワークステーションで運用する」という選択肢は、機密情報を守りつつコストを最適化する上で、極めて実践的で現実的な解となります。

実装フェーズ：RAG（検索拡張生成）をオフラインで組む

社内Wikiとファイルサーバーをどう連携させたか

システム構成の中核となるのは、RAG（Retrieval-Augmented Generation）アーキテクチャです。これは、ユーザーの質問に関連する情報を社内データベースから検索し、その検索結果をAIに「参考資料」として渡すことで、AIが学習していない社内固有の情報についても回答できるようにする仕組みです。

実装には、LLMアプリ開発フレームワークである「LangChain」などが採用されることが一般的です。しかし、ここでオフライン環境特有の課題が発生します。通常、Pythonのライブラリはインターネットからダウンロードしますが、本番環境のサーバーはインターネットに繋がっていません。

そのため、開発環境でビルドしたDockerコンテナイメージをファイルに出力し、それを物理メディア（またはセキュリティチェック済みの踏み台サーバー）経由で本番サーバーに持ち込むデプロイ手順が必要となります。また、Hugging Faceなどのモデルハブからモデルデータをダウンロードする際も、一度ローカルに落としてから転送する工夫が求められます。

ベクトルデータベースのローカル運用とセキュリティ担保

ドキュメントの検索には、テキストの意味を数値ベクトルに変換する「Embedding（埋め込み）」技術と、それを高速に検索する「ベクトルデータベース」が必要です。

Embeddingモデルには、多言語対応で精度の高い「intfloat/multilingual-e5-large」などを採用し、これもローカルサーバー内に配置するアプローチが有効です。ベクトルデータベースには、軽量で管理が容易な「ChromaDB」や「FAISS」も候補に挙がりますが、永続化とスケーラビリティを考慮し、Dockerコンテナで動作する「Qdrant」が選定されるケースが多く見られます。

ここで極めて重要なのが、アクセス権限の管理です。「一般社員が役員会議の機密議事録をAI経由で読めてしまった」という事態は絶対に避けなければなりません。ドキュメントのメタデータにアクセス権限情報を付与し、検索を実行する前にユーザーの権限でフィルタリングをかけるロジックをRAGパイプラインに組み込む必要があります。これにより、「AIは知っているが、権限のないユーザーには教えない」という制御を実現し、セキュリティ部門の要件を満たすことを目指します。

困難と克服：ハルシネーションと「遅い」という苦情

嘘をつくAIへの不信感をどう払拭したか

プロトタイプを現場のエンジニアに公開した際、よく寄せられるフィードバックがあります。
「この回答、もっともらしいけど数字が間違っているぞ」

生成AI特有の「ハルシネーション（もっともらしい嘘）」です。特に技術文書の場合、数値の間違いは致命的であり、現場の信頼を損なう可能性があります。

対策として、以下の3つのアプローチが実証的に有効です。

1. 回答には必ず「根拠となるドキュメントへのリンク」を併記させる：UI上で「この回答は以下の資料を参考にしました」と明示し、ユーザーが原文をすぐに確認できるようにします。
2. 「分からないことは分からないと言う」プロンプト制御：検索結果に関連情報が含まれていない場合、無理に回答を作らせず、「社内ドキュメントに関連情報が見当たりませんでした」と答えさせるよう、システムプロンプトを厳密に調整します。
3. 引用箇所のハイライト表示：回答のどの部分がどのドキュメントに基づいているかを可視化します。

これにより、AIは「全知全能の神」ではなく、「文献調査を代行してくれる優秀なアシスタント」であるという正しい認識を持ってもらうことが重要です。

推論待ち時間を短縮するためのキャッシュ戦略

もう一つのよくある不満は「回答が遅い」ことです。クラウドの高速なAPIに慣れていると、ローカルGPUでの生成速度は遅く感じられがちです。

これに対しては、「セマンティックキャッシュ」を導入することが効果的です。過去に似たような質問があった場合、再度LLMに推論させるのではなく、過去の回答をキャッシュから即座に返す仕組みです。全く同じ質問でなくても、意味的に近ければヒットするように設定します。

また、ストリーミングレスポンス（文字が順次表示されるUI）を実装することで、体感的な待ち時間を減らす工夫も有効です。ユーザーは「待たされている」のではなく「AIが処理している」と感じるようになり、不満を大きく軽減できます。

成果と展望：セキュリティ審査を通過した実績がもたらした変化

情報検索時間が短縮

正式版の運用を開始すると、明確な効果がデータとして表れ始めます。設計部門での計測事例では、過去のトラブル事例調査にかかる時間が大幅に短縮されたという報告があります。

「以前なら時間をかけてフォルダを調べていた調査が、AIに聞いて、提示されたファイルをざっと読むだけで終わるようになった。空いた時間でより創造的な作業ができる」という声も聞かれます。何より大きいのは、ベテランエンジニアたちが協力的な姿勢を見せてくれるようになることです。彼らが自分のローカルPCにあるメモ書きや古い資料を、AIの学習用フォルダに自発的に入れてくれるようになるなど、知見共有の文化が育つという副次的な効果も期待できます。

「これなら使える」という現場の安心感

そして、プロジェクトの最大の成果は、厳格なセキュリティ委員会から「正式運用承認」を得られることです。

「外部との通信遮断」「アクセス権限の継承」「ログのトレーサビリティ」。これらの要件をオンプレミス環境で論理的に満たすことで、これまでAI活用に慎重だったセキュリティ部門が、AI推進の強力なパートナーへと変わります。

「クラウド禁止だからAIは無理」ではなく、「クラウド禁止なら、安全な環境でAIを活用すればいい」。この発想の転換が、組織全体のAIリテラシーを引き上げ、結果として製造現場での音声入力AIや、自動コードレビューシステムへの展開が検討される企業も増えています。

担当者からのアドバイス：これからオフラインLLMに挑むあなたへ

「完璧な精度」を目指さない勇気

もしあなたが、これからオフラインLLMの構築に挑むなら、「最初から完璧を目指さないこと」を意識してください。

汎用的なクラウドAIモデルと、自社のオンプレミス環境を単純な性能スペックで比較するのではなく、「自社の専門的なデータを知っている」という独自の価値を重視することが、プロジェクト成功の第一歩です。

まずは特定部署の特定文書から小さく始める

全社のドキュメントをいきなり対象にするのではなく、例えば「品質保証部の過去のトラブル報告書」のように、対象を絞って小さく始めてください。特定のドキュメント群であれば、仮説検証とチューニングが回しやすく、効果も定量的に測定しやすいからです。

そして、「セキュリティ部門を初期段階から巻き込むこと」が極めて重要です。彼らを安全なシステムを作るためのアドバイザーとしてチームに迎え入れることが、プロジェクトを円滑に進める鍵となります。

オフラインLLMの構築は技術的なハードルがありますが、「自社の知財を自分たちの手で守り、最大限に活かす」という大きな価値があります。技術的な選定や具体的なアーキテクチャ設計で迷うことがあれば、専門家に相談することも有効な手段です。