AIが書いてAIがレビューしたとき、その設計やコードは誰のものになるだろうか

AIが高速にコードを書くようになった。すると当然、レビューが詰まります。 そうなると、次に出てくる発想は自然です。コードをAIが書くなら、レビューもAIに任せればよいのではないか。

この発想自体はまったくおかしくなく、むしろ合理的です。典型的なバグ、テスト漏れ、セキュリティ上の危うさ。こうした作業をAIが肩代わりしてくれるなら、レビュー待ちで詰まっていた開発フローはずいぶん楽になります。

けれど、そこで1つの問いが残ります。

AIが書き、AIがレビューし、人間が十分に理解しないままマージした設計やコードは、いったい誰のものなのでしょうか。 そのコードはリポジトリに存在しています。CIも通っている。Pull Requestだって承認済みです。見た目には何も問題がない。 では、障害が起きたとき、誰がその振る舞いを説明できるのか。次の変更が必要になったとき、誰がその設計判断を引き受けられるのか。

考えたいのは、AIでレビューを速くしたとき、レビューという営みから何が失われ得るのか、ということです。

理解負債という概念

ぼく自身、AIのレビューコメントを眺めながら「まあ問題なさそう」とapproveを押したことがあります。というか、張り切って現在進行形で押している。

Addy Osmaniは、理解負債（Comprehension Debt）を「システムに存在するコード量と、人間が本当に理解しているコード量のギャップ」と定義しています。

AIコーディングツールを深く使うチームでは、velocity metricsには現れないコストが蓄積する、という指摘です。 コードベースはきれいに見え、テストも通っている。しかし、その背後で人間のコード・システム理解は空洞化していく。

これは、従来の技術的負債とは少し性質が違います。

技術的負債は、摩擦として現れます。ビルドが遅い。依存関係が絡まっている。変更するたびに別の場所が壊れる。誰も触りたがらないモジュールがある。厄介ではあるが、少なくとも「そこに負債がある」ことは比較的見えやすい。

一方で、理解負債は見えにくいです。コードは整っている。テストはGreen。Pull Requestの件数は増えている。DORAのFour key metricsも悪くない。むしろ表面的には、開発はうまく回っているように見えます。Addyが言う「コードベースが健康そうに見える一方で、理解が静かにhollow out（内側から空洞化）していく」状態です。

AIは、人間が評価できる速度よりも速くコードを生成します。従来のレビューはボトルネックでした。けれど同時に、それは生産的で教育的なボトルネックでもあったように思います。人間がPull Requestを読み、コメントで議論を重ねることで、前提や設計判断、既存構造との整合性、変更の意図が、レビュアーの頭の中で再構成されていました。レビューは単なる検査工程ではなく、チームがシステムを理解し直すプロセスでもあったはずです。

テストや仕様だけでは、理解負債は消えない

テストを厚くすればよいのだろうか、という発想も自然です。

ユニットテスト、結合テスト、静的解析、Linter、Formatter、型検査。これらは必要です。AI生成コードを扱うなら、むしろ今まで以上に強化すべきだと思います。機械が大量にコードを書くなら、機械的に検証できるところは機械に任せた方が良い。

しかし、テストは理解の代替ではありません。

Addyはこの点をかなり明確に述べています。テストが検証できるのは、人間が思いついて仕様化した振る舞いに限られます。思いついていない振る舞いはテストに書けない。さらに、AIが実装変更に合わせて大量のテストケースを変更したとき、その変更が正しい仕様変更なのかどうかはテスト自身では判断できません。壊れた挙動に合わせてテストを書いただけかもしれないからです。

この判断には、ドメイン知識、過去の経緯、ユーザー影響、そして「このシステムでは何を守るべきか」という価値判断が必要になります。テストは理解を支えます。が、テストは理解そのものではありません。

では、仕様を書けばよいのでしょうか。

