PRレビュー修正〜コメント返信をClaude Codeで自動化してみた

はじめに

コードを書いている時間はエディタからなるべく離れたくない...ブラウザに見に行くのが辛い...ということで、以前からVSCode（Cursor）のプラグインを使っていました。

https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github

ただコメント返信をエディタからやったとしても、どのみち修正するのはAIだよな〜と思い、Claude Codeのカスタムコマンドで全部できれば良いじゃんと思い作ってみました。

Github上で直すかローカルで直すか

まずPRでのレビュー返信〜コード修正をClaude Codeで自動化したいと考える時に2つの選択肢があります。

1） Github上でClaude Code Actionを呼び出しレビューコメントに基づいて修正依頼を投げる

Claude Code Actionが公開されてから触っていますが、コードレビューでは非常に使い勝手がよくtacoms社でも全チーム活用しています。Github上でコード修正を依頼することもできるのですが、修正作業では必ずしも上手くいかないのが現状と考えます。
また、AIがコーディングしているプロセスがブラックボックス化されてしまい途中で介入できないのもデメリットの1つと考えます。（厳密にはActionを止めれば良いですが途中で方向転換はできません）

https://github.com/anthropics/claude-code-action

2） ローカルのClaude CodeでPRの情報を取得しghやMCP経由で操作する

ghでもMCPでも良いのですが、ClaudeCodeからPRの情報を取得したり更新したりすることも可能です。Claude Codeでコーディングを自動化することは日常でやっていることなので実装の精度は問題にならないですし、途中で介入できるメリットもあります。

ということで、今回は2の方針で進めました。

PRレビュー〜修正作業におけるこれまでとこれから

これまでのフローを一旦整理した上で、Claude Codeを使ったフローはどうなっていると良いのか考えてみます。

reviewee: 🙋‍♂️
reviewer: 💁‍♀️
Claude Code: 🤖

これまで

• 🙋‍♂️）PRを作成
• 🙋‍♂️）レビューリクエスト
• 💁‍♀️）コードレビュー・コメント
• 🙋‍♂️）Github or エディタ上でコメント確認
• 🙋‍♂️）レビューを受けて実装計画を検討
• 🙋‍♂️）実装作業 & コミット & リモートへpush
• 🙋‍♂️）コメント返信
• 💁‍♀️）LGTM

これから

• 🙋‍♂️ or 🤖）PRを作成
• 🙋‍♂️ or 🤖）レビューリクエスト
• 💁‍♀️ or 🤖）コードレビュー・コメント
• 🙋‍♂️）Claude Codeのカスタムコマンドを実行
• 🤖）コードレビュー内容やコメント内容の分析
• 🤖）実装計画を策定
• 🤖）実装作業 & コミット & リモートへpush
• 🤖）コメント返信
• 💁‍♀️）LGTM

補足
Claude Code Actionの精度が上がってくれば、PR上で完結するこちらのフローに統一するのが良いと考えています。

1） Github上でClaude Code Actionを呼び出しレビューコメントに基づいて修正依頼を投げる

カスタムコマンドでPRレビュー〜修正を自動化する

Claude Codeのカスタムコマンドで詳細なステップを記述しておき、コマンド実行するだけで以下のワークフローを実現できるようにしました。

• PRレビューを確認
• 実装計画を構築
• ユーザーに計画の確認依頼
• ユーザーの承認 -> 実装開始
• 実装完了後コミット&push
• レビューコメント1つ1つに返信する

実行方法

①以下のようなファイルを作り、.claude/commandsに置きます。

# PR レビューコメント修正コマンド

## 目的
あなたはPull Requestのレビューコメントを網羅的に確認しコードを修正するAIアシスタントです。
現在のブランチ紐づいているPR情報を取得し詳細な計画を作り、コードを修正した上でコメントに返信しましょう。

## 重要な注意事項
- 必要に応じてWEBの情報を参照してください。なお参照する場合は2025年7月時点最新の情報を参照しましょう
- 現在のブランチにPRが紐づいてない場合はここで作業を終了してください

---
## Pull Request 修正手順

### Phase 1: コメント情報の収集
1. `gh pr view --comments` でPRの詳細とコメントを取得
2. `gh api repos/{ORGANIZATION}/{CURRENT_REPO}/pulls/{PR_NUMBER}/comments` で詳細なコメントデータを取得
3. `gh api repos/{ORGANIZATION}/{CURRENT_REPO}/pulls/{PR_NUMBER}/reviews` でレビューコメントを取得
4. 必要に応じて `gh api repos/{ORGANIZATION}/{CURRENT_REPO}/issues/{PR_NUMBER}/comments` で一般コメントも確認

### Phase 2: コメント分析と分類
収集したコメントを以下の観点で分析してください：

