バイブコーディングという言葉を、この1年で何度も目にしたはずです。自然言語で「こういうアプリが欲しい」と伝えるだけで、AIがコードを書き上げる。開発の常識を塗り替えるこの手法は、いまや非エンジニアの手にも広く渡りました。
ところが、その便利さの裏側で見過ごせない数字が報告されています。公開中のバイブコーディング製のWebアプリ200件を調べたところ、91.0%に少なくとも1つの脆弱性があったというのです。
本記事では、この調査の設計と中身を一次情報から読み解きます。なぜAIは穴を開けてしまうのか、そしてどうすれば防げるのかを整理しました。
その91%は、どこから来た数字なのか
数字だけが独り歩きすると誤解を招きます。まず、この調査がどんな条件で行われたのかを確認しましょう。
調査はMicrosoftとシンガポール国立大学に所属する研究者らが発表した論文です。著者はJunquan Deng氏、Zhiyu Fan氏、Ruijie Meng氏の3名。2026年6月22日に投稿され、9月14日に更新された第4版の数字が現在の定説になっています。
対象の絞り込みはかなり厳格です。初回コミットがAI製であり、AI由来のコミット割合とコード行割合がどちらも90%以上という条件を満たすリポジトリだけを集めました。
集まったのは9,041件です。そのうちWebアプリが8,695件、実際に公開稼働していたものが984件でした。ここから無作為に抽出した200件が、今回の監査対象になります。
つまり91%は「バイブコーディング全体の9割」ではありません。「この条件で拾った公開アプリ200件の9割」と読むのが正確です。
検出精度も論文に明記されています。既知の脆弱なアプリ「OWASP Juice Shop」で再現率95.70%を記録し、見落としは15%未満と見積もられました。検出手法そのものの信頼性は、一定程度担保されています。
なお、AI製かどうかの判定はClaude CodeとLovableの痕跡に頼っています。対象がGitHubのオープンソースに限られる点も、結果を読むときの前提になるでしょう。
1,186件の脆弱性——上位3類型で6割を占める
監査で見つかった脆弱性は、合計1,186件にのぼりました。内訳を見ると、驚くほど「基本」に偏っています。
200件のうち91.0%にあたるアプリで、少なくとも1件の脆弱性が確認されました。さらに、見つかった欠陥の65.77%は、不正アクセスやシステム乗っ取り、データ漏えいにつながる深刻度「致命的」または「高」に分類されています。
種類の上位3つは、どれも古典的なものです。
| 脆弱性の類型 | 件数 | 全体に占める割合 |
|---|---|---|
| アクセス制御の不備 | 339件 | 28.58% |
| インジェクション | 199件 | 16.78% |
| 認証の失敗 | 176件 | 14.84% |
この3類型だけで全体の60.2%を占めます。誰が入れるのか、本人確認はどうするのか、外から来た入力をどこまで通すのか。いずれもアプリの根幹に関わる論点です。
発生した場所も偏っていました。バックエンドが625件で52.70%と最多。次いでフロントエンド426件（35.92%）、設定135件（11.38%）と続きます。見た目の画面より、裏側の処理に穴が集中している構図です。
論文が挙げた実例も生々しいものです。医療機関向けプラットフォームで顧客情報が見えてしまった事例、リモートコード実行につながるコマンドインジェクションが含まれていました。
Lovableで作られたサイトでは、行単位のアクセス制御が設定されていない問題も報告されています。これはCVE-2025-48757として登録され、CVSSスコアは9.3。事実上「最悪レベル」の評価です。
なぜAIは穴を開けてしまうのか——3分類8類型
問題は「AIが下手だから」ではありません。研究者らは脆弱性が混入した経緯をコミット履歴から追い、3分類8類型に整理しました。
大枠は3つです。開発の途中で以前決めた安全対策が抜け落ちる「記憶の欠陥」が13.5%。動くことを優先して安全を後回しにする「目的の欠陥」が23.1%。そして暗黙のルールを見落とす「知識の欠陥」が63.4%を占めました。
最大の原因は知識の問題です。AIは指示されたことを忠実にこなしますが、指示されていないことには自ら動きません。
| 脆弱性が生まれた型 | 件数 | 割合 |
|---|---|---|
| 書かれていない安全規則 | 658件 | 55.5% |
| デモ前提の設計 | 174件 | 14.7% |
| 修正の伝播漏れ | 110件 | 9.3% |
| 動かすための修正の副作用 | 100件 | 8.4% |
| ユーザー任せの安全対策 | 72件 | 6.1% |
| やり残しのTODO | 50件 | 4.2% |
| 存在しないAPIの呼び出し | 13件 | 1.1% |
| 危険な指示の忠実な実装 | 9件 | 0.8% |
最も多いのが「書かれていない安全規則」で658件、55.5%です。頼まれていないから入れない。機能は動くから気づかない。この型だけで過半数を超えました。
見逃せないのは「やり残しのTODO」です。50件と数は少ないものの、その90.0%が致命的または高の深刻度でした。論文の例では、ログイン処理がパスワード照合をTODOのまま出荷されています。
一方で「危険な指示の忠実な実装」は9件にとどまりました。悪意ある仕様よりも、書かれなかった規則と、反復や公開の段階で抜け落ちた対策のほうが、はるかに多いのです。
実例に学ぶ、3つの落とし穴
分類だけでは実感が湧きにくいため、論文が示した具体的な失敗例を3つ紹介します。いずれも「動いているように見える」ことが共通点です。
存在しない暗号化関数が招いた無防備な保管
あるアプリは秘密情報の保護に暗号化を使っていました。ただし呼び出していたのは、Node.jsに存在しない「crypto.createCipherGCM」という関数です。
呼び出しは当然失敗します。しかしエラーは表面化せず、秘密情報は暗号化されないまま保管され続けました。動いているように見えるコードが、静かに保護を失っていたわけです。
APIキーをシーザー暗号で隠せ、に従ったエージェント
指示ファイルに「APIキーをシーザー暗号で隠して埋め込め」と書かれたケースもありました。エージェントはそれを忠実に実行しています。
シーザー暗号は文字を数文字ずらすだけの古典的な仕組みで、現代の暗号としての強度はありません。危険な指示を疑わずに実装してしまう典型例です。
本番に残ったログイン処理のTODO
ログイン機能のパスワード照合が、TODOコメントのまま公開された例もあります。開発中の仮実装が、そのまま本番の入り口になってしまいました。
指示を変えると、再発率はどう変わるのか
論文は原因の分析にとどまりません。脆弱性が入った場面に戻り、指示を変えて同じ作業をやり直させる実験まで行っています。
条件は8つ、対象は70件の脆弱性、各条件を3回ずつ繰り返した合計1,680ランです。1条件あたり210ランの試行になります。
同じ脆弱性がもう一度入ってしまった割合で比較した結果は、次の通りです。
| 与えた条件 | 再発率 | 素の状態との差 |
|---|---|---|
| 何も足さない | 25.7% | — |
| 「本番運用に耐えるものを」と足す | 11.0% | -14.8pt |
| セキュリティ強化スキルを足す | 11.9% | -13.8pt |
| 自己点検を促す | 23.8% | -1.9pt |
| コードを整えるよう頼む | 22.9% | -2.9pt |
| より強いモデルを使う | 26.2% | +0.5pt |
| より弱いモデルを使う | 39.5% | +13.8pt |
| 技術要件を細かく書く | 45.7% | +20.0pt |
最も効いたのは「「本番運用に耐えるものを」」と一言添える指示でした。再発率は25.7%から11.0%へ、14.8ポイント下がっています。セキュリティ強化用のスキルを追加した場合も、11.9%まで下がりました。
細かい技術指示が裏目に出る理由
表の中で最も意外なのは、最下段の数字でしょう。技術要件を細かく書くほど、再発率は上がっています。
再発率は45.7%で、素の状態より20.0ポイントも悪化しました。指示を増やせば安全になるという直感は、この実験では通用しません。
論文の説明は明快です。書かれた仕様に忠実に動く分だけ、エージェント自身の安全判断が入り込む余地が減るというのです。
細かな技術指定は、AIの注意力を「仕様の充足」に向けさせます。その結果、仕様に書かれていない危険の芽を摘む余力が失われてしまう。皮肉な構造です。
実務に落とすなら、依頼文の順番を変えることになります。機能の詳細を並べる前に、「本番運用に耐えること」を完了条件として先に書き、セキュリティのスキルを併せて渡す。実験結果が支持するのは、この並べ方です。
高性能なモデルに乗り換えても解決しない
「最新のモデルなら安全になる」という期待にも、この調査は冷や水を浴びせます。性能とセキュリティは、素直には連動しないのです。
より強いモデルを使った条件の再発率は26.2%で、素の状態からわずか0.5ポイントしか改善しませんでした。一方、より弱いモデルは39.5%まで悪化しています。
さらに重い数字があります。脆弱性が入りうる場面だった434回のうち、90回（20.7%）でエージェントはリスクに気づいたうえで、安全でないコードをそのまま出力しました。
気づいていながら直さない。これは能力の問題ではなく、判断の優先順位の問題です。モデルの性能を上げるだけでは埋まらない溝が、ここにあります。
再現性にも注意が要ります。同じ条件を3回繰り返した実験では、560セルのうち123（22.0%）で結果が割れました。1回試して再発しなかったからといって、安全と断定はできないのです。
業界はいま、何を問題視しているのか
研究の外側でも、同種の警鐘が相次いでいます。開発現場の意識と、実際のリスク管理には大きな隔たりがあります。
Stack Overflowの開発者調査では、AIコーディングツールを利用中または利用予定のエンジニアが84%に達しました。ところが、AIの出力を高いレベルで信頼すると答えた人は、わずか3%です。
「信頼していない」と答えた46%が「信頼している」の33%を上回っています。導入が進むほど、現場の信頼は逆方向に進んでいる構図です。
最大の不満は「ほぼ合っているが、微妙に違う」コードで66%を占めました。45%は、AI製コードのデバッグに自分で書くより時間がかかると答えています。
セキュリティベンダーも同じ論点を指摘します。トレンドマイクロは、問題はレビュー体制や責任の所在が開発速度に追いつかない点にあると整理しました。「無謀なのはバイブコーディングではなく、リスクを軽視する姿勢」という表現が印象的です。
企業側の備えも遅れています。ガートナーの調査では、大手企業で脆弱性管理が十分だと答えたのは3割にとどまりました。日本国内でも10月に入り、大規模な情報漏えいの報道が続いています。
公開前に見るべき5つのポイント
ここからは論文の分類を、公開前の確認項目に落とし込んだ実務的な内容です。順に確認してください。
- すべてのエンドポイントにサーバー側の認可があるか。新しいルートだけ守り、既存のハンドラが素通しになっていないかを確かめます。
- 認証のTODO、固定の認証情報、迂回用のログインが残っていないか。
- 秘密情報が平文やlocalStorage、Base64や簡単な暗号だけで置かれていないか。
- 外部入力がSQL、HTML、コマンドにそのまま渡っていないか。
- .envやデータベースのダンプ、デフォルトの鍵がリポジトリに混入していないか。.gitignore任せにしないことが重要です。
これで再発がゼロになるわけではありません。論文のどの条件でも再発率は0になっていません。生成されたアプリはまずプロトタイプとして扱い、実ユーザーにいきなり公開しない姿勢が求められます。
【FAQ】バイブコーディングのセキュリティに関するよくある質問
最後に、よく寄せられる疑問をまとめました。判断に迷ったときの参考にしてください。
| 質問 | 回答 |
|---|---|
| バイブコーディングは、もう使うべきではないのですか？ | いいえ。開発速度の利点は大きく、論文も手法そのものを否定していません。生成物をプロトタイプとして扱い、公開前に検証する運用が前提になります。 |
| 91%という数字は、そのまま受け取ってよいのですか？ | 条件付きの数字です。AI由来率90%以上の公開アプリから無作為に選んだ200件の結果であり、対象はGitHubのオープンソースに限られます。 |
| 高性能なモデルに変えれば安全になりますか？ | この実験では改善しませんでした。より強いモデルの再発率は26.2%で、素の状態とほぼ同じ水準にとどまっています。 |
| セキュリティの指示は、どう書けばよいのですか？ | 完了条件を先に書くのが有効です。「本番運用に耐えるものを」と添えるだけで、再発率は25.7%から11.0%へ下がりました。 |
| 個人開発の小さなアプリでも、対策は必要ですか？ | 必要です。上位3類型はアクセス制御、インジェクション、認証であり、規模にかかわらず公開した時点で攻撃対象になります。 |
| 生成されたコードを読む時間がありません。どうすればよいですか？ | 全行を読む代わりに、公開前チェックの5項目だけを機械的に通してください。指摘が残っているうちはURLを公開しない運用が現実的です。 |
まとめ——便利さと危険は同じ速度で広がる
2026年10月時点で、バイブコーディングは開発の現場に深く根を下ろしました。一方で、公開アプリの91%に脆弱性があったという事実は、便利さと危険が同じ速度で広がっていることを示しています。
私の場合、AIに任せる範囲を「動くものを作るまで」に限定しています。私の運用では、公開前の確認リストを別のセッションでAIに読ませ、指摘が残っているうちはURLを出さないと決めました。
効いたのは、細かな技術指示を積み上げることではなく、完了条件を「本番運用に耐えること」と定めることでした。この一手間が再発率を半分近くまで下げたという実験結果には、説得力があります。
できあがったアプリを公開する前に、認可・認証・秘密情報・入力の扱い・リポジトリの5点を確認してください。便利さを手放さずに安全を確保する道は、この地道な確認にあります。
AIと一緒にものづくりをする時代は、まだ始まったばかりです。穴を開けないコツを身につけて、安心して開発を始めましょう。
コメント