合格ラインを誰が決めるか — 精度 92% と言われて、業務は判断できない

AI を業務に組み込むとき、必ず「どこまでの品質なら本番に出してよいか」を決める場面が来ます。そして多くの場合、この判断は宙に浮きます。

開発側は「精度 92% です」と報告します。業務側は「それは良いのか悪いのか」が分かりません。判断を求められているのに、判断の材料になっていないからです。

評価と品質 では受け入れ判定を構成する要素を扱いました。本稿はその各論として、合格ラインを業務部門が自分で決められる形にどう翻訳するかを論じます。

「精度 92%」が判断材料にならない理由

3 つあります。

第一に、何を分母にしているか分からない。 全件のうち 92% なのか、AI が回答した分のうち 92% なのか。「分からない場合は回答しない」設計であれば、回答率と正答率は別の数字です。回答率 50%・正答率 92% と、回答率 100%・正答率 92% では、業務への影響がまったく違います。

第二に、残り 8% の中身が分からない。 8% が「惜しい間違い」なのか「まったく的外れ」なのかで、必要な対策が変わります。同じ 8% でも、人が見れば一目で気づく誤りと、正しそうに見えて誤っている出力とでは、危険度が桁違いです。

第三に、そして最も重要なこととして、誤りのコストが種類ごとに違う。 ここを潰さないまま単一の数字で議論すると、必ず判断を誤ります。

誤りを 2 種類に分ける

品質を 1 つの数字で語るのをやめ、誤りの方向で分けます。

たとえば問い合わせに AI が一次回答する仕組みを考えます。誤りには 2 つの方向があります。

「精度 92%」が測っているのは前者だけです。後者は精度の数字にはまったく現れません。

そしてこの 2 つはトレードオフの関係にあります。AI が答える範囲を狭めれば、答えた分の精度は上がりますが、人に回す量が増える。広げれば逆になります。「精度を上げる」という言い方は、後者の存在を隠してしまうために、意思決定の役に立ちません。

そして決定的なのは、2 つのコストがまったく釣り合っていないことです。前者は取り返しがつかない場合がありますが、後者は「遅い」で済みます。だとすれば、合格ラインは「精度」ではなく、どちらの誤りをどこまで許すかとして設定されるべきです。

業務が判断できる形に翻訳する

では、業務部門は何を渡されれば判断できるのか。当社は、次の 3 つに翻訳することを勧めています。

① 件数に直し、2 方向を並べる。 「精度 92%」ではなく、たとえばこう示します。

月 1,000 件の問い合わせを、AI が全件に一次回答する構成の場合。 誤った回答が顧客に届くのが月 80 件程度。 AI が答える範囲を絞って誤回答を月 20 件に減らすと、人が対応する量が月 300 件増える。

「精度 92%」と「月 80 件」は同じ事実です。 それでも、前者を聞いて安心し、後者を聞いて青ざめる、ということが実際に起こります。率は少数の誤りを小さく見せます。

さらに 2 方向を並べることで、はじめて「どちらをどこまで許すか」という問いが業務側に渡ります。「月 80 件の訂正対応を引き受けるか、月 300 件を人が処理するか」なら、業務側は自分の経験と照らして答えられます。精度 92% という一つの数字からは、この問いは出てきません。

なお、件数は分母の取り方で変わります。上の例は AI が全件に答える構成を仮定しています。半分にしか答えない構成なら誤回答は月 40 件で、代わりに人が処理する量が最初から多い。どの構成を前提にした件数かを、必ず添えてください。

② 実物を見せる。 平均ではなく、実際に出た誤りをそのまま並べます。10 件も見れば、業務担当者は「これは困る」「これは問題ない」を即座に判別します。この判別こそが、業務側にしかできない仕事です。

③ 対処の手段とセットにする。 「誤りが出たとき、どう気づき、どう直すか」まで含めて提示します。誤りが避けられないことを前提に、気づける仕組みがあるかどうかで合格ラインは変わります。取り消せる誤りと、取り消せない誤りでは、許容できる水準が違うからです。

この 3 つが揃ってはじめて、業務部門は「責任を取れる」状態になります。逆に言えば、数字だけを渡して承認を求めるのは、責任を業務側に押し付けているだけです。

誰が決めるのか

結論から言えば、合格ラインを決めるのは業務部門であり、開発側ではありません。

理由は、合格ラインが技術的な問題ではないからです。「月 80 件の誤りを許容するか」は、その業務の性質・顧客との関係・訂正にかかる手間によって決まります。これらを知っているのは業務側だけです。

ただし、判断できる材料を作るのは開発側の責任です。ここを混同すると、次のどちらかになります。

• 開発側が勝手に合格ラインを決める（業務側が中身を知らないまま運用が始まる）
• 業務側に数字だけ投げる（判断できないので、承認が形式的になる）

どちらも、事故が起きたときに「誰も決めていなかった」状態になります。

運用開始後に基準は動く

合格ラインは一度決めて終わりではありません。運用が始まると、想定していなかった種類の入力が来ます。

当社が勧めているのは、最初は狭く始めて、実績を見て広げることです。AI が答える範囲を限定して開始し、人に回した分の内容を蓄積する。そのなかに「これは AI でも答えられた」が溜まってきたら、範囲を広げる。この順序であれば、広げる判断の材料が実データとして手元にあります。

逆に広く始めて狭めるのは困難です。すでに顧客に届いてしまった誤りは戻せませんし、範囲を狭めることは「後退」に見えるため、社内の合意が取りにくくなります。

継続的な評価の設計は 評価と品質、想定外の入力への対応は 業務システムへの接続 で扱っています。

まとめ

合格ラインを決めるのは業務部門です。しかし、判断できる形に翻訳するのは開発側の責任です。

そのために、単一の精度ではなく誤りの方向で分け、率ではなく件数に直して 2 方向を並べ、実際の誤りを見せ、対処の手段とセットで提示する。この翻訳を経ていない承認は、形式的なものにしかなりません。

「精度 92% です」と報告して承認を得たとき、本当に判断されたのかどうかを確認する価値があります。

本稿の内容は、第三者としてベンダーの品質報告や受け入れ基準を検証する 技術監修 の実務に基づいています。