バイブコーディングの脆弱性は、プロンプト一文でほぼ半減すると判明

Claude CodeやLovableにチャットで指示してアプリを作り、レビューする時間も技術力もないまま、そのまま公開ボタンを押したことはないだろうか。公開したあとになって「これ本当に大丈夫なんだろうか」と不安がよぎった人も多いはずだ。

Microsoft、シンガポール国立大学などに所属する研究者らが、実際に公開されているそうしたアプリを大規模に監査した論文を発表している。結論はシンプルだ。プロンプトに「本番運用に耐える実装にして」という一文を加えるだけで、脆弱性が作り込まれる割合をほぼ半分まで下げられる。一方で、指示を詳しく専門的に書くことは、効果が薄いどころかむしろ危険を増やす場合がある。何が原因で、何が効くのか。実験の中身を追っていく。

公開アプリの9割に脆弱性があった

この論文は2026年6月に発表され、9月に最新版が出ている。研究者らは、Claude CodeとLovableで作られたオープンソースのアプリ9,041件を収集した。そのうちWebアプリは8,695件、実際に一般公開されているものは984件あった。この984件から無作為に200件を抽出して監査したところ、論文によれば91.0%から少なくとも1件の脆弱性が見つかった。発見された脆弱性は合計1,186件、そのうち65.77%がCriticalまたはHighに分類される深刻なものだった。

脆弱性の種類は偏っている。多いのは権限チェックの不備(Broken Access Control)、注入攻撃(Injection)、認証の不備(Authentication Failures)の3種類だ。論文によれば、合わせて全体の60.2%を占める。

実際にこの3種類がどれほど深刻になり得るかを示す例が、NVDの脆弱性データベースに登録されている。Lovableが生成したサイトの一部で、データベースの行レベルセキュリティ(Row-Level Security)の設定が不十分だった。登録名はCVE-2025-48757、深刻度を表すCVSSスコアは10点満点中9.3にあたる。認証されていない第三者が、他人のデータへ自由にアクセスできる状態だった。

なぜここまで高い割合で、しかも同じような種類の不備が繰り返されるのか。

原因を分ける3つの欠陥クラス

論文によれば、研究者らは発見した1,186件の脆弱性を1件ずつ読み、コードとコミット履歴から「どう作り込まれたか」を分類した。2人が独立にラベルを付け、一致率(Cohen’s κ)は0.82。議論を重ねて統合した結果、8つの失敗パターンが、3つの欠陥クラスにまとまった。

この表から分かるのは、脆弱性の6割以上が「AI自身が気づいていない」ことに起因するという点だ。単純な不注意や手抜きより、知識の欠落が主因になっている。

知識の欠陥 暗黙のルールを守れない

最大の原因は「hidden security rules(暗黙の安全規則)」で、658件(55.5%)がここに属する。論文が挙げる例では、外部から受け取ったデータをそのままdocument.writeで画面に書き込んでいた。必要なエスケープ処理を省いたため、反射型XSS(クロスサイトスクリプティング)が生まれていた。認証情報のハッシュ化やサーバー側での権限チェックなど、ユーザーが「言わなくても当然やってくれる」と思っている作業ほど、プロンプトには明示されない。AIエージェントも、明示されない要件を自分から補うとは限らない。

目的の欠陥 デモ優先の設計

274件(23.1%)は、動くことを優先した結果として生まれる。代表例が「demo-oriented design」(174件)だ。OAuthのトークンをbase64エンコードしただけでブラウザのlocalStorageに保存していた。コードのコメントには「デモ用だから」と残っていた。もう一つの「function-fix side effects」(100件)は、認証エラーを解消するために認証そのものをバイパスするコードを足してしまうパターンだ。見た目には動くようになるため、そのまま残りやすい。

記憶の欠陥 直したのに伝わらない

160件(13.5%)は、一度加えた対策が他の場所まで行き渡らないケースだ。最多の「incomplete change propagation」(110件)はこうだ。新しく追加したAPIルーターにだけ認証ミドルウェアを適用し、既存の11個のハンドラーには適用し忘れていた。もう一つの「forgotten obligations」(50件)はこうだ。パスワード検証をTODOコメントとして残したまま、そのTODOが実行されないまま本番環境へ出てしまう。

