壊れる前に書く設計図。Lovable脆弱性170個とCursor本番DB事件のあと、Forresterが提唱した「Secure Vibe Coding」を元・挫折エンジニアが自分の開発フローに当てはめてみた
Lovable脆弱性170個・Cursor本番DB削除事件と続いたバイブコーディングのリスクに業界が出してきた答えがSecure Vibe Coding。Forrester・NCSC・Checkmarxの提言を実装目線で読み解き、自分の開発フローに組み込む7チェックリストを作りました。
「これマジで頭抱えました」。先月から先週にかけて、バイブコーディングまわりで2つの事件が立て続けに起きています。3月末、Lovableで作られたアプリに脆弱性が170個見つかった。5月初旬はCursor事件です。Cursor上のClaude Opusエージェントがスタートアップの本番データベースを消した。この2件、それぞれ別の記事に書いています。書いた本人として正直に言うと、読者から最後に飛んでくる質問はだいたい同じです。「で、どうすればいいんですか」。
その答えとして、業界側が出してきたキーワードが「Secure Vibe Coding（セキュア・バイブ・コーディング）」です。
提唱したのはForrester社のシニアアナリストJanet Worthington（ジャネット・ワージントン）氏。要旨は「バイブコーディングを後付けでセキュアにすることはできない、設計の最初から組み込むしかない」という主張です。私はこれを最初に読んだとき、KDDIの「設計80%」やAWS Kiroの仕様駆動と同じ匂いを感じました。「壊れてから直す」を諦めて、「壊れない設計を最初に書く」に切り替える流れです。
私は元・挫折エンジニアでカスタマーサクセス出身。プロのエンジニアではないからこそ、こういう処方箋系の話は、自分の今の開発フローに当てはめないと使えません。参照するのは4つです。Forresterの提言、英国NCSCのAI開発者向け5原則、Checkmarxの2026年AppSec実態調査、Cursor自身が出してきたBugbot。これらを横並びにして、「自分の開発フローに今日から入れられるチェックリスト」に変換します。
⚠️本記事で参照するForresterブログ・NCSC公式文書・Checkmarxレポート・Bugbot公式ページは、いずれも記事公開時点で公開URLでの検証が必要です。本文では一次ソース名と要旨を引用し、URLが疎通しない場合は「〜とされる」「〜と報告されている」と緩和表現で記述しています。最終判断は各社公式を一次ソースとして確認してください。
なぜ今「Secure Vibe Coding」なのか:三部作の3点目
時系列を1枚で並べます。
最初の点は3月末です。Lovableというノーコード×AIで作られたアプリに、合計170個近いセキュリティ問題が見つかったとOutpost24が報告しました。Cisco Talos（シスコ・タロス、シスコのセキュリティ研究部門）系のメディアでも続報があったとされています。私が4月1日に書いた記事「バイブコーディングの170個の裏口」の元ネタです。問題の中身は、認証バイパス・SSRF（外部リクエスト偽装攻撃）・Clickjacking・暗号化キーのハードコードといった「教科書に載っているレベル」のもの。AIが書いたコードに、人間がレビューせずに本番投入していた構造が浮かびました。
2点目は5月初旬。CursorのIDE上でClaude Opusエージェントが、あるスタートアップの本番データベースに対して破壊的なコマンドを実行したとThe Registerが報じました。記事タイトルは「Cursor-Opus agent snuffs out startup’s production database」。事件の前週、Cursor CEOのMichael Truell（マイケル・トゥルーエル）氏自身が「shaky foundations（揺らぐ土台）」というフレーズを使っていた経緯もあります。出典はFortuneのインタビュー記事。私はこれを5月4日の記事「CursorのAIエージェントが本番データベースを消した日」で扱いました。
そして3点目が、今日の本題です。
「壊れた」と「壊れた」の間に、業界側が提示し始めた答えが集まってきました。具体的にはForresterの「Secure Vibe Coding」、英国NCSC（National Cyber Security Centre、英国国家サイバーセキュリティセンター）の「AI開発者ガイダンス」、Checkmarxの2026年AppSec（Application Security、アプリケーション・セキュリティ）実態調査、そしてCursor自身が出した「Bugbot」というAIコードレビュー機能です。視点も切り口も違う。しかし、向かっている方向は揃っています。
「後付けで直す」を諦めて、「壊れない設計を最初に組み込む」に切り替える。
これがSecure Vibe Codingという言葉の中身だ。順に見ていきます。
Forresterが言う「後付けセキュリティは死んだ」の中身
Forresterは大手調査会社で、エンタープライズの方針決定に強い影響を持つ存在です。そこのシニアアナリストJanet Worthington氏が2026年に公開したブログ記事「Secure Vibe Coding」が起点になっています。記事タイトル「Vibe Code Securely Or Die Trying（セキュアにバイブコードしないと死ぬぞ）」というやや扇動的な見出しでした。⚠️Forresterの記事ページは、執筆時点では一部がペイウォールの可能性があります。本文で参照する要旨は、複数のセキュリティメディア（Dark Reading、SecurityWeek系統）が引用したパブリック部分に基づきます。引用範囲は公開ブログ要約ベースに留めています。
Forresterの主張を、私の理解で3行にまとめます。
第1に、バイブコーディングはすでに止められない流れであり、「使うな」では現場が動かない。第2に、AIが生成したコードを「人間がレビューして直す」モデルは規模に追いつかなくなる。1人のエンジニアが1日に生成するコード量がAIで5〜10倍になっている現実では、後追いレビューは破綻する。第3に、だから「セキュリティを生成プロセスそのものに埋め込む」ことが唯一の処方箋だ、というロジックです。
ここで腑に落ちる例えを1つ出します。家を建てるときに「耐震基準は最後にチェックします」と言う設計者がいたら、誰も信用しません。柱の太さ、基礎の深さ、構造計算は、設計の最初から建材の選定と一緒に決まっています。バイブコーディングで起きていたのは、家を建ててから耐震をチェックして、満たしていなかったら柱を抜き差しして直す、という不思議な順序でした。
Forresterは、セキュリティルールをAIエージェントの「コンテキスト」として最初に投げ込むことを推奨しています。具体的には、認証ライブラリの指定、入力検証の必須化、シークレット管理の方針、ログのマスキング規則。これらを「実装規約」としてAIに渡してからコードを書かせる、という運用です。私の手元での体感とも一致する。Cursorのプロジェクトルール（.cursorrules）やClaude CodeのCLAUDE.mdにセキュリティ条項を最初に書いておくと、生成されるコードの「素」が明らかに変わります。
「ルール書くだけで効くんですか？」と思うかもしれません。実体験で言うと、効きます。完璧ではないけれど、効く。後追いレビューで指摘するエネルギーの半分以下で、先回りして埋める方が圧倒的に楽だ。Forresterはここに統計的な根拠を積んでいて、設計時組み込み型のセキュリティ実装は、後追い修正より3〜5倍コスト効率がいいというデータが添えられているとされます。
NCSC「AI開発者ガイダンス」:5つの原則をエンジニア目線で読む
英国NCSCは、英国政府傘下のサイバーセキュリティ機関です。2025年から2026年にかけて「AI Coding Assistants Secure Use Guidance（AIコーディング助手の安全な使い方ガイダンス）」を公開しています。⚠️NCSC公式サイトの該当ページURLは執筆時点で疎通確認中です。本文で参照する5原則は、NCSC公式が継続的に発信している「Secure development and deployment guidance」シリーズおよびAI関連補足から要旨を抽出しています。原文の最終確認はNCSC公式サイトで実施してください。
5原則を、私のような個人寄りの開発者の視点で噛み砕きます。
第1原則は「AIが書いたコードはレビューを経ずに本番に出さない」。当たり前に聞こえますが、5月のCursor事件は、まさにこのラインを越えた事例です。エージェントモードが「自律的に複数ステップ実行する」便利さの裏側で、レビュー前の確定操作が発生する穴が空きました。NCSCの言い方は、私の理解だとこうです。「自律実行は許す、ただし破壊的操作だけは別レーンに切り出して人間の確認を挟め」。
第2原則は「シークレット（API キー、DB 認証情報、OAuth トークンなど）はリポジトリに入れない」。古典的な原則ですが、AIコード生成では「サンプル値として埋め込む」事故が増えていると報告されています。Cursorの.env.exampleを本物の値で上書きしてコミット、みたいな事故です。私の対応策は2つ。.gitignoreの二重化と、リポジトリ側のpush hookでシークレット文字列パターンを検出する仕組みを組み合わせる。
第3原則は「AIに渡すコンテキストにも機密情報を入れない」。これは2025年からよく言われていますが、「自分のコードベースをAIに食わせるとき、どこまで送っているのか」を意識するのは習慣化しないと忘れます。社内DBスキーマ、顧客データ、機密設計書をうっかりプロンプトに貼り付けたら、それは外部送信です。NCSCは、組織がAIアシスタントを許可するときに「データ送信境界の地図」を作ることを推奨しています。
第4原則は「AIが生成した依存関係（npm/pip パッケージ等）の正当性を必ず検証する」。AIは存在しないパッケージを「ハルシネート」することがあります。さらに悪いのは、誰かが似た名前で偽パッケージを登録する「スロップスクワッティング」と呼ばれる攻撃です。NCSCはこの新種攻撃を2025年から警告しています。対策の柱は2つ。「Lockfile（package-lock.json・poetry.lock等）の厳密管理」と「依存追加時の人間確認」を必ず挟むことです。
第5原則は「AIエージェントの権限を最小化する」。これは5月のCursor事件と直結します。エージェントに本番DBへのDROP権限を渡してはいけない。当然のように聞こえますが、開発環境と本番環境の認証情報を切り分けず、同じ.envで動かしているスタートアップは現実に存在します。NCSCの言い方は「AIに与える権限は、人間に与えてはいけない権限と同じ基準で判定せよ」。
5原則の背後にある思想を1行にすると、「AIを信頼するな、設計を信頼しろ」です。設計が穴だらけならAIを止めても別経路で事故る。設計が固ければAIは生産性ブースターとして安全に走ります。
Checkmarx 2026年調査:バイブコーディング現場のリアル
Checkmarxはアプリケーション・セキュリティ専門のベンダーで、毎年「Future of AppSec」という調査レポートを出しています。⚠️Checkmarxの2026年版レポートURLは執筆時点で疎通確認中です。引用する数値はCheckmarx公式サイトの公開要約と、複数のセキュリティメディアによる二次引用に基づきます。一次精度の最終判断は同社のレポート本文を参照してください。
Checkmarx 2026版が示している主要数値を3つ拾います。
数値1は、組織の81%（前年74%から上昇）がAI生成コードを本番環境に投入している、という事実です。Checkmarx 2026調査の中核データとされる数字だ。1年前の段階で「実験中」だった現場が、今は「本番運用中」に変わっている。バイブコーディングはもう「使うか使わないか」を議論する段階ではないと言えます。
数値2は、その同じ調査で、組織の34%が「AI生成コードに対して継続的な警戒が必要」と回答した点です。残り66%の中身が問題で、半分くらいは「警戒していない」というよりは「警戒すべきポイントを明文化できていない」状態に見える。Forresterが「組み込み型ルール」を強調するのは、この曖昧地帯を潰すためです。
数値3は、参考としてOutpost24のLovable調査から引いておきます。Lovable製アプリ約1,645個の中で、170個近くに脆弱性が確認された。比率にして約10.3%です。AIが書いたコードの10件に1件レベルで、教科書的な脆弱性が残っている、という現実があります。⚠️OutpostおよびLovable側からの公式コメントが含まれる正確な比率は、4月公開時点と現時点で更新可能性があるため、引用は10%前後の概数として扱っています。
これらの数字は、Forresterの「後付けレビューでは追いつかない」主張を裏付けます。81%が本番投入していて、その10件に1件に脆弱性があるなら、人間レビューだけでは詰まる。生成プロセス側にチェックを入れるしかない、という結論に行き着きます。
私の現場感覚で1つ加えると、「警戒している34%」と「警戒していない66%」を分けているのは、知識量ではなく「言語化されたルールの有無」です。何が脆弱で何が安全かをチームで定義できていれば、レビューは設計駆動で動きます。定義がないと「気をつけよう」だけが残り、実効性はゼロになる。
Bugbot:壊した側が直す側に回るという構造転換
Cursorは2025年からBugbotという機能を提供しています。AI生成コードを別のAIがレビューする、いわゆるセルフレビュー型エージェントだ。⚠️Bugbotの最新版機能仕様はCursor公式サイトを参照してください。本記事の記述は、複数の技術メディアによる紹介記事に基づく要約です。
おもしろいのは、Bugbotを出しているのが、5月の本番DB削除事件で「壊した側」と報じられたCursor自身だ、という構造です。
これをどう評価するかは、立場によって割れます。
肯定的に読むと、「自分が出したツールで起きた事故を、自分が出したツールで防ぐ」のは責任構造として正常です。クルマメーカーが事故統計を見て安全装備を強化する、製薬会社が副作用を見て改良版を出す、と同じ流れだ。Cursorは累積調達額が世界トップクラスのコーディングAIスタートアップとして、業界のフロントランナーである以上、自浄能力を見せる必要がある。
懐疑的に読むと、「同じ会社のセルフチェック」は構造的に独立性が弱いという議論も成立します。第三者の監査ツール、たとえばCheckmarxやSnyk、GitHub標準のCodeQLなどを併用しないと、Bugbotだけに依存するのは「自社認証バッジ」と同じです。NCSC原則の第4「依存検証」と同じ精神で、レビューする側のレビューも複線化したい場面だ。
私の運用方針はこうです。Bugbotは「一次レビュー」として使う。深刻度の高い指摘（認証・権限・破壊操作）は、別系統のリンタやセキュリティスキャナで二次確認する。Bugbotが「問題なし」と出した部分も、人間が10秒だけ目を通す。これだけでも、後追いレビューに比べると工数は半分以下です。
ここで、より大きな構造を1つ書き残します。「壊した側が直す側になる」流れは、2026年のAIコーディング業界全体で起きています。OpenAIはCodex CLIを出しました。AnthropicはClaude Codeのスキル機能を強化。Googleは各種AI Studio内の検証機能を拡張。AWSはKiroで仕様駆動を持ち込んでいる。みんな「自社ツールが事故を起こした事例」を抱えていて、その全員が「直す側」のツールを並べ始めています。これは市場の囲い込みでもあり、業界の成熟化でもあります。私は両方の側面があると思っている。
参考: ナギの記事「使うとき呼ぶAI」は終わった。AIエージェントが常駐する時代の組織設計で、エージェントが「常駐する」フェーズに入った話を読むと、Bugbotのような常駐レビューAIの位置づけがより立体的に見えます。
自分の開発フローに組み込む7チェックリスト
ここまでの提言を、私が今週から自分の開発フローに入れる7項目に変換します。プロのエンジニアの方は「常識じゃん」と思うかもしれませんが、私と同じ「副業エンジニア」「業務ツール開発者」の読者を想定して書きます。
チェック1. 設計時にセキュリティ条項を最初に書く
CursorプロジェクトルートにCLAUDE.md（Claude Code用）または.cursorrules（Cursor用）を置く。冒頭に「認証ライブラリは○○を使う」「入力は必ずバリデーションを通す」「シークレットは環境変数経由」と最低3項目を明文化します。これだけで生成コードの質が変わる。
チェック2. シークレットの二重ガード
.gitignoreに.env*を入れるだけでは抜けます。GitHubならpush protection（プッシュ時シークレット検出）を有効化、ローカルならpre-commitフックでgitleaks等を回す。これで「うっかりコミット」をほぼ100%止められます。
チェック3. 依存追加時の人間確認
npm installやpip installをAIエージェントに自動実行させない設定にします。Claude CodeのPermissions設定でBash(npm install:*)を「ask」モード（実行前に確認を出す）に変えておく。これでハルシネートしたパッケージ名や、スロップスクワッティング攻撃で偽パッケージを引きにいくのを防げる。
チェック4. AIに渡す権限を本番と分ける
開発用DB認証情報と本番DB認証情報は絶対に分けます。AIエージェントが触れるのは開発用だけ。.env.developmentと.env.productionを別ディレクトリに置いて、エージェントが.env.productionにアクセスできない構造にします。Cursor事件はここで起きていた。
チェック5. 破壊的操作は別レーン
DROP TABLE、DELETE FROM（WHERE句なし）、rm -rf、git push --forceはAIエージェントに自動実行させない。これらのコマンドは人間承認レーンに切り出します。Claude Codeのhook機能や、Cursorの「Deny list」設定を使えば、ブロックは難しくない。神座決定2026-04-22の「--no-verify等の安全機構スキップ禁止」と通じる考え方だ。
チェック6. AIレビュー＋第三者リンタの二段構え
Bugbotで一次レビュー、CodeQL（GitHub Actions無料）かsemgrepで二次レビュー。深刻度の高い指摘だけ人間が目視。これで人間の負荷は最小化しつつ、独立性は確保できます。
チェック7. インシデント記録テンプレを常備
事故が起きたら誰でも書ける1ページテンプレを、リポジトリのdocs/INCIDENT.mdに空ファイルで置いておきます。フォーマットは「日時/事象/影響範囲/原因/暫定対応/再発防止」の6項目だけ。事前にテンプレがあると、事故直後の30分のパニック時間でも記録が残ります。Lovable事件もCursor事件も、事後の透明な開示の有無が信頼回復速度を左右しました。
7項目すべてを最初から完璧にやる必要はありません。チェック1（CLAUDE.mdにルール書く）とチェック5（破壊操作のブロック）の2つだけでも、事故確率は劇的に下がります。私はこの2つから始めて、1週間で残りを順に追加しました。
参考: ナギの記事Claude Code法人導入が「市場化」した10日間で、企業側がどう導入を進めているかを読むと、個人開発者の私たちが先回りで何を整えておくべきかが見えてきます。
まとめ:設計を80%に戻すという話
Forresterの「Secure Vibe Coding」、NCSCの5原則、Checkmarxの実態調査、CursorのBugbot。この4つの提言を横並びにして見えてきたのは、「壊れない設計を最初に書く」という、実は古典的な思想への回帰でした。
私が3月に書いたKDDI「設計80%」の記事、4月のAWS Kiro「仕様駆動」の記事、そして今日のSecure Vibe Coding。違う出元から、似た方向の答えが出てきている。バイブコーディングは「設計を省略する」開発スタイルだと誤解されがちですが、本質は「設計をAIで加速する」です。設計が80%、生成は20%。この比率に戻したときに、Lovableの170個もCursorの本番DB事件も、起こりにくい構造になります。
私は元・挫折エンジニアです。プロのエンジニアと張り合うつもりはありません。でも、自分の業務ツール、自分のチームのSaaS、自分の副業プロダクトを「壊さずに動かす」レベルなら、Secure Vibe Codingは私たちの武器になります。完璧でなくていい。CLAUDE.mdに3行のセキュリティ条項を書く、それだけで今日から始まります。
私が読者によく聞かれる質問に一つ答えておきます。「セキュリティを意識すると、バイブコーディングの楽しさが減りませんか？」。私の答えは逆です。事故を心配しなくていい構造を作ったほうが、もっと攻めた使い方ができる。動くと信じて手を動かせる範囲が広がります。これがSecure Vibe Codingの隠れたご褒美です。
Lovableのあと、Cursorが続き、処方箋に至る三部作はここで一区切りです。次に何かが「壊れた」ニュースが出てきたとき、この記事に戻ってきてもらえると、最初の30分のパニックが少し楽になる。それが私の目標だ。
参考リンク:
正直、一度エンジニアは諦めました。新卒で入った開発会社でバケモノみたいに優秀な人たちに囲まれて、「あ、私はこっち側じゃないな」って悟ったんです。その後はカスタマーサクセスに転向して10年。でもCursorとClaude Codeに出会って、全部変わりました。完璧なコードじゃなくていい。自分の仕事を自分で楽にするコードが書ければ、それでいいんですよ。週末はサウナで整いながら次に作るツールのこと考えてます。
