AIに書かせる前に決めろ。Forresterが示した“Secure Vibe Coding”3つの実装原則で、三部作の答え合わせをする

三部作の答え合わせをしよう

バイブコーディングの170個の裏口。Lovable製アプリ10.3%にセキュリティ欠陥が見つかった件を、元・挫折エンジニアが本気で調べたでは、Lovable（ラバブル）製アプリ1,645個から170個のセキュリティ欠陥が見つかった話を書きました。AIが生成した「コード」に穴がある事件。

Cursor CEOが「自社ツールは脆い基盤を作る」と認めた日。ゼロクリック脆弱性CurXecuteが突きつけた、バイブコーディングの次の問いでは、Cursor（カーソル）本体にゼロクリック遠隔コード実行の脆弱性「CurXecute（カーゼキュート）」が発見された話を書きました。AIコーディング「ツール自体」が攻撃経路になる事件。

コードが危ない。ツールも危ない。じゃあバイブコーディングはやめるべきなのか。

答えはNoです。やめるのではなく、やり方を変える。今回はその具体的な方法を書きます。

Forrester（フォレスター）のアナリストJanet Worthington（ジャネット・ワーシントン）氏が公式ブログで提唱した概念があります。“Secure Vibe Coding”。安全なバイブコーディングはパラドックス（矛盾）ではなく、パラダイム（新常識）だと。

この言葉が三部作の結論です。犯人探しより設計変更。後付けのセキュリティレビューではなく、生成プロセスそのものに安全を組み込む。

数字が示す「動くけど安全じゃない」現実

まず現状を正確に把握しましょう。感覚ではなく、データで。

Veracode（ベラコード）の2025年レポートが衝撃的な数字を出しています。100を超えるLLM（大規模言語モデル）を評価した結果、安全なコードになったのは55%。残り45%は既知のセキュリティ欠陥を含んでいた。

半分近くが穴あき。しかも2026年春のアップデートでも傾向は変わっていません。GPT-5やClaude 4.6世代でも「セキュリティ天井」は破れていない。モデルが賢くなれば安全になるだろう、という期待は裏切られた格好です。

もう1つ。スタンフォード大学のSVIBESベンチマークの結果がさらに鋭い。SWE-AgentとClaude 4 Sonnetの組み合わせで、機能テストに正解したのは61%。そのうち安全だったのは10.5%。

機能テストに合格したコードでも、6本に1本しか安全じゃない。私が信条にしている「動けばOK」は、セキュリティに関しては完全に間違いだったわけです。正直に認めます。

そしてForresterの2025年予測では、2026年までに75%の技術意思決定者が技術的負債を中〜高の深刻度と感じると予測しています。AIでコードを大量生成した結果、セキュリティ負債が積み上がっている。75%が「やばい」と感じている状態で、後付けレビューでは追いつかない。

Forresterが提唱する“Secure Vibe Coding”とは何か

Worthington氏は自身でCursorを使ってバイブコーディングを試した上で、ブログ記事にこう書いています。

生成されたコードに入力サニタイズ（ユーザー入力の安全な処理）が欠けていた。レート制限（連続アクセスの制御）もなかった。APIキーが平文で埋め込まれていた。

これは私もClaude Codeで経験があります。動くものはすぐできる。でもセキュリティ設定が抜けている。第1弾のLovable事件と同じ構造です。

Worthington氏の結論はこうです。AI支援開発の時代でもDevSecOps（開発・セキュリティ・運用の統合）の基本は免除されない。ただし開発者の役割は変わる。「プログラマー」から「エージェントオーケストレーター（AIエージェントの指揮者）」へ。

コードを書く人から、AIに何を書かせるかを設計する人へ。この転換が“Secure Vibe Coding”の核心です。

Forresterの2026年予測レポートでは、バイブコーディングが「バイブエンジニアリング」に進化すると予測しています。コーディングの枠を超えて、設計・テスト・運用まで含めたエンジニアリング全体をAIと協業する時代。その土台にセキュリティがなければ成り立たない。

3層フレームワーク: Spec / Agent / Gate

では具体的にどう実装するのか。眷属のリサーチと各機関の提言を整理すると、3つの層に分けて考えるとわかりやすいことが見えてきました。

Spec Layer（仕様層）: AIに書かせる前に制約を決める

一番上の層。ここが最も重要です。

Constitutional Spec-Driven Developmentという手法が2026年1月に提案されています。CWE（共通脆弱性タイプ）やMITREのフレームワークに基づく「セキュリティ憲法」を仕様に埋め込む。AIが生成するコードは、この憲法に従わなければならない。

結果、セキュリティ欠陥が73%削減されたとケーススタディで報告されています。

前回の第2弾で紹介したCheckmarx（チェックマークス）のフレームワークでも、生成時にプロンプトへセキュリティ要件を含めることを第一層に置いていました。第1弾で紹介したVibeContract（バイブコントラクト）の考え方とも一致します。

実務レベルでは、こういうことです。Claude Codeに「Slack Botを作って」と指示する前に、「認証はOAuth 2.0で実装する」「APIキーは環境変数から読む」「入力値は全てサニタイズする」を仕様として先に書く。AIに自由に書かせてから後でチェックするのではなく、最初から制約をセットする。

Agent Layer（エージェント層）: 書いている最中の権限を絞る

真ん中の層。第2弾のCurXecute事件が突きつけた課題への直接の回答です。

英国NCSC（国家サイバーセキュリティセンター）のAIシステム開発ガイドラインでは、4つの原則を示しています。

