RAGベンダーの選び方：権限・監査・運用で提案の良し悪しを見抜く方法

RAGとは何か：まず「できること／できないこと」を揃える

RAG（Retrieval-Augmented Generation）は、生成AIに社内文書や業務データを「検索で取り出して」渡し、回答の根拠を社内情報に寄せる仕組みです。たとえば「就業規則のこのケースはどう扱う？」「この取引先の契約条件の例外は？」といった問いに、社内の規程・契約書・FAQ・議事録などを参照して答えさせます。ここで重要なのは、RAGは万能な“知恵袋”ではなく、検索できる形で整理された情報に強いという点です。

よくある誤解は「RAGを入れればハルシネーション（もっともらしい誤回答）がゼロになる」という期待です。実際には、検索結果が不十分だったり、権限が適切にかかっていなかったり、最新情報が取り込まれていなかったりすると、誤回答や情報漏えいのリスクは残ります。つまりRAG導入の成否は、モデルの選定よりも、データの扱い方と運用設計に強く依存します。

さらに、RAGの導入は「PoC（試作）で当たればOK」ではありません。現場で使い続けるには、文書の更新、検索品質の維持、アクセス権の変更、監査対応、問い合わせの増加、障害時の復旧など、運用の現実があります。ベンダー選定で見るべきは、デモの見栄えだけではなく、権限・監査・運用まで一気通貫で説明できるかです。この記事では、非エンジニアの情シス・管理部門・経営層でも提案の良し悪しを見抜けるように、チェック観点を具体化します。

提案の良し悪しは「権限設計」でほぼ決まる

RAGは社内情報に触れるため、最初に詰めるべきはアクセス権（権限）です。社内のファイルサーバ、SharePoint、Google Drive、Box、Confluence、kintone、社内DBなど、データ源が増えるほど複雑になります。良いベンダー提案は「何ができるか」より先に、誰が何にアクセスできるのかを仕様として固定します。

最低限確認したい権限の論点

• ユーザー単位のアクセス制御：部署・役職・個人の権限に沿って検索結果が出し分けられるか
• 既存権限の継承：ファイルのACLや共有設定をそのまま反映できるか（手作業での二重管理にならないか）
• 回答の根拠に機密が混ざる可能性：検索結果が見えないのに要約だけ漏れる、といった事故を防げるか
• 権限変更の反映速度：異動・退職・プロジェクト終了時に即時反映できるか

特に注意したいのが「検索インデックス（検索用のデータベース）を作る段階で権限が崩れる」パターンです。データを一括で吸い上げてしまう設計だと、インデックス側で権限管理が破綻しやすく、結果として“誰でも検索できる社内情報庫”が出来上がります。提案書に「権限対応」と書いてあっても、実態が「アプリ側でフィルタします」程度だと危険です。インデックス作成時点で権限メタデータが持てるのか、持てるならどの粒度（ファイル、段落、行）か、を質問してください。

また、現場では「部署横断のプロジェクト」「代理申請」「監査対応の一時閲覧」など例外が必ず出ます。良いベンダーは、例外の発生を前提に、ロール設計（役割ベース）と例外フロー（申請・承認・期限付き付与）まで提案します。逆に、デモ段階で管理者アカウントしか見せない場合は、権限の難所を避けている可能性があります。

監査・ログが弱い提案は、後で必ず詰む

RAGは「誰が、どの情報にアクセスし、何を聞き、何が返ったか」を後から説明できないと、情報セキュリティ・内部統制・取引先監査で止まります。特に大企業の情シスや、個人情報・機密情報を扱う中小企業では、監査証跡は導入の必須条件です。良いベンダーは、機能一覧の中にログを入れるだけでなく、監査で問われる“説明責任”を満たすログ設計を示します。

監査で本当に必要なログの中身

• 利用者ログ：誰が（ID/部署/端末/IP）いつ利用したか
• 問い合わせログ：入力文（プロンプト）と、返答内容、利用したモデル、パラメータ
• 参照ログ：どの文書のどの箇所を根拠として参照したか（RAGの検索結果、スコア）
• 権限判定ログ：アクセス拒否が発生した場合の理由、判定ルール
• 管理操作ログ：データ取り込み、インデックス更新、権限変更、設定変更

ここで落とし穴になるのが「個人情報・機密がログに残りすぎる」問題です。ログは監査に必要ですが、保存期間やマスキング（伏字化）もセットで設計しないと、ログ自体がリスクになります。良い提案は、保存期間（例：90日/1年）、閲覧権限、暗号化、削除ポリシー、エクスポート手段まで具体的です。

さらに、外部監査や取引先からは「その回答はどの文書に基づくのか」を求められることがあります。RAGの強みは根拠提示ですが、実務では根拠URLや文書名だけでなく、“該当箇所”まで示せるUIが重要です。回答が正しくても、根拠が追えないと現場が使わなくなります。ベンダー比較では「根拠表示の形式」「参照元の版（改訂履歴）」「回答が古い文書を引いた場合の検知」まで確認しましょう。

運用設計：PoCで“当たる”より、半年後に“回る”が大事

RAGは導入直後より、運用が回り始めた後に差が出ます。最初は「規程を読ませたら答えた」で成功に見えますが、運用が始まると「文書が更新された」「部署ごとに言い回しが違う」「質問が想定外」「回答が長すぎる/短すぎる」「現場が使わない」などが発生します。良いベンダーは、システム構築と同じ重みで、運用体制・KPI・改善サイクルを具体化します。

