ローカルLLM RAGの作り方｜社内文書を読ませる手順とクラウドとの差

ローカルLLM RAGとは、会社のPCや社内サーバーで動くLLMに、社内文書を検索してから答えさせる仕組みのことです。社員数十〜200名の会社であれば、まず小さな文書群で試してみて、閲覧権限と更新の担当まで決められそうな場合にだけ自社構築へ進むのが、無理の少ない判断になります。GPUや費用の全体像はローカルLLMとは何かの記事にまとめていますので、こちらでは社内文書を読ませる手順と、クラウド型との違いを中心にお話しします。

RAGとは何か｜LLM単体では社内文書を知らない

RAGとは、LLMに答えさせる前に、社内文書の中から関係する文章を探して渡す仕組みになります。LLMは単体のままだと、会社の就業規則や営業資料、マニュアル、過去の稟議書を最初から知っているわけではありません。

たとえば、社員の方が「育児休業の申請はいつまでですか」と聞いたとします。LLM単体に聞くと、一般論をそれらしく返してくることがあります。社内規程の文言と違う答えが混ざると、総務の方があとで直す仕事が増えてしまいます。

RAGでは、先に文書検索を走らせることになります。就業規則や社内FAQから近い文章を取り出して、その文章を材料にLLMが答える流れです。「資料にないことは答えない」「参照元を示す」という指示も一緒に入れておけば、一般論だけで進む回答を減らすことが出来ます。

ただし、RAGを入れれば何でも正しくなるわけではありません。検索で違う文章を拾えば回答もずれてしまいますし、小型モデルでは根拠の引用がぶれることもあります。RAGの良し悪しは、LLMの賢さだけでなく、文書の整え方と検索の当たり方で決まります。

まず決めておきたいのは、何を答えさせたいかという点になります。社員の手続き、製品仕様、営業ナレッジ、契約書の確認では、必要な文書も、許せる回答の範囲も変わってきます。最初は1つの問いに絞って、答えられるかどうか試してみてください。

作る前の4問判断表｜ローカルで作るか、既製サービスを使うか

ローカルLLM RAGが候補になるのは、社外に出せない文書を扱うときです。ただ、実際に作る価値がある会社と、既製の法人向けサービスやファイル添付で足りる会社とに分かれます。

社員数十〜200名の会社では、専任のAI開発チームがいないことも多いでしょう。最初に次の4つの問いで分けてみると、社内の話し合いがかなり楽になります。金額ではなく、作業の有無と担当の種類で見てみてください。

実際に大事になるのは、作れるかどうかより、作った後の運用を社内で持ち続けられるかどうかです。Mac mini（M6）16GBは149,800円（税込）から、Mac Studio（M5 Max）36GBは419,800円（税込）からと公式に表示されています。これは最小構成の価格で、RAGでは埋め込みモデルも一緒に動くため、メモリを増やした構成を選ぶ場面も多くなります。検証用と本番用で2台に分けると、最小構成でもMac miniで299,600円、Mac Studioなら839,600円からの出費となってしまいます。

GeForce RTX 5090は32GB、RTX 5080・5070 Ti・5060 Ti（16GB版）は16GBのVRAMを持つことが、NVIDIAの公式比較表で確認出来ます。価格は販売店や時期で変わるため、購入するときに確かめてみてください。購入の前に、社内で使うモデルのサイズと、同時に何人が待てるかを決めておきましょう。

ローカルで作る理由が弱いようであれば、RAGサービス比較で既製サービスを並べてみたほうが早いこともあります。社内で作る手間と、既製サービスを使う手間を同じ表に置いてから、先へ進んでみてください。

ローカルLLM RAGの構成｜文書から回答までの流れ

ローカルLLM RAGは、文書を小さく分け、数値のベクトルに変え、検索してからLLMへ渡す、という流れになります。この順番が分かっていると、どこで精度が落ちているのかも見つけやすくなるでしょう。

