AIコーディングツールで開発は速くなるのか?2026年最新研究が示す意外な結果
「AIを使えば開発が速くなる」——この前提を揺るがす研究が、HackerNewsで400近くのポイントを集めて大きな話題になっています。
AI安全研究機関のMETRが2025年7月に公開した論文では、経験豊富な開発者16名を対象に厳密なランダム化比較試験を実施したところ、AIコーディングツールを使ったグループは使わなかったグループより19%遅くタスクを完了していたことが判明しました。そして最も驚くべきことは、その開発者たちは「AIのおかげで20%速くなった」と感じていた点です。
この記事では、研究の詳細を読み解きながら、「なぜ速くなったと感じるのに実際には遅いのか」「どういう条件ではAIが本当に効くのか」を整理していきます。AIコーディングツールを日常的に使うエンジニアにとって、自分の生産性を正しく評価するための視点が得られるはずです。
—
まず研究の設計を正確に理解することが重要です。METR(Model Evaluation and Threat Research)はAI安全性を専門とする研究機関で、今回の研究は単なるアンケート調査ではなく、ランダム化比較試験(RCT)という医療臨床試験と同等の厳密な手法で行われました。
研究の基本設計
| 項目 | 内容 |
|---|---|
| 参加者 | 経験豊富なオープンソース開発者 16名 |
| 対象リポジトリ | 平均スター数22,000以上、コード100万行以上の大規模OSS |
| タスク数 | 246件(バグ修正・機能追加・リファクタリング) |
| 平均タスク所要時間 | 約2時間 |
| 使用ツール | Cursor Pro(Claudeモデル) |
| 報酬 | 時給150ドル |
| 測定方法 | セッション録画+実装時間の自己記録 |
各タスクは「AIツール使用可」または「使用禁止」にランダムに割り当てられ、参加者は自分が書いたコードの提出するリポジトリの実際の課題リストを提供しました。つまり、架空のプロジェクトではなく本番に近い実務タスクで測定された点が重要です。
結果:-19%という数字の意味
AIツール使用グループは非使用グループより19%多くの時間がかかった——この数字は、単純に「AIが邪魔した」という話ではありません。
なぜ遅くなったかについて、研究では以下の要因が挙げられています。
- AI出力のレビュー時間:AIの提案コードを一行一行確認し、問題がないか精査する作業が発生した
- 低い採用率:AIが提案したコードのうち使えないと判断したものを除外・修正する作業コスト
- 大幅な修正コスト:AI生成コードをそのまま使えず、大きな修正を加えるケースが頻発した
- コンテキスト整合性:大規模コードベースの複雑な依存関係をAIに正しく理解させるためのプロンプト作業
ベテラン開発者が大規模・複雑なコードベースで作業する場合、「AIが70%まで書いてくれるが、残り30%を整合させる作業が最初から自分で書くより遅い」という構造が浮かび上がります。
知覚と実測の乖離
もう一つの重要な発見が知覚と実測のギャップです。
| タイミング | 開発者の主観的予測 | 実測値 |
|---|---|---|
| タスク開始前 | 「AIで24%速くなるはず」 | — |
| タスク完了後 | 「AIで20%速くなった(体感)」 | 実際は19%遅かった |
開始前も完了後も「速くなる/なった」と感じているにもかかわらず、実際には逆の結果でした。研究者らはこれを生産性プラシーボと表現しています。
なぜ人は遅くなっているのに速くなったと感じるのか。有力な説明の一つは認知的苦労の軽減です。「自分でゼロから考える苦労」がなくなり、AIのコードを読んでレビューする作業に置き換わることで、主観的な疲労が減り「楽になった=速くなった」と脳が誤認する可能性があります。
2026年2月の追報:状況は変わりつつある
METRは2026年2月に実験設計の変更を発表し、最新データも公開しました。
新しいコホート(800件以上のタスク、57名の開発者)では、AIによる遅延は-4%(信頼区間: -15%〜+9%)まで縮小しています。つまり「統計的に有意な遅延」とは言えない水準になっています。
同時に研究上の課題も明らかになりました。
- 招待した開発者の30〜50%がAIなし条件での参加を拒否した(「AIなしで作業したくない」という理由)
- エージェント型AIツールはバックグラウンドで作業するため、実作業時間の正確な計測が困難になった
- 開発者によっては「AIが2時間で終わらせられるタスクに20時間かける気にならない」という発言もあった
METRはこれらの問題を踏まえ、タスク単位のランダム化から開発者単位のランダム化への移行を検討しています。つまり「研究自体もまだ発展途上」という状況です。
他の研究は何を言っているか——メタ的に見る
METR研究だけが特異なわけではありません。複数の研究を並べると、条件による大きな差が見えてきます。
生産性が上がるという研究
GitHubの自社研究(2023年)では、Copilotを使った開発者は使わなかったグループより55%速くタスクを完了したと報告しています。ただしこの研究のタスクは「新規のWebサーバー実装」というグリーンフィールド(既存依存なし)の課題でした。
また複数企業を対象にした研究では、経験の浅い開発者が最大35〜39%の速度向上を示した一方、ベテランは8〜16%の向上にとどまっていました。
コード品質に関するデータ
GitClearは2億1,100万行のコード変更を分析し(2020〜2024年)、以下の傾向を確認しています。
| 指標 | 2021年(AI普及前) | 2024年(AI普及後) |
|---|---|---|
| コードチャーン率(2週間以内の修正) | 3.1% | 5.7%〜7.9% |
| リファクタリング比率 | 約25% | 約10%未満 |
| コードクローン(コピペ)比率 | 8.3% | 12.3% |
速度が上がった分、長期的なコード品質に問題が蓄積しやすくなっているという見方もできます。
「効く条件」と「効かない条件」を整理する
ここまでの研究を横断的に見ると、AIコーディングツールの効果はタスクの性質と開発者の習熟度によって大きく異なることが分かります。
| 条件 | 生産性への影響 | 理由 |
|---|---|---|
| グリーンフィールド開発(新規実装) | 大きく向上しやすい | コンテキスト依存が少ない、ボイラープレートが多い |
| 経験の浅い開発者のタスク | 向上しやすい | コードを書くより学習・調査コストが主ボトルネック |
| ドキュメント・テストコード生成 | 向上しやすい | 正確さより量が求められるタスク |
| 大規模レガシーコードベースの修正 | 低下しやすい | コンテキスト把握にプロンプトコストがかかる |
| ベテランの複雑な設計・アーキテクチャ | 低下しやすい | AIの70%完成品の「残り30%調整」がボトルネック |
| 厳密なコードレビュー基準のOSS | 低下しやすい | 提案されたコードの修正・レビューコストが高い |
つまり「AIコーディングツールは速くなるか?」という問いに対する正直な答えは、「タスクによる」です。
開発者が今すぐ実践できる3つの視点
研究から得られる実践的な示唆として、以下の3点を提案します。
1. 自分の「感じ方」を測定値で補正する
METR研究が示した最大の教訓は、主観的な快適さは生産性の正確な指標ではないという点です。タスクの所要時間をAI使用前後で実際に記録し、どのタスク種別でどれだけ変わるかを自分のデータで確認してみましょう。
2. タスクの性質でツールの使い方を変える
新規実装・ドキュメント生成・テスト自動化ではAIを積極的に使い、複雑なレガシーコードのデバッグや設計判断では「AIに聞く前に自分で考える」スイッチを持つことが重要です。ツールを全自動で使うか、提案のトリガーとして使うかの使い分けが鍵になります。
3. 「AIが書いたコードのレビュー負債」を意識する
GitClearのデータが示すように、AIが生成したコードは短期的には量産できても、チャーン率(修正頻度)が上がる傾向があります。速度と品質のトレードオフを意識し、特にチームで保守するコードにおいては「AIが書いたコードほど丁寧にレビューする」という習慣が必要です。
まとめ
METR研究が示したのは「AIコーディングツールは役に立たない」という結論ではありません。それは「測定しなければ分からない」という戒めです。
経験豊富な開発者が大規模OSSで作業するという特定の条件下では19%の遅延が確認された。一方で2026年の追報では-4%(統計的有意差なし)まで縮小し、新規開発やジュニア開発者のタスクでは大きな向上を示す研究も複数あります。
AIコーディングツールへの投資判断をする際は、「みんなが使っているから」「使った感じが良いから」という理由ではなく、自分の実際のタスク構成・コードベースの特性・チームの習熟度に基づいた評価が必要です。
正直にお伝えすると、この領域の研究はまだ発展途上で、METRも自ら「実験設計を変更する」と認めています。2026年中に、より信頼性の高いデータが出てくることを期待しつつ、今できることは自分の環境で小さく測定することではないでしょうか。
あわせて読みたい
- LNAI入門|AIコーディングツール設定を1ファイルで統一する方法 — AIコーディングツールの設定を統一管理するLNAIの使い方
- Vite 8.0正式リリース|Rust製Rolldownで本番ビルド最大87%削減 — フロントエンド開発を高速化するVite 8.0の技術詳細
参考・出典
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity — METR(参照日: 2026-03-13)
- We are Changing our Developer Productivity Experiment Design — METR(参照日: 2026-03-13)
- Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity (論文) — arXiv(参照日: 2026-03-13)
- Research: quantifying GitHub Copilot’s impact on developer productivity and happiness — GitHub Blog(参照日: 2026-03-13)
- AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones — GitClear(参照日: 2026-03-13)
- Unpacking METR’s findings: Does AI slow developers down? — DX(参照日: 2026-03-13)
—
AIエージェントの設計・構築に関する体系的な知識は、AIエージェント構築完全ガイドでまとめています。
あわせて読みたい:
- AIエージェント構築ツール徹底比較 — Dify / n8n / LangChainの選び方
- AIエージェント導入戦略ガイド — 失敗しない導入プロセスの全体像
—
この記事はAIgent Lab編集部がお届けしました。
あわせて読みたい: Windsurf Wave 13のArena Mode