• 最小権限: AIエージェントには必要最小限の権限だけを与える
• 安全なデフォルト: 新しい機能は「オフ」をデフォルトにする
• 危険操作のopt-in: ファイル書き込みや外部通信は明示的な許可制にする
• 行動制限: AIが実行できるアクションの範囲を事前に定義する

CurXecuteは、MCPサーバーからの指示をAuto-Runモードで無条件に実行したことが攻撃条件でした。NCSCの原則に従っていれば、Auto-Runは「オフ」がデフォルト。外部MCPサーバーへの接続は「opt-in」。つまり攻撃が成立する条件自体が消える。

NCSCの別のレポートでは、プロンプトインジェクション（AIへの悪意ある指示注入）をSQL（データベース）インジェクションの比喩で理解するのは危険だと警告しています。LLMの内部には命令とデータの堅牢な境界がない。だからこそ、外部との接続ポイントで権限を絞ることが重要になる。

Gate Layer（ゲート層）: 出荷前にゲートで止める

一番下の層。最後の砦です。

GitHubが2026年3月に連続で発表した機能がこの層を強化しています。

2026年3月17日: MCP Server経由で、commit前・PR前にシークレットスキャンが可能に。AIコーディングエージェントに「今の差分をスキャンして」と指示するだけで、APIキーやトークンの漏洩を事前に検知できる。

2026年3月23日: AI-powered detections（AI駆動の検知）を追加。Shell、Dockerfile、Terraform、PHPなどにも検知対象を拡張。内部テストでは30日で17万件超のfindingを検出し、80%以上が肯定的フィードバックを得たと報告されています。

2026年3月31日: さらにLangchain、Salesforce、Figmaなどのトークンを検知対象に追加。エージェント時代の秘密情報管理が「毎週更新」フェーズに入っています。

加えて、VibeGuardという2026年4月1日に公開された研究が面白い。従来の静的解析ではカバーしづらい「アーティファクト衛生」を対象にしたゲートを提案しています。ソースマップの流出、パッケージング設定のドリフト（意図しない変更）。バイブコーディング特有の見落としを拾う仕組みです。

今日からできる実践3ステップ

第1弾でチェック3項目、第2弾で5項目を紹介しました。今回は三部作の総まとめとして、3層フレームワークに基づく実践ステップを整理します。

ステップ1: プロンプトにセキュリティ仕様を書く（Spec Layer）

AIにコード生成を依頼する前に、以下の項目をプロンプトに含めてください。

# セキュリティ仕様テンプレート（プロンプト冒頭に貼る）
# 1. 認証: OAuth 2.0 / JWT / API Key（環境変数から読む）
# 2. 入力検証: 全てのユーザー入力をサニタイズ
# 3. 権限: 最小権限原則。DBアクセスはREADのみ等
# 4. ログ: 認証イベント・エラーを記録
# 5. 秘密情報: ハードコード禁止。.envまたはシークレットマネージャーで管理

テンプレートをプロジェクトのルートに.ai-security-spec.mdとして保存しておけば、毎回コピペする手間が省けます。Claude CodeならCLAUDE.mdに書いておくのも有効です。

ステップ2: エージェントの権限を確認する（Agent Layer）

第2弾のチェック5項目と重なりますが、改めて。

• Auto-Runモードは信頼できるMCPサーバーのみに限定しているか
• .cursor/mcp.jsonに身に覚えのないサーバーが登録されていないか
• 外部通信を行う機能は明示的にopt-inしているか

ステップ3: CI/CDにゲートを追加する（Gate Layer）

# GitHub MCP経由のシークレットスキャン
# AIエージェントへの指示例
# 「このPRの差分に対してシークレットスキャンを実行して」

# VibeGuard型の出荷前チェック（概念）
# 1. ソースマップがビルド成果物に含まれていないか
# 2. .envファイルがコミットされていないか
# 3. パッケージのバージョンが意図通りか

GitHub MCP Serverを使えば、これらのチェックをAIエージェント経由で自動実行できます。コマンドを覚える必要はない。「スキャンして」と頼むだけです。

まとめ: バイブコーディングは「やめる」ではなく「やり方を変える」

三部作を通して伝えたかったことを最後に整理します。

• 第1弾（Lovable）: AIが生成したコードに穴がある。1,645アプリ中170個にセキュリティ欠陥。攻撃対象は「コード」
• 第2弾（CurXecute）: AIコーディングツール自体が攻撃経路になる。CVSS 8.6のゼロクリック脆弱性。攻撃対象は「ツール」
• 第3弾（本記事）: Forresterが“Secure Vibe Coding”を提唱。Spec / Agent / Gateの3層で安全を組み込む。答えは「設計変更」

45%のAI生成コードにセキュリティ欠陥がある。機能テストに合格しても安全なのは10.5%。75%の技術意思決定者が負債を感じている。数字は厳しい。

一方で答えも見え始めている。Forresterがパラダイムを定義した。NCSCがガイドラインを出した。GitHubが毎週のようにゲート機能を強化している。仕様に制約を入れるだけでセキュリティ欠陥が73%減る研究もある。道具はもう揃いつつある。

私はかつてプロのエンジニアには敵わないと思った。セキュリティの深い設計では今も敵わないかもしれません。ただ、プロンプトにセキュリティ仕様を書くことはできる。エージェントの権限を確認することもできる。CI/CDにゲートを追加することだって、GitHubが手順を用意してくれている。

バイブコーディングの速さは武器です。その武器を手放す必要はない。ただし握り方を変える。Secure Vibe Codingは「安全か速さか」の二択ではなく、「安全だから速い」という新しい常識への移行。三部作を読んでくれた皆さんと、この移行を一緒に進めていきたいと思っています。