書く速度と読む速度の差が生む AI 時代のレビュー負債をどう返すか

レビュー負債は、読む量を増やしても返せません。返せるのは、出す単位を小さくするか、機械に落とさせるか、そもそも起きないように権限で縛るかの 3 つだけです。

AI コーディングツールを使い始めて最初に壊れるのは、書く速度と読む速度の釣り合いです。生成側は数倍になりますが、人が差分を読んで妥当性を判断する速度は変わりません。差が埋まらないまま溜まっていくものを、ここではレビュー負債と呼びます。

根拠はツールの仕組みに置きます。以下は Claude Code の公式ドキュメント(2026 年 10 月 16 日取得)の記述だけで組み立てます。

人を増やしても追いつかない

まず、並列化が負債を増やす側に働くことを確認します。公式ドキュメントは、エージェントチームについて「Agent teams use approximately 7x more tokens than standard sessions when teammates run in plan mode」と書いています。トークンは出力量の代理指標です。並列数を上げると、レビュー対象は人を増やした分より速く増えます。

レビュアーを増やす方向にも限界があります。増やせるのは読む人の数であって、1 つの変更に対して必要な文脈の量は減りません。むしろ、同じコードベースを理解している人の数が増えないまま読む人だけ増えると、判断のばらつきが増えます。

返すべきは読む側の供給ではなく、需要の側です。

返し方 1:出す単位を小さくする

差分が大きくなってから読むのではなく、大きくなる前に方向を合意します。公式ドキュメントがプラン モードを勧める理由がそのままこれです。「Claude explores the codebase and proposes an approach for your approval, preventing expensive re-work when the initial direction is wrong」。

ここで人が読むのは、コードではなく方針です。読む量は桁で小さくなり、間違っていたときに捨てる量も小さくなります。Claude Code の Plan Mode に操作と承認の流れをまとめてあります。

もう 1 つ、差分に入らないものを増やす方向があります。調査はコードを生みませんが、本体のコンテキストを埋めます。公式ドキュメントは「Delegate the exploration so only the findings come back」「The subagent reads files in its own context window and reports a summary」と書いています。調査をサブエージェントに出せば、レビュー対象は結論だけになります(サブエージェントの作り方)。

返し方 2:機械に落とさせる

人が読む前に、機械が落とせるものを落とします。これは前回の論考(実装が使い捨てになる AI 開発時代にテストが仕様の唯一の固定点になる)で扱った「落ちるものだけが固定点になる」の、レビュー工程での適用です。

注目したいのは、この発想がツール側に実装され始めていることです。auto モードの説明にはこうあります。「In auto mode, a second model, the classifier, reviews actions instead of you」。人の代わりに別のモデルがレビューすると公式が明言しています。レビューの一部は、すでに人から機械へ移っています。

フックも同じ役割を担います。2026 年 10 月の v2.1.295 で、コマンドフックと HTTP フックに onFailure: "block" が追加されました。フックが起動できない、タイムアウトする、想定外の終了コードで終わる場合に、処理を通さずブロックします。壊れた検査が素通りしないということは、機械レビューを人のレビューの前段として信頼できる、ということです(hooks で lint と format を自動実行する)。

人の目が入らない実行では、この層が唯一のレビューになります(Claude Code をヘッドレスで CI から動かす)。

返し方 3:起きないように縛る

3 つ目が、レビュー対象そのものを減らす方法です。実行されなかった操作はレビューの必要がありません。

ここで効くのは、モデルへのお願いではなく権限です。公式ドキュメントは「Permission rules are enforced by Claude Code, not by the model」と書き、プロンプトや CLAUDE.md の指示は「what Claude tries to do」は変えても「what Claude Code allows」は変えない、と続けます。

実務的には、レビューで繰り返し指摘している内容を deny か ask に変換します。「本番の設定ファイルは触らせない」「push の前は必ず止める」は、毎回コメントで書くより 1 行の deny / ask ルールにしたほうが確実で、以後レビューの対象から外れます(settings.json で permissions を設計する)。

反論と限界

この主張は、次の条件では成り立ちません。

機械が落とせない種類の誤りが残る。 設計の妥当性、ドメインの取り違え、仕様そのものの誤りは、テストにもフックにも分類器にも落ちません。auto モードの説明も「Explicit ask rules still force a prompt」と書き、人を止める余地を残す前提で設計されています。機械レビューは人のレビューの代替ではなく、人が見る対象を絞る装置です。

小さく出すと全体の整合性が見えなくなる。 1 回あたりの差分が小さくなるほど、設計が分散していることに気づきにくくなります。だから返し方 1 は「分割する」ではなく「分割の前に方針を合意する」が本体です。方針の合意を省いて差分だけ小さくすると、負債は設計の側へ移るだけです。

縛れるのは、事前に列挙できる危険だけ。 deny ルールは知っている危険にしか書けません。新しい種類の危険は、最初の 1 回は必ずレビューで見つけるしかありません。権限設計はレビューの出力を固定する仕組みであって、入力をなくす仕組みではありません。

そもそも負債が問題にならない領域がある。 使い捨てのプロトタイプ、個人の実験、外部に影響しないスクリプトでは、レビュー負債を返すコストが成果を上回ります。この場合は「返さない」が正しい判断です。

まとめ

• 生成量は並列化で増えるが、1 変更あたりに必要な文脈の量は減らない。人を増やしても追いつかない
• 返し方 1 は、差分が大きくなる前に方針を合意すること。プラン モードの推奨理由がそのまま当てはまる
• 返し方 2 は、機械に落とさせること。auto モードの分類器は「人の代わりにレビューする」と公式に書かれている
• 返し方 3 は、権限で縛ること。実行されなかった操作はレビューの対象にならない
• 設計の誤りは落ちず、小さく出すと整合性が見えにくくなり、縛れるのは既知の危険だけ。この 3 つがこの主張の限界