社内文書を対象とした RAG（検索拡張生成）の構築を外部の開発会社に発注しようとしたとき、提案書に「回答精度 90% を目指します」と書かれていたら、その数字をどう受け止めればよいでしょうか。上長から「その 90% は何を測った数字なのか、検収ではどうやって確認するのか」と問われて答えに詰まった、という経験をお持ちの方は少なくないはずです。
やっかいなのは、この問いに一言で答えられる「正解」が存在しないことです。RAG の精度は単一の数字ではなく、社内文書から必要な根拠を探し出す部分の精度と、その根拠から回答文を組み立てる部分の精度が別々に積み重なった結果として現れます。さらに、それらが良好でも現場の業務が楽になるとは限りません。どの層を測った数字なのかが揃っていない限り、複数社の提案を横並びで比較することもできません。
そして本当に困るのは、契約後です。評価の定義を決めないまま開発が進むと、検収の場で「これは合格なのか」の判断が主観に委ねられます。ベンダーは「PoC で示した水準は達成しています」と言い、発注側は「現場が使えないので受け入れられません」と言う。どちらも嘘をついていないのに合意できないという事態が起こります。この対立は技術の問題ではなく、合格ラインを事前に定義しなかったことによる契約の問題です。
この状況を避けるための道具が、RAG の評価指標です。指標を知る目的は、自分で評価を実施できるようになることではありません。ベンダーの評価レポートを読み解き、自社の業務用途に照らして「この数字がこの水準なら受け入れる」という合格ラインを、発注前に自分の言葉で提示できるようになることです。
本記事では、発注判断に必要な最小限の 4 指標（Context Recall / Context Precision / Faithfulness / Answer Relevancy）の読み方から始め、それらをまとめて算出する評価フレームワーク RAGAS の位置づけ、評価に不可欠な正解データの準備分担、そして合格ラインを検収条件・保守契約へ落とし込む手順までを、発注者の立場で解説します。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
RAG評価指標とは？「精度90%」だけでは発注判断できない理由
RAG 評価指標とは、RAG システムの品質を「検索できているか」「生成できているか」といった観点ごとに分解し、数値で表すための基準のことです。まずは、なぜ「精度」という一語では発注判断ができないのかを整理します。
「精度」という一語が指しているものは1つではない
RAG は、質問を受け取ってから回答を返すまでに、大きく 2 つの工程を通ります。1 つは、社内文書の集合から質問に関係しそうな箇所を探し出す「検索」の工程です。もう 1 つは、探し出した箇所を材料にして日本語の回答文を組み立てる「生成」の工程です。
この構造から、「精度」と呼ばれるものが少なくとも 3 種類存在することが分かります。
「精度」の指すもの | 測っている対象 | 悪いときに起きること |
|---|---|---|
検索の精度 | 質問に答えるために必要な文書を取り出せているか | 答えは社内文書にあるのに「見つかりませんでした」と返る |
生成の精度 | 取り出した文書に忠実で、質問に答える文章になっているか | もっともらしい嘘が混ざる、質問とずれた説明が返る |
業務での正答率 | 現場の担当者が「使える回答だった」と判断した割合 | 数値は良いのに現場から使われなくなる |
提案書に書かれた「回答精度 90%」がこの 3 つのどれを指しているかによって、意味はまったく変わります。検索の精度が 90% なのであれば、10 回に 1 回は根拠にたどり着けていないという話です。業務での正答率が 90% なのであれば、それは人間が評価した結果であり、誰が何問を評価したのかによって数字の重みが変わります。
複数社の提案を比較する際に最初にすべきことは、値の大小を比べることではなく、それぞれの数字が 3 種類のどれを指しているかを揃えることです。
RAG評価方法の基本は3層に分けて測ること（検索・生成・業務成果）
RAG 評価方法の基本は、この 3 種類を混ぜずに、層として分けて測ることにあります。層に分ける最大の利点は、問題が起きたときに原因の所在を切り分けられることです。
検索の層の数値が低ければ、原因は文書の分割方法・検索方式・元データの整備状況といった、根拠を取り出す仕組みの側にあります。検索の層は問題ないのに生成の層の数値が低ければ、原因はプロンプト設計や利用しているモデルの側にあります。両方が良好なのに現場から「使えない」と言われるのであれば、そもそも想定していた質問と現場の質問がずれています。
発注者にとって重要なのは、この 3 層のどこに問題があるかによって、直すべき相手と負担すべき費用の所在が変わるという点です。元データの整備は多くの場合に発注側の責任範囲に入りますし、プロンプト設計は開発会社の責任範囲に入ります。層を分けずに「精度が悪い」とだけ議論すると、責任の押し付け合いになります。
指標を定義しないまま発注すると検収で何が起きるか
指標と合格ラインを定義しないまま発注した場合、検収の場で典型的に次の 3 つが起こります。
1 つ目は、合否判定の主観化です。「体感では 7 割くらいは合っている気がする」といった議論になり、判断が担当者の感覚に依存します。担当者が交代すると評価も変わるため、いつまでも検収が終わりません。
2 つ目は、評価作業そのものの費用負担でもめることです。後述するとおり、指標を算出するには「この質問にはこの回答が正しい」という正解データが必要です。この作成には相応の工数がかかりますが、見積もりに含まれていないことが少なくありません。契約後に「どちらが何問作るのか」を交渉することになります。
3 つ目は、改修範囲の際限のない拡大です。合格ラインがない状態で「まだ精度が足りない」と指摘し続けると、開発会社側は無償対応の範囲を確定できません。結果として、追加費用の請求か、品質を諦めた妥協かのどちらかに着地します。
いずれも、契約前に「何を、どのデータで、いくつ以上なら合格とするか」を書面化しておけば避けられる種類の対立です。以降のセクションは、その書面を書くための材料を集める作業だと考えて読み進めてください。
検索側の評価指標｜Context PrecisionとContext Recall
まず、検索の層を測る 2 つの指標を見ていきます。RAGAS ではこの 2 つを Context Recall（文脈再現率）と Context Precision（文脈適合率）と呼び、いずれも 0 から 1 の範囲のスコアとして算出します（Ragas 公式ドキュメント）。
Context Recall（文脈再現率）｜必要な根拠を取りこぼしていないか
Context Recall は、回答に必要な情報のうち、実際に取り出せた割合を表します。Ragas の公式ドキュメントでは「関連する文書（または情報の断片）のうち、どれだけを取得できたか」を測る指標と定義されており、値が高いほど取りこぼしが少ないことを意味します（Ragas: Context Recall）。
業務の言葉に置き換えると、「答えは社内文書のどこかに書いてあるのに、システムがそこにたどり着けなかった割合」を裏返した数字です。たとえば「育児休業の延長申請はいつまでに出せばよいか」という質問に対して、答えは就業規則の付則に書かれているのに、システムが本則の別条項ばかりを取り出してしまうケースが該当します。
この指標が低いということは、生成側をどれだけ改善しても正解にたどり着けないということを意味します。材料が手元にないまま料理を作らせているのと同じ状態です。社内問い合わせの用途では、「答えられるはずの質問に答えられない」という体験がそのまま利用離脱につながるため、Context Recall は優先的に確認すべき指標になります。
なお、この指標を算出するには「本来どの情報が必要だったか」を示す正解データが必要です。Ragas の LLM ベースの実装でも、参照回答（reference）を主張単位に分解し、それぞれが取得した文脈で裏付けられるかを判定する方式が採られています。正解データがなければ算出できないという点は、後述する評価データセットの準備分担に直結します。
Context Precision（文脈適合率）｜取り出した文書のうち回答に役立った割合
Context Precision は、取り出した文書のうち、実際に回答の役に立った情報がどれだけ含まれていたかを表します。Ragas の公式ドキュメントでは、取得した文脈の中で関連するチャンクを上位に並べられているかというランキングの適切さを評価する指標として定義されています（Ragas: Context Precision）。
業務の言葉に置き換えると、「関係のない資料をどれだけ混ぜて渡してしまっているか」の裏返しです。この値が低い状態は、必要な情報は含まれているものの、その周囲に無関係な文書が大量に混ざっている状況を示します。
発注者が見落としやすいのは、Context Precision の低さが 3 つの形で跳ね返る点です。1 つ目は回答品質で、無関係な情報が混ざるほど生成側が引きずられ、的外れな回答が出やすくなります。2 つ目は費用で、生成モデルに渡す文章量が増えるほど利用料金が増加します。3 つ目は応答速度で、渡す量が増えれば回答が返るまでの待ち時間も伸びます。
つまり Context Precision は、品質だけでなくランニングコストと体感速度にも関わる指標です。ベンダーから「精度を上げるために取り出す件数を増やしました」という説明を受けた場合は、Context Precision と月額のモデル利用料が同時にどう変化したかを確認するのが妥当な質問になります。
検索側の数値が低いときに疑う3つの原因と、開発会社に返す質問
検索側の数値が低いとき、原因は次の 3 つのいずれかであることが大半です。重要なのは、このうち 2 つは発注側の資産に起因しうるという点です。
1. 文書の分割方法（チャンク設計）が用途に合っていない
RAG は文書を一定の単位に切り分けて検索対象にします。この切り方が細かすぎると前後の文脈が失われ、粗すぎると無関係な記述が同居して Context Precision が下がります。表や箇条書きの多い社内規程・マニュアルは、切り方の影響を特に受けやすい種類の文書です。この論点の詳細はRAGのチャンク分割で解説しています。
2. 検索方式が質問の性質に合っていない
意味の近さで探す検索方式は言い換えに強い一方、型番・条文番号・固有名詞といった「文字列そのものが重要な語」を取りこぼしやすい傾向があります。社内文書では両方の質問が混在するため、方式の組み合わせが結果を左右します。具体的な考え方はハイブリッド検索とRAGの検索精度で扱っています。
3. 元データ側に問題がある
同じ規程の新旧版が両方登録されている、スキャン画像の PDF で文字が抽出できていない、部署ごとに用語が違う、といった状態では、検索の仕組みをどれだけ改善しても限界があります。これは開発会社の実装品質ではなく、発注側の文書管理の問題です。
これらを踏まえると、検索側の数値が低いという報告を受けたときに返すべき質問は次のようになります。
- 低かった質問はどのような種類でしたか（言い換えの多い質問か、固有名詞を含む質問か）
- 取りこぼした根拠は、そもそも検索対象のデータに含まれていましたか
- 分割方法や検索方式の変更で改善余地はありますか。その場合の追加工数はどの程度ですか
- 元データ側の整備が必要な場合、対象となる文書と作業量を提示していただけますか
この質問群を投げられる状態になっていれば、「精度が出ない」という報告を責任のなすりつけ合いにせず、次の作業の切り分けに変換できます。
生成側の評価指標｜FaithfulnessとAnswer Relevancy
次に、生成の層を測る 2 つの指標です。検索で集めた根拠が手元にある前提で、そこから作られた回答文の品質を評価します。
Faithfulness（忠実性）｜ハルシネーションを数値で検知する
Faithfulness は、生成された回答が、取り出した根拠に忠実であるかを表す指標です。Ragas の公式ドキュメントでは「生成された回答が、提供された文脈に基づいており、事実に反する情報を持ち込んでいないか」を判定する指標として位置づけられています（Ragas 公式ドキュメント）。
算出の考え方はシンプルです。回答文を主張の単位に分解し、そのうち根拠文書から裏付けられるものの割合を取ります。回答に含まれる 5 つの主張のうち 4 つが根拠で裏付けられ、1 つが根拠に存在しない情報であれば、スコアは 0.8 になります。
社内向けの AI 導入において、この指標がもっとも直接的に業務リスクと結びつきます。RAG で最も怖いのは「答えられないこと」ではなく、「もっともらしい嘘を自信ありげに答えること」だからです。存在しない申請期限や、実際には廃止された制度の説明が返ってくれば、それを信じた従業員が誤った手続きを取ります。Faithfulness は、この種の危険を数値で検知するための指標です。
ここで注意したいのは、Faithfulness が高いことは「回答内容が世の中の事実として正しい」ことを保証しないという点です。保証するのはあくまで「渡された社内文書に忠実である」ことです。元の社内文書自体が古ければ、その古い内容に忠実な回答が返ります。文書の鮮度管理は、指標では代替できない発注側の責務です。
Answer Relevancy（回答関連性）｜質問に答えているかを測る
Answer Relevancy（Ragas の最新のドキュメントでは Response Relevancy とも表記されます）は、生成された回答が質問の意図にどれだけ的確に応えているかを表す指標です。根拠に忠実であることと、質問に答えていることは別だという前提に立っています。
たとえば「経費精算の締切はいつですか」という質問に対して、経費精算規程の目的や適用範囲を長々と説明し、締切日には触れずに終わる回答は、Faithfulness としては高くなり得ます。書かれている内容はすべて根拠文書に忠実だからです。しかし質問には答えていません。この種の「間違ってはいないが役に立たない回答」を検知するのが Answer Relevancy の役割です。
つまり、生成側の 2 指標は次の 2 つの失敗パターンに対応しています。
失敗パターン | 症状 | 検知する指標 |
|---|---|---|
根拠にない情報が混ざる | 存在しない期限や制度をもっともらしく述べる | Faithfulness |
質問に答えていない | 根拠には忠実だが、聞かれたことに触れず冗長 | Answer Relevancy |
どちらのリスクを重く見るかは業務用途によって変わります。誤った情報が実害に直結する用途（安全・法務・顧客対応）では Faithfulness を優先し、一次回答の効率化が主目的の用途では Answer Relevancy の重みを上げる、という判断になります。この優先順位付けが、後述する合格ラインの設計にそのままつながります。
生成側の数値が低いときに疑う原因（プロンプト設計・文脈量・モデル選定）
生成側の数値が低い場合、原因は主に開発会社の設計判断の側にあります。代表的な 3 つを挙げます。
1 つ目はプロンプト設計です。「根拠に書かれていないことは答えない」「根拠がない場合は分からないと回答する」といった指示が組み込まれているかどうかで、Faithfulness は大きく変わります。回答を無理に作らせる設計になっていないかは、確認すべき論点です。
2 つ目は渡す文脈の量です。根拠として渡す文書量を増やすと Context Recall は上がりやすくなりますが、無関係な情報も一緒に増えるため、生成側が引きずられて Faithfulness や Answer Relevancy が下がることがあります。検索側と生成側はトレードオフの関係になり得るという点は、レポートを読む際に押さえておくと理解が早くなります。
3 つ目はモデルの選定です。同じ根拠を渡しても、利用するモデルによって指示への従順さや日本語の扱いは変わります。コスト重視で軽量なモデルを選んでいる場合、その判断が数値に反映されている可能性があります。モデルを変更した場合の品質と月額費用の見込みを併せて提示してもらうと、判断材料が揃います。
RAGASとは？検索と生成を分けて測る評価フレームワーク
ここまで挙げた 4 指標をまとめて算出するために、開発の現場で広く使われているのが RAGAS です。
RAGASが発注者にとって有用な理由｜責任範囲を切り分けられる
RAGAS（Ragas）は、RAG パイプラインの評価に特化したオープンソースの評価フレームワークです。学術的な発表としては EACL 2024 のデモ論文「Ragas: Automated Evaluation of Retrieval Augmented Generation」として公開されており（ACL Anthology）、実装は GitHub 上で公開・保守されています（explodinggradients/ragas）。
発注者の立場から見た RAGAS の価値は、機能の豊富さではありません。検索の層と生成の層を分離して数値化できること、すなわち責任範囲を切り分けられることにあります。
「回答が良くない」という 1 つの現象に対して、Context Recall が低ければ根拠を取り出せていない、Faithfulness が低ければ根拠はあるのに逸脱している、と原因を特定できます。この切り分けができれば、改修の相手先と費用負担の議論を事実ベースで進められます。逆にいえば、ベンダーの評価レポートに検索側の指標がまったく含まれていない場合、その切り分けができない状態で検収を迎えることになります。
LLM-as-a-judgeによる自動採点の仕組みと限界
RAGAS の指標の多くは、LLM を採点者として使う「LLM-as-a-judge」という方式で算出されます。人間が 1 問ずつ目視で採点する代わりに、別の LLM に「この回答の主張は、この根拠で裏付けられるか」を判定させ、その集計としてスコアを出す仕組みです。
この方式の利点は、評価を繰り返し実行できることです。人手評価は 1 回あたりの負荷が大きく、設定を変えるたびに実施することは現実的ではありません。自動採点であれば、変更のたびに同じ基準で測り直せます。
一方で、発注者として認識しておくべき限界が 3 つあります。
採点者モデルのブレ: 採点も LLM による生成である以上、同じ入力でも実行のたびに判定が揺れる可能性があります。小数点以下の差を根拠に優劣を論じることには無理があります。レポートを読む際は、0.82 と 0.79 の差を意味のある差として扱わない姿勢が必要です。
採点コスト: 評価を実行するたびに LLM の API 呼び出しが発生します。評価データの問数が多いほど、また指標の数が多いほどコストは増えます。「毎月全問で再評価する」といった条件を安易に契約に書くと、その費用は最終的に発注側に転嫁されます。
人手による抜き取り確認が不可欠: 自動採点が業務上の妥当性まで判定してくれるわけではありません。スコアが高い回答が現場にとって使いやすいとは限らないため、検収時には現場担当者による目視の抜き取り確認を併用するのが実務的です。
RAGAS以外の評価ツールとの違いと、発注者が確認すべき3点
評価ツールは RAGAS だけではありません。汎用の LLM 出力評価フレームワーク、独自に構築した社内スクリプト、クラウド事業者が提供する評価機能など、開発会社によって選択は分かれます。
発注者の立場では、どのツールを使うかはベンダーの裁量に委ねてかまいません。ツール名を契約に書き込むと、より適した手段が出てきたときに身動きが取れなくなります。代わりに確認すべきは次の 3 点です。
確認事項 | 確認する理由 |
|---|---|
出力される指標が検索側・生成側の両方をカバーしているか | 責任範囲の切り分けができるかどうかが決まる |
採点方法（自動採点か人手か、採点に使うモデルは何か） | 数値の再現性と、比較可能性の前提を揃えるため |
同じ条件で再実行できるか（評価データと設定が保存されているか） | 改修前後の比較、および運用後の再評価に必要 |
3 点目は特に重要です。評価データと実行条件が保存されていなければ、「改修によって良くなった」という主張を検証できません。評価結果とあわせて、評価データ・実行条件の引き渡し方法を契約段階で確認しておくことをおすすめします。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
評価データセット（QAペア）は誰がどう準備するのか
ここまで説明したすべての指標には、共通の前提があります。「この質問に対しては、この情報が根拠で、この回答が正しい」という正解データが必要だということです。この準備をどちらが担うかは、費用と品質の両方に効いてくる論点です。
評価用データセットに必要な問数と質問の選び方
評価用データセットは、質問と期待される回答（および根拠となる文書）を組にしたものです。何問必要かは用途と求める確度によって変わりますが、問数を決める前に押さえるべきは質問の選び方です。
優先して含めるべきは、次の 4 種類です。
- 現場で実際に頻度の高い質問: 問い合わせ履歴やヘルプデスクの記録から抽出します。頻度の高い質問で外すと、体感の品質が大きく下がります
- 答えを間違えると実害が出る質問: 安全基準、法令に関わる手続き、金額に関わる規定など。ここは合格ラインを個別に厳しく設定する対象にもなります
- 言い換えや略語を含む質問: 現場では正式名称ではなく通称・略語で聞かれます。実際の言い回しをそのまま採用します
- 答えが存在しない質問: 社内文書に記載のない事柄を聞かれたときに「分かりません」と正しく答えられるかを確認します。この種の質問を含めていない評価は、ハルシネーション耐性を測れていません
4 番目は見落とされがちですが、社内公開の可否を判断するうえで重要な観点です。評価データの構成を確認する際は、この種の質問が含まれているかを尋ねてみてください。
問数については、少なすぎると 1 問の正誤でスコアが大きく振れ、多すぎると作成と採点の負荷が現実的でなくなります。まずは業務上重要な領域を優先して整備し、運用開始後に実際の質問ログから追加していく進め方が、負荷と実効性のバランスを取りやすい方法です。
準備責任は発注側か開発会社か｜費用への跳ね返りと決め方
評価データの作成は、見積もりから漏れやすい作業の代表格です。どちらが担当するかによって、次のように性質が変わります。
準備の主体 | 長所 | 短所 |
|---|---|---|
発注側（業務部門）が作成 | 現場の実際の言い回し・重要度が反映され、評価の妥当性が高い | 業務部門の工数を確保する必要がある。作成基準がばらつきやすい |
開発会社が作成 | 形式が統一され、評価の実行までを一貫して任せられる | 業務知識が不足し、現場と乖離した質問になりやすい。工数分が見積もりに乗る |
共同で作成（質問は発注側、形式整備は開発会社） | 現場の妥当性と形式の統一を両立できる | 役割分担と締切の調整が必要 |
実務上は 3 番目の共同作成が現実的です。「どの質問を評価対象にするか」の判断は現場の業務知識がなければできず、「どの文書のどの箇所を根拠とするか」の整理は開発会社が担ったほうが効率的だからです。
いずれの形を採るにせよ、契約前に次の 3 点を合意しておくと、後の負担でもめずに済みます。
- 評価データの問数と、その作成をどちらが何問担当するか
- 作成にかかる工数を見積もりに含めるか、発注側の持ち出しとするか
- 運用開始後に評価データを追加・更新する際の担当と費用
合成データ生成に頼るときの注意点
最近は、社内文書から LLM に質問と回答の組を自動生成させる手法（合成データ生成）も一般的になりました。作成負荷を大きく下げられるため、初期の評価データを揃える手段としては有効です。
ただし、合成データだけで評価を完結させる場合には注意が必要です。理由は 2 つあります。
1 つ目は、生成される質問が文書の書きぶりに引きずられることです。文書中の表現をそのまま使った質問が作られやすいため、現場の担当者が使う略語や口語的な言い回しが再現されません。実際の利用場面より易しい条件で測ってしまい、評価が甘くなります。
2 つ目は、文書に書かれている内容からしか質問が作られないことです。「文書に答えがない質問」が生成されにくいため、先ほど挙げたハルシネーション耐性の確認ができません。
現実的な進め方は、合成データで土台の問数を確保し、現場の問い合わせ履歴から抽出した実際の質問を一定数上乗せする形です。ベンダーから提示された評価データが合成のみで構成されている場合は、実質問の追加を依頼するとよいでしょう。
合格ラインの決め方と検収条件への落とし込み
ここからが本題です。指標の意味が分かっても、「いくつなら合格か」を決められなければ、検収の場での判断はやはり主観に戻ってしまいます。
なお、指標値に業界共通の絶対的な基準値は存在しません。用途によって許容できる誤りの水準が違う以上、汎用の合格点は原理的に定義できないためです。したがって、決め方の手順を持つことが答えになります。
業務用途から逆算して許容できる誤りの水準を決める
合格ラインは、指標の側からではなく、業務の側から逆算して決めます。手順は次の 3 ステップです。
ステップ 1: 誤りが起きたときの影響を書き出す
その回答を信じて行動した結果、何が起きるかを具体的に書き出します。「申請期限を間違えて手続きが遅れる」「誤った安全手順で作業する」「顧客に誤った案内をする」では、深刻度がまったく違います。
ステップ 2: 誤りを人間が止められるかを確認する
回答がそのまま最終判断に使われるのか、間に人間の確認が入るのかを確認します。社内担当者向けの一次情報として使い、最終判断は人が行う設計であれば、多少の誤りは運用で吸収できます。一方、顧客へ自動で返信する設計であれば、吸収する余地はありません。
ステップ 3: 用途の性質に応じて重視する指標と厳しさを決める
ステップ 1・2 の結果から、どの指標を優先し、どこまで厳しくするかを決めます。判断の方向性は次のように整理できます。
用途の性質 | 優先する指標 | 水準の考え方 |
|---|---|---|
社内担当者向けの一次情報（最終判断は人間） | Answer Relevancy / Context Recall | 取りこぼしの少なさを優先。多少の冗長さは運用で許容できる |
全社員向けの規程・手続き案内 | Faithfulness | 誤情報の混入を最優先で抑える。根拠の提示を必須にする |
顧客対応・安全・法務に関わる領域 | Faithfulness（最優先） | 単独の合格ラインでは不十分。人間の確認を挟む運用を前提にする |
重要なのは、すべての指標に一律の目標値を置かないことです。用途に照らして重み付けをした合格ラインのほうが、社内での説明も、ベンダーとの合意も通しやすくなります。
指標値と業務KPIをセットで合格条件にする
指標値だけを合格条件にすると、「数値は達成したが現場が使わない」という結末を避けられません。指標は業務成果の代理指標にすぎないためです。
そこで、指標値と業務 KPI をセットで検収条件に書くことをおすすめします。業務 KPI の例としては次のようなものが挙げられます。
- 一次回答率: 人間へエスカレーションせずに完結した問い合わせの割合
- 有用性評価: 利用者が「役に立った」と回答した割合（回答画面の評価ボタンなどで取得）
- 対応時間: 従来の問い合わせ対応にかかっていた時間との比較
- 利用継続率: 導入後一定期間の利用者数の推移
この 2 階建ての条件にしておくと、議論が建設的になります。指標値が未達なら技術側の改修、指標値は達成しているのに業務 KPI が未達なら想定質問と現場のズレ、というように、次に打つ手が特定できるためです。
検収条件に明記すべき4項目（対象指標・目標値・評価データ・不合格時の扱い）
最後に、合意した内容を検収条件として書面に落とします。最低限、次の 4 項目を明記してください。
1. 対象指標: どの指標を評価対象とするかを列挙します。検索側・生成側の両方から選ぶことが、責任範囲の切り分けを可能にする条件です。
2. 目標値と測定条件: 各指標の目標値に加えて、「どのモデルを採点者として使うか」「何回実行した結果の平均を採用するか」を書きます。採点にブレがある以上、実行条件を揃えなければ比較になりません。
3. 評価に用いるデータ: 検収に使う評価データの問数・構成・作成主体・確定時期を明記します。「検収の直前に開発会社が有利な質問セットを用意する」といった事態を避けるため、評価データは開発の早い段階で確定させ、双方で共有しておくことが望ましい進め方です。
4. 不合格時の扱い: 目標値に届かなかった場合の改修回数、改修費用の負担、それでも届かない場合の措置（納期の延長・範囲の縮小・契約の見直し）を定めます。ここを空欄にしたまま契約すると、改修が無限に続くか、品質を諦めるかの二択になります。
これらの条件を発注前にベンダーと擦り合わせておくと、提案段階での質問の質も上がります。評価以外の観点も含めた確認事項の全体像は、RAG導入で開発会社に確認すべき質問に整理していますので、あわせてご覧ください。
運用開始後の再評価｜精度は放置すると落ちる
検収時点の数値をクリアしても、それは「その時点の文書と、その時点のモデルで、その評価データを使った場合」の結果にすぎません。RAG の精度は、運用を続けるうちに変動します。
精度が落ちる3つの原因（文書更新・モデル更新・質問傾向の変化）
1. 対象文書の更新
規程が改定され、マニュアルが差し替えられ、新しい文書が追加されます。新旧が混在すれば検索結果が割れ、古い版が上位に来れば誤った回答の原因になります。文書を追加する運用フローと、古い版を検索対象から外す運用フローを決めておく必要があります。
2. 利用しているモデルの更新
生成に使う LLM は提供事業者側で更新され、旧バージョンの提供が終了することもあります。モデルが変われば、同じプロンプト・同じ根拠でも出力の傾向は変わります。改善する場合もあれば、これまで機能していた指示の効き方が変わる場合もあります。
3. 質問傾向の変化
利用者が慣れてくると、質問の仕方が変わります。当初は単純な用語の確認が中心でも、次第に複数の条件を組み合わせた複雑な質問が増えていきます。検収時の評価データが想定していた範囲を、実際の利用が超えていくということです。
いずれの原因も、開発会社の実装品質とは無関係に発生します。だからこそ、再評価の枠組みを最初から契約に織り込んでおくことが必要になります。
再評価の頻度と実施主体を保守契約に書く
保守契約には、次の 4 点を含めることを検討してください。
項目 | 決めておく内容 |
|---|---|
再評価の頻度 | 定期実行の間隔と、臨時実行の条件（文書の大規模改定時・モデル更新時など） |
実施主体と費用 | 誰が実行し、その費用が保守費に含まれるか別途か |
評価データの更新 | 実際の質問ログから評価データを追加・更新する頻度と担当 |
数値低下時の対応 | どの程度低下したら調査に着手するか、その調査と改修の費用負担 |
すべてを高頻度に設定する必要はありません。自動採点にはコストがかかるため、定期実行は重要な質問に絞った小規模なセットで行い、文書の大規模改定やモデル更新のタイミングで全問の評価を実施する、といった使い分けが現実的です。
あわせて、検収時に用いた評価データと実行条件を発注側の資産として引き渡してもらうことをおすすめします。これがあれば、将来ベンダーを変更する場合でも、同じ基準で新旧を比較できます。評価データは一度作れば長く使える資産であり、この観点は開発会社の乗り換え可能性を確保するうえでも意味を持ちます。
まとめ｜評価指標は「測る」ためではなく「合格ラインを握る」ために使う
RAG 評価指標を理解する目的は、自分で評価を実行することではなく、ベンダーの示す数字を読み解いて発注判断を下せるようになることにあります。本記事の要点を整理します。
指標は層に分けて読む: 「精度」は検索・生成・業務成果の 3 層に分かれます。発注判断に必要な最小限は、検索側の Context Recall（取りこぼしのなさ）・Context Precision（無駄のなさ）と、生成側の Faithfulness（根拠への忠実さ）・Answer Relevancy（質問への的確さ）の 4 つです。層に分けることで、問題の所在と責任範囲を切り分けられます。
合格ラインは業務から逆算する: 指標に業界共通の基準値はありません。誤りが起きたときの影響と、人間が止められるかどうかから逆算して、優先する指標と水準を決めます。そのうえで、指標値と業務 KPI をセットで検収条件に書きます。
評価データの分担を契約前に決める: 指標は正解データがなければ算出できません。問数・作成主体・費用負担・更新の担当を、契約前に合意しておきます。合成データのみで構成された評価データには、実際の質問と「答えが存在しない質問」を上乗せします。
再評価を保守契約に織り込む: 文書更新・モデル更新・質問傾向の変化によって精度は変動します。再評価の頻度・実施主体・費用・数値低下時の対応を、あらかじめ定めておきます。
提案書に「精度 90%」と書かれていたときに返すべき問いは、「その 90% は 3 層のどれを、どの評価データで測った数字ですか」です。この問いを起点に、合格ラインの設計・評価データの分担・再評価の枠組みまでを発注前に握れれば、検収の場で判断に迷う状況は避けられます。
関連情報
RAG や AI 開発の発注検討を具体的に進めたい方は、お役立ち資料から、発注前の要件整理や社内稟議に活用できる資料をご覧いただけます。
評価指標の設定や検収条件の書き方について個別にご相談がある場合は、お問い合わせフォームからご連絡ください。要件の整理段階からご相談いただけます。
はじめての AI 導入ガイド――中小企業が失敗しないための7ステップ
この資料でわかること
AI導入を検討しているが「何から始めればよいか分からない」中小企業の意思決定者に対し、導入プロジェクトの全体像を一気通貫で提示し、「自社でも着手できる」という確信と具体的な行動計画を持ってもらうこと。
こんな方におすすめです
- AI導入を検討しているが、何から始めればよいか分からない
- ベンダーの選び方や費用感がつかめず、判断できない
- 社内でAI導入の稟議を通すための資料が必要
入力いただいたメールアドレスにPDFをお送りします。
よくある質問
- RAGASの4指標のうち、発注者としてまず優先して確認すべきはどれですか？
業務用途にもよりますが、誤情報が実害につながる用途ではFaithfulness（根拠への忠実さ）を最優先で確認してください。次に、答えられるはずの質問に答えられているかを示すContext Recallを見ると、問題の所在を切り分けやすくなります。
- 複数のベンダーが提示した指標値は、そのまま数字の大小で比較してよいですか？
いいえ。採点に使ったモデルや評価データの問数・構成が揃っていなければ、数値の大小だけを比較しても意味がありません。LLM-as-a-judgeによる採点は実行のたびに結果がブレるため、各社に測定条件を確認し、揃っていない場合は同一条件での再算出を依頼してください。
- 評価データセットの作成費用は、最初から見積もりに含めてもらうべきですか？
はい。評価データの作成は工数のかかる作業で見積もりから漏れやすく、契約後に「どちらが何問作るのか」でもめる原因になります。契約前にどちらが何問作成するか、作成にかかる工数を見積もりに含めるかを合意し、見積もりに明記しておくことをおすすめします。
- ベンダーがRAGASを使っていない場合、評価の妥当性はどう判断すればよいですか？
ツール名にはこだわらず、検索側・生成側の両方を数値でカバーしているか、採点方法（自動採点か人手か、使用モデルは何か）が明確か、同じ条件で評価を再実行できるかの3点を確認してください。これらを満たしていれば、RAGAS以外のツールでも問題ありません。
- 指標のスコアが0.82と0.79のようにわずかに違う場合、優劣を判断してよいですか？
いいえ。LLM-as-a-judgeによる採点は実行のたびに結果がブレるため、小数点以下のわずかな差を優劣の根拠にはできません。契約書には目標値だけでなく、採点に使うモデルや実行回数といった測定条件も明記し、複数回実行した平均や傾向で判断してください。
- 検収時に合格ラインをクリアしていれば、その後は評価をしなくてもよいですか？
いいえ。文書更新・モデル更新・質問傾向の変化によって精度は運用中に変動するため、検収時の数値はその時点の結果にすぎません。再評価の頻度・実施主体・費用負担・数値低下時の対応を保守契約にあらかじめ定めておくことが必要です。
