メインコンテンツまでスキップ

Cursor における Bugbot を使用した自動コードレビュー

Bugbot

Bugbot は、GitHub リポジトリと直接統合する Cursor の組み込み自動コードレビューエージェントです。プルリクエストを開くと、Bugbot は差分を分析し、潜在的なバグを特定し、改善を提案し、PR にインラインコメントを残します。このガイドでは、初期セットアップから高度な設定まで、フォーラムユーザーが頻繁に直面する PR ルーティングや GitHub Teams 統合の問題を含めて解説します。

Bugbot の機能​

Bugbot は各プルリクエストに対して複数のレイヤーの分析を実行します：

  • バグ検出 - 論理エラー、null 参照リスク、エッジケースを特定
  • セキュリティスキャン - SQL インジェクションやハードコードされたシークレットなどの潜在的な脆弱性をフラグ付け
  • スタイルと一貫性 - コードベースのパターンからの逸脱をチェック
  • パフォーマンスのヒント - N+1 クエリなどの非効率なパターンを強調
  • テストカバレッジ - 変更に対応するテストがない場合に注記
ヒント

Bugbot は完全にクラウドで実行されます。レビューを行うために Cursor を開いたままにする必要はありません。リポジトリで有効にすると、デスクにいるかどうかにかかわらず、Bugbot はすべての PR を自動的にレビューします。

前提条件​

Bugbot を設定する前に、以下を確認してください：

  1. Cursor Pro または Business プラン - Bugbot はフリーティアでは利用できません
  2. プルリクエストワークフローが有効な GitHub リポジトリ
  3. リポジトリへの管理者またはメンテナー権限（アプリのインストールに必要）
  4. チームベースの PR ルーティングが必要な場合は GitHub Teams の設定

リポジトリでの Bugbot の有効化​

フォーラムユーザーが最も多く報告する問題は、Bugbot が「disabled for this repository」と表示することです。これはほぼ常に、GitHub App のインストールステップがスキップされるか、部分的に完了したことに起因します。

ステップ 1：Cursor GitHub App をインストール​

Bugbot は GitHub App を通じて動作します。まだインストールしていない場合：

  1. Cursor を開き、Settings > Features > Bugbot に移動
  2. Connect GitHub Account をクリック
  3. GitHub にリダイレクトされ、Cursor アプリを認証
  4. スコープを選択：
    • All repositories - Cursor はアカウント内の任意のリポジトリをレビュー可能
    • Selected repositories - レビューする特定のリポジトリを選択
警告

インストール時に特定のリポジトリを選択し、後で新しいリポジトリを作成した場合、明示的に追加するまで Bugbot は新しいリポジトリで動作しません。これが「disabled for this repository」エラーの第一位の原因です。修正するには、GitHub > Settings > Integrations > Applications > Cursor > Configure に移動し、新しいリポジトリを追加してください。

ステップ 2：Cursor 設定で Bugbot を有効化​

GitHub アプリをインストールした後：

  1. Cursor Settings（Cmd/Ctrl + ,）を開く
  2. Features > Bugbot に移動
  3. Enable Bugbot を ON に切り替え
  4. Bugbot を有効にするリポジトリを選択

ステップ 3：接続を確認​

テストプルリクエストを作成し、Bugbot が応答するか確認：

# Create a test branch
git checkout -b test-bugbot-connection

# Make a small change
echo "// Bugbot test" >> README.md
git add README.md
git commit -m "test: verify bugbot connection"
git push origin test-bugbot-connection

GitHub で PR を開きます。30-60 秒以内に Bugbot がコメントを投稿するはずです。そうでない場合は、以下のトラブルシューティングセクションに進んでください。

PR ルーティングとレビューアー割り当て​

Bugbot は、ファイルパス、コード所有権、またはチームメンバーシップに基づいて、プルリクエストを特定のレビューアーにルーティングできます。フォーラムユーザーは、特に GitHub Teams で PR ルーティングが常に期待通りに動作しないことを報告しています。

PR ルーティングの理解​

