RAGの精度をどう評価する？社内AIチャットの質問テスト集の作り方

RAGや社内AIチャットの精度を評価するなら、担当者が思いついた質問を数回試すだけでは不十分です。

まず、実際の業務を代表する20〜30問程度の質問を用意します。各質問に「回答へ必ず含めたい要点」「参照すべき資料」「答えてはいけない内容」「合格条件」を付け、文書やモデルを変更した後も同じ条件で繰り返します。

重要なのは、AIの文章が自然かどうかだけで判断しないことです。

必要な資料を検索できたか。資料に書かれた範囲で答えたか。重要な条件を落としていないか。資料に答えがないときに、推測せず確認を促せたか。これらを分けて見ると、RAGのどこを直すべきか判断しやすくなります。

この記事では、小規模事業者や少人数チーム向けに、RAG・社内AIチャットの評価に使う質問テスト集の作り方、採点項目、質問の種類、更新後の再テスト方法を整理します。

すでに回答精度が低く、原因の切り分けから始めたい場合は、RAGの回答精度が低い時に見るべき原因も参考になります。

結論：RAGの評価は4項目に分ける

RAGの回答を一つの点数だけで評価すると、検索に失敗したのか、検索結果は正しいのに回答で間違えたのかが分かりません。

最初は、次の4項目に分けると実務で扱いやすくなります。

評価項目	確認すること	失敗時に見る場所
検索	必要な資料や該当箇所が取得されているか	文書、分割方法、検索語、絞り込み
回答	質問に直接答え、必要な要点を含んでいるか	プロンプト、モデル、回答形式
根拠	回答内容が取得した資料に基づいているか	参照情報、生成指示、引用表示
答えない判断	資料にないことを推測せず、確認を促せるか	対象範囲、拒否条件、案内文

たとえば、就業規則の申請期限を聞いたとき、正しい規則ファイルが検索できていなければ検索側の問題です。

正しい箇所が検索できているのに期限を間違えたなら、回答生成側の問題です。

期限は合っていても、対象者や例外条件を落としていれば回答の完全性に問題があります。

資料に制度が書かれていないのに、一般論から日数を作って答えたなら「答えない判断」の問題です。

この分け方をしておくと、「RAGの精度が悪い」という曖昧な感想を、修正できる作業へ変えられます。

デモでうまく答えた質問だけでは判断できない

RAGのPoCでは、作った本人が資料名や表現を知っています。

そのため、「経費精算マニュアルの提出期限を教えて」のように、文書の見出しと同じ言葉で質問しがちです。この質問に答えられても、実際の利用者が「領収書はいつまでに出せばいい？」と聞いたときに同じ資料へたどり着けるとは限りません。

また、答えが一つの段落にまとまった簡単な質問だけを試すと、次の失敗が見えません。

• 言い換えた質問で検索できない
• 複数の資料を比べないと答えられない
• 古い規定と新しい規定を取り違える
• 対象者や条件によって答えが変わる
• 資料に答えがないのに、それらしい内容を作る
• 閲覧できない資料の内容を回答へ混ぜる

良い質問テスト集は、AIが答えやすい質問の一覧ではありません。実際の利用場面で起きる言い換え、曖昧さ、例外、情報不足まで含む確認表です。

質問テスト集に入れる項目

最初から専用の評価システムを作る必要はありません。スプレッドシートでも、次の項目があれば始められます。

項目	記入内容
質問ID	Q001、Q002など変更しない識別子
質問文	利用者が実際に入力しそうな表現
質問タイプ	単純検索、言い換え、比較、対象外など
期待する要点	回答に必ず含めたい事実や条件
参照すべき資料	正解の根拠になる文書名、版、該当箇所
禁止事項	推測してはいけない内容、混ぜてはいけない旧情報
期待する動作	回答、追加質問、回答不可、担当窓口案内など
検索結果	必要な資料が上位に取得されたか
回答結果	必須要点、誤り、抜け、不要な断定
合否	合格、条件付き合格、不合格
実行条件	実行日、モデル、プロンプト、文書版、設定
修正メモ	失敗原因と次に変更する場所

