AIで書いたコードをAIが直す。Cursor Bugbotを試したら、バイブコーディングの次の壁が見えた

バイブコーディングを始めてから、作れるものの幅が広がりました。

SlackのBot、スプレッドシートとAPIを繋ぐ集計ツール、社内ダッシュボード。「とりあえず動くもの」をAIと一緒に作ることが、以前よりずっと速くなっています。10年のブランクを経てコードを書き始めた私でも、です。

ただ、正直に言うと、ひとつずっと気になることがありました。

「自分が書いたコード（AIが生成したコード）って、本当に安全なのかな」という不安です。

ロジックを通す、APIの繋ぎ方を覚える、動作を確認する、という流れは身についてきました。でも「AIが生成したコードの中に潜んでいるバグ」を、自分の目で全部チェックするのは正直難しい。ひとりでバイブコーディングしているとなおさらです。

この悩み、私だけじゃなかったようです。

米国の開発者調査（getpanto.ai）によると、AIコーディングツールを毎日使っている開発者は92%にのぼります。別の米国調査（secondtalent.com）でも、63%が回答しています。「AIが生成したコードのデバッグに、想定以上の時間がかかっている」というものです。

9割以上が毎日使って、6割以上が詰まっている。これがバイブコーディングの「次の壁」の正体です。

今回は、この壁を崩す可能性を持ったツール「Cursor（カーソル） Bugbot」を紹介します。AIで書いたコードを、AIが自動でレビューしてバグを指摘する仕組みです。日本語での解説記事がほぼ存在しない今のタイミングで、先に知っておく価値があると感じています。

---

AIで書いたコードには、どれくらいのリスクがあるのか

まず数値を正直に見ておきたいです。

2026年初頭の時点で、開発現場で書かれるコード全体のうち41%がAI生成・AI支援によるものという米国の調査があります（secondtalent.com、2025年調査）。約4割のコードが、何らかの形でAIの手を経ています。

問題は、そのコードの品質です。

指標	数値	出典
AI生成コードの重大バグ発生率（人間比）	1.7倍	secondtalent.com「AI-Powered Development: The State of Code Quality」2025年調査
AI生成コードのロジック・正確性エラー率（人間比）	1.75倍	secondtalent.com（同調査）
AI生成コードのセキュリティ脆弱性（人間比）	2.74倍	secondtalent.com（同調査）
AIコードに「高い信頼を置く」開発者の割合	わずか3%	secondtalent.com（同調査）

これを見ると「え、AIって危ないの？」と感じる方もいるかもしれません。

私の解釈は少し違います。「AIで爆速で書けるようになった。でも品質チェックの仕組みが追いついていない」という話です。

AIが書けるスピードに、確認のプロセスが対応できていない状態が生まれている。だから、AIを高く信頼している開発者がわずか3%というデータも、ある意味当然の結果です。

使う、でも全部は信頼しない。そのギャップを埋めるのが「品質保証の自動化」という次のステップです。

【バイブコーディングの現状マップ】

AIコーディングツール毎日使用率:  ████████████████████ 92%
デバッグに想定以上の時間かかる:  ████████████▌       63%
AIコードに高い信頼を置く開発者:  ▌                    3%

↑ この「使う」と「信頼する」のギャップが、品質保証ツール登場の背景

バイブコーディングが上手くいくほど、QAの課題は大きくなる

CS（カスタマーサクセス）の仕事をしていると、「動くツール」を作ったあとの「品質問題」がどれだけ大変かを経験します。

お客さんがツールを使い始めると、想定外の動作が次々と出てきます。「動くこと」と「安全に動き続けること」は別の話です。

バイブコーディングも同じ軌道を辿っていると感じています。作れるようになる人が増えると、次は「それちゃんと動くの？」という問いに向き合う必要が出てきます。

ここがバイブコーダーにとっての「次の壁」です。CS出身だからこそわかるんですけどね。

---

Cursor Bugbotとは何か。PRの門番として立つAI品質保証官

Cursor Bugbot（カーソル バグボット）は、GitHubのPR（プルリクエスト、コードの変更申請）に自動で組み込まれるバグ検出AIです。

