RAGの評価指標（KPI）の作り方：正答率と引用で成果を可視化する方法

RAGは「作って終わり」ではなく「測って育てる」仕組み

RAG（Retrieval-Augmented Generation）は、社内文書やナレッジから関連情報を検索（Retrieval）し、その根拠を使って回答を生成（Generation）する仕組みです。チャットボットや社内FAQの高度版として注目されますが、導入後に現場からよく出るのが「便利そうだけど、結局どれくらい良くなったの？」という疑問です。ここで必要なのが評価指標（KPI）です。

特に情シスや企画側の立場では、“モデルが賢いか”より“業務が改善したか”を説明できることが重要です。RAGの価値は、回答の正しさだけでなく「根拠を提示できる」「社内ルールに沿った回答をする」「問い合わせ対応が減る」といった業務成果にあります。しかし、RAGはLLM（生成AI）単体と違い、検索・文書・生成の複合システムのため、原因がどこにあるかを切り分けながら改善する測り方が欠かせません。

本記事では、開発の専門知識がない方でも、社内説明・ベンダー管理・改善サイクルに使える形で、RAGのKPI設計を解説します。結論から言うと、最初に押さえるべき中核は「正答率（正しい回答か）」と「引用（根拠が示せているか）」です。この2つが揃うと、成果が可視化され、改善の方向性もブレにくくなります。

まず決める：RAGのKPIは「利用目的」から逆算する

KPIを作るとき、いきなり数値を並べると失敗しがちです。先に「何のためのRAGか」を言語化しましょう。目的が違えば、同じ“良い回答”でも求められる水準が変わります。たとえば、社内ヘルプデスクの一次対応なら「速くてそこそこ正しい」が価値ですが、法務・品質・セキュリティの領域なら「慎重で根拠が明確」が必須です。

目的が決まったら、KPIは大きく2階建てで設計します。上の階が経営・現場に効く「業務KPI」、下の階が改善に使う「品質KPI」です。RAGでは、この品質KPIの中心に正答率と引用を据えると、改善が回しやすく、説明もしやすくなります。「業務成果（時間/件数）」と「品質（正答/引用）」をセットで追うのが、導入を継続させるコツです。

中核KPI：正答率（正しい回答か）を実務で測る方法

正答率はシンプルに見えて、測り方を誤ると「数字だけ立派で現場が不満」という状態になります。RAGの正答率は、単なる文章の自然さではなく、業務上の質問に対して“必要十分に正しいか”で判断します。ポイントは、評価基準を業務に合わせて定義することです。

おすすめは、回答を4段階で判定する方式です。二択（正しい/誤り）よりブレが少なく、改善にもつながります。

KPIとしては「A比率」「A+B比率」を使い分けます。一次回答の自動化が目的ならA+B、品質統一や監査が絡むならAが重要です。ここで大切なのは、“何点以上を合格とするか”を利用部門と合意してから測ることです。情シスだけで決めると、現場の期待とズレて炎上しやすくなります。

評価データ（テストセット）の作り方も成果を左右します。理想は、実際の問い合わせログ・メール・チャット履歴から質問を集め、頻出（ヘビーユース）と重要（リスク高）を混ぜることです。数は最初から完璧を狙わず、まずは50〜100問程度で回し、月次で増やします。質問は「短い一言」だけでなく、「前提条件を含む現場の文体」に寄せると、RAGの弱点が早く見えます。

さらに、正答率は平均だけでは危険です。重要なのは失敗の種類です。RAGでは、検索に失敗したのか、検索は合っていたが生成が間違えたのかで対処が異なります。評価時は可能なら「なぜダメだったか」をラベル化し、改善タスクに直結させます。

• 検索ミス：参照すべき文書が見つからない（文書整備・検索設定・メタデータが課題）
• 引用ミス：関係ない箇所を根拠にする（分割方法・埋め込み・検索精度が課題）
• 生成ミス：根拠はあるのに言い換えで意味が変わる（プロンプト・回答フォーマットが課題）

中核KPI：引用（根拠が示せるか）で“信頼できるRAG”にする

RAGの強みは、回答の根拠となる社内文書を提示できることです。ここが曖昧だと「結局、生成AIのそれっぽい文章では？」と不信感が残り、利用が進みません。逆に、引用がきちんと出るだけで、非エンジニアでもレビューしやすくなり、現場展開が一気に楽になります。

引用のKPIは、単に「リンクが出た」では不十分です。最低限、次の3点を分けて測ります。

実務では、引用の品質が上がると「正答率の評価」も安定します。なぜなら、レビュワーが根拠を見て判定できるため、「文章がうまいから正しそう」といった錯覚を減らせるからです。引用はRAGの“説明責任”を担保する安全装置として扱うとよいです。

引用KPIを上げるための設計ポイントは、主に文書側にあります。たとえば、PDFのスキャン画像や、更新日が不明な文書は、RAGの引用品質を大きく落とします。文書整備で最低限やるべきは「最新がどれか」「正式版はどれか」「適用範囲は何か」が分かるようにすることです。ITに詳しくなくても、管理ルールを決めるだけで効きます。

• 文書メタ情報：タイトル、版数、更新日、主管部署、適用対象（部門/製品/地域）
• 粒度：1ファイルに何でも入れない（章ごとに分けると引用が当たりやすい）
• 禁止事項：古い手順・例外情報は“廃止”と明記（残すなら注記する）

