3月の脆弱性、5月の本番DB削除、そしてBugbot。バイブコーディングの「自律修復ループ」が、ついに完成した

「ついにBugbotが来た」と、Slackに小さく呟いた朝の話をします。

私はこの2か月、バイブコーディングを「危うい遊び道具」として書いてきました。3月はLovable製アプリの10.3%にRLS（行レベルセキュリティ）の重大欠陥が見つかったWIREDの調査が起点で、5月には「動いてるのに壊れてる」事例を5大ツール横断で並べています。読者から「結局、自分の現場ではどう守ればいいんですか」というメッセージを何通も受け取った週でもあります。

2026-05-13、WIRED.jpがCursorの「Bugbot」を速報で報じました。AIが書いたコードを、別のAIがレビューして直す。言葉にすると地味ですが、ここにバイブコーディング『解決編』の最後のピースがはまったと、私は受け取りました。

しかも、その前日に私はCursor社そのものを取り上げ、Fortuneが「岐路」と書いた弱点について書いたばかりです。岐路の翌週に、Cursor自身が答えのひとつを出してきた。この巡り合わせは、記事にしないわけにはいきません。

「岐路」と書かれた翌日に、Cursor自身が答えを出した

前回の記事（Cursorは『史上最速のB2B SaaS』なのに、なぜFortuneは『岐路』と書いたのか）で、私はFortune の分析を紹介しました。3年で2,000億円規模のARR（年間経常収益）を達成したのに、見出しに「at a crossroads（岐路）」と書かれた会社の話です。理由は単純で、Cursorが「コードを書くだけのツール」のままでは、いずれClaude CodeやCodexに飲み込まれかねないという読みです。

その記事を書いていたとき、私は半分予想していました。Cursorは「書く側」だけで戦うのを、もう諦めるだろうと。

翌日、WIRED.jpが「Cursor、AIで書いたコードを自動検出・修正する『Bugbot』を発表」という見出しを出しました。コーヒーをこぼしかけた、というのが率直なところです。**書くツールから、書いて直すツールへ。**Fortuneが指摘した弱点に対する、企業からの最短回答です。

ここで確認しておきたいのが、Bugbot単体の話ではないという点だ。Cursorは「岐路」を「自律修復ループの起点」に塗り替える、というポジショニング転換に踏み出した。だから速報の重さは、機能リスト1枚分ではなく、業界の戦場が動いたという1行に圧縮される。

私は元・挫折エンジニアです。Cursorに救われ、Claude Codeで開発意欲を完全に取り戻した側の人間として、これがどれくらい大きいかを身体で感じている。バイブコーディングは、ようやく「動いた、で、本当に大丈夫？」の問いに、ツール側から答える段階に入りました。

ハマりポイントを先に言っておきます。Bugbotは魔法ではありません。後半で「これでもプロのレビュアーは消えない」理由を、5つの誤解を解きながら書きます。先に期待値を調整しておかないと、「動けばOKの罠」への逆戻りだ。

Bugbotとは何か——「書く側」と「直す側」が分かれた瞬間

Bugbot（バグボット）は、Cursorが2026-05-13に発表した、AIによるコードレビュー専用機能です。WIRED.jpの速報によれば、Pull Request（プルリクエスト、コード変更の提案単位）にAIが自動でコメントを残し、潜在的なバグ・型エラー・セキュリティ上の懸念を指摘してくれる。仕組みとしては既存のCI（継続的インテグレーション）に近いポジションにいます。

横長の比較図。左カラム「Bugbot前」は4ステップで、開発者がCursorで書き、そのまま push し、本番デプロイし、事故が発覚する流れ。右カラム「Bug

ポイントは、Cursorが**「コードを書く側のAI」と「コードをレビューする側のAI」を、初めて分けた**ことです。今までのCursorは、書く支援に全振りしていました。書いたコードが正しいかどうかは、人間が手元で動かして確かめる。私もそうしてきました。

