コードレビューの問題は、ほとんどのチームが思うよりも早く変わり始めている

数年前、ソフトウェアエンジニアリングの最大のボトルネックは通常 implementation だった。

しかし今、AI 支援の開発が普及し始めた後、本当のボトルネックは静かに移動している：

もはや「コードを書き出す」こと自体ではなく、「何が変わったかを理解する」こと。

これはコードレビューをするときに非常に明確に感じる。

コードが特別に悪いからではない。

エージェントが特別に信頼できないからでもない。

多くの異なるリポジトリ間で PR をレビューし始めると、全体のレビュー体験が本質的に違う感じになり始めることに気づくからだ。

本当に難しい部分はもはや：

• 構文
• 実装の詳細
• ビジネスロジックさえも

ではなく：

context reconstruction（コンテキスト再構築）

だ。

そして AI が普及すればするほど、この問題はより顕著になる。

「おかしい」と感じ始めた瞬間

ある日、短時間で複数の異なるリポジトリの PR をレビューした。

個々の PR を見ると、実際にそれほど悪くはなかった：

• 構造がクリーン
• チェックがすべて通過
• 命名が合理的
• ロジックも一貫しているように見える

AI 生成のコードの多くは表面上、人間が書いた過去のコードよりも「整理されて」いさえする。

しかし複数のリポジトリをレビューした後、あることに気づき始めた：

「PR の実際のスコープ」に対する把握感を失い始めていた。

diff が大きいからではない。

リポジトリを切り替えるたびに、メンタルモデルを再構築しなければならないからだ：

• アーキテクチャの前提
• ランタイムの制約
• 歴史的な規約
• デプロイの影響
• 所有権の境界
• トレースの振る舞い
• SSR/クライアントの分離
• フィーチャートグルのパターン
• リリースの安全性の前提

そこで気づいた：

本当に高コストなのは、コード自体ではない。

それは：

限られた時間内に、安全にレビューするのに十分なほど operational context を再構築できるか。

そして最近の AI 支援開発の議論の多くも、同じことを指し示し始めている：

AI は実装の速度を上げたが、人間のレビュー能力は同期して上がっていない。

AI はエンジニアリングのコスト構造を変えた

以前コードレビューが機能していたのは、implementation 自体が高コストだったからだ。

人間はそれほど速くコードを書けなかった。

これが自然に制限していた：

• PR の数
• PR のスコープ
• アーキテクチャの広がり

レビュアーはそのためゆっくりリポジトリへの親しみを積み上げられた。

しかし AI 支援の開発は全体の方程式を変えた。

今：

• implementation が安くなった
• scaffolding がほぼ無料
• boilerplate がほぼ instant
• 反復コストが大幅に下がった

しかし review attention は一緒にスケールしていない。

人の認知帯域幅はほぼ変わっていない。

そこで奇妙な不均衡が生まれる：

Anthropic は最近直接こう言っている：

「コードレビューはボトルネックになり始めている。」

AI コードの最大の危険は「もっともらしく見える」こと

AI 生成コードには危険な特性がある：

通常「正解のように見える」のだ。

• 構造が合理的
• 命名が正常
• パターンが一貫して見える
• フォーマットが美しい

これが心理的な錯覚を生む：

レビュアーが「skim review」を始めやすくなる。

視覚的にコードが「問題ない」ように見えるから。

しかし本当に難しいのは operational correctness だ。

特に multi-repo organization の中では。

本当に問うべき問いは：

• これは system assumption に違反していないか？
• これは tracing consistency を壊さないか？
• SSR の振る舞いが subtly break しないか？
• ownership boundary がバイパスされていないか？
• rollout リスクは何か？
• historical architecture decision と衝突しないか？

これらは構文レベルの問題ではない。

それは：

context reconstruction の問題だ。

最近の研究では、コンテキストが多すぎるとレビュー品質が向上するのではなく、reviewer の attention の希薄化を引き起こす可能性があると指摘されてさえいる。

今、本当のボトルネックはコード自体ではない

後になって気づいた：

現代のコードレビューは本質的にコードをレビューしていない。

それは：

限られた認知バジェットの中で、変更の意図を検証するのに十分なシステム理解を再構築すること。

この 2 つは大きく異なる。

なぜなら従来のコードレビューフローには暗黙の前提があるからだ：

レビュアーは diff から意図を自分で reconstruct できる。

しかし AI 支援の環境では、この前提が急速に崩壊しつつある。

特に：

• リポジトリが大きく
• 所有権が断片化し
• 実装スループットが大幅に増加し
• PR の数が急増する

ときに。

なぜ Multi-Repo レビューが特に崩壊しやすいか

