バイブコーディングは本当に速いのか——METR研究が突きつける「19%遅延」の逆説
2026年4月5日、Bloombergが「Vibe CodingのFOMO」を特集した。AIと会話しながらコードを書くこのスタイルは、米国の開発者の92%が日常的に利用するほど普及した。ところが同時期、独立研究機関METRが発表したデータは正反対の結論を示している——経験豊富な開発者がAIコードツールを使うと、使わない場合より19%遅くなるというものだ。
採用率の急拡大と生産性の実測値が逆方向を向いている。この矛盾をどう読むか。
Vibe Codingとは何か、なぜ今これほど広がったか
Vibe Codingという言葉は、OpenAIの共同創業者アンドレイ・カルパシーが2025年初頭に広めた概念だ。コードの細部に気を取られず、「やりたいこと」を自然言語でAIに伝えて実装を進めるスタイルを指す。
拡散の背景にはツールの成熟がある。GitHub CopilotやCursor、Claude Codeは補完精度を大幅に引き上げ、初心者でも動くコードをある程度生成できるようになった。Second Talentがまとめた統計によれば、米国の開発者の92%がAIコードツールを毎日使っており、スタートアップでは全コードの60〜80%がAI生成というケースも珍しくない。
ここまで普及すれば、「使っていない自分が遅れている」という感覚——FOMOが生まれるのは自然だ。Bloombergが特集で指摘したのはまさにこの心理で、Vibe Codingが技術選択の問題というより、スタートアップ界隈での「文化的な空気」になりつつあると分析している。
METRが出した数字の中身
問題は、この「空気」を支えるデータが揺らいでいる点だ。
AI安全研究機関METRが2026年3月に発表した研究は、オープンソースプロジェクトの実務タスクを対象に、AIコードツールを使った場合と使わない場合の作業時間を比較した。対象は経験豊富な開発者16人、246件のタスク。結果は「AIツール使用時のほうが19%時間がかかった」というものだった。
研究者たちも結果に驚いたと述べている。主な原因として挙げられたのは次の点だ。AIが生成したコードの検証に時間を取られる。意図と異なるコードが出力された場合のデバッグが煩雑になる。「AIが何かをやってくれている」という感覚が実際の進捗確認を遅らせる——いわゆる「AIへの過度な委譲」の問題だ。
ただし、この研究には重要な留保がある。サンプルは16人・246案件という限定的な規模であり、対象もオープンソースの既存コードベースへの作業に限られている。新規プロジェクト、単純な機能追加、非熟練者への効果については検証されていない。
「実感」と「実測値」がなぜずれるのか
Fortuneの報道によれば、AI生成コードへの信頼度は2025年に77%だったものが、2026年初頭には60%に低下している。生成コードに潜む微妙なバグ、セキュリティ上の問題、文脈を無視した実装——こうした経験が積み重なり、「とりあえず動くが信頼できない」というコードへの不信感が広がっている。
しかし採用率は下がっていない。むしろ上がり続けている。なぜか。
一つの解釈は、「生産性向上」を実感する場面が偏っているからだ。定型的なボイラープレート、ドキュメント生成、簡単なテスト作成——こういったタスクではAIツールは明確に速い。開発者は「速かった体験」を記憶に残しやすく、「遅かった体験」はデバッグの苦労として別の記憶に分類される。結果として「全体として速い」という主観的評価が形成される。
もう一つは、採用することのシグナル価値だ。チームやプロダクトがAIツールを活用しているという事実は、投資家や採用市場へのアピールにもなる。FOMOは個人の感情だけでなく、組織の意思決定にも影響する。
熟練者が遅くなるメカニズム
METRの研究が特に示唆するのは、「経験豊富な開発者」にこそ逆効果が出るという点だ。これは直感に反する。
説明の一つとして考えられるのは、認知的負荷の配置の問題だ。経験者はコードを読むとき、パターン認識と直感で高速に意図を把握する。AI生成コードは、このパターンに合わない書き方をすることがある。「自分なら書かないコード」を読み解くのは、空白から書くより遅い場合がある。
加えて、熟練者ほど品質基準が高い。AI生成コードを「まあ動くから良い」と通せず、自分の納得できる水準に修正しようとする。その修正コストが蓄積する。
一方、初心者はAI生成コードのパターンを「正しいもの」として学ぶため、読解の摩擦が低い。また品質への基準がまだ形成途中なため、修正コストも発生しにくい。METRの研究が経験者に絞ったものである以上、「初心者にはむしろ効果的かもしれない」という仮説は否定されていない。
信頼の問題をどう扱うか
Fortuneは「Vibe Coding時代の本当のボトルネックは信頼だ」と指摘している。この視点は重要だ。
ツールの精度が向上しても、「このコードは正しいか」を確認するコストが開発フローに残り続ける限り、生産性の上限は信頼の程度によって決まる。AI生成コードをそのままマージできる確信が持てなければ、レビューとテストの工数は減らない。
この問題の解決策として現在議論されているのは、主に三つの方向性だ。一つはAIが生成する説明の充実——コードだけでなく「なぜこう書いたか」の根拠を提示する。もう一つはテストの自動化と生成の組み合わせ——コードと同時にテストを生成し、信頼性を機械的に担保する。三つ目は、特定のリポジトリやコードスタイルに特化したファインチューニングで、「このチームの書き方に近い出力」を得る方向だ。
どれも完全な解決にはなっていないが、「生成して終わり」から「生成して検証するワークフロー」への移行が、今後の焦点になるだろう。
数字をどう使うべきか
METR研究の「19%遅延」という数字は、センセーショナルに見えるが、文脈なしに引用するには慎重さが必要だ。16人・246案件は、一般化の根拠としては薄い。対象タスクも既存コードベースへの作業に限られており、グリーンフィールド開発や軽量なスクリプト作成には別の結果が出る可能性がある。
それでもこの研究が価値を持つのは、「Vibe Codingは必ず速い」という前提に対して、条件付きの反証を初めて定量的に提示したからだ。採用率の高さや個人の体感は証拠にならない。測定し、検証し、文脈に合わせて評価する——ソフトウェアエンジニアリングの基本的な態度を、AIツール自体にも適用することが求められている。
ツールが普及するほど、「みんな使っているから」という理由での採用判断が増える。だが生産性ツールの本質的な問いは変わらない。どのタスクに、どの開発者が、どのワークフローで使うと効果があるか。その答えは一律ではなく、チームと文脈によって異なる。
Sources: