LLMOツールの自動判定は正しい？適合率・再現率を人手で検証する評価シート

LLMOツールの自動判定を検証するときは、保存された回答を人が読み、同じ定義で付けた参照判定と照合します。「言及あり」と判定された回答の正しさを確かめる適合率と、本当に言及がある回答を拾えた割合である再現率を分けることが基本です。全体の一致率だけでは、見逃しが多いのか、別ブランドを誤って拾っているのかを判断できません。

この確認は、ツールを疑うためだけの作業ではありません。自動集計をそのまま月次報告に使う範囲と、人の確認を挟む範囲を決めるための業務設計です。本記事では、ブランド言及の有無を例に、評価対象の選定、判定表、架空の計算例、改善後の再検証までを説明します。記載する数値は説明用の架空データであり、特定サービスの性能を示すものではありません。

自動判定の精度と、AIに言及される確率は別の数字

「AI回答の20%に自社が出た」という値は、回答内容を集計した露出の指標です。一方で「言及ありと判定した回答のうち何%が正しかったか」は、集計に使う判定処理の品質を表します。自動判定が正確でも自社への言及が少ない場合はありますし、自社が多く言及されてもブランド名の取り違えが含まれる場合はあります。

まず評価単位を「一つの回答における対象ブランドの言及有無」に固定します。同じ回答にブランド名が三回出ても、この評価では一件です。引用URLの抽出、推薦の有無、回答内の登場順位は別の判定課題として扱います。複数の処理を一つの合否にまとめると、どの処理を直すべきか分からなくなります。

例えば、回答本文にはブランド名がなく、出典リンクのタイトルにだけ名前がある場合を考えます。本文言及を測るなら「なし」、リンク先まで含めた存在確認なら「あり」になり得ます。どちらかを一律に正解とする前に、ツールの表示定義と報告したい内容を揃えてください。定義の不一致と、処理の誤りは別々に記録します。

先に作る判定基準と評価シート

人が付ける参照判定も、担当者の直感だけでは安定しません。正規名称、認める略称、会社と製品の区別、一般名詞と同名の扱いを短い基準書にまとめます。略称は何でも許可するのではなく、本文の文脈から対象を特定できる条件を添えます。回答を後から書き換えず、観測時の原文を参照することも基準に含めます。

回答に含まれる顧客名や非公開の質問文を外部共有する必要はありません。社内確認用の原文と、共有する集計表を分け、必要な担当者だけが原文を参照できる運用にします。匿名化した表でも回答IDの対応は維持し、説明を求められたときに根拠へ戻れるようにしてください。

適合率・再現率を60件の架空例で計算する

評価指標の定義は、Googleの機械学習講座の解説でも確認できます。適合率は自動的に「あり」とした件数のうち参照判定も「あり」の割合、再現率は参照判定が「あり」の件数のうち自動判定が拾えた割合です。ここでは人手で合意した参照判定を基準として、独自の架空例に当てはめます。

適合率は18÷24＝75%です。「あり」と出た四件のうち一件が、この標本では参照判定と合いませんでした。再現率は18÷21＝約85.7%です。参照判定で見つかった21件の言及のうち、三件を拾えていません。一致率は（18＋33）÷60＝85%になります。

この三つの値は評価した60件の結果です。そのまま全エンジン・全期間の性能と表現してはいけません。評価時の質問群、選び方、対象期間、判定対象を添えて初めて意味が伝わります。少数の標本では一件の差で値が動くため、小数点以下を細かく出すより分子と分母を併記する方が実務上は有用です。

分母がゼロの場合は、0%や100%を自動で入れず「算出対象なし」とします。例えば自動判定が全件「なし」であれば、その標本の適合率は計算できません。見逃しがあるかは参照判定側で確かめます。空欄の意味を統一しておくと、担当者が集計表を引き継いだ際の誤読も減らせます。

標本の選び方で結論が変わる

