修正PRを食べてレビュースキルが向上：Claude Codeによる自己改善サイクル

はじめに

こんにちは。メルペイ 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 というコマンド一発で実行でき、以下の 6 つの汎用的観点を自動チェックします。

汎用的観点

チェック内容

コードの正確性

ロジックの誤り、nil 参照、型の不一致、境界値での挙動など

エッジケース・異常系

エラーハンドリングの漏れなど

後方互換性

API 変更による既存の呼び出し元への影響

機能的影響

機能の喪失、拡張性への制約

テストの十分性

PR におけるテストの追加・更新有無

Unit Test の網羅性

既存テストも含めた正常系・異常系・境界値のカバレッジ

Extra 観点：コードベース固有のチェック項目

上記 6 つは汎用的な観点ですが、/review-pr スキルにはこれに加えて「Extra 観点」と呼ぶセクションも存在します。このセクションには、チームのコードベース固有のアーキテクチャや設計パターンに基づいたチェック項目が蓄積されています。

具体的な内容はリポジトリの特性に依存するため詳細には触れませんが、汎用的なレビュー観点では検出しにくい「そのプロジェクトならではの見落としパターン」を防ぐための項目が並んでいます。この Extra 観点こそが、後述する /improve-review-pr によって継続的に育てられていく部分です。

しかし、この仕組みを形骸化せず運用し続けるためには課題がありました。

課題：スキルは使い続けても賢くならない

当初の仕組みのままだと、過去の学び（見落としパターン）が仕組み側に蓄積されません。どれだけ /review-pr スキルを使い続けても、新しい不具合のパターンを自動で学習することはありません。

ある日、AI のレビューをすり抜けて不具合が混入し、チームが修正 PR（Pull Request）を作成する必要が生じたとします。同じようなパターンの不具合が再発しても、スキルのファイルを手動で更新しない限り、AI は同じ見落としを繰り返します。

これは「人間が毎回ルールを追記しなければならない」という運用負荷を生みます。私たちがこの課題を解決するために作ったのが /improve-review-pr コマンドです。

/improve-review-pr：修正 PR を糧にスキルを育てる

概要

/improve-review-pr は、対応漏れが発覚した修正 PR（Pull Request）を分析し、/review-pr スキルに Extra 観点として再発防止のチェック項目を追加するコマンドです。

修正 PR が発生するたびに「なぜ元のレビューで見落としたか」を分析し、同じパターンの見落としを二度と起こさないようスキルを更新します。ユーザーの承認を経てから SKILL.md を更新する設計で、チームの知見を継続的に蓄積できます。

仕組み

/improve-review-pr を実行すると、以下のステップが走ります。

Step 1:修正 PR の情報取得

gh コマンドで修正 PR（Pull Request）のタイトル・説明・変更ファイル・差分を取得します。

Step 2:元 PR の特定（任意）

修正 PR（Pull Request）の説明文から「この修正が対応した元の PR」を自動抽出します。特定できない場合はユーザーに確認し、不明な場合もそのまま分析を続行します。

Step 3:対応漏れの分析

「なぜこの変更が元 PR のレビューで見落とされたか」を分析します。元 PR が判明している場合は「元 PR のどのファイル変更が、修正の必要性を示唆していたか」まで深掘りします。

Step 4:パターンの抽象化と分類

個別の事例を汎用的なチェックパターンに変換します。以下の基準で追加先を判断します。

分類

条件

追加先

リポジトリ固有

コードベース固有のアーキテクチャに起因

リポジトリ固有チェックとして追加

汎用

一般的なレビュー観点で防げる

既存の観点セクションに追記

既存チェックの強化

類似するチェックが既に存在する

既存項目を拡張

Step 5:重複チェックと提案

/review-pr の SKILL.md を読み込み、類似チェックの有無を確認した上で改善提案します。承認を得てから更新します。

Step 6:SKILL.md の更新

ユーザーの承認後、スキルファイルを更新し、変更箇所をサマリとして表示します。

この 2 つのコマンドを組み合わせることで、以下の自己改善サイクルが回り始めます。

自己改善サイクルの全体像

先週マージされた PR（Pull Request）から候補を検出するため、週次で GitHub Actions が実行され、候補が存在する場合、Slack に通知します。

チームメンバーはその通知を見て /improve-review-pr を実行することで、レビュースキルに改善が 1 つ積み上がります。

「修正 PR（Pull Request）を都度見逃さずスキルに反映する」という運用負荷を自動化によって低減した、継続的なフィードバックループです。

プロセス設計のポイント：Human-in-the-Loop

完全自動化も技術的には可能ですが、あえて「ユーザーの確認・承認を経てから更新する」設計にしています。理由は 2 つあります。

1.誤ったパターンの混入を防ぐ

AI が導出したパターンが常に最適な状態とは限りません。

チェック観点がもう一段階抽象化が必要だったり、チームの開発方針に対して妥当ではない場合もあります。人間が内容を確認することで、このような不適切なチェック項目が追加されてしまうリスクを低減しています。

2.チームの知識として定着させる

承認プロセスを通じることで、「なぜこのチェック項目が追加されたか」をチームメンバーが意識する機会が生まれます。

単なるルールの羅列ではなく、背景のある知識として蓄積されていきます。

まとめ

Claude Code のスキル機能を活用することで、AI レビューを「固定されたツール」ではなく、チームの知見を蓄積し続ける仕組みとして運用できるようになりました。今後さらに多くの修正 PR を経てスキルが充実していくことを期待しています。

同様の仕組みに興味がある方の参考になれば幸いです。

次の記事は hasegway さんです。引き続きお楽しみください。