テストに通るのに使えない——AIが書いたコードの半分は現場で却下される

「テストに合格」の意味が現場と違う

まず、この研究が何を調べたのかを整理する。

SWE-benchは、実際のソフトウェアで過去に見つかったバグを使い、「AIがそのバグを正しく修正できるか」を自動で採点するテストだ。採点の仕組みはシンプルで、修正後のコードが既存のテストをすべて通れば「合格」とみなされる。OpenAI、Anthropic、Googleといった企業がこのスコアを競い、「SWE-benchで○○%達成」という数字がプレスリリースに並ぶ。たとえるなら、AIコーディングの「TOEIC」のような存在だ。

METRは、このテストに合格したAIのコードを、実際にそのソフトウェアを日常的に開発している現役エンジニア4名に見せた。出所を伏せた状態で「このコードをプロジェクトに採用するか」を判断してもらった（METR公開レポート）。

結果、テストの合格率と現場エンジニアの採用率には平均24ポイントの差が開いた。テストで「合格」とされたコードのうち、およそ半分は現場のエンジニアに「これは使えない」と判断された。

なぜ「合格」したコードが却下されるのか

テストは「バグが直ったかどうか」を機械的にチェックする。だが現場のエンジニアは、それだけでは判断しない。

却下されたコードを分類すると、3種類の問題が見えてくる（METR公開レポート）。一つ目は「書き方の質」——動くけれど、コードの書き方がプロジェクトのルールに合っていない。二つ目は「副作用」——バグは直ったが、別の機能を壊している。三つ目は「根本的な不備」——テストは通ったが、実は問題の本質を解決していない。

身近な例に置き換えてみる。報告書の誤字を直してほしいと頼んだら、AIが誤字は直したが、文章の意味が変わってしまった。あるいは、誤字は直ったが、フォーマットが社内ルールと違う。さらには、実は誤字ではなく表現自体を修正すべきだったのに、表面的に直しただけだった。テストは「誤字がなくなったか」しか見ない。現場の人間は「この報告書を上に出せるか」を見ている。

「AIにコードを書かせる」判断への影響

この話はエンジニアだけの問題ではない。

いま、多くの企業が「AIにコードを書かせる」判断を行い始めている。その判断を下すのはCTOやエンジニアリングマネージャーだけではなく、経営層やプロジェクトマネージャーの場合もある。そのとき根拠になるのが「SWE-benchで○○%達成」という数字だ。

昨日配信した記事で、AmazonがAI生成コードの本番投入にベテランエンジニアの承認を義務化した動きを取り上げた。AIの使用率80%を目標に掲げた結果、システム障害が連発し、人間による検証が制度化されたという話だ。METRの研究は、Amazonの判断を裏付けるデータを提示している。テストに合格するだけでは、現場で使える品質には届かない。

以前取り上げた記事では、医療AIが試験には合格するのに臨床現場では機能しない構造を扱った。医療からコーディングへ。分野は違うが、構造は同じだ。「テストの点数」と「現場で使える実力」のズレは、AI産業全体に横たわる未解決の課題になりつつある。

物差しが壊れている可能性

この研究で興味深いのは、人間が書いたコードの扱いだ。比較のために、人間が過去に書いた修正コード47件を、同じ条件でエンジニアに審査させた。結果、人間のコードでも採用率は68%にとどまった（METR公開レポート）。つまり、現場のエンジニアが見ているのは「正しく動くか」だけではなく、「将来このコードを別の人が修正するとき困らないか」「プロジェクト全体の設計と整合するか」といった、テストでは測れない判断だ。

METRは、テストのスコアが年間約9.6ポイント改善している一方、現場エンジニアの採用率の改善はそれより遅いペースだと示唆している（METR公開レポート、統計的に10%水準で有意）。AIの性能は上がっている。しかし現場が求める品質との距離は、スコアの伸びほどには縮まっていない可能性がある。

さらに重要な留保がある。この調査ではAIに1回きりの試行しか与えていない。実際の開発では、指摘を受けて修正し、再提出する反復がある。だが、この留保こそがこの研究の核心を際立たせる。現場の仕事が「1回の提出で完結する」ものではないのなら、「1回の試行で何%解けたか」を競うテストは、そもそも仕事の実態と合っていない。測れるものだけを測り、測れないものが現場では価値を決めている——AIの導入を判断する側にとって、テストのスコアは参考にはなっても、根拠にはならない時代に入りつつある。