結論から書きます。自動テストの通過は、そのまま使える成果物であることを意味しません。METRの実測では、人間が書いたテストによる自動採点が38%（±19%）だったのに対し、人間のレビュアーが手直しなしでマージ可能と判断したPRは15件中0件でした。テストに通った分でも修正見積りは平均26分です。
何が測られたのか（一次資料の実測）
METRが公開した記事「Research Update: Algorithmic vs. Holistic Evaluation」は、AIエージェントが書いたプルリクエスト（PR）を、二通りのやり方で採点し直した検証です。ひとつは人間が書いたテストケースを自動で走らせて合否を判定する「アルゴリズム的評価」、もうひとつは実際のOSSメンテナが受け入れ基準に照らして中身を読む「全体的評価」です。
対象と条件は次のとおりです。
| 項目 | 内容 |
|---|---|
| 対象リポジトリ | stdlib-js（約800万行）、hypothesis（約10万行） |
| 課題数 | 実課題18件（stdlib-js から15件、hypothesis から3件） |
| 人手レビュー対象 | 上記のうち15PR |
| エージェント構成 | Claude 3.7 Sonnet／Inspect ReAct スキャフォールド |
| 記事の公開時期 | 2025年8月 |
| 課題の絞り込み条件 | 大量の高品質なテストケースが書かれているPR |
この条件下での主な実測値は次のとおりです。
- 38%（±19%、95%信頼区間）：人間が書いたテストケースによる自動採点でのエージェント平均成功率。分母は実課題18件。n が小さく、信頼区間は±19%と幅があります
- 27%（±20、95%信頼区間）：人手レビュー対象サブセットでの自動採点成功率。分母は人手レビューした15PR
- 0件（15件中）：人間のレビュアーがそのままマージ可能と判断したPRの数。判定基準は大規模成熟OSSリポジトリの受け入れ基準
- 平均42分：エージェントのPRをマージ可能な状態にするのに要する修正時間の見積り。分母は人手レビューした15PR全体。レビュアーによる見積り値であり、実際に修正した実測値ではありません
- 平均26分（最短15分）：エージェントがテストに通っていたPRの修正所要時間の見積り。分母はテストに通った4PR
- 20分〜4時間、平均1.3時間：同じ18課題を人間のOSSメンテナ自身が処理するのに要した時間
（出典：METR、2025-08-13、https://metr.org/blog/2025-08-12-research-update-towards-reconciling-slowdown-with-time-horizons/）
この数字は誰が出しているのか
読む前に押さえておくべき前提があります。この記事はMETR自身による発表であり、同社はAIエージェントの能力評価手法（時間ホライズン指標）そのものの提供者です。 METRは自社の先行研究、すなわち開発者生産性のランダム化比較試験で観測された「AI利用による減速」と、自社の時間ホライズン指標が示す高い能力評価との食い違いを説明する目的で、この調査を実施しています。つまり、自社の評価手法をめぐる論点について、当事者が自ら測って公開した数字です。
これは「だから信用できない」という話ではありません。後述するとおり、この記事は自社の評価手法にとって不都合な結果を本文に明記しています。ただ、何を「成功」と定義するかという枠組み自体が発信元の関心に沿って設計されている以上、その枠組みごと自社に持ち込んでよいかは読む側が判断する必要があります。発信元の立場を確認してから数字を読む姿勢については、AIの回答品質と推論品質は別物か でも同じ論点を扱っています。
テストに通ってもなお、何が足りなかったのか
この検証で興味深いのは、指摘された不備の内訳です。テストに失敗した実行と、テストに通った実行とで、レビュアーが指摘した不備の種類が違います。
| 指摘された不備の種類 | テストに失敗した実行（n=11） | テストに通った実行（n=4） |
|---|---|---|
| 中核機能 | 100% | 25% |
| テスト網羅 | 91% | 100% |
| 文書 | 89% | 75% |
| lint・整形 | 73% | 75% |
| コード品質 | 64% | 50% |
読み取れることははっきりしています。テストに失敗した実行では、そもそも中核機能が動いていない指摘が100%でした。一方、テストに通った実行でも、テスト網羅の不備は100%、文書の不備は75%、lint・整形の不備は75%で指摘されています。中核機能の指摘は25%まで下がりますが、ゼロにはなりません。
つまり自動テストは、中核機能が動くかどうかについてはある程度の判別力を持っている一方で、テスト網羅・文書・整形といった「人が読んで初めてわかる不備」はほぼ素通りさせます。テスト通過は不備の有無ではなく、不備の種類が変わる境目でしかありません。
なお、n=11 と n=4 というサブグループの母数は極めて小さく、割合は1〜2件の増減で大きく動きます。100%と書かれていても、4件中4件という意味です。この規模感を外して割合だけを引用すると誤読になります。
読者への意味：完成の合図をどこに置くか
中小企業の経営者・情報システム担当にとって、この実測が持つ意味は2つです。
1.「テストが通った」を完成の合図にすると人的コストを読み違える
AI開発ツールの導入検討では、「AIが書いたコードがテストを通った件数」が成果指標として提案されることがあります。しかしこの検証の条件下では、自動採点38%に対してレビュー通過は0件でした。テスト通過は、人の手が要らないことを一切保証していません。
さらに、テストに通った4PRですら修正見積りは平均26分、最短でも15分でした。ゼロ分のケースが1件も出ていない、というのがこの数字の要点です。投資対効果の試算をするなら、「レビューと手直しの人件費」を必ず工数に計上すべき根拠になります。この計上を落とすと、削減できたつもりの時間が別の担当者の残業として現れます。
2. 比較対象は「人間が同じ課題にかけた時間」で見る
同じ18課題を人間のメンテナ自身が処理した時間は、20分〜4時間、平均1.3時間でした。一方、エージェントのPRをマージ可能にする修正見積りは平均42分です。この2つを並べると、少なくともこの条件下では、AIに書かせて人が直す経路が人が最初から書く経路を圧倒的に上回る、とは言えません。
大事なのは、自社で判断するときも同じ2つの数字を並べることです。AI導入後の所要時間だけを測っても意味がなく、同じ課題を自社の担当者がゼロから処理した時間と比べて初めて効果が出ます。自社基準での評価の組み方は 自社の評価基準を持つ で整理しています。また、AI開発ツールを工程全体の成功率としてどう測るかは AIエンジニアリング業務の成功率 が参考になります。
一次資料が自ら認めている限界
この検証には、本文自身が明記している制約が複数あります。中小企業がそのまま自社に当てはめるのは適切ではありません。
- 対象が大規模成熟OSSに限定されている。stdlib-js は約800万行、hypothesis は約10万行で、いずれも貢献者数百人規模です。本文自身が「多くのソフトウェア開発案件はここまでの文書・品質要件を持たない」と認めています。社内ツールなど基準の緩い開発にそのまま当てはめることはできません
- 課題選定にバイアスがある。本文は「大量の高品質なテストケースが書かれているPR」で絞り込んだと明記しており、通常の業務課題より明確にスコープされた問題に偏る可能性があります
- サンプルが極めて小さい。全18課題、人手レビューは15PR、サブグループは n=11 と n=4 です。38%の信頼区間は±19%と広く、サブグループの割合は数件の増減で大きく動きます
- エージェント構成が基本的。使用したのは「基本的なエージェントスキャフォールド」で、並列推論など高度な計算資源の活用をしていません。より優れたツール構成なら成績が上がる余地があると本文が認めています
- モデル世代が限定される。評価モデルは Claude 3.7 Sonnet であり、記事の公開は2025年8月です。以後のモデル世代に同じ数字が当てはまるとは限りません
- 42分・26分は見積りであって実測ではない。レビュアーが「これを直すならこのくらい」と見積もった値で、実際に修正作業を行って計測した時間ではありません
とくに1点目は、中小企業の読者にとって決定的です。この0件という結果は「AIのコードは使えない」ではなく「数百人が読む前提の成熟OSSの受け入れ基準では、そのままマージできるものは出なかった」という意味です。自社の受け入れ基準が違えば、結果も変わります。
TOEの読み筋
ここからは編集部の解釈です。TOEでは、この検証と同じ条件でのAIエージェントによるPR生成・レビュー計測を未実施です。 以下は一次資料と自社の一般的な開発実務からの推論であり、実測に基づく主張ではありません。
第一に、この記事から持ち帰るべきは数字そのものではなく、「完成の定義を誰が握っているか」という問いだと考えています。テスト通過という定義は自動化しやすく、だからこそ指標に採用されやすい。しかし採用される理由が「測りやすいから」である指標は、測れない部分をコストとして外に押し出します。今回で言えば、文書・テスト網羅・整形の不備がレビュアーの時間として現れました。
第二に、実務での現実的な扱いとしては、AI開発ツールの効果を「書く時間の削減」ではなく「レビュー込みの1件あたり総時間」で測るのが妥当だと考えます。前者だけを見ると必ず良い数字が出ますが、それは工数が移動しただけかもしれません。
第三に、自社の受け入れ基準を先に言語化しておくことです。何をもってマージ可能とするかが文書化されていない組織では、AIの成果物を評価する軸自体が人によってぶれます。この点は、AIを入れるより前の話です。導入初期の進め方は 中小企業のAI導入 最初の一歩 と 少人数チームでのAI導入 で扱っています。
いずれも、自社の課題・自社のリポジトリ・自社の基準で小さく測ってからでないと判断できません。ベンチマークの数字は、測り方を設計するための参考であって、結論ではありません。
まとめ
- METRの検証では、人間が書いたテストによる自動採点が38%（±19%、95%信頼区間、実課題18件）だったのに対し、人間のレビュアーがそのままマージ可能と判断したPRは15件中0件でした（出典：METR、2025-08-13）
- テストに通った4PRでも修正見積りは平均26分・最短15分で、ゼロ分の事例は出ていません。テスト通過は「手直し不要」を意味しません
- テストに通った実行（n=4）でも、テスト網羅の不備は100%、文書とlint・整形の不備は各75%で指摘されました。自動テストは人が読んで初めてわかる不備を素通りさせます
- ただし対象は貢献者数百人規模の大規模成熟OSS（stdlib-js 約800万行、hypothesis 約10万行）に限られ、本文自身が一般のソフトウェア開発はここまでの品質要件を持たないと認めています。社内ツール開発にそのまま一般化はできません
- サンプルは全18課題・人手レビュー15PR・サブグループ n=11 と n=4 と極めて小さく、42分・26分はレビュアーの見積りで実測値ではありません。またMETRは自社の評価手法をめぐる論点の当事者です
- 中小企業が持ち帰るべきは、AI開発ツールの投資対効果を「レビューと手直しの人件費」込みで試算すること。TOEではこの検証と同条件の計測は未実施です