最初に、PDFやWord、テキストなどの社内文書を用意します。LM Studioの文書チャットでは、docx、pdf、txtをチャットに添付できると公式ドキュメントに書かれています。短い文書でモデルのコンテキストに収まる場合は全文を会話に入れ、とても長い場合はRAGを使う形へ自動で切り替わるという説明になります。

次に、文書をチャンクに分けていきます。チャンクとは、検索の単位になる短い文章のかたまりのことです。見出しや段落で切っておくと、人が読んでも意味の通る単位になりやすいでしょう。表はそのまま抽出すると崩れることがあるため、Markdownの表にしてから入れたほうが確認しやすくなります。

その後、埋め込みモデルで文章を数値ベクトルに変えます。Ollamaの公式ドキュメントでは、埋め込みはテキストを数値ベクトルに変え、ベクトルDBに保存し、コサイン類似度で検索したりRAGパイプラインで使ったり出来るもの、と説明されています。ベクトルの長さはモデルによって変わり、典型的には384〜1024次元になるとのことです。

ベクトルDBには、Chromaのようなオープンソースのデータ基盤を使うことが出来ます。ChromaはApache 2.0ライセンスのオープンソースとして公開されています。質問が来たら、同じ埋め込みモデルで質問もベクトルにして、近い文書チャンクを探す仕組みです。

最後に、見つけた文書チャンクと質問をLLMへ渡します。このとき、プロンプトに「資料にない内容は答えない」「回答に使った参照元を示す」と入れておいてください。一般論で補ってしまいがちなモデルほど、ここを強めに書いておく必要があります。

流れは単純に見えても、失敗はそれぞれの段階で起きてしまいます。文書が古い、分け方が荒い、埋め込みモデルを途中で変えた、検索で関係ない断片を拾った、LLMが参照元を取り違えた、という順で確かめていきましょう。OllamaのTipsでも、登録時と質問時で同じ埋め込みモデルを使うよう示されています。

道具とPCの選び方｜GUI完結とコード実装を分ける

道具は、まずGUIで触ってみるものと、コードで作り込むものに分けて考えると選びやすくなります。総務や経営者の方が動きを確かめる段階であれば、GUIから始めたほうが話が早いでしょう。

LM Studioは、チャットに文書を添付して試すことが出来ます。公式ページでは、RAGはうまくいくこともあれば、調整と試行が要ることもあると説明されています。質問には、資料に出てきそうな言葉や考え方をなるべく多く入れてみてください。

AnythingLLMは、文書とのチャット、複数ユーザー、ベクトルDB、文書パイプラインを掲げるMITライセンスのプロジェクトになります。PDF、TXT、DOCXなど複数の文書形式が挙げられていて、ドラッグアンドドロップでのアップロードや、出典表示つきのチャット画面も説明に入っています。

ただし、AnythingLLMで複数人の利用と権限設定が出来るのはDocker版だけ、というのがGitHubの記載です。デスクトップ版は無料でアカウントも要らず、macOS、Windows、Linuxのネイティブ版があり、モデルや文書、チャット履歴は手元の機械に残ると同社は説明しています。社内で使うのであれば、サイドバーのPrivacyからテレメトリーを止める設定も確かめておいてください。

コードで作る場合は、OllamaでLLMや埋め込みモデルを動かし、LangChainなどの実装用ライブラリで処理をつなぎ、ChromaのようなベクトルDBに保存する構成が候補になります。GUIでは足りない検索条件や取得件数、権限の絞り込みまで作り込める一方で、画面、認証、ログ、エラー時の確認もすべて自分たちで見ることになってしまいます。

PCは、動かすモデルの大きさと、どれくらいの待ち時間なら許せるかで決めることになります。LM Studioは16GB以上のRAMを推奨しており、Windows x64ではAVX2が必要で、専用VRAMは4GB以上が推奨とされています。RAGではLLMだけでなく、埋め込みモデルや、場合によっては検索結果を並べ直すモデルも動くため、余裕は多めに見ておいたほうが扱いやすいでしょう。

