AIベンチマークが実務の9割を測れていない理由

知人の一人は中堅物流企業でオペレーションを担当しているのですが、昨春、彼女のチームは3週間かけて、LLMに例外処理ワークフローを任せられるかを評価しました。対象は、互いに仲の悪い3つのシステムをまたいで、発注書と一致しない請求書を突き合わせるという地味で骨の折れる作業です。ベンダーのスライドには印象的な数字が並んでいました。MMLU、GSM8K、HumanEval、そしてエージェント系ベンチマークのいくつか。モデルは用意されたテストをすべて高得点で通過しました。ところが実際の1週間分の例外データを食わせると、ベンダーが社名を略して書いていたせいで、14,000ドルの請求書を別の発注書に自信満々で紐づけてしまったのです。こうした失敗は、どのリーダーボードでも測定されていません。

このギャップは、いまや数値で示せるようになりました。公開されているAIベンチマークを、米国労働省のO*NETの職業分類（アメリカの仕事を構成する923職種と18,797のタスク）と照合した最近の調査では、米国の労働時間の90%が、ベンチマークのカバーがほとんどないかまったくないタスクに費やされていることがわかりました。923職種のうち、5件以上のベンチマーク・プロンプトに裏付けられたタスクを1つでも持つ職種は208にすぎません。22の職種ファミリーのうち6つは、まったくカバーされていません。居心地の悪い結論は、AIの能力が低いということではありません。AIの能力を測る物差しが、経済のごく一部にしか向いていないということです。

AIベンチマークが実際にカバーしている範囲

この調査の方法論は、見出しから受ける印象よりも慎重なので、理解しておく価値があります。研究者たちは、未飽和で質の高いエージェント系ベンチマーク29種を選びました。これらは質問に答えるだけでなく、モデルが実際に作業を遂行しなければならないテストです。そのうえで、人間の専門家と照合検証したLLMジャッジを使い、各ベンチマーク・プロンプトがどのO*NETタスクを検証しているかにタグを付けました。タスクは、少なくとも5件のプロンプトが対応づけられた場合に「カバー済み」とみなされます。それぞれのタスクに費やされる労働時間の推定値と組み合わせると、評価スイートが何を見られているのかを経済全体で俯瞰できます。

見えているものは、広くはなく、細く偏っています。ソフトウェア工学と金融分析はベンチマークで飽和しています。一方、トラック運転、ガス発電所の運転、飲食サービス、そして医療現場の日常業務の大半は、事実上見えていません。しかも偏りは、技術的に自動化可能かどうかだけで決まるわけではありません。「AI曝露度が高い」とタグ付けされたタスクは、そうでないタスクに比べて約6倍ベンチマーク化されやすい。これは納得できます。ただ、その影響を統制しても、職種全体の給与総額が大きい職種のタスクは、依然として有意に過剰に代表されています。弁護士のタスクは手厚くカバーされています。一方で、同程度のAI曝露を受けている法務秘書や裁判所書記官は、ほとんど登場しません。

もう一度考えてみてください。私たちは、多くの人が実際に就いている仕事の現実の姿を無視して、名声の高い方の仕事を基準にAIを測っているのです。中間所得層の知識労働の長い裾野、つまりコーディネーター、事務員、専門職、スケジューラーといった人々の労働時間の合計は、経済の中で非常に大きな割合を占めています。それなのに、その領域の測定基盤はほぼ存在しません。誰かが「AIは知識労働のX%をこなせる」と主張するとき、どの知識労働なのか、どう測ったのか、どのタスクリストに照らしたのかを問い返すべきです。正直な答えはたいてい、研究論文向けに設計されたテストで測られた、薄くて代表性に欠けるごく一部、というものです。

ベンチマークの飽和は評価設計の失敗である

私は何年も評価パイプラインを作ってきましたが、そこで得た最も厳しい教訓はこれです。ベンチマークは世界のモデルであり、そのほとんどは出来が悪いモデルです。雑然として文脈依存で、複数ステップにわたる人間の作業を、採点しやすい明確なプロンプトと検証可能な答えに圧縮してしまいます。採点が安くつくからです。そこへグッドハートの法則が効いてきます。ベンチマークが開発の目標になった瞬間、それが本来プロキシとして測るはずだった能力を測らなくなるのです。学習データにテストの分布が染み込み、チームはリーダーボード向けに調整し、スコアは上がるのに、実世界での性能はむしろ横ばい、あるいは悪化していきます。

飽和は目に見える症状にすぎません。主要なフロンティアモデルがすべて90%を超えるスコアを出すようになると、そのテストは識別力を失っています。しかし、より深刻な問題は、私たちが同じスタイルで、同じ種類のタスクを対象とした別のベンチマークを作って対応してしまうことです。自動採点の方法がわかっているのが、そうしたタスクだからです。多肢選択式のQAからは、さらに難しい多肢選択式のQAが生まれます。コーディング課題からは、さらに難しいコーディング課題が生まれます。一方で、「この契約書の免責条項が、3月の条件提示書と静かに矛盾していることに気づく」といったベンチマークは誰も作りません。採点には弁護士、時間、そして自動化に馴染まない判断が必要だからです。

