コードを書き進めていると、行末にグレーの文字がにじむ。次の行、その次の行、さらにテストコードまで。Cursorの提案は止まらない。補完を読むたびに思考が途切れ、確認だけで午前中が終わる。提案が多いのは賢い証拠だが、賢すぎて疲れることがある。
この感覚は多くの開発者が抱えている。CursorはVS CodeをベースにしたAIコードエディタで、Tab補完やチャット、エージェント機能によって開発速度を大幅に上げる。しかし、その提案量の多さが裏目に出て、レビュー負荷が増し、結果的に品質確認が追いつかなくなるケースが少なくない。
実際、あるチームのアンケートでは「AI生成されたコードに対するチェックの目が緩くなっている場面もあり、結果としてレビューに費やす時間が増えている」という声が上がっている。また、別の開発者は「修正を任せるよりも、調査や修正方針の検討で使うことが多い」と使い方を限定している。
Cursorの提案をすべて受け入れようとすると、確かに手戻りは増える。しかし、公式が提供するレビュー機能や設定を適切に使えば、負担は大幅に軽減できる。
Cursorの提案が多すぎてレビュー負荷が増える理由
Cursorの提案が多いと感じるのには、いくつかの構造的な理由がある。
提案の種類と発生タイミング
Cursorは、大きく分けて三つの方法で提案を行う。
- Tab補完：コードを入力中に、次に書くべき行をリアルタイムで予測して表示する。数文字入力するたびにグレーのテキストが現れ、Tabキーで受け入れられる。この補完は非常に高頻度で、単純な変数名から関数全体まで幅広い。
- チャット機能：エディタ内でAIと対話し、コードの説明や修正を依頼できる。質問の仕方によっては、大量のコードブロックが返ってくる。
- エージェント機能：「〇〇を実装して」と自然言語で指示すると、AIが自律的にコードを生成・修正し、ファイル作成やターミナルコマンドの実行まで行う。一度の指示で複数ファイルにまたがる変更が発生し、その差分すべてをレビューする必要が出てくる。
これらの提案が同時に、あるいは連続して発生するため、エディタ上で常に何らかの提案と向き合うことになる。特にエージェント機能を使うと、変更範囲が広がり、レビューすべきコード量が一気に増える。
提案の質とノイズ
提案のすべてが有用なわけではない。ある調査では「表面的なスタイル指摘は不要」という意見があり、AIがフォーマットや命名の指摘を大量に出してくることが、ノイズとして認識されている。また、生成されたコードが見た目は正しくても、細かい条件漏れやエッジケースを外していることもある。
このようなノイズの多い提案をすべて真面目にレビューしようとすると、本来集中すべきロジックやセキュリティの確認に時間が割けなくなる。結果として、重要な問題を見落とすリスクが高まる。
公式ドキュメントが示すレビュー機能の位置づけ
Cursorの公式ドキュメントでは、AIが生成したコードをそのまま受け入れるのではなく、レビュー工程を挟むことが推奨されている。具体的には、Agent ReviewとBugbotという二つのレビュー機能が用意されており、これらを適切に使うことで、レビュー負荷を管理できるとされている。
Agent ReviewとBugbotの使い分けに関する情報は、公式ドキュメントやCursorブログで確認できる。
小さく使うタスクの切り方
レビュー負荷を減らす最も基本的な方法は、一度に扱うタスクのサイズを小さくすることだ。
エージェントへの指示を細分化する
エージェント機能は強力だが、「この機能を全部実装して」と大きな指示を出すと、当然ながら大量のコードが生成される。代わりに、以下のようにタスクを分割する。
- データ取得部分だけを先に実装させる
- UIコンポーネントだけを生成させる
- テストコードだけを書かせる
こうすることで、一度にレビューするコード量が減り、各ステップで品質を確認しやすくなる。
チャットでの質問を調査目的に絞る
ある開発者が「修正を任せるよりも、調査や修正方針の検討で使うことが多い」と述べているように、チャット機能はコード生成よりも、既存コードの理解や調査に使うほうが、レビュー負荷を抑えやすい。
例えば、「この関数が呼ばれている場所をすべて教えて」「このエラーの原因として考えられることを列挙して」といった質問は、提案される情報量が限定的で、確認も容易だ。
Tab補完の受け入れ基準を決める
Tab補完は特に頻度が高いため、すべてを検討していると思考が中断される。事前に「変数名や単純な代入のみTabで受け入れ、ロジックを含む行は必ず手動で確認する」といったルールを決めておくと、判断が速くなる。
採用しない提案の見分け方
すべての提案を受け入れる必要はない。むしろ、積極的に「採用しない」判断をすることが、レビュー負荷の軽減につながる。
レビュー観点を事前に固定する
CursorのAgent ReviewやBugbotを使う際に、レビュー観点を指定することで、ノイズの多い指摘を減らせる。
“`
以下の観点でレビューしてください。
- 本番で起きそうなバグ
- 認証や権限の漏れ
- nullやundefinedの扱い
- 失敗時のエラーハンドリング
- テスト不足
表面的なスタイル指摘は不要です。
“`
観点を絞ることで、AIがフォーマットや命名の指摘にリソースを割くことを防ぎ、本当に重要な問題に集中できる。
リントやフォーマッターに任せる領域を明確にする
コードスタイルやフォーマットの指摘は、ESLintやPrettierなどのツールに任せるべきだ。Cursorの提案のうち、これらのツールで自動修正できるものは、AIに指摘させる必要がない。
プロジェクトにあらかじめリントルールを導入し、CIでチェックする体制を整えておけば、Cursorが同様の指摘をしてきても無視できる。
コンテキストが不足している提案を見抜く
Cursorはプロジェクト全体のコードベースを理解する機能（Codebase Answers）を持つが、それでも文脈を完全には把握できない。特に、社内ライブラリや特殊なビジネスロジックを含むコードでは、一見正しそうな提案が実は要件を満たしていないことがある。
このような提案は、以下のようなサインで見分けられる。
- 提案されたコードが、プロジェクトのディレクトリ構成や命名規則から外れている
- 既存の類似実装と明らかに異なるアプローチを取っている
- コメントやドキュメントに書かれていない前提に依存している
少しでも違和感があれば、その提案は一旦保留し、手動で確認するか、チャットで追加の質問をする。
レビュー観点を固定化して負荷を減らす
レビュー観点を固定化することで、毎回何を確認すべきか迷わなくなり、判断速度が上がる。Cursorの機能を使いながら、この固定化を実現する方法を紹介する。
Agent Reviewの活用
Cursorには、ローカルでの変更をAIにレビューさせるAgent Review機能がある。変更後に「Review」から「Find Issues」を実行すると、現在の差分に対してAIが問題点を指摘してくれる。
また、Source Controlからmainブランチとの差分に対してAgent Reviewをかけることも可能だ。複数ファイルにまたがる変更の場合は、`@Branch`を使ってブランチ全体を文脈として渡すと、より的確なレビューが得られる。
“`
@Branch このブランチの変更をレビューしてください。 バグ、セキュリティ、抜けているテストを優先して見てください。
“`
Bugbotの導入
チーム開発でPRを運用しているなら、Bugbotの導入を検討したい。Bugbotは、PRのdiffを分析し、バグやセキュリティ、コード品質の問題を自動でコメントする機能だ。GitHubやGitLabと連携し、PR更新時に自動実行することもできる。
Bugbotは、過去のPRコメントや議論を文脈として読み取るため、重複した指摘を避け、人間のレビュアーがまだ気づいていない問題に集中できる。公式ドキュメントでは、Bugbotは「PRに潜むバグを見つけることに重点を置いている」と説明されている。
`.cursor/BUGBOT.md` でチームルールを共有する
Bugbotの動作は、プロジェクトルートの `.cursor/BUGBOT.md` ファイルでカスタマイズできる。このファイルに、チーム固有のレビュー観点や無視すべき指摘を記述しておくことで、全員が同じ基準でAIレビューを活用できる。
例えば、次のような内容を記述する。
“`
- パフォーマンスに関する指摘は、実際の計測データがない限り行わない
- テストコードのカバレッジは80%を目標とするが、UIコンポーネントのスナップショットテストは必須としない
- 特定のライブラリ（例：lodash）の使用は非推奨
“`
このように、チームのコンテキストをBugbotに教えることで、的外れな指摘を減らし、レビュー負荷をさらに下げられる。
導入効果を測る指標と判断のタイミング
Cursorを導入した後、レビュー負荷が本当に増えたのか、それとも許容範囲なのかを判断するには、客観的な指標が必要だ。
レビュー時間の計測
最も直接的な指標は、PRあたりのレビュー時間だ。Cursor導入前後で、以下のようなデータを比較する。
- PRの平均レビュー時間
- レビューコメントの数（人間によるものとAIによるもの）
- 指摘された問題の深刻度（バグ、セキュリティ、スタイルなど）
もし、AIによるスタイル指摘が増え、人間のレビュー時間が減っていないなら、観点の絞り込みが不十分かもしれない。
手戻り率の追跡
AIが生成したコードが原因で、後工程で手戻りが発生する割合を追跡する。具体的には、以下のようなケースをカウントする。
- AI提案を受け入れたコードが、後のテストで失敗する
- AI提案を受け入れたコードが、本番環境でバグを引き起こす
- AI提案を受け入れたコードが、他の開発者によって大幅に修正される
この手戻り率が高い場合、レビュー工程で見落としが発生している可能性が高い。
開発速度とのバランス
Cursorの目的は開発速度の向上だ。レビュー負荷が増えても、全体の開発速度が十分に向上していれば、許容できる場合もある。
以下のような指標を総合的に見る必要がある。
- 機能あたりのリードタイム
- スプリントあたりの完了ストーリーポイント
- 開発者の体感速度（アンケートなど）
レビュー負荷が増えたと感じても、実際には開発速度が大幅に上がっているなら、その負荷は必要な投資と捉えられる。
判断のタイミング
Cursorの利用を継続するか、使い方を見直すかの判断は、少なくとも2〜4週間のデータを取ってから行うべきだ。
特に、以下のような兆候があれば、使い方の見直しを検討する。
- レビュー時間が導入前より20%以上増加した
- 手戻り率が導入前より上昇した
- 開発者が「提案が多すぎて集中できない」と頻繁に訴える
逆に、開発速度が20%以上向上し、手戻り率が横ばいか減少していれば、現在の使い方を継続してよい。
Cursorの提案量に合わせた設定の調整
Cursorの設定を調整することで、提案の頻度や種類をコントロールできる。
プライバシーモードとデータの取り扱い
Cursorの設定でプライバシーモードを有効にすると、コードデータがCursor社やモデルプロバイダーに保存されなくなる。これはレビュー負荷に直接関係しないが、機密性の高いプロジェクトでは、提案の受け入れ判断に心理的な余裕が生まれる。
[料金プランとプライバシー設定](https://cursor.com/ja/pricing)の詳細は公式ページで確認できる。
利用上限とプラン選択
Cursorの料金プランは、利用量に応じてHobby、Pro+、Ultra、Teams、企業プランがある。Pro+プラン以上では、エージェント機能やBugbotが利用できるが、利用量が上限に達すると、提案の速度が制限されたり、追加料金が発生したりする。
レビュー負荷が増える一因として、利用上限を気にせず大量の提案を生成させてしまうことがある。自分の利用量を定期的に確認し、必要に応じてプランを見直すことも、間接的に負荷管理につながる。
モデルの選択
Cursorでは、使用するAIモデルを選択できる。高性能なモデルほど精度の高い提案をするが、その分、提案の量も多くなりがちだ。また、モデルによって料金の消費量も異なる。
もし提案の多さに圧倒されているなら、あえて少し性能の低いモデルを選ぶことで、提案が控えめになり、自分で考える余地が増えることもある。
チームでの運用ルールを作る
Cursorをチームで使う場合、個人の設定任せにすると、レビュー負荷にばらつきが出る。チームとしての運用ルールを決めておくことが重要だ。
レビュー観点の共有
`.cursor/BUGBOT.md` やプロジェクトのCONTRIBUTING.mdに、AIが生成したコードのレビュー観点を明記する。例えば、以下のような項目を入れる。
- セキュリティチェックリスト
- パフォーマンス基準
- テスト要件
- 禁止するライブラリやパターン
これにより、誰がレビューしても同じ基準で判断でき、AIの指摘に振り回されにくくなる。
提案の受け入れフロー
AIの提案を受け入れる際のフローを統一する。例えば、以下のようなステップを決める。
1. AI提案は必ずローカルで動作確認する
2. ロジックに関わる提案は、必ず別の開発者に目を通してもらう
3. テストコードの提案は、カバレッジが不足していないか確認する
このフローを守ることで、提案の質にばらつきがあっても、一定の品質を保てる。
定期的な振り返り
スプリントの振り返りなどで、Cursorの使用感やレビュー負荷について話し合う時間を設ける。具体的には、以下のような質問を投げかける。
- 今週、AIの提案で助かった場面は？
- 逆に、ノイズに感じた提案は？
- レビューに時間がかかりすぎたPRはあったか？
この振り返りを通じて、チームのルールを継続的に改善していく。
最後に、Cursorが自分の開発スタイルに合うかどうかを判断するための基準をまとめる。
向いている使い方
- 小規模なタスクを積み重ねる開発スタイル
- 調査やコードリーディングに多くの時間を割いている
- テストコードの作成を効率化したい
- チームでレビュー観点を共有し、AIの指摘を取捨選択できる体制がある
向いていない使い方
- 大規模な機能を一度にAIに任せたい
- 提案をすべて受け入れることに抵抗がない（結果的に品質が下がる）
- コードスタイルやフォーマットの指摘をAIに頼りたい（リントで十分）
- 機密性の高いコードを扱い、AIへのデータ送信を最小限にしたい
判断のためのチェックポイント
Cursorの導入を検討しているなら、以下の点を確認してほしい。
- まずはHobbyプランで試し、Tab補完とチャット機能の使用感を確かめる
- エージェント機能を使う場合は、タスクを細分化してレビュー負荷を測る
- Bugbotを導入するなら、`.cursor/BUGBOT.md` でチームルールを定義する
- 2週間程度使ってみて、レビュー時間や手戻り率を導入前と比較する
もしレビュー負荷が許容範囲を超えるなら、設定の調整や使い方の見直しで対応できる。それでも改善しない場合は、競合ツールの検討も選択肢になる。
Cursorは強力なツールだが、その提案の多さに振り回されると、本来の目的である開発速度の向上が損なわれる。まずは、今日から一つだけ試してみてほしい。エージェントに指示を出す前に、タスクを半分のサイズに分割することだ。それだけで、レビューすべきコード量が減り、確認の集中力が続くようになるはずだ。
コメント