モデル選びでは、ライセンスと日本語での使い勝手を分けて見ていきます。gpt-oss-20bはApache 2.0で、総21B、活性3.6B、16GBのメモリで動作するよう設計されたとOpenAIは自己申告しています。Ollamaでのダウンロードサイズは14GBです。

qwen3.5 9bは6.6GB、27bは17GB、gemma4 26bは約16〜19GBとOllamaライブラリに表示されています。実行時にはコンテキストの分だけ追加のメモリが要るため、ダウンロードサイズだけでPCを決めないようにしてください。なお、Llama 4は独自ライセンスで、Scoutの公式対応12言語に日本語は含まれていません。

埋め込みモデルについては、Ollamaがembeddinggemma、qwen3-embedding、all-minilmを推奨モデルとして示しています。bge-m3はBAAIのモデルで、567m、1.2GB、8Kコンテキストで、100以上の作業言語を支えると表示されます。embeddinggemmaはGoogleの300Mパラメータの埋め込みモデルで、622MB、2Kコンテキスト、100以上の話し言葉のデータで訓練されたという説明になります。

DeepSeekなど、ほかのモデルを候補に入れる場合は、配布元のライセンスや商用利用の条件、日本語での検証結果を別に確かめておきましょう。モデル名だけで選ぶと、後からライセンスや日本語回答の揺れで戻ることになってしまいます。

実際に作る手順｜LM StudioとAnythingLLMで試す

最初のPoC（小さく試す検証）は、社内の一部の文書だけで作るのが現実的になります。いきなり全社の文書を入れてしまうと、誤回答の原因も権限の問題も切り分けにくいでしょう。

LM Studioで試す場合は、まずローカルで動かすモデルを用意してから、チャットに文書を添付します。添付できるのは、公式ドキュメントではdocx、pdf、txtと示されています。短い文書なら全文が会話に入り、とても長い文書ならRAGを使う形へ切り替わるため、同じ質問を短い文書と長い文書で試してみると、動きの違いがよく分かります。

質問を書くときは、資料の中にありそうな単語を入れるのがコツになります。たとえば「休職」だけでなく、「私傷病」「復職」「診断書」のように、資料の見出しや本文に出てきそうな言葉を混ぜてみてください。LM Studioの公式ドキュメントでも、関連する資料にありそうな用語や考え方、言葉を質問に入れることがコツとして挙げられています。

AnythingLLMで試す場合は、まずデスクトップ版で1人での検証を済ませるとよいでしょう。文書をドラッグアンドドロップして、出典表示つきで答えが返ってくるかを見ていきます。業務で使う段階へ進むなら、複数ユーザーと権限設定がDocker版だけという点を前提に考えてください。

コード実装へ進む場合は、文書の取り込み、チャンク化、埋め込み、ベクトルDBへの保存、検索、LLMへの受け渡しを、それぞれ分けて作っていきます。Ollamaで埋め込みを作るときは、登録時と質問時で同じ埋め込みモデルを使うことになります。途中で埋め込みモデルを替えた場合は、文書側のベクトルも作り直す前提で考えておきましょう。

最初に入れる文書は、社内規程のうち公開範囲がはっきりしているものか、公開されているサンプル文書が向いています。総務の方が関わるのであれば、厚生労働省のモデル就業規則を使うと、本物の自社規程を入れる前に精度を確かめることが出来ます。条番号や日数を覚えさせるのではなく、参照元に沿って答えられるかを見てみてください。

PoCで見たいのは、答えが上手かどうかだけではありません。どの文書を参照したか、参照元の書き方が読めるか、違う質問をしたときに同じ箇所へ引っ張られすぎていないか、資料にないことを聞かれたときに止まれるか、といった点も大切になります。担当者だけでなく、実際に使う部署の方にも質問してもらいましょう。

