2026年10月、「バイブコーディングで作った公開中のWebアプリの9割に脆弱性」というニュースが流れました。この章では、元になった論文を読み、その数字が何を意味していて、何を意味していないのかを確かめます。怖がるためではなく、正しく怖がるためです。
この章の学習目標
- バイブコーディングという言葉の意味と、この教材での扱い方を説明できるようになる
- 「91%に脆弱性」という数字の出どころと、その前提条件を人に説明できるようになる
- 「AI製だから危ない」のか「公開アプリは元々そんなもの」なのかを、数字をもとに切り分けられるようになる
バイブコーディングとは
バイブコーディング（vibe coding）は、2025年2月にAI研究者のアンドレイ・カーパシー氏がSNSで使った言葉です。「雰囲気（vibe）に身を任せて、コードを読まずにAIに全部書かせる」というニュアンスで、当初は半分冗談でした。それが1年ほどで、Claude Code、Lovable、Cursor、Replit といった道具の普及とともに、ごく普通の開発方法になりました。
この教材では、もう少し広く「自然言語で指示を出し、設計から実装までの大部分をAIに任せてアプリを作ること」をバイブコーディングと呼びます。あなたがこれまで作ってきた教材サイトや学習用アプリも、ほとんどがこれに当たります。
経理の仕事に置き換えると、「仕訳の起票を全部、新人に口頭で頼んで、できあがった伝票を見ずに承認している」状態に近いものです。新人が優秀でも、承認者が中身を見ていなければ内部統制は効きません。バイブコーディングの危うさは、AIの能力の問題というより、「見ないまま承認している」構造の問題です。
論文は何を調べたのか
ニュースの元になったのは、2026年6月に公開された論文「Understanding the (In)Security of Vibe-Coded Applications」です。著者はJunquan Deng、Zhiyu Fan、Ruijie Mengの3名で、所属は独立研究者、Microsoft、シンガポール国立大学です。日本のニュースでは「MSの発表」と紹介されることがありますが、正確には「Microsoft所属の研究者を含むチームの論文」で、Microsoft社としての公式発表ではありません。
調査の手順は次の通りです。この絞り込みの過程が、数字を読むうえでいちばん大切です。
対象となった道具は Claude Code と Lovable の2つです。GitHub上で「AIが書いたコードがほぼ全部」と判定できるリポジトリを集め、そのうち実際にインターネット上で動いているWebアプリ984件から、200件を無作為に選んで監査しました。
- リポジトリ
- プログラムの保管庫。GitHubなどに置く「このアプリのファイル一式と変更の履歴」のこと。経理でいえば、1つの案件の書類をまとめたファイルボックスです。
- コミット
- 保管庫への「保存の記録」。誰が・いつ・どこを変えたかが1件ずつ残ります。訂正履歴つきの帳簿のようなものです。「AI由来のコミット比率90%以上」は、保存の記録の9割以上をAIが行っていた、という意味です。
- 監査（セキュリティ監査）
- アプリに攻撃に使える弱点がないかを、第三者の目で調べること。会計監査と同じく、「作った人以外」が見るのが要点です。
監査は、2種類のAIエージェント（Claude Code と GitHub Copilot）と、2種類のセキュリティ用の追加知識（スキル）を組み合わせた4通りで、1件につき4回行わせています。出てきた生の報告は11,150件。重複を整理して2,125件に絞り、到達可能性と再現性を無害な方法で確かめて1,287件に。最後にセキュリティ専門の著者2名が独立にレビューし、両者が「実際に悪用できる」と判定したものだけを残しました。それが1,186件です。
- AIエージェント
- 指示を受けて、自分でファイルを開いたり、コードを読んだり、コマンドを実行したりしながら作業を進めるAI。チャットで答えるだけのAIと違い、「手を動かす」AIです。Claude Code はその代表です。
- スキル
- AIに追加で渡す「専門知識の手順書」。ここでは「セキュリティ監査のやり方」を書いた文書を渡した場合と渡さない場合を比べています。
- 到達可能性
- 見つかった弱点が、外部の利用者から実際にたどり着ける場所にあるかどうか。コードの中にあっても、誰も呼び出せない処理なら実害は小さい、という考え方です。
- 再現性
- 同じ操作をすれば、同じ弱点が何度でも確認できること。偶然ではなく、仕組みとして穴が開いていることの証明です。
結果：182件（91.0%）に、1件以上の脆弱性
200件のうち182件、91.0%に少なくとも1件の脆弱性がありました。1件もなかったのは18件だけです。見つかった1,186件のうち65.77%は、深刻度が「致命的」または「高」でした。これは、第三者による不正アクセス、システムの乗っ取り、データ漏えいに直接つながりうるものです。
種類別に見ると、上位3つで全体の6割を占めます。
| 順位 | 種類（OWASP Top 10:2025の分類） | 件数 | 割合 | 一言でいうと |
|---|---|---|---|---|
| 1 | アクセス制御の不備 | 339 | 28.6% | 他人のデータが見える・触れる |
| 2 | インジェクション | 199 | 16.8% | 入力欄から命令を送り込まれる |
| 3 | 認証の不備 | 176 | 14.8% | ログインの仕組みが甘い |
| 4 | 暗号化の不備 | 112 | 9.4% | パスワードや秘密の保存が雑 |
| 5 | セキュリティ設定の不備 | 108 | 9.1% | 初期設定のまま、鍵が開いている |
1位の「アクセス制御の不備」は、たとえば「ログインしていれば、URLの数字を変えるだけで他人の記録が見える」といった状態です。経理でいえば、承認権限のない人が承認ボタンを押せてしまう、あるいは他部署の伝票を自由に閲覧できてしまう状態に相当します。第5章と第10章で、自分のアプリでこれを確かめる方法を扱います。
/account/12 のような形になっていて、ログインしたまま数字を 13 に変えたら別の利用者の残高が表示された。これが1位の「アクセス制御の不備」です。見た側に悪意がなくても、仕組みとしては穴です。2位の「インジェクション」は、振込先の名前欄に文字を入れたら、その文字が「名前」ではなく「命令」としてデータベースに届いてしまう状態。3位の「認証の不備」は、パスワードを何回間違えてもロックされない、ログアウトしても「戻る」で残高画面が開く、といった状態です。
- 深刻度（severity）
- その穴が悪用されたときの被害の大きさを、「致命的」「高」「中」「低」の4段階で表したもの。論文はOWASP（Webセキュリティの国際的な非営利団体）の評価基準を使っています。「致命的」は、たとえば誰でも全利用者のデータを読める、といった状態です。
この数字が意味しないこと
ここが、ニュースの見出しだけでは分からない部分です。
「AI製アプリ全体の91%」ではない
91%は「Claude Code または Lovable で作られ、GitHubに公開され、実際に稼働している984件から無作為に選んだ200件」の数字です。非公開のリポジトリ、他の道具で作ったもの、サーバー側の処理がないただの静的サイトは、この母集団に入っていません。「世の中のAI製アプリの9割が危ない」とまで言うのは、論文の範囲を超えています。
- 母集団
- 統計で「調べた全体の範囲」のこと。91%という数字は、この範囲の中でだけ意味を持ちます。アンケートの「回答者100人のうち」の「100人」が母集団です。
- 静的サイト
- あらかじめ作ったページをそのまま表示するだけのサイト。教材サイトや用語集サイトはこれに当たります。入力を受け取って処理する仕組みがないので、穴ができる場所も少ない。
- サーバー側の処理
- 利用者の入力を受け取り、保存したり計算したりする部分。ログイン、フォーム、データの保存があるアプリには必ずあります。論文が調べたのはこちらです。
人が作ったアプリも、実はそれほど変わらない
比較のために、セキュリティ検査会社Veracodeの年次報告を見てみます。2025年版では、同社が検査した（主に企業が人手で開発した）アプリの80%に、1件以上のセキュリティ上の欠陥がありました。調べ方が違うので単純比較はできませんが、「Webアプリはだいたいどこかに穴がある」のが現実です。AI製だけが突出してひどい、というわけではありません。
ただし、論文のほうは「実際に悪用できる」と専門家2名が確認したものだけを数えていて、そのうち65.77%が致命的または高でした。穴の「数」より、穴の「質」のほうが気になる結果だと言えます。
| 論文（Deng ほか, 2026） | Veracode（State of Software Security 2025） | |
|---|---|---|
| 調べた対象 | Claude Code／Lovable製で、GitHubに公開され、稼働中のWebアプリ200件 | 同社の検査サービスを使う企業のアプリ（主に人手で開発。数十万件規模） |
| 調べ方 | AIエージェントが候補を出し、到達性・再現性を確かめ、専門家2名が「悪用できる」と判定 | 自動検査ツールで欠陥を検出（悪用できるかの人手判定はしない） |
| 結果 | 91.0%に1件以上。見つかった穴の65.77%が致命的・高 | 80%に1件以上の欠陥 |
| 読み方 | 「実際に悪用できる穴」がほとんどのアプリにある | 「何らかの欠陥」はどんなアプリにもある |
「AIは危ない」ではなく、「AIはこういう間違い方をする」
この論文のいちばんの価値は、91%という数字そのものより、「なぜAIがそこを間違えるのか」を8つのパターンに整理し、「どう頼めば防げるか」を実験で確かめたところにあります。たとえば、AIへの指示に「本番運用に耐えるものを（ready for production）」と一言添えるだけで、同じ脆弱性が再発する割合が25.7%から11.0%に下がりました。逆に、技術的な指示を細かく書き込むと45.7%に悪化しています。この話は第4章で詳しく扱います。
では、何が本当に危ないのか
危険の大きさは「誰が作ったか」よりも「そのアプリが何を扱うか」で決まります。
- ログインも個人情報の入力もない、読むだけの情報サイトであれば、攻撃されても盗まれるものがほとんどなく、被害は限られます。
- ログイン機能がある、他人のデータを保存する、お金を扱う。ここが本丸です。論文で見つかった深刻な欠陥の多くも、権限チェック漏れやデータ漏えいにつながる類のものでした。
非エンジニアにとって本当に怖いのは、技術がないことそのものより、「穴があることに気づけないまま、他人のデータを預かるものを公開してしまう」ことです。逆に言えば、人のデータを扱わないものなら、過度に怖がる必要はありません。この切り分けは第3章で詳しくやります。
やってみる：見出しの数字を、自分の目で確かめる
- ITmediaの記事（出典に挙げたもの）を開き、「9割」「91%」「200件」「65.77%」の4つの数字が本文のどこに出てくるかを探します。
- どこを見る：記事の3段落目あたり。「9041件のうち」から始まる一文に、絞り込みの数字が並んでいます。
- OKの状態：「200件」が「無作為に抽出」された数で、「91%」がその200件に対する割合だと読み取れたらOKです。
- 論文のページ（arXiv）を開き、冒頭の「Abstract（要旨）」だけを読みます。英語が苦手なら、AIに貼り付けて日本語にしてもらって構いません。
- どこを見る：ページ上部の「Abstract」。10行ほどの英文です。
- OKの状態：要旨の中に「200」と「91」が出てくることを確認します。見出しの数字が論文の要旨に由来していると分かれば十分です。
- 詰まったら：AIへの頼み方は「この英文を日本語にして、出てくる数字を全部そのまま残してください」。数字を丸めさせないのがコツです。
- 自分が公開しているサイトを1つ選び、「読むだけ」か「入力やログインがあるか」を点検ノート（紙でもメモアプリでも）に書きます。第3章で使います。
まとめ
- 「91%」は、Claude Code／Lovable製で公開稼働中の984件から無作為抽出した200件の数字。専門家が「悪用できる」と確認した脆弱性だけを数えている。
- 人が作ったアプリでも80%に欠陥がある（Veracode 2025）。AI製だけが特別に危ないわけではないが、見つかった穴の65.77%が致命的・高だった点は重い。
- 本当の危険は「何を扱うか」で決まる。他人のデータやお金を扱うものを、確認せずに公開することがいちばん危ない。
出典
- Junquan Deng, Zhiyu Fan, Ruijie Meng「Understanding the (In)Security of Vibe-Coded Applications」（arXiv:2606.23130、2026年6月、v4は2026年9月14日）
- ITmedia NEWS「バイブコーディングで作った公開中のWebアプリ、9割に脆弱性 MSの研究者など調査」（2026年10月7日）
- Veracode「State of Software Security 2025」の報道（i-programmer）（2025年3月）
- OWASP Top 10:2025（日本語版）