自動判定で「あり」となった回答だけを読むと、検出した内容の正しさは確認できます。しかし「なし」の中に言及が隠れていないか分からないため、その調査だけで再現率を出すことはできません。「あり」と「なし」の双方を評価対象に含める必要があります。

全体の傾向を把握する評価では、対象期間の取得済み回答から無作為に選ぶ方法を基本にします。エンジンごとの件数が大きく異なる場合は、全体の構成を保つ標本と、各エンジンを詳しく見る標本を分けると分かりやすくなります。各群を同数選んだ結果を単純に合算すると、実際の運用比率と異なる数値になります。

一方、表記揺れや長い比較文を意図的に集める調査は、弱点を探すために役立ちます。ただし難しい事例を増やした標本の率を、通常運用の性能として示すことはできません。「日常の回答を代表する確認」と「失敗しやすい事例を探す確認」に名前を付け、台帳も集計も分けてください。

同一質問の連続実行だけで標本を埋めないことも大切です。似た回答ばかりになると、質問の種類が違う場面での誤りを見落とします。質問の分類や版を残す方法は、プロンプトの版管理の記事と組み合わせて運用できます。

自動判定を検証する5ステップ

図：基準を決める、標本を選ぶ、人手で判定、誤りを数える、再検証するの5ステップ。本文でも同じ手順を説明。

1. 基準を決める

本文における対象ブランドの言及有無など、検証する判定を一つ選びます。正規名称、略称、本文と出典の範囲、保留条件を基準書に書き、版番号と適用日を付けます。最初に数件を担当者同士で読み、定義のずれを整理します。

「候補として推奨されている」まで求める場合は、名前が出ただけの言及とは別の項目にします。「おすすめしない」という回答も名前の言及自体はあり得るため、推薦と混同しない設計が必要です。評価を始めてから都合に合わせて基準を変更せず、変更した場合は影響範囲を記録します。

2. 標本を選ぶ

期間、質問群、エンジン、取得経路を決め、あり・なしの両方を含む回答一覧を固定します。通常運用の標本と難しい事例の標本を分け、選定方法と対象件数を保存します。取得できなかった回答は別の件数として残します。

回答のダウンロードや参照権限に制約がある場合は、使える範囲を先に確認します。原文を確認できないレコードを、判定が正しかったことにして集計してはいけません。少量の試行から必要な確認時間を見積もり、継続できる範囲で標本を増やします。

3. 人手で判定

可能な範囲で自動判定を伏せ、担当者が原文から参照判定と根拠箇所を記録します。判断が割れる回答は別の担当者と確認し、合意した理由を残します。根拠が不足する回答は保留にし、保留件数を報告します。

人の判定も誤るため、「人手だから必ず正しい」という扱いは避けます。意見が割れた理由が基準の曖昧さなら基準を直し、同じ条件の回答を見直します。多忙で一人しか担当できないときは、少なくとも不一致例と保留例を後日再確認し、その制約を報告に添えます。

4. 誤りを数える

参照判定が確定した回答について、正しく検出、誤検知、見逃し、正しく非検出の四つに分類します。適合率と再現率を分子・分母付きで計算し、取得不能と保留を除いた件数を明記します。誤りの理由も同時に集計します。

例えば65件を選び、二件が取得不能、三件が保留、残り60件が評価対象だったなら、最初の65件からの流れを残します。保留を除いた結果だけが高く見える可能性もあるため、率の改善と一緒に保留件数の変化も確かめてください。

5. 再検証する

誤検知や見逃しの原因に応じて、名称辞書や判定基準の修正を検討します。修正に使った回答とは別に確保した回答で再評価し、変更前後の基準版、判定版、対象条件を残します。修正により別の誤りが増えていないかも確認します。

失敗した回答だけで再試験すると、その事例に合わせた改善しか確認できません。既知の不一致例を回帰確認用に残し、未使用の回答を評価用に分ける方法が実務的です。判定処理を提供側が更新する場合は、更新内容と適用時点を確認してから過去の数値と比較します。