精度を上げる準備｜チャンク、前処理、検索の調整

RAGの精度は、文書を入れる前の掃除で大きく変わってきます。モデルを大きくする前に、重複や古い版、表の崩れを減らしておきましょう。

チャンクは、見出しと段落をなるべく一緒に残すのがおすすめです。見出しだけ、本文だけに分かれてしまうと、検索で拾われた断片の意味が薄くなってしまいます。社内規程であれば、章、条、項のまとまりを崩しすぎないほうが読みやすいでしょう。

表は、PDFから抽出すると列が混ざることがあります。給与テーブルや休暇の対象者一覧、承認フローの表が崩れると、LLMは別の列をつないで答えてしまいます。人が見て意味の通るMarkdownの表に直してから入れると、確認もしやすくなります。

重複と古い版は、回答の精度を下げる代表的な例です。IPAサイトに掲載されている「テキスト生成AIの導入・運用ガイドライン」でも、回答精度を低下させる情報の例として、ノイズが含まれる情報、重複した情報、最新版ではない古い情報が挙げられています。文書フォルダに旧版が残っている会社ほど、ここでつまずきやすくなってしまいます。

検索をベクトル検索だけに頼ると、品番や条番号、部署名のような文字列を取りこぼすことがあります。そこで候補になるのが、キーワード検索とベクトル検索を併用するハイブリッド検索です。検索結果をもう一度並べ替えるリランクも、関係の薄いチャンクを下げるために使われています。

LM Studioの文書ページには、チャンク分割、取得数、再ランク、閲覧権限、複数人共有の設定項目は記載されていません。まずGUIで足りるかを試してみて、足りないところだけコード実装へ進む順番にすると、作り込みすぎを避けやすくなります。

プロンプトも合わせて調整していきます。おすすめは、回答のルールを短く決めて固定しておくことです。「渡された資料だけで答える」「資料にない場合は分からないと答える」「参照元の文書名を出す」「判断が分かれる場合は人に確認する」といった形で入れておくとよいでしょう。資料にないことをもっともらしく補う回答は、PoCの段階で必ず落としてください。

よくある失敗は、精度が低い原因をすぐLLMのせいにしてしまうことです。実際には、文書抽出の崩れや古い版、チャンクの切り方、検索語の不足で起きていることも少なくありません。回答を責める前に、検索で拾われた断片を一度のぞいてみましょう。

権限管理の落とし穴｜全社文書を1つに入れない

社内文書RAGで怖いのは、文書が社外に出てしまうことだけではありません。ローカルに閉じていても、見せてはいけない文書を社内の別の方へ見せてしまう問題が残ります。

たとえば、人事評価や給与、役員会資料、個別の労務相談を、1つのベクトルDBにまとめて入れたとします。質問した方が本来その文書を見られない立場でも、検索で断片が拾われれば、回答に混ざってしまうおそれがあります。社外には出ていなくても、社内での情報漏れとなってしまいます。

IPAサイト掲載のガイドラインでは、RAGに使うデータに機密情報や個人情報が含まれる場合について、アクセス制限やデータの定期的な棚卸しに触れています。同じ資料には、ベクトルDBに機密情報を含むデータを格納した場合、全てのユーザが機密情報を参照できる、という趣旨の注意もあります。

実装の面では、部署ごとにベクトルDBを分ける形が使えます。総務用、営業用、管理職用のように分けておけば、検索対象を最初から狭めることが出来ます。もう一つは、文書ごとに閲覧できる部署や役職の情報を持たせて、検索するときに質問者の属性で絞り込む方法になります。

どちらの方法でも、作る前に社内の権限表が欠かせません。ファイルサーバーの権限が整理されていない会社では、RAGだけをきれいに分けるのは難しいでしょう。まずは、誰が見てよい文書なのかを、総務と情シスで紙に書き出してみてください。

