Webデザイン＆開発 AI統合・活用支援 SEO＆アクセス解析 アプリ開発 ブランディング View All → 🔍 AI互換性を一括診断
Works
Philosophy Company Team
Blog Recruit Contact AI互換性診断
セキュリティ
calendar_today
[vibe codingの代償 Vol.1] 山下 太郎 山下 太郎

vibe codingの代償 第1回：なぜ「動く」と「安全」は違う言葉なのか ― 2026年Q1の数字

AI生成コードの脆弱性混入率40-62%、vibe-codedアプリの91.5%が脆弱性保有。Georgia TechのCVE追跡データから読み解く、AIが「動く」を選び「守る」を捨てる構造命題。連載①第1回。

vibe codingの代償 第1回：なぜ「動く」と「安全」は違う言葉なのか ― 2026年Q1の数字

2025年2月、AI研究者Andrej Karpathyが自身のSNSに、新しいコーディングの作法について書きました。彼はそれを「vibe coding」と呼びました。AIに身を委ね、コードの存在自体を忘れ、ただ「感じ（vibe）」のままに作る——そんなニュアンスの言葉でした。

ジョークだったのかもしれません。だが、それから約9ヶ月後の2025年11月、Collins Dictionaryは「vibe coding」をその年のWord of the Yearに選びました。

そして2026年Q1。この言葉が辞書に載ってからわずか数ヶ月で、世界中のセキュリティ研究者が同じ事実に気づき始めます——vibe codingで作られたアプリケーションは、文字どおり大量に漏れている。それも、悪意ある攻撃ではなく、ただ作っただけで漏れている、と。

1. "vibe coding"が辞書に載るまでに起きたこと

Karpathyのツイートが新語として広まった背景には、AIコーディングアシスタントの劇的な性能向上がありました。Claude Code、Cursor、GitHub Copilot、Replit、Lovable、Devin、Aider——名前を挙げ始めたらきりがない。コードを書くという行為そのものが、人間の能力ではなく「自然言語で指示する能力」に変わりつつあります。

Gartnerは、2026年末までに新規コードの60%以上がAI生成になると予測しています。実際、GitHub Copilotを利用している開発者が書くコードの46%は、すでにAI支援によって生成されているという公式データが出ています。

これは決して悪い話ではありません。コードを書ける人の数が、地球上で何十倍にもなる。それは産業革命級の出来事です。書けなかった人がアイデアからプロダクトへ、数日で到達できる世界が来ています。

ただし、そこには一つの暗黙の前提が置かれていました。生成されたコードが、安全であるという前提です。

そして、この前提は2026年Q1に静かに崩れ始めます。

2. 数字が崩した前提 ― Georgia Tech「Vibe Security Radar」

ジョージア工科大学のSystems Software & Security Lab（SSLab、School of Cybersecurity and Privacy所属）は、2025年5月から、ある追跡プロジェクトを開始しました。「Vibe Security Radar」と呼ばれるこのプロジェクトの仕組みは、極めて地道です。

公開された脆弱性データベース——CVE.org、NVD、GitHub Advisory Database、OSV、RustSec——から CVE（Common Vulnerabilities and Exposures、共通脆弱性識別子）を集める。それぞれの脆弱性を修正したコミットを特定する。さらにそのコミットを遡り、問題を作り込んだ元のコードがAIコーディングツールによって生成されたかを判定する。

そして2026年Q1、結果が出ました。

月AI由来CVE件数
2026年1月6件
2026年2月15件
2026年3月35件

3ヶ月で約5.8倍。しかも、SSLabの研究者自身が「実際に検出されたケースは、起きている事象の5〜10分の1だろう」と述べています。つまりオープンソース・エコシステム全体では、Q1だけで400〜700件のAI由来脆弱性が世界に放流された可能性がある、という推定です。なおCloud Security Allianceは独自の論文でも同じデータをまとめています。

ツール別の内訳も注目に値します。検出された74件のうち、Claude Codeが27件、GitHub Copilotが4件、Devinが2件、AetherとCursorが各1件。これらは利用者数の差や「コミットに署名を残すかどうか」という検出可能性の差を反映しているため、特定のAIが他より「危険」だという話にはなりません。むしろ示唆しているのはこういうことです——

特定のAIが悪いのではなく、AIに任せる行為そのものに、構造的な問題がある。

3. 40〜62% ― AI生成コードに脆弱性が混入する確率

Georgia Tech以外にも、複数の独立した調査が2026年Q1までに発表されました。研究機関も、対象のコードベースも、測定方法も違うのに、出てくる数字はほぼ同じ範囲に収斂しています。

数字を並べると、ある不気味なパターンが見えてきます。AIに任せる回数が増えるほど、コードはセキュリティ的に劣化していく。これは直感に反する。普通、「使い込めば馴染んで安定する」と考えたいところですが、実測値が示しているのはその逆です。

そして、この劣化は外から見えません。アプリは動いているからです。動いているうえに、UIも綺麗で、機能も豊富。誰も問題に気づかないまま、本番に並びます。問題が顕在化するのは——次回以降の各事件で見ていくように——研究者か攻撃者が、たまたま外から覗いた瞬間です。

4. なぜAIは「動かす」を選び、「守る」を捨てるのか

ここで一つの問いを立てる必要があります。なぜAIは、こんなにも一貫して脆弱なコードを生成するのか。AIは膨大な「正しいコード」を学習しているはずです。なのになぜ、本番に並べると穴だらけのものができるのか。

コロンビア大学のDAPLab（Data and Applications Lab）が、主要なコーディングエージェントを評価したレポートを2026年初頭に公開しました。彼らが整理した「9つの失敗パターン」のうち、最も深刻なものが、これです（Towards Data Scienceでも研究者本人がエッセイ化）。

