新しいAIモデルが自分の仕事に本当に良いかを見極める方法

短い答え：発表時のベンチマークはあなたの問いに答えない

最先端モデルのリリースにはいつも、標準化された評価で先行していることを示すグラフが添えられます。その数字は本物ですが、月曜日に何を使うべきかを決めるうえではほとんど役に立ちません。理由は3つあります。

差はわずかで、そのタスクはあなたのものではありません。 推論ベンチマークでの2ポイント差は、どちらのモデルが良いクライアントメールを書けるか、200行にわたってスキーマをより確実に保持できるかについては何も語りません。

ベンチマークは採点しやすいタスクしか測っていません。 正解があるものです。ほとんどのプロフェッショナルな仕事には正解がありません。トーン、構成、何を省くかという判断です。そこにこそモデル間の差が最も出るのに、そこは何も測定されていません。

発表時の比較はベンダー自身が行っています。 必ずしも不誠実というわけではありませんが、自社のモデルが2位になった評価を公表する会社はありません。

答える価値がある問いはもっと狭いものです。週に20回行う特定のタスクで、この2つのうちどちらが優れているか。それには公表された答えはなく、調べるのに1時間ほどかかります。

リリース間で実際に変わる傾向にあるもの

最近の最先端モデルのリリースを見ると、日常的な使用で重要になる改善はいつも同じ領域に集中しており、それらは発表で取り上げられることがほとんどありません。

改善した点	どう気づくか	ベンチマークに表れるか
指示への従順さ	3つ目の制約を無視しなくなる	ほとんどない
否定形の指示	「比喩を使わないで」が実際に守られる	ない
長文脈の記憶	3ページ目だけでなく140ページ目の内容も見つける	部分的
書式の規律	頼んだ通りの列を持つ表が毎回出てくる	ない
較正された不確実性	でっち上げる代わりに「わからない」と言う	ない
トーンの制御	送信できる状態になるまでの書き直しが減る	ない
推論の深さ	見落としたエッジケースを拾う	ある、これだけが測定対象

この7つのうち5つはベンチマークのグラフには表れず、新しいモデルが使ってみて良く感じるか悪く感じるかの理由になっています。特に指示への従順さは、編集して使える初稿と捨てる初稿の違いを生みます。

1時間でできる評価

発表時の記事を読む代わりにこれをやりましょう。自分の素材で両方のモデルを並べて実行します。

1. 直近2週間の本物のタスクを5つ集めます。 おもちゃのようなプロンプトではなく、実際の文脈を貼り付けた本物のものです。少なくとも1つは文章作成タスク、1つは構造化出力タスク、1つは不慣れな事柄について推論が必要なタスクを含めます。
2. 何も実行する前に、それぞれについて良い回答の条件を一文で書き出します。 これは、より長く自信ありげな出力を好んでしまうという、強く、ほぼ無意識のバイアスを防ぐステップです。
3. 各タスクを両方のモデルに並行して実行します。 どちらの回答も他方に引きずられないようにするためです。
4. 出力の読みやすさではなく、編集の手間で採点します。 つまり、出力から送信できるものにするまでにどれだけ作業が必要かです。
5. 勝者だけでなく差の大きさも記録します。 差がなければ、そのタスクではモデル選びを気にしなくてよいという、本当に役立つ情報になります。
6. 記録を保存しておきます。 3か月後に次のリリースが来たとき、同じ5つのタスクを再実行すれば20分で本物の答えが得られます。

最後の点が積み重なっていく部分です。保存された評価セットこそが、以降の各リリースを安く評価できるようにする唯一のものです。

最先端モデルを見分ける6つのプロンプト

一般的な質問には、どの高性能モデルも似たような答えを返します。違いを見たいなら、特定の能力に負荷をかけましょう。

• 難しい局面でのトーン。 締め切りに間に合わなかったことをクライアントに伝えるメモを書いてください。過度に謝罪せず、言い訳もせずに責任を認めてください。120語以内で。 語調の違いはすぐに表れます。
• 否定形の制約。 比喩や例えを一切使わずに[概念]を説明してください。 否定形の指示への従順さは、思っている以上にばらつきます。
• 厳密な抽出。 すべての日付、金額、当事者を、ちょうどこれらのキーを持つJSON配列として抽出してください。フィールドがない場合はnullを使ってください。推測しないでください。 書式の規律と、空欄を埋めたがる傾向を試します。
• 長文脈の記憶。 長い文書をアップロードし、途中の内容について尋ねます。うたわれているコンテキスト長とは違う、実際に使えるコンテキストが明らかになります。
• 知らないことを認める。 本当にマイナーな、あるいはごく最近の事柄について尋ねます。最良の回答は明確な「わからない」か、出典付きの検索結果です。ここでのでっち上げは、どんなベンチマークがあろうと失格です。
• 複数制約への準拠。 一度に6つの制約を与え、いくつ守られたかを数えます。この1つのテストが、他のどれよりも日々の満足度をよく予測します。

答えはたいてい「どちらも、それぞれ違う用途で」

人はリリースに対して結論を求めますが、評価を実際にやってみたあとの正直な結論は、ほぼ常に割れます。一方のモデルは文章とトーンで勝ち、もう一方は厳密な構造とスピードで勝ちます。一般的な推論についてはどちらも僅差で、それだけでは何も決まりません。

これはごまかしではなく、実際の結果であり、実務上の意味を持ちます。使えるモデルが1つだけなら、どのカテゴリのタスクで劣ることを受け入れるかを選んでいることになります。両方使えるなら、リリースにまつわる問いは「乗り換えるべきか」ではなく「どのタスクを動かすか」になり、はるかに小さく低リスクな判断になります。

これはリリースの意味そのものも変えます。すでに複数のモデルがあるワークスペースに新しいモデルが加わると、5つのタスクを再実行し、ルーティングを調整して、そのまま続けるだけです。移行もなく、解約もなく、テストする前にコミットしたせいで劣ったものを1か月使い続けることもありません。

リリース当日にすべきこと

すぐにデフォルトを切り替えないこと。 発表週の印象は、目新しさと最初に出回った例に強く左右されます。

評価セットを再実行すること。 前回のものを保存していれば20分で済みます。

地味な点を確認すること。 コンテキストウィンドウ、既存のプロンプトが同じように振る舞うか、頼っていた何かが変わっていないか。一般的には優れたモデルが、あなた固有のテンプレートでは劣ることもあり、本番の作業をそこに移す前に知っておく価値があります。

丸ごとではなく、タスクごとにルーティングを更新すること。 新モデルが明らかに勝ったカテゴリだけを移し、残りはそのままにします。

制約が見えてくるまで2週間待つこと。 新しいモデルの失敗パターンは、広く使われ始めてからおよそ2週間で表面化し、それらは発表にはほとんど載っていません。

全体のフレームワークについてはAIモデルの選び方を、1つのプロンプトで2つのモデルを実行する具体的な方法についてはモデルを並べて比較するを参照してください。