社内RAGの精度はどう上げる？文書整備と評価の進め方

この記事では、架空の経費規程を例に、社内RAGの誤答の原因と直し方を図解します。まず、間違った答えが返った質問か、規程から正解を確かめられる質問を一つ選びます。

たとえば、規程では予約前に承認が必要なのに、AIが「後で申請できます」と答えた場合です。この答えを信じて予約すると、必要な承認を受けないまま手続きを進めてしまいます。

業務側は正解と根拠の規程を示します。システム担当者には、検索結果と、回答を作るAIが実際に受け取った文章を調べてもらいます。この文章を、ここでは「AIへの入力」と呼びます。

文書を増やす前に、一つの質問で原因を調べると、直す場所を絞れます。同じ質問と根拠を使い、回答の正しさと閲覧権限を分けて確かめます。

規程の管理担当者と、どの文書を根拠にするか、いつの宿泊に使うか、誰が読めるかを決めます。現在と過去の問い合わせ、一般社員向けの規程と閲覧者を限る規程を分けて整理します。

文書の保管場所・管理担当・版・適用期間・読める人をまとめた一覧が「文書台帳」です。正式な根拠として管理する文書を「正本」と呼びます。ファイルの更新日時ではなく、台帳と規程の内容で使う文書を選びます。

過去の問い合わせには旧版が必要な場合があります。一方、部署内のコピーは正本へ集約し、回答の根拠から外します。この違いを台帳に残すと、更新時にどのデータを直すかも追えます。

システム担当者に、規程のPDFから表や注記まで読み取れているか確認してもらいます。金額だけでなく、適用日と承認条件も残っていることが大切です。

長い文書は、検索用の小さなまとまり（チャンク）に分けます。システム担当者には、分けた後も金額・適用日・承認条件を一緒に見つけられるか確認してもらいます。

読み取れているのに見つからないときは、検索を調べる

社員は、規程と同じ言葉で質問するとは限りません。「ホテル代」と聞いても「宿泊費」の規程を探せるか、現場で使う質問をシステム担当者に渡して確かめます。

「10月2日に13,000円の宿を、承認前に予約してよい？」を「ホテル代の上限は？」だけに変えると、日付・金額・承認の話が抜けてしまいます。

承認条件がAIに届いているのに誤答した場合は、検索だけを直しても原因に合わない可能性があります。AIが受け取った文章全体や、回答の指示も調べます。

規程を差し替えた後は、新しい条件で答えるかを試します。閲覧の許可を取り消したときや文書を削除したときも、使わせたくない内容が検索や回答に残らないか、システム担当者に確認を頼みます。

RAGは、PDFから読み取った文章を検索用に保存します。過去の回答を一時保存して使う構成もあります。規程を変更したら、こうした保存先と回答への反映も確かめます。

検索画面から消えたことと、内部のデータが消えたことは別です。利用者の画面で分からない部分は、システム担当者やサービス提供元に調べてもらい、確かめられない部分は「未確認」として残します。

会話履歴を保存する構成では、変更前の情報が履歴に残ることがあります。記録としての保存と、次の回答への再利用を分けます。情報管理担当者と、読める人・保存期間・再利用の可否を決めます。

業務側は規程で回答を、システム担当者は検索結果とAIへの入力を確認します。文書を見つけたことと、条件を守って答えたことは、別々に確かめます。

検索結果だけを見ても、AIへ実際に渡った文章までは分かりません。両方の記録を比べれば、「探せなかった」のか「AIへ渡すときに落ちた」のかを分けられます。

原因の切り分けや確認項目を整理したい場合は、無料相談で、質問と根拠の規程をもとに相談できます。

「答えない方がよい質問」も確かめる

規程に書かれていない質問には、推測せず経理への確認を案内できるかを試します。ただし、検索で見つからないだけで「規程にない」とは判断できません。経理担当者が原文で確かめます。

閲覧を許可していない文書は、検索結果にも回答用AIへの入力にも含めないようにします。最後の回答に内容が出なかっただけでは、権限の制限が正しく働いたとは判断できません。

試した結果をもとに、直す箇所と、まだ確認できていない箇所を分けます。誤答や権限の問題を残したまま対象を広げず、修正後に同じ質問で確かめてから利用範囲を判断します。

経理が確認した正解と、システム担当者が調べた検索・AIへの入力・権限の結果をもとに、情報管理担当者と利用を広げてよいか判断します。

部署や対象文書を広げるときは、その範囲で回答・権限・更新・削除・会話履歴を確かめます。質問集と確認記録を引き継げる形に残すと、次の更新でも同じ基準で比べられます。

確認日：2026年10月23日。文書の準備・分割・アクセス制御・更新と削除・検索と回答の評価について、以下の公式資料で確認した範囲を説明しています。経費規程・金額・質問・回答は確認手順を示す架空例で、製品の試験成績や精度改善の実測値ではありません。

1. RAG準備段階：代表資料と評価質問のそろえ方 — 現場の質問と代表的な文書を選び、業務を知る人が正解を確認する進め方。表・画像・脚注の読み取りを確かめる際にも参照しています。
2. RAG分割段階：文脈と文書構造を保つ考え方 — 文書を検索用に分ける際に、見出しや前後の意味を保つ考え方。必要な条件まで切り離さないための資料です。
3. Azure AI Searchの文書単位のアクセス制御 — 利用者ごとに、検索してよい文書を制限する方法。権限の変更を検索用データに反映する必要性を参照しています。
4. RAG評価：検索と最終回答で見る観点 — 検索で必要な文章が見つかったかと、最終回答が正しいかを分けて評価する考え方を参照しています。
5. Azure Storageの変更・削除を検索索引へ反映する条件 — 元の文書の変更・削除を、検索用データに反映する条件。ファイルを消しただけで反映が完了したと判断しないための資料です。
6. Azure AI Searchの索引更新と処理結果の確認 — 検索用データの更新方法と、その処理結果を確認するための資料です。
7. Azure AI Searchの親文書・子文書の対応と更新・削除 — 元の文書と、そこから作った検索用の文章を対応付け、更新・削除するための資料です。
8. Amazon Bedrockの文書解析：テキストと図表の扱い — 文字だけを読む方法と、表・画像も扱う方法の違いを確認するための資料です。
9. Amazon Bedrock：回答を生成せず、検索した根拠を確認する — 回答を作らず、検索で見つかった文章と出所を確認する方法。検索結果と回答を分けて調べる際に参照しています。
10. Amazon Bedrock：検索候補を質問との関連性で並べ直す — 見つかった文章を、質問との関連が深い順に並べ直す仕組みの説明です。

製品ごとの対応範囲と設定は、利用する構成の公式資料で確認してください。