特に重要なのは、質問文だけでなく「参照すべき資料」と「期待する要点」を先に決めることです。

回答を見てから正解を決めると、自然な文章に引っ張られて採点が甘くなります。

正解文は一字一句決めなくてよい

生成AIの回答は、同じ内容でも文章表現が変わります。

そのため、長い模範回答との完全一致だけで採点すると、内容は正しいのに言い回しが違う回答を不合格にしてしまいます。

実務では、次の3つを分けて定義すると採点しやすくなります。

1. 必ず含めたい要点

質問に答えるために欠かせない事実です。

たとえば「経費精算はいつまで？」という質問なら、申請期限だけでなく、締め日、対象となる費用、例外申請の有無が重要な場合があります。

要点は短い箇条書きにします。

• 利用日の翌月5日まで
• 原本提出が必要
• 期限を過ぎた場合は上長確認

2. 含めてはいけない内容

旧版の期限、別部署だけのルール、一般的な会社の慣習など、混ざると危険な内容を決めます。

「旧版の翌月10日を案内しない」「承認されたと断定しない」のように書きます。

3. 許容できる表現差

箇条書きか文章か、敬語の違い、同じ意味の言い換えなど、業務上問題のない差は許容します。

評価対象は文章の見た目ではなく、必要な情報が正しく、安全に伝わったかです。

質問は7種類を混ぜる

質問テスト集が簡単な事実確認だけに偏ると、実際の利用時の弱点が見えません。

次の7種類を混ぜます。

1. 一つの資料で答えられる基本質問

最も単純な確認です。

例:

• 交通費精算の提出期限はいつですか？
• 見積書の承認者は誰ですか？
• 休暇申請はどのフォームから行いますか？

基本質問で失敗する場合は、文書が登録されているか、検索対象になっているか、見出しや表が正しく取り込まれているかを確認します。

2. 利用者の言い換え質問

文書に書かれた正式名称を使わない質問です。

例:

• 立て替えたお金は何日までに出せばいい？
• お客さんに出す金額は誰に見てもらう？
• 明日休みたいときはどこから申請する？

社内では、略語、口語、古い呼び方、部署独自の言い方が使われます。実際の質問ログがある場合は、個人情報を除いたうえで表現の参考にします。

3. 複数資料を確認する質問

一つの文書だけでは答えが完成しない質問です。

たとえば、出張申請の手順は出張規程、申請フォーム、経費精算マニュアルに分かれていることがあります。

「大阪へ2泊の出張をするとき、事前申請から精算まで何が必要？」のような質問で、必要な資料を複数取得できるか確認します。

ただし、最初のPoCで複数資料の統合が必須でないなら、無理に難問を増やす必要はありません。実際の利用目的に必要な範囲で入れます。

4. 条件によって答えが変わる質問

部署、雇用形態、金額、契約区分などによって答えが変わる質問です。

例:

• 10万円を超える発注は誰の承認が必要ですか？
• 業務委託でもこの申請フォームを使いますか？
• 営業部と制作部で精算期限は同じですか？

条件が不足している場合は、勝手に一つへ決めず、「金額はいくらですか」「所属部署を確認してください」と追加質問できるかも評価します。

5. 最新版を選ぶ質問

文書更新後に、旧版ではなく現行版を使えるか確認します。

改定前後で変わった期限、申請先、料金、担当窓口などを質問します。

文書の追加・差し替え・削除ルールについては、RAGが古い資料を答え続けるのを防ぐ更新設計で詳しく整理しています。

6. 資料に答えがない質問

RAGの安全性を見るうえで重要な質問です。

社内資料に書かれていない将来の方針、未決定の料金、個別案件の判断などを質問し、推測で埋めないことを確認します。

合格例は、「登録資料では確認できません」「担当者へ確認してください」「判断に必要な条件が不足しています」のような応答です。

