Introducing Change Stack: The first AI-native code review interfaceの意訳です。
コードレビューは18年間、大きく変わっていませんでした。私たちはそこに手を入れました。
コードレビューを数年以上経験している方なら、誰も正面から直してこなかった事実に気づいているはずです。コードレビューは、2008年にGitHubが登場して以来、本質的にはほとんど変わっていません。ファイル単位で表示され、アルファベット順に並び、最後までスクロールして確認する。この流れを年に1,000回も繰り返しています。
一方で、プルリクエストを書いた本人は、その変更を一つの流れとして理解しています。新しいデータ構造、それを扱うロジック、呼び出し元、そしてテスト。その流れは作成者の頭の中にはありますが、レビュー画面上には表現されていません。レビュアーは正しさを判断する前に、アルファベット順に並んだファイルを一つずつ追いながら、その流れを最初から組み立て直さなければなりません。
この認知負荷こそが、大きなPRが何日も放置される原因です。シニアエンジニアが500行を超えるPRを十分に見きれず、機械的に承認してしまう理由でもあります。アーキテクチャに関するフィードバックが少なく、些細な指摘ばかりが目立つ理由もここにあります。ツールはレビューの進め方に影響を与えてきました。しかも、望ましくない方向にです。
本日、Change Stackをリリースします。コードレビューのやり方を根本から見直す新しい機能です。
Change Stackでできること
Change Stackは、任意のプルリクエストを受け取り、平面的なファイル一覧ではなく、順番に読み進められるレビュー画面として再構成します。ファイルをアルファベット順に並べる代わりに、関連する変更を少数の独立したまとまりにグループ化します。それぞれのまとまりは、変更内容を自然に理解できる順序に沿って、複数のレイヤーに分解されます。これは、経験豊富なシニアエンジニアが他の人に説明するときに選ぶであろう順番です。すべてのレイヤーは、実際のdiff内の特定の行範囲に紐付いており、それぞれにAIが生成した要約が付与されます。新しいAPIの仕様、状態遷移、サービス間の呼び出し順序など、構造を図で示した方が分かりやすい場合には、Change Stackはdiffの横に図を生成します。シーケンス図、ステートマシン、ER図など、そのコードが実際に何をしているのかを最も分かりやすく表現する図をChange Stackが描画します。すべてのレイヤーに図が付くわけではありません。視覚的な補助があると理解しやすい場合だけです。
3ペイン構成では、左側に変更のまとまりとレイヤーのナビゲーション、中央にdiff、右側に範囲ごとの補足情報が表示されます。キーボード操作（「J」で次へ、「K」で前へ、「Z」で集中モード）に対応しているため、マウスに手を移す必要がありません。レビュアーはファイルを確認済みとしてマークし、特定の範囲にインラインコメントを残し、レビューの下書きを積み上げ、実際のGitHubレビューとして提出できます。これらはすべて、タブを切り替えずに完結します。
重要なのは、レビュー結果がGitHubにそのまま反映されることです。Change Stackはレビュー画面を改善するものですが、コメントや承認はチームが普段使っているGitHub上に反映されます。既存のワークフローを壊しません。
なぜ重要なのか
シニア開発者やテックリードとして、毎週複数の複雑なPRを扱うチームを率いているなら、マージ速度のボトルネックが「品質を落とさずに素早くレビューすること」にあると感じているはずです。Change Stackはこの課題に直接向き合います。コード変更を、論理的に整理されたレビューしやすい単位へ分解するためです。
Change Stackは、チームをまたいだレビューにも役立ちます。たとえば、以前自分が担当していたファイルが変更された場合や、セキュリティ上重要な処理が変更されたためにレビューへ呼ばれる場合です。以前であれば、こうしたPRでは最初の20分を「このPRは何をしているのか」を読み解く作業に費やし、その後でようやく本格的なレビューに入る、ということがよくありました。Change Stackがあれば、その把握を短時間で終えられます。たとえば、新しい呼び出し経路を示すシーケンス図や、更新されたライフサイクルを示すステートマシンによって、20分かかっていた理解の作業を30秒まで短縮できます。
なぜこの方法が優れていると考えるのか
現在のAIコードレビューツールの多くは、既存のGitHub画面の上に、より賢いコメントボットを追加することでレビューのボトルネックを解消しようとしています。しかし、この方法は逆効果になることがあります。すでに多くのやり取りがあるPRのスレッドにコメントが増えると、レビュアーの認知負荷はさらに高まります。コードの変更、人間からのフィードバック、AIによる説明を同時に処理しなければならないためです。この問題は、大きく、構造化されていないdiffではさらに深刻になります。そして、この一年でAI生成コードの量が急増したことで、問題は急速に大きくなっています。
Change Stackは、レビューの進め方そのものに対して、まったく異なるアプローチを取ります。PRの作者がdiffをどのように構成したのかを、順番に理解できる形で示すことで、レビュアーの認知負荷を下げます。さらに、必要に応じて図で理解を補助します。
実際のレビューの流れに合わせた設計
- レビューしやすいレイヤー: Change Stackは、PRを機能単位のレイヤーに分解します。これによりレビュアーは、生のファイル順ではなく、変更の意図に沿って内容を辿ることができます。
- 図（役に立つときだけ）: レイヤーには、実際の処理の流れ、状態の変化、データの関係、スキーマの変更などを表すMermaid図を含めることができます。シンプルなレイヤーはテキストのみで表示されます。
- レイヤー単位のdiff: 各レイヤーは、自身に属するコード範囲を前後の文脈とともに表示します。これにより、レビュアーは説明されているPRの該当箇所に集中できます。
- 表示位置に連動する要約: レビュアーがレイヤー内をスクロールすると、画面右側の領域で、現在表示しているコードに対応する要約がハイライトされます。
- スナップショット履歴: Change StackはPRごとにスナップショットを保持し、レビュアーはスナップショットセレクタから表示を切り替えられます。
- 古い表示への警告: PRが表示中のスナップショットより先に進んでいる場合、Change Stackは表示が古くなっていることを示し、元になったコミットを特定します。
- GitHubにそのまま反映されるレビュー: コメントや最終的なレビュー操作（承認や変更リクエスト）は、GitHub側と同期します。
- 読み取り専用リンクの共有: 公開PRのレビュー画面は、サインインなしで開けます。コメントには引き続きGitHub認証が必要です。
- レビュアー本人としてのサインイン: GitHubのサインインフローでは、選択中のレイヤーやスナップショットを含むChange StackのURLが維持され、レビュー操作はレビュアー本人として投稿されます。
- 任意利用のワークフロー: Change StackはCodeRabbitのリンクから開きます。利用しない人にとっては、通常のGitHub PRワークフローはそのままです。
これから目指すもの
Change Stackは、より分かりやすく案内されたレビュー体験の第一歩です。コードレビューは、何が変わったかを示すだけでなく、なぜ変わったのか、どこに注目すべきか、それぞれの判断がより大きなシステムの中でどう位置づけられるのかを、チームが理解できるようにするべきです。私たちは、diffを読み解く作業ではなく、ソフトウェアがどう進化していくのかを追体験できるレビューを目指して開発を進めています。
diffは18年間、大きく変わっていません。そろそろ変わるときだと、私たちは考えています。
Change Stackは期間限定で、すべてのユーザーが無料で利用できます。次にキューに入る大きなPRで、ぜひ試してみてください。「Review Change Stack」ボタンは、CodeRabbitのPRサマリーコメント内にあります。
