バイブコーディングで見落としがちなセキュリティリスクと5つの対策

「バイブコーディングで作ったアプリ、セキュリティ大丈夫ですか？」——この質問を受ける回数が、2025年の後半から急に増えた。答えはシンプルで、何も対策しなければ大丈夫ではない。

バイブコーディングのセキュリティリスク、結論から言えば「AIが書いたコードは動くが、安全とは限らない」という一点に尽きる。コードが動くことと、本番運用に耐えることは別の問題だ。

受講者の中にも、AIが生成したコードをそのままデプロイして痛い目に遭った人がいる。僕自身、Cursorで作ったAPIのコードをレビューしていて、認証のバイパスが可能な実装を見つけたことがある。2025年の10月だったと思う。画面を二度見した。

この記事でわかること

バイブコーディングのセキュリティが甘くなる構造的な理由

なぜAIが書いたコードにセキュリティの穴が生まれるのか。根本的な原因は、AIの学習データにある。

GitHubの公開リポジトリには、セキュリティを考慮していないサンプルコードが大量に存在する。AIはそれらを学習しているから、「動くけど安全ではないコード」を平気で生成してしまう。特に認証やデータベース操作まわりでこの傾向が顕著だ。

AIコード生成の盲点

LLMは「最もありがちなコードパターン」を出力する傾向がある。セキュリティ対策は「ありがちでない追加処理」なので、明示的に指示しない限り省略されやすい。これがバイブコーディング最大の落とし穴だろうか。

AIが生成するデータベース操作コードで、最も多く見かける脆弱性がこれだ。ユーザーの入力値を直接SQL文に埋め込むコードを、AIは何の躊躇もなく書く。

僕が2025年11月にCursorで生成した予約管理アプリでは、検索機能のSQL文がまさにこのパターンだった。プレースホルダーを使わず、文字列結合でクエリを組み立てている。テストでは正常に動く。だが悪意あるユーザーが検索欄に特定の文字列を入れれば、データベースの中身を丸ごと抜き出せる状態。

対策はシンプルで、プレースホルダー（パラメータ化クエリ）を使うだけだ。AIに「SQLインジェクション対策を含めて」と一言プロンプトに加えれば、ほぼ確実に安全なコードが出てくる。問題は、その一言を知らないと加えようがないこと。

見た目では分からない

SQLインジェクションの脆弱性は、アプリの見た目や通常の操作では一切分からない。コードの中身を確認しない限り、危険な状態で運用し続けることになる。

Stripe、OpenAI、LINE——外部サービスとの連携に必要なAPIキーを、コードに直接書いてしまうパターン。これもAIが頻繁にやる。

先月、ある受講者がGitHubの公開リポジトリにOpenAIのAPIキーを含むコードをプッシュした。12時間後に気づいた時点で、そのキーで約8,000円分のAPI呼び出しが行われていたそうだ。GitHubには公開リポジトリを自動スキャンしてAPIキーを悪用するボットが存在する。

対策は環境変数（.envファイル）を使うこと。さらに.gitignoreで.envファイルをバージョン管理から除外する。この2つをセットで覚えておけば防げる。

「ログイン画面はあるのに、URLを直接叩けばログインなしでも管理画面に入れる」——こんな状態のアプリをこれまでに5件以上見てきた。全部バイブコーディングで作られたものだ。

AIは「ログインページを作って」という指示に対して、見た目のログインフォームは作る。ただし、他のページに認証チェックを入れるかどうかは、指示がなければやらないことが多い。認証と認可は別の概念だが、AIはその区別を曖昧にしがちではないだろうか。

掲示板やコメント機能を持つアプリで起きやすい。ユーザーが入力した文字列をそのままHTMLに表示してしまうと、悪意あるスクリプトが実行されかねない。

2025年の秋にBolt.newで作ったフィードバックフォームで、この問題に遭遇した。テスト入力に`