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