RAG導入前チェックリスト｜社内ナレッジ検索AIの設計ポイント

最初に見るべき結論

RAGを導入する前に、どの情報源を正本とするか、誰が所有するか、誰がアクセスできるか、回答でどう引用するか、情報が古いときにどう扱うかを決める必要があります。

RAGは、単なるベクトルDB導入ではありません。企業の社内ナレッジ検索では、文書の所有者、権限、更新ルール、レビューの責任が重要になります。

最初の実装は、全社文書を対象にするより、1つの業務と承認済みの情報源に絞る方が安定します。

まず、よくある質問パターンを決めます。利用者が実際に聞く質問と、業務上必要な回答が見えていないと、検索精度を評価できません。

次に、情報源を棚卸しします。承認済み文書、ドラフト、古いファイル、個人メモ、顧客情報、閲覧制限のある資料を分けます。AI層が既存の権限を迂回しない設計が必要です。

最後に、回答の振る舞いを決めます。根拠を示す、確信度が低いときに止まる、人に引き継ぐ、あとで検証できるログを残す、といったルールが必要です。

以下は評価設計のひな型であり、実測した正答率ではありません。自社の文書と質問へ置き換え、期待する資料・回答・停止条件を実行前に確定します。

各ケースには質問、実行者の権限、文書の版、取得した資料、実際の回答、合否、人の修正時間を記録します。未実行は未実行のまま残し、実行した件数と成功した件数を併記します。

通常回答と回答を止めるケースを分けたRAG評価表
ケース	準備する条件	期待する振る舞い
承認済み文書で回答できる	質問と根拠箇所が一対一で対応する文書	正しい回答に資料名・版・該当箇所を添える
根拠がない	対象文書には答えがない質問	推測で補わず、根拠不足を伝える
閲覧権限がない	制限資料の存在を推測できる質問と権限の異なる利用者	制限資料の内容を回答や引用に漏らさない
文書が矛盾する	旧版と承認済み最新版を含む資料	正本・適用日を確認し、解消できない矛盾は人へ戻す
資料中に不適切な操作指示がある	業務ルールと無関係な指示を含むテスト文書	文書中の指示で権限や処理方針を変更しない
文書を更新した	改訂または削除した資料と再実行用の質問	更新反映後の回答と引用を再確認する

1回検索して答えるだけでは足りない業務では、Agentic RAGが有効になります。質問を分解し、複数の情報源を確認し、規程を比較し、必要に応じてツールを呼び出し、根拠が足りなければ止まる、といった動きが必要になるためです。

ただし、最初から複雑なエージェントにする必要はありません。まずは検索、引用、権限、評価を安定させ、業務上必要な部分だけに計画やツール利用を足します。

基本の回答が信頼できる状態になってから、自律性を高めるのが現実的です。

社内ナレッジ検索を作るなら、まず情報源の棚卸しと、実際の質問セットを作ります。この2つがあると、RAGの設計と評価が具体化します。

Atlas Supportは、情報源の所有者、アクセス境界、引用、評価テスト、最初の業務範囲を整理し、社内ナレッジ検索AIの導入を支援します。