2026年2月25日に一般提供（GA）が開始されました。TechCrunch（テッククランチ）で同年3月5日に「アジェンティック・コーディングシステム」として報道されています。アジェンティックとは、AIが自律的に動くコーディング支援を指します。

「PRが来たら自動でスキャンする」という仕組みです。人間が「ここを見て」と指示しなくても、GitHubにPRが作られるたびにバックグラウンドで自動処理が走ります。

報告の形式は3点セットです。

• タイトル（どんなバグか一行でまとめ）
• バグの詳細説明と影響範囲（なぜ問題なのか）
• 問題のあるコードのdiff（変更差分）（どの行が問題か）

PRを出すたびに「これ問題ありそうですよ」という通知が来るイメージです。

Bugbotの動きを流れで示すと次の通りです。

【Cursor Bugbotの動作フロー】

開発者がPRを作成（コードの変更をGitHubに申請）
    ↓
Bugbotがバックグラウンドで自動スキャン開始
    ↓
バグなし → PRにcleanのラベルを付与
バグあり → 「タイトル・説明・diff」の3点セットでコメント
    ↓
Autofix（自動修正機能）が起動
    ↓
  仮想マシン上でテスト実行
    ↓
  修正案を作成してPRに提案
    ↓
開発者が修正案を確認 → マージするかどうかは人間が決める

Autofixという機能が「次のレベル」

バグを指摘するだけでなく、独立した仮想マシン上でクラウドエージェント（AIが自律的に動くプログラム）が起動して、テストを行い、修正案を提案して、場合によってはそのまま適用まで実行します。

Cursor公式によると、Autofixの提案変更が「そのままマージされる割合」は35%を超えています。

3件に1件以上は、AIの修正をそのまま使えているということ。これはなかなかの数字です。

チームごとのルールも蓄積できる

Bugbotにはカスタムルール機能があります。

チームで「こういうコードの書き方はNG」というベストプラクティスを登録しておくと、それも含めてチェックしてくれます。過去の障害で学んだパターンを学習させていくイメージです。

独自のコーディング規約を持つチームには、この機能がかなり効いてきます。

---

実際どこまで解決できるのか。76%という数字の中身

Cursor公式が公開しているデータで、現時点（2026年2月時点）の「マージ前問題解決率」は76%です。

この数字、最初から76%だったわけではありません。

• ローンチ時: 解決率52%、1PRあたりのバグ修正数0.2件
• 40回の実験・改善後: 解決率70%超、1PRあたりのバグ修正数0.5件
• 現在（2026年2月）: 解決率76%

改善の速度を見ていると、Cursorチームがかなり本気でこれを育てているのが伝わります。

現在の月次処理規模は200万件超のPRです。Rippling、Discord、Samsara、Airtable、Sierra AIなど、実際のプロダクト企業での導入実績があります。

下記は、Bugbotが出力するレポートのイメージです（架空のサンプルです）。

## 🔴 Bugbot: SQLインジェクションの脆弱性を検出

**影響範囲**: 高リスク（セキュリティ）
**場所**: src/api/users.ts, 42行目

**問題の説明**:
ユーザー入力がサニタイズ（入力値の安全化処理）されないまま
SQLクエリに直接挿入されています。
悪意のある入力によってデータベースが不正操作されるリスクがあります。

