こんにちは、近藤(りょう)です!
生成 AI を導入したが「成果をどう測ればいいかわからない」という声をよく聞きます。
生成 AI を業務に導入しても、「本当に効果が出ているのか?」を示せなければ、改善や追加投資の判断は難しくなります。
特に RAG(Retrieval-Augmented Generation)は、外部データを活用して精度や利便性を高められる一方、その効果は適切な指標を設定しなければ見えにくく、成果の判断が曖昧になりがちです。
導入初期からKPIを設定しておくことで改善や社内での合意形成がスムーズになります。
この記事では、生成 AI + RAG の評価に適したKPIの選び方と、運用に活かすためのポイントを解説します。
なぜ RAG に KPI の設定が不可欠なのか?
RAG(Retrieval-Augmented Generation)は、生成 AI が外部データを検索・取得し、それをもとに回答を生成する仕組みです。

社内ナレッジ、FAQ、マニュアル、製品データなどを活用できるため、業務効率化や顧客対応の質の向上に貢献するポテンシャルがあります。
しかし、KPIを設定せずに導入すると...
- 「何となく便利」止まりで効果が曖昧
- 投資効果(ROI)が証明できない
- RAG の評価観点がなくチューニングに悩む
RAG を「導入して終わり」にしないためには、初期段階からKPI設計が効果的です。KPIがなければ、RAG が本当に役立っているのか、業務にどの程度貢献しているのか判断が曖昧になります。
効果の曖昧化を防ぐには、ビジネス視点または技術視点のいずれか(理想は両方)から効果を測定します。
■ ビジネス視点:業務効率・コスト削減・顧客満足度など
■ 技術視点:回答精度・検索網羅性・応答速度など
それぞれで「定量的」または「定性的」のどちらを測るかをKPIとして設定します。これにより、改善の優先度やアプローチを客観的に判断しやすくなります。
RAG の KPI 設計ステップ
PoC(概念実証)段階から本番運用までスムーズに移行するためのフローは次の通りです。
※既存 RAG の改善が目的の場合は、ステップ3から開始できます。
- ステップ 1:ビジネス目標の明確化
- ステップ 2:PoC(概念実証)の実施(推奨)
- ステップ 3:現状分析と課題抽出
- ステップ 4:KPIの設定
- ステップ 5:改善サイクル(PDCA)
ステップ 1:ビジネス目標の明確化
まずは 「RAG 導入で何を達成するのか」 を具体的に定義します。
目標は経営課題や部門KPIと直結させることで、社内承認や予算獲得がスムーズになります。
例えば...
■ 社内ヘルプデスクの一次回答時間を短縮(目標:平均10分 → 2分以内)
「経費精算の方法」や「VPN接続エラー」などの問い合わせを RAG で即時回答し、電話・メール対応の待ち時間を削減。
■ 建設現場での安全マニュアル検索を高速化(目標:平均15分 → 1分未満)
現場監督がタブレットから作業手順や安全ルールを即時検索可能にし、安全性と作業効率を向上。
■ 研究開発部門の文献調査効率化(目標:論文・特許・社内技術資料の調査時間を半減)
複数ソースを横断検索し、必要な引用や関連技術情報を RAG で自動要約。
ステップ 2:PoC(概念実証)の実施(推奨)
いきなり本番環境へ導入・実装するのではなく、小規模なテスト環境で RAG の基本性能を検証・評価することを推奨します。
現場メンバーや想定利用者をテストユーザーとして招き、初期段階でフィードバックを収集することで、本番展開時の失敗リスクを大幅に減らせます。
検証項目例
■ 回答精度:正答率、誤回答率、不要情報の混入率
■ 応答速度:ユーザーが許容できる待ち時間内に返答できているか
■ 使いやすさ(UI/UX):検索・閲覧・評価の操作性
■ 誤回答の傾向分析:誤情報や古い情報の参照パターンを特定
ステップ 3:現状分析と課題抽出
現行業務と比較し、現状分析と課題抽出しておきます。
現行業務の実値があればそれをベースライン(基準値)として利用します。
現行業務が存在しない、または数値化できない場合は、PoCで得られた結果をベースラインとして活用すると、その後の改善効果を定量的に測りやすくなります。
(実際、元データを数値化できていないケースは多く見受けられます。)
この段階で、抽出した課題をKPI候補に紐づけることで、その後のKPI設計や改善策の検討がスムーズになります。
現状の課題例 → KPI候補化の例
- 在庫情報の回答精度が80%未満 → Precision(適合率)
- 特定キーワードで関連情報がヒットしないケースが多い → Recall(再現率)
- 利用者のBad評価率が50件以上 → Good/Bad 評価(または利用者満足度)
ステップ 4:KPIの設定
RAG の導入効果を正しく測るには、ビジネス視点または技術視点のいずれか(理想は両方)でKPIを設定します。
あわせて、測定方法・レビュー周期・評価を担当するアクター(担当者や部署)を事前に定義しておくことで、責任の所在が明確になり、PDCA をスムーズに回せるようになります。
RAG の精度・効果測定で採用すべき KPI 例
| KPI名 | 定義 | 補足 |
|---|---|---|
| アクティブ利用率 | 利用対象者のうち、一定期間に RAG を利用したユーザーの割合 | ログイン履歴や会話履歴から利用ユーザー数を集計し、(利用ユーザー数 ÷ 全対象者数)×100 で算出 |
| Good/Bad 評価 | 回答後に利用者がGood/Badボタンで評価した比率 | UIで簡易評価を促し、即時フィードバックを収集。改善ポイント抽出に活用 |
| Precision(適合率) | RAG が返した回答のうち正解だった割合 | Ragas や Knowledge Base Evaluation を使い、評価データセット+LLM-as-a-Judge で算出。「不要な情報を含めない」精度指標 |
| Recall(再現率) | 正解として登録されている情報のうち取得できた割合 | Precision 同様に Ragas 等で算出。検索網羅性の評価指標で、情報漏れ防止に有効 |
| 問合せ対応時間 | 1件の質問に回答が出るまでの平均時間 | ユーザー操作時間+システム処理時間。短縮は業務効率改善の指標 |
| 利用者満足度 | 回答に対する5段階評価やアンケートスコア | ユーザーに満足度アンケートを実施。NPS(推奨度)や星評価(★1〜★5)も活用可 |
| コスト削減額 | 導入前後で削減できたシステム費・人件費などの金額 | システム費:Cost Explorer や Calculator から算出 人件費:input/output のトークン数から推定した削減時間 × 人件費単価。カテゴリ別(顧客対応、社内調査、資料作成、コード生成など)に分けて算出すると分析精度が向上 |
| レイテンシー | 回答が返るまでの平均処理時間 | サーバー処理+ネットワーク時間を含む |
| 初回解決率(FCR) | 人手を介さず RAG が即時解決できた割合 | 業務効果を示す代表的なKPI |
| 二次対応件数 | RAG だけで解決できず人にエスカレーションされた件数 | 件数または割合で計測 |
| ナレッジ更新数 | RAG や生成 AI が自動または半自動で更新したナレッジ件数 | 月次・四半期ごとに集計 |
ステップ 5:改善サイクル(PDCA)
KPI をもとに改善を繰り返します。
一度設定したKPIも運用フェーズや利用状況に応じて定期的に見直す必要があります。
- Plan(計画):改善施策を立案
- Do(実行):計画した施策を実装・運用する
- Check(評価・分析):KPIで効果を測定し、原因を分析する
- Act(行動):有効な施策は標準化。未達要因を是正検討し次のPlanへ
RAG の改善アプローチ
KPI をもとに PDCA を回す際は、RAG 自体の改善策も検討することが必要となります。
精度・再現性・応答速度といった指標を向上させるには、データ構造や検索手法、モデル活用方法まで含めた包括的な見直しが必要になります。
まずは、必要なドキュメントが十分に収集できているかを確認し、ノイズ(古いデータや重複データ、誤ったデータ)の除去を行いましょう。
それでも検索精度の改善が見込めない場合は、AWS の「Advanced RAG」の考え方をベースに、まずはここから *1 → 高度な Retrieval *2 → エージェント *3 or ファインチューニング *4 or Graph RAG の順でアプローチをしていくことをおすすめします。
まとめ
RAG は外部データを活用して生成 AI の精度を高められる強力な仕組みですが、KPIを定義していなければ効果が曖昧になりがちです。
導入初期からビジネス視点(初回解決率、コスト削減、満足度)や技術視点(Precision, Recall, レイテンシー)で評価することが効果的だと思います。
また、PoC から小規模に始め、データとフィードバックをもとに PDCA を回せば、RAG の精度と価値は継続的に向上し、成果を数値で可視化することで組織内の合意形成や追加投資判断にも有効です。
改善し続けることで、RAG は価値を高め、精度を磨き続ける AI となると思います。
評価方法については、AWSの資料も参考になりますので一読していただくと理解が深まるかと思います。
Retrieval-Augmented Generation(RAG) の評価(AWS 資料)
*1:まずはここから:チャンクサイズの調整, ドキュメントパースの改善, メタデータによるフィルタ, ハイブリッド検索の導入
*2:高度な Retrieval:リランキング, クエリ書き換え, Small-to-big Retrieval
*3:エージェント:クエリ計画, クエリルーティング, マルチドキュメントエージェント
*4:ファインチューニング:埋め込みモデルの微調整, テキスト生成モデルの微調整
近藤 諒都
(記事一覧)カスタマーサクセス部CS5課
夜行性ではありません。朝活派です。
趣味:お酒、旅行、バスケ、掃除、家庭用パン作り(ピザも)など
2025 Japan AWS All Certifications Engineers