RAG開発会社を選ぶには？デモより検索評価・権限・更新運用を確認

RAG開発会社を選ぶとき、最初のデモで自然な回答が返ることだけを見てはいけない。RAGは、質問に関係する文書を探す処理と、その文書を使って回答を作る処理に分かれる。回答が悪い原因も、検索漏れ、権限設定、古い文書、生成の誤りで異なる。

候補会社には同じ文書、質問、権限、更新シナリオを渡す。合否は検索評価、文書権限、引用、更新・削除、運用の5項目で決める。

5項目を合格・不合格で確認する

項目	合格条件	必要な証拠	不合格例
検索評価	正解文書を検索し、不要文書を抑える基準を満たす	質問、正解文書ID、検索順位、全結果	回答文だけを採点し検索結果を残さない
文書権限	利用者ごとの許可が検索時と回答時に反映される	権限表、利用者別テスト、拒否結果	ログインできれば全員が同じ文書を検索できる
引用	回答の主張と根拠箇所が対応する	回答、文書ID、該当箇所、リンク	文書トップへのリンクだけを付ける
更新・削除	追加、改訂、削除が決めた時間内に反映される	更新時刻、検索用データの処理、再検索結果	古い版や削除済み文書が残る
運用	品質低下、失敗、モデル変更を検知し再評価できる	指標、ログ、通知、再試験、担当	納品後の監視と変更責任がない

この表は製品機能の有無ではなく、今回の構成で再現できるかを見る。クラウド製品が機能を持っていても、権限同期や更新処理を正しく実装していなければ合格にはならない。

回答より先に検索結果を採点する

回答が正しくても、偶然モデルが知っていただけかもしれない。検索評価では、質問ごとに「参照すべき文書」と「参照してはいけない文書」を決め、検索順位と取得結果を保存する。

最低限、次の種類を入れる。

• 一つの文書で答えられる質問
• 複数文書を組み合わせる質問
• 古い版と新しい版がある質問
• 表や箇条書きから答える質問
• 文書内に答えがない質問
• 言い換えや社内略語を含む質問

MicrosoftのAzure RAGガイドは、取得する文書片の数を評価指標に合わせて調整し、矛盾する時期・作者の文書を扱う必要を説明している。固定した検索件数や分割方法を万能値にせず、自社のテストセットで検索漏れとノイズを比べる。

NIST AI RMFは、目的に合う測定方法を選び、再現可能なテスト・評価・検証を文書化する考え方を示す。候補会社には、最終スコアだけでなく、検索に失敗した質問と検索結果を提出してもらう。

文書権限は検索時に試す

社内RAGでは、営業、人事、経営、委託先で見られる文書が違う。画面へのログインだけでは、検索用データ内の権限が守られている証拠にならない。

Azure AI Searchの文書単位アクセス制御は、取込時に権限情報を検索用データへ同期し、検索時に利用者の情報と照合して返す文書を制限する仕組みを説明している。同じ製品を使わなくても、確認する境界は共通する。

候補会社には、次の試験を求める。

1. 利用者Aだけが読める文書を用意する
2. Aでは検索結果と回答に出ることを確認する
3. 利用者Bでは文書ID、断片、要約、引用のいずれにも出ないことを確認する
4. Aの権限を外し、決めた時間内にBと同じ結果になることを確認する
5. 権限同期が失敗した場合の安全側の動作を確認する

権限変更には同期の遅れがあり得る。製品名だけで「リアルタイム」とみなさず、今回のデータ源、検索用データ、認証方式で実測する。

引用は主張と根拠箇所を対応させる

回答末尾に文書リンクがあっても、本文の主張をその文書が支えているとは限らない。引用の合格条件は、読者がリンク先の該当箇所へ到達し、回答の根拠を確認できることだ。

一つの回答に複数の主張がある場合、どの文書のどの部分が各主張を支えるかを見る。検索した文書に答えがない場合は、別の一般知識で補うのではなく、回答できないと返す条件も試す。

引用が誤っているとき、検索した文書が違うのか、正しい文書から誤った文章を作ったのかを分けて記録する。修正担当と再試験範囲が変わるからだ。

文書の追加・更新・削除を一組で試す

RAGの知識は固定されない。AWSのRAGガイドも、非公開文書のアクセス制御と、更新・変化の管理を設計上の論点に挙げる。

更新試験では、新規文書の追加だけでなく、既存文書の改訂と削除を含める。

• 新規文書がいつ検索可能になるか
• 古い版が同時に残らないか
• 削除した文書が検索・回答・引用から消えるか
• 元データに戻したとき再現できるか
• 取込失敗を誰へ通知するか

「毎日更新」「自動同期」という説明だけでは合格にしない。変更時刻と再検索結果を残し、要求時間内に反映されたかを判定する。

納品後の再評価まで契約へ入れる

モデル、埋め込みモデル、検索設定、文書構成が変われば、初回の合格結果はそのまま使えない。運用では、どの変更で全テストを再実行し、どの変更なら一部でよいかを決める。

デジタル庁の2026年版ガイドラインは政府向けだが、リリース前のテストシナリオ、期待品質、仕様要件、独立したテスト、運用中の監視、モデル更新後の再確認を扱う。民間のRAG発注でも、抜けを確認する材料になる。

契約・仕様書には、テストセットの版、合格基準、結果ファイル、監視指標、再評価の契機、担当、追加費用を書く。候補会社が製品画面だけを見せ、検索結果、権限試験、削除試験を残せないなら選定を止める。

RAG開発会社を選ぶ基準は、デモの回答が最も流暢なことではない。失敗を検索・生成・権限・更新へ切り分け、同じ条件で再試験できることが、本番運用へ進める証拠になる。