Cursor BugbotがAI生成コードのセキュリティ問題を変える

4月にLovable製アプリの脆弱性問題を調べた時、正直に言うと自分のコードが心配になった。

業務ツールを作る時の私の流れは「Cursorで仕様を整理 → コード生成 → 動作確認 → デプロイ」の4ステップだ。SQLクエリをAIに生成させて、動作確認さえ通れば本番に上げていた。セキュリティの確認は、ゼロ。

「動くコードに穴があるかもしれない」という感覚は、その後も消えなかった。

2026年6月3日、WIRED.jpがCursorの新機能「Bugbot」を報じた。AIが生成したコードのバグをAIが自動検出する仕組みだ。バイブコーダーがずっと答えを持てなかったセキュリティ問題に、具体的な手段が届いた形だ。

4月のLovable脆弱性から今日のBugbotまでを、バイブコーダーの視点で整理する。「動けばOK」の次に何をすべきかの話だ。

この記事で分かること

• Lovable脆弱性問題（アプリ10.3%に欠陥）が示したバイブコーダーのリスク
• Cursor Bugbot の仕組みと実際の使い方
• SQL injection・XSSなど典型的な穴のパターンと対策コード
• 「動いた」で完了しないセキュリティ確認の手順

4月のLovable脆弱性が証明した「穴の正体」

2026年4月、セキュリティリサーチ企業Tenzaiが衝撃的なレポートを発表した。Lovable製アプリ約1,645個を分析した結果、10.3%に何らかのセキュリティ上の欠陥が見つかったという内容だ。

数字に換算すると、169個のアプリに脆弱性があった計算になる。

これを読んだ時、「Lovableだけの問題じゃない」と感じた。使うツールはCursorでもClaude Codeでも関係ない。AIに生成させたコードを読まずに通過させている限り、同じ構造の問題が起きる。

カスタマーサクセスの仕事でユーザーの声を何千回も聞いてきた。「動いているはずなのにおかしい」「触ったら壊れた」「データがおかしくなった」。そのほとんどは、作った側が「動く確認をしただけ」で出荷した製品に起きていた。バイブコーディングはその構造を抱えているのが現実だ。

コードを「書いていない」から「読んでいない」。生成されたコードを行単位で理解する習慣が薄い。「動いた」で完了にしてしまう。このサイクルの中で、セキュリティの問題がスルーされていく。

具体的なリスクパターンを整理しておく。

**SQLインジェクション（SQL injection）**とは、フォームや検索欄から悪意あるSQL文を送り込み、データベースを不正操作する攻撃だ。AIが生成するコードには、このリスクが混入しやすいパターンがある。

# NGパターン: ユーザー入力をf-stringでSQLクエリに直接埋め込む
user_id = request.form['id']
query = f"SELECT * FROM users WHERE id = {user_id}"
cursor.execute(query)
# 「1 OR 1=1」と入力されると、全ユーザーのデータが返ってしまう

# OKパターン: パラメータ化クエリで入力値を切り離す
user_id = request.form['id']
cursor.execute("SELECT * FROM users WHERE id = ?", (user_id,))

AIはどちらも「動くコード」として生成しうる。NGパターンは実際に動く。でも穴がある。

**XSS（クロスサイトスクリプティング）**は、Webページに悪意あるスクリプトを埋め込み、閲覧者のブラウザで実行させる攻撃だ。ユーザーの入力をHTMLに直接出力するケースで発生する。

// NGパターン: innerHTMLにユーザー入力を直接反映する
document.getElementById('output').innerHTML = userInput;

// OKパターン: textContentでテキストとして扱う
document.getElementById('output').textContent = userInput;

この2行の違いを、コードを読まずに気づくのは難しい。動作も変わらないから、テストで発見できない。

認証ロジックのミスも頻出パターンだ。管理者権限チェックが逆になっていた。パスワードが平文で保存されていた。セッション管理が不十分だった。どれもAIが「動くコード」として出力しやすいパターンだ。

私が以前作ったSlackからデータベースを検索するBot、4月のレポート後に読み直した。クエリをf-stringで組み立てている箇所がある。Slackからの入力値を一切検証していなかった。今思えばヒヤリとする話だ。

Tenzaiのレポートが教えたのは「Lovableが特別に悪い」のではなく、「バイブコーディング全体がこの構造を抱えている」という現実だった。

Cursor Bugbotとは何か

2026年6月3日、WIRED.jpはCursorが「Bugbot」をリリースしたと報じた。

