Explainable PRs and smarter reviewer routing in CodeRabbitの意訳です。
CodeRabbitのPR概要（ウォークスルー）に、最近、2つのアップデートが入りました。この2つを組み合わせると、ウォークスルーの役割そのものが大きく強化されます。1つはPRの読み方を変えるもので、もう1つはレビュアーの振り分け方を変えるものです。
それぞれフローの異なる部分に位置していますが、目指す方向は同じです。ウォークスルーは、PRをただ説明するだけでなく、PRの意図を伝えるべきだという考え方です。フラットな差分は単なる説明にすぎません。提案レビュアーをただ並べたリストも同様です。どちらも、変更を本当に信頼するためにも、適切な人にレビューしてもらうためにも、十分とは言えません。
今回の2つのアップデートは、その課題に応えるものです。
レイヤーベースのウォークスルー: PRを実際の構造に沿って読む
PRを開きます。ファイル一覧はアルファベット順に並んでいます。
api/ db/ services/ tests/ utils/ web/
スクロールしながら、何が起きたのかを頭の中で再構築していきます。マイグレーションが起点だったのか、それともAPI変更の後に追加されたのか? この新しいサービスは、下流の型変更を引き起こしたのか、それともその結果なのか? テストはどこに位置付けられるのか?
これがフラットな差分のコストです。変更を読む順番は、変更が実際に行われた順番とも、依存関係とも一致していません。そのため、毎回PRの最初の数分間を、評価に入る前の整理作業に費やすことになります。
AIが書いたPRでは、この問題はさらに深刻になります。AI生成のPRは規模が大きくなりがちで、一度に多くのファイルに触れるため、頭の中で再構築する必要が増えます。しかも、間違えたときの代償も大きくなります。隣に座って「何を考えていたのか」と聞ける人間がいないからです。
私たちは以前、説明可能性 (explainability)について書いたことがあります。重要な仕事を担うAIシステムは、自分の判断過程を見せなければ、信頼は決して生まれない、という考え方です。
フラットな差分は、まさにその対極にあります。何が変わったかは伝えてくれますが、その変更がどう考えられたのか、何が何に依存しているのか、全体が筋の通った形になるためにどの順番で物事が起きる必要があったのかは教えてくれません。
それを読み解く負担は、PRを開いた人にすべてのしかかります。
レイヤーベースのウォークスルーは、これに対するCodeRabbitの答えです。アルファベット順のファイル一覧ではなく、CodeRabbitが変更の組み立て方を逆算し、論理的なレイヤーに整理します。何が最初に変更され、次に何が来て、何が何に依存しているのか、という観点です。典型的なPRウォークスルーは、たとえば次のような順序になります。- データモデルとスキーマの変更
- 新しいモデルを使うバックエンドのロジック
- 新しい形式を外部に返すAPIレスポンス
- 新しいレスポンスを読み取るフロントエンドやクライアント側
- 上記をカバーするテスト
各レイヤーには、そのレイヤー内の変更に絞ったサマリーが付きます。全体の流れを把握したい場合は上から順に読むことができますし、自分のレビュー観点に合わせて該当レイヤーへ直接飛ぶこともできます。セキュリティ担当ならまず境界部分を、フロントエンド担当ならレスポンスまわりを見たい、といった具合です。
これは、変更を書いたのが人間でもAIエージェントでも、同じように機能します。ただし、本領を発揮するのはAIのケースです。作者に「何を考えていたのか」と尋ねられないからこそ、ウォークスルーが代わりに作業内容を示す必要があるのです。
レイヤーベースのウォークスルーは、CodeRabbitがそれを実現する方法です。
提案レビュアーの指示: CodeRabbitが「誰が何をレビューするか」を決める
CodeRabbitには、以前からウォークスルー内に提案レビュアー機能がありました。提案はGitの履歴とコードオーナーシップを基にしており、「そのファイルの適切なレビュアーは、最近そこを触っている人だ」と言える、安定したコードベースでは十分に機能します。
ただし、次の2つのケースではあまりうまく機能しません。
適切なレビュアーが、最近のコミッターではないケース。たとえばその領域の専門家、つまり
auth/配下ならセキュリティチーム、マイグレーションならデータ基盤チーム、インフラ変更なら今週オンコールのSRE、といった場合です。適切なレビュアーが個人ではなく、チームであるケース。
提案レビュアーの指示 (Suggested reviewers instructions)を使えば、これらをCodeRabbitのYAMLファイルに直接書けます。レビュアー、つまり個人ユーザーやチームを、アサインすべき条件に対応付けられます。
リストが空の場合、CodeRabbitはこれまでどおり、過去のPRに基づく既存の提案にフォールバックします。チームの事情に合わせて、網羅的に書くことも、絞り込んで書くこともできます。
いくつか押さえておきたい細かい点があります。
- GitHubではチームハンドルが利用できます。GitLabではグループハンドルは無視され、個人ユーザーのハンドルだけが解決されてアサインされます。
auto_assign_reviewers: trueと組み合わせれば、CodeRabbitが提案された人たちに実際にレビュー依頼を出すようになります。ウォークスルーに名前を並べるだけでは終わりません。
試してみる
PRを開くたびに、変更の順番を頭の中で組み立て直していたのなら、レイヤーベースのウォークスルーがその負担をかなり軽くしてくれるはずです。
「プラットフォームチームの誰か、これ見てもらえますか?」というSlackメッセージを何度も書いていたなら、suggested_reviewers_instructionsがその役目を引き受けてくれます。
