AI導入前の品質チェック｜正答・回答不可・権限外を分けて評価する

先に、要点をまとめます。

• AIの回答品質は「正しく答えられた割合」だけでは判断できません。答えられない質問への振る舞い、古い資料の参照、権限外の情報、担当者の修正負担 を分けて評価してはじめて、業務に乗せてよいかを判断できます。
• 品質のばらつきは実測されています。Stanford HAI「2026 AI Index」では、 主要26モデルのハルシネーション率が22〜94%の幅 で報告されました。モデル選定だけで品質は決まりません。
• 導入前に確認するのは10項目です。特に効くのは、 評価セットを作ってから測ること と、 撤退基準を先に書面化すること 。この2つを飛ばすと「動くけれど信用できないAI」が社内に残ります。

2026年9月23日時点の情報です。

AIの回答品質が心配なとき、導入前に何を確認すべきか？

「正しい回答が出るか」ではなく、「間違いをどう検知し、誰が止めるか」を先に決めます。

回答品質への不安は、多くの場合「AIが嘘をつくかもしれない」という漠然とした形で語られます。しかし業務で困るのは、嘘そのものより 「嘘に気づけない状態」 です。自然な日本語で書かれた回答は、参照した資料が古くても、必要な条件を省いていても、根拠にない数字を足していても、読んだ人には同じように見えます。

そこで、導入前の確認は次の10項目に分解します。上から順に確認してください。順番が重要です。

#	確認項目	何を見るか	未確認のまま進んだ場合
1	想定用途を1業務に絞れているか	最初の1業務を1文で書けるか	良し悪しの判定基準そのものが作れない
2	正答の定義があるか	「正しい回答」の合否基準を人が文章化したか	以降のすべての測定がぶれる
3	評価用の質問セットを用意したか	実務で実際に聞かれる質問を抽出したか	デモの数問で「良さそう」と判断してしまう
4	誤りの発生率を測定したか	評価セットに対する割合を数値で記録したか	「たまに間違える気がする」で止まる
5	出典提示の有無を確認したか	回答の根拠となる資料・URLを示せる設計か	利用者がその場で真偽を確かめられない
6	想定外の質問への振る舞いを決めたか	「わかりません」と答えさせる範囲を定義したか	範囲外の質問にも創作して答える
7	機密情報の境界を引けているか	送信・参照してよい情報の範囲を社内で合意したか	ツール選定後に手戻りが発生する
8	人がレビューする手順があるか	最終確認者と差し戻しフローが決まっているか	「みんなで気をつける」は手順ではない
9	ログと改善サイクルを設計したか	誤回答が出たとき誰がいつ直すか決まっているか	誤りが放置され信頼が失われる
10	撤退基準を決めたか	何を下回ったら停止するか書面化したか	使われないAIを抱え続ける

10項目すべてに自信を持って「はい」と答えられない場合、全社展開の段階ではありません。1業務・1チームに絞った検証から始めてください。

なぜ回答品質が経営課題になるのか？

誤回答は会議資料・商談・契約書に紛れ込み、訂正に割ける人員が少ない組織ほど影響が大きくなるからです。

機能追加・AIを組み込みたいについて相談するいまの業務システムは残したまま、機能追加・改修やAIの組み込みで手間を減らす受託開発。書類の読み取り、社内資料への回答、既存システムとの連携まで機能追加・AIを組み込みたいを見る →

品質のばらつきは感覚ではなく実測されています。Stanford HAI「2026 AI Index」の Responsible AI 章では、主要26モデルを対象としたハルシネーション率が22〜94%の幅で報告されています。同章はもう一つ重要な指摘をしています。誤った前提が「第三者がそう信じている」という形で示されたときはモデルはうまく扱えるのに、同じ誤りを「利用者自身がそう信じている」形で示すと正答率が大きく落ちる という現象です。GPT-4oの正答率が98.2%から64.4%へ下がった例が挙げられています。

業務利用で考えると、これは無視できない性質です。社内の担当者は「たしかこの規程は◯◯だったはず」という前提を付けて質問します。利用者が誤った前提を持っているときほど、AIはその前提に追従しやすい ということになります。評価セットを作るときは、わざと誤った前提を含む質問を入れてください。

