公開中のバイブコーディング製アプリ200件 91%に穴があった
AIに作らせて公開されているWebアプリの91%に、少なくとも1つの脆弱性が見つかりました。米Microsoftやシンガポール国立大学などの研究者が、論文「Understanding the (In)Security of Vibe-Coded Applications」で調べた結果です。
調べた対象は、オープンソースで公開されているバイブコーディング製のアプリ9041件です。このうちWebアプリは8695件で、実際に動いていたのは984件でした。研究チームはそこから200件を無作為に選んでいます。
見つかった欠陥は1186件あり、その65.77%が深刻度「致命的」か「高」でした。第三者の不正アクセスやデータ漏えいにつながりうる穴です。
原因の63.4%は知識の欠陥 上位モデルに替えても直らない
いちばん多い原因は、言われなくても守るべきルールをAIが見落とす「知識の欠陥」で、63.4%を占めました。ユーザーの危険な指示をそのまま実行してしまうケースもここに入ります。
| 原因の分類 | 割合 | 中身 |
|---|---|---|
| 知識の欠陥 | 63.4% | 暗黙のルールを見落とす・危険な指示に従う |
| 目的の欠陥 | 23.1% | 安全より動かすことを優先する |
| 記憶の欠陥 | 13.5% | 前に決めた対策が途中で抜け落ちる |
研究チームは条件を変えて同じ作業をやり直させています。何も工夫しないと同じ脆弱性が25.7%で再発しました。プロンプトに「本番運用に耐えるものを」と書き添えると11.0%に下がり、セキュリティ強化用のスキルを足すと11.9%でした。
逆に技術的な指示を細かく書き込むと45.7%へ悪化しています。より上位のAIモデルに替えても結果はほとんど良くならず、悪くなる場合もあったそうです。
「本番運用に耐える」の1行をGPTとGeminiに試した
AInformationは10月7日に同じ1行の効き目を手元で確かめました。会員登録とログインができるFlaskのアプリを1ファイルで作らせ、指示の最後に「本番運用に耐えるものにしてください」を足す回と足さない回を比べています。GPT-6 Luna・GPT-6.1 Sol・Gemini 3.8 FlashにAPIの既定の設定のまま各5回、計30回投げました。
| モデル（1行なし→あり・各5回） | 秘密鍵をコードに直書き | CSRF対策 | ログイン回数の制限 |
|---|---|---|---|
| GPT-6 Luna | 0回→0回 | 5回→5回 | 0回→5回 |
| GPT-6.1 Sol | 0回→0回 | 5回→5回 | 0回→5回 |
| Gemini 3.8 Flash | 5回→0回 | 0回→5回 | 0回→0回 |
差がいちばん大きかったのはGemini 3.8 Flashです。1行なしでは5回とも秘密鍵を文字列で直書きし、debug=Trueのまま起動するコードを返しました。1行足すと5回とも鍵を環境変数から読み、CSRF対策も入りました。ただしログイン回数の制限は、1行足してもGeminiでは1回も入りませんでした。
GPTの2つは1行なしでもCSRF対策を入れていて、1行足すと5回ともログイン回数の制限が加わりました。代わりに返事は長くなり、待ち時間の中央値はGPT-6.1 Solで39.9秒から84.9秒に延びています。
数え方：返ってきたコードの文字を機械で数え、当たった行を目で見直した。パスワードのハッシュ化は30回すべてに入り、SQLを文字列でつなぐ書き方は0回だった。Claudeは今回APIの鍵が通らず試せていない。研究の数字は「やり直したときの再発率」で、今回の試験とは測り方が違う。
Claude CodeやCodexで公開する前に 足す1行と見る3点
指示文には「本番運用に耐えるものにしてください」を1行足しておくのがよさそうです。研究でも手元の試験でも効き目が出ました。一方で、使うライブラリや書き方まで細かく指示するのは避けたほうが無難です。研究では再発率が45.7%まで上がっています。
そのうえで、公開前に次の3点はコードを開いて自分で確かめておきたいところです。
- 秘密鍵やAPIキーがコードに直接書かれていないか
- debug=Trueのような開発用の設定が残っていないか
- ログインの総当たりを止める回数制限があるか
Claude CodeやCodexのような道具でも、作るのは同じAIです。モデルを上位に替えれば安全になるという考えは、今回の研究で崩れました。社内向けのちょっとした道具でも、外に公開する日だけは人の目を1回通すことになりそうです。
- バイブコーディング
- 自然言語で指示を出すだけでAIにアプリ全体を作らせる開発のやり方。プログラミングの専門知識がなくてもアプリを作って公開できる
企業の導入支援をしていると、現場の人がAIで作った小さな社内アプリを「せっかくだから取引先にも」と外へ出したがる場面によく出会います。危ないのはこの瞬間です。今回の試験でもGeminiは指示しだいで鍵の直書きをやめましたが、ログイン回数の制限は最後まで足しませんでした。指示文の1行は保険にはなっても検査の代わりにはなりません。情報システム部門は、外に公開するときだけ通す確認表を先に1枚作っておくと、止めずに済むとみています。
- バイブコーディングで作ったアプリはそのまま公開して大丈夫？
- そのまま公開するのは危ないです。Microsoftなどの研究者が公開中のバイブコーディング製Webアプリ200件を調べたところ、91%に少なくとも1つの脆弱性がありました。見つかった1186件の欠陥のうち65.77%は不正アクセスや漏えいにつながりうる「致命的」か「高」でした。秘密鍵の直書きや開発用の設定が残っていないかを公開前に確かめてください。
- 上位のAIモデルに替えれば安全なコードになる？
- 研究ではほとんど改善しませんでした。論文はより上位のモデルに替えても結果はほぼ変わらず、悪化する場合もあったとしています。原因の63.4%は言われなくても守るべきルールをAIが見落とす知識の欠陥です。モデル選びよりも指示文と公開前の確認のほうが効きます。
- プロンプトに何を書けば脆弱性が減る？
- 「本番運用に耐えるものを」と書き添えるのが効きました。研究では同じ脆弱性の再発が25.7%から11.0%に下がっています。AInformationの10月7日の試験でもGemini 3.8 Flashは5回とも秘密鍵の直書きをやめました。ただし技術的な指示を細かく書き込むと再発は45.7%に上がったので書きすぎは逆効果です。
この記事の出典
補助資料
- [1]ITmedia AI+この記事の元にした報道
出典の最終確認日：2026年10月7日
