結論を先に

熟練OSS開発者16名・実課題246件をランダム割付で測った調査で、AI使用を許可した条件の完了時間は19%長くなりました。同じ16名は事前に24%速くなると予測し、実験後も20%速くなったと信じていました。実測と実感の符号が逆です。ただし対象は極めて限定的で、著者自身が「大半の開発者に当てはまる証拠ではない」と明記しています。

（出典：METR（2025年7月10日公開）、2025-07-10、https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/）

まず、この記事の利害関係を明かします

この記事を書いている株式会社TOEは、中小企業向けにAI導入の支援を行っている会社です。「AIを入れましょう」と提案して対価を得る立場にあり、利害関係者です。

そのうえで、今回取り上げる調査の出どころについても整理しておきます。調査を行ったMETRは、AIモデルの評価を専門とする研究機関であり、被験者が使ったCursorやClaude 3.5/3.7 Sonnetの提供者ではありません。つまりこれは「メーカーが自社製品の効果を自分で発表した数字」ではありません。もし発信元が自社製品について書いている場合、読者はその数字を割り引いて読む必要がありますが、今回はその構図には当たりません。

一方で、TOEはこの実験を自社では再現していません。以下の読み筋は、TOE未実施の前提で書いています。

実際に何をどう測ったのか

METRが行ったのは、意見調査でもベンチマークでもなく、実務課題を使ったランダム化比較試験です。

  • 被験者は熟練のオープンソース開発者16名
  • 対象は実際に存在する課題246件（バグ修正・機能追加など、架空の練習問題ではない）
  • 各課題を「AI使用可」「AI使用不可」にランダムに割り付け
  • 1課題あたり平均2時間、被験者への報酬は時給150ドル
  • 使用ツールは主にCursor Pro＋Claude 3.5/3.7 Sonnet（2025年前半時点のフロンティアモデル）

重要なのは、被験者が自分が複数年（multiple years）貢献してきたリポジトリで作業している点です。対象リポジトリは平均2.2万スター超、100万行超という規模の成熟した大規模OSSでした。つまり被験者は、そのコードベースの構造も暗黙のルールも既に頭に入っている状態です。

調査の対象範囲

項目 内容
被験者（n数） 熟練OSS開発者 16名
対象課題 実課題 246件（1課題あたり平均2時間）
割付方法 課題ごとにAI使用可／不可をランダム割付
対象コードベース 被験者が複数年貢献した成熟OSS。平均2.2万スター超、100万行超
使用ツール・モデル 主にCursor Pro＋Claude 3.5/3.7 Sonnet
実施期間 ブログ本文に記載なし（公開日は2025年7月10日）
発信元 METR。使用ツールの提供者ではない

なお、実施期間はブログ本文に明記がありません。「いつ測ったのか」は結果の賞味期限を左右する情報なので、分からない点は分からないまま置いておきます。

数字の中身 ― 実測と実感が逆を向いた

出た数字は3つです。すべて同じ16名についてのものです。

指標 値 条件
実測された完了時間の変化 19%長くなった AI使用可の条件と使用不可の条件の比較。熟練OSS開発者16名・実課題246件
開発者本人の事前予測 24%速くなる 同じ16名による実験前の予測。実測は19%の遅延で方向が逆
開発者本人の事後自己評価 20%速くなった 実測19%の遅延を経験した後の、同じ16名の事後自己申告

事前に「24%速くなる」と予測するのは、まだ分かります。人は新しい道具に期待します。

見過ごせないのは3つめです。実際に19%遅くなる作業を自分の手でやり終えた後でも、本人は「20%速くなった」と答えている。体験しても、実感は修正されませんでした。

これはAIの性能の話というより、人間の時間感覚の話です。AIが出力している間、開発者は待っているだけで手を動かしていない。その待ち時間は「自分が働いた時間」として記憶されにくい。一方、自力でコードを書いた時間は全部が労働として記憶に残る。同じ実時間でも、体感の重みが違う可能性があります。ただしこれはTOEの解釈であり、調査がその機序を検証したわけではありません。

この調査で言えないこと（著者自身が明記している限界）

ここが最も大事な部分です。METRは自ら、次の点を証拠として主張していないと書いています。

  • 本研究は「現在のAIが多くの／大半のソフトウェア開発者を高速化しない」ことの証拠にはならない
  • ソフトウェア開発以外の領域で、個人や組織が高速化しないことの証拠にもならない
  • この設定においてさえ、既存AIをより効果的に使えばプラスの高速化を得る方法が存在しない、とは言えない
  • Cursorの学習効果（50時間を超える使用による習熟）の影響は排除できていない
  • 高い品質基準が求められる環境では、AIの能力が相対的に低い可能性がある

