Vibe Codingの信頼が崩壊した3つの理由と今日からできる対策

「まずClaude Codeにやらせてみよう」

いつからか、それが僕の口癖になっていた。プロンプトを打ち込んで、コードが画面に流れていくのをぼんやり眺める。便利だし、実際に動くものがどんどんできあがる。でもどこかに「これ、本当に大丈夫なのか」という感覚がずっとあった。

その違和感の正体が、最近のデータではっきり見えてきた。

米国開発者の**92%が日常的にAIコーディングツールを使っている。にもかかわらず、AI生成コードへの信頼度は過去2年で77%から60%**に急落している。使えば使うほど信頼が下がる。この逆説が、いまVibe Codingをめぐる最大のテーマになっている。

以前『Vibe Coding入門』や『Agentic Engineering』の記事で、AIコーディングの可能性や進化の方向性を書いた。今回はその「影」の側面に焦点を当てたい。AIコーディングを使い始めた人、すでに使っている人が「なぜ不安を感じるのか」を理解し、安全な使い方を持ち帰れる記事を目指す。

そもそもVibe Codingとは何か

なぜこんな逆説が生まれたのか。まずVibe Codingという言葉の定義から確認しておきたい。

Vibe Codingとは、AIに自然言語でタスクを伝え、生成されたコードをそのまま受け入れる開発スタイルのこと。

2025年2月6日、OpenAI共同創業者のAndrej KarpathyがXで提唱した。彼の言葉を借りると「vibeに身を任せ、指数関数的な進化を受け入れ、コードの存在すら忘れる」。この言葉がバズり、Merriam-Websterが2025年3月にスラングとして掲載。Collins英語辞書の「今年の単語」にまで選ばれた。たった1年で一般語化したスピードには正直驚かされる。

ただし、ここで押さえておきたいポイントがある。

Karpathyはもともと、プロトタイプや週末プロジェクト向けを想定していた。それが企業の本番環境へ転用されたことで問題が起きている。元Google Chrome DevEx責任者のAddy Osmaniはこう区別している。「Vibe Codingは理解なき受け入れ。AI支援エンジニアリングは深い関与を必要とする。両者はまったく違う」と。

僕自身、ClineやClaude Codeを使い始めたとき、最初は「これは試作品だから」という意識があった。AIがファイルを次々に書き換えていく光景は衝撃的で、「すごい時代が来た」と素直に感じた。でもいつのまにか、本番に近いものを作るときも同じ感覚でやっていた。試作品と本番の境界線があいまいになっていく——これがVibe Codingの罠だと感じている。

信頼崩壊の理由1：「動く」けど「安全じゃない」コード

Vibe Codingが何かはわかった。では、なぜこれほど広まりながらも信頼が崩壊しているのか。

ある分析レポートによると、AI生成コードの61%は機能的に正確だが、セキュリティ面で安全なのは約10.5%にとどまるという。

つまり「動くけど危ない」コードが大量生産されている。見た目は問題なく動くのに、裏側にセキュリティの穴が空いている状態。これが信頼崩壊の正体の一つになる。

2025年12月、セキュリティ企業Tenzaiが5つのAIコーディングツール（Claude Code、Cursor、Windsurf、Replit、Devin）を対象にテストを実施した。15個のアプリを生成させ、セキュリティ脆弱性を検証したところ、結果は衝撃的だった。

  • 5ツール合計で69の脆弱性を検出（うち6件が重大）
  • SSRF（サーバーサイドリクエストフォージェリ）は全ツールで共通して発生
  • CSRF対策が未実装のアプリも全ツールで確認された
  • マイナスの金額を注文に入力しても、5ツール中4つが検証せずに通した

認証やビジネスロジックの欠陥など、AIが見落としがちな脆弱性が目立つ結果だった。

Vibe Codingに関連したCVE（共通脆弱性識別子）も増加傾向にあるとされ、2026年に入ってから報告件数が加速しているという指摘がある。

実際の被害も出ている。CNBCの報道によると、2026年3月5日、AmazonでGen-AI支援のコード変更が適切な承認なしに本番展開され、U.S.注文量が99%減少。約630万件の注文が消失した。

Clineがファイルを次々に書き換えていくのを初めて見たとき、僕は爽快感を覚えた。でもそのとき、セキュリティチェックを一度もしていなかった。Amazonの事件を読んで、正直ゾッとした。規模は全然違うけれど、構造は同じだ。「動いているから大丈夫」と思い込んでいた点は、僕も変わらない。

信頼崩壊の理由2：ステップを重ねるほど壊れていく「複合エラー問題」

セキュリティ問題は「1回のミス」では済まない。複数のステップを重ねるほど、リスクが掛け算で膨らんでいく。これが「複合エラー問題」だ。

