INDEX

「コードレビューは人間がやるべき」という、最後の幻想

2026/06/22

全体に公開

いまさら聞けないAIエージェントと組織の新常識広木大地

観点が言葉になれば、砦は仕組みに変わる

スピードが上がった現場で、何が詰まっているか

先日、登壇したパネルセッションで、会場に問いを投げました。「コードレビューがチームのボトルネックになっている方は、手を挙げてください」と。正確な調査ではありません。ただ、会場の体感では、半分ほどの手が挙がりました。

AI が実装速度を 3倍、5倍、10倍と押し上げた現場で、次に詰まるのは、人間が変更を読む工程です。コードはどんどん生成される。けれど、その下流でシニアエンジニアが PR (コード変更の依頼) を抱えて溺れている。

「最後はシニアが見るから大丈夫」という運用は、もう成り立たなくなりました。砦の前に押し寄せる流量が10倍になったのに、守り手の数はそのまま。これでは持ちません。

「シニアが最後に見るから大丈夫」は、いつから幻想になったか

そもそも、コードレビューは何のためにあったのでしょうか。

本来は「内部の規約に則っているか」「自分たちが決めた最低限の品質を、コードの形で維持できているか」を見るための営みです。設計判断の整合をチームで揃え、属人化を防ぐためのもの。少なくとも、私が最初に教わったコードレビューはそういう設計でした。

ところがどこかの段階で、コードレビューは「最後の品質の砦」になりました。書いた本人とは別の目で確認し、バグを発見する仕組みのはずが、いつの間にか承認の儀、とでも言うべきものに変質していきました。

しかし、シニアエンジニアの頭の中で、テストコードとソースコードを並べて、本当にバグを止められるのでしょうか。一日に十本、二十本と PR が流れてくる現場で、人間の目が漏れなく検査できるはずがありません。

「シニアが最後に見るから大丈夫」という運用は、AI 以前からかなり危うい前提でした。流量が少なかったので、機能しているように見えていただけです。

その薄い前提が、AI 時代の流量で剥がれました。

コードレビューを解体する、という作業

幻想を認めると、次にやることは解体です。

シニアが PR を見るとき、頭の中で何が起きているのか。何を、どんな順番で、どこに照らして確認しているのか。これを言語化する作業が、コードレビューの解体です。

観点が言語化されると、それは AI が読み取れる入力になります。十分なルールと観点を AI に渡せば、定型化できる観点については、人間が毎回目で追うより安定してレビューが回ります。同じ観点を、同じ厳密さで、何度でも、疲れずに当ててくれるからです。

逆に言えば、少なくとも定型レビューを AI に渡せない組織の多くは、レビュー観点が言語化できていない組織です。「シニアが何を見ているか分からないけれど、あの人が承認したから大丈夫」という運用が続いている組織。ここでは、シニアが辞めた瞬間に品質が崩れます。

解体の作業は、組織にも利益があります。シニアの頭にあった暗黙の判断基準が、自動で走る検査の束、つまりハーネスのルールとして整理される。チーム全体に継承できる形になります。コードレビューの解体は、属人性を解きほぐす作業でもあります。

観点を細かく分けて並列に走らせる、スイスチーズモデルで多層に防ぐ

品質保証には、スイスチーズモデルという考え方があります。航空安全の世界で長く使われてきたモデルです。

穴の空いたチーズのスライスを、何枚も重ねるイメージです。一枚だけだと穴を貫通して向こう側が見えますが、穴の位置がずれた何枚かを重ねれば、貫通する穴はなくなる。

スイスチーズモデルの単層と多層レビューの対比

ソフトウェアの品質保証も同じです。静的解析、リンター、ユニットテスト、プロパティベーステスト (満たすべき性質を多数の入力で検査する手法)、エンドツーエンドテスト、コードレビュー、セキュリティスキャン。一つ一つは穴だらけのフィルターですが、重ねれば穴は塞がっていきます。

AI レビューを多層ハーネスとして組み立てるときの肝は、観点を細かく分けて並列に走らせることです。

たとえば、ある経営者がプロトタイプを作ってきて「セキュリティ的に大丈夫か見てほしい」と相談されたとき、私はこう動きます。まず観点を9つに分けます。権限の境界、入力検証の死角、機密値の露出経路、依存ライブラリの来歴、SSRF や SQL インジェクションといった外部からの攻撃経路、CSRF 防御、セッション管理、暗号化運用、ログと監査の妥当性。この9観点を、Codex に1つずつ割り当てます。同じ9観点を、Claude Code にも1つずつ割り当てる。合計18のセッションを並列に走らせ、独立に見つけた問題を突合する。両系統が同じ場所を指したら確度が上がる。片系統だけが指した箇所は、トリアージの候補に回します。

なぜここまで手間をかけるか。同じモデルに同じプロンプトで同じコードを長時間レビューさせると、AI も同じ思い込みをずっと引きずるからです。仕様の勘違いも、ロジックの飛びも、そのまま温存される。一枚のスライスでは、必ず同じ場所に穴が空きます。

観点を分け、別の系統のモデルを当てると、思い込みの方向がずれます。穴の位置が変わるので、層を重ねるほど、貫通する穴は減る。

人間のレビュアーがチームに1人いて、その人が全観点を頭の中で同時に走らせるというのは、シニアエンジニアへの過大な期待です。少なくとも定型化できる観点では、観点を分けて並列に当てるほうが、人間よりはるかに少ない見落としで済みます。

解体された仕事は、ハーネスに沈む

コードレビューを解体すると、何が残るのか。

観点はハーネスに沈み、組織の「当たり前の水準」として底上げされます。次の PR から、次のプロジェクトから、その観点は CI (コード変更ごとに自動検査を走らせる仕組み) が落ちて知らせてくれるものに変わります。

ここまで来ると、人間の役割は次の問いへ移ります。「次に、何の観点を入れようか」と。

これまでハードルが高くて諦めていた品質の話を、今ならハーネスに混ぜられます。テスト駆動の徹底。形式手法 (仕様を数学的に検査する手法) に基づく仕様検査。サプライチェーン攻撃の経路分析。認可境界の独立レビュー。「うちの組織にはそこまでやるエンジニアがいない」と諦めていた品質基準も、観点として言葉にできれば、AI のハーネスに組み込めます。

これが 品質とスピードの両立 の意味するところです。スピードが上がるから品質を犠牲にしましょう、ではない。観点を言語化してハーネスに沈めるから、少なくとも定型化された観点では、品質とスピードを同時に上げられる余地が生まれます。

ただし、譲れない前提があります。組織が、自分たちのレビュー観点を言葉にできること。これができないと、ハーネスに何も入りません。