ポイント3行
- バイブコーディングへの批判は正当だが、問題の本質は「AIを使うこと」ではなく「仕様もテストも書かずにAIに丸投げすること」にある
- METR研究の「19%遅くなった」は特殊な条件下の結果であり、その後のフォローアップでは研究デザイン自体の課題が認められている
- 批判をすべて踏まえた上での正解は「AIを使わない」ではなく「AIを正しく使う」こと
バイブコーディングに対する不安、めちゃくちゃわかる
2025年2月、OpenAIの共同創設者であるアンドレイ・カーパシーが「バイブコーディング」という言葉を生み出した。「コードの存在を忘れて、ノリに身を任せる」という開発スタイルを描写したこの言葉は、瞬く間にネット上で大論争を巻き起こした。コリンズ英語辞典の2025年「今年の言葉」にも選ばれるほどの社会現象になっている。
そして当然のように、批判も山ほど出てきた。
「AI生成コードの40〜62%にセキュリティ欠陥がある」「GitClearの2億行分析でコードの書き直し率が41%増加した」「CTO 18人中16人がAI生成コードで本番障害を経験した」——こうした数字を見せられたら、「やっぱりAIにコードを書かせるのは危険だ」と思うのは自然な反応だと思う。
ただ、ここで一歩立ち止まって考えてほしい。これらの問題は本当に「バイブコーディングそのもの」の問題なのか、それとも「バイブコーディングの間違った使い方」の問題なのか。結論から言うと、自分はいろいろ調べた上で後者だと考えている。
そもそも「バイブコーディング」の定義がブレまくっている
議論がかみ合わない最大の原因は、「バイブコーディング」という言葉の定義がブレまくっていることだと思う。
カーパシー本人がXに投稿した元の文章を読むと、彼が描写していたのは「コードを一切理解せずに、AIの出力を全部受け入れて、エラーが出たらそのまま貼り付けて直してもらう」という開発スタイルだった。本人も「週末の使い捨てプロジェクトには悪くない」と書いていたくらいで、プロの開発現場にそのまま持ち込むことは想定していなかった。
ところが、この言葉が広まるにつれて「AIをコーディングに使うこと」全般がバイブコーディングと呼ばれるようになってしまった。ここに大きな混同がある。
Djangoの共同作成者であるサイモン・ウィリソンは、この区別をはっきりさせている。彼の考え方はシンプルで、「たとえLLMがコードを全部書いたとしても、開発者がレビューして、テストして、理解したなら、それはバイブコーディングじゃない」というものだ。スタンフォード大学のアンドリュー・ングも「バイブコーディングという名前は不幸だ。多くの人に『雰囲気でやればいい』と誤解させている」と指摘している。
つまり、「AIにコードを書かせること」と「AIが書いたコードを理解せずに出荷すること」は、まったく別の行為だということだ。バイブコーディングの批判記事の多くが本当に批判しているのは後者であって、前者ではない。
「天国から地獄」体験談、失敗パターンはみんな同じ
バイブコーディングで「地獄を見た」という体験談はネット上にたくさんあるけど、よく読むと失敗のパターンは驚くほど共通している。
ある開発者は「最初の1週間は天国、その後は地獄だった」と報告している。別の開発者は「本番環境のコードの3分の1以上が重複していた」と書いている。また別の事例では「テストはもちろん存在しない」とはっきり書かれていた。
これらの体験談を注意深く読むと、全員に共通しているのは仕様もテストも書かずに「○○を作って」とAIに丸投げしていたということだ。
これって、設計図なしで家を建てておいて「大工が悪い」と言っているようなものだと思う。どんなに腕のいい大工でも、設計図がなければ依頼者の頭の中にある完成イメージを再現できない。そして建築基準の検査を省略すれば、欠陥住宅ができあがるのは当然の話だ。
「新機能を追加するたびにデグレが頻発した」という問題は、自動テストがあれば即座に検出できた。「同じテキスト処理の関数が15ファイルに散在していた」という問題は、仕様書にアーキテクチャの方針を書いておけば防げた。テストが存在しないコードベースが崩壊するのは、AIが書いたかどうかに関係なく、ソフトウェア開発の世界では当たり前のことだ。
つまり「天国から地獄」の体験談が示しているのは、バイブコーディングの限界ではなく、ソフトウェア開発の基本原則を省略したときに何が起きるかということだと思う。AIがコードを書くスピードが速いぶん、基本原則を省略したときの破綻も速い。それだけの話だ。
METR研究の「19%遅くなった」をちゃんと読み解く
バイブコーディング批判で最も引用される研究が、METR（AI安全性研究機関）の「AIで開発者が19%遅くなった」という2025年7月の研究だ。インパクトのある数字だし、「ほら見ろ、AIは役に立たないじゃないか」と言いたくなる気持ちはわかる。
でも、この研究にはかなり特殊な条件があった。
まず、対象になったのは大規模オープンソースリポジトリに平均5年以上、1,500回以上コミットしている熟練開発者わずか16名だ。全員が自分が何年も触り続けてきたコードベースで作業している。使用ツールは2025年初頭時点のモデル（具体的にはCursor ProとClaude 3.5/3.7 Sonnet）だった。
例えるなら、自分の家の間取りを完璧に知り尽くしている人に「カーナビを使って自分の家まで帰ってください」と頼んだようなものだ。そりゃカーナビの設定時間ぶん遅くなるに決まっている。
そして2026年2月に公開されたフォローアップでは、METR自身が研究デザインの課題を認めている。新しい実験では参加者の多くが「AIなしで作業するのは嫌だ」としてAI禁止タスクの提出を避ける傾向があり、選択バイアスが発生していた。ある参加者は「AIを使わずに作業するのは、ウーバーに慣れた後に歩いて街を横断するようなものだ」と表現している。
METRのフォローアップでは、元の研究の参加者サブセットでは18%の速度向上が示唆されたものの、METR自身が「このデータは選択バイアスにより信頼性が低い」と結論づけている。つまり、19%遅くなったという結果も、18%速くなったという結果も、そのまま鵜呑みにはできないということだ。
重要なのは、この研究が示しているのは「自分が何年も深く関わってきたコードベースでは、AI導入の恩恵が限定的かもしれない」ということであって、「AIはコーディングに役立たない」という結論ではないということだ。新しいプロジェクトや不慣れなコードベースでの効果は、この研究の射程外にある。
でも、数字はこっちも見てほしい
批判的な記事が多く出回っている一方で、あまり一緒に紹介されないデータもある。
業界全体の採用状況
Stack Overflow Developer Survey 2025によると、開発者の84%がAIコーディングツールを利用中または利用予定で、51%が日常的に使っている。JetBrains State of Developer Ecosystem 2025では85%が定期利用と回答している。DXが13万5千人の開発者を分析した結果では、週あたり平均3.6時間の時間節約が報告されていて、5人に1人が週8時間以上の節約を実感しているという。
もしバイブコーディングが「使えない」なら、84%の開発者が全員だまされているのだろうか。さすがにそれは考えにくいと思う。
エンタープライズの実績
Spotifyは2026年2月10日のQ4決算説明会で、共同CEOのグスタフ・セーデルストレームが「最も経験豊富なエンジニアたちは2025年12月以来、コードを1行も手書きしていない」と発言した。社内システム「ホンク」（Claude Code基盤）を通じてSlackからバグ修正や新機能の実装ができるようになり、2025年中に50以上の新機能をリリースしている。エンジニアが朝の通勤電車の中からスマホで機能追加を指示し、オフィスに着く前に本番環境にマージできるというのだから、開発のスタイルが根本的に変わっていることがわかる。
Googleも社内コードの25%がAIアシストで書かれていると発表しており、CEOのスンダー・ピチャイは「得られるのはエンジニアリングの加速であり、置き換えではない」と明言している。GitHub Copilotのユーザー数は2,000万人を超えた。
プロダクションコードに占めるAI生成コードの比率は、2026年第1四半期時点で26.9%に達している（GitClear/ShiftMag、420万開発者の分析）。もはや「使うか使わないか」の段階ではなく、「どう使うか」の段階に入っている。
セキュリティ問題は「AIを使わない理由」じゃない
AI生成コードのセキュリティ欠陥が人間の約2.74倍——この数字は確かにインパクトがある。実際にAI生成コードが原因で個人情報が流出した事故も起きている。
しかし、冷静に考えてほしい。これらの事故に共通しているのは「セキュリティテストが存在しなかった」ということだ。ある事故のケースでは、創設者が「コードは1行も書いていない、アーキテクチャを描いただけ」と発言していて、セキュリティレビューの形跡がなかった。
ここで本質的な問いを立ててみよう。「人間が書いたコードなら、テストなしでセキュリティは担保されるのか？」答えはNOだ。SQLインジェクション、クロスサイトスクリプティング、認証バイパス——OWASPトップ10の脆弱性は、AIが登場するずっと前から人間のコードに存在し続けてきた。これらはAI固有の問題ではなく、テストとレビューが不在であることが生み出す構造的な問題だ。
むしろ、AIはセキュリティテストの生成を高速化できる側面がある。「OWASPトップ10に対応するセキュリティテストを書いて」と指示すれば、人間が見落としがちな観点も網羅的にカバーできる。GMO Flattセキュリティが「エンジニア応援プログラム for バイブコーダー」としてAI脆弱性診断エージェントを提供し始めたのは、「AIを使うな」ではなく「AIを使うなら安全に使え」という方向性を示していて、これが正しいアプローチだと思う。
つまり、セキュリティを理由にAIを拒否するのではなく、「AIと一緒にセキュリティテストも書く」のが正解だ。
「スキルが衰える」問題を歴史の文脈で考える
「AIに頼りすぎるとスキルが衰える」——直感的にはもっともに聞こえる。でも、歴史を振り返ると、同じ懸念はあらゆる技術革新のたびに繰り返されてきた。
電卓が普及したとき「暗算能力が衰える」と言われた。IDEのオートコンプリートが登場したとき「APIを覚えなくなる」と言われた。Stack Overflowが普及したとき「自分で考えなくなる」と言われた。そしてGoogle検索が当たり前になったとき「記憶力が衰える」と言われた。
これらの懸念には一定の真実が含まれていた。実際、多くの人は昔ほど暗算をしなくなった。でも、電卓が登場したことで数学が衰退したわけではない。計算という低レベルの作業から解放されたことで、むしろ高度な数学的思考に時間を使えるようになった。
ソフトウェアエンジニアリングでも同じことが起きていると思う。和田卓人氏（t-wada）が指摘しているように、バイブコーディングによって裾野が広がれば広がるほど、プロに求められる品質やインパクトは高くなる。エンジニアの価値は「コードを手打ちできること」から「何を作るべきかを定義し、品質を保証できること」にシフトしていく。これはスキルの喪失ではなく、スキルの再定義だ。
Spotifyの事例がわかりやすい。同社のエンジニアの役割は「コードを書く人」から「要件を定義し、AIの出力をレビューし、アーキテクチャを判断する人」に移行している。これを「スキルの喪失」と呼ぶか「スキルの進化」と呼ぶかは、視点の違いでしかない。
ジュニアエンジニアの育成問題
松尾研究所の報告にあった「ジュニアがバイブコーディングで実力が伸びない」という問題は、確かに重要だ。ただ、ここから導くべき結論は「ジュニアにAIを使わせるな」ではなく「ジュニアの育成方法を再設計せよ」だと思う。
仕様駆動開発のワークフローでは、ジュニアに求められるスキルは「コードを手打ちする力」ではなく「要件を明確に定義する力」と「テストで仕様を検証する力」になる。これらはソフトウェアエンジニアリングの本質的な能力であり、AIがさらに進化した10年後でも間違いなく通用するスキルだ。
むしろ、ジュニアが数百行の定型コードを手打ちする時間を「なぜこの設計なのか」「このテストケースで十分なのか」を考える時間に充てたほうが、長期的にはずっと強いエンジニアが育つ可能性がある。
カーパシーの「手書き回帰」は、バイブコーディングの否定じゃない
バイブコーディング批判の決定打として、「提唱者のカーパシー自身が全コード手書きでNanochatを作って、AIエージェントは役に立たなかったと言った」という話がよく引用される。確かにインパクトのあるエピソードだけど、「提唱者自身が否定した」と解釈するのは早計だ。
カーパシーがNanochatを手書きした理由は、それが約8,000行のフルスタックChatGPTパイプラインという、彼自身が完全に設計・理解できる規模のプロジェクトだったからだ。自分が熟知しているドメインの比較的小規模なプロジェクトでは、AIの介入がかえってオーバーヘッドになるケースがある——これはMETR研究の結果とも整合している。
重要なのは、カーパシーが次に提唱したのが「バイブコーディングをやめろ」ではなく「エージェンティックエンジニアリング」だったことだ。これは単一のAIに「ノリ」で指示するのではなく、複数のAIエージェントを計画者・検証者・最適化者として構造的にコントロールする開発スタイルのことを指している。
つまり、カーパシーは「AIを使うな」と言ったのではなく「AIの使い方を進化させろ」と言った。バイブコーディングの否定ではなく、発展的な進化だ。実際に2026年3月にはAutoresearchというプロジェクトもリリースしていて、AIエージェントが自律的にML実験を回す仕組みを公開している。AIを遠ざけるどころか、むしろもっと深く活用する方向に進んでいる。
「三大負債」には、もう処方箋がある
技術的負債・理解負債・認知負債の「三大負債」は、AI活用における構造的な課題として鋭い指摘だと思う。でも、これらの負債に対する処方箋は、すでに現場の実践から生まれている。
技術的負債 → 自動テストの徹底
GitClearが報告したコード書き直し率41%増加は、テストなしでAI生成コードをそのまま取り込んだ場合の話だ。仕様駆動のワークフローでは、テストが通らないコードはそもそもマージされない。テストが仕様を正しく反映していれば、AIが書き直そうが人間が書き直そうが、品質は仕様によって担保される。
理解負債 → インターフェース定義でレビュー範囲を限定
AI生成コードの全行を人間が理解する必要はない。仕様駆動開発では、人間がレビューするのは「インターフェース定義（メソッド名・引数・戻り値の型）」と「テストケース（何を検証するか）」だけで済む。実装の詳細はテストが検証してくれる。これによって、理解すべき範囲は実装コード全体ではなく、仕様を反映した薄いレイヤーに限定される。
認知負債 → 仕様書がシステムの地図になる
AI生成コードの量がどれだけ増えても、仕様書が存在すればシステム全体の構造は人間が把握できる。仕様書はシステムの「地図」であり、個々のコードを読まなくても全体像を理解するためのツールだ。Google Cloudのアディ・オスマニ氏が「人間のエンジニアがアーキテクチャに責任を持つこと」を強調しているのは、まさにこの仕様レベルでのコントロールの重要性を意味している。
実例：VibeOpsメソッド
トランスコスモスは、5種類のLLMによる多数決レビュー（3モデル以上の承認が必要）を組み込んだ「VibeOpsメソッド」で、従来15.5人日かかっていた案件を1.5人日で完了させた（87%削減）という成果を報告している。これは「バイブコーディングをやめる」のではなく「バイブコーディングにガードレールを付ける」というアプローチであり、三大負債への実践的な回答だと思う。
本当の敵はバイブコーディングじゃない
ここまでの議論を整理すると、バイブコーディングへの批判は大きく2つに分けられる。
正当な批判と、その対処法
| 批判 | 対処法 |
|---|---|
| セキュリティ欠陥が多い | セキュリティテストの自動生成と専門家レビュー |
| 技術的負債が蓄積する | 仕様駆動開発、自動テスト、CI/CDの徹底 |
| ジュニアのスキルが伸びない | 育成カリキュラムの再設計（要件定義・テスト設計重視） |
| コードレビューの負荷が増える | インターフェース定義レベルでのレビューに限定 |
| 本番障害が発生する | テストカバレッジの強制と段階的デプロイ |
「誤用」に対する批判（正しく使えば発生しない問題）
| 批判 | なぜ誤用の問題か |
|---|---|
| 最初は天国、その後は地獄 | 仕様もテストもなく丸投げした結果 |
| コードの3分の1が重複 | アーキテクチャ仕様を書かずにAIに任せた結果 |
| AIが「直った」と言うのに直っていない | テストがないのでAIが修正完了を検証できない |
| デグレが頻発する | 回帰テストがないので検出できない |
本当に戦うべき相手は「バイブコーディング」という手法じゃない。「仕様なし・テストなし・レビューなし」という怠惰だ。そしてこの怠惰は、AIがあろうがなかろうが、ソフトウェアを壊し続けてきた永遠の敵だ。
「使わない」は本当に選択肢なのか
2026年3月現在、開発者の84%がAIコーディングツールを利用中または利用予定。プロダクションコードに占めるAI生成コードの比率は26.9%。Spotify、Google、Microsoft、GitHubといった世界のトップテック企業が全面的に導入している。
この状況で「AIコーディングは使わない」と宣言するのは、2010年に「バージョン管理は使わない」と宣言するのに近い。技術的には可能だけど、競争力という観点ではかなり厳しい選択だと思う。
週あたり平均3.6時間の時間節約が報告されているということは、5人チームなら年間で900時間以上の差が開く計算になる。その差は時間が経つほど広がっていく一方だ。
じゃあ、具体的にどうすればいいのか
「批判はわかった、じゃあどうすればいいの？」という声が聞こえてきそうなので、今日からできる具体的なアクションを3つ紹介しておく。
1. まずは小さなタスクで試す
新規の小機能（APIエンドポイント1つ、UIコンポーネント1つ）を対象にして、次の順序で進めてみてほしい。
- 要件を自然言語で書く（箇条書き5〜10項目くらい）
- AIにインターフェース定義を作らせて、人間がレビューする
- AIにテストと実装を作らせて、テストを自動実行する
- テストがすべて通ったら完了
この体験をすれば、「AIが書いたコードを全部読まないといけない」という思い込みが変わるはずだ。全部読む必要はない。仕様とテストが正しければ、実装の詳細はテストが保証してくれる。
2. 組織としてルールを決める
AI活用のルールを個人の判断に任せるのは良くない。以下のような境界線を組織として定義しておくのがおすすめだ。
| 自由に使える領域 | 条件付きで使える領域 | 使わない領域 |
|---|---|---|
| プロトタイプやMVP | 本番システム（テストカバレッジ80%以上必須） | セキュリティレビューなしの本番デプロイ |
| 社内ツール | 顧客データを扱う機能（セキュリティテスト必須） | 医療・金融の規制対象コード（専門家レビュー必須） |
| テストコード生成 | 認証・認可ロジック（手動レビュー必須） | 暗号化・鍵管理（専門家による実装必須） |
3. データで判断する
感情や印象ではなく、データで判断しよう。機能あたりの開発時間、バグ発生率、テストカバレッジをBefore/Afterで計測して、1ヶ月後にチームで振り返る。もしデータが「使うべきではない」と示すなら、そのときに正当な根拠を持って判断すればいい。逆に「効果がある」と出たなら、安心して活用範囲を広げられる。
まとめ4行
- バイブコーディングへの批判はデータに裏付けられた真剣な問題提起であり、すべてのエンジニアが読むべき内容だ
- しかし批判の結論は「AIを使うな」ではなく「AIを正しく使え」であるべきで、仕様駆動開発やエージェンティックエンジニアリングが正しい方向性を示している
- 問題の本質は「バイブコーディング」ではなく「仕様なし・テストなし・レビューなし」という怠惰にあり、これはAIの有無に関係なくソフトウェアを壊す永遠の敵だ
- バイブコーディングを全否定するのは簡単だが、批判のすべてに目を通した上で「正しく使えば武器になる」と判断するほうが、はるかに難しく、はるかに価値がある