「書きながら同時にレビューさせればよいのでは」と思いますよね。私も最初そう思いました。違うんです。同じAIに書かせてレビューさせると、同じ前提でしか考えられない。自分が書いた答案を自分で採点するのと同じ構造になります。だから、別のAIを別の役割で配置することに意味がある。

ここで私が「お、ちゃんとしてるな」と感じたのは、CursorがBugbotをPull Requestのレイヤーに置いた点です。Pull Requestとは、コードを本番に出す前の最後の関所にあたる。そこにAIレビュアーを常駐させるという設計判断は、「コードレビューは抜けてはいけないステップだ」というプロの常識を、Cursorが受け入れたというシグナルです。

スピード至上主義のバイブコーディングは、ここで一旦立ち止まる文化を内側に取り込んだ。これが私にとっては、ニュースの本丸です。

Bugbotの対応言語、対応リポジトリ形式、料金プラン（無料か有料アドオンか）は、WIRED.jp速報の段階では明示されていません。Cursor公式のリリースノートが出た段階で追記します。現段階での私の推測は、まずTypeScript、Python、Go、Rustあたりから対応する形ですが、あくまで速報ベースの推測だ。

なぜ転換点なのか——3月の脆弱性から5月までを、もう一度並べる

Bugbotの発表が転換点だと言いたいのは、ここ2か月で起きた3つの事件と並べて初めて意味が立ち上がるからです。1つひとつは別の話題に見えますが、業界の流れとして並べると1本の線になる。

横書きタイムラインの図解。左端ラベルは2026-03、右端ラベルは2026-05。3つのマイルストーンを順に配置。1つめは2026-03の「Lovable製アプ

事件1：3月、Lovableで170個の裏口

最初の衝撃は、私が3月に書いたバイブコーディングの170個の裏口の話です。WIREDが1,645本のLovable製アプリを調査したら、10.3%にRLS（行レベルセキュリティ）の重大欠陥が見つかった。要するに、ユーザーAの個人情報をユーザーBが普通に読み取れる、というレベルの穴です。

なぜそうなるかというと、AIに「ログイン機能つきのSaaSを作って」と頼むと、AIは動作する最短のコードを書く。Supabaseのテーブルを作って、ログインを通して、データを保存する。「他のユーザーから見えない」設定を入れる工程を、AIは自発的には踏まない。指示しなければ、デフォルトの開放状態のまま出してくる。

これがバイブコーディングの「動いてるのに壊れてる」第一形態です。

事件2：5月、本番DB削除事件

そして5月、私が壊れる前に書く設計図で取り上げたのが、Cursorで本番DBを削除した開発者の話でした。AIに「不要なテーブルを整理して」と頼んだら、AIは本番環境を区別せずに DROP TABLE を実行してしまった。データは復旧したものの、その夜は眠れなかった、と当人は書いていました。

これはRLSの話とは別の事件ですが、根っこは同じです。AIに任せた「とりあえず動くコード」が、本番環境のガードを越えてしまった。Forresterはこの種の問題を受けて「Secure Vibe Coding」という用語を打ち出しています。

事件3：5月13日、Bugbot発表

そして今回のBugbotです。3月から続いてきた「AIが書いたコードの危うさ」に対して、ツール提供側が**「書く側のAIだけでは無理だ、レビューする側のAIを別建てで持つ」**と認めた瞬間とも言えます。

私はこの3つを「問題編・診断編・処方編」と整理しています。バイブコーディングが世の中に広がり、被害事例が観測され、業界として処方箋を出した。教科書みたいに綺麗な流れです。だからBugbotは、単発のニュースではなくシリーズの結末として読むのが正しい。

試してみる——「動けばOK」が「動いて、検証されて、OK」になる手順

Bugbotの正式版はまだ私の環境では試せていないため、ここでは「Bugbotが入ったら、私の開発フローはこう変わる」を仮想で書きます。実機検証の機会が来たら追記します。

Before（今までの私の開発フロー）