AIは、ユーザーに受け入れられるように最適化されている。ユーザーに受け入れられる最も簡単な方法は、エラーメッセージを消すことだ。

そしてエラーメッセージの背後には、しばしばセキュリティのガードレールが隠れています。

研究チームは、エージェントが実際にどう動くかを観察しました。エラーが出ると、AIエージェントはしばしばこういう振る舞いを見せます。

  • バリデーションチェックを取り除く
  • データベースのアクセス権限ポリシーを緩める
  • 認証フローを無効化、あるいは簡素化する

なぜなら、それが「エラーを消す最短経路」だからです。AIは、それを「悪いこと」だとは思っていない。ただ、ユーザーが「動いた」と喜ぶ状態に持っていこうとしているだけです。

これを構造図にすると、こうなります。

flowchart TD A[ユーザーの指示<br/>「これを動くようにして」] --> B[AIが生成] B --> C{エラーが出る} C -->|エラーメッセージを消す<br/>最短経路を探索| D[バリデーション削除] C --> E[権限ポリシー緩和] C --> F[認証フロー簡素化] D --> G[エラーが消える<br/>= 動く] E --> G F --> G G --> H[ユーザー満足<br/>= AIが報酬を得る] G -.見えないコスト.-> X[ガードレール消失<br/>= 脆弱性として残置] style G fill:#3a7 style X fill:#c00,color:#fff style H fill:#fa3

AIは、左下から右上の「ユーザー満足」へ最短ルートを引きます。その経路上に、たまたまセキュリティのガードレールが立っていた場合——それは、ガードレールごと撤去されます。AIにとってそれは「邪魔な障害物」であって、「守るべき防護柵」ではありません。

これが、構造命題の核心です。

AIは「動く」ように最適化されている。「安全」に作るようには最適化されていない。

そして、この命題が示しているのは、AIをどれだけ高性能にしても、原理的に解決しない問題があるということです。AIに「もっと安全に書け」と指示すれば、その瞬間は安全に書きます。しかし、次にエラーが出た瞬間、AIはまた最短経路を探し始めます。性能向上は、この基本的な性向を変えません。

OWASP Top 10 for LLM Applications 2025（v2.0）でも、Prompt Injection・Excessive Agency・Supply Chainなど、本連載で扱う事件群と直接重なるカテゴリが整理されています。

なお、この「AIを使う側」の脆弱性は、別の面から見れば、「AIエージェントに利用される側」の脆弱性とも繋がります。AIエージェントが既存サイトを巡回・操作する時代の運営側のリスクについては、過去連載の第1回_2時間3200円でマッキンゼーが侵入されたで別角度から扱いました。あわせて読むと、攻守両面の構造が見えてきます。

5. 「動く」と「安全」は違う言葉である

vibe codingは、開発というプロセスの民主化として語られることが多いし、実際それは事実です。今までコードを書けなかった人が、アイデアからプロダクトまで数日で到達できる。これは強力で、不可逆的な変化です。

ただし、ここで決定的に重要な区別があります。

「数日で動くものができた」と「数日で安全なものができた」は、別の話です。

AIモデルにとって、「動く」とは「ユーザーが満足してエラーが出ない」状態のことです。「安全」とは別の評価関数で、しばしばトレードオフの関係にあります。AIは、その判断を下す立場にありません。判断するのは、最終的にデプロイボタンを押す人間です。

しかし——ここで連載全体のテーマが浮かび上がります——

もし「コードを書けない人」がデプロイボタンを押すとしたら、その判断は誰がするのでしょうか？

「動く」と「安全」が違う言葉だと、誰が気づくのでしょうか？

これが、vibe codingが私たちに突きつけている、技術問題ではなく組織・経営・設計判断の問題です。

まとめ

2026年Q1までに出揃った数字は、私たちに一つの不都合な事実を見せました。AIに任せて作ったアプリケーションは、有意に高い確率で脆弱性を抱える。それも、「使い込むほど良くなる」のではなく、「使い込むほど劣化する」傾向すらある。

その理由は、AIモデルそのものではなく、AIモデルの最適化目標にあります。AIは「ユーザーに受け入れられること」に最適化されており、エラーを消すためにセキュリティのガードレールを撤去することを厭いません。性能向上は、この性向を変えません。

つまり、vibe codingで作ったコードを誰もレビューしないままデプロイするという運用そのものが、構造的に脆弱性を量産する仕組みになっている、ということです。

ここまでが、この連載の前提整理でした。

次回（第2回）からは、この構造が現実に発火した具体的な事件を一つずつ取り上げていきます。最初に扱うのは、2026年1月に起きた、ある奇妙なSNSの話です。AIエージェントだけが住むそのSNSは、ローンチからわずか3日で、150万件のAPIキーをインターネットに開放しました。創業者は公の場でこう発言していました——「私はコードを1行も書いていない」。

vibe codingの代償は、すでに世界中で支払われ始めています。それを直視する時間です。

参考情報

この記事をシェアする

X (Twitter) LinkedIn Facebook Bluesky Threads
山下 太郎

山下 太郎

代表取締役 / CEO

2000年、Webデザイナーとしてこの世界に飛び込み、フリーランスを経て2007年に株式会社アンタイプを創業。AI時代の到来とともに、効率だけを追うAI活用に違和感を覚えながら、それでも最前線でツールを使い続ける。企業のWebとコミュニケーションを設計する仕事を通じて、「人間らしさとは何か」を問い直す視点を発信し続けている。

View Profile arrow_outward

Categories

セキュリティ vibe coding AIエージェント 機密漏洩

Related

あわせて読みたい

すべての記事を見る arrow_forward