レビューの資産化：過去のレビューコメントをAIで整理して開発ルールに落とす

目的は？

一言で言うと

過去のレビューコメントをAIで整理して開発ルールにする

なぜ

こんにちは
最近は、AIエージェントによるコーディングの生産性向上が話題ですよね。

自分としても、Claude CodeのOpus4.5の利用を最近初め、
その質の高さに自分のコーディングスキルのプライド(といっても、エンジニア歴2〜3年なので大したスキルはないのですが笑)をキッパリすて、AIをガンガン活用してスピードをあげていこうと思っています。

また、AIエージェントの成長もこれから上がっていき・・・

まあ色々な要因でPR数が急増し、レビュワーが足りない現象にすぐなりそうです。

---

レビュー負荷を減らす方法で思うのが、ルールの準備だと思っています。(claude.mdとかinstructions.mdとか)

ただそのルールを準備するのが、コードベースから読み取ったり、日々の開発中に〜とか意外と大変です。
そこで今回は、過去のレビューを活用したいと思います。

また、PR レビューには「チームの暗黙知」が含まれる可能性が高いと思っています。

「このプロジェクトではこの書き方のほうが読みやすいよ」

「このAPIの返り値はこう扱うのが慣習だよ」

「この変数名は他のファイルと揃えてほしい」

「この状況ではエラーハンドリング入れておくと後で助かるよ」

こういう 明文化されていない細かい判断基準 が、日々のレビューコメントの中に散り散りに埋まっていて、
実はこれが チームの品質を支えている “非公式ドキュメント” だったりするのかなと。

そこらへんもうまい具合にルール化できれば良さそうです。

どのようにやるのか？

レビュー収集

まずは、どのようにレビューを集めるか？ですが、GitHub CLIが使えそうです。

これによりjsonでレビューコメントを出力できます。

repos/:owner/:repo/pulls/:number/reviews

また、全期間だと巨大なファイルになってしまいそうで、一旦テストの意味合いも兼ねて、今回は過去半年にしています。

あとは最低限の以下の項目に絞ります。

• body (コメント内容)
• path (コメント対象のファイルのパス)
• line (その行番号で nullもある)

fetch-comments.bash

#!/bin/bash
ORG="orgを入れてください"
REPO="リポジトリ名を入れてください"
SINCE=$(date -v-6m +%Y-%m-%dT00:00:00Z)

gh api \
  -H "Accept: application/vnd.github+json" \
  "repos/$ORG/$REPO/pulls?state=all&per_page=100" |
jq -r --arg since "$SINCE" '.[] | select(.created_at >= $since) | .number' |
while read pr; do
  gh api \
    -H "Accept: application/vnd.github+json" \
    "repos/$ORG/$REPO/pulls/$pr/comments"
done |
jq -s 'flatten | map({body, path, line})' > all_comments.json

実行にちょっと時間がかかるかもです。

あと、以下のコマンドで簡単にorgとrepoがわかります

git remote -v
# 出力例: origin  [e-mail]:your-org/repo-name.git (fetch)

レビュー整形

そうすると、こんな感じのjsonになりました。

いいですね！ここら辺のコメントとか、結構勉強になります。
これは、丁寧にレビューコメントを書いてくださっていたチームメンバーの方に頭が上がりません。ありがとうございます。

感謝の気持ちは忘れずに、他の行も確認していきます。
例えば、これは有効な情報になりません。承知しただけです。

なので、一旦このレビューコメントの情報から、有効そうな情報だけを整理していこうと思います。

以下のプロンプトを使用してみてください。

あなたは GitHub のコードレビューコメント JSON をフィルタリングするモデルです。

目的：
- 元の JSON 構造を壊さずに、コメントのうち「指摘（Issue / 改善要求 / 問題指摘）」だけを残す。
- 指摘ではないコメントはリストから完全に削除する。
- キーの順番や構造は可能な限り元 JSON を保持する。

---

【指摘コメントの定義】

次のいずれかに該当する場合は「指摘」と判断する：

- コードの問題点を述べている（バグ、仕様不一致、誤動作の可能性）
- 型・データ構造・例外処理・APIレスポンスの不整合を指摘している
- ロジック・命名・責務分離・可読性に関する改善要求
- 考慮漏れ・境界値・エッジケースの指摘
- 冗長・不要コードの削除要求
- 安全性・パフォーマンスの懸念
- 設計や方針レベルの「こうすべき」提案

---

【指摘ではないコメント（削除する）】