PR ルーティングは、Bugbot が PR を分析した際に誰がレビュー要求を受けるかを決定します。ルーティングロジックは以下の優先順位に従います：

  1. CODEOWNERS ファイル - 存在する場合、変更されたファイルの所有者がレビューアーになる
  2. GitHub Teams マッピング - Bugbot 設定によるチームベースのルーティング
  3. フォールバック - すべてのメンテナーがレビュー要求を受ける

CODEOWNERS の設定​

リポジトリルート（または .github/CODEOWNERS）に CODEOWNERS ファイルを作成します：

# Default owners
*                           @team-leads

# Frontend files
src/components/             @frontend-team
src/pages/                  @frontend-team
src/styles/                 @frontend-team

# Backend files
src/api/                    @backend-team
src/models/                 @backend-team
src/middleware/             @backend-team

# Infrastructure
terraform/                  @devops-team
docker/                     @devops-team
.github/workflows/           @devops-team

# Security-sensitive files
src/auth/                   @security-team @team-leads
.env*                       @security-team

GitHub Teams 統合​

チームベースのルーティングでは、Bugbot は GitHub Teams のメンバーシップを読み取ります。設定するには：

  1. GitHub 組織で Org Settings > Teams の下にチームが設定されていることを確認
  2. 各チームにメンバーを追加
  3. CODEOWNERS でチーム名（@ プレフィックス付き）を参照
  4. Cursor で、Settings > Features > Bugbot > Advanced に移動
  5. Use GitHub Teams for routing を有効化
ヒント

CODEOWNERS の GitHub チーム名は完全に一致する必要があります。よくある間違いは、チーム slug ではなく表示名を使用することです。例えば、チーム名が「Frontend Engineers」で slug が frontend-engineers の場合、CODEOWNERS エントリは @Frontend Engineers ではなく @frontend-engineers でなければなりません。

一般的な PR ルーティングの問題​

問題：PR が間違ったチームにルーティングされる​

症状： バックエンドファイルを変更する PR がフロントエンドチームにルーティングされる。

原因： CODEOWNERS パターンの重複。最初に一致したパターンが優先され、パターンは上から下に評価されます。

解決策： より具体的なパターンが前にくるよう CODEOWNERS ファイルを並べ替えます：

# Specific first
src/auth/                   @security-team @team-leads
src/api/                    @backend-team

# Then general
src/                        @all-developers
*                           @team-leads

問題：チームがレビュー要求を受け取らない​

症状： Bugbot は PR をレビューするが、GitHub チームメンバーがレビューアーとして追加されない。

原因： GitHub チームが「secret」（非表示）に設定されているか、メンバーがいない。

解決策： GitHub > Organization > Teams > [チーム名] > Settings に移動。レビュー要求を受け取るたい場合は、チームの可視性が「Secret」に設定されていないことを確認。チームにアクティブなメンバーがいることを確認。

Bugbot 設定​

基本的な有効化に加えて、Bugbot には動作をカスタマイズするためのいくつかの設定オプションがあります。

レビューの厳格さ​

Bugbot が発見に対してどの程度厳格かを制御します：

{
  "bugbot.severity": "balanced",
  "bugbot.maxComments": 20,
  "bugbot.autoResolve": false
}
厳格さ動作
strict軽微なスタイル問題を含むすべての発見を報告
balancedバグ、セキュリティ問題、重大なスタイル問題を報告（デフォルト）
lenientバグとセキュリティ脆弱性のみを報告

ファイル除外​

生成ファイルやベンダーファイルのレビューを防止します：

{
  "bugbot.excludePaths": [
    "**/*.min.js",
    "**/*.min.css",
    "node_modules/**",
    "dist/**",
    "build/**",
    "*.lock",
    "package-lock.json",
    "yarn.lock"
  ]
}

セキュリティエージェント設定​

Bugbot には脆弱性をスキャンする専用セキュリティエージェントが含まれています。独立して設定できます：

{
  "bugbot.securityAgent": {
    "enabled": true,
    "sensitivityLevel": "high",
    "scanForSecrets": true,
    "scanForDependencies": true,
    "ignorePatterns": [
      "test/**",
      "__mocks__/**"
    ]
  }
}
警告