Microsoft 365 Copilotは、個々のユーザーが少なくとも表示アクセス許可を持っている組織データのみを表示すると説明されています。クラウド型が既存の権限を引き継ぐ例です。ローカルで自作する場合は、この権限の考え方を自分たちの仕組みに組み込む必要が出てきます。

OWASP LLM08:2025では、細かなアクセス制御と権限を意識したベクトルストア、信頼できる情報源だけを受け入れること、検索活動のログを残すことが対策として挙げられています。ローカルだから安全というわけではなく、誰が何を検索できるかまで決めて、初めて社内に渡せる仕組みになります。

モデル就業規則で精度テスト｜質問セットで測る

自社規程を入れる前に、公開されているモデル文書でテストしてみると、失敗が見えやすくなります。厚生労働省のモデル就業規則はWordとPDFで公開されていて、試験用の文書として使うことが出来ます。

テストでは、検索と回答の生成を分けて見ていきます。デジタル庁のリスク対策ガイドブックでは、質問文に対して関係する文章を抽出できているか、関係する文章に対してLLMの出力が合っているか、出力結果に含まれる固有名詞が関連文章内に含まれているか、という見方が示されています。

まず、モデル就業規則を1つの文書群として登録します。PDFとWordの両方を入れると重複になってしまいますので、どちらか一方にしましょう。表や見出しの崩れを比べたい場合は、PDFとWordを別々の検証環境に入れて見比べるとよいでしょう。

質問は10問ほど用意します。答えになる文章を人が先に確認して、どの文書のどのあたりを見ればよいかをメモしておきます。正解のメモ（条番号や日数）は、自分たちで作っておきましょう。

• 年次有給休暇について、取得できる条件を説明してください。
• 休職が必要になる場面には、どのようなものがありますか。
• 復職の判断では、どの資料や手続きが関係しますか。
• 服務規律で禁止されている行為を、社員向けに短く説明してください。
• ハラスメントに関する記載を探し、相談先の考え方を説明してください。
• 賃金の支払いに関するルールを、参照元つきで答えてください。
• 安全衛生に関する会社と社員の役割を説明してください。
• 退職に関する手続きで、社員が確認すべき点を挙げてください。
• 資料に書かれていない福利厚生について質問されたら、どう答えますか。
• 管理職だけが見られる資料が混ざった場合、回答に出してよいですか。

評価は、検索で正しい箇所を拾えたか、回答が拾った箇所に沿っているか、資料にないことを止められたか、の3つに分けて見ることになります。検索が外れているなら、文書の分け方や検索語を直します。検索は当たっているのに回答がずれる場合は、プロンプトやLLMを見直してみましょう。

小型モデルでは、出典の書き方が安定しないことがあります。モデルが文書名を取り違えたり、根拠を広く言い換えすぎたりする場合は、回答を短めにして、参照元を文書名だけにするなど、制約を強めてみてください。テスト質問は、導入前だけでなく、文書の更新やモデルの変更のたびに同じものを使います。

更新運用チェックリスト｜古い版を残さない

社内文書RAGの運用でいちばん残りやすい失敗は、古い版が検索に残ってしまうことです。作った直後より、半年後の文書更新のときに品質が崩れやすくなります。

就業規則や営業資料、製品マニュアルは、どれも更新されるものです。新しいファイルを入れるだけでは足りません。古い版を消し、再インデックスをかけ、テスト質問で答えが崩れていないかを確かめるところまでを、1つの運用として決めておきましょう。