単一リポジトリの親しみはまだかろうじて成立する。

しかし multi-repo organization は問題を大きく増幅する。

各リポジトリには独自の hidden context がある：

• デプロイワークフロー
• ランタイム環境
• オブザーバビリティの前提
• CI ルール
• アーキテクチャの歴史
• ビジネスの重要度
• 運用リスク

リポジトリを切り替えるたびに、エンジニアリングのキャッシュ無効化のようなことが起きる。

レビュアーは再ロードしなければならない：

• 用語
• パターン
• 依存グラフ
• リスクモデル

最終的に危険な状態が始まる：

PR はまだレビューされている。

承認はまだ通っている。

パイプラインはまだグリーンだ。

しかし実際の architectural verification の深さはすでに下がり始めている。

そしてこのことは表面上通常は見えない。

多くの自動化は実は間違ったレイヤーを解決している

多くのチームが追加し始める：

• lint
• 静的解析
• AI レビュアー
• セキュリティスキャナー
• PR サマライザー

これらはすべて有用だ。

しかしほとんどは実際には最適化している：

mechanical validation。

本当に難しい問題は依然として：

人間は十分に速く operational intent を reconstruct できるか？

これは全く異なるレベルの問題だ。

次の本当に重要なエンジニアリング能力：コンテキストエンジニアリング

ますます感じるのは：

次の重要なエンジニアリング規律は、prompt engineering ではないかもしれない。

それは：

reviewer-oriented context engineering。

つまり：

• アーキテクチャの理解をどう圧縮するか
• cognitive warmup コストをどう下げるか
• PR の意図をどう素早く reconstruct できるようにするか
• 曖昧さをどう下げるか
• リスクをどう明確に surface するか
• 高い実装速度の中でシステムの一貫性をどう維持するか

言い換えると：

PR 自体が「コード diff」から「構造化されたレビューパケット」へと進化しつつある。

PR は Structured Review Packet へと進化する必要があるかもしれない

過去の PR：

• タイトル
• 説明
• diff
• コメント

これだけではもはや十分でないかもしれない。

将来の PR には以下が必要になるかもしれない：

## Why this exists
## User impact
## Systems affected
## Runtime risks
## Rollback strategy
## Testing evidence
## Architectural considerations
## AI-generated scope

エンジニアが劣化したからではない。

それは：

human attention が最も希少なリソースになったから。

私がますます信じる Layered Review Model

Layer 1 - マシン

マシンが担当する：

• フォーマット
• 型チェック
• lint
• 依存チェック
• コントラクト検証
• テスト
• ポリシー施行

人間はここに認知を使うべきではない。

Layer 2 - AI レビューエージェント

エージェントが支援する：

• 重複したロジック
• 疑わしいパターン
• 欠けたエッジケース
• アーキテクチャの異常
• 一貫性の違反

しかし AI レビューは：

認知負荷を下げる。

アカウンタビリティを置き換えるのではなく。

現在のフロンティアモデルのレビュー能力は、真のアーキテクチャレビューからまだ遠い。

Layer 3 - 人間のアーキテクチャレビュー

人間が本当に focus すべきは：

• システムの一貫性
• 運用の安全性
• リリースの影響
• ビジネスの正確性
• 保守性
• アーキテクチャの完全性

真に high-value な意思決定。

最後の重要な観察

業界全体がゆっくりあることに気づき始めていると思う：

AI はエンジニアリングの複雑さを排除していない。

ただ複雑さを移動させただけだ。

から：

• 実装の労力

へ：

• 調整
• レビュー
• 一貫性
• オブザーバビリティ
• アーキテクチャの明確さ

へ。

そしてコードレビューは、このシフトが最初に症状を現し始める場所だ。

Final Thought

将来最も価値あるエンジニアは、コードを最も速く書く人ではないかもしれない。

それは：

• システムの一貫性を維持する
• レビューの品質を維持する
• コンテキストを効率的に圧縮する
• 組織がエンジニアリングの理解をスケールするのを助ける

人だ。

なぜなら：

コード生成が十分に安くなったとき、一貫性こそが本当に高価なものだから。

参考文献

• Anthropic のコードレビューボトルネックに関する議論 Anthropic says code review has become a bottleneck
• AI 支援コードレビューとレビュアー過負荷の研究 LLM-Based Code Review Research (arXiv)
• スケールするモダンなコードレビューの実践 Code Review Best Practices That Scale
• AI 支援レビューの落とし穴の議論 AI-Assisted Code Review: Opportunities and Pitfalls
• 一般的なエンジニアリングレビューワークフローのガイダンス Best Code Review Practices