セキュリティエージェントは PR 差分内のハードコードされたシークレット（API キー、パスワード、トークン）をスキャンします。シークレットと思われるものを見つけた場合、クリティカルな問題としてフラグ付けします。これは安全機能です。フラグ付けされた文字列が実際のシークレットでないことを確認せずにこれらの警告を無視しないでください。実際のキーのように見えるテストフィクスチャであっても、誰かが本番コードにコピーした場合に危険な可能性があります。

承認ワークフロー​

Bugbot は GitHub のレビュー承認システムと統合します。Bugbot の発見が PR のマージをブロックするかどうかを設定できます。

必須レビューの設定​

GitHub リポジトリ設定で：

  1. Settings > Branches > Branch protection rules に移動
  2. メインブランチのルールを編集
  3. Require pull request reviews before merging の下で：
    • 必須承認レビュー数を設定（例：2）
    • 新しいコミットがプッシュされたときに Dismiss stale pull request approvals を有効化
    • Require review from Code Owners を有効化

Bugbot を必須レビューアーとして設定​

Bugbot を必須レビューアーとして設定できます。有効にすると、Bugbot がレビューを完了し、承認するかレビューが棄却されるまで、PR をマージできません。

Cursor で：

  1. Settings > Features > Bugbot > Workflow
  2. Block merge on critical findings を有効化
  3. ブロックの厳格さのしきい値を設定（デフォルト：critical と high）
ヒント

ブロック機能は慎重に使用してください。しきい値を低く設定しすぎると（低厳格度の発見でブロック）、スタイル問題がマージを妨げたときに開発者が不満を感じる可能性があります。「critical と high」から始め、チームの経験に基づいて調整してください。

Bugbot の意見の相違への対処​

時として Bugbot がフラグ付けしたものが、開発者は誤検知だと考える場合があります。推奨されるワークフロー：

  1. GitHub の Bugbot コメントで Resolve conversation をクリック
  2. なぜ誤検知か説明するコメントを追加
  3. 同じパターンで繰り返し誤検知が発生する場合、// bugbot-ignore コメントを追加：
# bugbot-ignore: This is intentionally using eval for a DSL interpreter
result = eval(user_expression)

"Disabled for This Repository" のトラブルシューティング​

これは最も報告される Bugbot の問題です。この診断フローチャートに従ってください。

診断ステップ 1：GitHub App のインストールを確認​

# Check if the Cursor app has access to your repo
gh api repos/{owner}/{repo}/installation --jq '.id'

これが 404 を返す場合、GitHub App はこのリポジトリにインストールされていません。

解決策： GitHub > Settings > Integrations > Applications > Cursor > Configure に移動し、リポジトリを追加してください。

診断ステップ 2：Cursor のリポジトリ設定を確認​

  1. Cursor 設定を開く
  2. Features > Bugbot に移動
  3. 有効なリストでリポジトリを探す
  4. ない場合、Add Repository をクリックして選択

診断ステップ 3：ブランチ保護ルールを確認​

Bugbot は GitHub App がレビューコメントを投稿できることをリポジトリに要求します。ブランチ保護ルールが厳しすぎる場合：

  1. GitHub > Settings > Branches に移動
  2. ブランチ保護ルールを編集
  3. Allow specified actors to bypass requirements に Cursor アプリが含まれていることを確認
  4. Restrict who can push to matching branches でアプリがブロックされていないことを確認

診断ステップ 4：競合するアプリを確認​

他の自動レビューツール（CodeRabbit、GitHub Copilot、SonarQube）をインストールしている場合、Bugbot と競合する可能性があります。

解決策： 他のレビューボットを一時的に無効にし、Bugbot が動作し始めるか確認。動作する場合、ツールが共存するように設定する必要があり、webhook 設定やレビュートリガーの調整が必要になる場合があります。

診断ステップ 5：Bugbot ステータスを確認​

# Check Cursor service status
curl -s https://status.cursor.sh/api/v2/incidents.json | jq '.incidents[] | select(.status != "resolved")'

アクティブなインシデントがある場合、解決を待って再試行してください。

警告

Cursor のアップデート直後、Bugbot が「disabled」と表示されることがあります。これは GitHub トークンの再認証が必要な既知の問題です。Settings > Features > Bugbot に移動し、Disconnect をクリックしてから GitHub アカウントを Reconnect してください。設定を失うことなくトークンがリフレッシュされます。

