「だいたい合っている」を数字に置き換える
検証で作ったAIエージェントを本番へ出すかどうかを決める場面で、判断材料が「触ってみた感じでは問題なさそう」に留まることがあります。この状態では、承認する側は止める理由も進める理由も持てません。数回試して良い結果が出たという印象は、実データの全体で同じ結果になる保証にはならないためです。
判断できる形にするには、次の4つを先に決めます。どれも精度を上げる作業ではなく、精度を測れる状態を作る作業です。
| 決めること | 決まっていないと起きること | 決まった状態 |
|---|---|---|
| 何で測るか | 都合のよい件だけで良い結果が出る | 実データから無作為に抜いた評価用データが手元にある |
| 何を一致とみなすか | 採点する人によって結果が変わる | 項目ごとに、完全一致か許容範囲かが書いてある |
| どこまでの誤りを許すか | 影響の重い誤りが割合に紛れる | 誤りの種類ごとに許容件数が決まっている |
| 満たさないときどうするか | その場の判断で本番へ進む | 対象範囲を狭めるか人の確認を足すかが決めてある |
この4つが揃うと、評価の結果は「本番に出せる／出せない」の答えになります。逆に1つでも欠けると、同じ測定結果を見ても関係者ごとに解釈が割れます。以降では、それぞれをどう決めるかを順に見ていきます。要件定義の段階で書き残す形は AIエージェントの要件定義の書き方 で扱っています。
評価用データを実データから作る
最初に用意するのは、正解が分かっている入力と出力の組です。ここを担当者への依頼で集めると、処理しやすい件が集まります。「代表的なものを何件か出してください」という頼み方をすると、例外や読み取りにくい入力が抜け落ちるためです。
集め方は次の順で進めます。
- 対象業務の実データを期間で区切って取り出す。繁忙期を含む長さにする
- その中から機械的に抜く。並び順の先頭から取らず、無作為に選ぶ
- 抜いた件のうち、例外や処理できない入力がどれだけ混ざっているかを数える
- 業務担当者が正解を作る。値だけでなく、そう判断した根拠も残す
- 作った組をファイルとして保存し、以降の測定で使い回す
3番目で数えた割合には、評価とは別の意味があります。対象範囲の設定が実態と合っているかが分かるためです。例外が想定よりはるかに多ければ、精度を測る前に対象範囲の切り方を見直すことになります。
4番目の根拠は、採点で判断が割れたときに効きます。正解の値だけを残すと、AIの出力が違った理由が読み取りの誤りなのか判断基準の違いなのかを後から区別できません。
5番目を省くと、モデルや指示文を変えるたびに測る対象が変わり、前回との比較ができなくなります。評価用データは固定して残し、追加するときは追加分が分かる形にします。
一致とみなす条件を項目ごとに決める
抽出や分類のように出力が値で返る処理では、項目ごとに扱いを分けます。すべてを完全一致で採点すると、業務上は問題のない表記の違いで不合格が積み上がります。
| 出力の種類 | 一致の判定 | 決めておくこと |
|---|---|---|
| 金額・数量・日付 | 完全一致 | 表記の形式をどちらに揃えるか |
| 名称・住所 | 表記ゆれを許容 | 法人格の有無や全角半角をどう扱うか |
| 分類・区分 | 完全一致 | 判断が分かれる境目の例を先に決めておく |
| 文章の下書き | 含まれるべき要素の有無 | 何が入っていれば要件を満たすかの一覧 |
| 添える根拠 | 参照先が実在し、内容と対応するか | 根拠の付け方の形式 |
文章を生成する処理では、一字一句の一致では測れません。代わりに、その文面に入っていなければならない要素を先に一覧にして、それが含まれるかで採点します。宛先の情報が入っているか、金額の記載が入力と一致しているか、といった形です。要素の一覧は業務担当者が作れます。
根拠を添える処理では、根拠そのものも採点の対象にします。出力の値が合っていても、参照先として示された文書に該当する記述が無い場合があるためです。値と根拠を別々に数えると、どちらの側に手を入れるべきかが分かります。
誤りは種類ごとに数える
全体の正答率を1つの数字にすると、業務への影響が違う誤りが同じ重みで混ざります。日付を1日読み違えるのと、対象外の案件を処理してしまうのとでは、後で起きることが違います。
誤りは次の3つに分けると、多くの業務で足ります。
| 誤りの種類 | 業務で起きること | 許容度の置き方 |
|---|---|---|
| 処理してはいけないものを処理した | 対象外の相手や案件に手が付き、取り消しの連絡が要る | 0件を条件にすることが多い |
| 処理すべきものを取りこぼした | 未処理のまま滞留し、期日に間に合わない | 拾い直す手段があるかで決める |
| 値を間違えた | 後工程の点検や突合で見つかる場合と、そのまま通る場合がある | 見つかる仕組みの有無で分ける |
種類ごとに数えると、合格ラインを業務側の言葉で決められます。全体で何割という問いに業務担当者は答えにくいのですが、「取り違えは1件も出せない」「取りこぼしは月に数件までなら翌日に拾える」という形なら答えが返ってきます。
3つ目の値の誤りは、さらに分けると扱いやすくなります。金額のように後工程の突合で必ず見つかるものと、備考欄の内容のように誰も点検しないまま先へ進むもので、許せる件数が変わるためです。
合格ラインは業務ごとに変わる
同じ正答率でも、本番に出せる業務と出せない業務があります。分けるのは次の3点です。
誤りが後の工程で見つかるか。 承認画面で人が見る、月次で突合する、といった点検が後段にあるなら、そこで止まる誤りは合格ラインを下げても運用が成立します。誰も見ないまま外部へ出る出力は、同じ数字でも扱いが変わります。
誤りを取り消せるか。 社内の管理表への書き込みは直せますが、外部への送信や決済のように後から戻せない処理は、出す前の条件を厳しくします。
件数がどれだけあるか。 割合が同じでも、月10件の業務と月2000件の業務では出てくる誤りの実数が違います。合格ラインは割合ではなく、月あたり何件までなら現場が拾えるかで置くと現実的な線になります。
合格ラインを満たさなかったときの動きを先に決めておくと、測定のたびに議論をやり直さずに済みます。対象範囲を狭めて確実に処理できるものだけを任せるか、人が確認する工程を足して運用するか、いったん見送るかの3つです。どれを選ぶかで必要な体制が変わるため、評価を始める前に候補として並べておきます。
人が確認する工程を残したまま測る
本番の運用で人が最終確認をする作りにする場合、精度は確認前の出力で測ります。確認後の結果は人が直した後の姿なので、AIがどれだけ正しかったかは分かりません。
測るには、確認画面に出す前の出力をそのまま記録に残し、人が確定させた内容と並べて保存します。この2つが揃うと、運用しながら精度を数え続けられます。差分が出た件を種類ごとに集計すれば、評価用データで測ったのと同じ形の数字になります。
このやり方には副次的な効果があります。確認する人が毎回どこを直しているかが分かるため、指示文や判定条件のどこに手を入れるべきかが具体的に見えます。特定の項目だけ修正が集中しているなら、その項目の扱いを直せば済みます。
記録を残すときは、誰がいつ何を直したかも一緒に保存します。後で精度を報告する際に、集計の元をたどれる形にしておくためです。あわせて、確認にかかっている時間も記録すると、削減効果の計算にそのまま使えます。効果を金額へ換算する手順は AI導入の効果測定と効果検証 で扱っています。
本番に出す前に確認する項目
評価の結果が合格ラインを満たしても、それだけでは本番に出せません。精度以外に、次の項目を埋めた状態にします。
| 確認する項目 | 満たしていると言える状態 | 満たしていないときの動き |
|---|---|---|
| 評価用データの出どころ | 実データから無作為に抜き、抜き方を書き残してある | 抜き直す。担当者が選んだ件は使わない |
| 一致の定義 | 項目ごとに完全一致か許容範囲かが決めてある | 業務担当者と1項目ずつ決める |
| 誤りの種類別の許容件数 | 種類ごとに月あたり何件までかが決めてある | 割合ではなく件数で置き直す |
| 処理できなかった件の扱い | 行き先と拾う担当と、滞留に気づく手段がある | 業務側の手順として決める |
| 運用開始後の測り方 | 確認前の出力と確定内容を並べて残す仕組みがある | 記録の置き場所を先に用意する |
| 落ちたときの判断 | 誰が、どの数字を見て、何を止めるかが決めてある | 判断する人を1人まで特定する |
下の3つは測定ではなく運用の準備です。ここが空白のまま本番へ出すと、精度が落ちたことに気づけないまま件数だけが積み上がります。運用条件と決裁の詰め方は 生成AIのPoCが進まない で扱っています。
運用開始後に精度が落ちたときの気づき方
本番に出した後、精度は一定のままではありません。入力の形が変わる、業務の判断基準が変わる、扱う対象が広がる、といった理由で徐々にずれます。落ちたことに気づく仕組みを、出す前に置きます。
見る数字は3つで足ります。
人が直した件の割合。 確認前の出力と確定内容の差分から出ます。この割合が前の週や月より上がっていれば、どこかがずれています。全体だけでなく項目ごとに出すと、原因の見当が付きます。
処理できなかった件の数。 AIが判断を保留した件や、エラーで止まった件です。急に増えたときは、入力の形が変わった可能性があります。
入力の内訳。 差出人や書式、扱う区分の分布です。分布が変われば、評価用データで測ったときの前提から離れています。
この3つを見る担当と頻度を決めておきます。件数の多い業務なら週単位、少なければ月単位で足ります。数字が動いたときに何をするかも先に決めます。評価用データで測り直す、対象範囲を一時的に狭める、人の確認を厚くする、といった選択肢を並べておくと、その場で判断せずに済みます。
評価用データ自体も更新が要ります。業務の変化で扱う入力が変われば、古いデータで測った結果は現状を表しません。新しく出てきた形の入力を評価用データへ追加し、追加した分が分かるようにしておくと、前回との比較を保ったまま更新できます。
まとめ：AIエージェントの精度を判定できる形にする5点
- 測る前に、評価用データ、一致の定義、誤りの種類別の許容度、満たさないときの動きの4つを決める
- 評価用データは実データから無作為に抜く。担当者に選んでもらうと処理しやすい件が集まる
- 全体の正答率ではなく、誤りの種類ごとに数える。業務側は割合より件数で答えられる
- 合格ラインは、誤りが後工程で見つかるか、取り消せるか、月あたり何件出るかで変わる
- 人の確認を残す場合は確認前の出力を記録し、運用開始後も同じ形で精度を数え続ける
Augueでは、評価用データの作り方から合格ラインの設定、運用開始後に精度を見続ける仕組みづくりまでを支援してまいります。本番に出してよいかの判断が付かない段階からでも整理できますので、ご興味がある方は是非ご相談ください。
関連する記事
要件として書き残す形は AIエージェントの要件定義の書き方、本番化の可否と運用条件の詰め方は 生成AIのPoCが進まない、効果を金額へ換算する手順は AI導入の効果測定と効果検証 を参照してください。
よくある質問
評価用のデータは何件くらい用意すればよいですか？
一律の件数は置けません。求める合格ラインが厳しいほど、また誤りの発生が少ないほど、判定に必要な件数は増えます。実務では、種類ごとに許容する件数を先に決め、その件数が観測できるだけの母数を逆算する形にします。許容が「取り違えは0件」なら、0件だったと言い切れる規模まで集める必要があります。
正解データを作る工数はどれくらい見ておくべきですか？
1件あたりの所要時間を実際に数件で測ってから掛け算してください。担当者が普段その業務にかけている時間より長くなるのが普通です。判断の根拠まで書き残すためです。工数が重い場合は、対象項目を絞るか、既に処理済みの過去データを正解として流用できないかを先に検討します。
採点そのものをAIにやらせてもよいですか？
表記ゆれの判定や文面の要点が含まれるかの確認では作業量を減らせますが、採点結果をそのまま合否の根拠にはしないでください。採点側の誤りが評価に混ざります。使う場合は、人が採点した一部と採点結果がどれだけ一致するかを先に確認し、ずれの傾向を把握したうえで補助に留めます。
使うモデルを新しいものへ変えるとき、評価はやり直しですか？
保存してある評価用データをそのまま流し直します。データと採点の定義を固定してあれば、変更の前後を同じ土俵で比べられます。全体の正答率が上がっていても誤りの種類が入れ替わることがあるため、合計ではなく種類ごとの件数で並べて確認してください。処理にかかる時間と1件あたりの費用も同時に測っておくと、切り替えの可否をまとめて判断できます。
外部へ開発を委託する場合、受け入れ基準はどこまで契約に書きますか？
評価用データの出どころと件数、一致とみなす条件、誤りの種類ごとの許容件数、満たさなかったときの扱いまで書きます。ここが曖昧だと、納品物の合否が測定のたびに変わります。あわせて、評価用データと採点結果を自社が受け取れる形にしておくと、運用開始後の比較に使えます。