Claude Codeでドメインに特化したコードレビューをする
Claude CodeにはGitHub連携があり、Issueから実装を指示したり、Pull Requestのレビューを依頼したりできます。
デフォルトの状態でも言語やフレームワーク、周辺コードに基づいたレビューをしてくれて大変有用ですが、サービス仕様の観点から深掘ったレビューが出来るとさらに安心感がありそうです。
この記事ではClaude Codeにレビュー観点を与え、期待する切り口でPRをレビューしてもらう方法を紹介します。
作りたいもの
用意した観点に基づき、Claude Codeがレビューしてくれる仕組み。
大まかなポイントはこんな感じです:
- サービスの仕様 / 実装で間違えやすい箇所などの観点をClaudeに伝えておく
- PRレビュー時には観点に基づいてチェック・フィードバックしてもらう
- 汎用的ではない、サービス固有のバグを見つけられる精度を目指す
まずはGitHub連携をセットアップ
Claude CodeのGitHub連携がまだの場合はセットアップから始めます。
Claude Codeを起動し、 /install-with-github
コマンドを実行して手順に従えば簡単にセットアップできるはずです。
GitHub Actionsの作成、Anthropic APIキーの環境変数へのセットなどが自動で完了します。
(Claude CodeをGitHub Actionsで動かすためにはAPIキーが必要です。現時点ではMaxやProプランを契約している場合も同様)
試しにPRコメントで @claude このPRをレビューして
と話しかけてみましょう。
画像のようにClaudeが登場し、レビューの進捗を伝えてくれる状態になっていればOKです。
ドメインに詳しいレビューをしてもらう
レビューの観点を作成する
まずはレビューの観点を書いておきましょう。
今回は docs/REVIEW.md
というファイルを作り、以下のように記述しました。
# コードレビューガイドライン
コードレビューでは「デグレ」を検出できるように注意深く実装の変更を調べます。
**レビューポイント** に従って、少しでも怪しいと思ったらコメントで指摘してください。
## レビューポイント
### 観点その1
(ここに観点その1の詳細...)
### 観点その2
(ここに観点その2の詳細...)
レビュー観点には間違えがちな実装箇所や、過去に起きたインシデントの再発防止のチェックリストなどを記載します。
Pull Requestのテンプレートを活用して再発防止のチェックリストを置いたりすると思いますが、歴史が長くなって数が増えすぎると項目の確認や管理が煩雑になってきます。
AIレビューでは今回の変更ではどの項目のチェックが重要なのかも自動で判断されます。人間の負担を少し減らすことができると思います。
レビュー観点を読み込み、ultrathinkする
作成した観点に沿ってレビューしてもらいましょう。
Claude Codeには特別なキーワードがあり、「think」「think hard」「think harder」「ultrathink」の順により深い思考をしてくれます。
このキーワードを付与して、レビュー時に以下のように依頼すると観点に沿ったレビューをしてもらえます。
@claude @docs/REVIEW.md の観点に従ってこのPull Requestをレビューしてください。
このタスクは重要なので細かい点も見過ごさないこと。 ultrathink して確認してください。
返信はすべて日本語で行うこと。
ちなみにレビュー観点を読ませるだけでもそれなりに優秀ですが、複雑なバグを発見するには ultrathink
キーワードが必要でした。
キーワードをつけることで影響範囲をより詳細に調査してくれます。
レビュー依頼文をデフォルト設定にする
レビュー依頼時に毎回上記のメッセージを打つのは面倒です。
claude.yml
を編集してデフォルトの指示文に設定しておきましょう。
// claude.yml
// ...(略)
- name: Run Claude Code
id: claude
uses: anthropics/claude-code-action@beta
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }
custom_instructions: |
- レビュー観点は @docs/REVIEW.md にあります。これを参考にして、絶対に抜け漏れがないように ultrathink して考えてください。
- 常に日本語で返信してください。
こんな感じで custom_instruction
を書いておくと指示文に自動で追記されます。
この設定をしておけば、PR上では以下のようにシンプルな依頼でOKです。
// これだけで観点に基づくultrathinkレビューが実施される
@claude このPRをレビューして
PR作成時に自動でレビューされるようにする
初期でセットアップされる claude.yml
では、PRのタイトルや本文、コメントに @claude
のキーワードが登場しないとClaude Codeがトリガーされません。
今回はPull Requestを作成したタイミングで自動的にレビューして欲しいので少し手を加えます。
PR作成時に自動でClaude Codeを発火させるには direct_prompt
のオプションを利用します。
自動で作られる claude.yml
とは別に claude-pr-review.yml
を作成し、以下の内容を記述しましょう。
// claude-pr-review.yml
name: Claude Auto Review
on:
pull_request:
types: [opened]
jobs:
claude-auto-review:
runs-on: ubuntu-latest
if: github.event.pull_request.user.type != 'Bot'
permissions:
contents: read
pull-requests: read
issues: read
id-token: write
steps:
- name: Checkout repository
uses: actions/checkout@4
with:
fetch-depth: 1
- name: Run Claude Code
id: claude
uses: anthropics/claude-code-action@beta
with:
anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
direct_prompt: |
このPRをレビューしてください。
- レビュー観点は @docs/REVIEW.md にあります。これを参考にして、絶対に抜け漏れがないように ultrathink して考えてください。
- 常に日本語で返信してください。
ポイントは以下の通りです:
- Pull Requestオープン時に自動で発火する
- botが作ったPRには反応しない(dependabotなどが作るPRは無視)
-
direct_prompt
には先ほどと同じ指示文を記述
これでPR作成時に自動でレビューが実行されます。
ちなみにtypesの指定にopen
だけでなくsynchronized
も追加すると新しいコミットがされる度にレビューが走ります。チェックとしては万全ですが、レビュー回数が多くなってしまうため今回はなしにしています(追いコミット時はメンバーが手動で @claude
と呼びかけてレビュー依頼する)。
カスタムスラッシュコマンドを用意する
Claude Codeにはカスタムスラッシュコマンドという、よく使うプロンプトや指示を登録しておける機能があります。
今回用意した観点に基づくレビューをコマンド登録し、GitHub上だけでなく開発中のローカル環境でも呼び出せるようにしておきましょう。
カスタムスラッシュコマンドを追加するには定められたパスにファイルを追加します。
今回は .claude/commands/review-scan.md
を作成し、以下の中身を記述しました。
---
description: "docs/REVIEW.md に従ってレビューを行います"
---
# タスク
- レビュー観点は @docs/REVIEW.md にあります。これを参考にして、絶対に抜け漏れがないように ultrathink して考えてください。
- 常に日本語で返信してください。
# レビュー内容
``bash
# mainブランチとの差分を取得
git diff main...HEAD
# コミットログも確認
git log --oneline main..HEAD
``
上記のgit diffの結果を基に、 @docs/REVIEW.md のガイドラインに従ってレビューを実施してください。
review-scan.md
というファイル名で作成したのでコマンド名は /review-scan
になります。Claude Codeを起動して確認してみましょう。
これでコマンドからレビューを実行できるようになりました。
コミット前にレビューして確認したり、レビュー項目を追加したときに期待通り指示してくれるかを確認したりできます。
AIレビューのコスト
Claude Code利用にかかる費用ですが、今回試したPull Requestでは1回のレビューで約5円がかかりました。
これが安いか高いかはプロジェクトによるでしょうが、自分としては重大なインシデントを事前に防げるのであれば十分ペイする金額ではないかと思っています。
GitHub Actionsのトリガーを編集すれば「特定のディレクトリ下のファイルが変更された時のみレビューする」ように絞ることも可能です。
この辺りは費用と効果のバランスを見て改善していきたいところです。
おわりに
Claude Codeの賢さを活かし、最低限の仕組みでドメインに詳しいレビューをしてもらうことができました。検証として過去にインシデントとなった変更を改めてレビューしてもらい、その時の問題点が正しく指摘されることを確認しました。
一度仕組みができれば後は docs/REVIEW.md
をアップデートしていくだけです。専門的な仕様、重要だけど忘れがちな観点などをチームで追加して育てていきましょう。
今回紹介した内容は実際にmicroCMSに導入した仕組みです。運用してみて気づいた点があればまたご紹介したいと思います。
それでは、最後までお読みいただきありがとうございました!
Discussion