バイブコーディングのセキュリティは大丈夫？生成AIで作ったアプリに潜む脆弱性とOWASP対策
バイブコーディングで作ったシステム、そのまま運用して大丈夫？生成AI時代に増える「動くけれど危ないアプリ」
生成AIの普及によって、システム開発のハードルは劇的に下がりました。
ChatGPTやClaude、Cursorなどに、
「顧客管理画面を作って」
「ログイン機能を追加して」
「Supabaseと接続して」
「管理画面からデータを編集できるようにして」
と指示すれば、以前ならエンジニアが何日、場合によっては何週間もかけていたものが、数時間で形になることも珍しくありません。
いわゆる**「バイブコーディング（Vibe Coding）」**です。
これは非常に大きな変化です。
一方で最近、
「AIで社内システムを作ったものの、このまま業務で使って大丈夫なのか不安」
「ある程度完成しているので、セキュリティを含めて一度ちゃんと見てほしい」
「担当者がAIで作ったが、退職してしまい、中身がよく分からない」
といった相談も出てくるようになりました。
なぜこのようなことが起こるのでしょうか。
結論から言えば、
「アプリを動かすこと」と「安全に運用できるシステムを作ること」は、まったく別の仕事だからです。
バイブコーディングの何がすごいのか
最初に強調しておきたいのは、バイブコーディング自体が悪いわけではないということです。
むしろ弊社でも、生成AIを活用したAI駆動開発を積極的に利用しています。
特に生成AIが強いのが、
- UIの作成
- CRUD画面の作成
- APIのひな形
- DBアクセス処理
- フォーム作成
- デザイン調整
- テストコード作成
- リファクタリング
などです。
例えば、
「顧客一覧をカード形式で表示して、ステータス別に色を変えてください」
と指示すれば、かなりそれらしい画面が短時間で完成します。
以前なら、
設計
↓
HTML/CSS
↓
Reactなどで実装
↓
API作成
↓
DB接続
と進めていたものを、AIがまとめて作ってくれます。
その結果、
「もうほとんど完成しているのでは？」
と感じやすくなりました。
ここに、生成AI開発特有の落とし穴があります。
UIが完成すると「システムも完成した」ように見える
システム開発には、大きく分けると、
見える部分
と
見えない部分
があります。
ユーザーから見えるのは、
- ログイン画面
- 一覧画面
- 検索
- 登録フォーム
- グラフ
- ボタン
- メニュー
などです。
生成AIは、この「見える部分」を作るのが非常に速い。
そのため、開発開始から数時間で、
「かなりできている」
ように見えます。
しかし、本番運用で重要になるのはむしろその裏側です。
例えば、
- 認証
- 認可
- 権限管理
- 入力値検証
- APIアクセス制御
- セッション管理
- 暗号化
- 秘密情報管理
- ログ管理
- 監査ログ
- バックアップ
- エラー処理
- Rate Limit
- CSRF対策
- XSS対策
- SQL Injection対策
- 依存ライブラリ管理
- 脆弱性管理
などです。
これらは基本的に画面からは見えません。
つまり、
UIはきれいなのに、裏側では危険な状態
というシステムが簡単に出来上がってしまいます。
「ログインできる」と「認可されている」は違う
特に生成AIで作ったシステムを確認するときに注意したいのが、認証と認可の違いです。
例えば、
一般ユーザー
管理者
という2種類のユーザーが存在するとします。
画面上では、
一般ユーザーには管理者メニューを表示しない。
これだけならAIでも簡単に実装できます。
しかし、
https://example.com/admin/users
へ直接アクセスしたらどうでしょうか。
さらに、
GET /api/users/123
の「123」を「124」に変更したら、別の利用者の情報が取得できないでしょうか。
UIからボタンを隠すことと、サーバー側でアクセス権限を制御することは別です。
そしてOWASP Top 10:2025でも、Broken Access Control（アクセス制御の不備）がA01、つまり最上位のリスクとして挙げられています。
見た目だけではまず分からない部分です。
「AIが作ったから危険」なのではない
ここは誤解してほしくないポイントです。
問題は、
AIがコードを書いたこと
そのものではありません。
人間が書いても脆弱なコードは当然存在します。
問題なのは、
「動いたからOK」という判断で、本来必要なレビュー工程まで省略されてしまうこと
です。
生成AIによって、
アイデア
↓
実装
↓
動作
までが猛烈に速くなりました。
一方、
要件定義
↓
脅威分析
↓
設計レビュー
↓
コードレビュー
↓
セキュリティテスト
↓
権限テスト
↓
脆弱性診断
↓
運用設計
は、自動的にはついてきません。
ここにギャップがあります。
実際、AI生成コードはどのくらい安全なのか
AIによるコード生成については、セキュリティ面の研究も進んでいます。
Veracodeが2025年に公表した調査では、100以上のLLMをJava、Python、C#、JavaScriptなどの課題で評価したところ、生成されたコードサンプルの45%が同社のセキュリティテストを通過しなかったと報告されています。
もちろん、これはあらゆるAI生成コードの45%に脆弱性があるという意味ではありません。
評価条件が設定されたベンチマーク結果です。
しかし重要なのは、
「最新の高性能AIに作らせれば、セキュリティも自動的に担保される」とは限らない
という点です。
AIは、
「正常系で動くコード」
については非常に優秀になりました。
一方で、
「悪意を持ったユーザーがどう攻撃するか」
「想定外の入力をされたらどうなるか」
「別ユーザーになりすましたらどうなるか」
「APIを直接叩かれたらどうなるか」
といった観点は、別途チェックする必要があります。
OWASP Top 10で見れば問題が見えてくる
Webアプリケーションのセキュリティを確認するときによく利用されるのがOWASP Top 10です。
2026年9月現在の最新版であるOWASP Top 10:2025では、次の10項目が挙げられています。
- アクセス制御の不備
- セキュリティ設定の不備
- ソフトウェアサプライチェーンの不備
- 暗号化の不備
- インジェクション
- 安全性を欠いた設計
- 認証の不備
- ソフトウェアまたはデータの完全性の不備
- セキュリティログとアラートの不備
- 例外的な状況への不適切な対応
これを眺めても分かるように、
「画面が正しく表示されるか」
という話はほとんど出てきません。
セキュリティとは、その裏側の設計の問題だからです。
バイブコーディングで特に起こりやすい問題
弊社がAIで作られたシステムを見る場合、例えば次のような部分を確認します。
1. 認証はあるが、認可が弱い
ログイン機能はある。
しかし、
「誰がどのデータを見ていいか」
という制御が不十分になっているケースです。
これは非常に注意が必要です。
2. APIを直接叩くことが想定されていない
画面上では操作できなくても、
ブラウザのDeveloper ToolsやHTTPクライアントからAPIを直接呼ぶと操作できてしまう。
フロントエンドだけで制御している場合によく起こります。
3. APIキーや秘密情報がコードに含まれている
例えば、
OPENAI_API_KEY
DATABASE_URL
SUPABASE_SERVICE_ROLE_KEY
AWS_ACCESS_KEY
などです。
環境変数として適切に管理すべき情報が、ソースコードやフロントエンド側へ入っていないか確認する必要があります。
Gitリポジトリに一度コミットした場合は、単純に現在のファイルから消すだけでは不十分なこともあります。
4. 入力値チェックが弱い
ユーザーから入ってくるデータを、そのままDBやHTMLへ渡してしまう。
結果として、
SQL InjectionやXSSなどにつながる可能性があります。
OWASP Top 10:2025でもInjectionはA05に位置付けられています。
5. ライブラリを大量に追加している
AIに、
「これを実現してください」
と頼むたびに、
npm install XXXXX
が増えていくことがあります。
その結果、
「なぜこのライブラリが入っているのか分からない」
状態になります。
OWASP Top 10:2025では、新しい重要項目としてSoftware Supply Chain FailuresがA03に位置付けられています。
AI時代には特に重要なポイントです。
6. エラー時の挙動が考慮されていない
通常操作では問題ない。
しかし、
- DBが落ちた
- APIがタイムアウトした
- 外部サービスが停止した
- 想定外の値が返ってきた
- 同時操作が発生した
という場面でおかしくなる。
生成AIによる高速開発では、正常系を先に完成させることが多いため、こうした例外系が後回しになりやすくなります。
OWASP Top 10:2025でも、例外的な状況への不適切な対応がA10として新たに整理されています。
AI機能が入ると、さらにチェック項目が増える
生成AIそのものをシステムへ組み込む場合は、通常のWebセキュリティだけでは足りません。
OWASPでは、LLM・生成AIアプリケーション向けにもTop 10を公開しています。
例えば、
- Prompt Injection
- Sensitive Information Disclosure
- Supply Chain
- Improper Output Handling
- Excessive Agency
- System Prompt Leakage
- Vector and Embedding Weaknesses
- Unbounded Consumption
などです。
例えばAIエージェントへ、
「メール送信」
「DB更新」
「ファイル削除」
「外部API実行」
まで許可する場合、
単にチャット画面を作るのとはリスクがまったく違います。
AIに与える権限が大きくなるほど、
「AIが何をできるか」
ではなく、
「AIにどこまでやらせてもよいか」
という設計が重要になります。
AI機能そのものを開発するときの備えは機密情報を守るために実施していることに書いています。
バイブコーディングをやめる必要はない
ここまで読むと、
「それならAIでシステムを作らない方がいいのでは？」
と思うかもしれません。
弊社は逆だと考えています。
生成AIを使えば、以前とは比較にならない速度でシステムを作れます。
特に、
バイブコーディングが向いている領域
- アイデア検証
- PoC
- プロトタイプ
- UIモック
- 社内業務の簡易ツール
- 要件整理
- 小規模な自動化
では非常に強力です。
例えば「この業務をシステム化するとどうなるか」を確認するために数百万円をかける必要はなくなりました。
まずAIで作って、
実際に触ってから考える。
これは非常に合理的です。
問題は「PoC」と「本番システム」の境界がなくなること
最も危険なのは、
試しに作る
↓
意外と使える
↓
社内で使う
↓
顧客情報を入れる
↓
利用者が増える
↓
いつの間にか基幹業務になる
というパターンです。
最初は3人だけで使う予定だった。
気付けば30人が使っている。
最初はダミーデータだった。
気付けば顧客名、住所、契約情報が入っている。
こうなると、
プロトタイプとして許容できた設計が、そのまま本番システムになってしまいます。
PoCから先へ進めるときの作り方の違いはバイブコーディングと仕様駆動開発の違いで整理しています。
「作り直す」必要はない場合も多い
逆に、
「AIで作ったから全部作り直しましょう」
という話でもありません。
既存システムを調査して、
UI
業務ロジック
DB構造
認証
認可
API
ライブラリ
インフラ
ログ
バックアップ
などを整理すれば、
既存資産を残しながら安全性を高められる場合があります。
例えば、
Step 1
現状のコード・インフラを調査
Step 2
OWASP Top 10などを基準にリスクを洗い出す
Step 3
重要度を付ける
Critical
High
Medium
Low
Step 4
Critical / Highから修正
Step 5
自動テスト・静的解析・依存関係チェックなどをCI/CDへ組み込む
Step 6
運用ルール・監視・バックアップを整える
という進め方も可能です。
重要なのは、
AIで作ったか、人間が作ったかではなく、現在どの程度安全なのかを確認すること
です。
セキュリティは最後に一度チェックして終わりではない
そしてもう一つ重要なのが、
セキュリティは納品直前のチェック工程ではない
ということです。
NISTのSecure Software Development Framework（SSDF）でも、安全なソフトウェア開発を、
- 組織・開発環境を準備する
- ソフトウェアを保護する
- 安全性を考慮して開発する
- 発見された脆弱性へ対応する
という継続的な開発プロセスとして整理しています。
つまり、
AIで作る
↓
最後だけセキュリティチェック
ではなく、
AIで高速に作る
↓
設計レビュー
↓
AIで実装
↓
自動テスト
↓
セキュリティチェック
↓
人間によるレビュー
↓
本番
↓
監視・アップデート
という形にしていく必要があります。
これから必要なのは「AIを使わない開発」ではなく「AIを管理できる開発」
生成AIによって、コードを書く速度は今後さらに上がっていくでしょう。
すると開発のボトルネックは、
コードを書くこと
から、
コードが正しいか、安全か、運用可能かを判断すること
へ移っていきます。
だからこそ今後のシステム開発では、
「AIを使っています」
だけでは十分ではありません。
重要なのは、
- どのような設計基準で作っているか
- どのようなレビューをしているか
- どのようなテストをしているか
- どのようなセキュリティ基準を使っているか
- AIにどこまで権限を与えているか
- 誰が最終的に責任を持って確認するか
まで含めたAI開発のガバナンスです。
「AIで作ったシステムを一度見てほしい」という相談が増える理由
これまでシステム開発には専門家が必要でした。
そのため、
設計
→ 開発
→ テスト
→ 運用
という工程がある程度セットになっていました。
しかし生成AIによって、
開発だけが極端に簡単になりました。
これは素晴らしい変化である一方、
専門家が担当していた、
- アーキテクチャ
- セキュリティ
- 非機能要件
- 保守性
- 可用性
- 障害対応
- データ保護
まで自動的についてくるわけではありません。
その結果、
「アプリを作れる人」は急増した一方、「そのシステムを安全に運用できるか判断できる人」はそれほど急には増えていない。
このギャップが現在起きているのだと思います。
本番へ上げる前に一度見てほしい、というご相談は作る前から一緒に考えるシステム開発で承っています。
まとめ：バイブコーディングは「入口」として非常に強い
バイブコーディングは、システム開発を大きく変える技術です。
これまで、
「予算がないから作れない」
「エンジニアがいないから試せない」
と思われていたアイデアを、すぐ形にできます。
これは間違いなく大きなメリットです。
一方、
「作れるようになったこと」と「安全に運用できるようになったこと」は同じではありません。
画面が動いている。
ログインできる。
DBに登録できる。
AIが回答してくれる。
これだけでは、本番システムとして安全とは判断できません。
これからは、
生成AIによる圧倒的な開発速度
と
従来のシステム開発で培われてきた設計・テスト・セキュリティ・運用の知識
を組み合わせることが重要になります。
弊社でもAIを積極的に開発へ取り入れています。
ただし、「AIに全部作らせて終わり」ではなく、AIを使うことで実装速度を高めながら、人間が設計・レビュー・セキュリティ・品質を管理することを重視しています。
すでに生成AIやバイブコーディングでシステムを作っていて、
- このまま本番運用してよいか分からない
- セキュリティ面が不安
- 作った本人以外、中身を理解していない
- 顧客情報を入れてよいのか判断できない
- OWASP Top 10などに沿って確認したい
- 今あるシステムを捨てずに改善したい
といった場合は、**「作り直す前に、まず現状を診断する」**という選択肢もあります。
生成AI時代だからこそ、
速く作ることと、安全に運用することを分けて考える。
これがこれからのシステム開発では、ますます重要になっていくと考えています。