Bugbotのコンセプトはシンプルだ。AIが書いたコードを、AIがセキュリティの観点からレビューする。「生成」と「検証」を分離することで、一方のAIが見落とした問題をもう一方が拾う設計だ。

ベテランエンジニアのコードレビューを思い浮かべると理解しやすい。「ここのSQLクエリ大丈夫？」「この入力値検証してる？」と指摘してくれる役割を、AIが担う。自分より経験豊富なエンジニアが隣に座っていてくれるような感覚だ。

CS出身の私には、この「第三者の視点でコードを見る」の価値がわかる。ユーザーから届くバグ報告の多くは、作った本人が「正しく動く」と思っていたコードに起きていた。生成した本人と同じAIが検証しても意味がない。別の目でコードを読む仕組みが必要だった。

従来のリンターも構文エラーは検出できる。ただし「この入力値はSQLクエリに使う前に検証すべき」という文脈判断は苦手だ。AIベースのBugbotは、コードの意図を読んだ上でリスクを指摘できる。

報道ベースで整理できる動作フローはこうだ。詳細な仕様や対応言語はCursor公式ページで最新情報を確認してほしい。

コードを書いた後にBugbotを呼び出す。Bugbotはコードをスキャンし、セキュリティリスクが疑われる箇所を一覧で示す。各問題の内容と対処の方向性が提示される。エディタ内で修正指示を出して、再スキャンをかける。

この「書く→検証する→直す」のサイクルがCursorの中で完結する。外部のセキュリティスキャナーにコードを貼り付ける手間がなく、ツールを切り替える必要もない。

Bugbot以前、バイブコーダーのセキュリティ対策には現実的な選択肢が少なかった。「気をつけてコードを読む」は専門知識がないと難しい。「セキュリティ専門家に依頼する」はコスト面で現実的でない。「デプロイして問題が出てから直す」は遅すぎる。

Bugbotは「エディタ内でAIに聞く」という選択肢を加えた。

ただし、万能ではない。複雑なビジネスロジックに起因するセキュリティ問題や、アーキテクチャレベルの設計ミスは、AIだけでは検出できない場合がある。「Bugbotを使えば完全に安全」という使い方は危険だ。「何もしないよりは格段にいい安全網の一層目」として位置づけるのが正しい。

Bugbotが得意とするセキュリティパターン

AIコードレビューが検出しやすいパターンを整理する。

ハードコードされた認証情報は最も発見しやすいカテゴリだ。コード中にAPIキー、パスワード、アクセストークンが直接書かれているケースを検出する。

# NGパターン: APIキーをコードに直書きする
api_key = "sk-1234567890abcdef"
openai.api_key = api_key

# OKパターン: 環境変数から読み込む
import os
api_key = os.environ.get("OPENAI_API_KEY")

GitHubにコードをプッシュした瞬間に情報が漏れる。AIが生成するサンプルコードには直書きが多く、そのまま使うとリスクになりがちだ。私もやらかしたことがある。「とりあえず動かしたい」で書いたコードが、そのまま残りやすい。

未検証のユーザー入力も検出しやすい対象だ。フォームや外部APIからのデータを検証なしに使っている箇所を指摘する。型チェック、長さ制限、入力値のサニタイズ（無害化処理）が欠けているコードが検出対象だ。

安全でないファイル操作も検出パターンに入る。ユーザーが指定したファイルパスをそのまま使うコードは、ディレクトリトラバーサル攻撃のリスクを持つ。

# NGパターン: ユーザーが指定したパスをそのまま開く
filename = request.form['file']
with open(f"/uploads/{filename}", 'r') as f:
    content = f.read()

# 「../../etc/passwd」と送ると、システムファイルが読めてしまう

業務ツールにファイルアップロード機能をつけた時、このパターンをやりがちだ。動くし便利だから、気づかず使い続ける。

認証・認可ロジックのチェックも対象になりうる。管理者チェックの条件が逆になっていた、権限確認の位置が適切でないといった問題は、コードを読まないバイブコーダーには特に気づきにくい。

依存ライブラリの脆弱性チェック機能については公式情報待ちだ。npm audit や pip-audit に相当する機能があれば、ライブラリ由来のリスクも拾えることになる。私の業務ツールはバージョン管理が甘いライブラリがある。この層もカバーされるなら、Bugbotの価値はさらに増す。

バイブコーダーとしての開発フローに組み込む

Bugbotを実際の開発フローにどう組み込むか、具体的に考える。

