「AIで開発力が19%低下」METR研究を、AIで700時間開発している非エンジニアが読んだ

METR（Model Evaluation & Threat Research）の研究（arxiv: 2507.09089）が衝撃的な結果を出した。「AIコーディングツールは経験豊富な開発者の作業時間を19%増加させる」。

自分はClaude Codeを700時間以上使って開発している。プログラミングの専門知識はない。この研究を読んで、自分の体験と照らし合わせた。

研究の要点

METRが16人の経験豊富なOSS開発者を対象に、246タスクのランダム化比較試験を実施。開発者はそれぞれ担当プロジェクトで平均5年の経験を持つ。

結果:

開発者の予測: 「AIで24%速くなる」
実測結果: 19%遅くなった（信頼区間: +2%〜+39%）
事後評価: 開発者は「20%速くなった」と感じた
原因: AIの出力確認・デバッグ・コンテキスト切り替えのコスト

衝撃的なのは43ポイントの認知ギャップ。「24%速くなるはず」と予測し、「20%速くなった」と感じ、実測では「19%遅くなった」。感覚と現実が完全にずれている。対象が「AI初心者」ではなく「経験豊富なエンジニア」だったことも重要。

非エンジニアとして見た3つの視点

1. 「書く速さ」と「正しさ」は別

自分の環境でも同じことが起きた。Claude Codeは数秒でコードを生成する。でも、生成されたコードが正しいかを確認するのに、生成時間の10倍かかることがある。

例: hookのシェルスクリプト。Claude Codeが5秒で書いた。テストしたら、特定のパターンでバイパスされた。修正に30分。

速く書けることは、速く完成することではない。

2. AIに依存するとデバッグ力が落ちる

研究が指摘する「デバッグ時間の増加」に共感する。自分はプログラミングの知識がないから、AIが書いたコードがなぜ動かないのかを自力では判断できない。

対策としてやっていること:

編集後に自動構文チェックを走らせる。AIが書いたコードの文法エラーを即座に検出
テストを大量に書く。AIが書いたコードが壊れていないか自動で検証する
危険な操作（ファイル削除、本番デプロイ等）は自動でブロック。AIの判断ミスを機械的に止める

これはAIに限った話ではない。チーム開発のCI/CDパイプラインと同じ発想だ。人間を信頼するが、機械的に検証する。 AIも同じ。

3. 非エンジニアにとっては「19%低下」どころではない

研究の対象は「既にプログラミングができるエンジニア」だ。彼らにとってAIは「補助ツール」であり、AIなしでもコードは書ける。

自分にとってAIは「唯一の手段」だ。AIなしでは1行もコードが書けない。

19%低下? 自分にとっては「100%の能力を獲得した」に等しい。

ゼロベースの人間にとって、AIコーディングツールは「下落」ではなく「参入障壁の消滅」。

自分のデータで検証する

3ヶ月のデータを振り返る:

指標	値
投資額	$600（月$200 × 3ヶ月）
自律稼働時間	700時間以上（80セッション）
作成したプロダクト	npmパッケージ2つ、ゲーム1本、Zenn Book 2冊、技術記事39本
記事の累計閲覧数	35,000+
収益	約$28（¥2,190）— 赤字$572
事故	rm -rf事故2回、git force-push 1回、無限ループ多数

研究の言う「19%低下」は自分には当てはまらない。なぜなら、比較対象がない。AIなしでは1行もコードが書けないから。

ただし、事故のデータは研究の指摘と一致する:

rm -rf事故 → AIが安全性を考慮しない（研究の「認知コスト」に該当）
無限ループ → AIが自分の失敗に気づかない（「デバッグコスト」に該当）
git force-push → AIがリスクを過小評価する

研究が正しいと思う点: AIの出力を確認するコストは、確かに大きい。自分も「AIが5秒で書いたコード」の確認に30分かかることがある。METRが言う「認知のギャップ」は、自分自身にも当てはまる。「速くなった気がする」と「本当に速くなった」は違う。

結論: この研究から何を持ち帰るか

この研究を読んで、3つのことを考えた。

