RAG（検索拡張生成）の導入相談で最初に出るのは、たいてい製品の話です。しかし実務で結果を分けるのは、その手前にある文書の状態です。この記事では、RAGを入れる前に社内文書へ施す5つの準備と、どこまで整えれば評価に進めるかを整理します。

対象は、RAGのPoCや社内検索をこれから始める情報システム部門、業務部門、文書管理の担当者です。ベクトルDBの製品比較、埋め込みモデルの選定、アクセス制御製品の実装手順は扱いません。RAGの仕組みそのものはRAGとは何か──社内ナレッジ検索の基本で扱っています。

RAG導入前の5つの準備を2つの独立した軸に分けた図。根拠性を決める「検索設計」の軸には4つの準備が属する。準備1「対象範囲と正本」＝どの文書を答えの根拠にするかを決め、正本を1つに定める。準備2「文書構造」＝見出し・表・脚注・添付の意味のまとまりが壊れない形へ整える。準備3「メタデータ」＝所有者・版・更新日・対象期間・廃止状態を文書へ持たせる。準備5「評価」＝代表質問・期待する根拠・失敗条件を決めてから範囲を広げる。機密性を守る「権限制御」の軸には準備4が属し、閲覧権限と機密区分を検索設計とは別に設計する。2つの軸は独立しており、権限制御を強めても回答の根拠性は上がらず、その逆も成り立たない。両方が必要である。
図：RAG導入前の5つの準備 — 検索設計と権限制御は別の軸

RAG導入前に文書整備が必要な理由

RAGは、質問に関連する文書を検索し、その内容を根拠として生成モデルに答えさせる仕組みです。Microsoft は Azure AI Search のドキュメントで、RAG を「自社のコンテンツに回答を接地させることで LLM の能力を拡張するパターン」と説明しています。ここで重要なのは、接地先の品質が回答の品質を大きく左右する一因であることです。同じドキュメントは「RAG の品質は、取得用にコンテンツをどう準備するかに依存する」と述べる一方で、良い根拠を与えるには適切なコンテンツ・賢いクエリ・最適なチャンクを選び出すクエリロジックの組合せが要るとも説明しています。文書整備は唯一の決定因子ではなく、検索の設定やプロンプト設計とは別の要因として並びます。本稿が扱うのはそのうち文書側です。

つまり、次のような状態はRAGを入れても解消しません。

  • 正本が複数ある：同じ規程の版が3つ散在し、どれが有効か文書からは分からない
  • 古い文書が残っている：廃止済みの手順書が検索対象に入り、根拠として提示される
  • 記述が矛盾している：部門ごとに異なる運用が書かれ、どちらも「社内文書」として同じ重みを持つ
  • 暗黙知が文書化されていない：そもそも書かれていない内容は、検索しても出てこない

よくある誤解に「RAGを入れればモデルが覚えている古い知識が消える」というものがあります。RAGは、検索した文書を回答の根拠として与える仕組みであって、モデルが学習時に獲得した知識を消去する仕組みではありません。だからこそ、根拠として何を与えるかを設計する必要があります。

準備1：対象範囲と正本を決める

最初に決めるのは「どの文書を答えの根拠にするか」です。社内の全文書を対象にすると、古い版・下書き・個人メモまで根拠になります。

  • 対象業務を1つに絞る：全社ではなく、たとえば「就業規則と勤怠の問い合わせ」から始める
  • 正本を1つに定める：同じ主題に複数の文書があるなら、どれが正本かを決めて他を対象外にする
  • 対象外を明示する：下書き、個人フォルダ、過年度資料は最初から入れない

件数を増やすことを成功条件にしないでください。投入文書数は成果ではありません。「答えの根拠として妥当な文書だけが入っている」状態が成果です。

準備2：所有者、版、更新日、廃止状態を持たせる

次に、対象文書へ管理情報を持たせます。文書の中身ではなく、その文書自体についての情報です。

