AIの実力は、世間のランキングではなく自社の「十問」でしか測れません

「最新のAIランキングで一位が入れ替わった」という記事を見るたびに、乗り換えを検討していないでしょうか。その検討時間の大半は無駄になります。世間のベンチマークが測っているのは「世界の誰かの平均的な仕事」での成績であり、自社の見積作成や仕訳の分類での成績ではないからです。必要なのは、自社の実際の仕事から作った十問の腕試しです。新しいモデルが出るたび、この十問を解かせて採点します。それだけで、順位表を眺めるより確かな判断ができます。本稿では、この十問の作り方、採点の仕方、回すタイミングを具体的に示します。

ソフトウェア開発は「受け入れテスト」で答えを出してきました

システム開発の世界には、受け入れテストと呼ばれる確立した工程があります。英語では User Acceptance Testing、略してUATです。開発会社の内部テストが終わった後、発注した側・実際に使う側が、自分たちの業務シナリオに沿ってシステムを動かし、合格か不合格かを判定します。開発側の「動きます」という言葉を信じて検収するのではなく、自分の仕事で確かめてから受け取る、というのが数十年かけて定着した工学の慣行です。判定の主導権を発注側が握る、という点が肝心です。

AIの選定にも、同じ発想がそのまま使えます。ベンダーの宣伝文句や世間のランキングは、いわば開発側の「動きます」に相当します。受け取る前に、自分の業務シナリオで試験をするのです。ただし一点だけ違いがあります。従来のシステムは同じ入力に同じ出力を返しますが、AIの出力は毎回揺れます。だからこそ一問勝負ではなく、複数の問題を束ねた評価セットが要るのです。

十問はこう作ります——実案件五問、失敗三問、例外二問

配分の目安を示します。まず、日常の実案件から五問。直近の仕事から入力をそのまま切り出します。見積依頼のメールから明細を起こす、契約書の草案から支払条件を抜き出す、応募者の経歴書を求人要件と突き合わせる、といった具合です。選ぶ基準は「先月もあったし、来月も必ず発生する仕事か」という問いです。社名や個人名は伏せ字にしますが、文章の崩れや情報の欠けは直さないでください。きれいに整えた瞬間、それは「他人の試験」に戻ってしまいます。

次に、過去の失敗例から三問。人でもAIでも、実際に間違いが起きた事例を選びます。単位を取り違えた見積、科目を誤った仕訳、与信の注意信号を見落とした受注などです。ここでの問いは「これを間違えたら、実務で損害が出るか」。出るなら採用します。

最後に、例外的な難問を二問。「担当者が上司に相談するレベルのケースか」を基準に、月に一度あるかどうかの厄介な案件を入れます。複数の契約条件が絡む請求や、前例のない値引き依頼などです。この枠は満点を期待する場所ではなく、モデルの世代が進んだときに差が現れる観測地点です。

合否は「正解を先に書いておく」ことで決まります

受け入れテストが機能するのは、合格基準を実行前に文書化しておくからです。AIの評価も同じで、解かせる前に、各問の模範解答と「ここを外したら不合格」という急所を書いておきます。金額、期日、契約の当事者名など、間違えたら実害が出る点を急所に据えてください。

順序を逆にしてはいけません。出力を見てから採点基準を考えると、もっともらしい文章に引きずられて甘い点をつけてしまいます。部分点も付けず、急所を外したら不合格という二択で数えます。十問中何問合格したかだけを記録すれば、採点者による揺れも抑えられます。出力の揺れへの対策としては、同じ問題を二回ずつ解かせ、二回とも合格したときだけ合格と数える方法が有効です。なお、案内文の作成のように正解が一つに定まらない仕事では、模範解答の代わりに「必ず含める要素」と「書いてはいけない内容」を三つずつ挙げておけば、同じ方式で採点できます。

なお、この合格数を部署の業績指標にしてはいけません。指標にした瞬間、十問への最適化が始まり、ものさし自体が歪みます。指標の歪みは別稿の主題なので、ここでは「選定と更新の判定にだけ使う」と決めておけば十分です。

回すタイミングは三つあります

タイミングは三つです。モデルの大型更新が発表されたとき、ツールの乗り換えや新規契約を検討するとき、そして何もなくても四半期に一度の定点観測です。十問なら一巡は一時間もかかりません。この軽さこそが継続の条件になります。

結果は日付とモデル名を添えて一枚の表に残してください。「昨年は三問だった例外枠が、今回は五問合格した」という履歴は、どの業務をいつAIに任せ始めるかという投資判断の根拠になります。導入の現場で繰り返し見てきたのは、モデルの世代交代のたびに選定の議論が振り出しに戻る光景です。自前のものさしがない組織は、毎回ゼロから世間の評判を集め直すことになります。評価セット自体も年に一度は棚卸しし、なくなった業務の問題は現役の業務のものに入れ替えてください。

「十問では少なすぎる」という反論に答えます

統計の目で見れば、十問は確かに少数です。しかし目的は学術的な性能測定ではなく、自社で使うか否かの判定です。比べるべき相手は千問の精密な試験ではなく、現状の「ゼロ問」、つまり評判と印象だけの選定です。十問で明確な差が出ないなら現行のままでよい、という判断が下せる時点で、ものさしとして十分に働いています。実際、AIを開発する側の世界でも、公開ベンチマークとは別に用途ごとの評価セットを自前で作ることが、標準的な実務になりつつあります。

「作る手間が惜しい」という反論にも触れておきます。十問の材料は過去の実案件と失敗例なので、新しく書き起こす文書はほとんどありません。集めて、正解を添えるだけです。最初の三問なら三十分で形になります。

まず三十分でできること

業務を最もよく知る担当者を一人決め、次の三歩を今週中に済ませてもらってください。第一歩、直近一か月のメールとファイルから「AIに任せたい仕事」の実例を三件コピーし、固有名詞を伏せ字にして一つのフォルダに入れます（十分）。第二歩、各件について模範解答と急所を一枚のメモに書きます（十五分）。第三歩、いま使っているAIにその三問を解かせ、日付・モデル名・合否を同じメモに記録します（五分）。残りの七問は、来週以降に失敗例と例外を一件ずつ足していけば揃います。

次にランキングの記事を開きたくなったら、代わりにこのフォルダを開いてください。順位を追うのをやめ、十問を揃え、モデルが替わるたびに回し、履歴で乗り換えを決めます。AI選定の主導権は、その手順を持った会社の側に移ります。