ここまでが原因の分類だ。では、プロンプトの書き方を変えれば、この割合は実際に動くのか。

プロンプトで脆弱性は減るのか

論文によれば、研究者らは実際に脆弱性が作り込まれた70件を選び、その直前の状態までコードを巻き戻してから、条件だけを変えて同じ依頼をAIエージェントにやり直させた。条件は「エージェントハーネス(AIの安全確認の仕組み)」「モデルの強さ」「プロンプトの書き方」の3要素のうち1つだけを変える設計にした。8パターンそれぞれを3回ずつ、合計70×8×3=1,680回実行している。

基準となる条件は、既定のハーネス・中位モデル(GPT-5.6-Terra)・短い非専門的なプロンプトの組み合わせだ。この基準では、210回の実行中54回(25.7%)で元の脆弱性が再発した。4回に1回は、同じ失敗を繰り返したことになる。

この基準に対して、残り7つの条件はそれぞれどう動いたのか。

詳しいプロンプトほど危険だった

論文のTable 4にある、この8条件の再発率を比べたものだ。基準(25.7%)以外の7条件のうち、下がったのは4条件、上がったのは3条件ある。最も効果が大きかったのは、プロンプトに「ready for production(本番運用に耐える)」と一文を加えた条件で、11.0%まで下がった。次いで、既定のハーネスにセキュリティ強化スキルを足した条件が11.9%。

自分はここで予想が外れた。「詳しく、専門的に指示を書くほど安全になるはずだ」と思っていたからだ。実際には逆で、プロンプトを変えた4パターンの中では、より専門的で詳細な技術指示にした条件だけが基準より悪化し、45.7%(+20.0ポイント)を記録した。これは8条件全体で見ても最大の悪化幅で、モデルを弱くした条件(39.5%)より高い再発率になっている。

なぜ詳しい指示がかえって裏目に出るのか。論文は、詳細な技術指示がエージェントに要求仕様をより文字通りに従わせ、自分自身の安全判断を働かせる余地を減らすためだと分析している。「production」という一言は、安全な実装の既定値をエージェント自身の中から呼び出すだけで、判断の余地を奪わない。一方、技術的に細かく指定された仕様は、その指定を満たすことが最優先の目標になり、指定されていない安全対策は後回しになる。

モデルを強くする方向も、思ったほどの効果はなかった。弱いモデルから中位モデルへは13.8ポイントの改善があった。一方、中位モデルから最上位モデルへはむしろ0.5ポイント悪化しており、改善が止まるどころか逆転していた。「性能を上げれば安全になる」という前提も、ここでは崩れている。

ただし、どの条件でも脆弱性の再発をゼロにはできていない。最も効果的だった条件でも11%は再発している。論文はこれを「エージェントはセキュリティ上のリスクを認識していても、それを安全な実装に反映できないことがある」という認識と実装の落差として指摘している。

今日からできる対策

ここまでの結果から、読者が今すぐプロンプトに反映できる対応は次の2つになる。

• 依頼の最後に「本番運用に耐える実装にして」といった一文を加える。技術的な詳細を積み増すより、この短い一文のほうが効果が大きかった
• 既定のハーネスに、公開されているセキュリティ強化スキルを追加する。論文が実験で使ったのは、Addy Osmani氏がGitHubで公開しているスキルだ

逆に、優先度が低いと分かった対応もある。プロンプトを専門的で詳細な技術指示に変えることは、効果が薄いどころか悪化させる可能性がある。モデルを最上位のものに変えるだけでは、大きな改善は見込みにくい。

まとめ

公開されているバイブコーディングアプリの91.0%に脆弱性があり、65.77%は深刻度の高いものだった。原因を分類すると、不注意よりも「AIが気づいていない暗黙のルール」が6割以上を占める知識の欠陥が最大だった。

プロンプトの書き方を変える実験では、「本番運用に耐える実装にして」という一文が、モデルを強くするよりも効果的に脆弱性の再発を減らした。一方、指示を詳しく専門的に書くことは、プロンプトを変える対応の中で唯一、基準より悪化する結果になった。どの対策も再発をゼロにはできない。それでも、プロンプトに一文を加えること、公開されているセキュリティ強化スキルを使うことは、今日から試せる具体的な対応として確認されている。