「バイブコーディングは危険」はもう古い “AI任せ”のコードに潜む4つのワナと回避策：デプロイ直前発覚の脆弱性は“罰”でしかない

Trend Microがバイブコーディングがセキュリティに与えるリスクやその対策について解説するブログを公開した。

[＠IT]

　セキュリティベンダーTrend Microは2026年3月31日（米国時間）、自然言語プロンプトからコードを生成する「バイブコーディング」（Vibe Coding）がセキュリティに与えるリスクについて解説するブログを公開した。

「バイブコーディングは危険」は本当か

　バイブコーディングとは、人間やAIエージェントが自然言語のプロンプトを基に本番環境向けのコードを生成するワークフローを指す。現時点では多くのコードが行単位の精査が不十分なまま生成されることが多く、IDE（統合開発環境）の単純な補完機能や標準的なコード支援ツールとは異なり、セキュリティに大きな影響を及ぼすという。

「開発者の不注意」ではなく、自然な変化

　従来の開発には、コードを書き、レビュー、テストし、議論するという「手間」が組み込まれており、デプロイはそれを経た後だった。バイブコーディングではこのプロセスをスルーすることが多い。

従来の開発フローとバイブコーディングの違い（提供：Trend Micro）

　プロンプトから生成されたコードを見た開発者の多くは、たった1つの問い、「これは動くか？」に集中する。「安全かどうか」という問いも「自分はこのコードが何をしているか完全に理解しているか」という問いも、後回しになる。これは開発者の不注意によるものではなく、こうした開発スタイルに伴う自然な変化といえる。

　バイブコーディングが既存のセキュリティコントロールを取り除くわけではないが、その圧倒的なスピードによって、レビューやポリシー承認といった既存のプロセスを押しやってしまう。

　結果として本番コードは意図通りに動き、基本的なテストも通過するが、深いレビューや脅威モデリング、セキュリティ検証は経ていない。機能が到達点となり、セキュリティは「後で対応するもの」になる。

“AI任せ”のコードに潜む4つのワナ

　AIはコードを単独で生成するわけではない。プロンプトはビジネスロジックだけでなく、フレームワークの選択やヘルパーパッケージ、実装のショートカットを伴うことが多い。具体的には以下4つのリスクが生じる。

1. 意図しない依存関係
   OAuth（認可プロトコル）ログインのプロンプトが、開発者が明示的に選択していないヘルパーライブラリやスターターテンプレートを取り込む場合がある
2. 危険なデフォルト（既定）設定
   生成されたサービスが、デモ用には問題ないが本番環境では危険な、過剰なログ設定や広過ぎるネットワークバインディングを引き継いでしまう
3. 脆弱（ぜいじゃく）なシークレット（認証情報や秘密鍵）処理
   プレースホルダーのシークレットやテストトークンがそのまま残る
4. 正常系のみのロジック
   有効なユーザーに対しては動作するが、認可の境界条件や不正利用の制限、エラーハンドリングなどが考慮されていないコードになる

　こうした変更は「ちょっとしたヘルパー関数」「簡単なエンドポイント」として過小評価されやすい。しかし、重要なのは、セキュリティ負債は1つの重大なミスではなく、デプロイのプレッシャーの下で行われる何百もの合理的な判断の積み重ねで形成されるという点だ。

セキュリティ負債が無数の判断の積み重ねで形成されるプロセス（提供：Trend Micro）

責任の所在がバラバラに断片化してしまう

　バイブコーディングの大きなリスクは、「責任者がいない」ことではなく、責任の所在がバラバラに断片化してしまうことにある。コミッターは記録に残っても、開発の意図や生成プロセス、依存関係の根拠、レビューの独立性は不明確になりがちだ。責任はプロンプト作成者、AIエージェント、レビュワー、サービスオーナーに分散する。

　開発者が去り、チームの流儀を無視したAI独特のコードが残されると、ささいな不具合の修正が困難を極める。「このコードを誰が生成したか」「このライブラリはなぜ追加されたか」「この動作は仕様かバグか」「これをいじって壊れないか」――。こうした調査に費やされる時間は、当初の短縮された開発時間を容易に食いつぶしてしまう。

　さらに深刻なのは、同じAIシステムでコードの生成と検証の両方を行うケースだ。これはレビューの形は成していても、実態としては「職務分離」が完全に機能不全に陥っていることを意味する。

4つのリスク回避策

　バイブコーディングが定着した現実を前提に、セキュリティはソフトウェア構築方法に適応する必要がある。Trend Microは4つの実践的な転換を挙げている。

• 問題を早期に検知する
  遅いアラートより早いシグナルが有効
• ガードレール（安全対策）を自動化する
  セキュリティをプロンプト入力時の開発者の記憶に依存しない
• 共有コンテキストに集中する
  開発チームとセキュリティチームが引き継ぎなしで同じ問題を確認できるようにする
• セキュリティをワークフローに最適化する
  作業を止めないセキュリティをワークフローに組み込む

デプロイ直前発覚の脆弱性は“罰”でしかない

　Trend Microは、個別ツールの寄せ集めでは、この課題には対応できないと指摘する。チームが普段からリスクを管理している場所であるCI/CD（継続的インテグレーション／継続的デリバリー）ワークフローにセキュリティを直接統合することが重要になるとしている。

　開発プロセスの早い段階でセキュリティ情報を提示することも重要だという。早い段階ならば、開発を助けるガイダンスになるからだ。しかし、デプロイ直前の最終段階で突き付けられる脆弱性は、開発者にとって手戻りを強いる「ペナルティー」として受け取られてしまう可能性がある。

　Trend Microは「バイブコーディングは無謀な行為ではない。無謀なのは、そのリスクを無視することだ。真のリスクは、AIが安全でないコードを書くことではなく、人間がセキュリティを確保する機会を持てないまま、コードをデプロイしてしまうことにある」と指摘している。