項目なぜ要るか
所有者内容の誤りを直す責任者が決まる。不明な文書は更新されない
版・改定日複数版が並んだとき、どれが有効かを機械的に判別できる
対象期間「2025年度の運用」のように、いつの話かを回答に添えられる
廃止状態廃止済みを検索対象から外せる。削除しないまま残せる
公開区分後述の権限制御と、検索対象の切り分けに使う

この情報は、ファイル名の慣習ではなく構造化された属性として持たせます。「rev3_最新_final2.docx」は人間には読めますが、機械的な判別には使えません。

準備3：検索単位を壊さない文書構造へ整える

RAGでは、長い文書をそのまま渡すのではなく、一定の大きさに分割して扱うのが一般的です。これはモデルが受け取れる入力量に上限があるためで、Microsoft のドキュメントは、分割が必要になるのは「元の文書がモデルの入力上限を超える場合」だが、「単一のベクトルでは内容をうまく表現できない場合にも有効」と説明しています。

分割の大きさに唯一の正解はない

同ドキュメントは Azure AI Search における出発点として、512トークン（およそ2,000文字）のチャンクサイズと25%（128トークン）の重なりから始めることを推奨しています。ただし同時に、最適な重なりはコンテンツの種類や用途によって変わること、パラメータの最適な選び方はチャンクをどう使うかに依存することも明記しています。

数値は出典の条件つきで読んでください

上記の512トークン・25%という値は、Azure AI Search のドキュメントが示す出発点であり、あらゆる製品・あらゆる文書に当てはまる一般則ではありません。「チャンクを小さくすれば精度が上がる」という単純な関係も成立しません。自社の文書と質問で試し、結果を見て調整する対象です。

文書側でできること

分割の設定は後から調整できます。ただし構造が壊れた文書を機械的に分割するだけでは、意味のまとまりを保ちにくくなります。前処理や分割方式の工夫で補える部分はありますが、文書側を整えておくほうが確実です。文書側で整えられるのは次の点です。

  • 見出しの階層：本文のどこがどの見出しに属するかが、書式ではなく構造として分かる
  • 表：画像化された表ではなく、行と列が保持された表にする
  • 脚注・注記：本文と切り離されると条件が落ちる。本文中に条件を書くか、対応関係を保つ
  • 添付・別紙：本体と別紙の関係を明示する。単独で読むと意味が変わる別紙は要注意
  • スキャン画像：テキストとして抽出できない文書は、そのままでは検索対象にならない

準備4：閲覧権限と機密区分を検索とは別に設計する

ここが実務で最も混同されるところです。回答の根拠性を決める検索設計と、機密性を守る権限制御は、別の軸です。

Microsoft は RAG の課題の一つとして「セキュリティとガバナンス」を挙げ、「プライベートなコンテンツを LLM に開くには、きめ細かいアクセス制御が必要になる」と述べています。同社の文書レベルアクセス制御のドキュメントでは、取り込みから問い合わせ実行までの各段階で文書単位の権限を適用する方式が説明されています。

混同しやすい点を分けて書きます。権限制御を強めても、回答の根拠性は上がりません。見せてよい人にだけ見せることと、正しい文書を根拠に答えることは、別の問題です。逆に、検索設計をどれだけ良くしても、権限が設計されていなければ機密は守られません。両方が要ります。

権限の反映にはタイムラグがある

もう一点、実務上見落とされやすいのが権限変更の反映タイミングです。Microsoft のドキュメントは、元のシステム側で権限が変わっても、その変更が検索結果に反映されるのは、権限情報が索引側へ同期された後であると説明しています。「元システムで権限を外したから、もう出てこないはず」という前提は置けません。

設計時に決めておく項目は次のとおりです。

  • 機密区分の定義（社外秘、部門限定、全社公開など）と、区分ごとの扱い
  • 誰の権限で検索するのか（利用者本人か、共通アカウントか）
  • 権限変更が検索側へ反映されるまでの時間と、その間の扱い
  • そもそも投入しない文書の基準（人事・懲戒・係争・要配慮個人情報など）

