AIコーディングツールが「動くコード」を生成するのは得意だ。しかし「安全なコード」を生成するのは、まったく別の話である。

この記事でわかること：

  • なぜAI生成コードにセキュリティ問題が集中するのか
  • 実際に起きたバイブコーディング由来のデータ漏洩事例
  • 今日から実践できる7つのセキュリティ対策
  • AIが繰り返す「ハードコードされた認証情報」問題の本質

バイブコーディングとは何か

「バイブコーディング（vibe coding）」とは、自然言語でAIに指示を出してコードを生成させる開発スタイルだ。Andrej Karpathy氏が2025年初頭に提唱し、Cursor、Claude Code、GitHub Copilotといったツールの普及とともに広まった。

2025年の調査では、開発者の75%が何らかの形でバイブコーディングを利用しており、90%がそれを有用だと評価している（参考）。開発速度が3〜4倍になるという報告もあり、個人開発者から企業チームまで急速に採用が広がっている。

問題は「速く動く」と「安全に動く」のあいだにある深い溝だ。

AI生成コードは機能するが安全ではない

カーネギーメロン大学の研究では、AIエージェントが生成したコードのうち61%が機能テストを通過した。しかしセキュリティテストを通過したのは、そのうちの10.5%にとどまった（参考）。

機能する10のコードのうち、9つに悪用可能な脆弱性が残っている計算になる。

Cloud Security Allianceの調査では、AI生成コードの45%以上に危険な脆弱性が含まれるとしている。人間の開発者がAIを使うと開発速度は3〜4倍になる一方、脆弱性の混入は10倍に増えるという（参考）。

Waseem et al.（2025）が7つのバイブコーディング製MVPをスキャンしたところ、970件のセキュリティ問題が発見された。そのうち801件が高深刻度だった。

よく見つかる問題は以下の通りだ。

  • ハードコードされたAPIキー・JWTシークレット・データベースパスワード
  • アクセス制御の不備（誰でも他ユーザーのデータを読める状態）
  • 認証ロジックの省略
  • 入力値の検証・サニタイズなし
  • セッション有効期限の未設定

「supersecretjwt」問題

セキュリティ企業Invictiが20,000以上のバイブコーディング製アプリを分析したところ、AIモデルが同一の認証情報を繰り返し生成していることが判明した。

“supersecretkey”という文字列は、分析した20,000アプリのうち1,182件で同一のJWT署名秘密鍵として使われていた。これはGPT-5が最もよく生成するJWTシークレットの文字列でもある（参考）。

予測可能なJWTシークレットがあれば、攻撃者は管理者トークンを偽造してダッシュボードに侵入できる。認証が存在しているように見えて、完全に迂回できる状態だ。

実際に起きたデータ漏洩

バイブコーディング由来のセキュリティ事故はすでに複数起きている。

AIソーシャルネットワーク「Moltbook」では、Supabaseのセキュリティ設定漏れにより150万件のAPI認証トークン、64,000件のユーザーメールアドレス、4,060件のプライベートメッセージが外部から読める状態になった。プライベートメッセージの一部にはOpenAI APIキーが平文で含まれていた。

プラットフォーム「Base44」では、公開されているアプリIDだけで他ユーザーのプライベートアプリにアクセスできる欠陥が発見された。バイブコーディング製の営業アプリでは、AIが認証とレート制限を省略したために侵害を受けた事例もある。

なぜプロンプトに「安全に書いて」と書くだけでは足りないのか

CMUの研究は、プロンプトに「安全なコードを書いてください」という指示を加えた場合も検証した。共通脆弱性一覧（CWE）を提示したり、回避すべき脆弱性の種類を明示したりするパターンも試した。

いずれも効果は限定的だった。それどころか、セキュリティに注力させると機能の正確さが下がるという逆効果も見られた。研究チームは「プロンプトは解決策ではない。セキュリティは実行中のアプリケーションに対して独立してテストされるべき第一級の目標である」と結論づけている。

AIコーディングアシスタントが不安全なコードを生成するのは、プロンプトの書き方の問題ではない。テストの仕組みの問題だ。

今日から実践できる7つの対策

1. 認証には既存のライブラリを使う

AIが生成した認証ロジックは使わない。Clerk、Supabase Auth、Auth0などの実績あるライブラリを明示的に指定する。「セキュアなログインフォームをClerk認証で実装して」のように、ライブラリ名を含めてプロンプトを書く。

2. APIキーをAIチャットに貼り付けない

APIキーや秘密鍵は環境変数（process.env）で管理する。AIとの会話にキーを直接貼り付けると、プロンプト履歴にキーが残り、ログやキャッシュを通じて漏洩するリスクがある。

3. JWTの有効期限を設定する

JWTトークンは最大7日で失効させ、リフレッシュローテーションを設ける。有効期限なしのトークンは、一度漏洩すると無期限に悪用される。

4. .gitignoreを最初に作る

プロジェクト開始時の最初のファイルとして.gitignoreを作成する。.envファイル、シークレットキー、設定ファイルがリポジトリに混入しないよう、コード生成を始める前に設定する。

5. ユーザー入力を常にバリデーションする

すべてのフォーム入力・APIリクエストに対して、バリデーションとサニタイズを明示的に指示する。「parameterization（パラメータ化）」「sanitization（サニタイズ）」という用語をプロンプトに含めると、AIがSQLインジェクションやXSSの対策コードを生成しやすくなる。

6. TruffleHogなどでシークレットをスキャンする

CI/CDパイプラインにシークレットスキャナを組み込む。指示していても、AIが誤ってAPIキーをコードに含めることがある。TruffleHogはGitリポジトリ内の認証情報を自動検出する。

7. 外部公開前にセキュリティレビューを依頼する

コードが完成したら別の会話でAIに「このコードをセキュリティエンジニアとして見直して、OWASP Top 10の観点でチェックして」と依頼する。生成したAIと同じ会話では行わず、新しいコンテキストで確認する。

見落とされがちなプロンプトインジェクションのリスク

バイブコーディングのセキュリティリスクは、生成されたコードだけに限らない。AIエージェント自体を標的にした攻撃がある。

開発者が外部のコーディングルールファイル、フォークされたリポジトリ、MCPサーバー設定をエディタに取り込むとき、エージェントはそれらを信頼できるコンテキストとして読み込む。攻撃者はそのファイルに悪意ある指示を隠す手法を使い始めている。

Liu et al.（2025）の研究では、この間接プロンプトインジェクション攻撃がCursorとGitHub Copilotに対して最大84%の成功率を示した。SSHキーの窃取から権限昇格まで、コマンドの範囲も幅広い（参考）。

外部から持ち込むファイルは、コードと同様にセキュリティの観点から確認する必要がある。

バイブコーディングは続く、だからこそ対策が必要

バイブコーディングは開発の速度と裾野を大きく変えた。非エンジニアがアプリを作り、個人開発者が数時間でMVPを立ち上げられる時代になった。

その速度は維持したまま安全性を確保するには、AIへの指示の書き方を工夫するのではなく、開発プロセス全体にセキュリティのチェックポイントを組み込むことが必要だ。シークレット管理、認証ライブラリの選定、スキャンの自動化——これらはいずれも一度設定すれば繰り返し使えるものばかりだ。

最初の数十分を準備に使うことで、後から生じる大きなリスクを避けられる。