**問題のあるコード**:
```diff
- const query = `SELECT * FROM users WHERE id = ${userId}`;
+ // Autofixの提案:
+ const query = `SELECT * FROM users WHERE id = ?`;
+ db.execute(query, [userId]);  // プリペアドステートメントで安全化

✅ Autofix準備完了 — “Apply fix”でそのまま適用できます

### 「残り24%」は何か

逆に言うと、24%のケースでは検出しきれないバグがあります。

現時点での制限も正直に書いておきます。複雑なビジネスロジックのバグ（「この業務フローではこの処理が走ってはいけない」という仕様理解を要するもの）は、まだAIには難しい部分があります。特定の環境依存のバグ、複雑なマルチスレッドの競合なども同様です。

ハマったポイントを先に言っておくと、「Bugbotが指摘してくれたから安心」という過信だけは避けてほしいです。ツールはあくまでレビューの補助であり、最終判断は常に人間が持つ前提で使うのが正解です。

「76%はBugbotに任せる、24%は自分が見る」という役割分担として考えると、かなり実用的な選択肢になります。

---

## 競合ツールと何が違うのか

AIによるコードレビュー系のツールはBugbotだけではありません。主要な競合との比較を整理します。

【AI PRレビューツール比較（2026年3月時点）】

┌─────────────────┬──────────────┬──────────┬───────────────────┐ │ ツール │ 対応PF │ 自動修正 │ 強み │ ├─────────────────┼──────────────┼──────────┼───────────────────┤ │ Cursor Bugbot │ GitHub のみ │ ✅ あり │ Cursor統合・深い │ │ CodeRabbit │ GitHub/Lab/ │ △ 限定的 │ マルチPF対応 │ │ │ Bitbucket │ │ │ │ Copilot（コパイロット） PR Rev │ GitHub のみ │ ❌ なし │ GitHub純正 │ │ Greptile │ 複数 │ ❌ なし │ セマンティック検索 │ └─────────────────┴──────────────┴──────────┴───────────────────┘

※PF = プラットフォーム

選択の軸はシンプルです。

GitHubメインで開発していて、Cursorをすでに使っているなら、Bugbotが一番スムーズに導入できます。GitLab（ゲットラボ）やBitbucket（ビットバケット）を使っているチームには現状対応していないため、CodeRabbit（コードラビット）の方が選択肢として合っています。

「GitHub純正がいい」という方はCopilot PR Reviewを選ぶことになりますが、Autofix機能がないため、バグ指摘後の修正は自分で行う必要があります。

### Claude（クロード） Code（クロードコード）との関係も整理しておく

Claude Code（クロード コード、Anthropic（アンソロピック）が提供するターミナルネイティブのAIコーディング環境）との棲み分けも確認しておきます。

Claude Codeは推論の深さと大規模なコンテキスト処理が強みですが、GUIがなくターミナル（コマンド入力画面）から操作するため、PRに自動で組み込まれるBugbotとは役割が異なります。

Bugbotが「PRの門番」、Claude Codeが「実装段階の思考パートナー」というイメージです。組み合わせて使うのが実用的な運用になります。

ちなみに参考として、2026年現在のAI IDEの「最も愛されているツール」評価を載せておきます（adventureppc.com調べ）。

- **Claude Code**: 46%
- **Cursor**: 19%
- **GitHub Copilot（ギットハブコパイロット）**: 9%

Copilotがエンタープライズでの普及率では圧倒的なのに、満足度でClaudeが引き離しているのは興味深いデータです。

---

## 価格と導入のリアルな話

価格は$40/ユーザー/月（月額）、$32/ユーザー/月（年額）です。

Cursor本体のサブスクリプション（Cursor Pro $20/月）とは別課金になります。両方使うと$60/月の計算です。

1ユーザーあたり月200PRレビューまで利用できます。チームの場合はプールされるので、複数人でも使いやすい設計です。

### 個人バイブコーダーへの正直な所感

個人で使うとなると、月$40は無視できない金額です。

「毎月PRを大量に出している」「業務ツールを複数人で保守している」という状況なら費用対効果が出やすいと思います。

一方で、趣味の個人プロジェクトや、まだ試作段階のツールなら、最初から導入する必要はないかもしれません。「ある程度育ってきたプロジェクトで、品質を担保したい段階になったら入れる」という判断が現実的です。

導入手順はシンプルです。

```bash
# 【Bugbot導入手順】
# 1. cursor.com/bugbot にアクセスしてGitHub Appを追加するだけ

# 設定ファイルの例（リポジトリのルートに .cursor/bugbot.yaml を作成）
# ────────────────────────────────────────────

bugbot:
  autofix: true           # 自動修正機能を有効化
  rules:
    - no-hardcoded-secrets  # APIキー・パスワードのハードコードを禁止
    - no-console-logs       # console.log（デバッグ用出力）の残留を禁止
    - sql-injection-check   # SQLインジェクション（DBへの不正な操作攻撃）チェック
  exclude:
    - "**/*.test.ts"       # テストファイルはスキャン対象外
    - "docs/**"            # ドキュメントはスキャン対象外

