OpenAIがo3を発表したとき、ベンチマーク数字のインパクトは並外れていた。ARC-AGIで87.5%、GPQAダイヤモンドで87.7%、AIME 2024では96.7%——どの指標も、人間のトップパフォーマンスを射程に入れる水準だった。「AGIに近づいた」という言説がコミュニティを駆け抜けた。
しかし、実際にo3を触ったエンジニアたちの声は少し違う温度感を持っていた。「単純なはずのコードレビューで変な答えを返してくる」「コストが高すぎて日常使いできない」「考えすぎてズレた結論に着地する」——スコアと体感の間の距離は、単なる期待値のズレで説明するには少し大きすぎた。
この乖離は、o3というプロダクトの問題ではない。ベンチマーク評価と実務適性の間に構造的に存在する非対称性の話だ。
ベンチマークが「測っている条件」を読む
ARC-AGIは、「人間には簡単だがAIには難しい」とされる論理パターン認識の評価セットとして設計された。人間が90%以上正解できる問題を、AIが解けるかどうかを問う形式だ。o3はこれを大量の計算リソースを投入することで突破した。OpenAIの開示情報によれば、高精度設定での推論には1問あたり数十ドル規模のコストがかかるとされている。
「解けた」は事実だ。しかし「どんなコストで解いたか」は、スコアの外にある。
実務の意思決定でAIを選ぶとき、問われるのはスコアではなくROIだ。週に100回繰り返すタスクに1回あたり数十ドルかかるモデルを本番ワークフローに組み込む選択は、ほぼどの組織でも成立しない。「性能は高いが使えない」という評価が生まれる第一の理由がここにある。
「よく定義された問題」と「実際の仕事」の間
ベンチマークが測定できるのは、問題が明確に定義され、正解が一意に存在し、評価者が答えを検証できる条件下での能力だ。ARC-AGIも、GPQAも、SWE-benchも、この条件を満たすよう設計されている。問題は意図的に整形されている。
実際のソフトウェアエンジニアリングはそうではない。要件は曖昧で、コンテキストは長く入り組んでおり、「正解」は「動く」「保守できる」「チームが理解できる」「既存の設計思想と整合する」が複合したものだ。コードを生成する能力と、プロジェクトの文脈を読んで適切な判断をする能力は、異なるものだ。
「単純なはずのタスクで変な答えを返す」という報告が目立つのは、おそらくo3の推論構造と逆説的に関係している。o3は複雑な問題を深く考えることに最適化されている。シンプルな入力を受け取ったとき、そのシンプルさを正確に見抜けないケースがある——あるいは、複雑に解釈する方向へ動いてしまう。これはモデルの欠陥というより、ベンチマークが問わなかった問いが実務で露出した例だ。
スコアが「見えていない」変数
ベンチマークが構造的に捉えにくい変数がある。コスト、レイテンシ、予測可能性、同じ入力に対する出力の安定性、長いコンテキストでの挙動、曖昧な指示への応答、既存ワークフローとの摩擦——これらはすべて、実務での「使えるかどうか」を決定づける要因だが、標準的なベンチマークの外にある。
特に「予測可能性」は見落とされやすい。エンジニアリング業務でAIを使う場合、何が返ってくるかある程度見通せることは、精度と同じくらい重要だ。高精度でも出力が不安定なモデルは、品質確認のコストを増やし、結果として生産性を下げる。スコアはこのトレードオフを映さない。
評価軸をどこに置くか
o3への批判を述べたいわけではない。このモデルが特定の問題領域で卓越した能力を持つことは、ベンチマークが示した通りだろう。問題は、そのスコアを実務適性の代理指標として読む側の習慣にある。
ベンチマーク設計者自身も繰り返し指摘してきたことだが、「AIが難しい問題を解ける」ことと「AIが私の業務を助けられる」ことは、別の命題だ。スコアの高さは前者を示すが、後者を保証しない。
o3のスコアと使用感の乖離は、単なるプロダクト評価の問題ではない。AIモデルの能力評価基準が、実際の業務要件から離れた場所に設計されていることのシグナルとして読むべきだ。ベンチマークが何を測っているかを理解しないまま意思決定の根拠にすると、導入後に「数字は良かったのに」という後悔に変わる。
スコアを見る前に、「これは何を測っているか」を問う習慣が、今のAI導入判断には必要だと思う。
コメント