1. **コメントの分類**
   - 🔴 必須修正項目（blocking issues）
   - 🟡 推奨修正項目（suggestions）
   - 🟢 質問・議論項目（questions/discussions）

2. **技術的重要度**
   - 🚨 クリティカル（システム障害リスク）
   - 🔥 高（本番環境への影響大）
   - 📈 中（品質・保守性への影響）
   - 📝 低（スタイル・可読性）
   - 🎯 改善提案（将来的な拡張性）

3. **カテゴリー**
   - **仕様適合性に関する指摘**
      - 要件定義との整合性
      - 既存機能の仕様
      - 受け入れ条件
   - **コーディングルールに関する指摘**
      - `docs/cording/example.md``との整合性
      - 命名規則の統一性
      - インデント・フォーマット
   - **パフォーマンスに関する指摘**
      - メモリ使用量の最適化
      - データベースクエリの効率性
      - API呼び出しの最適化
      - キャッシュ戦略
   - **アーキテクチャに関する指摘**
      - 類似実装との統一性
      - 過去意思決定(ADR)との整合性
      - 依存関係の方向性
      - デザインパターンの適用
   - **テスト品質に関する指摘**
      - テストカバレッジの妥当性
      - テストケースの網羅性
      - モックの適切性
      - テストの可読性・保守性
   - **エラーハンドリングに関する指摘**
      - 例外処理の適切性
      - エラーメッセージの明確性
      - ログ出力の妥当性
      - 復旧可能性の考慮
   - **可読性・保守性に関する指摘**
      - コードの自己文書化
      - コメントの適切性
      - 関数・クラスの責務分離
      - 複雑度の管理

4. **影響範囲**
   - 単一ファイル修正
   - 複数ファイル修正
   - アーキテクチャ変更
   - 依存関係変更
   - データベーススキーマ変更
   - API仕様変更

### Phase 3: 修正計画の立案

**重要**
- 分析結果について深く考え(ULTRATHINK)、修正計画を作成してください
- 分類されたコメントのうち修正するのは`必須修正項目`と`推奨修正項目`の2つのみでお願いします。

```markdown
# PR #{PR_NUMBER} 修正計画

## 📋 コメント一覧
| コメントの分類 | カテゴリー | ファイル | 内容 | レビュアー |
|--------|------------|----------|------|-----------|
| 🔴 | Code Quality | src/main.js:15 | 変数名をより具体的に | @reviewer1 |
| 🟡 | Performance | src/api.js:42 | キャッシュ機能の追加検討 | @reviewer2 |

## 🎯 修正方針
### 必須修正項目（Phase 1）
- [ ] 項目1: 詳細な修正内容
- [ ] 項目2: 詳細な修正内容

### 推奨修正項目（Phase 2）
- [ ] 項目1: 詳細な修正内容
- [ ] 項目2: 詳細な修正内容

## 📅 実装順序
1. 必須修正項目の実装
2. 推奨修正項目の実装
3. テスト実行・検証
4. プッシュ・レビュー依頼

## ⚠️ 注意事項
- 質問・議論項目に分類されたものは計画不要です
- 修正により既存機能に影響がないか確認
- テストが全て通ることを確認
- 依存関係の変更がある場合は慎重に検討
`​``

### Phase 4: 計画品質のチェック
- [ ] PR上の全コメントを参照している
- [ ] 全コメントが「必須修正項目」「推奨修正項目」「質問・議論項目」の3つに分類されている
- [ ] コメントの内容が分析されている
- [ ] 具体的で明確な修正方針が作成されている

計画の80%がチェックされている状態になるまで次のフェーズに進まないでください。

### Phase 5: ユーザー確認
`修正計画`を提示し、以下を確認してください：
- 修正方針に問題がないか
- 優先順位が適切か
- 追加で考慮すべき点がないか

**この段階で必ずユーザーの承認を得てから次のPhaseに進んでください。**

### Phase 6: 実装実行
ユーザーの承認後、以下の手順で実装を行ってください：

#### 1. 事前準備
- 現在のブランチの状態確認
- 依存関係の確認
- 計画の確認

#### 2. 修正実装
- 優先度順に修正を実施
- 各修正後にコミットを作成
- コミットメッセージにはPR番号と修正内容を記載

#### 3. 検証
**重要: 全ての項目が成功するまで検証を終了しないでください**
- [ ] フォーマットチェック
- [ ] リンターチェック
- [ ] テスト
- [ ] モック生成

```bash
# フォーマットチェック
make fmt

# リンターチェック
make lint

# テスト実行
make test