誤検知と見逃しを、業務上の影響へ結び付ける

一律に「80%以上なら合格」と決めるだけでは、利用目的との関係が見えません。対外的な成果報告へ自動集計を載せるなら、誤検知によって実績が過大に見える影響を重く扱います。調査候補を広く拾い、後で人が読む用途なら、見逃しを減らす設計が役立つ場合があります。

修正方法は、利用者が設定できる範囲に限られることもあります。その場合は不一致の原文、期待する判定、基準版を揃えて提供側に確認し、修正前の暫定対応を決めます。重要な報告対象だけ人が確認する方法でも、対象を明確にすれば運用できます。

導入前に提供側へ確認したい項目

LLMOツールを選ぶ際は、単に「精度が高いか」ではなく、何をどう検証できるかを確認します。回答原文へ戻れるか、言及と引用が区別されるか、判定の変更履歴を把握できるかは、実際の報告業務に直結します。比較の全体像はLLMOツールの比較記事も参考になります。

LLMOチェキの公式サイトでは、AI回答や言及、引用元を確認する機能を案内しています。導入を検討するときは、自社の質問とブランド表記で原文を確認し、必要な判定を追跡できるかを確かめてください。本記事の架空の評価値は、LLMOチェキの実測性能ではありません。

報告書には率だけでなく、使える範囲を書く

報告の一文は「対象期間の回答から選んだ60件で、本文言及の適合率18/24、再現率18/21を確認。保留三件と取得不能二件は別管理」といった形にします。対象と除外を短く添えることで、集計値を読む人が過度に一般化するのを防げます。

次に、確認が必要な用途を決めます。例えば月次の対外報告に載せる言及例は原文確認を通し、社内の探索用一覧は自動判定を使う、といった使い分けです。誤りが多かった質問群やエンジンだけを次回の重点確認にし、全件確認を漫然と増やさないようにします。

評価は一度で終わりません。ブランド名称、質問群、取得経路、判定処理が変わったときは、前回の結果がそのまま当てはまるか見直します。数値の良し悪しを競うより、どの条件なら安心して判断に使えるかを共有することが、LLMOツールを継続して使うための土台になります。

評価担当者の引き継ぎで迷いを減らす

基準書には、典型的な正例と負例だけでなく、判断が割れた境界事例を載せます。例えば「製品名と会社名が同じ」「略称が一般名詞にも使われる」「引用先のタイトルだけに名称がある」といった例です。それぞれに採用した判定と理由を一行添えると、担当者が交代したときも同じ論点を確認できます。

初回は、全員が別々に同じ少量の回答を判定してから、結果を合わせます。先に正解例を見ながら作業すると、基準が理解できているのか、答えを写しているのか区別しにくくなります。不一致を責任追及に使わず、定義を具体化する材料として扱うことが継続の条件です。

評価作業の時間も台帳に残します。一回答あたりの確認時間が長い場合、原文の表示位置や根拠箇所の記録方法を改善できるかもしれません。自動判定の率だけが改善しても、例外確認に毎月長い時間がかかるなら、運用上の負担は解決していません。判定品質と確認工数を一緒に見てください。

変更の優先順位は件数だけでは決めません。少数でも顧客向け報告を誤らせる不一致なら先に対応し、頻繁でも社内の探索で簡単に除けるものは後回しにする判断ができます。どの不一致を残したまま使うかについて、責任者と合意し、例外確認が必要な範囲を明文化します。

担当者への依頼文には「何件を見るか」に加え、「何を見ないか」ではなく評価対象を具体的に書きます。本文言及だけを確認する回で、担当者ごとに推薦の強さまで採点すると基準が変わってしまいます。別の気付きは備考へ残し、正式な評価項目へ加える場合は次の版で揃えます。