だからこそ私は、ベンチマークの飽和はAIがその領域を「解いた」ことを意味する、という見方に同意しません。飽和とは、計器が振り切れているというだけの話です。40°Cを指して止まる温度計は、部屋が40度であることを証明しているわけではありません。別の温度計が必要だと示しているにすぎません。本番運用のためにモデルを評価しているなら、そして特に誤りに実際のコストがかかるLLMベースの意思決定システムを構築しているなら、飽和したベンチマークでのリーダーボードの差は、判断においてほぼゼロの重みしか持つべきではありません。

私たちは、測ると決めた仕事についてモデルがどれほど優れているかは正確にわかっています。それ以外の9割については、ほとんど何もわかっていないのです。

AI評価における街灯効果

街灯の下で鍵を探す酔っぱらいの古い小話があります。鍵をそこで落としたからではなく、そこしか明かりがないからです。ベンチマークの作り方も同じ論理に従っていて、データはそれがランダムではないことを裏付けています。今回の調査では、職種内でのタスクの重要度がカバー率を予測することがわかりました。その職種にとって最も重要と評価されたO*NETタスクは、最も重要度の低いタスクに比べて、ベンチマーク化される確率が6〜10倍高いのです。表面的には、賢明な優先順位付けに聞こえます。しかし実際には、私たちは見せ場となるタスクを測り、それをつなぐ部分を飛ばしているということです。

どんな仕事も、大部分はそれをつなぐ部分でできています。ソフトウェアエンジニアのベンチマーク化されたタスクは「このテストを通過する関数を実装せよ」です。しかし彼らの実際の一日には、同僚の書きかけのマイグレーションを読むこと、どのステークホルダーが実際にその決定を握っているのかを見極めること、そしてチケットが別の問題を記述していることに気づくことが含まれます。以前にも書きましたが、エージェント型コーディングツールの成否は、まさにこの点にかかっています。ループ、コンテキスト、権限の境界が、生成品質そのものより重要なのです。こうしたことは、HumanEval型のスコアには一切表れません。

カバー率の数字そのものにも、微妙な定義上の問題があります。「カバー済み」とは、5件以上のプロンプトがあるタスクに対応づけられていることを意味するのであって、5件のプロンプトがそのタスクを捉えていることを意味しません。子育ての悩みについて親にカウンセリングする13件のプロンプトは、ソーシャルワーカーが担当ケース、法廷、家庭訪問の食卓で実際にこなしている仕事を代表するものではありません。もし「よくカバーされている」という素人の基準を当てはめれば、測定された経済の割合は10%ではなく、ほぼゼロになるでしょう。街灯は狭いだけではありません。照らす光そのものが薄いのです。

モデルは生成するが、判断は誰もベンチマークしていない

私が最も痛烈だと感じる非対称性がこれです。現存するほぼすべてのベンチマークは「作る」ことをテストしています。コードを書く、メモを起草する、問題を解く、といったことです。しかし、ほとんどの実務タスクで経済的に決定的な半分は「検出」です。ミスを捕まえる、不整合を指摘する、自信満々の答えが間違っていると気づく、といったことです。経験の浅い会計担当者の価値は照合結果を作ることではなく、数字がおかしいと気づくことにあります。ベンチマークがこれをほとんどテストしないのは、採点可能な誤り検出タスクを作るほうが、採点可能な生成タスクを作るよりずっと難しいからです。現実味のある欠陥のある成果物、もっともらしいが間違っている微妙な誤り、そして何を検出できたとみなすかについての人間の合意が必要になります。

これは、評価設計に適用したドアマンの誤謬です。ドアマンを自動ドアに置き換えると、手遅れになってから、そのドアマンが入居者を迎え、荷物を受け取り、通りを見張ってもいたことに気づくのです。仕事のうちベンチマーク化された部分だけを自動化すると、ベンチマーク化されていない部分が実は構造を支える柱だったと知ることになります。私の物流業界の知人のモデルは、見える作業である突合メモの下書きは見事にこなせたのに、肝心の突合そのもの、つまりメモを書く価値を生んでいた判断を、静かに台無しにしていたのです。評価スイートは付け合わせを採点し、メインの料理を無視していました。

誤り検出が一級のベンチマーク対象として扱われるまで、デモの性能と本番での性能の間には、持続的なギャップが残るでしょう。これは、仕様が言っていることと実装が行っていることの間に存在するのと同じギャップであり、ソフトウェアの世界と同じく、失敗はそのギャップの中で育ちます。90パーセンタイルで生成し、30パーセンタイルで検証するモデルは、本番では、タイピングが速い30パーセンタイルの社員にすぎません。

