バイブコーディング時代に潜むセキュリティの急所とは？
「バイブコーディングを使って開発している方は？」セッション冒頭でこう問いかけると、会場の8〜9割が手を挙げた。続けて「その中で、AIが作ったコードのセキュリティレビューをしたことがある方は？」と問うと、挙手は約1割にまで激減した。
Developers Summit 2026のセッション「バイブコーディングの罠：開発者が知るべきセキュリティの急所」に登壇したKyohei氏は、この落差を指し「皆さん、バイブコーディングへの不安感を感じているのではないか」と切り出した。
同氏は外資系IT企業でエンジニアとして活動する傍ら、GitHubでスター数4000を超えるPDF帳票ライブラリ「pdfme」のオープンソース開発者でもある。自身もpdfmeの開発において脆弱性報告を受けて修正した経験があり、その際の「ヒヤリとした個人体験」が、セキュリティの啓発活動を始めるきっかけになったという。
セキュリティの啓発活動を始めてから、自身が独自に行った調査では、URLを変更するだけで誰でもアクセスできる公開バケット上に、1万件超の個人情報が放置されている実態を発見した。
「自分が発見した1万件の裏には、何百倍もの脆弱性や個人情報漏洩が隠れているはずだ」とKyohei氏は語る。実際、Aikido Securityが450名のCISOを対象に実施した調査でも、5分の1の組織で生成AIの生成コードに起因する深刻なインシデントが発生しており、69％の企業がすでに脆弱性を発見しているという。
「知識なき完成が最も危険だ」とKyohei氏は断言する。たとえば、2025年7月に発生した女性向けマッチングアプリの大規模情報漏洩（Tea事件）では、会員登録前に提出された身分証明書7万2000件と、110万件のプライベートメッセージが完全に公開された状態になっていた。この原因は、BaaSのストレージルールにおける設定ミスである。
この事件からも、AIが生成した「動くコード」が、必ずしも「安全なコード」とは限らないことがうかがえる。
「反脆弱」な組織とは？ AIが安全なコードを書かない原因
Kyohei氏は、セキュリティへの向き合い方を以下の3段階に整理する。
- 脆弱：AIに丸投げし、検証も学習もしない個人やチーム。攻撃を受けると簡単に壊れる。
- 堅牢：外部診断やレポートに依存してセキュリティを守る状態。ストレスには耐えるが成長しない。
- 反脆弱：セキュリティを自分たちで所有し、インシデントから学び続けることでかえって強くなる個人や組織。
このうち「堅牢」なアプローチの問題は、四半期ごとのペネトレーションテストが、AIを用いた日々のデプロイと相性が悪い点にある。診断時点のスナップショットに対して修正を完了した直後から、新たな脆弱性が混入するリスクがあるためだ。四半期ごとの診断と毎日のデプロイのギャップを、外注だけで埋めることには限界がある。
そこで目指すべきなのが、3つ目の「反脆弱」である。その前提として、まずは「AIが防御的なコードを書かない根本原因」を理解しなければならない。
たとえば「認証付きのAPIを作って」と明示的に指示しなければ、AIは認証機能を実装しない。セキュリティの欠陥は、要件として定義されない限りAIの視界には入らない。さらに、人間のフィードバックによる強化学習（RLHF）の影響により、AIは「簡潔で正しく見えるコード」を出力する傾向がある。そのため、入力値のサニタイズや所有権のチェックといった防御的な処理が省略されやすい。
「AIは指示されたことに忠実であり、指示されていないことは行わない」──この構造を理解することが、次に挙げる5つの急所を学ぶ前提となる。
