業務用AIの選び方：順位表より誤回答と確認費用で比較する

AIを調達する担当者は、公開ベンチマークの順位を見て候補を絞りたくなる。共通の問題を同じ採点で比べられる点は有用だ。しかし顧客からの問い合わせ分類と、契約上の例外条項の抽出では、許せない誤りが違う。順位表の総合点が高くても、発注する仕事で重要な一種類の誤りを繰り返すなら採用理由にならない。

最高得点のモデルが、最も安い失敗をするとは限らない

ここで比べるのは「公開順位の上位を買う」か「自社の失敗例から選ぶ」かである。後者を選ぶとしても、少数の都合のよい例で候補を決めれば、公開評価より悪い判断になる。公開評価は候補を広く知る入口として使い、最終判断には、使う文章、言語、更新頻度、誤りの損失、確認する人の能力を反映させる。

順位表が答えている問いを読む

StanfordのHELMは、モデルを一つの正答率だけでなく、複数の場面と指標で比較し、評価していない場面も明示しようとする研究である。研究者自身、初期版で英語以外や人との対話を十分に扱えないことを述べる。この率直な限界が大切だ。公開順位は「この評価集合ではどうだったか」を示しても、「日本語の社内手順の改定通知を安全に処理できるか」には直接答えない。

ベンチマークが古いなら、モデルや業務の文書が更新された後の性能を保証しない。採点方法が単発の応答だけなら、担当者が修正・再質問する実際の作業時間を表さない。平均点だけなら、重大な少数の失敗を隠す可能性もある。逆に公開評価を完全に捨てて自社の例だけを見ると、評価項目の抜けや特定の担当者の好みに偏る。二種類の証拠が答える範囲を分ける。

NISTのAIリスク管理枠組みは、利用文脈を定め、妥当性・信頼性や運用中の測定について、領域の専門家を交える考え方を示す。これは製品選定の順位ではなく任意の管理枠組みだ。米国の規範を日本で一律の契約義務として書くこともしない。選定側が「何を間違えると損をするか」を先に決めるための枠として使う。

評価する仕事を一件の流れに戻す

例えば契約書の抜粋を作るなら、モデルの文章が自然かだけでなく、原文の該当箇所を示せるか、例外条件を落としていないか、担当者が確認する時間が減るかを測る。営業メールの下書きなら、事実の確認、人手の修正、相手へ送った後の訂正対応まで含める。どちらも「正答率」一語でまとめられない。技術担当だけで評価項目を作らず、結果を使う部署と誤りを修正する部署を入れる。

事前に許容できない誤りを決め、過去の通常例だけでなく、例外、文書の改定、曖昧な指示、扱ってはいけない情報を含む試験を用意する。実際の顧客情報を無断で外部へ入力して試してはならない。権利と機密を守れる加工済みの事例を使い、加工が答えに影響する場合は限界として記す。モデルの設定、入力文、参照文書、採点手順も固定し、候補を同じ条件で比べる。

仮想の二社比較で選択を逆転させる

以下は仮想例であり、製品の実測ではない。候補Aは公開順位が高く、一般的な要約に強い。候補Bは総合点が低いが、社内の契約例外を根拠付きで抽出する試験では確認漏れが少なく、担当者の修正も短い。契約審査支援を目的とし、確認者が結果を必ず見る体制なら、Bを選ぶ理由がある。順位を逆転させるのは、広告の印象ではなく、その業務で重大な失敗を減らせるという観測だ。

条件を変えよう。目的が多言語の一般問い合わせの初期分類で、例外条項の抽出は使わない。Bの試験例が日本語の契約文だけなら、Bを優先する根拠はなくなる。Aを含めて問い合わせで再評価する。さらに、どちらのモデルでも機密情報を扱う契約条件が満たせないなら、性能比較に勝っても導入しない。評価の対象と利用許可を混同しない。

失敗の重さで採点を変える

