Harjot Gill
July 21, 2026
2 min read
英語版の記事の日本語訳です。
コーディングエージェントは、ソフトウェア開発における「希少なもの」を変えました。
もっともらしい変更を作る時間は短くなっています。それでもチームは、その変更を受け入れるべきか、システムをどう変えるのか、次に何を作るべきかを決めなければなりません。テストが通っただけでは、これらの問いに答えられません。
この差が、説明可能性のギャップです。モデルは、より多くのコンテキストを扱い、並列に作業できます。人の理解は同じようには伸びません。ボトルネックは、コードを作ることから、その方向を決められるほど深く理解することへ移ります。変更を説明できなくなると、チームはシステムを形作る側から、生成物を受け入れる側へ回ります。
多くのレビュー画面は、ファイル、行、コメントという最も低いレベルから始まります。これらは欠かせない根拠です。ただし、1つのシステム変更がルート、プロバイダー、テンプレート、テスト、設定を横断するとき、出発点としては適していません。
レビューには、より高い抽象度が必要です。ただし、要約を信じるだけでは不十分です。意図からシステムの挙動へ、さらにコードへと下り、すべての主張をdiffまで追跡できる経路が必要です。
レビュアーの仕事は、変更ファイルを数えることではありません。答えるべき問いは別にあります。
テスト、静的解析、エージェントは、実装の細部をさらに検証できます。それでも、境界は妥当か、トレードオフに価値があるか、システムをどの方向へ進めるかは、人が決めます。
変更のモデルを持てなければ、レビュアーに残るのは承認か拒否だけです。モデルがあれば、設計を改善し、前提を疑い、その変更を次の判断へつなげられます。
レビュアーが毎回ファイルツリーから変更を組み立て直すべきではありません。この作業には時間がかかり、各自が別の解釈を作ると議論も難しくなります。レビューは、チームが一緒に検証できるモデルを示すべきです。
リポジトリのパスは、コードがどこにあるかを示します。しかし、複数のファイルがなぜ一緒に変わったのか、どのファイルから読むべきかまでは説明しません。
リポジトリは実装単位でコードをまとめます。レビュアーは、挙動と判断の単位で考えます。1つの挙動が、ルート、プロバイダー、設定、テンプレート、テストを横断することもあります。
diffは正確な根拠です。そこに、有用な読む順序が必要です。
TanStack/cliのプルリクエスト#490は、目的はシンプルですが、実装は広範囲です。認証、環境変数、テンプレート、パッケージ設定、テストにまたがる45ファイルが変更されました。
GitHubでは、45のファイルから読み始めます。Change Stackでは、同じdiffを、関連するシステムの挙動に沿った6つのパスにまとめます。どちらもコードは変えません。変わるのは出発点です。
1つのdiffに、ファイル構造とシステムの挙動という2つの読む順序があります。
GitHubはファイルと行の正確な履歴を残します。レビュアーが確認できなければならない根拠です。
Change Stackは、関連する挙動に基づいて読む順序を提案します。各パスから元のコードを開けます。
2つの画面は、別の問いに答えます。GitHubは「コードがどこで変わったか」を示します。Change Stackは「どの変更を一緒に判断すべきか」を提案します。
6つのパスは、PRに対する結論ではありません。どのコード範囲を1つの思考単位として扱うかという主張であり、レビュアーはその主張自体を疑えます。
Change Stackの1つのパスは、10のファイルを1つのサインインフローとして結びます。レビュアーが判断すべき挙動は、どの1ファイルにも収まりません。ルート、プロバイダー、コールバック、設定、テストの間に存在します。
10ファイルが1つのリクエスト経路になります。実装を開く前に、制御の流れを示します。
この図は、コードと照らして検証するためのモデルです。最初の問いは「これはどんなフローか」ではなく、「このフローは正しく、完全で、安全か」になります。
作成者、レビュアー、メンテナーは、diffから別々の解釈を抱えるのではなく、同じフロー案を見ながら疑問を出せます。
きれいな要約で終わるなら、抽象化は簡単です。難しいのは、根拠まで追跡できることです。
このレビューでは、PRから変更レイヤーへ、レイヤーからシステムのフローへ、さらに意味単位、ファイル、行へと移動できます。レビュアーは、挙動を高い視点で判断し、それぞれの主張を実装と照らせます。
視点を上げて意図と挙動をつかみ、視点を下げてコードと照らします。両方向へ移動できて初めて、抽象化が役立ちます。
各レベルには1つの役割があります。意図は変更の理由を、システムの挙動は部品の関係を、レイヤーはレビューの境界を示します。意味単位は関数、ルート、型を特定し、ファイルと行が根拠になります。
上のレベルをなくすと、レビュアーは座標からシステムを組み立て直さなければなりません。下のレベルをなくすと、確かめられない説明を信じるよう求めることになります。
コーディングエージェントの生成量が増えても、大きなdiffや長い要約だけでは作業を管理できません。どちらも、レビュアーにシステムの再構築を任せます。役に立つモデルは、確かめ、直し、議論できます。
レビュー画面に必要なのは、きれいな要約ではなく、スタックです。各レベルが別の問いに答え、すべてのレベルがコードへつながります。
どの表現も、それだけでは十分ではありません。意図、挙動、正確な根拠の間を、つながりを切らずに移動できることに価値があります。
目標は、読むコードを減らすことではありません。ゼロからモデルを作る代わりに、筋の通ったモデルをコードと照らすことへ時間を使うことです。機械が変更を整理し、経路を示します。モデルは正確か、境界は妥当か、その方向へ進む価値があるかは、人が決めます。
diffは今も根拠です。スタックは、その根拠を判断に使える形にします。