運用で必ず決めるべきこと

• データ更新の責任者：誰が、どの頻度で、どのデータ源を更新するか
• 品質指標（KPI）：回答採用率、根拠提示率、検索ヒット率、一次解決率、削減工数
• 改善フロー：誤回答の報告→原因分類（検索不足/権限/文書品質/プロンプト）→対策
• 問い合わせの受け皿：情シス/業務側/ベンダーの役割分担、SLA

特に中小企業では、専任担当が置けないケースが多いです。その場合、ベンダーが「運用の省力化」をどう実現するかが重要です。たとえば、文書取り込みの自動化（コネクタ）、更新検知、インデックス再構築のスケジュール、障害通知、定例レポートなどです。“運用は御社でお願いします”の提案は、後で形骸化しやすいので注意してください。

また、RAGの品質は「文書の書き方」にも左右されます。規程がPDF画像で検索できない、議事録がバラバラ、略語が部署ごとに違う、といった状態では精度が出ません。良いベンダーは、データ整備を“ITの話”にせず、業務側が動ける形に落とし込みます。例えば「FAQ化すべきトップ20の質問」「文書テンプレ」「命名規則」「改訂時の周知」など、業務改善として提案できるかがポイントです。

提案比較で使えるチェックリスト：価格より“事故らない設計”を見る

複数社の提案が並ぶと、機能や価格に目が行きがちです。しかしRAGは、情報漏えい・誤回答・運用停止が起きた時の損失が大きく、安い導入が高くつくことがあります。比較のコツは、見積の内訳より先に、「前提条件」「範囲」「責任分界」を明文化しているかを見ることです。

非エンジニアでも見抜ける比較観点

• 範囲の明確さ：どのデータ源まで接続するか、対象部門、対象業務、対象言語
• セキュリティ前提：クラウド/オンプレ、データの保存場所、暗号化、SSO/MFA対応
• 権限の実装方針：継承方法、粒度、権限変更の反映、例外対応
• 監査の実装方針：ログ項目、保存期間、エクスポート、再現性
• 運用体制：障害対応、定例改善、KPIレビュー、問い合わせ窓口
• 将来の拡張：部門追加、データ源追加、モデル変更、コストの増え方

ここで、提案書の「言い切り」に注目してください。良い提案は「できます」だけでなく「どの条件ならできる／できない」を書きます。例えば「SharePointはこの権限モデルなら継承可能」「PDFはテキスト化が必要」「行単位権限はDB側の設計が必要」など、制約を先に出してくれるベンダーは信頼できます。逆に、何でもできます系の提案は、契約後に追加費用が出たり、要件が後出しで崩れたりしやすいです。

導入の現実的ステップ：小さく始めて、権限と監査を先に固める

RAGは「全社展開」から始めるより、事故が起きにくい範囲で始め、設計を固めてから拡張するのが安全です。特に権限・監査・運用を重視するなら、対象業務の選び方が重要です。おすすめは、機密度が中程度で、問い合わせが多く、答えが文書にある領域（例：総務の手続き、ITヘルプデスク、社内ルール、営業資料の探し物）です。

失敗しにくい進め方（例）

1. 対象業務の決定：「問い合わせ削減」「検索時間削減」など目的を1つに絞る
2. データ棚卸し：参照して良い文書、最新版の所在、改訂頻度、権限構造を確認
3. 権限・監査要件の固定：SSO、MFA、ログ項目、保存期間、閲覧権限を決める
4. PoC：精度だけでなく、権限の事故が起きないか、根拠が追えるかを検証
5. パイロット運用：実ユーザーで1〜2か月運用し、改善ループを回す
6. 拡張：部門追加・データ源追加を段階的に実施し、運用負荷を測る

PoC評価は「回答がそれっぽいか」だけでは不十分です。最低でも、（1）権限が違うユーザーで同じ質問をしたときに参照結果が変わるか、（2）回答の根拠がUIで追えるか、（3）誤回答が出た時に原因がログから特定できるか、を確認しましょう。“検証項目を先に定義してくれるベンダー”は、運用まで見ている可能性が高いです。

また、費用面では「初期構築費」より「運用費」と「拡張時の増え方」を見てください。RAGは利用者が増えると、検索基盤・ストレージ・モデル利用料・監査ログ保管などが増加します。良いベンダーは、ユーザー数・データ量・問い合わせ回数の増加に対して、コストの見通しを説明します。逆に、月額が安く見えても、追加データ源や権限例外で都度費用が発生する契約形態だと、後から予算が読めなくなります。

まとめ

RAGベンダー選びで差が出るのは、デモの見栄えやモデル名ではなく、権限・監査・運用の設計力です。RAGは社内情報に近いからこそ、「誰が何を見られるか」「後から説明できるか」「半年後も回るか」を最初に固める必要があります。

• 権限：既存権限の継承、インデックスでの権限保持、例外対応、変更反映速度を確認
• 監査：問い合わせ・参照・権限判定・管理操作までログ設計し、保存期間とマスキングも決める
• 運用：データ更新責任、KPI、誤回答の改善フロー、問い合わせ体制を提案に含める

提案比較では、「できます」より「条件と制約」を先に出してくれるかを見てください。条件が明確なほど、後から追加費用や手戻りが減り、社内説明もしやすくなります。自社のデータ源・ユーザー区分・優先業務を整理し、権限と監査を前提にPoCを設計できれば、RAG導入は安全に成果へつながります。