業務AIの評価設計｜精度と合格基準の作り方
業務にAIを入れたものの「これで本当に使えるのか」を判断できず止まってしまう。私たち日本FDE協会が現場で最もよく見る詰まり方の一つが、このAI 評価設計の欠落です。FDE（Forward Deployed Engineer＝顧客の現場に入り込んで課題を技術で解くエンジニア）は、動くものを作るだけでなく、その出力が業務水準に達しているかを測る仕組みまで用意します。この記事を読めば、自社の業務AIについて何を精度指標として測り、どの水準を合格とするかを自分で設計でき、さらに誰がいつ判定したかを記録として残す着手点までつかめるようになります。導入手順全体ではなく、評価という一点を一緒に深掘りしていきましょう。
AI 評価設計は「何を測るか」から始まる
精度と一言で言っても、業務によって測るべきものはまったく違います。まず押さえたいのは、AIの出力を「正解と照合できるタスク」と「正解が一つに定まらないタスク」に分けることです。ここを混ぜると、評価基準そのものが破綻します。
照合できるタスクの指標
請求書からの項目抽出や、問い合わせのカテゴリ分類のように「正解が定まる」業務では、正答率・適合率・再現率といった指標が使えます。たとえばバックオフィスの書類処理では、抽出した金額や日付が原本と一致するかを照合できるため、フィールド単位の正答率が主指標になります。ここで大事なのは、全体の正答率だけを見ないことです。金額欄だけ間違えると業務影響が大きい、といった項目ごとの重み付けを評価に持ち込む必要があります。
正解が定まらないタスクの指標
カスタマーサポートの応答生成や要約のように出力が一つに定まらない業務では、正答率という発想が合いません。この場合は、事実に反する内容を含んでいないか（正確性）、質問に答えているか（適切性）、社内規定に反する表現がないか（安全性）といった観点を分解し、それぞれを人が採点する評価票を作ります。SaaS企業の問い合わせ対応でこの設計をしたとき、最初は「良い/悪い」の二択で採点していましたが、判定者ごとにばらつきが大きく機能しませんでした。観点を分けて各3段階にした途端、採点が安定しました。
合格基準は業務リスクから逆算する
一般的な評価解説は、指標の計算方法までで止まりがちです。しかし現場で本当に難しいのは「何%なら合格にするか」です。私たちは、この線を精度スコア単独では決めません。間違えたときに何が起きるかから逆算します。
誤りの影響で線引きを変える
同じ90%の正答率でも、社内メモの下書き生成と、顧客に送る金額の記載では意味がまったく違います。前者は多少の誤りを人が直せばよく、後者は一件の誤りが信頼を損ないます。そこで、誤りを「人が容易に気づけるか」「気づかず流れたときの損害はどれくらいか」の2軸で分類し、損害が大きく気づきにくい誤りが多いタスクほど合格ラインを引き上げます。数値そのものは業務ごとに異なるため、正答率何%が正解という一律の目安はありません。
要件を評価基準の言葉に翻訳する
ここがFDEの腕の見せどころです。現場のヒアリングで得た業務要件は、そのままでは評価に使えません。「請求書処理を楽にしたい」という要望を、「金額・日付・取引先名の3項目を原本一致で判定し、金額の誤りはゼロを目標、日付は月次で1件以内」といった測れる基準に落とします。前川会長が製造業のクライアントで入出荷管理の帳票処理を支援したときも、最初にやったのは「どの項目が間違うと出荷が止まるか」を現場担当者と洗い出す作業でした。止まる項目を最優先の評価対象に据えることで、合格基準に説得力が生まれます。要件を基準へ変換するこの一手間を飛ばすと、精度は高いのに現場が使わないAIになりがちです。
評価は「残し方」まで含めて設計する
評価は一度やって終わりではありません。誰がいつどの基準で合格を判断したのかを記録に残し、運用の中で回し続けられるようにして初めて、統制や監査に耐える状態になります。ここは市場のAI評価解説がほとんど触れない領域であり、法人の現場で最も重視される点でもあります。
判定を職務分掌の中に置く
評価で見落とされやすいのが「誰が合格を決めるのか」です。AIを作った本人が自分で合格を出すと、客観性が担保されません。開発担当と、業務の責任者による判定を分けておくと、承認の流れがそのまま統制の形になります。誰が判定し、誰が承認したかを残す。この分掌の考え方は、AIかどうかに関わらず内部統制の基本ですが、AIの評価にも同じ発想が有効です。
評価記録を証跡として残す
残すべきは、評価に使ったデータ（テストケース）、そのときの出力、採点結果、判定日、判定者です。これをバージョンとともに保管しておくと、後から「この時点でなぜ合格としたか」を説明できます。AIやプロンプトを更新したら再評価し、前回との差分がわかる形で記録を積み上げます。前川会長が金融機関でシステムを扱っていた頃から、判断理由まで文書に残すことは運用を止めないための基本でした。AI評価でも、この証跡があるかどうかで、担当者が代わったときの引き継ぎやすさがまるで違ってきます。なお、ここで述べているのは一般的な内部統制の考え方であり、特定の法規制への適合を約束するものではありません。
設計ステップ | 決めること | 残す記録 |
|---|---|---|
指標の選定 | 照合型か生成型か／観点の分解 | 評価票・観点定義 |
合格基準 | 誤りの影響から逆算した水準 | 基準の設定理由 |
判定 | 誰が採点・承認するか | 判定者・判定日・結果 |
継続 | 更新時の再評価ルール | バージョンと差分 |
評価設計は要件定義や業務改善の進め方と地続きです。要件をどう引き出すかはFDE要件定義で失敗しない実践テクニック、AI業務改善の全体像はAI業務改善の進め方｜FDE実践者が教える手順、RAG特有の詰まりはRAG 構築で業務が詰まる箇所と設計の勘所が参考になります。必要スキルの地図はFDEに必要なスキルの全体像｜8領域で解説をご覧ください。
よくあるご質問
Q. AI 評価設計は精度スコアを測るだけでは不十分ですか。
精度スコアの計測は出発点にすぎません。何%を合格とするかを業務リスクから決め、誰がいつ判定したかを記録として残し、更新のたびに再評価する仕組みまで整えて、はじめて運用に耐える評価になります。スコアの計算だけで止めると、精度は高いのに現場で使われないAIになりがちです。
Q. 合格ラインの正答率は何%を目安にすればよいですか。
一律の目安はありません。同じ正答率でも、誤りに人が気づけるか、気づかず流れたときの損害がどれくらいかで意味が変わるためです。誤りの影響が大きく気づきにくい業務ほど基準を引き上げる、という逆算の考え方で、業務ごとに個別に決めることをお勧めします。
Q. 評価を作った本人が合格判定してもよいですか。
客観性の観点からは分けることをお勧めします。開発担当と業務責任者で採点と承認の役割を分けておくと、承認の流れがそのまま統制の形になり、後から判断理由も説明しやすくなります。判定者・判定日・結果を記録に残しておくと引き継ぎもスムーズです。
自社の業務AIの評価設計、一緒に組み立てませんか
日本FDE協会
FDE（Forward Deployed Engineer）の認知拡大・人材育成・コミュニティ形成を目的とした協会です。技術とビジネスの双方を現場で実践するエンジニアを支援しています。