自社のレビュー履歴からAIコードレビュアーをつくる方法

「またこの指摘か…」と感じたことはありませんか

プルリクエストのレビューで、毎回同じような指摘を書いている。レビュアーによって指摘の粒度がバラバラで、新人が混乱している。レビュー待ちの時間が長くて開発のリズムが崩れる——こうした悩みを抱えているチームは少なくないはずです。

実は、この悩みを解決する材料はすでに社内にあります。それが過去のレビュー履歴です。GitHubやGitLabに蓄積されたPRコメントには、あなたのチームが「何を大事にしているか」「どこでよくミスが起きるか」が詰まっています。

この記事でできるようになること

この記事では、社内に眠っているレビュー履歴データを使って、自社の基準に沿ったAIコードレビュアーをゼロから組み立てる手順を紹介します。特別な機械学習の知識がなくても、ChatGPTなどのLLM（大規模言語モデル）とプロンプト設計の工夫だけで、実用に耐えるレビュー補助ツールの土台を作ることができます。

自社のレビュー履歴は、汎用AIレビューツールにはない「自分たちの文化」を教え込める唯一の教材です。

ステップ1：レビュー履歴データを集める

まずはGitHubやGitLabのAPI、あるいはエクスポート機能を使って、過去のPRコメントを収集します。見るべきポイントは次の3つです。

• レビュアーが指摘した本文
• 指摘対象になったコードの差分（diff）
• その指摘が「採用されたか」「議論の末に却下されたか」

最低でも直近半年〜1年分、できれば数百件規模のコメントがあると傾向が見えやすくなります。件数が少ないチームでも焦る必要はありません。まずは集められる範囲で始めて、後から追加していけば大丈夫です。

ステップ2：データを整形し、指摘パターンを分類する

集めたコメントをそのままAIに読ませても効果は限定的です。ここで一手間かけるのがポイントです。

1. 個人名やプロジェクト固有の機密情報を除去する
2. 指摘内容を「命名規則」「例外処理」「テスト不足」「パフォーマンス」などのカテゴリに分類する
3. 各カテゴリごとに代表的な指摘例を5〜10件ずつピックアップする

正直に言うと、この分類作業はかなり地道で面倒です。ただ、ここで手を抜くとAIの指摘が的外れになりやすいので、最初の一回だけは丁寧にやる価値があります。ExcelやスプレッドシートでもいいですしChatGPTに分類補助をさせるのも一つの方法です。

ステップ3：プロンプトに過去の指摘例を組み込む

分類が終わったら、いよいよAIレビュアーのプロンプトを作ります。ポイントは、指摘カテゴリごとに「良い指摘の例」を数件ずつ差し込むfew-shot形式にすることです。

例えばこんな構成です。

あなたは弊社のコーディング規約に精通したレビュアーです。
以下のカテゴリを重点的に確認してください。

【命名規則】
過去の指摘例：「boolean型の変数はis/hasで始めてください」

【例外処理】
過去の指摘例：「catchブロックでエラーを握りつぶさず、ログに残してください」

これからコードの差分を渡します。上記の観点で指摘してください。

このように過去のコメントを「お手本」として渡すことで、汎用的なAIレビューよりもぐっと自社らしい指摘が返ってくるようになります。

プロンプトに過去の指摘例を入れるだけで、AIの指摘は驚くほど「自社っぽく」なります。

ステップ4：CIやPR作成時に組み込んでみる

プロンプトができたら、GitHub Actionsなどを使ってPRが作成されたタイミングでAIに差分を渡し、コメントとして自動投稿する仕組みを作ります。最初から完璧を目指さず、まずは特定のリポジトリ・特定のディレクトリだけに限定して試すのがおすすめです。

運用のイメージとしては次のような流れになります。

• PR作成をトリガーにAPIを呼び出す
• diffと過去指摘を組み込んだプロンプトを送信
• 返ってきた指摘をPRコメントとして投稿する
• 人間のレビュアーが最終判断する（AIの指摘を鵜呑みにしない）

ここで大事なのは、AIレビュアーはあくまで一次チェック役という位置づけにすることです。最終承認は必ず人間が行う運用にしておくと、誤検知があっても事故になりにくくなります。

ステップ5：フィードバックを回してプロンプトを育てる

運用を始めると、「この指摘は的外れだった」「もっとこういう指摘をしてほしかった」というフィードバックが出てきます。それを定期的に集めて、プロンプトのfew-shot例を差し替えていきましょう。

つまずきやすいポイントと対処

機密コードの扱いは最初につまずきやすい部分です。社外のAPIにコードをそのまま送ることに抵抗があるチームも多いでしょう。その場合は、機密性の低いリポジトリから試す、あるいは差分の一部だけを抜粋して送るといった工夫が現実的です。

誤検知（ハルシネーション）も避けて通れません。AIが存在しない関数名を指摘したり、規約にない指摘をすることもあります。これは事前に「わからない場合は指摘しない」という指示をプロンプトに入れておくとかなり軽減されます。

正直なところ、最初のプロンプトで完璧な指摘が返ってくることはまずありません。最初は戸惑いやすいポイントですが、何度か調整を重ねるうちに、驚くほど実用的な指摘をしてくれるようになっていきます。

まとめ

自社のレビュー履歴は、そのまま眠らせておくにはもったいない資産です。過去の指摘をfew-shot例としてプロンプトに組み込むだけでも、汎用的なAIレビューとは違う「自社らしい」指摘が得られるようになります。まずは1つのリポジトリ、数十件のコメントからで構いません。今日集められる範囲のデータから、小さく試してみてはいかがでしょうか。