🐇

Claude Code でのPRレビュー対応を自動化するまでの試行錯誤

2025/06/08に公開

 はじめに：伝言係からの脱却Claude CodeとAI によるレビューサービスの CodeRabbit を導入して、個人開発でのコード生成と自動レビューができるようになりました。しかし、CodeRabbit からの指摘をひとつずつコピペして、Claude Codeに伝えて修正...この繰り返しは億劫です。
このような作業は人間のやるべきことではないので、できるだけ claude.md にワークフローを明示的に記載して自動化してもらうことにしました。

 追記：重要なこと実装指示、PR対応を重ねていくうちに、本記事のメインの claude.md によるワークフローと同じかそれ以上に、以下も非常に重要だと感じました。

 実装のセッションと、PR対応のセッションを分ける集中する範囲が明確になり、セッションが長引かず会話の内容を見失うことが少なくなります。
セッション１：実装 > コミット > PR作成 > 終了

セッション２：レビュー確認 > 指摘整理 > 順次対応 > 終了
大きめの指摘がきた場合は、TODO.md などに追記させ別のセッションで対応することも検討します。

 セッションの開始時に claude.md を確実に読み込ませる例えば「claude.md の内容を読み込み要約してください。」のような指示をセッション開始時にすることにより、確実にルールを読み込ませ、実は読んでなかったというような事態を回避します。

 Claudeの使用するツール類を充実させる今回のケースでは、github api で取得したコメントの構造を Claudeが正確に理解することをが重要になるので、json解析を助けるjqをインストールしておきます。

 最終的なワークフロー試行錯誤の結果、以下のワークフローが確立されました：

 claude.mdに記載した必須手順## ⚠️ CRITICAL: PR Review Comment Check (MUST DO FIRST)
When working on PRs, **ALWAYS execute these two commands FIRST**:

# Command 1: Get PR overview
gh pr view {pr_number} --comments
# Command 2: Get line-by-line comments (CRITICAL - often missed)
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments

## PR Comment Response Rules
### Required Steps (Execute in this order)
1. **Get PR review comments**: 
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments

2. **Reply to each comment_id**: 
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --method POST \
  --field body="Your reply message here" \
  --field in_reply_to={comment_id}

### ⚠️ FORBIDDEN Commands (Never Use)
Do not use these commands (Reason: Posts to PR body or overwrites existing comments)
- gh pr comment {pr_number} --body="..."
- gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --method POST --field body="..." (without in_reply_to)
- gh api repos/{owner}/{repo}/pulls/comments/{comment_id} --method POST (overwrites existing comment)

### Response Requirements
1. **Reply to EVERY comment** (including nitpicks)
2. **Include commit IDs** for fixes: Fixed in commit [abc123](link)
3. **Mark status clearly**: "Fixed", "Won't implement", "Acknowledged"
4. **Use in_reply_to** for direct comment replies

### ⚠️ CRITICAL: Never Auto-Reply
- **NEVER** reply to comments without explicit user instruction
- **ALWAYS** ask user how to respond to each comment
- **WAIT** for user to provide specific reply text or approve "won't implement" responses

 運用ルール
必ず2つのコマンドを実行（PR概要 + 行コメント）

全てのコメントに返信（ニットピック含む）

ステータスを明記：「Fixed」「Won't implement」「Acknowledged」

コミットIDを含める：Fixed in commit [abc123](link)
今では、Claude Codeに「このPRに対応して」と指示するだけで、指摘の一覧を深刻度と共に報告してくれます。その後、対話で対応方針を決めて実装してもらい、適切にコメント返信までしてくれる状態になり、伝言係から脱却しました。

 フェーズ1：手作業からの第一歩
 問題：PRの画面からコメントを手作業でコピペ最初は、GitHub のPR画面を開いて、レビューコメントを一つずつコピペして Claude Code に渡していました。
# 毎回こんな感じで...
1. PRを開く
2. コメントをコピー
3. Claude Codeに貼り付け
4. 修正内容を確認
5. コミット
6. 次のコメントへ...

 解決策：gh cliでコメント取得を自動化# これでPRのコメントを一括取得！
gh pr view {pr_number} --comments
Claude Codeに「このコマンドでレビューコメントを取得して、一つずつ対応して」と指示するだけで、手作業が一気に減りました。

 フェーズ2：見落としの発見
 問題：Claude が行コメントを見逃していた次のPRで気づいたのが、「あれ？このコメント対応されてない」という指摘。調べてみると、コードの特定行に対するコメントを Claude Codeが見落としていることが判明。
gh pr view --commentsでは、PR全体のコメントしか取得できず、コードの行に紐づいたコメントは別のAPIが必要でした。

 解決策：gh api で行コメントも取得# この2つのコマンドが必要だった
gh pr view {pr_number} --comments                    # PR全体のコメント
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments  # 行コメント

 フェーズ3：ドキュメント化の試み
 問題：セッションを切り替えると、また行コメントの指摘を見落としClaude Codeに手順をまとめてもらって docs/development_workflow.md に記載しclaude.mdから参照できるようにしました。
しかし、Claude Codeのセッションを切り替えると、また同じ間違いを繰り返す...

 解決策：claude.mdに直接記載Claude Codeに聞けばそんなワークフローちゃんと読んでなかったとのこと。外部ファイル参照ではなく、claude.mdに直接書き込むことで、確実に読んでもらえるようになりました。