引用が出せない質問（例：雑談、方針未決定、社内に根拠がない）も必ずあります。その場合は「引用なしで断言しない」ルールを入れ、KPIとしては“適切な保留（エスカレーション）率”を併用します。引用率を無理に100%にすると、関係ない引用を付けてしまい、むしろ危険です。

運用で効くKPIセット：品質・業務成果・リスクを同時に見る

正答率と引用は中核ですが、運用では「どれだけ使われ、どれだけ削減でき、どれだけ安全か」も見たいはずです。ここでは、情シスや管理職が社内説明に使いやすいKPIセットを紹介します。最初から全部は追えないため、まずは“少数のダッシュボード”に落とし込むことがポイントです。

自己解決率は計測が難しいことがあります。その場合は代替として「チャット後の問い合わせ発生率」「同一質問の再訪率」「回答後の“役に立った”評価」を使います。完璧な計測より、意思決定に足る指標を継続して取るほうが価値があります。

また、RAGのKPIは平均値だけでなく、重要度で重み付けすると説得力が上がります。例として「全体A+Bは80%だが、重要カテゴリ（情報セキュリティ/経費精算/人事）ではAが90%」のように出せると、導入継続の判断がしやすくなります。カテゴリ別にテストセットを分け、部門ごとのオーナーにレビューしてもらうと、E-E-A-T（経験・専門性・権威性・信頼性）にもつながります。

評価の進め方：テストセット→定期計測→改善の回し方

「KPIを作ったが、誰がいつ測るのかが曖昧で止まった」というケースが多いです。ここでは、RAG評価を運用に落とす手順を、非エンジニアでも回せる形にします。コツは、最初から自動化にこだわらず、手動評価とログ活用を組み合わせることです。

1. 質問リスト（テストセット）を作る：問い合わせログから頻出30問、重要20問などで開始
2. 正答・引用の判定基準を決める：A/B/C/Dと、引用適合のチェック観点を文書化
3. 月次で定点観測：同じ質問で比較し、改善前後の差を見える化
4. 失敗を分類して改善：検索・文書・プロンプト・権限制御のどこが原因か切り分け
5. 現場フィードバックを拾う：「この回答は使えた/危ない」を簡単に送れる導線を用意

判定は、利用部門の代表者（業務の専門家）と情シス（運用責任者）が一緒に行うのが理想です。理由は、RAGの改善は“正解”が業務ルールに依存するからです。ここをベンダー任せにすると、「それっぽいが運用に合わない」状態になりがちです。業務の専門家が評価に関与するほど、RAGは早く賢くなります。

改善の打ち手は、KPIとセットで管理するとブレません。例えば、引用適合率が低いなら、文書の分割（チャンク）や検索設定の見直しが優先です。正答率が低いが引用は合っているなら、回答フォーマット（「結論→条件→手順→注意」）の指示や、断言を避けるプロンプトが効く場合があります。逆に、引用も正答も低いなら、そもそもナレッジが不足している可能性が高く、文書整備が最短ルートです。

改善の考え方（例）
- 引用が出ない：検索対象に入っていない／権限で読めない／文書が画像PDF
- 引用がズレる：文書が長すぎる／章立てが曖昧／用語ゆれ（社内略語）が多い
- 正答が不安定：質問の前提を確認せず断言／例外条件を落とす／出力形式がバラバラ

よくある失敗と回避策：KPIが形骸化するパターンを潰す

RAGの評価は、最初は盛り上がっても、運用が忙しくなると止まりがちです。よくある失敗は「指標が多すぎる」「測り方が難しい」「数字が良くても現場が喜ばない」の3つです。ここでは、KPIが形骸化する原因と、現実的な回避策をまとめます。

• 失敗：指標を詰め込みすぎる
  回避：最初の3か月は「A+B正答率」「引用適合率」「自己解決に近い指標」の3つに絞る
• 失敗：評価が担当者の感想になる
  回避：A/B/C/Dの基準と、引用チェック観点を1枚にして共有する
• 失敗：現場の不満が“数字に出ない”
  回避：カテゴリ別（部門別）にKPIを出し、重要領域のA率を別枠で管理する
• 失敗：引用があるのに危ない回答をする
  回避：引用箇所の版数・更新日を表示し、古い文書は参照しないルールを作る
• 失敗：改善が進まない
  回避：月次の定点観測に加え、週次で“失敗トップ10”だけ直す運用にする

特に大企業の情シスでは、セキュリティや監査の観点が重要になります。RAGのKPIに「権限外情報の参照が起きていないか」「機密が回答に含まれていないか」といった観点を入れると、稟議や展開が通りやすくなります。技術的な実装はベンダーに任せるとしても、評価観点（何をNGとするか）を決めるのは発注側です。

まとめ

RAGは、社内文書を根拠に回答できる一方で、検索・文書・生成が絡むため「何が良くなったか」を示しにくい仕組みです。だからこそ、導入効果を社内で説明し、改善を回すためのKPIが欠かせません。

まず押さえるべき中核は、正答率（業務で使える正しさ）と、引用（根拠を示して信頼を担保する）です。これに、利用状況や自己解決に近い業務KPI、そしてリスク（NG回答）を最小限で組み合わせると、現場と経営の両方に説明できるダッシュボードになります。最初は少数の質問（50〜100問）から定点観測を始め、失敗を分類して改善を積み重ねるのが現実的です。

もし「何をKPIにすべきか社内合意が難しい」「評価用の質問や文書整備が進まない」「PoCから本番運用に移せない」といった壁がある場合は、目的整理から評価設計、改善サイクルの構築までを一緒に進めると失敗が減ります。