結論：15〜50名程度の小規模企業で社内AIを試すなら、最初のPoCは実際の業務質問50〜100問程度を目安にすると、よくある質問だけでなく失敗しやすいパターンも混ぜやすくなります。ただし50〜100問は絶対基準ではありません。重要なのは、正答だけでなく、検索・出典・未回答・権限・更新・利用定着を分けて評価することです。
PoCは「AIが賢いか」ではなく「業務で使えるか」を確かめる
PoC（Proof of Concept）は、本番導入前に「この仕組みが自社の業務で成立するか」を小さく確かめる検証です。社内AIの場合、モデル単体の知識テストではなく、自社資料を検索して回答する一連のシステムを見ます。
2026年9月にNISTが公開したARIA Evaluation Planning Manualは、AIアプリケーションの評価を、Model Testing、Red Teaming、User Testingという複数の方法を組み合わせて考える枠組みとして整理しています。社内AIでも、単純な回答テストだけでなく、失敗させる試験と実利用者による試験を分ける方が実態を把握しやすくなります。
避けたい評価：提供会社が用意した「答えやすい質問」だけを5〜10問試して、すべて答えたから導入を決めること。実際の社員は略語、曖昧な質問、古い言い回し、資料にない質問もします。
なぜ50〜100問を目安にするのか
50〜100問という数字は、業界標準として定められた合格ラインではありません。小規模企業が初期PoCを行う際に、質問パターンの偏りを減らしつつ、人手で結果を確認できる現実的な規模としての目安です。
20問程度でも明らかな不具合は見つかりますが、すべて「よくある簡単な質問」になりやすく、表記ゆれや更新、未回答、権限といった例外パターンが入りません。一方、最初から数千問の評価セットを作ると、PoC準備自体が負担になります。
質問数より大切なのは質問の種類を分けることです。たとえば80問なら、次のように構成できます。
| 質問カテゴリ | 例 | 目安 |
|---|---|---|
| 日常的によくある質問 | 申請方法、製品仕様、手順、社内ルール | 25問 |
| 言い換え・略語・口語 | 正式名称を使わない質問、社内略称 | 10問 |
| 表・Excel・数値 | 料金表、型番、条件、一覧から探す質問 | 10問 |
| 旧版・新版 | 更新前後で答えが変わるルール | 10問 |
| 資料に答えがない質問 | 存在しない制度、未登録情報 | 10問 |
| 権限差の確認 | 一般社員と限定ユーザーで結果が変わる質問 | 5問 |
| 曖昧・意地悪な質問 | 前提不足、複数解釈、誘導質問 | 10問 |
評価項目1：回答内容は業務上使えるか
最初に見るのは、質問に対して必要な情報が返っているかです。ただし「完全一致の正解文」を作る必要はありません。業務で必要な事実が含まれているか、不要な推測を加えていないかで判定します。
結果は「正解／不正解」だけでなく、そのまま使える・出典確認が必要・使えないの3段階に分けると実務判断しやすくなります。
評価項目2：正しい資料を検索できているか
RAGでは、回答生成より前に「必要な資料を検索できたか」が重要です。回答が悪いとき、LLMが悪いのか、検索で違う資料を拾ったのかを分けて見ないと改善点が分かりません。
MicrosoftのRAG評価ドキュメントも、Document RetrievalやRetrievalと、Groundedness、Relevance、Response Completenessなどを分けて評価しています。つまり「検索」と「生成」を別の段階として測る考え方です。
評価項目3：回答の出典は妥当か
答えの文章がそれらしくても、出典が違う資料なら本番では危険です。PoCでは、回答内容と一緒に参照元を確認します。
- 質問に関係する資料が出典になっているか
- 該当箇所を人が読んでも回答を裏付けられるか
- 古い版ではなく現行の正本を参照しているか
- 複数資料が必要な質問で片方だけ見ていないか
Nexfila AIでの考え方は出典を確認できるRAGの使い方でも説明しています。
評価項目4：資料に答えがないとき、無理に答えないか
社内AIにとって重要なのは、答えられる質問に強いことだけではありません。資料に根拠がないときに、もっともらしい回答を作らないことも重要です。
テストセットには必ず「資料には答えが存在しない質問」を入れてください。理想的な挙動は、答えが見つからないことを伝え、必要なら関連資料や担当者確認へ誘導することです。
評価項目5：古い資料と新しい資料が混ざったとき
実運用では、旧版マニュアルや過去の料金表が残ることがあります。社内AIが自動的にどちらが正しいか保証するとは限りません。
PoCでは意図的に旧版と新版を含め、どちらを検索するかを確認します。新しい資料を正本として使いたいなら、ファイル名、メタデータ、削除・差し替え運用などを含めて設計する必要があります。詳しくは社内AIの資料更新・差し替えを参照してください。
評価項目6：PDFだけでなくExcel・表も試す
文章だけのPDFは答えられても、Excelの複雑な表、結合セル、複数シート、画像化された表では検索品質が落ちる場合があります。
自社で実際に使うファイル形式をPoCへ入れ、「この料金はいくら」「この型番の条件は何か」といった表検索を試します。AIに合わせて資料を全部作り直すのではなく、どの既存資料までそのまま使えるかを見極める検証です。
評価項目7：社員が実際に使う言い方で聞く
PoC担当者だけで質問を作ると、資料に書かれた正式名称をそのまま使いがちです。しかし実際の社員は、略語、旧称、口語、言い間違いを使います。
できれば総務、営業、現場、管理職など複数の利用者から「普段どう聞くか」を集めてください。同じ意味を2〜3種類の表現で聞くと、表記ゆれへの強さを確認できます。
評価項目8：権限外の資料を答えないか
回答精度が高くても、本来見えない資料を検索できるなら本番導入できません。一般社員、人事、経営など閲覧範囲が異なる場合は、同じ質問を異なるユーザーで試します。
「一般社員では回答されないが、権限を持つユーザーでは回答される」という結果になっているかを確認します。アクセス設計については社内AIのアクセス権限で詳しく整理しています。
評価項目9：資料更新後に答えが変わるか
PoC時点で答えられても、更新が反映されないシステムでは運用できません。テスト資料の一部を差し替え、旧回答から新回答へ切り替わるかを確認します。
更新反映にかかる時間、古い検索インデックスが残らないか、削除した資料が出典に出続けないかも見ます。
評価項目10：社員が迷わず使えるか
最後に、精度ではなく利用体験を見ます。NIST ARIAがUser Testingを評価の一部として扱うように、実際の利用者が使ったときの行動は、モデル評価だけでは分かりません。
質問を作れるか
「何を聞けばよいか分からない」状態にならないか。
出典を確認できるか
回答が不安なときに元資料へ戻れるか。
回答待ちが長すぎないか
日常利用でストレスになる速度ではないか。
使い続けられるか
最初の数日だけでなく、業務中に再利用されるか。
PoC結果は1つの「正答率」にまとめない
社内AIの評価では、一つの総合点だけにすると問題の場所が分からなくなります。最低でも次のように分けて記録すると改善しやすくなります。
| 指標 | 見ること | 失敗時に疑う場所 |
|---|---|---|
| 検索成功 | 正しい資料・箇所を拾えたか | 文書分割、Embedding、検索設定、表記ゆれ |
| 回答妥当性 | 業務上必要な事実を返したか | プロンプト、LLM、検索文脈 |
| 出典妥当性 | 回答を裏付ける資料が出ているか | 検索・引用ロジック |
| 未回答安全性 | 資料にない質問で断定しないか | 回答ルール、しきい値 |
| 権限 | 見てはいけない情報を参照しないか | RBAC、workspace、ACL |
| 更新反映 | 資料差し替え後に新情報へ変わるか | 再index、cache、正本運用 |
| 利用性 | 社員が自然に使えるか | UI、質問例、導線、応答速度 |
合格ラインは会社ごとに決める
「正答率90%なら導入」のような共通の合格基準はありません。用途によって許容できる失敗が違うためです。
たとえば社内FAQやマニュアル検索では、多少回答できない質問があっても、出典確認と担当者へのエスカレーションができれば運用可能な場合があります。一方、法令判断、医療、決済、重大な安全手順などでは、より厳しい評価と人間による確認が必要です。
PoC開始前に、「何ができれば導入するか」「何が起きたら導入しないか」を決めておくことが重要です。
PoCの進め方：5ステップ
1対象業務を1〜2個に絞る
総務FAQ、製品仕様検索、現場マニュアルなど、まず対象を限定します。
2代表資料だけを登録する
最初から全社資料を入れず、対象業務に必要な資料から始めます。
350〜100問程度の評価セットを作る
日常質問だけでなく、未回答、旧版、表、略語、権限を混ぜます。
4回答・検索・出典・権限を分けて記録する
「ダメだった」ではなく、どこで失敗したかを残します。
5数名の実利用者でPilotする
テストセットで通っても、実際の質問は予想外です。限定ユーザーで利用し、失敗例と利用率を確認します。
Nexfila AIの先行導入で確認したいこと
Nexfila AIでも、Pilot顧客の実データが蓄積した後は、実際の50〜100問テストから回答可能率、出典確認、未回答、PDF・Excel差、古い資料問題などを一次情報として公開する方針です。
現時点では第三者顧客の十分な実績がないため、実績値を装って「精度○%」とは表示しません。先行導入では、自社の資料と質問で実際に確かめてもらうことを重視します。
よくある質問
社内AIのPoCでは何問くらい試せばよいですか？
小規模企業の初期検証なら、50〜100問程度を一つの目安にできます。ただし質問数より、よくある質問・未回答・表記ゆれ・旧版・表・権限など複数パターンを含めることが重要です。
正答率だけ見れば評価できますか？
不十分です。検索した資料、出典、未回答時の挙動、権限、更新反映、利用者が使い続けられるかも別々に確認してください。
本番の機密資料を全部入れる必要がありますか？
ありません。代表資料で小さく検証し、データ取扱い・権限・削除・品質を確認してから対象を広げる方が現実的です。
RAGでは何を評価すべきですか？
検索で正しい情報を拾えたか、回答がその情報に基づいているか、質問への関連性、必要情報の抜けがないかを分けて見ると原因を特定しやすくなります。
PoCが成功したらすぐ全社展開してよいですか？
まず限定ユーザーのPilotを挟む方が安全です。実利用では質問の表現、資料更新、権限、応答速度、運用負荷がPoCと変わるためです。
参考にした一次情報・公開情報
- NIST「ARIA Evaluation Planning Manual: Elements of ARIA-Style AI Evaluations」
- NIST「TEVV-Athlon Framework for Evaluating AI Systems」
- Microsoft「Retrieval-Augmented Generation (RAG) evaluators」
- 社内AIの効果測定・KPI
- 社内AIの回答と出典確認