AIツールで経験豊富な開発者が19%遅くなる｜METR研究の衝撃と2026年の真実

「AI coding tools made me 19% slower. The irony is I thought I was getting faster.（AIコーディングツールで19%遅くなった。皮肉なのは、速くなっていると思っていたことだ）」

これはHacker Newsスレッド（Study finds AI tools made open source developers 19% slower、2025年7月）で多くの支持を集めたコメントだ。別のユーザーはこう書いた。「Glad there’s a study that backs up empirically what many of us have experienced anecdotally.（経験則として感じていたことが、実証的なデータで裏付けられてよかった）」

2025年7月、AI安全性評価機関のMETRが発表した研究が開発者コミュニティを揺さぶった。経験豊富な開発者16人にAIツールを使わせたところ、使わない場合より19%遅くなったというランダム化比較試験（RCT）の結果だ。しかも開発者たちは「速くなっている」と信じていた。

METR研究の概要：RCTが明かした数字

METRはAIモデルの安全性・能力評価を専門とする独立研究機関だ。2025年2月から6月にかけて実施したこの研究は、業界では珍しいランダム化比較試験（RCT）の形式をとっている。

研究設計の骨格：

項目	詳細
参加者	経験豊富な開発者16人
タスク数	246件の実際のIssue
対象リポジトリ	平均2.2万スター・100万行超のOSS
開発者経験	平均5年以上の当該リポジトリへの貢献歴
使用ツール	Cursor Pro + Claude 3.5/3.7 Sonnet
1タスク平均時間	約2時間

各Issueはランダムに「AIあり」「AIなし」のどちらかに割り当てられ、同じ開発者が両条件でタスクをこなした。「AIあり」条件では主にCursor ProとClaude 3.5/3.7 Sonnetが使われた。

結果は明確だった。AIツール使用時の完了時間は非使用時より19%長い（信頼区間：+2%〜+39%）。統計的に有意なスローダウンだ。

出典: METR研究ブログ（2025年7月10日）

知覚と現実の39ポイントギャップ

この研究で最も衝撃的なのは、スローダウンの事実ではなく、開発者が気づいていなかったという点だ。

• 研究開始前の予測：「AIで24%速くなる」
• 研究終了後の実感：「AIで20%速くなった」
• 実際の測定値：「AIで19%遅くなった」

予測と実態の差は43ポイント。開発者は「速くなっている」と感じながら、実際には遅くなっていた。この知覚と現実のギャップは、AIツールの評価を個人の体感に頼ることの危険性を示している。

なぜ経験豊富な開発者は遅くなるのか

METR研究とその後の分析が特定した主因は4つだ。

1. コンテキストスイッチングのコスト

コーディングからプロンプト作成へ、AIの出力確認へ、修正判断へ。この一連の切り替えが認知コストを生む。複雑な問題への集中が毎回リセットされ、取り戻すのに時間がかかる。

2. コードクリーンアップの負担

AI提案の採用率は44%未満だった。つまり半数以上の提案を確認・評価・却下するプロセスが必要だ。熟知したコードベースなら、自分で書く方が最初から正確で速い場合がある。

3. 熟知コードベースでの過剰依存

研究参加者は平均5年以上、100万行超のコードを知り尽くした開発者だ。そのレベルになると、自分の頭の中にすでに正しい解がある。AIを経由することが「迂回路」になる。

4. 委任できないタスクの排除

研究の途中で、参加者の30〜50%が「AIなしでやりたくないタスクは最初から除外した」と報告した。AIが必要な難しいタスクほど測定から外れていた可能性があり、スローダウン効果が過大推計された可能性も否定できない（後述）。

Augment Codeの分析（出典: Augment Code Guide）によると、AIの最大の問題は「コード断片しか見えない」点だ。アーキテクチャ全体を把握していないAIが生成したコードは、局所的には動くが設計の一貫性を欠く場合がある。経験豊富な開発者はその「ズレ」を感じ取り、修正に時間を割く。

2026年2月：METRが自ら研究設計を更新

2026年2月、METRは「研究設計を変更する」という異例の発表をした（出典: METR Blog）。理由は3点だ。

1. 参加者バイアスの深刻化
「AIなし条件」に協力する開発者の確保が困難になった。時給50ドルを提示しても、「業務の50%をAIなしでやるのは無理」と断る開発者が増加した。研究から外れる開発者ほど「AIへの依存度が高い」つまり「AIで最も恩恵を得ている」層だった可能性が高い。

