AIが生成したコードの45%にセキュリティの欠陥がある。機能は動く。でも安全ではない。
これは一つの企業が出した数字ではない。Veracode、CMU、Wuhan University、Tenzai——複数の独立した研究機関が、それぞれ異なる方法で同じ結論に至った。AIコード生成のセキュリティ問題は、特定のツールや使い方の問題ではない。構造的な問題だ。
45%、10.5%、69件——何の数字かわかるか
45%は、AIが生成したコードが OWASP Top-10（セキュリティの重大問題リスト）の脆弱性を含む確率だ。10.5%は、AIエージェントが作ったコードで機能的にも安全にも合格したものの割合。69件は、5つのAIコーディングツールが作った15アプリから見つかった脆弱性の総数だ。
どれも2025年から2026年にかけて発表された研究の数字だ。バイブコーディングがブームになってから、研究者たちはAI生成コードのセキュリティを体系的に調べ始めた。その結果が、一致して同じことを示している。
「AIが書いたから大丈夫」はなぜ幻想なのか。データから読み解く。
なぜ「動く」と「安全」は別の話なのか
AIモデルは、インターネット上にある膨大なコードを学習した。問題は、インターネット上のコードの多くが「動く」コードであって「安全な」コードではないことだ。
セキュリティヘッダーを設定していないサーバー、CSRF（後述）対策が抜けたフォーム、XSSに無防備なAPIレスポンス——こうした実装は世の中にあふれている。AIはその現実を学んだ。だから「動くが安全でない」コードを量産することになる。
Veracodeの CTO Jens Wessling は2025年のレポートでこう述べた。「モデルは正確なコードの生成では向上しているが、セキュリティでは改善していない。大きいモデルが小さいモデルより著しく優れているわけでもない。これはスケーリング問題ではなく、システム的な問題だ」
スケーリング、つまりモデルを大きくすれば解決する話ではない。コードが動くかどうかは学習データから拾えるが、セキュリティは「文脈を読んだ設計判断」が必要だ。AIが苦手とする領域だ。
研究1: Veracode — 100以上のモデルを80タスクで試した
セキュリティベンダーのVeracodeは、2025年7月に「2025 GenAI Code Security Report」を公開した。100以上のLLMを80のコーディングタスクでテストした大規模な調査だ（2025年10月に更新版も出ている）。
主な結果：
- 全体の45%のケースで OWASP Top-10 脆弱性を導入した
- Java は72%が失敗（最も危険な言語）
- Python、C#、JavaScript は38〜45%が失敗
- XSS（ページに悪意あるスクリプトを埋め込む攻撃）: 86%が安全なコードを生成できず
- ログインジェクション（ログへのデータ混入）: 88%が失敗
- 暗号実装: 14%が弱いアルゴリズムを使用
- SQL インジェクション（データベースへの不正命令）: 20%が失敗——比較的得意
Java で作られた AI コードは 72% が OWASP Top-10 の脆弱性を含む。「AI に Java を書かせれば 4 件中 3 件は欠陥品」という現実だ。
注目すべきは2年以上モデルが進化しても、セキュリティの数値がほぼ変わっていないことだ。2025年10月の更新で GPT-5 Mini が72%のセキュリティ通過率（過去最高）を出した。それでも4件に1件は脆弱性を持ち込むという現実は変わらない。
研究2: SusVibes（CMU）— 動いても安全なのは1割
Carnegie Mellon University（CMU）の Language Technologies Institute を中心に、Columbia University、Johns Hopkins University、HydroX AI が共同で実施した研究がある。論文名は「Is Vibe Coding Safe? Benchmarking Vulnerability of Agent-Generated Code in Real-World Tasks」。arxiv（2512.03262）で公開されている。
この研究が他と異なるのは、「実世界のフィーチャーリクエスト」を素材にした点だ。オープンソースリポジトリから収集した200件の実際の機能追加タスク、平均172行・複数ファイルにまたがる変更を SWE-Agent + Claude Sonnet で評価した。
結果：
- 機能テストを通過: 61%
- 機能的に正しく、かつセキュリティも通過: 10.5%
機能が正しく動いたコードのうち、8割超がセキュリティテストで落ちた。「動く＝安全」のギャップが、数字で見えた瞬間だ。
論文はこう結論づけている。「フロンティア LLM はセキュリティで非常に低い性能を示し、80%超のセキュリティテストで失敗した」
さらに示唆的な発見がある。セキュリティを意識したプロンプト（「セキュリティを考慮して実装して」という指示）を加えても改善しなかっただけでなく、機能性が約6%低下した。「AIに頼むときにセキュリティと言えばいい」という考えは、データが否定している。
研究3: Tenzai — 5ツール・15アプリ・69件の脆弱性
セキュリティ企業のTenzaiが2025年12月に実施し、2026年1月13日に公開した監査レポートは、現場の実態を直撃している。
Claude Code、OpenAI Codex、Cursor、Replit、Devinの5ツールに、同じプロンプト・同じスタックで各3アプリを作らせた。計15アプリを丸ごとセキュリティ監査にかけた。
結果は69件の脆弱性（Critical 6件、Low-Medium 約45件、残りはHigh）。
特に目を引くのは「全ツール共通の失敗」だ：
- SSRF（サーバーサイドリクエストフォージェリ）: 全5ツール、15/15アプリで検出
- CSRF（クロスサイトリクエストフォージェリ）保護: 0/15アプリ（2アプリが試みたが不完全）
- セキュリティヘッダー（CSP、HSTS、X-Frame-Options 等）: 0/15アプリ
SSRF とは、サーバーを踏み台にして内部ネットワークへのリクエストを送らせる攻撃だ。例えばサーバー上のアプリに「この URL のコンテンツを取得して」と命令すると、攻撃者は http://169.254.169.254/（クラウドのメタデータサーバー）を指定して、APIキーやインスタンス情報を抜き出せる。
逆に、SQL インジェクションや XSS（悪意あるスクリプト埋め込み）は0件だった。既知のパターンに対する防御は得意だが、アプリケーション全体の設計として考慮すべきヘッダーや認証保護は見落とす——この非対称性が、データから見えてくる。
Tenzai の結論は明確だ。「コーディングエージェントは安全なアプリを設計するという信頼を置けない」
研究4: Wuhan University ほか — GitHub Copilot の実コードを解剖
中国の武漢大学（Wuhan University）、ニュージーランドの Massey University、オーストラリアの RMIT University らの研究チームが、GitHub の実リポジトリから収集した GitHub Copilot 生成コードを分析した。ACM TOSEM 2025 に掲載された実証研究だ。
「実際に使われているコードを調べる」という方法は、実験室的な評価より信頼性が高い。分析対象は733スニペット、38の CWE カテゴリ（脆弱性分類）にまたがる。
結果：
- Python: 29.5%にセキュリティ問題
- JavaScript: 24.2%にセキュリティ問題
- 全体: 実際の GitHub プロジェクトで使われているコードの約3割に問題
研究5: Lovable — 1645アプリを自動スキャンして170件の欠陥を発見
ここまでは「研究室の話」と思った人もいるかもしれない。では実際に公開されているアプリはどうか。
2025年3月、セキュリティ研究者の Matt Palmer 氏がバイブコーディングツール「Lovable」で作られたアプリに深刻な欠陥を発見した。Superblocks のブログによると、自動スキャナーで1,645アプリを調査したところ、170アプリ（10.3%）に RLS（Row Level Security——データベースへのアクセス制御）の設定ミスまたは未設定が確認された。露出した情報はサブスクリプション情報、氏名、電話番号、API キー、決済情報、Google Maps トークンなどの個人情報だ。この脆弱性は CVE-2025-48757 として登録され、CVSS スコア（深刻度の指標）は9.3（Critical）だ。
その後 Lovable が「セキュリティスキャン」機能を追加した。しかし 2026年2月、セキュリティ研究者の Taimur Khan 氏が単一アプリで16件の脆弱性（うち6件 Critical）を発見し、18,000人超のデータ漏洩を確認した（The Register, 2026年2月）。Lovable のセキュリティスキャンは RLS の「存在」のみチェックし、設定が正しいかどうかは確認しない。「スキャンをパスした＝安全」ではなかった。
AIが得意なものと苦手なものの非対称性
5つの研究から見えてくるパターンがある。
SQL インジェクションや XSS は、「これをやってはいけない」という明確なルールがある。AIはそのルールを学習データから拾える。だからTenzaiの監査で0件だった。
一方、SSRF や CSRF、セキュリティヘッダーは、「アプリケーション全体の設計として何を考慮すべきか」という問いに答える必要がある。URLの検証、クロスオリジンのリクエスト管理、HTTP レスポンスの制御——これらは「コードを書く」行為ではなく「何を設定すべきかを知る」行為だ。AIは誰かが「これも入れて」と言わない限り、省略する。
比喩で言えば、AIは玄関の鍵のかけ方は知っているが、窓の鍵締め忘れや勝手口の存在を気にしない施工業者に近い。頼まれた仕事はする。頼まれていない安全確認はしない。
具体例で見る——AIが見落とすコードパターン
SSRF（サーバーサイドリクエストフォージェリ）
Tenzai の監査で15/15アプリが引っかかった脆弱性だ。
// ❌ AI が生成しやすいコード（SSRF 脆弱性あり）
// URL パラメータをそのままサーバーから取得する
app.get("/preview", async (req, res) => {
const url = req.query.url as string;
const response = await fetch(url); // ← 任意の URL に接続できてしまう
const html = await response.text();
res.send(html);
});
// ✅ 安全なコード（許可リスト方式）
const ALLOWED_PREFIXES = ["https://example.com", "https://trusted-cdn.com"];
app.get("/preview", async (req, res) => {
const url = req.query.url as string;
if (!ALLOWED_PREFIXES.some((prefix) => url?.startsWith(prefix))) {
return res.status(400).json({ error: "URL not allowed" });
}
const response = await fetch(url);
const html = await response.text();
res.send(html);
});
AIは「外部の URL を取得して返す」という機能を実装する。「取得先が安全かどうかを検証する」という設計は、明示的に頼まなければ入れない。
セキュリティヘッダー（0/15アプリで未設定）
// ❌ Tenzai 監査で 15/15 アプリが未設定
// セキュリティヘッダーが一切ない素のレスポンス
// AI はデフォルトでこれを生成する
// ✅ next.config.ts でヘッダーを追加
const nextConfig = {
async headers() {
return [
{
source: "/(.*)",
headers: [
{ key: "X-Frame-Options", value: "DENY" }, // クリックジャッキング防止
{ key: "X-Content-Type-Options", value: "nosniff" }, // MIME タイプ偽装防止
{ key: "Referrer-Policy", value: "strict-origin-when-cross-origin" },
{
key: "Content-Security-Policy",
value: "default-src 'self'; script-src 'self'",
},
],
},
];
},
};
セキュリティヘッダーは HTTP レスポンスに添えるメタ情報だ。「このページを他のサイトに埋め込ませない」「外部からスクリプトを読み込ませない」といった指示をブラウザに伝える。AIはアプリを動かすコードは書くが、このような「動作に直接影響しない防御設定」は省略する。
暗号実装（Veracode データより）
# ❌ AI が使いがちな弱い暗号（MD5 は 2004 年に衝突耐性が破られている）
import hashlib
password_hash = hashlib.md5(password.encode()).hexdigest()
# ✅ 安全なパスワードハッシュ（bcrypt を使う）
import bcrypt
hashed = bcrypt.hashpw(password.encode(), bcrypt.gensalt(rounds=12))
Veracode の調査では、14%の AI 生成コードが弱い暗号アルゴリズムを使っていた。MD5 はファイルのチェックサム用途には使われ続けているため、学習データに大量に含まれている。パスワードのハッシュ化に使うのは2004年以降不適切とされているが、AIはその区別を自動ではしない。
数字をまとめる
ここまでの研究データを並べると、現状がわかりやすくなる。
CodeRabbit が470件の GitHub PR を分析した調査（2025年）では、AI 生成コードは人間のコードと比べて XSS が2.74倍、安全でないオブジェクト参照が1.91倍多い。
Sonar の調査（2026年1月）では、96%の開発者が AI 生成コードを信用していないと答えた。しかしコミット前に確認するのは48%にとどまる。問題を知っていても行動が伴っていない。
バイブコーダーが今すぐできること
数字を並べたのは怖がらせるためではない。何をすればいいかを考えるためだ。
研究データが示す「AI の苦手領域」に対して、コストをかけずに手を打てる方法がある。
1. AI に「セキュリティレビューもして」と頼む
CMU の研究では、セキュリティプロンプトで改善しなかったという結果が出ている。ただし、これは「完全に解決しない」という話であって「まったく効果がない」ではない。Tenzai の監査が発見した CSRF 未設定や SSRF については、「このコードにセキュリティ上の問題はあるか？特に SSRF、CSRF、セキュリティヘッダーについて確認して」と明示的に聞くことで、問題が見つかることがある。
知識がなければ聞けない。だから何が弱点かを知っておくことに意味がある。
2. SAST ツールを導入する
SAST（静的アプリケーションセキュリティテスト）とは、コードを実行せずにソースコードを分析してセキュリティ問題を検出するツールだ。
- Semgrep（無料枠あり）: コードをスキャンして OWASP 系の問題を検出
- Snyk（無料枠あり）: 依存パッケージの脆弱性も合わせて検出
- GitHub Code Scanning（パブリックリポジトリは無料）: GitHub に組み込めるスキャン
コードを書いた直後にスキャンをかける習慣をつけるだけで、既知のパターンは自動的に検出できる。
3. Next.js アプリにセキュリティヘッダーを追加する
Tenzai の監査で全アプリが未設定だったセキュリティヘッダーは、next.config.ts に数行追加するだけで設定できる。前述のコード例がそのまま使える。
securityheaders.com に自分のアプリの URL を入れると、どのヘッダーが設定されているかをスコアで確認できる。デプロイ前に確認する習慣をつけるといい。
4. Supabase の RLS 設定を確認する
Lovable の事例が示すように、RLS の設定ミスは「スキャンをパスしても問題がある」ケースがある。Supabase の RLS は「有効にした」だけでなく「正しいポリシーを設定した」まで確認が必要だ。
Supabase ダッシュボードで各テーブルの RLS ポリシーを開き、「認証済みユーザーが自分のデータだけ読める」設定になっているか目視で確認する。
「システム的な問題」の意味
Veracode の CTO が「スケーリング問題ではなく、システム的な問題」と言ったことに立ち返ろう。
2年以上モデルを大きくしても、セキュリティの数値はほぼ変わっていない。GPT-5 Mini が過去最高の通過率を出しても、4件に1件は欠陥を持ち込む。これはどのモデルを使っても、現時点では根本解決されていない問題だということだ。
ツールの選択や設定で解決できる問題ではない。AI が生成したコードは、人間がセキュリティを確認するという前提で使うしかない。
バイブコーディングで動くものができた。その次のステップは「安全かどうかを確認する」だ。確認を習慣にするためのコストは、インシデントを起こしてから対処するコストよりはるかに低い。
参考研究・ソース