結論から言う。バイブコーディング（Vibe Coding）で生成したコードは「動く」だけであって「壊れない」保証はどこにもない。

筆者はSIer時代、官公庁系Webシステムの本番障害を何度も踏んできた。ログのタイムスタンプがUTCとJSTで混在していて原因特定が6時間遅れた夜がある。あの経験があるから断言する。AIが書いたコードを無検証で本番に載せる行為は、ログなしでデプロイするのと同程度のリスクを抱えている。

2026年に入り、CursorやClaude Codeを使って「プロンプトだけでアプリを作る」手法が急速に広まった。便利だ。だがX上でも「生成AIで作ったアプリが業務で使えない」という報告が増えている。想定外の入力で壊れる、データが消える、途中で止まる。AI生成コードが本番で壊れるのには構造的な理由がある。

AI生成コードはなぜ「動くけど壊れる」のか

AIコーディングツールは正常系を完璧に通す。プロンプトで指示した機能は、たいてい1回で動く。問題はその先だ。

異常系の処理がごっそり抜ける。想定外の入力、ネットワーク断、同時アクセス、権限不足。トレンドマイクロが2026年4月に公開した調査では、バイブコーディングで生成されたコードの45%が安全性に問題を抱えていた（Trend Micro: The Real Risk of Vibe Coding）。Georgetown大学CSETの検証では、主要5モデルが生成したコードの86%にXSS（クロスサイトスクリプティング）脆弱性が確認されている。

なぜこうなるのか。LLM（大規模言語モデル）は「機能を満たすコード」を最短で出力するよう最適化されている。セキュリティや耐障害性は「機能」ではないため、明示的に指示しない限り生成されない。これはツールの欠陥ではなく仕様上の挙動だ。

2026年前半に実際に起きたインシデント

数字だけでは掴みにくいので、報道済みの事例を挙げる。

2026年1月に公開されたAIソーシャルネットワーク「Moltbook」は、創業者が「1行もコードを書いていない」と公言していたサービスだ。公開から3日後、セキュリティ企業Wizの調査員が本番データベースの露出を発見した。流出したのはAPIトークン約150万件、メールアドレス3万5,000件、エージェント間のプライベートメッセージ。認証トークンの検証処理が一切実装されていなかったことが原因だった（Autonoma: Vibe Coding Failures）。

別の事例も深刻だ。Stripe決済のコードをAIに生成させた開発者が、シークレットキーがハードコーディングされた状態のままGitHubにプッシュした。ボットにスキャンされ、数時間後にはテスト決済が大量実行される事態に陥った。AI生成コードはヒューマンコードの約2倍の頻度でシークレットを露出させるという調査結果もある（3.2% vs 1.5%）。Georgia TechのVibe Security Radarによれば、2026年3月だけでAI生成コード起因のCVE登録が35件に達した。1月はわずか6件だった。増加速度が異常である。

「動いた」を「壊れない」に引き上げる検証項目

全項目を毎回やる必要はない。だが本番に載せるなら、最低限この4領域は確認すべきだと筆者は判断する。

入力バリデーションと境界値

AIは「想定通りの入力が来る」前提でコードを書く。空文字、null、極端に長い文字列、SQLインジェクション用の特殊文字——これらを手動で投げて、アプリが黙って落ちないか検証する。フォーム入力がある画面はすべて対象だ。

認証・認可の分離確認

AI生成コードで頻出するのが「認証は通るが認可がない」パターンである。ログイン機能は実装するが、他ユーザーのデータに横からアクセスできるIDOR（Insecure Direct Object Reference）が残る。APIエンドポイント単位で、自分以外のリソースにアクセスできないことを必ず検証する。

エラー時のデータ整合性

決済処理やDB書き込みが途中で止まった場合、データが中途半端な状態で残らないか。トランザクション制御の有無をコードレベルで確認する。筆者の経験上、ここが抜けているケースが最も多い。SIer時代にもバッチ処理の途中失敗で数千件のレコードが不整合になった現場を見てきたが、AIコードはこの種のガードを自発的には書かない。

シークレット管理

APIキー、DB接続文字列、OAuthシークレットがソースコードに直書きされていないか。以下のコマンドで検出できる。

grep -r "sk-" .
grep -r "AKIA" .
grep -r "password" . --include="*.env"

検出されたら環境変数か、AWS Secrets ManagerやGoogle Secret Manager経由で注入する設計に書き換える。

エンジニアがいない場合の現実的な対処

「レビューできるエンジニアがチームにいない」。この状況は珍しくない。それでも最低限やれることがある。

まず、CursorやClaude Codeのプロジェクト設定にセキュリティ要件を明示的に書く。Cursor なら .cursorrules、Claude Code なら CLAUDE.md に「APIエンドポイントには認可チェックを入れる」「シークレットは環境変数から読む」「入力値は必ずバリデーションする」と記述する。たったこれだけで生成コードの品質は変わる。プロンプトに書くのではなく、プロジェクトルートの設定ファイルに書く。毎回のプロンプトでは忘れるからだ。

次に、Snyk CLIやSemgrepのような静的解析ツールをCI/CDに組み込む。コードを読めなくても既知の脆弱性パターンは機械的に検出できる。Snyk CLIは無料枠があるため、個人開発でも導入障壁は低い。

そして本番デプロイの前に、最低1人はコードを通読する体制を作ること。全行を理解する必要はない。認証周り、DB操作、外部API連携の3領域だけでも目を通す。それすらできないなら、そのコードを本番に載せるべきではないと筆者は考える。

FAQ

バイブコーディングで作ったアプリは全部危険なのか？

プロトタイプや社内限定ツールなど、外部に公開しない用途であればリスクは限定的だ。問題になるのは外部公開かつ個人情報や決済を扱うケースで、ここは人間によるコードレビューが不可欠と判断する。

CursorとClaude Codeはどちらがセキュリティ上安全か？

2026年5月時点で、どちらもエンタープライズ向けSLAでは「ユーザーコードをモデル訓練に使わない」と明記している。セキュリティの差はツール側ではなく、利用者がレビュー工程を組み込んでいるかどうかに依存する。ツールの選定より運用設計のほうが重要だ。

AI生成コードの脆弱性を自動で検出するツールはあるか？

Snyk、Semgrep、GitHub Advanced Securityが代表的である。いずれもCI/CDパイプラインに組み込め、プルリクエスト単位でスキャンが走る。まずは無料のSnyk CLIから始めるのが現実的だ。

非エンジニアがバイブコーディングで業務アプリを作ること自体をやめるべきか？

やめる必要はない。ただし「作ったものを本番に載せる前にエンジニアか静的解析によるチェックを挟む」というルールは必須だ。コードを書く能力とコードの安全性を検証する能力はまったく別のスキルである。

参考文献