一つの平均点に、すべての誤りを足し込まない。誤字の修正と、存在しない契約条項を根拠として示すことでは、被害が違う。採点表には、単に正しいかだけでなく、担当者が見逃す可能性、見逃した場合の影響、後から訂正できるかを置く。重みを決めるのはモデル提供者ではなく、責任を負う業務部門である。重みを変えると候補の順位が逆転するなら、その事実を経営判断の資料に残す。

もちろん全てを点数にできるわけではない。重要な一件の失敗は、平均の改善で相殺してよいとは限らない。個人情報を外部へ送る恐れや、根拠のない承認を自動で確定する恐れがある用途なら、製品比較の前に利用条件や人間の承認経路を定める。安全条件を満たさない候補を高得点だからと残すのではなく、その用途から外す。これはAIの能力を否定することではなく、失敗が戻せない仕事を分けることである。

採点の重みを変えるだけでは足りない例を考えます。通常回答90問と権限・送信先の確認10問を採点し、Aが通常90問・重要確認5問に正解、Bが通常84問・重要確認10問に正解なら、合計はAが95点、Bが94点です。それでも重要確認の見逃しを許せない用途では、Bを候補にする、あるいは両方を見送る判断が残ります。これは公開モデルの実測順位ではなく、平均点で失敗を相殺する採点への反例です。

HELMの多面的な評価と業務の採点をつなぐには、重大失敗を点数で相殺してよいかを決める。問題、正解条件、モデル版、設定、実行日時、確認費をそろえず、他者の順位表と自社の試行結果を比べない。実測を公開する場合も、不利な問題を後から除かず、除外条件を先に固定する。

人が確認するなら、確認コストも測る

モデルの選定では、出力速度に確認・修正の時間を加えて比較する。重大な誤りを見つけにくい出力なら、総合点が高くても採用を見送る理由になる。確認者の経験差も試験条件に含めたい。人の承認が実際に誤りを止める設計は、人によるAIレビューで扱う。

評価データは時間とともに古くなる

導入時に用意した文書だけを繰り返し解かせると、社内の様式変更や顧客の新しい質問を拾えない。評価集合には、通常の依頼、例外、新たに発見した失敗を区別して追加する。過去に落ちた例だけで選ぶと、運用で頻繁に出る通常業務の劣化を見逃す。逆に通常例だけで平均点を上げると、少数の危険な誤りが残る。更新のたびに二つの層を比べ、以前の重要な失敗が再発しないかを見る。

モデル提供者が更新を行う場合、名称が同じでも動作が変わることがある。入力の前処理や検索の仕組みを変えた場合も、モデル自体の順位とは別に業務結果が変わる。候補と設定とデータの版を記録し、運用中の評価結果を導入時の結果とつなぐ。契約には、試験に必要な変更予告やログの扱いも確認したい。これらは研究論文の実測値ではなく、判断を再現できるようにする実務上の提案である。

公開された順位は候補を探す費用を下げる。その利点は残しながら、評価されていない日本語の業務や、取り消せない誤りを契約判断の中心に置く。

選んだ後も比較は終わらない

導入前には「公開評価で候補を探す→自社の失敗例で比較する→人を含む作業全体で試す」と進める。導入後は新しい文書や依頼が増えたときの失敗を記録し、同じ試験集合に追加する。誤り率だけでなく、修正時間、見逃した例外、対応を中断した件数を見て、採用時の理由がまだ成立しているかを確かめる。NISTの評価資源も方法を探す入口になるが、それ自体は業務成果を証明しない。

公開順位は候補の探索には使える。契約を決める根拠にするのは、業務で起きる失敗と人手の確認を含めて、同じ条件で比較できた場合である。評価できない重大な場面が残るなら、その用途を限定するか導入を見送る。順位を信じないという態度だけでは足りない。何に失敗すると困るのかを明示し、選定と運用の両方で測る。