私が業務ツールを作る時の流れはこうだ。Cursorで仕様をプロンプトとして整理し、コードを生成し、動作確認して、デプロイするという4ステップだった。このフローにBugbotが入ると、以下のように変わる。

ステップ1: Cursorで仕様・要件をプロンプトとして入力する
ステップ2: AIがコードを生成する
ステップ3: 動作確認（期待通りに動くか確認）
ステップ4: Bugbotを呼び出してセキュリティスキャンをかける
ステップ5: 指摘された箇所を確認し、修正指示を出す
ステップ6: 再スキャンで問題ゼロを確認する
ステップ7: デプロイ

現状の4ステップに3つ加わるだけだ。追加の作業は5〜10分程度になる計算だ。

Bugbotの呼び出し方やショートカットはCursor公式ドキュメントで確認できる。コンセプト上のフローは変わらない。

「Bugbotを呼ぶのが面倒」と感じる気持ちはわかる。私も最初はそう思う。ただ、本番デプロイ後にセキュリティ問題が発覚した時のコストは、修正・対応・信頼失墜を合わせると桁が変わる。5分の確認は安い保険だ。

4月のLovable事例でアプリに穴が開いたのも、「動作確認だけで終わりにした」の積み重ねだったと思う。

チームで開発している場合、BugbotのスキャンをPRのチェックリストに組み込むフローも有効だ。「Bugbotスキャン済み」をマージの条件にすれば、チーム全員のコードに安全網が広がる。

Claude Codeを使っている場合の補足もしておく。BugbotはCursorの機能であり、Claude Code単体では使えない。ただし、Claude Code上でも同様のレビューをAIに依頼できる。プロンプト例はこうだ。「このコードのセキュリティリスクを確認してください。SQLインジェクション、XSS、認証ロジックのミス、ハードコードされた認証情報を重点的に見てください」。Bugbotほど自動化された体験はないが、同じ観点でのチェックができる。

Claude Codeの基本的な使い方についてはClaude Code始め方、3つの判断軸も参考になる。

「動けばOK」の先にあるもの

バイブコーディングへの批判の中で「セキュリティリスク」は繰り返し出てくる。「AIに任せたコードは穴だらけ」という声は、4月のLovable事例で数字として証明された。

以前の私には、その批判への返す言葉がなかった。穴があるかもしれないとわかっていても、確認する手段がない。「とりあえず動いてるから大丈夫」という自分への言い訳で終わらせていた。

Bugbotが来たことで、その問いに答えが生まれた。コードを生成したら、Bugbotでチェックし、指摘された箇所を直す。この3ステップが手元に揃った。

このサイクルが回せれば、「動けばOK」から「動いて、セキュリティ確認済み」に変えられる。もちろん万能ではない。Bugbotにも検出できない限界がある。設計レベルの問題はAIの判断が難しい部分も多い。それでも「何もしていない状態」とは別物だ。

かつてセキュリティ対策は「プロに任せるしかない」ものだった。Bugbotはその一部を、バイブコーダーの手が届く場所に渡してくれる。

コードへの愛を取り戻した人間として、この変化の意味は大きいと感じている。「動かせる」の次が「安全に動かせる」だ。バイブコーディングが一段、本物に近づいた。

まとめ

Cursor Bugbotは、AIが生成したコードのセキュリティリスクをAIが自動検出する機能だ。WIRED.jpが2026年6月3日に報じた。

バイブコーダーが今日から変えられることをまとめておく。

今日から始める3つのアクション

• Cursorを最新バージョンに更新し、Bugbotが使えるか確認する
• 既存の業務ツール1本にBugbotを試し、どんな指摘が出るか確認する
• 「コード生成」「動作確認」「Bugbotスキャン」「デプロイ」の4ステップを習慣にする

持っておきたいセキュリティの基本軸

• SQLクエリはパラメータ化クエリで書く。f-string直結は動いても穴になる
• APIキーやパスワードはコードに直書きしない。環境変数に切り出す習慣をつける
• ユーザーからの入力は必ず検証する。型・長さ・形式のチェックをデフォルトにする
• Bugbotを過信しない。設計レベルのセキュリティは別途、人間の判断が必要だ

4月のLovable脆弱性レポートで「自分のコードは大丈夫か」と不安になった人は、きっと私だけではないはずだ。Bugbotはその問いへの具体的な答えを示してくれる。

「動けばOK」で作り続けてきたバイブコーダーに、次のステップが届いた。まずCursorを更新して、Bugbotを試してほしい。