AIモデルの評価基準の作り方、ベンチマーク56点のモデルが業務で勝つ

AIモデルの評価基準を作る目的は、今期どのモデルを選ぶかを決めることではない。ベンダーがモデルを更新するたびに、自分の組織の出力品質が変わったかを検知し、その原因をモデル側と自分たちが積み上げた指示側に切り分けられる状態を保つことである。国内の解説記事はすでに充実しており、MSEやF1スコアのような指標の使い分け、ルーブリックの自動生成、決定的チェックとLLM-as-judgeと人間サンプリングの3階層、評価体制を構築する4段階までが整理されている。それでも評価基準が社内に定着しないのは、指標の知識が足りないからではない。評価基準が「選定時に一度作る資料」として扱われていて、回し続ける持ち主がいないからだ。本稿はその一点に絞る。

なぜベンチマークの点数は業務の成果とずれるのか

具体的な数字から入る。Every の実戦評価では、OpenAIのGPT-5.6 Solがシニアエンジニアベンチマークで56点、AnthropicのFableが90点だった。34点の差は大きい。ところが元記事は、その差の大部分をSolが吐き出した約12,900行の不要コードで説明している（この元記事は導入と論点リストのみで、詳細は確認できない）。そして同じ記事の著者Katie Parrottは、6モデルの執筆ベンチマークで最下位だったそのSolを使って、その記事1本のドラフトを6〜8時間で24回回している（GPT-5.6 SolとFableはどう使い分けるべきか ― ベンチマーク順位と業務ROIが一致しない理由で扱った）。

この対比は、点数が間違っているということを示すものではない。元記事の結論は、Solは成果の姿が見えていて自分で舵を取りたい仕事に向き、輪郭の曖昧な長丁場の仕事にはFableを残す、というものだ。本稿の読みでは、ベンチマークは測るべきものを測っているが、その組織の業務が何を失敗と見なすかを知らないまま測っている。

Every はこの性質をはっきり言い切っている。

“Public benchmarks can tell you that one model is generally more capable than another. They can’t tell you whether it caught the clause your lawyers care about, preserved your house style, or spared an employee another round of checking.”

（公開ベンチマークは、あるモデルが別のモデルより総じて高い能力を持つことは教えてくれる。しかし、弁護士が気にする条項を拾えたか、その組織のハウススタイルを守れたか、従業員をもう一巡のチェック作業から解放できたかまでは教えてくれない。出典: Every、2026-08-26）

にもかかわらず、評価の仕組みを持たずに支出している組織は珍しくない。Mercor CEOのBrendan Foodyは、年間最大1億ドルをAIに支出しながら、実業務のタスク集で本番前にモデルを比較するオフライン評価（offline evals）を持たない企業が少なくないと指摘する。Box CEOのAaron Levieも「企業は雰囲気（vibes）だけでは進めない」と応じている（AI モデル選定はベンチマークスコアで決めていいのか ― 実業務で測るオフライン評価（offline evals）の作り方）。AstraとFable 5.1が大学院レベルの科学の問題で96%・93%を取る時代に（個人のスタンダードを AI テストに変える方法）、その点数と自分の組織の業務成果の対応関係が検証されていない組織が珍しくない、という状態である。

業務の評価基準は誰がどう作るのか

結論を先に置く。評価基準はトップダウンとボトムアップの2種類からなり、どちらも必要だが、国内の解説で手厚いのは前者で、現場に欠けているのは後者である。

Behind the Craft のPeter Yangが、自分のpodcast制作スキルの評価を、4,500人以上が受講するAI評価の講座を教えるShreyaとHamelに監査してもらったときの結果が分かりやすい。「要点それぞれが240〜330字に収まっているか」のように事前にルールを定義するトップダウン評価は充実していた。一方、AIの出力と自分の最終編集を比較して失敗を洗い出すボトムアップ評価は、ほぼゼロだった（AI の評価基準（eval）はどう作ればいいのか ― トップダウン評価とボトムアップ評価を組み合わせる5ステップ）。

“Top-down evals are rules that you define upfront. […] Bottom-up evals are failures found by comparing AI’s output with my final edits.”

（トップダウン評価とは、事前に定義しておくルールのことだ。［中略］ボトムアップ評価とは、AIの出力と自分の最終編集を比較して見つけた失敗のことだ。出典: Behind the Craft by Peter Yang、2026-08-23。元記事は目次と冒頭の要点のみ）

この区別が実務上重要なのは、作る主体が違うからだ。トップダウン評価は仕様書を書ける人が机上で作れる。ボトムアップ評価は、その業務のアウトプットを実際に直している人の手元にしか材料がない。ShreyaとHamelは、見つけた失敗を評価ルールに落とす前に10〜20件の過去事例を比べるよう勧めている。数件の例に合わせすぎた基準にしないためだ。

Everyはこれを全社員分作ろうとしている。編集長のKate Leeのベンチマークは句読点から語選択までの規則で校閲の判断を捉え、Mike Taylorのスライド作成のベンチマークには「1スライドに1アイデア」という自分の好みが入っている（個人のスタンダードを AI テストに変える方法）。評価基準の正体は、各人が普段AIの出力を直すときに使っている判断を、モデルに対して流せるテストに書き換えたものである。

ここから経営の決め事が1つ出る。評価基準を誰の持ち物にするかだ。業務の持ち主に握らせれば材料は手に入るが、個々の裁量に任せると基準が社内でばらつき、組織としてのモデル判断には積み上がらない。中央のAI推進部門に握らせれば基準はそろうが、ボトムアップの材料から遠い。現実的な分担は、合否基準の設計権限を業務部門に置き、書式と再実行の運用を中央が持つ形になる。

評価基準を持つとモデル更新の何が変わるのか

