「動くコード」は「安全なコード」ではない——バイブコーディングの5つのセキュリティ急所と反脆弱な開発実践
AIで開発速度が上がった分、セキュリティリスクが静かに蓄積されている現実を、数字と事例で突きつけるセッションレポートだ。
出典: 「動くコード」は「安全なコード」ではない！ バイブコーディングの5つのセキュリティ急所と反脆弱な開発者・チームになるための実践
要点 (事実のみ)
- Developers Summit 2026でのKyohei氏のセッション。バイブコーディングを「使っている」参加者は会場の8〜9割だったが、AIコードのセキュリティレビューを「したことがある」参加者は約1割に激減した。
- Kyohei氏はURLを変更するだけでアクセスできる公開バケット上に、1万件超の個人情報が放置されている実態を独自調査で発見した。
- Aikido Securityが450名のCISOを対象に実施した調査では、5分の1の組織で生成AIのコードに起因する深刻なインシデントが発生し、69％の企業がすでに脆弱性を発見している。
- 2025年7月に発生した女性向けマッチングアプリ「Tea」の大規模情報漏洩では、身分証明書7万2000件と110万件のプライベートメッセージが完全公開状態になった。原因はBaaSのストレージルールの設定ミスとされる。
- AIは「認証付きのAPIを作って」と指示されなければ認証を実装しない。RLHFの影響で「簡潔で正しく見えるコード」を出力する傾向があり、入力値のサニタイズや所有権チェックが省略されやすい。
徐 聖博の見解
このセッションが示す構造を、私は「仕様の不作為によるリスク」と呼ぶのが適切だと思っている。AIは指示されたことに忠実で、指示されていないことは行わない——この一文は、AI開発補助ツールを使い始めた頃から私自身が実感していた問題の核心だ。
弊社でも受託開発・AIエージェント開発を日常的に行っており、AIが生成したコードをそのまま使う頻度は明らかに増えている。だからこそ、セキュリティ要件を「プロンプトで明示する」習慣を開発フローに組み込む必要性を痛感している。認証・認可・入力バリデーション・シークレット管理といった防御的処理は、AIにとって「機能要件外」として処理されやすい。これは AI の欠陥ではなく、要件定義の欠陥だ。
記事が提示する「脆弱・堅牢・反脆弱」の3段階分類は実務的に有用だ。四半期ペネトレーションテストが毎日のデプロイと噛み合わない点も、CI/CDを回している現場では耳が痛い指摘だろう。私が重要だと考えるのは、発注側の中小企業がバイブコーディングでMVPを素早く作る場面でも、この「セキュリティは要件として書かなければAIの視界に入らない」という原則は変わらない点だ。AIが生成したコードのレビューを「コスト」と見るか「品質保証の最低ライン」と見るかが、今後の開発現場での分岐点になる。
(編集レンズ: 実装・運用視点 / 発注側・中小企業・開発実務への含意)
