何が起きたか：社内レビューを通った説明が、答え合わせで崩れた
Mishra氏は、データ移行時のドリフト（想定と異なるデータの変化）を検知し、その原因候補をランク付きで説明するツールを開発しました。最初のプロトタイプは流暢で具体的に聞こえる説明を出し、定性レビューは問題なく通過します。ところが、原因がすでに判明しているケースに当てて答え合わせをすると、無視できない頻度で誤った根本原因を指していました。
なぜ重要か：定性レビューは「流暢さ」しか測っていない
一般的な評価は、出力をサンプリングし、ドメイン知識のある人が「良い回答の頭の中のイメージ」と照らして判定し、外れが多ければプロンプトを直す、という流れです。これで捕まるのは、明らかな誤り・崩れた書式・的外れな話題まで。捕まらないのは、外部の正解と突き合わせない限り見抜けない誤りです。権威的な語り口で、自信たっぷりに違う原因を名指しする説明——これがレビューをすり抜けます。
点をつなぐとこうなります。レビュアーの基準は直感なので、直感を裏切らない誤答に対しては構造的に無力です。Mishra氏の表現では「精度が価値の源泉であるシステムにおいて、『もっともらしい』は『正しい』と同じではない」。そして賭け金は上がっています。アナリストが品質問題をどう調べるか、コンプライアンス担当がフラグ付きレコードをエスカレーションするか、運用チームが検証失敗をどう切り分けるか——LLMは生産性の付属品から、業務判断に影響する部品へ移りつつあります。
評価ハーネスの3要素
1. 合成グラウンドトゥルース：テストパイプラインに原因を意図的に仕込みます（スキーマ変更、変換ロジックのバグ、ソースシステムの挙動変化）。仕込んだ内容を記録し、発生したドリフトイベントをモデルに投げる。仕込んだものがそのケースの正解です。
2. スコアリング関数：ランク付き出力に二値の正誤判定は足りません。正解が候補に現れたか（presence）と、誤答候補に対してどれだけ上位に置かれたか（rank）の2軸を重み付けして合成します。
3. 全件の系統的評価：スポットチェックではなくデータセット全体に適用し、安定して解けるカテゴリ、一貫して外すカテゴリ、そして「自信のある誤答」を最も多く生む信号の組み合わせを可視化します。
なお初期の合成シナリオは「きれい過ぎ」て、本番よりドリフトの兆候が明白でした。ノイズ、重なり合う信号、複数のもっともらしい原因が同時に存在するケースを足して初めて、実環境の性能を予測できるようになったとしています。
結果：得意・苦手のマップと、確信度の崩壊
- スキーマ変更：証拠が存在し特徴的であれば、上流のスキーマ変更を安定して特定。
- 変換ロジックのバグ：大まかなカテゴリは当てるが、どの変更が原因かの特定を外す。特に複数の変更が時間的に近接している場合。
- 信号の重なり：異なる2つの原因が近い時期に起きたケースが最難関で、確信を伴う誤答の発生率が最も高い。
最大の発見は、モデルが表明する確信度が精度とまったく相関しなかったことです。むしろ最も間違っているケースで最も自信を示していた。グラウンドトゥルースで測らなければ永久に見えないパターンでした。
そしてMishra氏が「最も投資すべき難所」と呼ぶのは、ハーネスの実装ではなく合成グラウンドトゥルースの構築です。理由は工数ではありません。自分たちのユースケースにおける「正しい」が何かを、精密に定義せざるを得なくなるからです。定義さえ決まれば、スコアリング関数もハーネス基盤も比較的素直に作れます。
💼 事業会社視点：これは自社にどう効くか
日本企業でいま増えているのは、AIを「議事録要約」から「業務判断の入力」へ移す動きです。ECの返品不正スコアリング、SaaSのチャーン要因分析、受託開発の障害一次切り分け——いずれも出力が人の判断を動かします。この記事の含意は明快で、そこに定性レビューしか置いていない組織は、リリース可否を「読んで違和感がないか」で決めている、ということです。
役員が明日聞くべき質問は一つ。「正解が分かっているケースで精度を測ったか、それとも出力が妥当そうかを見ただけか」。後者なら、そのツールは流暢さの検査しか通過していません。
打ち手は具体的です。第一に、過去のインシデント記録や既知の不具合から「正解ラベル付きケース」を数十件でいいので作る。素材はJira、障害報告書、監査ログにすでにあります。第二に、Top-N型・ランク付きの出力なら、正解の出現有無と順位の2軸で採点する。第三に、モデルの確信度をUIに出しているなら外すか、運用者に「確信度は精度の指標ではない」と明示する。受託開発・SIerには逆にチャンスで、「正解データセットと評価ハーネスの構築」はPoCの次に売れる、成果が数字で示せる工程になります。