たとえば、AIが各ステップで90%の正解率を出すとする。かなり優秀に聞こえるだろう。でも5ステップのワークフローでは成功率が59%に下がる。10ステップでは35%未満だ（0.9の10乗で約34.9%）。

3ステップでは問題なく動いたのに、10ステップで突然壊れる。エラーは打ち消し合わず、掛け算で悪化していく。

このことを裏付けるデータもある。CodeRabbitが2025年12月にオープンソースGitHubの470件のPR（プルリクエスト）を分析した結果がこうだ。

  • AI共著PRは人間PRと比較して主要な問題が1.7倍
  • セキュリティ脆弱性が2.74倍
  • パフォーマンス問題（過剰I/Oなど）は約8倍

さらに興味深いのが、2025年7月のMETR研究（16名の開発者、246タスク）の結果だ。開発者たちはAIツールを使って「20%速くなった」と感じていた。しかし実際には19%遅くなっていた。「速くなった気がする」という認知の歪みが、危険の発見を遅らせている。

僕は以前から80:20の法則を体感してきた。コードの最初の80%はAIがあっという間に書いてくれる。でも残りの20%——セキュリティ、エッジケース、レビュー——に8割のパワーが要る。この法則がAIコーディングにもそのまま当てはまると気づいたとき、「速い」だけでは全然足りないと思った。

METR研究の「速くなったと思い込んでいたが実は遅くなっていた」という結果を読んで、自分も同じ錯覚をしているかもしれないと感じた。ビルドが通ると達成感がある。でもその裏に積み上がっているリスクが、僕には見えていなかったのかもしれない。

信頼崩壊の理由3：コードレビューが追いつかない構造問題

チーム会議でコードレビューを行う開発者たちの協働シーン Photo by airfocus on Unsplash

エラーが積み重なるのに、なぜそれを防ぐコードレビューが機能しないのか。実はレビューの仕組み自体が、AI時代に対応できていない。

AIがコードを書く速度は劇的に上がった。一方、レビューの速度は上がっていない。むしろ量が増えた分、レビューはより困難になっている。AWSは2026年に「レビュー能力こそが納品のボトルネックだ」と警告した。ある匿名CTOはこう証言している。「Vibe Codingの最も危険な特性は、完璧に動いているように見えて突然壊滅的に失敗するコードだ」。

技術的負債も積み上がっている。GitClearの分析によると、コード重複率は2021年の8.3%から2024年には12.3%へと48%増加。リファクタリング活動は25%から10%へと60%も減少した。コードが増えるのに、整理する人がいない状態だ。

皮肉な事例もある。Fortuneが報じたところによると、Claude Code自体がパッケージングエラーにより自社のソースコードを漏洩した。AIコーディングツールが自らセキュリティ問題を引き起こすという、なんとも象徴的な出来事だった。Qodo CEOのItamar Friedmanはこの件についてコメントしている。

リベ大の両学長がClaude Codeを推薦しているのを見たとき、「すごいことが起きている」と感じた。エンジニア以外の人にもAIコーディングが広がっている兆しだ。でも同時に思ったのは、レビューできる人がいないまま利用者だけが増えたら、問題の規模も一緒に大きくなるということ。一般社会への普及と信頼問題は、切り離して考えられない。

批判的な見方も知っておく

3つの構造的問題が見えてきた。この現実に対して、業界の有識者はどう反応しているのか。批判的な声も整理しておきたい。

Google Brain共同創業者のAndrew Ngは、「適切なAI支援開発には深い判断力が必要だ」と懐疑的なスタンスを示している。AIに丸投げする姿勢そのものへの批判だ。

Arshia Heraviの指摘も鋭い。「シニアエンジニアの価値は今や、生成されたコードを素早く批判的に読む能力にある。500行のAI生成コードから10分で構造的問題を2つ特定できるスキルが求められる」。ツールが変わったのではなく、求められる能力の種類が変わったということだろう。

METR研究が示した「熟練開発者ほど遅くなる」という逆説も注目に値する。自分のリポジトリに精通しているほど、AIの提案との認知的なすり合わせがボトルネックになり、結果として作業時間が伸びてしまう。慣れているほど遅くなるという皮肉が、「Vibe Codingは誰でも速くなる」という誤解を覆している。

Salesforce顧問のVicki Abrahamは「2026年が技術負債の年だ。負債の上に負債を積み重ねている」と警告した。Vibe Codingはプロトタイプ向けであり、本番環境に使うべきではない——という反省論が業界で広がりつつある。