# モック生成（必要な場合）
make go-gen
`​``

#### 4. 最終確認
  - 全ての必須項目が完了していることを確認
  - 検証が成功していること

### Phase 7: リモートリポジトリへのpushとコメント返信
#### 1. リモートリポジトリへのpush
  - 変更内容を確認してコミット
  - 修正内容をリモートリポジトリにpush

#### 2. コメントIDを取得して個別返信する
**重要: 個別コメント返信は必ずStep1→Step2の順番で実行してください**

##### Step1: コメントIDを確認する
```shell
gh api 'repos/{ORGANIZATION}/{CURRENT_REPO}/pulls/{PULL_NUMBER}/comments' | jq '.[] | {id: .id, body: .body}'
`​``

##### Step2: 修正対象のコメントIDごとに個別で返信する
**重要**
- コメントする際は「by Claude Code」の文字を追加してください
- 🔴必須修正項目と🟡推奨修正項目で実際に修正したもののみに返信する
- 🟢質問・議論項目には返信しない（別途回答が必要）
- 各コメントに対して具体的な修正内容を記載する

```shell
gh api --method POST -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" /repos/{ORGANIZATION}/{CURRENT_REPO}/pulls/{PULL_NUMBER}/comments/{COMMENT_ID}/replies -f 'body=test_comment'
`​``

例：
```shell
# コメントID 000001 （コメントアウト削除）への返信
gh api --method POST -H "Accept: application/vnd.github+json" -H "X-GitHub-Api-Version: 2022-11-28" /repos/{ORGANIZATION}/{CURRENT_REPO}/pulls/{PULL_NUMBER}/comments/{COMMENT_ID}/replies -f 'body=修正しました。コメントアウトを削除しました。

by Claude Code'
`​``

#### 3. レビュー再依頼
- レビューを再依頼
- 修正内容の要約をコメントで追加

### Phase 8: ユーザーへの作業結果出力

**出力フォーマット**
```markdown
### 作業内容
作業内容を全てまとめて記載する
{作業内容}

### 未回答の質問
未回答の質問が存在する場合はこちらに記載する
{未回答質問}
`​``

②コマンドを実行するだけ

レビュワーからのレビューコメント通知が飛んできたら、Claude Codeでこのコマンドを実行します。

/ pr-review-reply-fix.md

実行結果

実際にやってみた結果こんな感じでした 🎉🎉
ちゃんとレビューコメント1つ1つに返信もしてくれますし、修正してpushまでやってくれました👏👏

実装のポイント

1. 計画フェーズでコメント分析や分類を行うことでコンテキストを補強する

コメント情報の収集や分析フェーズを手厚くやっているのは、後半の実装フェーズに渡す前に最大限精度の高い計画を作ってもらうためです。「コメントの分類」や「指摘内容のカテゴリ」を作ることで、AIが実行計画を作成する際のコンテキストを補強しています。

1. **コメントの分類**
   - 🔴 必須修正項目（blocking issues）
   - 🟡 推奨修正項目（suggestions）
   - 🟢 質問・議論項目（questions/discussions）

2. レビューコメントへの個別返信制御

単純に「コメントしてください」の形だと、全ての作業内容をまとめた大きいコメントが投下されてしまいました。

せっかくコメントしてくれたにも関わらず、個別で返信されないと会話がスレッドにまとめられず不便でしょう...なので、きちんと個別で返信するように事例を示しながらステップを制御しました。

#### 2. コメントIDを取得して個別返信する
**重要: 個別コメント返信は必ずStep1→Step2の順番で実行してください**

##### Step1: コメントIDを確認する
```shell
gh api 'repos/{ORGANIZATION}/{CURRENT_REPO}/pulls/{PULL_NUMBER}/comments' | jq '.[] | {id: .id, body: .body}'
`​``

##### Step2: 修正対象のコメントIDごとに個別で返信する
**重要**
- コメントする際は「by Claude Code」の文字を追加してください
- 🔴必須修正項目と🟡推奨修正項目で実際に修正したもののみに返信する
- 🟢質問・議論項目には返信しない（別途回答が必要）
- 各コメントに対して具体的な修正内容を記載する

3. 質問コメントの適切な処理

チームメンバーがせっかくPRに質問をしてくれたにも関わらず、AIで全部作業をしているからといって質問をスルーしてはいけません！

コメントの分類フェーズで「修正依頼」か「質問」かを明確に分けており、「質問」についてはあえてAIから回答しないように制御し、最後の作業報告に以下のような形で報告するようにしています。

### 作業内容
作業内容を全てまとめて記載する
{作業内容}

### 未回答の質問
未回答の質問が存在する場合はこちらに記載する
{未回答質問}

まとめ

ということで、PRのレビューコメントを返信して実装するところまで自動化するコマンドを作ってみました。
カスタムコマンドは非常に面白い仕組みだと思います！
コマンドにプロンプトテンプレートを仕込むことができるので、これを上手く使えば色々なところでコマンド一発で様々な作業が実現できそうです。

皆さんもぜひ参考にしてみてください〜