仕様は理解負債を減らす方向には働きます。けれど、理解負債をゼロにはできません。仕様は意図や制約を言語化する入口であって、実装時の判断をすべて代替するものではないからです。境界条件、データ構造の選択、性能トレードオフ、暗黙の設計判断は、どれほど仕様を書いても実装の中に入り込みます。

仕様は入口です。出口ではない。 では、その入口から出口までのあいだで、人間はどこで判断を共有していたのか。ここでレビューの話に戻ります。

そもそもレビューで共有されていたものは何だったか

テストと仕様は、どちらも理解を支える。しかし、それだけでは理解をチームに根づかせることができません。 では、従来の開発では、その理解はどこで育っていたのでしょうか。そのひとつが、レビューだったのだと思います。

従来のレビューは、単なる欠陥検出だったのでしょうか。 もちろん、バグを見つける役割があります。セキュリティリスクを見つける。テスト不足を指摘する。命名の不整合を直す。こうした指摘は重要です。

しかし、レビューで交わされていたものは、それだけではなかったはずです。

「なぜここでは抽象化しないのか」「なぜ今回は拡張性より単純性を取るのか」「なぜこの依存をここに持ち込むと、半年後に困るのか」。

これらは、単なる知識伝達ではありません。チームが何を品質とみなすか。どのリスクを重く見るか。どのトレードオフを許容するか。つまりレビューでは、チームが判断基準を同期していました。言い換えると、レビューはチームの評価関数を共有する場でした。何を良いとみなし、何を悪いとみなすのか。このチームでは、どのような設計を良しとするのか。どのようなリスクを許容しないのか。

AIレビューは、差分要約や既知パターンに基づくリスク指摘には強いです。人間が見落とした観点を補うこともあるでしょう。けれど、それは判断基準の同期そのものではありません。

AIがコメントを出す。人間がそれを眺める。問題なさそうなので承認する。こういう流れが常態化すると、レビューは「判断基準を露出する場」から「承認を効率化する場」へと変わっていきます。そのとき、チームはバグを見逃すかもしれない。だが、それ以上に、判断基準を共有する機会を失うような気がします。

AIレビューに関する問いはここにあります。レビューをAIに担わせたとき、ぼくたちは理解や判断基準をどこで編纂していくのでしょうか。

SECIモデルの循環が痩せる

この問題は、知識創造の問題としても見られます。

暗黙知は、単に「まだドキュメント化されていない情報」ではありません。Michael Polanyiが「私たちは言えること以上のことを知っている」と書きましたが、暗黙知は経験・感覚・文脈依存の判断のように、言語や文書には必ずしも落とし込めません。

暗黙知には、掘り起こせば言語化できるものもあれば、身体化された技能や組織の中で共有される審美眼のように、成果物や状況と突き合わせなければ引き出しにくいものもあります。シニアがコードを見て「なんか変だな」と感じるとき、その違和感は単なる未文書情報ではありません。過去の障害、設計の失敗、チームの規範、運用の痛みが折り重なった判断です。

SECIモデルとは、組織が知識を生み出す仕組みを説明するモデルです。ざっくり言うと、暗黙知と形式知が互いに変換し合いながら組織の中を循環する、という考え方です。

シニアがコードを見て「ここはちょっと怖いですね」と言う。そこで、「なぜ怖いのか」を話す。以前似た設計で運用がつらくなったこと。今回は拡張性より単純性を取った方がよさそうなこと。今ここで抽象化すると、かえって変更しにくくなりそうなこと。

そういう会話を何度か見聞きするうちに、別のメンバーも少しずつ「このチームでは、こういうときに何を重く見るのか」を掴んでいきます。一部はADRやレビューガイドラインに残るかもしれない。残らないまでも、次に似た変更をするときの判断材料にはなる。

SECIモデルに引き寄せて言えば、レビューは、暗黙知が少しだけ言葉になり、それがチームの中で再利用されていく場でもあったのだと思います。