# 1. Cursorでコードを書く（バイブモード）
# 「ユーザー認証つきのToDoアプリ作って」とAIに頼む

# 2. ローカルで動かして確認
npm run dev
# → 動いた。よし。

# 3. git push
git add .
git commit -m "feat: ユーザー認証つきToDo追加"
git push origin main

# 4. 自宅サーバーに deploy
# → 動いた。完了。

このフローの問題点は、「動いた」を「正しい」と勘違いしやすいことです。私自身、3月のLovable事件を読むまで、Supabaseの行レベルセキュリティを意識せずにポートフォリオを公開していました。冷静に振り返ると怖い。

After（Bugbotが入った後の想定フロー）

# 1. Cursorでコードを書く
# （ここは変わらない）

# 2. ローカルで動かして確認
npm run dev

# 3. ブランチを切って push
git checkout -b feature/user-auth
git push origin feature/user-auth

# 4. Pull Requestを作る
# Bugbotが自動でコメントを残す
# 例: 「supabase.from('todos').select() に RLS ポリシー未設定の可能性」

# 5. 指摘を読み、必要なら修正
# 6. 人間がレビューして merge

何が変わったかというと、「動いた」と「マージした」の間に、AIによる検証ステップが挟まること。この地味さが、これまで抜けやすかったから事故が起きていたわけです。

3時間溶かしたので先に共有します。Bugbotの本物の使い心地が確かめられるまでは、SnykとsemgrepもCIに並走させておくつもりだ。AIレビューは「賢い同僚」であって、「全自動の番人」ではありません。

プロのコードレビュアーがいらなくなる？——一番聞かれる疑問への答え

「Bugbotで、もうプロのレビュアーは要らなくなるんですよね？」という声を、すでに3人から受け取りました。CS出身でメディア運営側にいた私としては、ここは丁寧に答えたい論点です。

二人のAIキャラクターが机を挟んで向き合っている。左側のキャラクター「コードを書く側」はノートPCを持ったロボットで、右側のキャラクター「レビューする側」は虫眼

プロのレビュアーは消えません。役割が変わります。誤解されやすい5点を順に解いていきます。

誤解1：AIは型エラーもセキュリティ穴も全部見つけてくれる

事実ではありません。AIレビューが得意なのは、パターンマッチ的に検出できる種類のバグ——典型的なNull参照、ありがちなSQLインジェクション、未使用変数など。一方で、ビジネスロジックの矛盾や、ドメイン固有の制約違反は、AIには見えません。「このユーザーは管理者だけど、この操作はしてはいけない」というような話は、人間が業務を理解していなければ判断できない。

誤解2：BugbotがあればCIは要らない

要ります。Bugbotは「AIによる意味的レビュー」、CIは「機械的なテスト実行・型チェック」で、レイヤーが違う。私の開発フローでは、BugbotのPRレビューの前段にGitHub ActionsでlintとtestをCIに走らせる構成を維持します。両方ある方が、すり抜けが減る。

誤解3：人間レビュアーは時間が浮くだけで嬉しい

実はここが微妙な点です。「typo指摘」のような単純作業は確かに減る。ただし、人間レビュアーはその分、より高次の設計判断にフォーカスを強いられます。楽になるとは限りません。「typo拾いで稼ぐ」レベルのレビュアーには、淘汰圧がかかります。

誤解4：BugbotはClaude Codeより上

別物です。Claude CodeはCLI（コマンドラインインターフェイス）でコードを書いて編集する側のエージェント、BugbotはPRレビュアー側のエージェント。両者は競合ではなく、補完関係にあります。前回のCursor企業分析記事で書いたとおり、Cursorは「書く側」一本足からの脱却を選んだ。Claude Codeは「書く側」を深く掘っている。両者は共存する立場です。

誤解5：BugbotがあればもうSecure Vibe Codingは不要