ただし、「だから使うな」で終わらせるのは建設的じゃないと僕は思う。正直、これらの批判を読んで、自分が毎日やっていることへの向き合い方が変わった。ツールを疑うのではなく、自分の使い方を疑う。そういう方向への転換だった。

Vibe Codingの「次」に来るもの

批判が出るほど深刻な問題である一方で、業界は手をこまねいているわけではない。信頼崩壊への応答として、いくつかの動きが進んでいる。

注目すべきは2つの方向性だ。

  • Policy-as-Code：セキュリティポリシーをコードとして自動実行する仕組み
  • Objective-Validation Protocol：AIの出力を独立したエージェントが検証するアーキテクチャ

Vibe Codingツール市場は2026年時点で47億ドル規模。2027年には123億ドル（年成長率38%）に達するとの予測がある。市場は縮小するどころか、ガバナンスとセットで成長していく方向にある。

一方、エンジニアリングリーダーの54%が新人採用の削減を予定しているという調査もある。これはツールが仕事を奪うという話ではなく、品質管理能力を持つ人材の価値が上がるという文脈で捉えるべきだと思う。

Cursor、Windsurf、Kiroと群雄割拠のコーディングエージェントが切磋琢磨している。僕は、次の勝者は「生産性」ではなく「信頼性」を武器にするツールだと感じている。速さの競争は一巡した。これからは「安全に使える」ことが差別化のポイントになるんじゃないだろうか。

安全にAIコーディングを使うための5つのステップ

セキュリティテストツールを使用して開発中のラップトップ画面 Photo by Jefferson Santos on Unsplash

業界の変化を待つだけでなく、個人でも今日から始められる対策がある。「理解なき受け入れ」を脱するための5つのステップを整理した。

1. セキュリティスキャナーを導入する

まずはこれだ。無料で始められるツールがいくつかある。

  • Semgrep：オープンソースで無料。ルールベースの静的解析ツール
  • Snyk：VSCode拡張あり。依存パッケージの脆弱性も検出
  • Gitleaks：秘密鍵やAPIキーの漏洩を検出

2. 「AI生成コードは必ず1人が通読する」ルールを決める

コードレビューを省略しない。500行のAI生成コードでも、10分あれば構造的な問題を探せる。完璧に読む必要はない。「認証」「金額処理」「外部API呼び出し」の3箇所だけでも目を通す習慣をつけたい。

3. 重要な処理は人間が書く領域と切り分ける

認証、決済、外部API連携——これらはAIに丸投げしない。人間が責任を持つ領域として明確に切り分ける。

4. AIへの指示にセキュリティ要件を含める

「XSSを防いで」「SQLインジェクションを考慮して」とプロンプトに明示するだけで、出力の品質が変わる。AIは指示されなければセキュリティを考慮しない傾向がある。

5. CIパイプラインにセキュリティスキャンを組み込む

本番環境にデプロイする前の最後の砦。GitHub ActionsにSemgrepを組み込めば、プッシュのたびに自動でスキャンが走る。設定は数行で済む。

Amazonも630万件の注文消失事故の後、シニアエンジニアによるコード承認を義務化した。Qodo CEOのItamar Friedmanは「artificial wisdom——組織固有のガバナンス層が必要だ」と提唱している。

正直、この5ステップを全部やっている日はまだ少ない。でもTenzaiの結果（69件の脆弱性）を見て、少なくともセキュリティスキャナーだけは今日から入れようと決めた。完璧でなくていい。1つ始めるだけで、コードを「信頼する」から「検証する」への切り替えが始まる。

まとめ：「信頼する」ではなく「検証して使う」に切り替える

ここまで、Vibe Codingの信頼崩壊の全体像と対策を見てきた。要点を整理する。

  • **使用率92%なのに信頼度60%**というパラドックスは、「動く」と「安全」が別物だから生まれている
  • AI生成コードのセキュリティ面で安全なのは約10.5%にとどまるとの分析がある
  • 複合エラー問題：ステップが増えるほど成功率は掛け算で低下する（10ステップで35%未満）
  • レビュー速度が追いつかない構造問題は、個人・企業レベルで意識的な対応が必要
  • 解決策は「使わない」ではなく、セキュリティスキャナー導入・レビュー習慣・処理の切り分けという具体的なステップにある

AIコーディングを「信頼する」時代は終わりつつある。これからは「検証して使う」時代だ。僕はこれからも毎日Claude Codeを使うけれど、使い方をアップデートしていこうと思っている。

まず今日、Semgrepをプロジェクトに入れてみてほしい。無料で使えるし、インストールは5分もかからない。セキュリティスキャナーを一度走らせると、AIが生成したコードの「裏側」が見えてくる。その体験が、最初の一歩になるはずだ。

参考リンク