## ⚠️ CRITICAL: PR Review Comment Check (MUST DO FIRST)
When working on PRs, **ALWAYS execute these two commands FIRST**:
# Command 1: Get PR overview
gh pr view {pr_number} --comments
# Command 2: Get line-by-line comments (CRITICAL - often missed)
gh api repos/{owner}/{repo}/pulls/{pr_number}/comments
学び: 重要な情報は、参照ではなく直接記載する

 フェーズ4：返信の自動化で新たな落とし穴
 問題：指摘が多すぎて、対応状況が分からないレビューコメントが5個、10個となると、「このコメントは対応済み？未対応？」の管理が大変に。
そこで、各コメントに対して以下を自動返信するようにしました：
対応したコミットID
対応しない場合の理由

 新たな問題：コメントを上書きしていたClaude Code に「コメントに返信して」と指示したところ、既存のコメントを上書きしてしまいました。
# ❌ これは既存コメントを上書きしてしまう
gh api repos/{owner}/{repo}/pulls/comments/{comment_id} --method POST --field body="..."
元のレビューコメントが消えてしまい、何に対する返信なのか分からない状態に...

 さらなる問題：PR本体へのコメントになっていた「上書きしないで」と指示したところ、今度はPR本体にコメントする形になってしまいました。
# ❌ これはPR本体にコメントしてしまう  
gh pr comment {pr_number} --body="..."
特定のコードコメントへの返信ではなく、PR全体への独立したコメントになってしまい、どのコメントに対する返信なのか追跡が困難に。

 最終解決策：in_reply_to で直接返信in_reply_toパラメータを使った直接返信にしてもらいました。
# ✅ 正しい方法：特定のコメントに返信
gh api repos/{owner}/{repo}/pulls/5/comments --method POST \
  --field body="Fixed in commit [abc123](link)" \
  --field t={comment_id}
CodeRabbitもご機嫌に再返信してくれています。

 追記：またしても繰り返される問題しかし、次のPRでClaudeが再び間違ったコマンドを使おうとしました。今度はbodyに返信しようとしました。しかも「注意深く確認する」というAIらしい？精神論を出してきました。

Claudeと相談し、ワークフローを以下のように修正しました：
## PR Comment Response Rules
### Required Steps (Execute in this order)
1. **Get PR review comments**: gh api repos/{owner}/{repo}/pulls/{pr_number}/comments
2. **Reply to each comment_id**: 
   gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --method POST \
     --field body="Your reply message here" \
     --field in_reply_to={comment_id}

### ⚠️ FORBIDDEN Commands (Never Use)
Do not use these commands (Reason: Posts to PR body or overwrites existing comments)
- gh pr comment {pr_number} --body="..."
- gh api repos/{owner}/{repo}/pulls/{pr_number}/comments --method POST --field body="..." (without in_reply_to)
- gh api repos/{owner}/{repo}/pulls/comments/{comment_id} --method POST (overwrites existing comment)
やるべきことを最初に記述し、やってはいけないことを最小限の記述にしました。

 追記：またしても、またしても繰り返される問題気が付いたらClaudeが指摘への対応の必要の有無も自ら判断して指摘へ返信していました。まだそこまでは求めていません。
Claudeと相談し、ワークフローに以下を追加しました。
### ⚠️ CRITICAL: Never Auto-Reply
- **NEVER** reply to comments without explicit user instruction
- **ALWAYS** ask user how to respond to each comment
- **WAIT** for user to provide specific reply text or approve "won't implement" responses

 学んだこと
 1. 対話による継続的改善Claude Code が何かミスをするたびに、なぜミスしたのか、どうすれば確実に防げるかを対話してドキュメントに残しました。この積み重ねが、最終的に安定したワークフローの構築につながりました。

 2. ドキュメント戦略外部ファイル参照 < 直接記載
抽象的な説明 < 具体的なコマンド例
正しい方法だけ < 間違った方法との対比

 まとめ手作業でのコピペから始まり、コメントの見落とし、ドキュメント化の試行錯誤、返信の自動化での落とし穴など、様々な課題に対処しながら、最終的に安定したワークフローを構築できました。Claude Codeとの対話を通じて継続的に改善を重ねることで、効率的な開発プロセスが実現できています。

 おまけ業務で使っている Devin では Github 統合が強いせいか、この手の問題で悩むことは少ないです。Claude Codeで PR作成、Devin で指摘対応、という分担もありかもしれません。

はじめに：伝言係からの脱却

追記：重要なこと

実装のセッションと、PR対応のセッションを分ける

セッションの開始時に claude.md を確実に読み込ませる

Claudeの使用するツール類を充実させる

最終的なワークフロー

claude.mdに記載した必須手順

運用ルール

フェーズ1：手作業からの第一歩

問題：PRの画面からコメントを手作業でコピペ

解決策：gh cliでコメント取得を自動化

フェーズ2：見落としの発見

問題：Claude が行コメントを見逃していた

解決策：gh api で行コメントも取得

フェーズ3：ドキュメント化の試み

問題：セッションを切り替えると、また行コメントの指摘を見落とし

解決策：claude.mdに直接記載

フェーズ4：返信の自動化で新たな落とし穴

問題：指摘が多すぎて、対応状況が分からない

新たな問題：コメントを上書きしていた

さらなる問題：PR本体へのコメントになっていた

最終解決策：in_reply_to で直接返信

追記：またしても繰り返される問題

追記：またしても、またしても繰り返される問題

学んだこと

1. 対話による継続的改善

2. ドキュメント戦略

まとめ

おまけ

Discussion