流暢でも、資料にない答えを作れば不合格です。

7. 権限外・対象外の質問

利用者が閲覧できない人事資料、顧客別見積もり、契約情報などを質問します。

検索結果にも回答にも権限外の内容が出ないことを確認します。

権限テストは、回答文だけでなく取得された文書一覧も確認します。最終回答で隠れていても、システム内部で権限外の文書を取得していれば設計上の問題が残ります。

アクセス制御の考え方は、社内AI検索で見えてはいけない資料を出さないためのRAG権限設計も参考になります。

最初の20問をどう配分するか

小規模なPoCなら、最初から数百問を作るより、利用頻度と失敗時の影響が大きい20問程度から始める方が運用しやすくなります。

配分例は次のとおりです。

質問タイプ	問数例	目的
基本質問	5問	主要資料を検索して答えられるか
言い換え質問	4問	実際の聞き方でも検索できるか
複数資料	3問	情報を組み合わせられるか
条件分岐・曖昧	3問	条件確認や追加質問ができるか
最新版	2問	旧情報を混ぜないか
答えなし	2問	推測を抑えられるか
権限外	1問	取得と回答を制限できるか

これは固定の正解ではありません。

社内規程検索なら最新版と権限外を増やします。製品マニュアル検索なら、型番違い、症状の言い換え、複数手順を増やします。問い合わせ回答支援なら、回答不可、確認事項、担当部署への引き継ぎを増やします。

重要なのは、利用目的に合わせて配分を決めることです。

合否基準は3段階でもよい

すべてを0点か100点で判断すると、改善の優先順位が分かりにくくなります。

最初は、次の3段階でも十分です。

判定	基準	対応
合格	必須要点と根拠が正しく、危険な断定がない	変更不要
条件付き合格	主要な回答は正しいが、補足不足や表現改善がある	利用影響を見て改善
不合格	事実誤り、重要条件の欠落、旧情報、権限外情報、根拠のない断定がある	公開・展開前に修正

質問ごとに重要度も付けます。

社内ランチ補助の案内と、契約金額や安全手順の案内では、失敗時の影響が違います。重要質問は1問でも不合格なら公開を止める、一般質問は全体合格率で見るなど、業務に合わせて基準を変えます。

単純な平均点だけで公開判断をしないことが重要です。

検索と回答を別々に記録する

RAGのテスト画面では、最終回答だけでなく、取得された資料やチャンクも確認できるようにします。

失敗は、次のように分かれます。

検索結果	最終回答	考えられる状態
正しい	正しい	合格
正しい	誤り	生成指示、モデル、回答構成を確認
誤り	誤り	文書、分割、検索、絞り込みを確認
誤り	偶然正しい	一般知識や推測で答えた可能性を確認

「答えだけ合っている」状態を合格にすると、後で資料が変わったときに誤回答が増える可能性があります。

社内RAGでは、正しい答えに加えて、正しい資料を取得していることも確認します。

回答へ出典を表示する設計は、利用者が確認しやすくなるだけでなく、評価時の原因切り分けにも役立ちます。詳しくは、社内AIチャットに根拠表示が必要な理由で解説しています。

一回の結果ではなく、同じ質問を繰り返す

生成AIの回答は毎回完全に同じになるとは限りません。

一度だけ合格した質問も、再実行すると要点が抜ける場合があります。重要な質問は複数回試し、「5回中5回合格」「5回中3回合格」のように安定性を確認します。

特に次の変更後は、同じ質問セットを再実行します。

• 社内文書を追加、差し替え、削除した
• 文書の分割方法や検索設定を変えた
• 埋め込みモデルや回答モデルを変えた
• プロンプトや回答形式を変えた
• アクセス権限や部署フィルターを変えた
• 検索結果の件数や並び替えを変えた

変更前の結果を基準として残しておけば、改善した質問と悪化した質問を比較できます。

新しい機能が動いたかだけでなく、以前できていた質問が壊れていないかを見るのが回帰テストです。