実際のタスク分布で評価に重みを付ける

ベンチマーク・マッピングの研究で最も実用的なアイデアは、最もシンプルでもあります。ベンチマークが一部のタスクを過剰に代表しているなら、プロンプトごとに平均を取るのをやめ、各タスクが実際に費やす労働時間で重み付けしたうえで、タスクごとに平均を取るべきだというものです。「金融アナリスト」とタグ付けされた全プロンプトの単純平均は、たまたまプロンプト数が最も多いタスクに支配されます。通常は、データセットを最も作りやすかったタスクです。O*NETで重み付けした平均では、現実の各タスクが対等に扱われます。その差は劇的になりえます。

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

この例には注目すべき点が二つあります。第一に、重み付けしたスコアが下がるのは、モデルの弱いタスクがプロンプトの母集団で過小に代表されていたからです。これは、単純平均が隠してしまう歪みそのものです。第二に、そしてより重要なことですが、「顧客に助言する」はプロンプトが一つも対応づけられていないため、計算からまるごと消えています。どんな重み付けの方式も、カバーがゼロのタスクを黙って落とします。そして、経済のほとんどではカバーがゼロであることが普通です。重み付けは重み付けの問題を解決しますが、データ欠落の問題は解決できません。それには既存の評価を再平均するのではなく、新しい評価を構築する必要があります。

自分の実際の仕事に照らしてAIを評価する方法

モデルを選定したり導入したりするなら、経済全体にわたるカバーのギャップは具体的な意味を持ちます。自分のユースケースが、ベンチマークが測定している小さく明るい一角に当てはまらない限り、公開ベンチマークは当てにならない事前情報にすぎません。だから、自分の一角は自分で作りましょう。これは思うほど大げさな作業ではなく、ベンダーのスライドを信じるよりずっと確実です。

• 想像ではなく、ログからタスクを抽出する。実際のチケット、メール、例外を1週間分取り出し、発生頻度に応じてサンプリングしましょう。評価セットは、自分の業務のヒストグラムを反映していなければなりません。地味な裾野も含めてです。その地味な裾野こそ、仕事の大半なのですから。
• 時間またはコストで重み付けし、両方の数値を報告する。単純平均と重み付き平均で、真実は挟み込まれます。モデルが単純平均では勝ち、重み付き平均では負けるなら、それはテストしやすいタスクに強いということです。まさにそれこそが、あなたがスクリーニングで見抜くべき失敗パターンです。
• 検証タスクを含める。実際の出力、それも既知の不良品を含めて取り上げ、意図的に仕込んだ誤りと自然に発生した誤りを検出できるかでモデルを採点しましょう。私の経験では、検出能力と生成能力はほとんど相関しません。そして、あなたが実際に買っているのは検出能力のほうです。
• 非公開のセットを確保し、定期的に入れ替える。数か月にわたって再利用する評価は、誰かがそれに合わせてプロンプトを調整し始めた瞬間に、意図せずとも学習の標的になります。ケースは四半期ごとに入れ替えましょう。
• 可能な限りエンドツーエンドの結果で採点する。タスクが「この請求書を突き合わせよ」であれば、中間の文章ではなく、突合結果そのものを採点しましょう。統合テストのないコードをユニットテストが良く見せてしまうように、中間指標はモデルを実際より良く見せてしまいます。

最後に、もう一つ、静かだが名前を付けておく価値のある効果があります。日常的にAIコーディングツールを使っている人なら、きっと心当たりがあるはずです。マイクロスケールのボーモル病です。生成が20倍速くなっても、一日中生成しているわけではありません。速くならなかった部分、つまりレビュー、調整、検証、判断に時間を使うことになります。ベンチマーク化されていない残りの部分は、AIが進歩しても縮むことはなく、むしろ解放された時間を埋めるように膨らみ、そのAIを導入する価値があったかどうかを決める要素として、より大きな割合を占めるようになります。自動化可能な部分を、ますます高い精度で測りながら残りを無視するのは、不完全であるだけでなく、何が重要かを取り違えているのです。

これは、AIの進歩が見せかけだという主張ではありません。能力の向上は本物ですし、私自身もそれに賭けてプロジェクトを進めてきました。言いたいのは、私たちの測定文化が誤った分布に向いているということです。ベンチマークは、プロンプトを書くことも採点することも安くつく分野、つまりコード、数学、試験型の知識に向けて作られてきました。しかし経済の大部分は、そういう仕事ではありません。評価が追いつくまでは、どの見出しの能力主張も、地図の明るい10分の1についての話として受け止め、自分たちの暗い9割をカバーする評価を作りましょう。この地味で派手さのない測定作業に取り組む組織は、リーダーボードを更新し続けるだけの他の組織より、良い導入判断を下すはずです。その差は僅差では済まないでしょう。