2. タスク選択バイアス
参加者の30〜50%が意図的に「AIなしではやりたくないタスク」を除外していた。AI活用で最も効果の高いタスクが測定から抜けていた。

3. 最新モデルへの非対応
研究期間（2025年2月〜6月）以降、Claude SonnetやGemini等のモデルは大幅に性能向上している。初期世代モデルでの結果が現在に直接適用できるわけではない。

METRの現在の立場：「2026年初頭の開発者は、早期2025年の推計よりAIツールから恩恵を受けている可能性が高い。」

つまりMETR自身が「19%スローダウン」という数字の過大評価を認め、最新状況では恩恵がある方向に修正している。

「AIが効く場面」と「効かない場面」

研究群を横断して見ると、AIが高いROIをもたらす条件と低い条件が浮かび上がる。

AIが効く場面（高ROI）

• 未知のコードベース・言語：ゼロから学ぶコストをAIが削減
• テスト生成：ボイラープレートコードが多く、AIが正確に処理できる
• ドキュメント作成：構造化された記述はAIの得意領域
• アイデア探索フェーズ：複数の実装案を素早く試したい時
• 初学者・ジュニア開発者：経験の浅い領域ではAIが補完役として機能する

AIが効きにくい場面（低ROI）

• 5年以上熟知したコードの改修：自分の頭の中に答えがある
• アーキテクチャ設計の核心部分：全体把握が必要でAIの文脈窓に収まらない
• 微妙なバグ修正：深いシステム理解が必要な箇所はAIの提案が的外れになりやすい

GitHub Copilot自体の調査（GitHub Blog、2025年）では、JavaScript開発者がCopilot使用時にタスク完了が55%速くなったという結果もある。ただしこれは「未知のタスク」「比較的単純な実装」が中心で、METRが測定した「5年以上のOSSプロジェクトの複雑なIssue修正」とは異なる。どちらが正しいかではなく、測定対象が違うと理解すべきだ。

開発者への実践的示唆

METRの研究とその後の2026年知見から、現場の開発者が取り入れられるアドバイスを整理する。

1. AIの採用率を意識する
自分のAI提案採用率が50%を下回っているなら、プロンプトの質か、そもそもAIを使う場面が最適かを見直す必要がある。確認・修正コストが積み重なっていないか数値で把握する。

2. 「詳細なコンテキスト渡し」が差を生む
Anthropicの2026 Agentic Coding Trends Reportでは、シニア開発者ほどAIへの委任前に「目標・代替案・手順」を詳細に示していると報告している。AIに任せる前に、自分が何を求めているか明文化することが品質を左右する。

3. テスト基盤を先に作る
AI生成コードは「局所的には動くが全体の設計と合わない」場合がある。堅固なCI/CDとテストカバレッジがあれば、AIの誤りを自動検出できる。ガバナンスなきAI委任は生産性を下げる。

4. 熟知コードでは体感を疑う
METR研究が示した最大の教訓は「体感は信頼できない」だ。長年触ってきたコードのAI支援では、「速くなっている感覚」に惑わされず、実際の作業時間を計測する習慣が重要になる。

まとめ：データが示す「使い方の問題」

METR研究の核心メッセージは「AIツールが悪い」ではなく、「使い方と文脈次第で全く異なる結果になる」だ。

経験豊富な開発者が19%遅くなったというデータは記録された事実だが、METRが2026年2月に認めたように、その数字は選択バイアスを含んでおり、最新モデルや現在のワークフローに直接適用できるわけではない。同時にGitHub Copilotが特定条件で55%の高速化を示したことも事実だ。

どちらか一方だけを信じるのは間違いだ。AIコーディングツールは「銀の弾丸」でも「生産性の敵」でもない。自分の知識・コードベースの成熟度・タスクの種類に応じて、正しく使い分ける道具だ。

---

関連記事

• AIエージェント時代の開発者役割変化
• Claude Code vs GitHub Copilot：現場での比較
• バイブコーディング完全ガイド2026
• AIコーディングエージェント比較2026

---

本記事に記載のデータは執筆時点（2026年5月）の公開情報に基づく。METR研究・各社調査の結果は手法・対象・時期により異なり、特定の環境での結果を保証するものではない。AIツールの採用判断は各自の環境・チーム状況を考慮した上で行うこと。