AIによる自動採点だけに任せない

質問数が増えると、回答の要点確認をAIで補助したくなります。

自動採点は、必須語の有無、参照文書、回答不可の表現、一定の評価基準を繰り返し確認する用途には役立ちます。

ただし、採点するAIも判断を誤る可能性があります。採点基準が曖昧なら、もっともらしい説明付きで誤判定することもあります。

小規模運用では、次の分担が現実的です。

• 機械で確認しやすい項目は自動化する
• 重要質問、不合格質問、境界事例は人が確認する
• 自動採点と人の判断が違った質問を記録する
• 採点基準を変えた場合は過去結果との比較条件を残す

「AIが5点と評価したから正しい」ではなく、業務担当者が重要な事実と運用上の危険を確認できる形にします。

実際の質問ログからテストを育てる

導入前は、業務担当者へのヒアリングや既存FAQから質問を作ります。

導入後は、実際の利用ログから次の質問を追加します。

• 何度も聞かれている質問
• 利用者が低評価を付けた回答
• 担当者が回答を修正した質問
• 検索結果が空だった質問
• 追加質問が必要だった曖昧な質問
• 文書更新後に答えが変わる質問

ログをそのままテストデータへコピーすると、氏名、顧客名、案件名、契約情報などが残る場合があります。必要に応じて匿名化し、テスト環境へ入れてよい内容だけを使います。

質問・回答・参照元・評価を改善に使うログ設計については、社内AIチャットのログ設計も参考になります。

小規模なRAG評価の進め方

最初は、次の順番で進めます。

1. RAGで支援したい業務を一つ決める
2. 利用者と文書の範囲を決める
3. 利用頻度と重要度が高い質問を20問集める
4. 各質問の必須要点、参照資料、禁止事項を決める
5. 検索結果と最終回答を記録できるようにする
6. 担当者が合格、条件付き合格、不合格を付ける
7. 失敗を検索、回答、根拠、答えない判断に分類する
8. 一度に一つの設定を変えて再実行する
9. 変更前後の結果と実行条件を保存する
10. 実際の利用ログから質問を追加する

最初から高度な評価基盤を作るより、同じ質問を同じ基準で繰り返せる状態を先に作る方が重要です。

スプレッドシートで限界が出たら、質問セット、実行結果、差分、担当者コメントを一覧化する小型ツールへ発展させられます。

YOSHIO.devで相談できること

YOSHIO.devでは、ローカルLLM・RAG環境構築、社内AIチャットのPoC、文書整理、評価用質問セット、小型の検証画面について相談できます。

たとえば、次のような相談です。

• RAGのPoCで何を合格条件にするか決めたい
• 実際の業務から20〜30問の評価質問を作りたい
• 検索結果と最終回答を分けて確認したい
• 資料にない質問で推測しない設計にしたい
• 文書更新やモデル変更後の回帰テストを行いたい
• スプレッドシートの評価表を小型ツール化したい
• クラウドAIとローカルLLMを同じ質問で比較したい

「精度を上げたい」という相談だけでも、対象業務、利用者、文書、失敗すると困る質問を整理すると、評価範囲を具体化できます。

機密情報を含む実データを最初から共有する必要はありません。文書の種類や質問例を匿名化し、小さな検証範囲から設計できます。

まとめ

RAGや社内AIチャットの精度は、数回のデモや文章の自然さだけでは判断できません。

まず、実際の業務を代表する20〜30問の質問テスト集を作ります。

各質問に、期待する要点、参照すべき資料、含めてはいけない内容、期待する動作を付けます。結果は、検索、回答、根拠、答えない判断に分けて確認します。

文書、モデル、プロンプト、検索設定を変えたら、同じ質問を同じ基準で再実行します。これにより、改善した点だけでなく、以前できていた質問が悪化していないかも確認できます。

大規模な評価システムより先に必要なのは、代表質問と合否条件を残し、比較できる状態です。

よくある質問