挨拶
こんにちは！最近メンバーのアウトプットが早すぎて、気づいたらPRレビューばかりやっています。たろう眼鏡です。
delyではClaude CodeのMaxプランが全エンジニアに導入されており、エンジニア全員で試行錯誤しながら日々のコーディングを効率化しています。
前回の記事ではJunieを信じると言いましたが、もう完全に諦めておりClaude Codeにオールインする所存です。
今回はClaude CodeのCustom slash commandsとGithub MCPサーバーを通じてヒトが行うPRレビューを効率化したのでその紹介をします！
何ができるの？
簡単にいうと、GitHub PRのURLを入力するだけで、差分を1ブロックずつ対話的にAIと協働しながらレビューを進行して、最終的にGitHub上に自動でインラインコメントを投稿してくれるというCustom slash commandsです。
もう手動でブラウザ開いて、ファイル見て、コメント書いて...という作業から解放されます✨
対話的なコードレビューを取り入れることで、AIによる指摘を参考にしつつ、自身の考えも柔軟に織り交ぜることができます。その結果、AI特有の無機質で一方通行なレビューを避けることができ、より実践的で納得感のあるレビュー体験が得られます。
また、私自身、レビュー中にSlackの通知が来たり、単純に集中力が途切れたりして中断したまま忘れてしまうことがよくあります。対話式であればリズムよくレビューを進めやすく、その点でも非常に有効だと感じています。
具体的な機能
- ✅ GitHub MCP経由でPRの差分を取得・解析
- ✅ 各変更ブロックごとに問題点を指摘
- ✅ レビューコメント案を自動生成
- ✅ レビューコメント案が気に入らなければ手動でカスタマイズ
- ✅ must/imo/ask/nits/suggestionの5段階でラベル分け
- ✅ GitHub MCP経由でインラインコメント自動投稿
事前準備
Github MCPをClaude Codeに設定して、使えるようにしておいてください。10分ぐらいでサクッと導入できるので、MCPの設定をしたことがない人もこの機会にトライしてみてください。
実際の流れ
今回作成したCustom slash commandsを実際に使って、PRのレビューを進行してみます。
👇️2ファイルの差分があるPRを用意しました
今回は動作確認のため敢えて不要な変更を追加し、PRとして投げています。
（findでレコードがなかったらその時点でActiveRecord::RecordNotFoundの例外が出るのでこの追記したロジックに到達しません）
1. /pr-reviewコマンド
/pr-reviewコマンドを叩く。
2. PRのURLを入力し、各種操作に許可を出す
PRのURLを入力することを求められるのでURLを入力します。
👇️
GitHub MCP経由で、指定したPRの詳細情報を取得するコマンドの許可を求められるので許可します。
👇️
GitHub MCP経由で、PRの差分を取得する許可をします。
3. AIがコードの差分&概要欄からPRの目的を要約する
AIがPRの差分や概要欄から今回のPRの目的を推測&要約します。
PRの目的をこのパートで擦り合わせることで、この後のレビューの精度を上げていきます。
もし、AIが提案した目的が間違っていれば、ここで修正案を投げることもできます。
今回は「OK」で応答します。
4. 各ブロックを対話的にレビュー
1つ目のブロックはAIの提案を受け入れてみる
各ブロックごとにレビューを進行します。
今回AIは、かなりマトモなレビュー案を提案してきているので従おうと思います。
👇️
must・imo・ask・nits・suggestionのいずれかのラベル名入力すれば、AIが提案したコメントをそのままインラインコメントとして作成します。その際選択したラベル名がバッチとしてコメントに付きます。
今回はmustを入力します。
skipを入力するとコメントは作成せず、次のブロックに進みます。
2つ目のブロックは自身の案を投げてみる
2つ目のレビューもマトモなので、本来はこのまま使いたいですが、今回はAIに従わないバージョンの挙動を紹介したいので、敢えて反抗して自身の案を投げてみたいと思います。
👇️
editを入力します。
👇️
修正内容の入力を求められるので「個人的にunlessは読みづらいのでif文で書くのが好きです」と入力してみます。
👇️
修正内容を入力後、ラベルの選択を求められます。
完全に自分の意見でしかないコメントなのでimoを入力します。
5. 最後にGitHubに自動投稿
これらのコメントをGitHub PRに追加しますか？（Y/N）と聞かれるので「Y」を入力します。
👇️
GitHub MCP経由で、PRのレビューを開始することを許可します。
👇️
GitHub MCP経由で、コメントを投稿することを許可していきます。
👇️
GitHub MCP経由で、レビューを終了することを許可します。
👇️
無事レビューコメントがGithubのPRにインラインコメントとして投稿されました。
選択したmust・imoのラベルがそれぞれ付いています。
これでコマンドは終了です。
こだわりポイント
GitHub MCPを用いることでインラインコメントを実現
インラインコメントはコマンドラインでやろうとすると意外と難しいですが、MCPを用いるとお手軽にインラインコメントを実現できます。
またエージェントからは直接APIを叩かないので、セキュアかつコンテキストの節約にも繋がります。
レビューラベルシステム
レビューラベルを強制的に選定させる仕組みも気に入っています。
| ラベル | 意味 | 色 | バッジ |
|---|---|---|---|
| must | 必須修正項目 | red | https://img.shields.io/badge/review-must-red.svg |
| imo | 個人的意見 | orange | https://img.shields.io/badge/review-imo-orange.svg |
| ask | 質問 | blue | https://img.shields.io/badge/review-ask-blue.svg |
| nits | 細かい指摘 | green | https://img.shields.io/badge/review-nits-green.svg |
| suggestion | 提案 | blue | https://img.shields.io/badge/review-suggestion-blue.svg |
コメントの緊急度が一目でわかるので、PR作成者にとっても親切だと思います。
使ってみての感想
当初はAIレビューに懐疑的でしたが、実際に試してみると、静的な観点からの網羅的なチェックや、レビュー時の漏れ防止に非常に役立つと実感しました。人間の感性や判断力と、AIの網羅性がうまく噛み合えば、より精度の高いコードレビューが実現できそうです。
AIの得意なところ
- 見落としがちな細かい問題を指摘
- コーディング規約やフレームワーク仕様の知識
- 一貫したレビュー基準の維持
人間が判断すべきところ
- コメントの緊急度（must/imo/nitsなど）
- プロジェクト固有のルールや方針
- 最終的な投稿判断
このバランスが取れているのが、このCustom slash commandsの一番の価値だと思います。
まとめ
Claude Codeの柔軟性を活かして、実用的なPRレビューアシスタントを作ることができました！
個人的には、レビュー時間の短縮もさることながら、レビューの品質向上に一番価値を感じています。AIが客観的な視点で問題点を指摘してくれるので、見落としが減りますし、一貫したレビュー基準を保てるようになりました。
また、プロンプトを改善することでレビューの着眼点を変えることも容易で、例えばパフォーマンスを厳しく見るなど、レビューの精度をカスタマイズできると思うので伸びしろは無限です。
もしPRレビューに時間を取られて困っている方がいらっしゃいましたら、ぜひ試してみてください！きっとレビュー業務が楽しくなると思います🚀
Custom slash commandsのソースコードを紹介
Claude Codeユーザーの方は、以下のコードを.claude/commands/pr-review.mdに保存して/pr-reviewコマンドで使えます！
⚠️私の環境では安定的に動作していますが、もし不具合などがあったらプロンプトをカスタマイズしてみてください⚠️
実装コード（長いので折りたたみ）
---
name: pr-review
description: GitHub PRを1ブロックずつ対話的にレビューします
---
# GitHub PRレビューアシスタント
あなたはGitHub PRレビューアシスタントとして、以下のプロセスを実行してください：
## ステップ1: PR URLの入力要求
まず、ユーザーに以下のメッセージを表示してPR URLの入力を求めてください：
```
GitHub PRレビューを開始します。
レビューしたいPRのURLを入力してください。
例: https://github.com/owner/repo/pull/123
```
## ステップ2: PR情報の取得と分析
URLを受け取ったら：
1. URLからowner, repo, pullNumberを抽出
2. MCP `mcp__github__get_pull_request` でPR情報を取得
3. MCP `mcp__github__get_pull_request_diff` で差分を取得
4. PR概要、コミットメッセージ、差分内容からPRの意図を要約
## ステップ3: 目的の確認
要約した目的を以下の形式でユーザーに提示：
```
【PRの目的】
[要約した内容]
この理解で正しいですか？修正が必要な場合は修正内容を教えてください。
正しい場合は「OK」と入力してください。
```
## ステップ4: ブロック単位のレビュー
差分を解析し、各ファイルの各変更ブロック（hunk）について：
1. ブロックを表示（ファイル名、行番号、変更内容）
2. 目的に照らしてレビューコメントを提供
3. 必要に応じてレビューコメント案を作成
4. ユーザーに確認を求める：
```
このブロックのレビュー結果：[問題なし/要レビューコメント]
[問題点の説明]
以下のレビューコメント案を作成しました：
「[作成者向けのレビューコメント案]」
コメントのラベル：
- must: 必須修正項目 
- imo: 個人的意見 
- ask: 質問 
- nits: 細かい指摘 
- suggestion: 提案 
このコメントで良いですか？
次のいずれかを入力してください：
- must / imo / ask / nits / suggestion → 該当ラベルでレビューに追加
- skip → コメントなしで次へ
- edit → コメント内容を修正
入力:
```
5. コメント修正の場合：
```
修正内容を入力してください（複数行可、終了は空行）：
```
ユーザーが修正内容を入力後：
```
ラベルを選択してください：
must / imo / ask / nits / suggestion
入力:
```
6. ユーザーの回答を待って次のブロックへ
## ステップ5: レビュー完了
すべてのブロックをレビューしたら：
```
レビュー終了です。お疲れさまでした！
レビュー結果サマリー：
- 総ブロック数: [数]
- 問題なし: [数]
- レビューコメント追加: [数]
レビューコメント一覧：
[ファイル名:行番号]  コメント内容
[ファイル名:行番号]  コメント内容
...
これらのコメントをGitHub PRに追加しますか？（Y/N）
```
## ステップ6: GitHub PRへのインラインコメント追加
ユーザーがYと回答した場合、GitHub MCP APIを使用して各コメントを該当するソースコードの行に直接追加する：
**重要な制約**：
- 必ずインラインコメントを使用する。サマリーコメントは一切追加しない
- エラーが発生してもインラインコメントの追加を断念せず、必ず成功するまで継続する
- GitHub MCP Review APIのみを使用してインラインコメントを追加する
- 各ステップを必ず順番に実行すること
- 特に、レビューコメントの投稿前には必ず最終確認を行うこと
### 手順：
1. PR URLからowner, repo, pullNumberを抽出（既に取得済み）
2. MCP `mcp__github__get_pull_request` でPR詳細情報（最新コミットSHA含む）を取得
3. MCP API経由でレビューを作成し、コメントを追加
### 実装の流れ：
1. MCP `mcp__github__create_pending_pull_request_review` でレビューを作成
2. 各コメントに対して MCP `mcp__github__add_comment_to_pending_review` でコメントを追加
3. 最後に MCP `mcp__github__submit_pending_pull_request_review` でレビューを送信
### MCP APIを使用したレビューコメント追加の例：
```
# 1. レビューを作成
mcp__github__create_pending_pull_request_review:
owner: [OWNER]
repo: [REPO]
pullNumber: [PR_NUMBER]
commitID: [COMMIT_SHA] (オプション)
# 2. 各コメントを追加
mcp__github__add_comment_to_pending_review:
owner: [OWNER]
repo: [REPO]
pullNumber: [PR_NUMBER]
path: "ファイルパス"
line: 行番号
body: "\n\nコメント内容"
subjectType: "LINE"
# 3. レビューを送信
mcp__github__submit_pending_pull_request_review:
owner: [OWNER]
repo: [REPO]
pullNumber: [PR_NUMBER]
event: "COMMENT"
body: "" (サマリーコメントを避けるため空文字列)
```
**重要なポイント**:
- `path`: Gitリポジトリのルートからの相対パス（例: "app/controllers/favorites_controller.rb"）
- `line`: 変更された行の番号（diffで+が付いている行の実際の行番号）
- `body`内の改行: `\n`を使用
- `subjectType`: "LINE"を指定してインラインコメントにする
- `event`: "COMMENT"を使用（"APPROVE"や"REQUEST_CHANGES"ではない）
### レビューラベル対応表：
| ラベル | 意味 | 色 | URL |
|--------|------|----|-----|
| must | 必須修正項目 | red | `https://img.shields.io/badge/review-must-red.svg` |
| imo | 個人的意見 | orange | `https://img.shields.io/badge/review-imo-orange.svg` |
| ask | 質問 | blue | `https://img.shields.io/badge/review-ask-blue.svg` |
| nits | 細かい指摘 | green | `https://img.shields.io/badge/review-nits-green.svg` |
| suggestion | 提案 | blue | `https://img.shields.io/badge/review-suggestion-blue.svg` |
### エラー対処：
- API呼び出しエラーの場合：
- MCP APIのレスポンスを確認
- 必須パラメータがすべて正しく設定されているか確認
- 権限エラーの場合：GitHub MCPサーバーの権限設定を確認
- 行番号エラーの場合：
- diffの実際の行番号と一致しているか確認
- 削除された行ではなく、追加または変更された行の番号を使用
- **絶対に行わないこと**：
- 通常のPRコメント（`mcp__github__add_issue_comment`）への切り替え
- エラー時の妥協
---
**実行開始**: それでは、レビューを開始します。GitHub PRのURLを入力してください。
Happy reviewing! 🎉
Discussion