AI がつくったものを、どう検証していますか — 答えを隠し、外れを数える

つくれるかどうかは、もう問いではありません。 つくったものが正しいかを、誰がどう確かめるか。それが問いです。

つくる速さは、すでに問題ではありません

最近の AI 導入相談で「これはつくれますか」という質問はほとんど出ません。たいていはつくれます。残る問いは一つです。できあがったものが正しいと、どうしてわかるのか。

この確認作業は自然には起きません。もっともらしいことと正しいことは違い、とくに報告書・分析・判定のように形の決まった成果物は、間違っていても表に出ません。

私たちは最近、この問題に正面から向き合う仕事をしました。長く体系化されてきた知識を AI に移して解釈文を生成する仕事でしたが、完成した瞬間に壁にぶつかりました。よく当たるという感想を百件集めても、それは根拠になりません。人は当たったものだけを覚えているからです。

そのときに立てた検証手順を、そのまま業務に移せる形にまとめました。

一. 答えがすでに出ている事例を選ぶ

検証の出発点は正解をすでに知っている問題です。

企業であれば、結論の出た過去の案件がこれにあたります。昨年に承認・却下が分かれた申請、すでに結果の出た見積り、クレームにつながった注文。結果のわかる事例が十分に積み上がっている領域から手をつけてこそ、検証が成立します。

逆に言えば答え合わせができない仕事は、いま着手する時期ではありません。結果が数年後に出る仕事、人によって判断が分かれる仕事がそれです。

二. 答えを隠したまま解かせる

ここが、多くの現場で抜け落ちる段階です。

事例を渡すときに結論を推測できる手がかりまで一緒に渡してしまうと、当たっても私たちは何もわかりません。当てたのか、知っていたことを書き写したのかを区別できないからです。

そこで私たちは、結論につながりうる情報をすべて消しました。対象が誰か、いつ・どこの出来事かがわかる値を一つも残していません。そして実際に消えたかを機械的に確認しました — AI に入るテキスト全体を手がかりになりうる語で走査し、一つでも見つかれば検証を中止する仕組みにしました。

この確認がないと、ブラインドは宣言にとどまります。実務でも同じです。過去の事例を投入するとき、結果の列だけを消して、結果を匂わせるメモは残したままにするという誤りが非常によく起こります。

三. 判定基準を先に書く

結果を見てから基準をつくると、何でも当たったように見えます。

何をもって「当たった」とし、何をもって「外れた」とするかを、事例を回す前に文章で書いておく必要があります。私たちはここに一つ足しました。当たったと判定した箇所には、その根拠となる記録を必ず添えさせました。根拠を示せなければ判定から外します。

この規則一つで検証の性格が変わります。印象ではなく、数えられるものになります。

結果の読み方 — 数え方が半分です

手順よりも難しいのが結果の解釈です。四つをお勧めします。

一つ、当たりと外れを一緒に数える。私たちの事例では、二件についてそれぞれ 22 か所と 31 か所が記録と一致し、3 か所と 6 か所が外れました。前の数字だけが並ぶ報告書は、検証結果ではなく宣伝物です。社内で AI の成果報告を受けるときに投げる問いも、これです — 何件が間違っていましたか。

二つ、外れを類型に分ける。すべてが同じ失敗ではありません。

• 完全に逆 — 正反対の答えを出した。道具の限界がそのまま見えます。
• 半分だけ正しい — 方向は合っているが結論が違う。根拠はつかんだのに最後の判断で外れた場合が多く、人が一段だけ入るべき場所です。
• 前提が違って当てはまらない — 答え自体は筋が通るが、この事例には該当しない。

三つ、三番目の類型をいちばん注意して見る。ここにその道具が何を既定値として想定しているかが現れます。私たちの事例では、対象が誰かを知らない状態の AI が、特定の国の制度を前提にした答えを出しました。偶然の誤りではなく学習された既定値であり、この既定値は当たった答えの中にも同じように混ざっています。外れた答えが、それを目に見えるようにしてくれたわけです。

業務に移すとこうなります。自社の規程ではなく業界の慣行で答えていないか、改定前の基準で答えていないか — 検証の誤答リストが、その手がかりをくれます。

四つ、当たりももう一段分ける。誰にでも当てはまる言葉とこの事例でしか成り立たない言葉は別ものです。「几帳面だが、ときに急ぐ」のような文はいつでも当たります。検証で点を与えるべきなのは、外れたかもしれないのに当たった答えだけです。

検証がついでに教えてくれること

この仕事では、想定していなかった収穫がありました。検証手順を回す間に既存システムの欠陥がいくつも表に出たのです。

理由は単純です。人がしていた判断を機械に任せるには、これまで暗黙のうちに処理していた例外と境界値を、すべて言葉にしなければならないからです。その過程で、もとからあった誤りも一緒に浮かび上がります。

とくに境界値です。人の目には自然に通り過ぎていた場所が、計算に移した瞬間、結果を分ける線になります。実際に私たちの事例では、入力が わずかにずれていたために結果の一つの軸がまるごと反転しました。検証の前には誰も気づいていませんでした。

AI 導入の最初の成果が新しい自動化ではなく、既存業務の誤りの発見である例は、思いのほか多いのです。

事後照合と予測は別です

最後に、いちばん重要な区別です。

過去の事例で通ったということは、過去の事例に似た仕事で使えるという意味です。先を当てるという意味ではありません。私たちもレポートの中に一文を太字で入れています — これは予測ではなく事後照合です。

検証結果を社内で共有されるときは、この一行を必ず添えてください。これが抜けると、良い検証結果がかえって過信の根拠になります。

まとめると

答えの出ている事例を選び、答えを隠し、基準を先に書き、外れまで数える。そして外れを類型ごとに読む。その道具をどこまで信じてよいかは、そこに書かれています。

つくるのに半日、検証にそれより長くかかったとしても、それは失敗ではなく正しく進んでいるということです。

この記事の事例となったレポートは、Orienteller で同じように確認・検証できます。