実際のところ、バイブコーディングで開発されたアプリの安全性は？

実際のところ、バイブコーディングで開発されたアプリの安全性は？

元論文：Understanding the (In)Security of Vibe-Coded Applications

今回の研究は、実際に公開されている、バイブコーディングで開発されたWebアプリの安全性を検証したものです。

【補足：バイブコーディング】
バイブコーディングは、Claude CodeやCodex等のAIツールに、実際の開発に関わる作業の大部分を委ねる方法のことです。

研究の方法

1. Webアプリの抽出

著者らは検証にあたって、Claude CodeやLovableなどのAIツールを利用した痕跡があるGitHubのリポジトリ（コードや変更履歴をまとめて保存する保管庫）を抽出しました。

そして、その中から「最初の変更がAIによるもので、かつ変更履歴とコードの双方で『AI作成』と判定された割合が90％以上」のリポジトリ（9,041件）が選ばれ、最終的に200種類のWebアプリが無作為に抽出されました。
なお、説明用の資料のみのリポジトリは除外されています。

2. 脆弱性の評価

著者らは、2種類のAIの組み合わせ（Claude Code＋Claude Sonnet 4.6、GitHub Copilot＋GPT-5.3-Codex）と2種類の安全性チェックのスキルを組み合わせ、各Webアプリを4通りの方法で監査しました。

最初は11,150件の指摘が挙がりましたが、セキュリティの専門家である2人の著者がそれぞれコードと公開されたアプリをチェックし、最終的に両者が「実際に悪用されるおそれがある」と判断した脆弱性（1,186件）だけが採用されました。

結果

1. 200種類中182種類のWebアプリで、何らかの脆弱性が検出された

200種類のWebアプリのうち182種類で少なくとも1件の脆弱性が検出され、Webアプリ1種類あたりの脆弱性の中央値は6件、平均は6.52件となっていました。
また、脆弱性が見つからなかった18種類のWebアプリも含めると、全体の脆弱性の平均は5.93件でした。

今回検出された脆弱性のうち、特に件数が多かったのは以下の3点です。

• アクセス制御の不備（339件）：誰がどの情報を閲覧・変更してよいかを制限する仕組みの不備。
• インジェクション（199件）：外部からの入力を不適切に扱うことで、意図しない処理が引き起こされる問題。
• 認証の不備（176件）：ユーザーが誰であるかを確かめる仕組みの不備。

加えて、見つかった脆弱性の65.77％が「Critical」または「High」というリスクに分類されました。

2. 原因としては、「ユーザーが明確に指示しなかった状況で、本来必要な安全対策を入れ忘れる問題」が最も多かった

著者らは、脆弱性が生じるまでの原因を、以下の3種類のグループに分類しました。

• 記憶に関する欠陥（160件、13.5％）：「安全対策が必要な部分まで反映されていない」「後回しの作業を忘れる」など。
• 目的に関する欠陥（274件、23.1％）：「デモの動作を優先して簡易化した仕組みを使う」「エラーの修正のために、安全対策を弱める」など。
• 知識に関する欠陥（752件、63.4％）：「危険な指示に従う」「存在しない仕組みを前提にする」「必要な安全対策を省く」「公開後の保守管理をユーザー任せにする」など。

そして最も多かったパターンは、「ユーザーが明確に指示しなかった状況で、本来必要な安全対策を入れ忘れる（658件、55.5％）」でした。
これは、「ログイン機能を作るなら、パスワードを確認する」「データを表示するなら、閲覧権限があるかを確認する」といった安全対策の実装を忘れるようなイメージです。

著者らはこの結果に関して、「ユーザーがこれらを具体的に指示しなかったからといって、AIがこれらの安全対策の実装を省略して良いわけではない」と解釈しています。

3. 指示や環境を改善することで、脆弱性の再発が減少した

次に著者らは、再現が可能な70件の脆弱性に関して、脆弱性が混入する前の状態から同様の機能の追加をやり直しました。

その結果、設定を特に変更しなかった場合は210回中54回（25.7％）で再び脆弱性が検出されましたが、安全対策を強化するスキルを追加した条件では210回25回（11.9％）、実際の環境で利用できる状態を求めた場合は210回中23回（11.0％）に減少しました。

一方、技術的な指示を増やした場合は逆に210回中96回（45.7％）となり、設定を変更しなかった場合より高い再発率となりました。
著者らは、「仕様を文字どおり実装することが優先された結果、安全性に関する判断の余地が狭くなった」と考察しています。

注意点

• 全てのバイブコーディング製Webアプリを対象とした研究ではありません。
• 人間主体で作ったWebアプリとは比較されておらず、「バイブコーディング製Webアプリは、人間主体のWebアプリよりリスクが高い」と結論づけることはできません。
• 新たな脆弱性を含む安全性は検証されていません。

---

責任と能力の不一致

バイブコーディングの成果物の保守管理は、ユーザーの役目

基本的に、一度公開したアプリの保守管理の体制は、アプリを提供・運営する側が整える必要があります。
その際、アプリを提供・運営する側がそのまま保守管理を担うこともあれば、外部に保守管理を委託するケースもあると思いますが、いずれのケースでも専門知識を持つ人たちが保守管理をすることになるでしょう（あくまで私の推測です）。

一方、個人がバイブコーディングでアプリを開発・公開する場合は、保守管理はユーザー自身で行わなければならないことが多いですが、バイブコーディングはコーディングやセキュリティの専門知識なしでもできてしまうことから、十分な知識や能力を持たないユーザーが保守管理を担うことになるケースも多いと考えられます。

「責任と能力の不一致」というリスク

「安全性の管理を求められる人が、その判断に必要な知識や手段を持っていない」という状況でも、情報を一方的に表示するだけで利用者の情報を収集しないアプリの場合は、比較的リスクが低いといえるでしょう。
しかし、仮に「ログイン機能」「データの保存や共有」「個人情報の取り扱い」「決済機能」などを備えたハイリスクなアプリの場合は、以下のようなリスクが増えるかもしれません。

• 個人情報や認証情報が外部に流出する。
• 権限のない人に、データを閲覧・変更・削除される。
• 脆弱性や不正アクセスに気づかず、知らない間に被害が広がる。
• 必要な更新や修正が行われず、セキュリティホールが放置される。
• 障害やデータの消失が起きても、適切に復旧できない。

アプリ内で取り扱う情報の重要性やリスクが高いほど、保守管理を担う側は重い責任を負うことになりますし、その責任を全うするために高い能力が必要になります。
しかし、その重い責任を全うできるだけの能力や手段が欠如している場合は、十分な安全性の確保ができず、利便性よりリスクが先行する可能性があります。

このような「責任と能力の不一致」は、AIが開発から管理までこなせるようになったこともあり、ユーザー（開発）側が認識しづらくなっているかもしれません。

「大丈夫、AIが保守管理までやってくれるから」

では、AIが全く使えない状況になったらどうしますか？

「バイブコーディングでアプリを開発したから、AIが使えない状態で保守管理できません」では、責任を果たしているとは言えないでしょう。
有益なアイデアがバイブコーディングでアプリになるのは素晴らしいことですが、アプリを完成させて終わりではなく、最後まで責任を持って管理しなければならないことを忘れてはなりません。