バイブコーディングのセキュリティリスクと対策｜AIコード生成の落とし穴

バイブコーディングは便利だが、セキュリティを無視すると事故になる

バイブコーディングで「AIに任せれば何でもできる」という風潮が広がっていますが、セキュリティリスクを理解せずに使うのは危険です。AIが生成するコードには脆弱性が含まれることがあり、本番環境にそのままデプロイすれば重大なインシデントにつながります。

私自身、Claude Codeで開発中にAIがrobots.txtを勝手に変更し、未完成のクライアントサイトが検索エンジンにインデックスされてしまったインシデントを経験しています。この記事では、バイブコーディング特有のセキュリティリスクと、実務で効果のあった具体的な対策を解説します。

バイブコーディング特有の3つのリスク

1. AIが意図しない変更をする

バイブコーディングでは、AIがプロジェクト全体を理解した上で「最適」と判断した変更を自律的に行います。しかし、AIの「最適」と人間の「正解」は一致しないことがあります。

私が経験したrobots.txtのインシデントはまさにこれです。AIはサイトの公開準備を「最適化」する一環としてインデックスを許可する設定に変更しましたが、そのサイトはまだ非公開の段階でした。CLAUDE.md（ルールファイル）に「robots.txtを変更しない」と記載していましたが、AIは約80%の精度でしか指示に従いません。残りの20%で事故が起きます。

2. 生成コードの脆弱性

AIが生成するコードには、SQLインジェクション、XSS（クロスサイトスクリプティング）、認証の不備といったセキュリティ脆弱性が含まれる可能性があります。特に非エンジニアがバイブコーディングで開発する場合、生成されたコードの安全性を自分で判断できないため、脆弱なコードがそのまま本番に入るリスクが高まります。

3. 機密情報の漏洩

バイブコーディングではプロジェクト全体のコードをAIに読み込ませるため、APIキー、環境変数、顧客データがAIのコンテキストに含まれることがあります。MCP（外部サービス連携）を使っている場合、AIが外部APIに機密情報を送信してしまうリスクもあります。

実務で効果のあった4つの対策

対策1: Hooks（強制的なガード）を設定する

Claude CodeのHooks機能を使えば、AIがツールを実行する前後にスクリプトを強制実行できます。CLAUDE.mdが「お願い」なら、Hooksは「法律」です。

たとえば、PreToolUse Hookで「robots.txtの編集をブロック」「本番ブランチへの直接pushを防止」といった絶対に破らせたくないルールを強制できます。私はrobots.txtのインシデント以降、すべてのプロジェクトでこの設定を導入しています。

対策2: Permissions（deny設定）で編集範囲を制限する

settings.jsonのPermissions設定で、ファイルパスやコマンド単位で「許可（allow）」「拒否（deny）」を設定できます。Hooksよりさらに厳格な制御です。

私の運用では、プロジェクトの機密性に応じてPermissionsの厳しさを変えています。クライアント案件など機密性が高い開発ではdenyを厳しく設定し、自社のコンテンツ制作など機密性が低い案件では緩めにする。この使い分けが実務では重要です。

対策3: 公開前の品質チェックを自動化する

PostToolUse Hookを使って、コードや成果物が生成された直後に品質チェックを自動実行します。具体的には以下をチェックしています。

クライアント特定情報（社名・URL・個人名）の漏洩がないか
APIキーや環境変数がコードにハードコードされていないか
基本的なセキュリティパターン（入力値のバリデーション等）が守られているか

対策4: 不要なMCP接続を外す

MCPは便利ですが、常にAPI経由で外部サービスと情報をやり取りするため、情報漏洩のリスクは常にあります。使っていないMCPを接続したまま放置することはセキュリティ的にメリットがありません。プロジェクトが終わったら外す、使わないものは接続しない——このシンプルな原則を守るだけでリスクは大幅に下がります。

非エンジニアがバイブコーディングで守るべき最低限のルール

コードの中身を完全に理解できなくても、以下の3つを守れば大きな事故は防げます。

本番デプロイ前に必ず誰かにレビューしてもらう: 自分で判断できないなら、エンジニアやAIセキュリティに詳しい人に確認を依頼する
.envファイル（環境変数）をGitにコミットしない: APIキーや秘密鍵が公開リポジトリに露出する事故は、バイブコーディングで最も多い失敗パターン
AIの変更を鵜呑みにしない: 「AIが変更したから正しい」ではなく「AIが変更したからこそ確認する」。Trust but Verify（信頼するが検証する）の姿勢が不可欠