ここが、評価基準を選定の資料ではなく運用の資産と呼ぶ理由である。

Everyの報告に、事情がそのまま出ている事例がある。同社のOpus 5検証で、Kieranはcompound engineering（26のエージェントと13のスキルを持つオープンソースのコーディングプラグイン）でモデルがステップの合間に止まり続ける現象に遭遇した。そこで彼が立てた問いは「Opusが悪いのか、プラグインが邪魔をしているのか」である。AI戦略家のDrew Breunigは、書かれた当時のモデルより長く生き残った指示をこう名付けている――「プロンプト負債」。見つかった古い指示の一つがそれだった。他のエージェントに引き継ぐため停止して待つよう命じる指示が残っており、引き継ぎ先のエージェントは存在しなかった。この引き継ぎを外すと、ワークフローの信頼性が上がった（モデル更新で社内プロンプトが壊れる「プロンプト負債」——Opus 5移行で誰がスキルを再検証するのか）。

経営にとって重要なのは、原因の切り分けに何が必要だったかである。元記事が勧める手順は、スキルを書き直す前に、またモデルを責める前に、同じモデル・同じタスクでスキルあり／なしの2回を他の条件をそろえて実行し、結果を比べることだ。スキルありの回だけ止まるなら、スキルが干渉している可能性がある。両方が同じ場所で失敗するならモデルかプロンプトかツールか、タスク自体を見る。結果がばらつくなら再試行する。

この手順は、固定したタスク集と合否の定義――つまり評価基準――がなければ成立しない。社内にスキルやプロンプトテンプレート、エージェント定義が何十本とある組織では、更新後に何かがおかしいという報告が上がったとき、モデルのせいなのか自分たちが積み上げた指示のせいなのかを切り分ける手段そのものがない。評価基準を持つと変わるのは、品質が落ちたかどうかが分かることに留まらない。落ちた原因をベンダー側と自分の組織側に切り分けられるようになる。これは、乗り換えるべきか自分たちの資産を刈り込むべきかという投資判断に直結する。

更新の頻度が上がっていることも効いている。投資家のGavin Bakerが紹介したVercel CEOのGuillermo Rauchのグラフでは、同社のフロントエンド向けクラウド基盤上で、オープンソースモデルのトークンシェアが2カ月で28%から62%に拡大している。a16zによれば法務職のCodex利用は2月比108倍である。選択肢が増える速度に対して、「最高スコアのモデルを選ぶ」という調達の作法は追いつかない。

そしてテストを持つと、選定の結論自体が変わることがある。Everyで、Mike Taylorの基準を使って複数モデルを比較したところ、小型のGPT-5.6 LunaがFableやGPT-5.6 Solを上回った。基準の持ち主であるMike自身が結果を検証し、小型モデルが良い成績だったと認め、日常業務の多くをこなせそうだとして、より難しい課題を基準に加えた。彼の日常業務の多くのタスクで、より高性能で高額なモデルが小型モデルに負けていた。これは一人のベンチマークの結果にすぎないが、全社員に最上位モデルを一律で配っている組織では、タスクの多くが小型モデルで足りている可能性があり、その差額は気づかれないまま積み上がる。

ただし、テストの点数そのものを素朴に信じてはいけない。Everyは編集長Kate Leeの過去約3万件の編集履歴で訓練したAIコピーエディタ「KateBench」を構築し、提案の受諾率85〜90%という数字を得た。一見、完成に近い。だがKateBenchの持ち主は、この数字を信用しない理由を2つ挙げた。1つは当時の提案数の上限が40件で、長い原稿では良い修正を見つけても編集者に見せる前に捨てていたこと（上限はその後80件に引き上げられている）。もう1つは実行ごとのばらつきで、こちらは上限を上げても消えない。だから彼は、各バージョンを複数回実行してからでないと改善と呼べないと考えている。単発のスコアはプロンプト変更の当たり外れでも動く。評価基準を回す運用には、再実行の回数まで含まれる。

最初に評価基準を作る業務はどれか

決めることは1つに絞れる。モデル更新のたびに、どの業務の評価基準を誰が回して結果を誰に報告するかを、ベンダーのリリースサイクルに先回りして割り当てることだ。

着手の順序は3手で足りる。第一に、対象を1業務に絞る。条件は、アウトプットを人が毎回直していて、その直した最終版が過去10〜20件分残っていること。週次レポート、提案書、問い合わせ一次返答のように、直した履歴が溜まっている業務が候補になる。第二に、その10〜20件についてAIの出力と人の最終版を突き合わせ、失敗パターンを5つ書き出す。これがボトムアップ評価の素になる。第三に、同一バージョンを複数回流して合否のばらつきを見る。ここまでで、その業務については次のモデル更新を数字で迎えられる。

なお、どの業務にどのモデルを割り当てるかという話はClaude と GPT、業務での使い分けをどう決めるかで扱っている。本稿が扱ったのはその手前、割り当ての根拠をどう持つかという工程である。評価基準を自前で持つか外部に委ねるかの判断軸は内製か、購入か ― 自前のAIハーネスへの投資をどう判断するかと合わせて読める。

まとめ: 指標を選ぶ前に、回す人を決める

AIモデルの評価基準の作り方でつまずいている組織の多くは、指標の知識が足りないのではない。評価基準を一度作って棚に置き、次のモデル更新までに誰も触らない構造になっている。Solの56点とFableの90点はどちらも正しい測定だが、自分の組織の業務が何を失敗と見なすかは一言も含んでいない。それを含んだテストは、作った瞬間ではなく、ベンダーのリリースのたびに流したときに価値を出す。経営が決めるべきは、指標の種類ではなく、モデル更新のたびにどの業務のテストを誰が回すか、その一点だ。