AIによるコーディングとレビューの流れが強くなり、人間同士のコミュニケーションが薄くなると、この循環が痩せます。その結果、コードは増えるが、組織の判断基準は育ちません。形式知としてのコードとコメントは残ります。AIのレビューコメントも残る。けれど、人間が「なぜそう判断するのか」を自分たちの基準として内面化する機会が減っていきます。

この点は、"AI時代に消えるのは「ジュニア」ではなく、「育成を放置できる時代」なのかもしれない" の指摘とも重なります。AIによって個人のアウトプット量が増えるほど、その成果物を評価し、選び、チームとして意味のある成果に変える負荷は人間側に返ってくる。つまり失われるのはジュニアという役割ではなく、「作業していれば自然に育つ」「レビューを回していれば自然に判断基準が同期される」という前提です。

AIレビューを否定しない。理解の編纂場所を設計する

AIレビューは有用ですし、ぼくは推進側です。人間が毎回同じように確認していた観点をAIが先に洗い出してくれるなら、それは明確な効率化です。

問題は、AIレビューそのものではありません。AIレビューを、人間同士が判断基準を同期する場の代替として扱うことです。

AIに任せてよいのは、確認観点の列挙や既知パターンへの照合など、判断材料を増やす作業です。逆に人間が手放してはいけないのは、その指摘を採用するかどうかを決めることだけではありません。なぜその指摘を重く見るのか。どのリスクは許容し、どのリスクは許容しないのか。今回の設計判断を、次に似た場面でも使える基準として残すのか。そうした判断の理由を、チームの中で共有することです。

だから必要なのは「AIレビューを使うか、使わないか」という二択ではなくて、AIレビューを使う前提で、人間が理解を編纂する場所を設計することなのだと思います。AIが生成してレビューした結果を、人間が意味づけして基準として整理し、次の変更に活かせる形で残すことです。

たとえば、AIレビューは一次スクリーニングとして使う。典型的なバグ、テスト漏れ、既知の危険パターンはAIが先に洗い出す。そのうえで人間レビューでは、設計判断、リスク許容、仕様外の暗黙判断に焦点を当てます。

Pull Requestには、AIに何を任せ、人間がどこを判断したかを残します。「AIの指摘をすべて反映しました」では足りません。「この変更では、性能より単純性を優先した」「この例外は握りつぶさず、呼び出し元に返す判断をした」「この抽象化、今は入れない。ユースケースが2つ揃うまで待つ」。こうした判断が残って初めて、レビューは次の変更に活かされていきます。

何度も出てくる判断は、ADRやレビューガイドラインに昇格させる。AIレビューを導入しただけでは、組織能力にはなりません。AIレビューの結果を、チームの判断基準を更新する材料にして初めて、組織能力になります。

AIを使うほど、人間はコードを一文字ずつ書く仕事から離れていきます。けれど、人間の仕事がなくなるわけではありません。むしろ、人間の仕事は、理解を編纂する仕事へ移っていきます。

そのコードを自分たちのものにする

AIが書いてAIがレビューする流れは止まりません。止める必要もないと思っています。

コードは増える。速度は上がる。自動化はさらに進む。ただし、そのコードを誰も理解していないなら、それは本当にチームのコードなのでしょうか。

リポジトリに存在しているだけで、組織の知識にはなっていないのではないか。テストが通っているだけで、説明責任を引き受けられる状態にはなっていないのではないか。

AI時代のレビューで問うべきなのは、AIがどこまで正確に指摘できるかだけではありません。 人間がどの判断を引き受けたのか。そのレビューを通じて、何を理解したのか。何をチームの基準として残したのか。次の変更でどう活かせるようにしたのか。

この問いを手放すと、レビューはいつの間にか、ただ承認を通すためのフローになってしまうのかもしれません。 AIが書き、AIがレビューする時代に、人間が一文字ずつコードを書く場面は減っていきます。けれど、そのコードをどう理解し、どの判断を引き受けるか。次の変更に何を残すかは、依然として人間側の問いです。

リポジトリにあるコードを、チームの知識にしていくこと。タイトルの「誰のもの」という問いは、結局そこに戻ってくるのだと思います。