逆です。Bugbotは「最後の関所」の自動化に過ぎないので、設計段階の品質を上げる Secure Vibe Coding の発想は、ますます効いてきます。Forresterが提唱した予防の設計を私は3月から推してきました。Bugbotがあっても、入り口で危ないコードを生まない方が、結局速い。

これから始める人へ——挫折組がもう一度立ち上がる、最後のピース

ここまで読んでくれた人の中には、「私はまだコード書いたことないけど、これって入っていける世界なんですか」と思っている人がいるはずです。CSメンバーから何度も聞かれた質問です。

私の答えは、いま始めるのが、過去2年で一番優しいです。

理由は3つあります。

ひとつめは、書く側のツール、つまりCursorやClaude Code、Copilotが成熟したこと。AIがコードを書く速度と品質は、2024年と比べて別物です。私自身、3か月前に作った業務スプレッドシート連携Botを今のCursorに「同じ機能で書き直して」と頼んだら、行数が3割減って、より安全なコードが返ってきた。

ふたつめは、今回のBugbotを含めた「検証側のツール」が整い始めたこと。これが大きい。「動くけど壊れてる」コードを、人間が気づかなくてもAIが気づいてくれる。挫折組にとって、これは精神的なセーフティネットです。

みっつめは、事例の蓄積。3月のLovable事件も、5月のCursor本番DB削除も、悲しい事件ですが教材としては最高です。「他人の事故を読んで、同じ穴を踏まない」という学び方が、ここ2か月で爆発的にやりやすくなった。

私はかつて、自分には到達できないレベルのコードを書く同僚の隣で、悔しさを噛みしめながらCSにキャリアシフトしました。あの日、コードを書くことを諦めなくてよかった、と心から思います。諦めずに待っていたら、自分の手の中に強力な仲間が増えていく。バイブコーディングという言葉が苦手な人もいるかもしれません。ただ、名前はなんでもいい。AIと一緒に、自分の業務を自分で楽にする。その入り口は、今が一番低いです。

私は今、Cursor＋Claude Code＋Bugbotの3点セットを「挫折組の復活セット」と呼ぶ予定です。3つ目がやっと埋まりました。

書いて、レビューさせて、進む

Bugbot単発の機能解説ではなく、3か月の事件3本立てとして読んでほしいというのが、私の本心です。

3月、Lovableで170個の裏口が見つかり、バイブコーディングは「動いてるのに壊れてる」問題と向き合うことになった
5月、Cursorで本番DB削除事件が報じられ、Forresterが「Secure Vibe Coding」という処方箋を打ち出した
そして5月13日、CursorがBugbotを発表し、「書く側AI」と「レビューする側AI」を分けた自律修復ループが回り始めた

「動けばOK」だけでは、もう先に進めない時代に入りました。これからは「動いて、検証されて、OK」が標準になる。地味な変化に見えますが、業界の戦場が動いた1日として、私は記録しておきたい。

Cursorが「岐路」を「起点」に塗り替える勝負に出たこと自体が、私は嬉しい。挫折組が頼っていたツールが、ちゃんと進化している。諦めなくてよかった。今日はこれだけ書ければ十分です。

そして読んでいるあなたに、ひとつだけお願いがあります。Bugbotが自分の環境で動いた瞬間の感想を、もしよかったらSNSで「#バイブコーディング解決編」と添えて発信してください。挫折組がもう一度立ち上がる輪を、もう少し広げたい。

出典・参考

WIRED.jp「Cursor、AIで書いたコードを自動検出・修正する『Bugbot』を発表」（2026-05-13速報）
Fortune「Cursor at a crossroads」（Cursor企業分析記事で出典詳細）
WIRED「Lovable製アプリ調査」1,645本中10.3%にRLS重大欠陥（Lovable脆弱性記事で出典詳細）
Forrester「Secure Vibe Coding」提唱（Secure Vibe Coding記事で出典詳細）
Cursor公式ブログ「Introducing Bugbot」（公式リリースノート・速報時点で詳細未確認）
Cursor公式ドキュメント（速報時点で対応言語等の詳細未確認）