さらに、統計面でも留保があります。19%という数値の信頼区間は公開版の本文には未掲載で、開発者クラスタを考慮したクラスター標準誤差は「forthcoming（今後公表）」とされています。n=16という規模を考えれば、この点は軽くありません。

そして条件面。使用モデルは2025年前半のClaude 3.5/3.7 Sonnetです。その後のモデル世代に同じ結果が当てはまる保証はありません。

つまりこの調査は「AIは開発を遅くする」という一般命題ではなく、「自分が知り尽くした大規模コードベースで作業する熟練者16名という条件下では、こうなった」という一点の観測です。ここを外して引用すると、調査を誤用することになります。

中小企業にとっての意味 ― 使えるのは数字ではなく、測り方

では自社に関係あるのか。19%という数字を自社に持ち込むのは誤りです。対象が違いすぎます。

持ち込めるのは、こちらです。

「使った本人が速くなったと感じている」を、導入効果の根拠にしてはいけない。

この調査が示したのは、実測と自己申告の符号が逆転しうるという事実です。差の大小ではなく、向きすら逆になった。だとすれば、導入後アンケートやヒアリングだけでROIを判断する運用は、成果を測っているのではなく期待を測っていることになります。

中小企業の現場で起きがちなのは、次の流れです。

  • 現場に「AIで楽になりましたか」と聞く → 「楽になりました」と返る
  • その回答を根拠に契約を継続・拡大する
  • 実際の処理件数や納期は変わっていないが、誰も測っていないので気づかない

止め方は単純で、時間を測ることです。

  • 同種の作業を「AIあり／なし」に分けて、作業時間を実測する
  • 分けられないなら、導入前後で同じ作業の所要時間を比較する
  • 測る単位は感想ではなく、件数・分・納期・差し戻し回数
  • 割り付けは可能な範囲でランダムに（得意な人がAIあり側に偏ると、比較が壊れます）
  • 「速くなった気がする」は記録しておくが、判断材料にはしない

評価軸そのものの立て方は自社の評価基準を持つという話で扱っています。導入初期の順序については中小企業がAIで最初にやる一歩が近いです。小さなチームでの進め方は少人数チームでのAI導入、開発業務そのものの成功率の測り方はAIエンジニアリング作業の成功率を参照してください。

TOEの読み筋（TOEでは未実施）

先に明記します。TOEはこの実験を再現していません。以下は実測ではなく解釈です。

この調査の価値は「AIは遅い」ではなく、AIが効く条件と効かない条件の境界線を示唆した点にあると読んでいます。

遅くなった側の条件を並べると、共通点が見えます。作業者はコードベースを熟知していて、品質基準が高く、暗黙のルールが多い。この状況では、人間が自分でやったほうが速いのは自然です。AIに文脈を説明し、出力を読み、基準に合っているか検証する。その一連が、自力で書く時間を上回った可能性があります。

逆に言えば、担当者が文脈を持っていない作業、品質基準がそこまで厳しくない作業、説明コストより実行コストのほうが大きい作業では、逆の結果が出る余地があります。中小企業の現場にある「調べる」「下書きを作る」「形式を揃える」といった作業は、むしろこちら側に寄っています。

ただしこれは仮説です。自社の業務がどちら側なのかは、自社で測るしかありません。この調査が本当に教えてくれるのは19%という数字ではなく、測らなければ符号すら分からないということです。

まとめ

  • METRの調査では、熟練OSS開発者16名・実課題246件をランダム割付した結果、AI使用可の条件で完了時間が19%長くなった（出典：METR、2025-07-10）
  • 同じ16名は事前に24%の高速化を予測し、実験後も20%速くなったと信じていた。実測と実感の符号が逆転した
  • 対象は自分が複数年貢献した成熟OSS（平均2.2万スター超・100万行超）での作業に限定され、著者自身が「大半の開発者に当てはまる証拠ではない」と明記している。信頼区間は未掲載、モデルは2025年前半世代
  • 中小企業が持ち帰るべきは19%という数字ではなく、「自己申告でROIを判断すると向きすら間違いうる」という測り方の指針
  • TOEはこの実験を未実施。AIが効く／効かない境界は業務ごとに違うため、導入判断は自社での作業時間の実測で行うのが現実的