はじめに
この記事は、コードレビューに関するTipsを投稿しよう！ by CodeRabbit Advent Calendar 2025の15日目の記事です
GitHub Copilot、Bitbucket の Rovo Dev、そして本カレンダー主催の CodeRabbit など、
巷には様々なAIコードレビューツールがあります。
これらは、PRレビューを補助する手段として、実務でも現実的な選択肢になってきました。
ただ、実務で使おうとするとこんな悩みはないでしょうか。
- 従量課金や利用上限が気になる
- チーム全体で使うとコストが読めない
- どれがいいのかよくわからない
便利なのはわかるけど、わざわざ導入するほど効果があるのかなと思っている人も多いのではないでしょうか。
かくいう私もその一人で
業務で Cursor を使っている私は、AIコーディングの力を実感している一方で、AIコードレビューは上記の理由により敬遠していました。
CursorにもAIコードレビュー機能があればなぁと思っていた時に、ふと閃きました。
「MCPを使えば、CursorでAIコードレビューツールを作れるんじゃね？」
できるだけお金をかけずに、Cursorだけで完結させることができるのではないか。
そう思い、Cursor × MCP を使ってAIコードレビューツールを自作してみることにしました。
なぜ「Cursor × Bitbucket MCP」なのか？
GitHubならGitHub Copilotを使えば簡単にAIコードレビューを実現できますが、Bitbucketだと少々手間がかかります。
Cursorだけでなるべくコストを掛けずに同様のことを実現するために、Bitbucket MCPを活用してAIコードレビューを実現することにしました。
これは単にコードをコピペしてAIに投げるのとはわけが違います。MCPを使うことで、以下の情報を複合的に判断させることができます。
- PRの差分（Diff）
- PRのタイトルと説明文（Description）
- リポジトリ内の関連ファイル
これらを組み合わせることで、「文脈」を踏まえたレビューが可能になります。
準備1： Bitbucket MCPを導入する
まずは Cursor が Bitbucket の情報を参照できるようにします。
Bitbucket の公式 MCP サーバーは存在しないため、今回は非公式の MatanYemini/bitbucket-mcp を使用しました。
設定は簡単で、Cursor の MCP 設定に Bitbucket MCP 用の設定を追加するだけです。
{
"mcpServers": {
"bitbucket": {
"command": "npx",
"env": {
"BITBUCKET_URL": "https://api.bitbucket.org/2.0",
"BITBUCKET_WORKSPACE": "Work Space ID...",
"BITBUCKET_USERNAME": "Email...",
"BITBUCKET_PASSWORD": "Password or API Token..."
},
"args": ["-y", "bitbucket-mcp@latest"]
}
}
}
準備2: レビュー用の Cursor ルールを作成する
なくてもいい感じにレビューしてくれますが、なるべくブレを少なくしたいのでルールはあったほうがいいです。
Cursor に協力してもらえればすぐに作成できます。
参考までに、今回の検証用に作成した ToDo アプリ用のPRレビュールールです。
PRレビュー用 Cursor ルールのサンプルを開く
---
description: プルリクエストレビュー、pull request review、PRレビューの実行手順。プルリクエストのレビューを依頼された際に適用される。
alwaysApply: false
---
# プルリクエストレビュー プロジェクトルール
## プルリクエストレビューの実行手順
プルリクエストのレビューを依頼された場合、以下の手順を厳密に実行してください。
### ステップ1: プルリクエストURLの取得
1. ユーザーからプルリクエストのURLを取得する
2. **Bitbucket MCPサーバーを使用してプルリクエスト情報を取得する**:
- `mcp_bitbucket_getPullRequest` ツールを使用してプルリクエストの詳細情報を取得する
- 取得した情報から、リポジトリ名、マージ先ブランチ、変更されたファイルなどを確認する
### ステップ2: リポジトリの確認
1. 現在のGitリポジトリの情報を取得する：
```bash
git remote get-url origin
```
または
```bash
git config --get remote.origin.url
```
2. **Bitbucket MCPサーバーから取得したプルリクエスト情報と比較する**:
- `mcp_bitbucket_getPullRequest` ツールで取得した情報からリポジトリ名（`repository.name` または `repository.full_name`）を確認する
- 現在のGitリポジトリのURLとプルリクエストのリポジトリ情報を比較する
3. **リポジトリが異なる場合**：
- 警告メッセージを表示：「エラー: 現在表示しているリポジトリとレビュー対象のリポジトリが異なります。リポジトリを合わせてください。」
- **レビューを中止する**（以降のステップは実行しない）
4. **リポジトリが同じ場合**：ステップ3に進む
### ステップ3: ブランチの確認
1. 現在のGitブランチを取得する：
```bash
git branch --show-current
```
2. **Bitbucket MCPサーバーを使用してプルリクエストのマージ先ブランチ（target branch）を取得する**:
- `mcp_bitbucket_getPullRequest` ツールで取得した情報から `destination.branch.name` を確認する
3. **ブランチが異なる場合**：
- 警告メッセージを表示：「エラー: 現在表示しているブランチとレビュー対象のマージ先ブランチが異なります。ブランチを合わせてください。」
- **レビューを中止する**（以降のステップは実行しない）
4. **ブランチが同じ場合**：ステップ4に進む
### ステップ4: コードレビューの実施
熟練のプログラマーとして、以下の観点から徹底的にコードレビューを実施してください。
**注意**: コードレビューを実施する際は、Bitbucket MCPサーバーから取得した以下の情報を活用すること：
- 変更されたファイル一覧（`mcp_bitbucket_getPullRequest` または `mcp_bitbucket_getPullRequestDiff` から取得）
- コミット履歴（`mcp_bitbucket_getPullRequestCommits` から取得）
- プルリクエストの説明やタイトル（変更の意図を理解するため）
**レビューの手順**:
1. `mcp_bitbucket_getPullRequestDiff` を使用してプルリクエストの差分を取得する
2. 変更された各ファイルについて、`read_file` ツールを使用してファイル内容を確認する
3. 差分とファイル内容を参照しながら、以下の4.1〜4.6の各項目をチェックする
#### 4.1 Angularルールの確認
以下のAngularのベストプラクティスに準拠していることを確認：
- **コンポーネント**:
- コンポーネントのサイズが適切であること（300行以下を推奨）
- テンプレートに複雑なロジックがないこと
- ライフサイクルフック（`ngOnInit`、`ngOnDestroy`など）が適切に使用されていること
- Change Detection戦略が適切であること
- **サービス**:
- サービスの責任範囲が明確であること
- 依存性注入が適切に使用されていること
- `providedIn: 'root'` が適切に使用されていること
- **テンプレート**:
- 可能であれば `@if`、`@for`、`@switch` を使用（Angular 17+）
- Observableの購読には `async` パイプを使用すること
- アクセシビリティが考慮されていること
- **フォーム**:
- 可能な限りReactive Formsを使用すること
- バリデーションが適切に実装されていること
- **ルーティング**:
- 新しいルートが適切に設定されていること
- ルートガードが適切に使用されていること（必要に応じて）
#### 4.2 バグの確認
- エラーハンドリングが適切に実装されていること
- null/undefinedチェックが適切に行われていること
- 型安全性が確保されていること（`any`型の使用が最小限であること）
- エッジケースが適切に処理されていること
- ロジックエラーがないこと
#### 4.3 メモリリークの確認
- Subscriptionが適切に解除されていること（`ngOnDestroy`で`unsubscribe()`を呼び出していること）
- イベントリスナーが適切に削除されていること
- タイマー（`setInterval`、`setTimeout`）が適切にクリアされていること
- Observableの購読が適切に管理されていること
#### 4.4 セキュリティの確認
- XSS対策が適切に行われていること（ユーザー入力のサニタイズ）
- `innerHTML` の使用が適切に制限されていること
- 認証・認可チェックが適切に実装されていること
- APIキーやトークンがコードにハードコードされていないこと
- 環境変数が適切に使用されていること
#### 4.5 コードの重複の確認
- DRY原則に従っていること
- 既存のユーティリティやサービスを活用していること
- 重複コードがないこと
#### 4.6 プルリクエストへの変更禁止
- **重要**: プルリクエストに対してコメントの書き込みや変更を加えないこと
- レビュー結果はローカルでまとめて表示するのみ
### ステップ5: レビュー結果のまとめ
以下の形式でレビュー結果をまとめて表示してください：
```
# プルリクエストレビュー結果
## 基本情報
- プルリクエストURL: [URL]
- リポジトリ: [リポジトリ名]
- マージ先ブランチ: [ブランチ名]
- レビュー日時: [日時]
## 確認結果
### ✅ Angularルール
[結果: 準拠 / 要修正]
[詳細]
### ✅ バグ
[結果: 問題なし / 問題あり]
[詳細]
### ✅ メモリリーク
[結果: 問題なし / 問題あり]
[詳細]
### ✅ セキュリティ
[結果: 問題なし / 問題あり]
[詳細]
### ✅ コードの重複
[結果: 問題なし / 問題あり]
[詳細]
## 総合評価
[総合的な評価と推奨事項]
```
## レビュー時の注意事項
1. **建設的なフィードバック**: 批判ではなく、改善提案の形でフィードバックを提供する
2. **優先順位の明確化**:
- **必須（Must）**: マージ前に修正が必要な項目
- **推奨（Should）**: 可能であれば修正すべき項目
- **任意（Nice to have）**: 将来的に改善できる項目
3. **一貫性の維持**: 既存のコードベースとの一貫性を確認する
## 使用するツール
### Bitbucket MCPサーバー（必須）
プルリクエストの情報取得には、**Bitbucket MCPサーバーを必ず使用する**こと：
- **`mcp_bitbucket_getPullRequest`**: プルリクエストの詳細情報を取得
- パラメータ: `workspace`, `repo_slug`, `pull_request_id`
- 取得できる情報:
- リポジトリ情報
- マージ先ブランチ（`destination.branch.name`）
- ソースブランチ（`source.branch.name`）
- 変更されたファイル一覧
- プルリクエストの説明やタイトル
- コミット情報
- **`mcp_bitbucket_getPullRequestDiff`**: プルリクエストの差分を取得
- 変更されたファイルの詳細な差分を確認する際に使用
- コードレビュー時に変更内容を正確に把握するために推奨
- **`mcp_bitbucket_getPullRequestCommits`**: コミット履歴を取得
- コミットメッセージから変更の意図を理解する際に使用
- 複数のコミットがある場合の確認に推奨
- **`mcp_bitbucket_getRepository`**: リポジトリ情報を取得（必要に応じて）
- リポジトリの詳細情報が必要な場合に使用
### その他のツール
- **Gitコマンド**: 現在のリポジトリとブランチ情報の取得
- `git remote get-url origin`: リモートリポジトリURLの取得
- `git branch --show-current`: 現在のブランチ名の取得
- **コードベース検索**: コードの重複や既存パターンの確認
PRレビュー用ルールのポイント
- PRの情報を取得する際に Bitbucket MCP を使うように明記する
- サンプルプログラムは Angular を使っているため、Angular ならではのレビュー観点があると良い
- レビューではローカルのコードを使用するため、PRのマージ先と同じブランチになっていることを確認する
サンプルPR
今回使用するサンプルPRです。
ちなみにこのPRは trackById の引数の順番が間違っています。
正しくは index が第1引数になります。
誤： trackById(todo: Todo, index: number)
正： trackById(index: number, todo: Todo)
実践
それでは実際にレビューしてみましょう。
Cursor を Agent モードにして以下のようにお願いしてみます。
このプルリクをレビューしてください
https://bitbucket.org/xxxxxxxxx
モデルは Gemini 3 Pro と GPT-5.1 Codex Max を有効にしています。
結果
ちゃんとバグを検知できていますね。
修正方法も詳しく書かれています。
さらには Angular 独自の観点やセキュリティ面でもレビューしてくれています。
また、特に指示せずとも他のローカルコードから学習して独自の仕様を考慮したレビューをしてくれます。
AIコードレビューツールを自作できた！ けど...
Cursor だけでAIコードレビューを実現できましたが、実際に運用してみると課題も見えてきました。
AIコードレビューツールを代表してCodeRabbitと性能を比較してみましょう。
自作コードレビューツール vs CodeRabbit
| 特徴 | Cursor × MCP | CodeRabbit |
|---|---|---|
| コスト | 追加料金は必要なし | 追加料金が必要 |
| 対話性 | 高 (その場で修正・相談可) | 高 (その場で修正・相談可) |
| 文脈理解 | 高 | 高 |
| 手軽さ | 低 (ブランチ切替・手動実行が必要) | 高 (寝てても勝手に終わる) |
| 強制力 | 低 (開発者の自主性に依存) | 高 (PRを強制チェック) |
| ローカルレビュー | 可能 | 可能（VSCodeの拡張機能） |
自作ツールの課題はやはり手動であるという点です。
PRのURLをコピーして貼り付けるだけですが、それでもブランチの切り替えなど、細かい作業が発生します。
これをPRレビューのたびに行うのは面倒です。
対してCodeRabbitはPRを出したら自動でレビューしてくれます。
これは開発の規模が大きくなるほど恩恵は大きくなります。
ならば「自作ツールならではの"強み"はないのか？」と考えに考えた結果、
「PRを出す前にセルフレビューができるではないか！」
とCursorならではの強みを思いつきました。
がしかし、どうやらCodeRabbitにはVSCode用の拡張機能があるらしく、ローカルでコミットすると変更内容を自動でレビューしてくれるそうです。
......
結論： CodeRabbitは素晴らしい
Cursor と MCP を使えば、AIコードレビュー自体は実現できました。
ただし、毎回ブランチを切り替えたり、Cursor に明示的に指示を出したりと、
運用面ではどうしても手間が残ります。
その点、CodeRabbit は、PR 作成時に自動で動くという意味での「強制力」と「自動化」の完成度が高いと感じました。
さらに、CodeRabbit for VSCode を使えばローカルでのレビューも可能です
自作すると、仕組みのメンテナンスや運用ルールの調整も含めて考える必要があります。
そうした運用面まで考慮すると、AIコードレビューツールに投資した方が、結果的にコストを抑えられるのかもしれません。