RAG構築の手順 – 社内文書をAIで検索・回答させる仕組みの作り方と評価

要点まとめ

• RAG（Retrieval-Augmented Generation、検索拡張生成）は、質問のたびに社内文書から関連箇所を検索し、その内容を根拠に生成AIが回答する仕組みで、AIモデル自体の再学習は不要です。
• 文書を更新した場合は、更新した文書を検索対象（索引）に取り込み直した時点で回答に反映されます。取り込みの手順と頻度を運用ルールとして決めておく必要があります。
• 日本語の文書では、意味で探すベクトル検索に加えて、型番や社内用語を確実に拾うキーワード検索を併用すると、取りこぼしを減らしやすくなります。
• 精度の評価は、現場が作ったテスト質問（数十問程度から）で「正答か」「根拠の文書が正しいか」を採点し、改善のたびに同じ質問で比較します。
• 運用開始後は、文書の取り込み手順、回答ログの点検方法、利用者からの評価の集め方を決めておくと、品質を改善しやすくなります。

RAG構築の6つの工程と決めること

埋め込みベクトルとは、文章の意味を数値の並びで表したもので、意味の近い文章ほど近い値になります。チャンクとは、検索の単位として分割した文書の断片を指します。

前処理と分割で確認すること

RAGの回答が期待どおりにならないとき、原因はAIモデルよりも前処理にあることが少なくありません。実装の際に確認する点は次のとおりです。

• 表を表として残す。PDFの表をそのままテキスト化すると、行と列の対応が崩れます。表の構造を保ったまま変換するか、重要な表は別途データとして整えます。
• スキャン画像はOCRの品質を確かめる。OCR（画像から文字を読み取る技術）の誤りは、そのまま検索の取りこぼしになります。
• 見出し単位で分割する。一定の文字数で機械的に区切るより、見出しや条番号の区切りを活かした方が、回答に必要な文脈がまとまりやすくなります。前後のチャンクと少し重ねる方法もあります。
• メタデータを付ける。文書名、版、更新日、所管部署、閲覧権限をチャンクごとに付けておくと、検索時の絞り込みと根拠表示、権限制御に使えます。

特に閲覧権限は、後から追加すると索引の作り直しになりやすい部分です。人事・経理・役員向けの文書を対象にする可能性があれば、最初の設計で要件に含めます。

日本語文書の検索で効く工夫

日本語は単語の区切りに空白がないため、キーワード検索では形態素解析（文章を単語に分ける処理）やN-gram（一定の文字数ごとに区切る方法）による索引づくりが必要です。製品型番、図面番号、社内の略語などは、意味で探すベクトル検索だけでは拾えないことがあるため、キーワード検索と組み合わせるハイブリッド検索が有効な場面が多くあります。

さらに、検索で集めた候補を、質問との関連度で並べ替える処理（リランキング）を加えると、上位に正しい根拠が来る割合を改善できることがあります。どの組み合わせが効くかは文書の性質で変わるため、評価用の質問で比較して決めます。

評価の方法 テスト質問で数字にする

評価は、次の手順で進めると改善の効果を説明しやすくなります。

1. 現場の担当者に、実際によく受ける質問と、間違えると影響が大きい質問を数十問ずつ挙げてもらう
2. それぞれに正解と根拠の文書を記録する
3. RAGの回答を「正答・部分的に正答・誤答・回答なし」で採点し、根拠の文書が正しいかも確認する
4. 前処理や検索の設定を変えたら、同じ質問のセットで再度採点して比較する

実装の現場では、回答の採点とは別に、検索の段階だけを評価することをおすすめします。具体的には、テスト質問ごとに「正解の根拠が含まれる文書」を記録しておき、検索結果の上位数件にその文書が入っているかを確認します。検索で正しい文書が見つかっていないのに回答の指示文を調整しても、精度はほとんど上がりません。検索と生成のどちらに問題があるかを切り分けることで、改善の手間を大きく減らせます。

「回答なし（分からない）」を誤答より良い結果として扱うかどうかも、業務に応じて決めておきます。誤った回答が大きな問題になる業務では、根拠が見つからない場合に答えない設計の方が安全です。

評価の結果は表にまとめ、変更内容と正答率の推移を残しておくと、社内での説明や本番化の判断に使えます。

公開事例 シンガポールのPropTech企業向けRAG検索

ベトナム・ハノイを拠点とするAI開発会社NKKTech Globalの公開事例として、シンガポールの不動産テック企業（NDAにより社名非公開）向けのRAGによる物件検索があります。期間は14週間で、物件を見つけるまでの時間が65%短縮、ユーザーのエンゲージメントが40%向上し、物件情報に関する誤った生成（ハルシネーション）はゼロだったと公開されています。

日本企業の事例ではありませんが、「回答の根拠を物件データに限定し、存在しない情報を作らせない」という設計は、社内文書のRAGでも同じように重要です。

構成と進め方の例はRAG開発のページで紹介しています。

運用開始後に決めておくこと

運用開始後も、文書の更新手順、回答ログの点検方法、利用者からの評価の集め方を決めておくと、品質を改善しやすくなります。文書の取り込みが止まると、回答はすぐに古くなります。

すでに使っているグループウェアやクラウドストレージに、AI検索機能が付属していることもあります。対象文書がそのサービスにまとまっていて権限もそのまま使えるなら、まずそれを試すのが速く、費用も抑えられます。回答を業務システムの操作までつなげたい場合はAIエージェントの構成も選択肢になります。

個人情報を含む文書を対象にする場合は、利用目的の範囲内か、外部のAIサービスが入力データを学習に使わない設定かを確認します。個人情報保護委員会の生成AIサービスの利用に関する注意喚起（2023年6月公表、2026年10月時点で掲載中）も参考になります。本記事は一般的な情報提供を目的としたものであり、法的助言ではありません。

よくある質問

RAGを構築すればハルシネーションはなくなりますか？ 減らすことはできますが、ゼロになるとは限りません。検索で正しい文書が見つからない場合や、文書自体があいまいな場合には誤った回答が出ることがあります。根拠の表示、根拠がない場合は答えない設計、テスト質問による定期的な評価を組み合わせます。

RAG構築にはどれくらいの期間がかかりますか？ 1部署の限られた文書で試作するなら数週間、権限管理や利用ログ、運用手順まで含めた本番化には数か月かかることが一般的です。文書の量と状態、特にスキャン画像や複雑な表の割合で期間は変わります。

社内文書をRAGに使っても情報漏えいの心配はありませんか？ 設計と契約次第です。利用するAIサービスが入力データを学習に使わない設定か、データをどの国・どのサーバーに保存するか、文書ごとのアクセス権を検索に反映しているかを確認します。個人情報を含む場合は、個人情報保護法上の取扱いも事前に整理します。