導入側の実態も確認できます。中小企業基盤整備機構「中小企業のAI等の利活用に係る実態調査」（2026年3月公表・調査期間2025年11月17日〜12月12日・全国の中小企業10,000社対象）によると、AIの導入率は20.4%、導入を検討している企業18.6%と合わせて39.0%が前向きです。一方で、社内の情報充足度を尋ねた設問では、 「成功事例や活用事例などの情報が十分に入手できている」に当てはまらないとする回答が83.3%、「適切なベンダーや製品を選定する情報が十分にある」が当てはまらないとする回答が79.8% でした。判断材料が足りないまま検討が進んでいる状況が読み取れます。

「正答」の定義はどう決めるのか？

同じ回答でも、要点が合っていれば正解とするのか、社内の言い回しまで一致させるのかで評価は変わります。測定前に文章化してください。

判定は4分類に分けると集計しやすくなります。

判定	意味	社内規程検索での例
正解	期待した要点をすべて満たす	手順・担当・注意点まで現行版で正しい
部分正解	要点の一部が欠落・不正確	手順は正しいが旧様式を案内している
誤り	事実と異なる内容を含む	存在しない規程を引用する
回答拒否	答えずに人への確認を促す	範囲外の質問に「担当に確認してください」と返す

重要なのは、範囲外の質問への「回答拒否」を誤りではなく望ましい振る舞いとして数えることです。 何でも答えるAIより、答えないと言えるAIのほうが業務では信頼されます。回答拒否を誤りに含めて集計すると、「創作してでも答えるAI」のほうが高得点に見えてしまいます。

評価表には何を書くのか？

質問ごとに、期待する動作と、不合格になる具体的な出力の両方を書きます。

以下は社内規程検索を題材にした記入例です。期待動作だけでなく「不合格の例」を書いておくと、判定者が交代しても基準が揃います。

質問・条件	期待する動作	不合格の例
通常の出張精算	現行規程と申請先を案内する	旧版の金額を回答する
規程にない例外	不明と示し確認先を案内する	類似規程から条件を創作する
他部署限定の文書	権限外の内容を返さない	タイトルだけが漏れる
同名の旧版と新版	適用日を見て現行版を区別する	更新日だけで機械的に選ぶ
元文書を削除した後	削除を反映して参照しない	キャッシュから旧情報を返す
誤った前提を含む質問	前提の誤りを指摘して訂正する	誤った前提に合わせて回答を組み立てる

最後の行が、前章で触れた「利用者の前提への追従」に対応する検査です。「たしか出張手当は5,000円でしたよね？」のような、実際と異なる数字を含む質問を必ず混ぜてください。

評価データはどう作るのか？

実務の質問・曖昧な質問・範囲外の質問・古い情報の質問・言い換え質問を混ぜ、期待回答を先に人が書きます。

集める質問の種類を整理します。

質問の種類	例	何を検査しているか
実務で実際に聞かれた質問	チャット・メール・電話メモから抽出	通常運転での正確さ
わざと曖昧にした質問	「あの件どうなった？」	確認を返せるか、憶測で答えないか
範囲外の質問	医療・法律・金銭判断に関わる内容	回答拒否できるか
古い情報を聞く質問	廃止された制度や旧価格	現行版を区別できるか
同じ意図の言い換え	用語の揺れを含む聞き方	表記ゆれに耐えるか
権限外の文書を狙う質問	他部署限定の資料の内容	権限制御が効いているか

質問は、個人情報を伏せたデータで構いません。ただし 権限と文書の状態（最新版か旧版か、削除済みか）は実際の運用と同じように再現してください。 ここを簡略化すると、本番で最も事故が起きやすい部分が検査されないまま合格します。

もう一つ、調整に使った質問だけで合格を判断しないでください。プロンプトや検索設定を調整する過程で使った質問は、その設定に合わせて調整済みです。調整に使わず別に取っておいた質問でも確かめること が、実際の性能を知る最低条件です。

測定した数字はどう記録するのか？

件数、対象文書、モデルと設定、確認日、判定者、判定ルールをセットで残します。

数字だけを残しても、後から比較できません。次の項目を必ず添えてください。

記録する項目	理由
評価した質問の件数と内訳	母数が違うと割合を比較できない
対象文書の範囲と時点	文書が増減すれば結果も変わる
使用したモデル名と設定	モデル更新で結果が変わるため再現に必要
確認日	「いつ時点の性能か」が判断材料になる
判定者	判定のぶれを後から確認できる
判定ルール	部分正解の線引きを揃える

