はじめに
こんにちは。メルペイQAチームでQA Engineerをしている @um(うめ) です。この記事は「Merpay & Mercoin Tech Openness Month 2026」の12日目の記事です。
コードレビューは品質を守る重要なプロセスですが、人間が行うレビューには限界があります。観点の漏れ、見落とし、初めて触るコードベースへの不慣れ、これらはチームが大きくなるほど顕在化する課題です。
私たちのチームでは、こうした課題に対処するため、Claude CodeのSkillsを活用したAIレビューの仕組みを導入しました。
この記事では、 /review-pr と /improve-review-pr という2つのコマンドを組み合わせた自己改善サイクルについて紹介します。
/review-pr：AIによるPRレビュー
概要
Claude Code には標準で /review というレビュースキルが組み込まれていますが、所属チームではこれとは別に、チーム固有の観点を盛り込んだレビュースキル /review-pr を独自に作成・運用しています。汎用的な観点だけでは拾いきれないポイントを、チームのコードベース／アーキテクチャに合わせて追加・調整できることが、独自運用を選んだ最大の理由です。
/review-pr は、PRの変更内容をAIが自動分析し、不具合リスクを多角的にレビューするスキルです。 /review-pr <PR番号> というコマンド一発で実行でき、以下の6つの汎用的観点を自動チェックします。
| 汎用的観点 | チェック内容 |
|---|---|
| コードの正確性 | ロジックの誤り、nil参照、型の不一致、境界値での挙動など |
| エッジケース・異常系 | エラーハンドリングの漏れなど |
| 後方互換性 | API変更による既存の呼び出し元への影響 |
| 機能的影響 | 機能の喪失、拡張性への制約 |
| テストの十分性 | PRにおけるテストの追加・更新有無 |
| Unit Testの網羅性 | 既存テストも含めた正常系・異常系・境界値のカバレッジ |
Extra観点：コードベース固有のチェック項目
上記6つは汎用的な観点ですが、 /review-pr スキルにはこれに加えて「Extra観点」と呼ぶセクションも存在します。このセクションには、チームのコードベース固有のアーキテクチャや設計パターンに基づいたチェック項目が蓄積されています。
具体的な内容はリポジトリの特性に依存するため詳細には触れませんが、汎用的なレビュー観点では検出しにくい「そのプロジェクトならではの見落としパターン」を防ぐための項目が並んでいます。このExtra観点こそが、後述する /improve-review-pr によって継続的に育てられていく部分です。
しかし、この仕組みを形骸化せず運用し続けるためには課題がありました。
課題：スキルは使い続けても賢くならない
当初の仕組みのままだと、過去の学び（見落としパターン）が仕組み側に蓄積されません。どれだけ /review-pr スキルを使い続けても、新しい不具合のパターンを自動で学習することはありません。
ある日、AIレビューをかいくぐる形で不具合が混入し、チームが修正PRを作成する必要が生じたとします。同じようなパターンの不具合が再発しても、スキルのファイルを手動で更新しない限り、AIは同じ見落としを繰り返します。
これは「人間が毎回ルールを追記しなければならない」という運用負荷を生みます。私たちがこの課題を解決するために作ったのが /improve-review-pr コマンドです。
/improve-review-pr：修正PRを糧にスキルを育てる
概要
/improve-review-pr <修正PR番号> は、対応漏れが発覚した修正PRを分析し、 /review-pr スキルにExtra観点として再発防止のチェック項目を追加するコマンドです。
修正PRが発生するたびに「なぜ元のレビューで見落としたか」を分析し、同じパターンの見落としを二度と起こさないようスキルを更新します。ユーザーの承認を経てから SKILL.md を更新する設計で、チームの知見を継続的に蓄積できます。
仕組み
/improve-review-pr <修正PR番号> を実行すると、以下のステップが走ります。
Step 1:修正PRの情報取得
gh コマンドで修正PRのタイトル・説明・変更ファイル・差分を取得します。
Step 2:元PRの特定（任意）
修正PRの説明文から「この修正が対応した元のPR」を自動抽出します。特定できない場合はユーザーに確認し、不明な場合もそのまま分析を続行します。
Step 3:対応漏れの分析
「なぜこの変更が元PRのレビューで見落とされたか」を分析します。元PRが判明している場合は「元PRのどのファイル変更が、修正の必要性を示唆していたか」まで深掘りします。
Step 4:パターンの抽象化と分類
個別の事例を汎用的なチェックパターンに変換します。以下の基準で追加先を判断します。
| 分類 | 条件 | 追加先 |
|---|---|---|
| リポジトリ固有 | コードベース固有のアーキテクチャに起因 | リポジトリ固有チェックとして追加 |
| 汎用 | 一般的なレビュー観点で防げる | 既存の観点セクションに追記 |
| 既存チェックの強化 | 類似するチェックが既に存在する | 既存項目を拡張 |
Step 5:重複チェックと提案
/review-pr のSKILL.mdを読み込み、類似チェックの有無を確認した上で改善提案します。承認を得てから更新します。
Step 6:SKILL.mdの更新
ユーザーの承認後、スキルファイルを更新し、変更箇所をサマリとして表示します。
この2つのコマンドを組み合わせることで、以下の自己改善サイクルが回り始めます。
自己改善サイクルの全体像
先週マージされたPRから候補を検出するため、週次でGitHub Actionsが実行され、候補が存在する場合、Slackに通知します。
チームメンバーはその通知を見て /improve-review-pr を実行することで、レビュースキルに改善が1つ積み上がります。
「修正PRを都度見逃さずスキルに反映する」という運用負荷を自動化によって低減した、継続的なフィードバックループです。
プロセス設計のポイント：Human-in-the-Loop
完全自動化も技術的には可能ですが、あえて「ユーザーの確認・承認を経てから更新する」設計にしています。理由は2つあります。
1.誤ったパターンの混入を防ぐ
AIが導出したパターンが常に最適な状態とは限りません。
チェック観点がもう一段階抽象化が必要だったり、チームの開発方針に対して妥当ではない場合もあります。人間が内容を確認することで、このような不適切なチェック項目が追加されてしまうリスクを低減しています。
2.チームの知識として定着させる
承認プロセスを通じることで、「なぜこのチェック項目が追加されたか」をチームメンバーが意識する機会が生まれます。
単なるルールの羅列ではなく、背景のある知識として蓄積されていきます。
まとめ
Claude Codeのスキル機能を活用することで、AIレビューを「固定されたツール」ではなく、チームの知見を蓄積し続ける仕組みとして運用できるようになりました。今後さらに多くの修正PRを経てスキルが充実していくことを期待しています。
同様の仕組みに興味がある方の参考になれば幸いです。
次の記事は hasegway さんです。引き続きお楽しみください。
