ローカルLLM×RAG構築入門｜社内文書を安全に活用

こんにちは。ローカルLLMと社内文書検索システムの構築を支援する、株式会社オレンジソフトウェアです。

オレンジソフトウェアは、企業向けの業務システム・Webシステム開発に加え、ローカルLLM、RAG、オンプレミス生成AIなど、社内情報を安全に活用するためのAI環境づくりを支援しています。

また、私たちはプログラミング教室で以前からAIを教える立場として、技術を初めて学ぶ方と向き合ってきました。その経験から、AIは専門用語を並べるだけでは正しく伝わらず、「何ができるのか」「どこに注意すべきか」「仕事でどう使うのか」を具体的に説明することが大切だと考えています。システムを開発する側と、利用者へ教える側の両方の視点を生かし、企業が無理なく運用できるAI活用をご提案しています。

「社内文書をAIに読ませたい」という要望を実現するうえで、RAGは重要な技術です。ただし、文書を登録するだけでは、正確で安全な回答にはなりません。この記事では、業務で使えるRAGを構築するための設計と評価を具体的に解説します。

この記事でわかること

ローカルLLMとRAGを組み合わせる仕組み
RAGに向く業務と慎重な判断が必要な業務
文書整備、分割、検索方式の考え方
社内文書のアクセス権を回答へ反映する方法
精度評価と継続的な改善方法

ローカルLLMを導入しただけでは、社内規程や製品マニュアルの内容を正確に回答できません。そこで利用されるのが**RAG（検索拡張生成）**です。質問に関連する社内文書を検索し、その内容を根拠としてLLMに回答させます。

ローカルLLMとRAGを組み合わせれば、文書を外部へ送信せずに、社内専用の検索・問い合わせ環境を構築できます。

RAGの基本的な流れ

RAGは、次の順序で動きます。

社内文書から文字を抽出する
文書を検索しやすい単位に分割する
各断片を数値表現へ変換し、検索用DBへ登録する
利用者の質問に近い断片を検索する
検索結果と質問をローカルLLMへ渡す
根拠となった文書名や箇所とともに回答する

LLM自体へ全社文書を再学習させる方法と比べ、文書を追加・更新しやすく、回答根拠を示しやすいのが特徴です。

RAGが向いている業務

就業規則や申請手順への社内問い合わせ
製品マニュアル、保守記録、過去障害の検索
契約書や議事録の要点確認
営業資料や提案事例からの下書き作成
品質文書、研究資料、設計標準の横断検索

回答が人命、法的判断、金銭処理に直結する用途では、AIだけで確定せず、出典を確認して担当者が判断する仕組みにします。

精度を左右する文書整備

RAGの精度はモデルだけでなく、元文書の品質に大きく左右されます。古い版と最新版が混在していないか、スキャン画像から文字を正しく抽出できるか、表や図の意味を保持できるかを確認します。

文書には、タイトル、部署、版、発行日、機密区分、閲覧権限などのメタデータを付与します。検索時に部署や最新版だけへ絞り込めるため、誤った資料を根拠にするリスクを減らせます。

文書の分割と検索方式

長い文書を丸ごと検索単位にすると、関係のない内容が混ざります。細か過ぎると前後関係が失われます。見出し、段落、表など文書構造を考慮して分割し、少し重なりを持たせる方法が一般的です。

検索では、意味の近さを使うベクトル検索と、製品番号や固有名詞に強いキーワード検索を組み合わせると安定します。取得した候補を再順位付けし、質問との関連が低い文書を除外する方法もあります。

アクセス権限は検索前に適用する

RAGでは、元ファイルを開けない利用者に、その内容を回答してはいけません。利用者の部署や役割を確認し、検索対象を許可された文書に限定します。

文書の登録時だけでなく、異動、退職、組織変更、文書廃棄に合わせて権限とインデックスを更新する仕組みが必要です。質問、検索結果、回答のログにも機密情報が含まれる可能性があるため、閲覧者と保存期間を決めます。

回答画面に必要な機能

業務用RAGでは、回答文だけでなく次の情報を表示すると確認しやすくなります。

根拠に使った文書名と該当箇所
文書の版と更新日
元文書を開くリンク
回答への評価ボタン
根拠が見つからない場合の明確な表示

「分かりません」と答えられる設計は重要です。関連度が基準を下回る場合は回答を抑制し、担当部署への問い合わせ先を案内します。

評価セットを作る

現場から実際の質問を集め、正解、参照すべき文書、許容できない回答を記録します。次の指標を分けて評価します。

評価対象	確認内容
検索	正しい文書・箇所を取得できたか
回答	根拠に沿って回答したか
出典	利用者が根拠を確認できるか
権限	許可されていない情報を出していないか
性能	業務上許容できる時間で返るか

モデルや検索設定を変更したら、同じ評価セットで再試験します。

回答精度が低いときの切り分け方

回答が期待と違うとき、すぐにモデルを大きくするのは適切とは限りません。処理のどこで失敗したかを順番に確認します。

必要な文書が登録されているか
OCRや文字抽出が正しく行われているか
質問に対応する文書断片を検索できたか
取得した断片に回答に必要な前後関係があるか
LLMが根拠を無視せず回答したか
画面に正しい出典が表示されたか

検索結果が誤っていれば、モデルではなく文書分割、検索語、メタデータ、再順位付けを調整します。正しい根拠を取得できているのに回答が誤る場合は、指示文やモデルを見直します。

小さく始めるRAGのPoC設計

最初から全部署の共有フォルダーを対象にすると、古い文書や権限の整理に時間がかかります。まず一つの業務、一つの文書群、10〜30個程度の代表質問から始めます。

PoCでは、回答を「正しい・一部正しい・誤り」だけで採点せず、検索、回答、出典、権限、速度を個別に評価します。現場担当者が正解と根拠文書を決め、システム担当者が性能と権限を確認する分担が有効です。

文書更新を運用へ組み込む

就業規則や製品マニュアルは更新されます。RAG側に旧版が残ると、もっともらしい古い回答を返す可能性があります。文書管理システムの更新を検知して再登録するか、管理者が承認後に反映する手順を決めます。

回答には文書名だけでなく版・更新日を表示し、利用者が最新版か判断できるようにします。廃止文書は元ファイルだけでなく、検索インデックスとキャッシュからも削除します。

RAG構築でよくある質問

PDFやスキャン文書も利用できますか？

利用できますが、文字情報を持たないスキャンPDFにはOCRが必要です。表、段組み、注釈、図面は読み取り結果が崩れることがあるため、代表文書で抽出品質を確認します。

社内文書をモデルの学習に使うのですか？

RAGでは、一般に質問時に関連文書を検索してモデルへ渡します。モデル自体を再学習させる方法とは異なり、文書の追加・更新・削除を反映しやすい構成です。

回答内容を完全に正しくできますか？

生成AIで誤回答の可能性をゼロにはできません。出典表示、関連度の閾値、回答できない場合の案内、人による確認を組み合わせ、業務上許容できるリスクへ下げます。

運用で続けるべき改善

低評価の質問を定期的に確認し、原因を「文書不足」「検索失敗」「回答生成」「権限」「操作」のどこにあるか分類します。文書が更新されたら自動または承認後に再登録し、削除された文書は検索対象からも確実に除外します。

まとめ

ローカルLLMとRAGの組み合わせは、社内文書を外部へ出さずに活用できる実践的な構成です。成功の鍵は、文書整備、検索方式、アクセス権、出典表示、継続評価を一つの運用として設計することです。

社内文書を使ったRAGのPoCを相談する

関連記事：ローカルLLM構築の進め方／ローカルLLM導入ガイド