• 月次で見ること文書フォルダに旧版、下書き、重複が残っていないかを見ます。回答ログから、よく聞かれる質問と誤回答の傾向も拾います。
• 文書改定時に見ること改定後のファイルを登録し、旧版を検索対象から外します。文書名に日付や版を入れ、どれが現行か分かる形にします。
• モデル入れ替え時に見ること同じテスト質問を投げ、検索結果と回答の変化を見ます。埋め込みモデルを替えた場合は、文書の登録をやり直します。
• 誤回答が出た時に見ること回答だけでなく、検索で拾ったチャンクを確認します。文書が悪いのか、検索が外れたのか、LLMが補ったのかを分けます。
• 権限変更時に見ること異動、昇格、退職に合わせ、検索できる文書の範囲を変えます。管理職と一般社員で同じ質問の回答が変わるかも見ます。

担当は1人に寄せすぎないほうがよいでしょう。総務は文書の正しさを見られますが、ベクトルDBやモデルの状態までは見にくいはずです。情シスは仕組みを見られますが、規程の意味までは判断しづらいこともあります。改定する方、登録する方、確認する方を分けて決めましょう。

ログも残しておきたいところです。誰が、いつ、どの文書群を検索し、どんな回答が出たのかを見られると、誤回答の調査が早くなります。OWASP LLM08:2025でも、検索活動の詳細なログを残すことが対策に含まれています。

現場の方には、誤回答を報告する窓口を見える場所に置いておいてください。RAGは間違えない仕組みではありません。間違いを見つけたときに、どの文書を直すのか、検索を直すのか、回答のルールを直すのかを決めて、次の作業へつなげていく仕組みになります。

会社の出費として目に入るのは、PCやサーバーの購入費だけになりがちです。しかし、更新の運用が止まってしまうと、古い回答を直す時間が後から増えていきます。金額にしにくい部分ほど、最初にチェックリストへ入れておきましょう。

クラウドとの差｜外に出さない価値と運用の重さ

ローカルLLM RAGとクラウド型の差は、データの置き場所だけではありません。自分たちで調整できる範囲と、自分たちで背負う運用の範囲も変わってきます。

ローカルの良さは、文書を社外サービスへ送らずに検証できることです。契約の上で外部サービスへ入力しづらい文書や、個人情報を含む文書を扱う場合には、大きな判断材料になります。社内の閉じたPCやサーバーで試せる安心感もあるでしょう。

一方で、ローカルは自分たちで見る範囲が広くなります。モデルの更新、埋め込みモデルの選定、ベクトルDB、バックアップ、権限、ログ、文書更新、誤回答の調査まで、すべて社内に残ります。作った方が退職した後に誰も触れない、という形になると、便利な試作品のまま止まってしまいます。

クラウド型は、契約や設定によって入力データの扱いが変わります。一律に危ない、安心、と分けるのではなく、学習に使われるか、保存場所、権限の引き継ぎ、ログ、使える文書数を確かめてみてください。Claudeのプロジェクトでは、有料プランで上限に近づくと自動でRAGモードになり、設定は要らないと説明されています。Gemini Notebook（旧NotebookLM）はソースに基づき、インラインで引用を表示しますが、無料ではノートブックあたり最大50件のソースという上限があります。

ファイルを一時的に読ませるだけなら、クラウドのファイル添付で足りる場面も出てきます。全社の文書を横断し、部署ごとに見える範囲を変え、更新後も同じ質問で確かめたいのであれば、RAGサービスや自社構築の検討へ進む段階です。ローカル構築は、機密性の答えであると同時に、運用を引き受ける選択になります。

迷ったときは、3段階で進めてみましょう。1つ目は、公開文書やモデル就業規則で動きを見ることです。2つ目に、社内で公開範囲の広い文書だけを使ってPoCを行います。最後に、権限が分かれる文書へ広げていく流れになります。この順番であれば、いきなり機密文書を入れて戻れなくなる事態を避けやすくなるでしょう。

法人向けの既製サービスを使うか、自社で構築・運用するかは、最後まで並べて考えて構いません。自社構築には自由度があり、既製サービスなら運用の一部をサービス側に任せることが出来ます。どちらかを正解と決めつけず、自社の文書量や権限、IT担当、社外に出せない契約があるかどうかで決めてみてください。

よくある質問