1. 自分がAIで速くなったと「感じている」なら、計測したほうがいい。
METRの研究で最も重要なのは、開発者が「速くなった」と感じているのに実測では遅くなっていたという認知のギャップ。感覚に頼らず、タスクの開始時刻と終了時刻を記録するだけでも違う。

2. AIの出力を鵜呑みにしない仕組みが必要。
自動テスト、コードレビュー、構文チェック。AIが書いたコードを人間が全部読むのは現実的ではないから、機械的に品質を担保する仕組みを入れる。これはAIに限らず、チーム開発でも同じこと。

3. 非エンジニアにとっては、この研究は「AIを使うな」という意味ではない。
研究の対象は「既にプログラミングができるエンジニア」。彼らにとってAIは補助ツール。自分にとってAIは唯一の手段。参入障壁が消えたことの価値は、19%の効率低下では測れない。

参考文献:

この記事の筆者は非エンジニアがClaude Codeに$600を投じて800時間走らせた全記録をZenn Bookにまとめています。METRが「エンジニアの生産性」を測った研究なら、こちらは「非エンジニアの生存記録」です: AIに仕事を任せてみた——非エンジニアが800時間で学んだ全記録（¥800・第2章まで無料）

「どのhookを入れればいいかわからない」なら → Hook Selector（5つの質問で最適なhookセットを推薦）
「CLAUDE.mdのトークンコストが気になる」なら → Token Checkup（トークン消費パターンを診断）

📖 トークン消費に困っているなら → Claude Codeのトークン消費を半分にする——800時間の運用データから見つけた実践テクニック（¥2,500・はじめに+第1章無料）

⚠️ Opus 4.7緊急情報（2026年4月17日）
Opus 4.7のauto mode安全分類器がOpus 4.6にハードコードされている問題が発覚。3日間で23件以上のデータ損失。さらにv2.1.100以降、APIコールごとに約20,000トークンが見えない場所で追加課金されている問題も判明（#46917、GitHub上196件のリアクション）（50GB永久消失含む）。4倍のトークン消費も報告されている。対策: npx cc-safe-setup --opus47（Survival Guide / Safety Scanner）

関連の素材

明日5月22日に新刊の事例集 Claude Code Claim-Verify Handbook ($19) を発売します。道具が「成功した」「比較した」「設定された」と主張する一方で実態が乖離していた事例を GitHubの起票の集まりから130件 (本文15件+付録D 115件) 整理した本で、 14件の防衛の手順と5件の自動の点検の道具と一緒に提供しています。道具の主張と実態の乖離の検証の経路は、開発の生産性の見え方を直接の生産性の数値と整合の状態に保つ規律の土台です。試し読みのGist (約16,000字、章1の全件) はこちら。

予防 hook の集まりは cc-safe-setup (MIT、 745件以上の hook、 30,000件以上のインストール)。月額の継続の媒体 CC Safety Lab (¥500/月、 Ko-fi) は毎月の事故の整理を配信。

📚 関連の参考資料 (2026年5月28日追加)

本記事の内容と関連する整理を、公開済の素材で articulate しています。

6月15日の課金分離の決定の枠組み: Migration Playbook v2 (Gumroad、 $19) ——14日後の決定の整理、 9集積の文脈、 130件の claim-verify divergence の事例。 60秒の購入判定の道具で事前判定が可能
月次の追補の継続: CC Safety Lab Founder Membership (Ko-fi、 ¥500/月) ——5月から12月の8ヶ月の章本文 (cache_control / 副の作業者 / AGENTS.md / Pro Max / 権限 / Skills / v2.1.150 / AUP false-positive)
9集積の枠組みの英語の長編 Gist: The 9-Cluster Framework: Mapping the Structural Failure Surface of Claude Code Operator Defense ——約3,300単語、全件の集積の mechanism / symptom family / defense path の整理。 cluster 9 (Usage Policy classifier over-trigger on Opus、 25+件の起票) の対話型診断道具: 4問の質問→推奨経路の道具
750+ MIT-licensed の hooks: cc-safe-setup (GitHub) ——14日で1,127人の独立利用者、 9集積の対応の hooks の整備の累計