AI実装録 / AI に評価させることの限界
AI に評価させることの限界 — 評価まで任せたら、誰が責任を取るのか
最終更新: 2026年9月2日
AI の出力を評価する作業は手間がかかります。数百件の出力を人が読んで判定するのは現実的でない、という場面は頻繁に生じます。
そこで、評価そのものを別の AI にやらせるという手法が広く使われています。出力と正解例を渡して「この回答は適切か」を判定させる、いわゆる LLM-as-judge です。
本稿では、この手法が有効に働く範囲と、責任の観点から任せてはいけない範囲を論じます。結論を先に書くと、当社は回帰検出の一部には使い、合格判定には使いません。
なぜ評価を自動化したくなるか
合格ラインを誰が決めるか で述べたとおり、業務が判断するには実際の出力を見る必要があります。しかし全件を人が見るのは、多くの場合コストが見合いません。
さらに厄介なのは、評価が一度で終わらないことです。プロンプトを直せば再評価、モデルが更新されれば再評価、参照する文書が変われば再評価。プロンプト管理と回帰 で述べた回帰検証は、この繰り返しを前提としています。
繰り返しのたびに人手を投入するのは現実的でない。だから自動化したくなる。この動機自体は正当です。
AI による評価が機能する条件
経験上、次の条件を満たすときは実用になります。
① 判定基準が明文化できる。 「この回答に、指定した 3 つの項目が含まれているか」のように、判定を機械的な確認に分解できる場合です。逆に「わかりやすいか」「丁寧か」といった判定は、評価する AI 側の解釈に依存し、判定がぶれます。
② 正解が事前に定まっている。 参照すべき文書が決まっており、そこに書いてあることと矛盾していないかを問う形であれば、判定は比較的安定します。
③ 誤判定のコストが低い。 評価の結果が「人が確認すべき候補を絞る」ために使われるのであれば、多少の誤判定は許容できます。
この 3 つ目が本質です。 AI による評価は、それ自体が AI の出力であり、間違います。したがってその誤りが許される用途にしか使えません。
構造的な問題：評価者も間違う
AI に評価させる構成には、避けられない問題が 3 つあります。
同じ弱点を共有する。 評価する側と評価される側が同系統のモデルであれば、苦手な領域も共通します。生成側が誤解する入力は、評価側も同じように誤解する可能性が高い。最も検出したい種類の誤り——もっともらしく間違っている出力——が、最も検出されにくくなります。
もっともらしさに引きずられる。 AI による評価は、内容の正しさよりも、形式の整った出力を高く評価する傾向があります。根拠が薄くても流暢な回答が通り、正しいが素っ気ない回答が落ちる。これは業務上、最も避けたい方向の誤りです。
基準が静かに動く。 モデルが更新されれば、評価の基準も変わります。評価結果の変化が、対象の劣化なのか評価者の変化なのか、区別がつかない。これは回帰検証の土台を崩します。評価側のモデルの版を固定すれば緩和できますが、固定した版はいずれ提供が終了するため、恒久策にはなりません。評価者の交代は、いつか必ず起きる前提で設計する必要があります。
「AI による評価で 95% が合格でした」という報告は、一見すると強力な根拠に見えます。
しかしこの数字は、評価する AI がそう判断したという事実を述べているにすぎません。評価者自身の正しさは、どこでも検証されていない。
この報告を受けた業務部門は、事実上、判断できません。数字を疑う根拠を持たないからです。結果として承認は形式的になり、合格ラインを誰が決めるか で述べた「誰も決めていない」状態が生まれます。
まず、LLM でなくてよい部分を切り離す
AI に評価させる前に確認すべきことがあります。その評価は、本当に LLM でなければできないのか。
前回と出力が変わったかどうかを見るだけなら、機械的な比較で済む場合が少なくありません。構造化された出力であれば項目ごとの一致を見ればよく、形式や禁則語彙の確認は通常のプログラムで判定できます。モデル選定と多層構成 で述べた「最下層にモデルを置かない」は、評価にもそのまま当てはまります。
LLM に判定させる必然性があるのは、表現が違っても意味が同じ、を吸収したい場合に限られます。それ以外に LLM を使うと、費用と再現性の両方で損をするうえ、次に述べる問題まで抱え込むことになります。
当社の使い分け
以上を踏まえ、当社は用途を明確に分けています。
| 用途 | AI に評価させるか | 理由 |
|---|---|---|
| 回帰の検出（前回と挙動が変わっていないか） | 一部に使う | 機械的な比較で拾えない、表現の揺れの判定に限る。誤検知は人が確認すれば済む |
| 人が見るべき候補の絞り込み | 使う | 全件確認の代替ではなく、優先順位づけ |
| 本番投入の合格判定 | 使わない | 責任の所在が消える |
| 顧客への品質報告の根拠 | 使わない | 評価者自身が検証されていない |
線引きの原則は 1 つです。評価の結果が「次に人が何を見るか」を決めるだけなら使ってよい。評価の結果が「人が見なくてよい」という結論を作るなら使ってはいけない。
前者では AI の誤りは手戻りで済みますが、後者では誤りが誰にも気づかれないまま本番に出ます。
責任から見た問題
技術的な精度以前に、責任の構造として整理しておくべき点があります。
AI が評価し、その結果をもって本番投入を決めたとします。事故が起きたとき、誰が判断したことになるのか。
- 評価した AI は責任主体になりません
- 開発側は「評価では合格でした」と言えます
- 業務側は「評価結果を信じた」と言えます
誰も判断していない状態が完成します。これは 監修型の AI 協働 で扱った承認の形骸化と同じ構造で、しかもより見えにくい。承認の記録は残っており、手続きは踏まれているからです。
当社が AI 開発・運用ポリシー 第 4 項で「判断と責任の主体は常に人間にある」と定めているのは、この構造を避けるためです。評価は判断の一部であり、判断を委ねられない以上、評価の最終段も委ねられません。
現実的な組み合わせ
とはいえ、全件を人が見るのは現実的でない。当社が実際に採っている形は次のとおりです。
- 代表サンプル集を人が作る（典型例・例外・過去に失敗した事例を含めて数十件）。ここは人が作らなければ意味がありません
- 日常の回帰検証は、まず機械的な比較で行い、表現の揺れの判定だけ AI に任せる
- AI が「変化あり」と判定した分は人が見る。全件ではなく差分だけなので、現実的な量に収まる
- 「変化なし」と判定された分からも、毎回数件を人が見る。判定結果に関わらず抜き取る
- 本番投入の合格判定は、人が代表サンプル集の実物を見て行う
4 番目を省きたくなりますが、ここが要点です。「変化なし」という判定を信じることは、その範囲で AI の判断に委ねることにほかなりません。評価する AI が回帰を見逃せば、その誤りは誰にも見られないまま通ります。前節で述べた原則——人が見なくてよいという結論を AI に作らせない——を守るには、「変化なし」の側にも人の目を残す必要があります。数件の抜き取りは、評価者自身が壊れていないかを確かめる監視です。
この形であれば、AI は人が見る優先順位を決めるために使われ、人が見なくてよい理由には使われていません。代表サンプル集の設計は プロンプト管理と回帰 で扱っています。
まとめ
AI による評価は、回帰の検出と候補の絞り込みには実用的です。評価者自身が間違うこと、生成側と弱点を共有すること、もっともらしさに引きずられること、基準が静かに動くこと——これらを前提に、誤っても手戻りで済む用途に限定すれば機能します。
一方、合格判定と品質報告の根拠には使えません。理由は精度ではなく責任です。評価を委ねた瞬間に、誰も判断していない状態が完成します。
「AI が評価して合格でした」という報告を受けたときは、評価者は誰が検証したのかを問う価値があります。
本稿の内容は、第三者としてベンダーの評価手法や品質報告を検証する 技術監修 の実務に基づいています。当社の方針は AI 開発・運用ポリシー に定めています。