Bugbot と GitHub Teams 統合の詳細​

チームメンバーシップの同期​

Bugbot はパフォーマンスのために GitHub チームメンバーシップをキャッシュします。チームメンバーを追加または削除した場合、変更がすぐに反映されない場合があります。

強制同期するには：

  1. Cursor 設定を開く
  2. Features > Bugbot > Advanced に移動
  3. Sync GitHub Teams をクリック
  4. 同期が完了するのを待つ（通常 30 秒以内）

複数チームメンバーシップ​

開発者が複数のチームに属している場合、Bugbot は CODEOWNERS の一致に基づいてルーティングします。ファイルが複数のチームに所有され、開発者が両方のチームにいる場合、重複ではなく単一のレビュー要求を受け取ります。

チームベースのレビューポリシー​

チームごとに異なるレビュー要件を設定できます：

{
  "bugbot.teamPolicies": {
    "security-team": {
      "requiredReviews": 2,
      "blockOnHighSeverity": true,
      "additionalScanners": ["dependency-check"]
    },
    "frontend-team": {
      "requiredReviews": 1,
      "blockOnHighSeverity": false
    }
  }
}

Bugbot のパフォーマンスと制限​

レビュー速度​

Bugbot は通常、PR がオープンまたは更新されてから 30-90 秒以内にレビューを完了します。速度に影響する要因：

要因影響
PR サイズ（変更行数）大きな差分は分析に時間がかかる
ファイル数各ファイルは個別分析が必要
リポジトリサイズ大きなコードベースはより多くのコンテキスト収集が必要
現在の負荷ピーク時はレスポンスが遅くなる可能性

コメント制限​

デフォルトで、Bugbot はレビューごとに最大 20 件のコメントを投稿します。これは PR 作成者が圧倒されるのを防ぎます。これを調整できます：

{
  "bugbot.maxComments": 50
}
ヒント

Bugbot が毎 PR コメント制限に達する場合、厳格度のしきい値を引き上げることを検討してください。制限に達することは、Bugbot が多くの低優先度の問題を見つけていることを意味します。それらをフィルタリングすると、レビューがより実行可能になります。

レート制限​

Bugbot は GitHub API のレート制限に従います。組織で同時に多くの PR がオープンされた場合、レビューがキューに入る場合があります。Bugbot は順番に処理し、すべてのレビューは最終的に完了します。

Bugbot 導入のベストプラクティス​

読み取り専用モードから始める​

既存のリポジトリで初めて Bugbot を有効にする際は、読み取り専用モード（マージブロックなし）から始めてください。これにより、ワークフローを妨げずにチームは Bugbot が何を見つけるかを確認できます。1-2 週間発見をレビューした後、設定を調整し、適切であればマージブロックを有効にします。

Bugbot の発見を学習ツールとして使う​

Bugbot の発見は現在の PR を修正することだけではありません。学習の機会です：

  1. 繰り返し発生する発見タイプを追跡（例：「null 参照リスク」が 30% の PR で発生）
  2. 将来のコードでパターンを防ぐための .cursor/rules エントリを作成
  3. チームチャンネルで興味深い発見を共有

定期的な設定レビュー​

毎月 Bugbot 設定をレビューしてください：

  • ファイル除外はまだ適切か？
  • 厳格度のしきい値は正しく調整されているか？
  • 抑制すべき新しい誤検知パターンはないか？
  • 現在の PR サイズに対してコメント制限は適切か？

まとめ​

Bugbot は、Cursor に接続された GitHub リポジトリのすべてのプルリクエストに自動化されたインテリジェントなコードレビューをもたらします。最も一般的な問題「disabled for this repository」は、GitHub App のインストール範囲を検証し、リポジトリが明示的に追加されていることを確認することでほぼ常に解決します。CODEOWNERS で PR ルーティングを設定し、セキュリティエージェントを調整し、マージブロックに漸進的なアプローチを採用することで、チームは Bugbot をバグとセキュリティ脆弱性に対する信頼できる第一の防御線として活用できます。