HERPでジョブミルを開発している岩下です。
直近チーム内のコードレビューに課題感があり、試行錯誤したところ良い落とし所が見えてきたので紹介します。
AIで生産量は増えた、でもレビューがボトルネックに
AIによってコードの生産量は爆増したものの、レビューがネックになっているのはどこも同じだと思います。
最近では agentic なコーディングも浸透してきて、この傾向がより顕著になってきた印象があります。
巷では
- レビューで担保すべきモノを整理する
- Lint/Skill/Test でガードレールを整備する
などなど、各社様々な対応を取っているようですね。
私の所属しているチームでも例に漏れずこの問題に直面しています。
現状はレビューのやり方・方針も大きくは変えておらず、PRの増加に伴いレビューの負担も増えている状態でした。
AIレビューを試してみたけどしっくりこなかった
AIによるレビューをいくつか試してみましたが、あまりしっくりきませんでした。
手始めに GitHub Copilot を利用してみました。
が、当時はモデル性能故か的を射ていない指摘が多く、ノイズになると判断したので利用を中止しました。
コーディング性能が高いとされる Claude Code Action も試してみました。
Copilot に比べコード理解度や指摘内容の品質は高いものの、プロジェクト特有のコンテキストは与えていないため、人間によるレビューと比較すると見劣りする部分がありました。
素の AI は、人間が見落としがちなミスを検出したり、一般的なプログラミングセオリーに基づいた指摘をすることは得意です。
一方で、プロジェクト固有のドメイン知識や暗黙のルールについては、 AI だけでは対応が難しい場面が多いです。コンテキストを十分に与えれば対処できますが、すべてのルールを明文化して整備するのは大変な作業です。
例えば私のチームではコードスタイルの統一を重視しています。レビューでもその観点から指摘が挙がることが多いのですが、これは厳密なドキュメントとしてまとめられているわけではなく、日々の開発の中でチーム内に醸成された共通認識の上に成り立っています。このような部分まで今の AI にいい感じに拾ってもらおうと考えるのは難しいです。
私がAIレビューに求めるもの
改めて整理すると、私がAIレビューに求めるものは2つあります。
1つ目は、素のAIが得意とする領域です。ただ正直、コンテキストを十分に汲まず邪魔なことも多い。レビューは指摘の数が多ければいいというものではなく、過不足なく的確にされないと、レビュイーも負担を感じます。
2つ目は、これまで人間がレビューしてきた領域です。プロジェクトのコンテキストを十分に把握していて、長くこのリポジトリに携わっているエンジニアが行うハイコンテキストなレビュー。そういうイメージです。
2つ目は、世にはそういった過去のレビュー資産を活用してくれるサービスがいくつかあるのでそれを使ってもいいでしょう。有名どころではCodeRabbitなど使ったことがある人も多いかもしれません。
が、せっかく手元に無限に働いてくれる優秀なコーディングアシスタントが居るので、ちゃちゃっと作ってみることにしました。
自作AIレビューツールの仕組み
リポジトリには過去数千件のPRが存在するので、それらを全て取得します。
次に、コードの diff から embedding を作り、それに対する指摘のコメントとセットにして、ベクトル DB に突っ込みます。
手軽に試したかったのでファイルベースで動く LanceDB を採用しました。
LanceDB をリポジトリに追加し、あとは Claude Code Action で PR をレビューさせる際に DB を参照させます。
PR の diff から embedding を取り、それを持って DB を検索。似た PR, diff が見つかれば、その PR をコンテキストに加えて Claude にレビューしてもらいます。
レビューコメントをつける際は、参照した過去 PR を根拠として載せることで、レビュイー側も納得感を感じられるようにしました。
結果
結果として、それなりに動くものができました。典型的な実装パターンなどは、かなりの精度で似た PR をコンテキストとして引っ張ってきて、過去レビューを活用してくれました。
また、実際に導入してみてチーム内からも良いフィードバックを貰えました。
初手のFBが速いこと、指摘の根拠を示してくれること、具体的に解消するコード例を提示してくれることも好評でした。
運用してみての気づき
一方、しばらく運用してみていくつか気づきがありました。
diff を embedding ベースで検索しただけでは、精度がそれほど良くないケースがありました。そもそも embedding に使っているモデルが用途にマッチしていない（AWS Bedrock Titan Embed Text V2）説もあり「なんか違うんだよな…」というPRを参考として拾ってくることがままあります。 diff だけではなく、 PR の description や紐づいている issue も検索の対象に加えることで、PR の目的ベースで類似 PR を拾ってくるなどの工夫が必要そうです。
まとめ
今回の自作を通して、AIレビューに何を求めるのか一定言語化できました。そして実際にやってみて、運用の難しい部分もわかりました。
これまで、車輪の再発明は避けるべきというのが通説でした。しかし近頃はそうでもないと自分は考えています。AIによって作るコストが劇的に下がった今、再発明によって得られる知識や気づきは、コスパのいいものになってきたと感じています。
今後は既存のサービスを含め AI によるレビューをより活用すべく検討していきたいです。
Discussion