AIコーディングツールやエージェントによって、コードの作成やプルリクエストの提出は速くなりました。PRが積み重なるなか、チームはどの変更に先に取り組むべきかを判断しなければなりません。その出発点は、各PRに次に何が必要で、誰がそれを前に進められるかを把握することです。
CodeRabbit Triageで解決しようとしたのは、この問題でした。最初はキューを整理することから始めましたが、各PRがどの状態にあるかを明確に把握できてこそ、その整理が役立つとすぐに気づきました。
並べ替えたリストだけではわからないこと
PRキューを整理する際、受信トレイという考え方は自然な出発点です。オープンなPRをセクションに分類し、対応が必要な作業をレビュアーが一か所で確認できるツールもあります。
私たちも同様の方法から始めました。しかし、すでに承認した人に対して、そのPRを「レビューが必要」と表示してしまうことがありました。また、承認済みでマージコンフリクトがあるPRを、作成者によるリベースが次のステップであるにもかかわらず、再レビューが必要なものとして表示していました。
それらのPRは、実装したフィルターの条件には一致していました。問題は、ラベルがレビュアーに何をするよう伝えていたかです。レビューしようとPRを開いた人が、次に対応すべきなのは作成者だと初めて気づくことになっていました。
こうした誤りが繰り返されると、レビュアーはキューを信用できなくなります。対応すべきか判断する前に、各PRを開いて状態を確認する手間が増え、受信トレイの有用性が損なわれます。
キュー内の位置を決める前に、各PRが次に必要とすることと、その責任者を確定する必要がありました。
PRに次に何が必要かを判断する
そのためには、まずシステムの各部分が何を判断するのかを明確にする必要がありました。初期設計では、分類、ライフサイクルの段階、優先度、健全性、準備状況、次のアクション、担当を別々の概念として扱っていましたが、その役割が重なることもありました。
実装を進めると、その重なりがより明らかになりました。誰もまだ対応できないPRでも、優先度は高い場合があります。インターフェースは、優先度と進行を妨げている要因の両方を説明する必要がありました。
ワークフローの分類と相対的な順位付けは目的が異なるため、分離しました。
- ワークフローの分類は、PRに次に何が必要かを決定します。明示的なルールが利用可能な根拠を評価し、ワークフローの状態、次のステップ、担当する役割、アクションやレビューが遅延しているかどうかを確定します。これらの判断にAIモデルは使いません。
- 相対的な順位付けは、注意を向ける順序を決定します。ワークフローの状態が確定した後、どのPRを先に確認し、どれだけ詳しくレビューするかを判断する助けになります。ワークフローの状態を変更することはできません。
分類器は次のルールを順番に確認し、最初に一致したものを選びます。
1. クローズ済み、または追跡対象外 → untracked
2. クローズ保護を確認後、取り下げを支持する強い根拠 → close_candidate
3. 明示的な高リスク、または重複・置き換え済みの根拠 → needs_decision
4. 変更要求、未解決スレッド、または古い承認 → needs_update
5. マージコンフリクト → blocked
6. ベースブランチとの差分の拡大 → needs_update
7. ドラフト状態 → needs_update
8. 必須チェックの失敗 → blocked
9. 現在の変更に対するレビューの欠如、またはレビュアーの対応停滞 → needs_review
10. それ以外では、最も有用なアクションを選択：マージ、作成者の更新、
レビュアーの対応、更新情報の取得、再開、クローズ、監視、経過観察。
PRを進めるべきかという人の判断は、機械的な修正より優先されます。そのため、needs_decisionはblockedより先に評価されます。すでにマージされた作業と重複するPRなら、コンフリクトの解消に時間を使う前に、残すべきかを判断する必要があります。変更要求も、レビュアーのフィードバックがより具体的な次のステップを示すため、検出されたコンフリクトより先に扱います。
分類器は最初に一致したルールからワークフローの状態を選びますが、該当する理由はすべて記録します。そのうえで、次のアクションを一つ、担当する役割を一つ特定します。それらが確定した後に、順位付けによってキュー内の位置が決まります。
「Other」が残っている理由
これらのルールがあっても、一部のPRにはフォールバックの分類が必要です。私たちのケースでは、Otherが低優先度のスコアだと誤解されることがよくありました。実際には、現在の根拠だけではより具体的な引き継ぎ先を判断できない場合に使う、レビューワークフローのラベルです。
最新のレビュー可能なコミットに対するレビュー記録からアクションのラベルを導けない場合、TriageはPRのワークフローの状態を使います。
- needs_reviewは、そのコミットに対するCodeRabbitの完了済みレビューが記録されていなければ「Not reviewed by CodeRabbit」、記録されていれば「Awaiting your review」になります。
- needs_update、blocked、needs_decisionは「Waiting on author」になります。
- monitorとclose_candidateを含む、それ以外の状態は「Other」になります。
Otherは、次に何が起きるべきかを正確に表すアクションのラベルがない場合にも使います。たとえば、チェックの完了待ちです。マージ前にチェックの終了を待つ必要があっても、その実行中に作成者が対応する必要はないかもしれません。
Otherを残すことで、判断できる範囲の限界が見えるようになります。より具体的なラベルには、それを裏付ける根拠が必要です。そうでなければ、対応不要な作業にレビュアーや作成者を戻してしまい、PR受信トレイと同じ問題を繰り返すことになります。
優先度の計算方法
TriageではP0からP3の優先度を使います。ベーススコアは、PRに関する検証可能な根拠を使い、決定的なルールで計算するため、同じ入力からは同じ結果が得られます。表示される優先度には、管理者ルール、CodeRabbitの判定、手動の上書きも反映されます。詳しくは優先度のドキュメントを参照してください。
計算には三つのシグナルを使います。
- 重大度 — 現在の検証済みレビュー指摘がどれほど深刻か。
- 緊急度 — リンクされたLinearまたはJiraの課題がどれほど緊急か。
- 影響度 — このPRを待っているためにブロックされている、他のオープンなPRの数。
各シグナルは0から1の値に正規化され、欠けているシグナルの寄与はゼロになります。一つの強いシグナルだけでも高い優先度になり、複数の中程度のシグナルは互いに補強し、正の根拠が追加されてもスコアが下がらないように組み合わせます。
function computePriority(s: PrioritySignals): Priority {
const impact = combine(s.severity, s.externalUrgency, s.dependencyImpact);
const score = Math.round(100 * impact);
const bucket = toBucket(score);
// 内部シグナルだけでは緊急事態と判定しない。
if (bucket === "P0" && !s.hasQualifyingExternalEvidence) {
return { bucket: "P1", score: 84 };
}
return { bucket, score };
}
計算に使う曲線と重みは調整します。計算結果のスコアは、以下の四つの優先度に対応します。
優先度は、どのPRを先に確認すべきかを判断する助けになります。一方、ワークフローの状態は、次に何が必要かを伝えます。たとえば、緊急の問題を修正するP1のPRでも、作成者がマージコンフリクトや失敗したチェックを修正する必要があるかもしれません。そうした障害はワークフローの状態に表示され、優先度スコアとは別に扱われます。
未レビューのPRにもP3のスコアが付くため、根拠の欠如には特に注意が必要です。
誰も確認していなかったPR
どんな優先度モデルでも、レビュー指摘も、リンクされた課題も、それに依存する他のPRもない場合をどう扱うか決める必要があります。私たちは欠けているシグナルをゼロとして扱うため、結果は次のようになります。
severity: 0 // 検証済みのレビュー指摘がまだない
externalUrgency: 0 // リンクされた課題がない
dependencyImpact: 0 // このPRによってブロックされているPRがない
score = 0 → P3
計算は単純ですが、結果は誤解されやすいものです。レビュアーがP3を見て低優先度だと考え、それを「誰かが確認し、懸念は少ないと判断した」と受け取るかもしれません。
そこに問題があります。中程度の影響を示す根拠があるPRが、誰も評価していないPRより上位になる可能性があります。未レビューのPRは、根拠が欠けているために低いスコアになるのです。
適当な数値を補う方法は魅力的に見えますが、私たちは利用可能な根拠にスコアを結び付けたままにしました。
- P3は、利用可能な優先度の根拠を反映します。スコアリングのシグナルが、近い将来の高い優先度をまだ示していないという意味です。P3のPRにも価値があり、慎重なレビューが必要な場合があります。
- 根拠には有効期限があります。レビュー指摘は、評価対象となったPRのバージョンに結び付きます。新しいコミットが追加されると、現在の根拠が得られるまで、古い重大度の寄与を取り除きます。
- レビュー状況は優先度と並べて表示します。レビュー済みか、誰が承認したか、作成者の対応待ちか、チェックが成功しているか、マージコンフリクトがあるかは、別々のフィールドに記録します。レビュアーは優先度と次に必要なことの両方を確認できます。
スコアへの各寄与は、レビュアーが確認できる根拠までたどれます。
モデル
CodeRabbit Triageは、リポジトリ単位のモデルを使ってPRを比較します。残りの作業量に対する価値、時間的な制約、情報の価値、手戻りのリスク、依存関係の順序、各変更に必要な人の判断の程度を考慮します。
チェックやアクティビティが似ている二つのPRでも、一方はリリースの障害を取り除いたり、他の複数の変更が依存する仮説を検証したりするかもしれません。モデルは、こうした違いを順位付けに反映します。
モデルは、リポジトリ内での順位、参考となる緊急度の評価、推奨するレビューの深さ、短い説明、PR間の関係を返します。これらの順位付けやレビュー指針の出力が、注意度の調整値を通じて決定的なベーススコアに反映されることはありません。
表示されるP0〜P3の優先度には、別の優先順位が適用されます。手動の上書きがCodeRabbitの判定より優先され、その判定は管理者ルールとベーススコアより優先されます。ベーススコアと判定は、固定のタイマーではなく、根拠が変化したときに再計算されます。現在の動作についてはTriageの優先度の仕組みを参照してください。
決定的なコードが、ワークフローの状態、次のアクション、準備状況、適格性、権限、そしてPRの変更や通知送信を伴うすべてのアクションを制御します。これらの制御を順位付けやレビュー指針から分離することで、次に誰が対応するかという振り分けを維持します。
各ユーザーには、自分向けのキューと役割に応じた次のアクションが表示されます。個人のキュー内でのPRの位置は、次のシグナルを使う別の注意度スコアで決まります。
- 次のアクションの担当者
- 引き継ぎの待ち時間
- 最近のアクティビティ
- 待機による圧力
- 関与の度合い
- 影響度
- レビューの作業量
この計算には、リポジトリ内の順位とモデルの出力は含まれません。PRは、その人の責任と対応の必要性に応じて、個人のキュー内で上位に移動します。
その責任は、実際のアクションにも及びます。Triageはレビュアーを提案し、選定理由を説明できます。レビューの依頼、Slackでの通知、接続先プラットフォームでのPR状態の変更には、明示的な人の操作が必要です。
インターフェース
状態モデルが固まった後、グループ化、サブグループ化、フィルター、表示プロパティ、保存済みビューを中心にインターフェースを設計しました。これらの設定によって、ユーザーは知りたいことに合わせてキューを整理できます。
第一の軸：グループ化
Triageは、レビュアーがキューの優先順位を付け、作業を進めるための集中的な方法を提供します。
- ワークフロー — レビュー待ち、作成者の対応待ち、マージ可能なPRを確認します。
- 作成者 — 誰のPRが待機していて、何が進行を妨げているかを確認します。
- リポジトリ — 複数のリポジトリにまたがる、対応が必要な作業を確認します。
第二の軸：サブグループ化
サブグループ化は、各グループをさらに詳しく分類します。Priorityでグループ化し、Review workflowでサブグループ化すると、P1のグループが、人のレビュー待ち、CodeRabbitのレビュー待ち、作成者の対応が必要、マージ可能なPRに分かれます。
これは、朝の作業を始めるための実用的な出発点になります。自分に割り当てられた高優先度のレビューに取り組み、作成者の対応が必要なPRを把握し、マージ可能なものを確認できます。
別の見方をしたければ、Review workflowでグループ化し、Review guidanceでサブグループ化します。Awaiting human reviewで絞り込めば、短時間のレビューが推奨されるPRと、まとまった集中時間が必要そうなPRを分けられます。
こうしたビューは、各PRの情報が一貫していることを前提とします。P1で人のレビュー待ちとされたPRは、どこに表示されても同じ優先度と状態を示す必要があります。グループ化を変更すると情報の見え方は変わりますが、PRの基礎となる状態は変わりません。
グループ化は整理し、フィルターはキューを絞る
このプロジェクトの開始時は、フィルターに両方の役割を担わせていましたが、すぐに管理が難しくなりました。フィルターは表示するPRを決めます。グループ化は、それらのPRを整理し、レビュアーが対応すべき作業を把握できるようにします。
たとえば、一つのリポジトリに絞り込んだ後、ワークフローでグループ化すれば、レビュー待ちと作成者の対応待ちのPRを確認できます。
ビューで設定を保存する
Triageのボードやリストを設定したら、ビューとして保存できます。ビューはフィルター、グループ化、レイアウト、並び順を保持するため、毎回設定し直さずに同じ作業環境に戻れます。
Agentic Change ManagementにおけるTriageの役割
CodeRabbit Triageが扱うのは、より大きな問題の一部です。エージェントによって実装のコストが下がると、チームには検証して理解できる量を超える変更案が届きます。それでも、受け入れるコードに対する責任はチームに残ります。
Agentic Change Managementは、人とエージェントが作成した変更を扱う共通のワークフローに、これらの責任をまとめます。独立したレビューと検証から始まり、人の注意を向ける優先順位を支援し、変更がコードベースに与える影響を説明し、コミット済みのコードにまでセキュリティ分析を広げます。
Triageは優先順位を付け、各PRの次のアクションを特定します。答えるのは、次の二つの問いです。
- 今、何に注意を向ける必要があり、それはなぜか。
- 誰が対応すべきか。
レビュアーは、なぜそのPRが自分に回ってきたのか、何が必要なのか、推奨の根拠は何かを確認してから、進め方を判断できます。
キューの次のアクションを確認する
CodeRabbit Triageは、各PRの現在の状態、次のアクションの担当者、そのアクションの待ち時間、優先度の根拠を表示します。PRがキューの上位にある理由と、自分に何が求められているかがわかります。
CodeRabbit Triageは現在利用できます。キューを開いて、自分のレビュー待ち、作成者の対応待ち、マージ可能なPRを確認してください。