加えて、 再試行して成功した場合は初回成功と分けて記録 してください。「もう一度聞いたら正しく答えた」は、業務では初回失敗として扱うべき場面が多くあります。回答が採用されたか、修正が必要だったか、根拠へ到達できたかも別々に数えます。担当者の修正負担が減っていなければ、正答率が高くても導入効果はありません。

本番稼働後は何を管理するのか？

モデル、検索方法、対象文書、アクセス権限のいずれかが変われば、結果も変わり得ます。変更のたびに同じ評価セットで再確認します。

変更の種類ごとに、再確認の必要性を整理します。

変更の種類	再評価の必要性	先に確認すること
モデルのバージョン更新	必須	提供元の更新告知と、切り戻しできるか
参照文書の追加・削除	必須	旧版が残っていないか、削除が索引に反映されるか
検索方法・プロンプトの調整	必須	調整に使った質問以外でも改善しているか
アクセス権限の変更	必須	権限外の質問セットが引き続き不合格を返すか
利用者の増加のみ	任意	新しい質問パターンが出ていないか

不合格だった場合に戻す条件を、変更前に決めてください。 「新しいモデルのほうが賢そうだから」で切り替えて、評価セットが通らないまま運用を続けると、品質の根拠が失われます。

あわせて、利用者が問題を報告できる窓口と、元資料やプロンプトを更新する担当を決めます。誤回答は必ず出ます。問題は、出たときに誰がいつ直すかが決まっているかどうかです。

回答品質の評価シートには、期待結果と判定を記入できます。ここに示した例は当社の実測精度ではありません。

自社で評価しきれないときはどうするか？

評価セットの設計、参照範囲の絞り込み、ログ分析のどこが負担かを切り分けてから、外部に頼む範囲を決めます。

すべてを社内人員だけで進めるのは負担が大きいのも事実です。ただし、外部に丸ごと任せると「何をもって合格としたか」が自社に残りません。次の切り分けが現実的です。

工程	社内で持つべきか	理由
想定用途の決定	社内	業務を知らないと1業務に絞れない
正答の定義	社内	何を正しいとするかは業務判断
評価セットの質問収集	社内（支援可）	実際に聞かれている質問は現場にしかない
評価の設計・集計の仕組み	外部に依頼可	手法の型があると早い
参照範囲の絞り込み・実装	外部に依頼可	権限設計と検索の実装が中心
撤退基準の決定	社内	停止判断は自社の責任

当社の作業単価は1時間11,000円（税込）です。範囲と工数はヒアリング後に算出するため、まず対象業務と現状を教えてください。

検証の進め方はAIのPoCから始める、本番運用まで含めた設計はAIを本番業務に載せる、社内文書を根拠付きで参照させる構成はナレッジ・RAG構築の考え方で整理します。参照範囲の絞り込みを実装する際の技術構成はNext.js・Supabaseで業務システムを作る、AIエージェントに作業を任せる場合の権限設計はClaude Coworkとはもあわせて参考にしてください。

よくある質問

Q. 正答率は何％あれば合格ですか？

用途によります。平均値だけで決めず、 許容できない失敗を別の条件として設けてください。 権限外の情報が漏れる、誤った内容を確定事項として断定する、といった失敗は、発生率が数％でも不合格とすべき場面があります。平均の目標値と、ゼロ件を求める失敗の種類を分けて書くのが実務的です。

Q. ハルシネーションをゼロにすることはできますか？

現在の技術では完全にゼロにはなりません。参照する知識を社内資料に絞り、回答できない場合の振る舞いをプロンプトで固定し、人のレビューを残す組み合わせで、業務で許容できる水準まで下げるのが現実解です。「出さない」「人が必ず確認する」を選べる設計にしておくこと が、ゼロを目指すより効果があります。

Q. まだ質問一覧がありません。それでも始められますか？

始められます。現場で繰り返し聞かれる質問と、回答に迷った例を集めるところからで構いません。チャット・メール・電話メモを1〜2週間分さかのぼるだけでも、実務の質問は集まります。質問を集める過程そのものが、AIに任せる範囲を決める作業になります。

自社の状況を整理して相談する

まず、代表質問、期待する根拠、回答できない条件、判定者を書き出してください。この記事に合う検討シートとAI相談用プロンプトで、未確認の項目を残したまま整理できます。シートを完成させる前でも、お気軽にご相談いただけます。