室谷前回はCursor Agentの使い方を解説しましたが、今回はBugbotとHooksという2つの機能を深掘りしていきます。この2つ、実は「Cursorをチームで本格運用する上で外せない」機能なんですよね。
テキトー教師そうなんですよ。.AI（ドットエーアイ）コミュニティのメンバーさんからも「Bugbotって何が便利なんですか？」「Hooksはどう使うんですか？」っていう質問が最近増えていて。
特にCursorを個人で使い始めて、チームに展開しようとする段階で壁にぶつかる方が多いですね。
特にCursorを個人で使い始めて、チームに展開しようとする段階で壁にぶつかる方が多いですね。
室谷Bugbotは一言で言うと「AIによるコードレビュー自動化」です。GitHubのプルリクエストを自動でレビューして、ロジックのバグや脆弱性を検知してくれる。
Cursorのコア機能の中でも、僕が特に注目してる機能の一つです。
Cursorのコア機能の中でも、僕が特に注目してる機能の一つです。
テキトー教師講座でも「コードレビューの工数が重い」という声はよく聞きます。特に小規模なチームだと、シニアエンジニアがボトルネックになりがちで。
そこにBugbotが入ると、レビュー待ちの時間が劇的に変わります。
そこにBugbotが入ると、レビュー待ちの時間が劇的に変わります。
室谷Ripplingというアメリカの人事管理SaaS企業が「Bugbotでコードレビューの工数が40%削減された」って言ってるんですよね。Discordのエンジニアリングリーダーも「深刻な障害を1件防ぐだけで、コストが元取れる」とコメントしていて・・・これって企業規模関係なく当てはまる話だと思います。
テキトー教師40%削減って相当ですよね。この記事では、そのBugbotの仕組みと使い方、そしてHooksという自動化機能の両方を、実際の使い方ベースで解説していきます。
Cursor Bugbotとは？AIコードレビューの仕組みを理解する
室谷まずBugbotの基本から整理しましょう。Bugbotは、GitHubのプルリクエストに対して自動でコードレビューを実行するCursorのツールです。
2025年7月にベータから正式リリースされた機能で、2026年現在はかなり成熟してきていますね。
2025年7月にベータから正式リリースされた機能で、2026年現在はかなり成熟してきていますね。
テキトー教師「AIがコードレビュー」と聞くと「本当にちゃんと見てくれるの？」って思う方も多いと思うんですが、数字で見ると説得力がありますよね。2025年7月のリリース時点で、Bugbotが指摘した問題のうち52%がマージ前に修正されていた。
つまり指摘の半分以上が「本当のバグ」だったということです。
つまり指摘の半分以上が「本当のバグ」だったということです。
室谷それが今は78%まで上がってるんですよね。2026年4月時点で78.13%。
他の競合AIコードレビューツールと比べても、次点のGreptileが63%なので15ポイントも高い。これ、かなり圧倒的な数字だと思います。
他の競合AIコードレビューツールと比べても、次点のGreptileが63%なので15ポイントも高い。これ、かなり圧倒的な数字だと思います。
| AIコードレビューツール | 解決率 | 分析PR数 |
|---|---|---|
| Cursor Bugbot | 78.13% | 50,310 |
| Greptile | 63.49% | 11,419 |
| CodeRabbit | 48.96% | 33,487 |
| GitHub Copilot | 46.69% | 24,336 |
| Codex | 45.07% | 19,384 |
| Gemini Code Assist | 30.93% | 21,031 |
（出典: Cursor Bugbot now self-improves with learned rules、2026年4月）
テキトー教師この「解決率」という指標が面白いんですよ。単に「バグを見つけた件数」じゃなくて、「開発者が実際に修正した割合」を測っている。
つまり「役に立ったコメントの比率」なんですよね。
つまり「役に立ったコメントの比率」なんですよね。
室谷そこが本質で。AIが大量にコメントを出しても、開発者が「また誤検知か」ってスルーするなら意味がない。
Bugbotは「本当に修正すべきバグを指摘できているか」をKPIにして改善を続けてきた。その設計思想が数字に出てると思います。
Bugbotは「本当に修正すべきバグを指摘できているか」をKPIにして改善を続けてきた。その設計思想が数字に出てると思います。
テキトー教師Bugbotが検知するのは主に3種類です。
- ロジックバグ: 計算ミス、条件分岐の誤り、エラーハンドリングの漏れ
- エッジケース: 想定外の入力、境界値の処理ミス
- セキュリティ問題: 認証漏れ、入力値の未サニタイズ、シークレットのハードコード
室谷コンパイラエラーや型エラー、ドキュメントの指摘は意図的にフィルタリングしてるんですよね。「そこはIDEやCIで拾えるから、Bugbotは人間でも気づきにくいロジックレベルの問題に集中する」という設計。
テキトー教師これ、コミュニティのメンバーさんに伝えると「なるほど！」って反応が多くて。AIコードレビューを入れると「trivialなコメントが大量に来て逆に邪魔」ってイメージがあるんですよ。
Bugbotはそこを意識的に絞り込んでいる。
Bugbotはそこを意識的に絞り込んでいる。
Bugbotの仕組み：なぜ高精度なのか
室谷技術的な話になりますが、Bugbotがなぜここまで精度が高いのか、少し掘り下げたいですね。Cursor社のブログを読むと、かなり興味深い設計になっていて。
テキトー教師教える立場から言うと、「AIが単に差分を読んでコメントする」というシンプルな構造じゃないんですよ、というのを最初に伝えることが大切で。
室谷最初のバージョンでは「8つの並列パス実行 + 多数決投票」という手法を使っていたそうです。同じ差分を異なる順序でAIに渡して、複数のパスが同じバグを指摘した場合だけレポートに含める。
これだけで誤検知率が大幅に下がった。
これだけで誤検知率が大幅に下がった。
テキトー教師面白いアプローチですよね。一種のアンサンブル学習みたいな発想で。
室谷で、最近のバージョンでは「エージェント型アーキテクチャ」に移行したんですよね。固定のパスを実行するんじゃなくて、AIがコードをツールで参照しながら「怪しいところ」を自分で掘り下げていく。
変更された行だけじゃなくて、変更が影響する周辺コードまで追いかけるようになった。
変更された行だけじゃなくて、変更が影響する周辺コードまで追いかけるようになった。
テキトー教師それが「直接変更されたファイルだけじゃなく、他のコンポーネントとの相互作用まで見てくれる」って評価につながってるんですよね。MavenのスタッフエンジニアさんがBugbotを「大規模なMRで特に役立つ」と言っているのもその辺りが理由だと思います。
室谷さらに2026年4月には「学習ルール（Learned Rules）」機能が追加されました。Bugbotが過去のPRのフィードバックから自動でルールを学習して、次のレビューに活かす。
「このコメントに開発者が反応しなかった」「ここは誤検知だった」という信号を蓄積してチューニングしていく。
「このコメントに開発者が反応しなかった」「ここは誤検知だった」という信号を蓄積してチューニングしていく。
テキトー教師使えば使うほど賢くなる仕組みですよね。2026年4月時点で11万以上のリポジトリで学習ルールが有効化されていて、4万4千以上のルールが生成されているとのことで。
Bugbotの使い方・設定方法
室谷では実際の使い方を見ていきましょう。まずBugbotはCursorのダッシュボードから有効化します。
テキトー教師設定の流れとしては、こんな感じです。
- cursor.com/bugbot にアクセスするか、Cursorダッシュボードの「Bugbot」タブを開く
- GitHubリポジトリを連携する
- 有料プランに加入する（詳しくは後述）
- 以降は新しいプルリクエストが作成されると自動でBugbotがレビューを実行
室谷セットアップ自体は5分もかからない。GitHubのインテグレーションを入れるだけなんですよね。
あとはPRを出すと自動でBugbotのコメントが来る。
あとはPRを出すと自動でBugbotのコメントが来る。
テキトー教師コミュニティのメンバーさんに「とりあえず触ってみてください」と言うと、「思ってたより簡単だった」って声が多くて。特別な設定をしなくても動くというのが入門のハードルを下げていますね。
室谷BUGBOT.mdというファイルでカスタムルールを書けるのも重要なポイントで。自分たちのコードベース特有のルール、たとえば「このAPIを使う時は必ずこのミドルウェアを経由すること」みたいな内部のお作法をBugbotに教えられる。
テキトー教師「AIに自社のコーディング規約を覚えさせる」というイメージですよね。これ、チーム展開する時に特に効いてきます。
オンボーディングのドキュメントにもなりますし。
オンボーディングのドキュメントにもなりますし。
室谷BUGBOT.mdの構造はCursor公式サイトのサンプルが参考になります。
---
description: "APIのセキュリティ基準と認証パターンをレビューで強制する"
globs: src/api/**/*.ts
---
# APIセキュリティ基準
## 以下をフラグアップすること
- authenticate()ミドルウェアが未適用のエンドポイント
- query()にsanitize()なしでユーザー入力を渡している箇所
- 文字列リテラルとしてシークレットがハードコードされている箇所
- 公開向けルートにrateLimit()がない箇所
- 本番環境でcors({ origin: '*' })を使っている設定
- 内部のstackTraceフィールドをレスポンスで露出している箇所
この書き方、Cursor Rulesの.mdcファイルと似てますよね。「どのファイルに適用するか（globs）」と「何をチェックするか」を書くだけで、Bugbotがコードレビュー時に参照してくれる。
室谷MYUUUのプロジェクトでも、セキュリティ系のルールは最初にBUGBOT.mdに定義することを習慣にしています。「ここは自動で見ておいてくれ」という領域をBugbotに委ねることで、人間のレビュアーがより本質的な設計判断に集中できる。
Bugbot Autofix：見つけて、直す
室谷Bugbotの中でも特に面白いと思う機能が「Autofix」です。2026年2月に正式リリースされた機能で、バグを指摘するだけじゃなく、Cursor CloudのAgentが自動でその修正まで行う。
テキトー教師「見つけた問題を自動で直す」というのは、コードレビューの次のステップですよね。BugbotがPRのコメントで「ここ問題ですよ」と指摘して、さらに「修正案のPRを出しておきました」まで自動でやってくれる。
室谷Autofixで提案された変更のうち、35%以上がそのままマージされているというデータがあって。「全部完璧じゃないけど、多くの場合そのまま使える修正を出してくれる」という精度です。
テキトー教師この数字、コンテキストで考えると面白くて。コードレビューのコメントが来て、開発者が自分で修正するのと比べて、Autofixは「スタートダッシュ」を提供してくれるんですよね。
修正の8割くらいはAutofixの提案をちょっと調整するだけで済む、という感覚。
修正の8割くらいはAutofixの提案をちょっと調整するだけで済む、という感覚。
室谷BugbotのAutofixはCloud Agentとして動くんですよね。仮想マシンの中でコードを実際に動かして確認しながら修正を進める。
「試して、確認して、直す」というループをAgent側がやってくれる。
「試して、確認して、直す」というループをAgent側がやってくれる。
テキトー教師ここが従来のAIコードレビューと一線を画す点で。コメントを出すだけのAIレビュアーから、実際にPRを修正するAgent型になっているということで。
Bugbotの料金：個人・チーム・Enterprise
室谷料金の話もしましょう。2026年現在の料金はこうなっています。
| プラン | 料金 | 特徴 |
|---|---|---|
| Bugbot Pro | $40/ユーザー/月 | 14日間個人トライアル、月200PRまで、カスタムルール利用可 |
| Bugbot Teams | $40/ユーザー/月 | 14日間チームトライアル、PR数無制限、分析ダッシュボード、高度なルール設定 |
| Bugbot Enterprise | 要問合せ | 30日間組織全体トライアル、高度な分析・レポート、優先サポート |
（出典: Cursor Pricing）
テキトー教師Proは月200PRまでという制限があって、Teamsはそれがない。小規模なチームだとProで足りることもありますが、アクティブに開発しているチームだと200PRはわりとすぐ超えますよね。
室谷MYUUUのような小さい開発チームでも、スプリントが詰まってる時期は200PR/月を超えることがある。その場合はTeamsにした方が安心感があります。
テキトー教師「Cursor本体のサブスクリプション（Pro: $20/月）と別にBugbotのサブスクリプションが必要なんですか？」って質問がコミュニティでもよく出るんですが、そうなんですよね。別サブスクリプションです。
室谷コストとしては月$40追加になるわけですが、「コードレビューの工数が40%削減」という効果と比べると、エンジニアの時給で計算すればすぐペイする数字だと思います。チームに中堅以上のエンジニアが1人でもいれば、その人のレビュー工数を減らすだけで元が取れる。
テキトー教師14日間の無料トライアルがあるので、まずは試してみることをおすすめしています。自分のプロジェクトで実際に使ってみないと、効果の実感がわかないですよね。
Cursor Hooksとは？エージェントのライフサイクルを制御する
室谷次はHooksの話をしましょう。これはBugbotとは別の機能で、「Cursorのエージェントが特定の操作を行う前後に、任意のスクリプトを実行できる」という仕組みです。
テキトー教師「Hooksって名前は聞いたことあるけど何に使うの？」という方、講座でも多いですね。一言で言うと「Cursorのエージェントの行動をカスタマイズ・監視するためのメカニズム」です。
室谷Hooksはhooks.jsonというファイルで定義します。置き場所は3つあって、プロジェクト固有の設定（.cursor/hooks.json）、ユーザーグローバルの設定（~/.cursor/hooks.json）、Enterprise向けのシステム設定（/etc/cursor/hooks.json）。
全部のファイルに書かれたHooksが合わせて実行されます。
全部のファイルに書かれたHooksが合わせて実行されます。
{
"version": 1,
"hooks": {
"afterFileEdit": [
{ "command": "hooks/lint.sh" }
],
"stop": [
{ "command": "hooks/notify.sh" }
]
}
}
設定の構造はシンプルですよね。「どのタイミングで（hookイベント名）」「何を実行するか（command）」だけ書けばいい。
複数のコマンドを並べることもできます。
複数のコマンドを並べることもできます。
室谷このJSON、Cursor Rulesの.mdcファイルに慣れている人にはとっつきやすい形式だと思います。
6つのHookイベント：それぞれの用途
テキトー教師2026年現在、Hooksには6種類のイベントがあります。整理するとこうなります。
| イベント | タイミング | 代表的な用途 |
|---|---|---|
| beforeSubmitPrompt | プロンプト送信前 | ログ記録、プロンプト内容の監査 |
| beforeShellExecution | シェルコマンド実行前 | 危険なコマンドのブロック、アクセス制御 |
| beforeMCPExecution | MCPツール実行前 | MCP呼び出しの承認・拒否 |
| beforeReadFile | ファイル読み込み前 | シークレット情報の除去、機密ファイルの保護 |
| afterFileEdit | ファイル編集後 | 自動フォーマット、lint実行 |
| stop | タスク完了時 | 通知送信、Gitコミット、ログ保存 |
室谷個人的に一番実用的だと思うのがbeforeShellExecutionとafterFileEditの組み合わせで。前者でやってはいけない操作をブロックして、後者でコード品質を自動で保つ。
テキトー教師beforeShellExecutionはAgentが危険なコマンドを実行しようとした時にブロックできるんですよね。これ、セキュリティ的にも重要で。
室谷レスポンスのJSONで制御するんですよ。Hookスクリプトが
{"continue": false, "permission": "deny"}を返すと、実行がブロックされる。テキトー教師beforeReadFileも面白い用途があって。ファイルを読み込む前に、そのファイルの内容からAPIキーやシークレットを除去してからLLMに渡す、というフィルタリングができます。
会社のコードに本番のAPIキーが書かれていて外部LLMに送りたくない、という場面で使えますよね。
会社のコードに本番のAPIキーが書かれていて外部LLMに送りたくない、という場面で使えますよね。
室谷それ、かなり重要なユースケースだと思います。セキュリティポリシー上、ソースコードを外部サービスに送るのに制約がある会社は多いですから。
Hookでフィルタリングを挟むことで、ポリシーに準拠しながらCursorを使える。
Hookでフィルタリングを挟むことで、ポリシーに準拠しながらCursorを使える。
テキトー教師stopフックも実践的ですよね。Cursorのタスクが完了した時に通知を飛ばす、Gitコミットを自動で作る、ログを保存する、といった処理をトリガーできます。
GitButlerというツールがCursor Hooksを使って「エージェントの作業が完了するたびに自動でGitコミットする」機能を実装していて、これが一つの典型的なユースケースです。
GitButlerというツールがCursor Hooksを使って「エージェントの作業が完了するたびに自動でGitコミットする」機能を実装していて、これが一つの典型的なユースケースです。
Hooksの実践例：プロジェクトに合わせた設定
室谷実際にHooksを使ってみた場合の、おすすめの設定パターンをいくつか紹介しましょう。
テキトー教師まず「タスク完了通知」はすぐに使えます。Cursorで長時間かかる処理をAgentに任せた時、完了したら知らせてほしいというニーズに応えられます。
macOSであればこんな設定です。
macOSであればこんな設定です。
{
"version": 1,
"hooks": {
"stop": [
{
"command": "osascript -e 'display notification \"タスクが完了しました\" with title \"Cursor\" sound name \"Glass\"'"
}
]
}
}
これ、地味に便利なんですよね。Agentに長い処理を任せて別の作業をしていても、完了したらMacの通知で教えてくれる。
テキトー教師次が「ファイル編集後の自動Lint」。afterFileEditフックでeslintやprettierを自動実行して、コードスタイルを強制できます。
{
"version": 1,
"hooks": {
"afterFileEdit": [
{ "command": "npx eslint --fix" }
]
}
}
Agentが書いたコードが自動でフォーマットされる状態になる。「Agentに書かせたら変なフォーマットで出てきた」という問題を根本から解消できます。
テキトー教師3つ目が「危険なコマンドのブロック」。本番環境のデータベースを直接操作するコマンドや、重要ファイルへの変更を制限するようなスクリプトを用意して、beforeShellExecutionフックから呼び出す。
室谷これはチームで使う場合に特に重要ですよね。Agentが意図しない操作をしてしまうリスクを、Hookで事前に封じ込められる。
テキトー教師Hooksに関しては、CursorダッシュボードのOutputチャンネルでHooksを選ぶとデバッグ情報が確認できます。Hookが正しく動いているか確認する時はここを見るのが一番早いです。
HooksとCursor Rulesの使い分け
室谷「HooksとCursor Rulesって何が違うんですか？」という質問、.AIのコミュニティでもよく出るんですよね。これを整理しておきたいです。
テキトー教師一言で言うと「決定論的かどうか」の違いで。HooksはスクリプトとしてCursorの外側で実行されるので、必ず同じ動作をする。
RulesはLLMに「このルールを守ってください」と伝えるものなので、LLMの判断次第で解釈が変わりうる。
RulesはLLMに「このルールを守ってください」と伝えるものなので、LLMの判断次第で解釈が変わりうる。
室谷「絶対にやってはいけないこと」はHooksで強制する。「こういうスタイルで書いてほしい」という方針はRulesで伝える。
この使い分けが本質的だと思います。
この使い分けが本質的だと思います。
テキトー教師あとHooksはLLMを経由しないので速度が速い。RulesやMCPはLLMが判断して実行するので、複数のステップが必要になります。
バックグラウンドで確実に実行したい処理はHooksの方が向いていますよね。
バックグラウンドで確実に実行したい処理はHooksの方が向いていますよね。
室谷GitButlerがHooksを使って「コミットの自動作成」を実装しているのは、その典型例で。「コミットを作る」という操作は毎回必ず決まった手順で行いたい。
LLMに「適当に判断して」ではなく、確実に決まったスクリプトで実行させたい。そういう場合にHooksが最適です。
LLMに「適当に判断して」ではなく、確実に決まったスクリプトで実行させたい。そういう場合にHooksが最適です。
テキトー教師まとめると、こう使い分けると良いですよ。
- Hooks: セキュリティ制御、自動フォーマット、通知、Gitオペレーション
- Cursor Rules: コーディングスタイル、設計方針、ドメイン知識の伝達
cursor ignore：不要なファイルをCursorから除外する
室谷最後に.cursorignoreの話もしておきましょう。これはBugbotやHooksとは別の機能ですが、Cursorを使う上でセットで知っておくべき設定です。
テキトー教師.gitignoreに近い発想ですよね。「このファイルはCursorのコンテキストに含めないでください」という指定ができる。
室谷.cursorignoreファイルをプロジェクトのルートに置いて、除外したいパスを書けばいい。
# 環境設定ファイル
.env
.env.local
.env.*.local
# ビルド成果物
dist/
build/
*.bundle.js
# テストスナップショット
**/__snapshots__/
# ログファイル
*.log
logs/
これ、コンテキスト管理的にも重要で。Cursorはファイルの内容をLLMに送りますが、.envのような機密情報が含まれるファイルを除外することで、意図しない情報漏洩を防げます。
室谷セキュリティポリシー的にも必須の設定だと思います。特に企業で使う場合、本番環境の設定ファイルやAPIキーが含まれるファイルはきっちり除外しておくべきで。
テキトー教師また、node_modulesやdistといった大きなディレクトリを除外することで、Cursorのパフォーマンスも改善します。コンテキストウィンドウの節約にもなりますし。
室谷.cursorignoreと.gitignoreは似てますが別ファイルです。Gitで管理したくないファイルが全てCursorから除外すべきファイルとは限らないので、必要に応じて別々に管理するのが正解です。
FAQ：Cursor BugbotとHooksのよくある質問
室谷ここではコミュニティでよく出る質問にまとめて答えましょう。
テキトー教師まず「Bugbotはプライベートリポジトリでも使えますか？」というのが一番多い質問です。
室谷使えます。GitHubのプライベートリポジトリでも動作します。
ただし、コードはCursorのサーバーに送られることになるので、セキュリティポリシーの確認は必要です。Cursor社はSOC 2認証を取得していて、データの取り扱いに関するポリシーはで確認できます。
ただし、コードはCursorのサーバーに送られることになるので、セキュリティポリシーの確認は必要です。Cursor社はSOC 2認証を取得していて、データの取り扱いに関するポリシーはで確認できます。
テキトー教師次が「GitLab、Bitbucketでも使えますか？」という質問。2026年現在、BugbotはGitHubとの連携が主軸です。
GitLabやBitbucketへの対応は限定的なので、最新情報はを確認することをおすすめします。
GitLabやBitbucketへの対応は限定的なので、最新情報はを確認することをおすすめします。
室谷「Hooksは全プランで使えますか？」という質問も出ますね。Cursor Proの機能として提供されています。
詳細はを確認してください。
詳細はを確認してください。
テキトー教師「Bugbotのコメントが多すぎて邪魔です」というフィードバックをもらうこともあります。そういう場合はBUGBOT.mdでフォーカスする問題カテゴリを絞り込むか、学習ルール機能を有効化して「このパターンはスルーしてください」という信号を蓄積させるのが効果的です。
室谷最初から精度が完璧なわけじゃなくて、使いながらチューニングしていく、というのがBugbotの設計思想だと思います。学習ルールが蓄積されるほど、自分たちのコードベースにフィットしていく。
まとめ：BugbotとHooksでCursorをチーム運用に昇華させる
室谷今回はBugbotとHooksを解説しました。Cursorを個人で使う段階から、チームで本格的に使う段階へのステップアップに、この2つは特に重要だと思います。
テキトー教師それぞれの役割をまとめると、こうなります。
- Bugbot: PRに対する自動コードレビュー。人間のレビュアーがロジック判断に集中できるよう、機械的に拾えるバグを先に除去してくれる
- Bugbot Autofix: バグを見つけるだけでなく、修正まで自動で実施。提案の35%以上がそのままマージされる精度
- Hooks: エージェントのライフサイクルに処理を挿入。セキュリティ制御、自動フォーマット、通知など確実に実行したい処理に
- cursor ignore: 不要ファイルをCursorのコンテキストから除外。パフォーマンスとセキュリティの両立
室谷「AIが書いたコードをどう品質管理するか」という課題は、AIコーディングが普及するほど重要になってきます。BugbotとHooksは、その課題に対するCursorのアンサーだと思いますね。
テキトー教師.AIコミュニティのメンバーさんにも「まずBugbotの14日間トライアルから始めてみてください」と伝えています。実際に自分のプロジェクトで動かしてみると、「あ、こういうバグって見落としがちだったんだ」という気づきがあると思いますよ。
室谷次回はCursor CLIとCloud Agentsをテーマに解説していく予定です。引き続きよろしくお願いします。