# ────────────────────────────────────────────
# これだけで次のPRから自動レビューが始まります

GitHub Appを追加したら、次のPRから自動でスキャンが走り始めます。設定ファイルはなくてもデフォルトで動くので、まず試してから調整するのが入りやすいやり方です。

---

バイブコーディングに「品質の壁」が見えてきた理由

ここまで読んできて「自分には関係ないかも」と思った方、少し待ってください。

バイブコーディングは「コードを書けなかった人が書けるようになるフェーズ」を終えつつあります。次のフェーズは「書けるようになった人が、書いたコードを安心して動かせるフェーズ」です。

arxiv.org（学術論文の共有プラットフォーム）に2026年3月に公開された”VibeContract”という論文で、同じことが指摘されています。タイトルの日本語訳は「バイブコーディングに欠けていたQAのピース」です。

学術的にも、バイブコーディングの「品質保証の欠如」が課題として認識されはじめています。

Bugbotはこの問題への、現時点で最も実用的な回答のひとつだと考えています。

具体的に「どんなバグを防げるか」を見ておく

CS出身の私が業務ツールで実際に経験したヒヤリハットを例に出すと、こういうものがあります。

// 【バイブコーディングで起きがちなバグの例】
// AIが書いたコードによくある「動くけど危ない」パターン

// ❌ バッドパターン: エラーハンドリングの漏れ
async function getCustomerData(customerId) {
  const response = await fetch(`/api/customers/${customerId}`);
  const data = await response.json(); // APIが失敗してもエラーを無視してしまう
  return data;
}

// ✅ Bugbotが推奨するパターン:
async function getCustomerData(customerId) {
  const response = await fetch(`/api/customers/${customerId}`);
  if (!response.ok) {
    // エラーハンドリング: APIが失敗した場合の処理を明示する
    throw new Error(`API error: ${response.status}`);
  }
  const data = await response.json();
  return data;
}
// Bugbotはこの「エラー処理の漏れ」を自動で検出して修正案を出してくれます

こういう「動くけど壊れやすいコード」を、PRが来るたびに自動でチェックしてくれるのがBugbotの実用的な価値です。

「プロのエンジニアには敵わないけど、自分の仕事を楽にするコードなら書ける」というスタンスでバイブコーディングしている人にとって、品質の自動チェックはかなり心強い存在です。

---

まとめ：バイブコーディングの「次のステップ」への備え

今回紹介したCursor Bugbotを整理します。

Bugbotでできること

• GitHub PRに自動でバグ検出コメントを付ける
• Autofixで修正案まで提案する（35%がそのままマージ）
• チームのカスタムルールを学習・適用する
• 月200万件超のPRを処理するスケール実績がある

現時点での制限

• GitHubのみ対応（GitLab・Bitbucketは非対応）
• 複雑なビジネスロジックの判断は苦手
• Cursor本体とは別課金（$40/ユーザー/月）

「AIで書いたコードをAIが直す」という発想は、1年前なら「まだ先の話」でした。

2026年3月の時点で、月200万件のPRを処理しながら76%の解決率を出すツールとして登場しています。日本語での解説がほぼない今、先に知っておいて損はないと感じています。

バイブコーディングで作ることに慣れてきた人は、品質を保証する方法についても少しずつ考えておくといいタイミングです。「とりあえず動くもの」の次のステップとして、Bugbotを頭の片隅に入れておいてください。

マジで使わないのもったいないです。

---

画像ディレクティブ一覧（合計5枚）

1. eyecatch×1（冒頭）
2. diagram×1（バイブコーディング統計チャート）
3. screenshot×1（GitHub PR + Bugbotコメント画面）
4. comparison×1（4ツール比較図）
5. diagram×1（バイブコーディング3フェーズ進化図）

eyecatch1 + diagram2 + screenshot1 + comparison1 = 合計5枚

---

記事中のデータ出典: getpanto.ai / secondtalent.com（2025年調査）/ cursor.com/blog/building-bugbot / arxiv.org/abs/2603.15691 / adventureppc.com