準備5：代表質問、期待根拠、失敗条件を作る

最後に評価の道具を用意します。用意してから投入するのが順序です。動かしてから評価方法を考えると、「なんとなく良さそう」で判断することになります。

用意するもの内容
代表質問実際に現場から来る質問を、言い回しはそのまま集める。件数ではなく対象業務・権限の違い・失敗条件・更新反映を覆えているかを条件にする
期待する根拠各質問に対し「この文書のこの箇所が根拠として出てほしい」を先に書く
失敗条件廃止文書が根拠に出る、権限外の文書が出る、根拠が示されない、など
更新反映の確認文書を1件更新し、いつ検索結果に反映されるかを実測する

小規模な初期確認であれば10〜20件程度から始める例がありますが、これは目安であり、対象業務の広さ、権限区分の数、想定する失敗条件によって増減します。件数を満たすことを目的にしないでください。

評価は「正しい答えが返ったか」だけでなく、「期待した文書が根拠として提示されたか」を見ます。たまたま正しい答えが出ても、根拠が別の文書なら、その正しさは再現しません。

評価で見落とされやすい3点

  • 答えられなかった質問を記録しない：正解率だけを見ると、そもそも根拠文書が存在しない領域が見えなくなる。「文書が無いから答えられない」は、検索の失敗ではなく整備の課題である
  • 更新の反映を測らない：文書を直した直後に古い内容が返る状態は、運用が始まってから発覚すると信頼を失う。反映までの時間を先に測っておく
  • 権限を1人分でしか試さない：管理者の権限だけで評価すると、権限の狭い利用者から見た結果が分からない。少なくとも2種類の権限で同じ質問を投げる

受入表と更新運用

準備1〜5の状態は、文書ごとに一覧で持ちます。全項目が埋まった文書から対象に入れる運用にすると、整備の進み具合と対象範囲が同じ表で管理できます。

  • 対象業務・文書名・正本かどうか
  • 所有者・版・改定日・対象期間・廃止状態
  • 構造の整備状況（見出し／表／別紙の扱い）
  • 機密区分・閲覧範囲
  • 代表質問での確認結果と、確認日

更新運用では、誰がいつ見直すかを決めます。所有者が決まっていても、見直しの契機が決まっていなければ文書は古くなります。制度改定、期初、年1回など、業務に合った契機を1つ決めれば十分です。

導入を止める条件

  • 対象業務の正本が決まらない。決める人がいない
  • 要配慮個人情報や係争関連が、対象文書から分離できない
  • 利用者ごとの権限で検索できず、全員が同じ範囲を見る構成しか取れない
  • 代表質問で、廃止文書や権限外文書が根拠として出る
  • 根拠が提示されず、回答の出どころを追跡できない
  • 誤った回答が出たときに、誰が直すのかが決まっていない

止める判断は、対象範囲を狭めることで解けることが多くあります。全社導入を止めるのではなく、条件を満たす1業務まで範囲を絞るのが実務的な収め方です。

まとめ

RAGの成否は、製品選定より前の文書の状態に大きく左右されます。正本を決め、管理情報を持たせ、構造を整え、権限を別軸で設計し、評価の道具を用意する。この5つが揃うと、うまくいかなかったときにどこが原因かを切り分けられるようになります。切り分けられることが、改善できることの前提です。

まずは1業務を選び、その正本・所有者・権限・更新日を棚卸ししてください。文書が何件あるかではなく、1件でも全項目が埋まるかを最初の目標にすると、必要な作業の実態が見えます。

引用元・参考文献

公式ドキュメント

公的機関

※ Microsoft Learn の記述は Azure AI Search という特定製品のドキュメントであり、本稿ではRAGの概念と機能境界の根拠として参照しています。チャンクサイズ等の具体的な数値は同製品における出発点として示されたものであり、他の製品や自社文書へそのまま一般化できるものではありません。本稿で述べた5つの準備は、これらの資料が示す考え方を踏まえた一般的な整理であり、特定の資料に手順そのものが規定されているものではありません。