- 確認（「これどうですか？」）
- 同意・賛同（「LGTM」「良いですね」）
- 雑談
- 感謝や挨拶
- 進捗・作業メモ（「ここ後で直します」）
- PRの意図説明
- コード外のメモ
- 結論が曖昧な意見（具体的な問題点が提示されていないもの）

---

【出力ルール】

- 入力は JSON の配列とする。
- 出力も JSON の配列にする。
- 指摘コメントのみを残し、それ以外のコメントは配列から除去する。
- コメント内容は `body` フィールドで判断する。
- JSON のフォーマットはそのまま維持し、値を変えない。
- フィルタリング以外の書き換えは禁止。

Gemini等で先ほどのjsonを添付して、実行してください。(推論モード等を推奨)

量が多い場合、分割する必要があるかもです。

いい感じに、指摘系のコメントだけにフィルタできたら、OKそうです。

整形データの適用

さて、ここから指摘をどのように抽象化したり、分類したりを考えたいです。

また、目的の通り.md系へ保存するので、またワンステップjson→mdにするプロンプトが必要そうです。

ここでは、instructionsの構成などがプロジェクトで様々かと思いますので、一旦jsonを列挙するようなプロンプトにしています。

また、抽象的なルールだけにせず、せっかく取得したので具体例としてコメントを入れるようにしています。

あなたは GitHub のレビューコメント JSON をもとに、
instructions.md を以下の最小構成で生成します。

【出力構造】
# Instructions

- **ルール:** {抽象化したルール1行}
  - 具体例: 「{コメントbodyから要点を1行で要約}」(path: {path}, line: {line or N/A})

- **ルール:** {抽象化したルール1行}
  - 具体例: 「…」

（コメント数だけ続く）

【変換ルール】
- 必ず「ルール → 具体例」の 2 段構造だけで出力する
- ルールはコメント内容から抽象化した再現性のある原則
- 具体例は body の要点を1〜2行で要約し、path/line を含める
- 同じルールに分類できそうでも、**まとめず必ず1コメント1ルールとして列挙**
- Markdown のみ出力（JSON は不要）

では以下の JSON をもとに instructions.md を生成してください：

完成

結果として、このようなレビューコメントを元にしたルールの列挙ができました。

ルール: オブジェクトを不変化した場合、その利用側でも readonly の型を適切に扱うよう統一する
  - 具体例: 「const アサーションを付けたなら、利用側の型にも readonly を反映する必要があるとの指摘」（某 UI コンポーネント or データモデル）

ルール: フォーム関連コンポーネントでは、ユーティリティ型を拡張したうえで ...rest を展開し、柔軟に外部から制御できるようにする
  - 具体例: 「汎用コンポーネントとして設計するため、ユーティリティ型を拡張し rest props を許可する案が提案された」（某 UI コンポーネント内）

ルール: 非同期関数の引数はオブジェクトリテラルで定義し、可読性と一貫性を保つ
  - 具体例: 「別箇所の記法と合わせるため、オブジェクト形式で引数を渡すのが良いとの指摘」（某 API フック内）

ルール: 汎用コンポーネントの型定義では、フォーム制御ライブラリが提供する型ユーティリティを利用し、型安全性を高める
  - 具体例: 「フォーム制御用の型を any にせず、提供されているユーティリティ型を使う案が提示された」（某 UI コンポーネント内）

あとは好きな場所に振り分けたり置いていけば良さそうです。

改善点や思ったこと

データ取得の際に、pathとlineも取得したが、あまり役にたっていないこと

うーん。そもそもpathとlineが必要なかったか、もしくはその実際のコードを取得できればよかったかもです。

レビューがあっているとは限らない

• 過去のレビューはチームの成熟度によってばらつく
• 新しいアーキテクチャ導入後、古いレビューは逆にアンチパターンになる可能性

ここは、最終的に出たルールをしっかり確認する必要がありそうです。

lint でカバーできる内容は、lint に任せる

ESLint や RuboCop などで機械的に検出できるものは、instructions に書くのではなく、
リントツールのルールとして設定したほうが管理しやすくなります。

今後のスケーリング

今後のレビューコメントをどうしていくか？ですが、半年ごとに〜とかやるのは流石にしたくないですよね。
CIで、「そのPRのコメントを集め、同様の成形を行いPRを作成する」ことができたら良さそうです。

ただ一旦そこは手動で、レビューの指摘内容をチマチマルールに追加していくで良さそうです。

まとめ

過去のレビューから、少しでも多くルールを強化することができた。

まだinstructionsなどが整備されていないリポジトリでも、土台の一部として有用な手法かもしれない。