AI生成コードのレビュー体制、自動チェックに渡していない情報を誰が供給するか

AI生成コードのレビュー体制でレビュアを増やす前に確かめるべきは、自動チェックをすり抜けた欠陥のうち、そこに情報を渡していれば捕まえられたものがどれだけあるかである。AI生成コードのレビューを扱う記事で今回の偵察で上位に出たものは、GitHubの手順書から製品ベンダーのガイドまで、検査を何に任せるか——人が読むか、AIレビューツールを入れるか、静的解析を先に通すか——という軸で書かれていた。足りないのはその手前の問いである。本稿は、自動チェックに渡していない情報を誰が供給するか、そして渡しようがない判断を誰が持つか、という2つの割り当てに絞る。

AIでコードの量が増えると、レビューはどこから詰まるのか

具体的な場面から入る。EveryのメールアシスタントCoraを手がけるKieran Klaassenは、朝ノートPCを開くと、エージェントが夜のうちに出した緑のプルリクエストの山があり、最初の会議の前にマージできる状態の機能が並んでいる、と書いている。彼の工程では、レビューの段階が複数のレビューエージェントを並列に展開し、それぞれが別の種類の問題を探す。

それでも、ある変更は検査を全部すり抜けた。Coraのメールカードを開くアニメーションが、クリックした画面中ほどからではなく画面上部から滑り込んでいた。Klaassenはこう書いている——そのプルリクエストは自動検査をすべて通過しており、レビューエージェントには指摘として残すものが何もなかった、と。彼がそれに気づいたのは、アプリを開いてカードをクリックしたときである。

重要なのはその後だ。彼がその違和感を口に出し、エージェントが直し、その判断は規則として書き戻された。同記事は、次にカードを含む機能を作ったとき、エージェントは既定で正しい向きのアニメーションにしたと書いている。つまり書き戻しが効いたのは作る側で、レビュー側の自動チェックが同じ欠陥を取れるようになったとは書かれていない（AIエージェントが書いたコードの品質は誰がどう上げるのか ― 「Polish」と判断ルール化の複利構造）。

同じ記事は、この話を能力の限界の話としても書いている。アニメーションはエージェントがまだ苦手とするものだ（ただし時間とともに良くなる）、と著者は明記している。さらに踏み込んで、画面上のものが自分の作ろうとしたものと一致しているかはエージェントには決められないので、この工程にはエージェントを置いていないとも書く。計画書は「雑誌のような見え方にしろ」とは指示できるが、ページの密度がちょうどよくなった時点は指示できない。見て自分で決めるしかなかった、というのが著者の記述である。

ここから2種類の仕事が分かれる。 渡せば次から効く情報と、渡しようがなく毎回人が決めている判断である。前者は書き戻す工程を作れば積み上がる。後者は積み上がらないので、誰がいつ持つかを割り当てるしかない。AI生成コードの急増が開発インフラとレビューの仕組みに圧力をかけているという論点は、OpenAIのインフラチームへの取材記事でも挙がっている（ただし当媒体が確認できたのは告知文のみで、取材の中身は裏が取れていない。AI生成コードの急増で、コードレビューはどう再設計されるのか——OpenAIインフラチームへの取材が挙げる3つの圧力）。量が増えること自体は前提でよい。本稿が引く元記事の一つも、AIが人のレビューより速く変更を生み出すようになったと書いている。問うべきは、その前提のうえで2種類の仕事がどう配分されているかである。

どの失敗の基準が、先に書けないのか

コードレビューの基準がすべて後出しになるわけではない。型の不整合、既知の脆弱性の類型、規約違反は先に書ける。先に書けないのは、製品としての良し悪しに関わる基準のほうだ。

4,500人以上のPMとエンジニアにAI評価を教え、50社以上のAI企業を支援してきたHamel HusainとShreya Shankarは、賃貸アシスタント製品の本番トレース100件に対して、自動評価ツールとコーディングエージェントをかけた。トレースとは、1セッションの記録のことで、利用者の入力からシステムの途中処理、最終出力までを含む。結果は得意・不得意・副作用の3方向に分かれた。トレースの中を見れば分かる失敗——ツールの出力と矛盾する回答など——は得意で、人間が見落とす問題も見つけた。一方、製品としての判断とトレースの外にある文脈を要する問題は見逃した。そのうえで、良い応答を失敗として挙げるノイズも出した（AI製品の失敗パターンをどう見つけ出すか、メトリクス先行がハマる罠）。

見逃した例として著者らが挙げるのは、予算を理由に会話を打ち切ろうとした見込み客に対し、アシスタントが礼を述べて会話を閉じたやりとりである。ほとんどのエージェントはこれを成功と見る。だが製品の目的は成約の支援であり、ここでは同じ会社の安い物件や別の物件を探して提案すべきだった。そして著者らは、この「異議対応」という失敗の種類を事前にエージェントへ指示していれば自動で拾えたはずだが、指示に入れるべきだと分かったのはそのトレースを自分たちで読んだ後だった、と書いている。

“You can explain those standards to the agent, but you often only discover them in the first place by reviewing the data.”

（その基準をエージェントに説明することはできる。だが、そもそもその基準に気づくのは、データを見返したときであることが多い。出典: Lenny’s Newsletter by Hamel Husain, Shreya Shankar、2026-09-22）

例を見ることで「良い」の定義が変わるこの現象を、著者らはcriteria driftと呼ぶ。注意すべきは、この文が「基準は渡せる」と「気づくのは見返したとき」を同時に言っていることだ。前半が書き戻しの可能性を、後半がその前提条件を示している。基準は渡せば効く。ただし渡せる状態にするには、誰かが先に実物を見ていなければならない。

著者らが用意したツールが、エージェントに失敗候補を出させる前に人へ10件のトレースを読ませる設計になっているのは、彼らが自動化バイアスへの意図的な安全装置と呼ぶ理由からである。目安としては100件まで読み進めることを勧めている。エージェントの初期の提案を鵜呑みにせず、意見が食い違ったところを使ってエージェントの理解を正す、というのが彼らの書き方だ。指示を渡せば一発で終わるとは書いていない。

これはAI製品のトレース検査の話であって、コードレビューの検証ではない。ただし書き戻し先の区別は移せる。Lennyの例が示すのは検査側に基準を渡す経路で、Klaassenのアニメーションが示すのは作る側に規則を渡す経路である。前者は次から検出できるようになり、後者は次から欠陥自体が出にくくなる。自分の組織でどちらに書き戻しているかは、工程表を見れば分かる。どちらにも書き戻していなければ、同じ欠陥が毎回出る。

基準を渡したあと、自動チェックに何が残るのか

たとえば2つ残る。自動チェックごとの取りこぼしと、検査の対象に映っていない状態である（先の検証が示したノイズのように、これ以外も残る）。

取りこぼしのほうには数字がある。Every CEOのDan Shipperが、新興AIラボTypeSafeのモデルJevとFable 5.1に、同じ4種類の文章検査をかけて比較した。検査項目は、動作の説明がないか、推論のつながりが欠けていないか、本来の成果が手段にすり替わっていないか、主張が出典を歪めていないか、の4つ。対象は彼がこの検証のために生成した12本の合成パッセージで、内訳は問題のない版が6本、意図的に欠陥を入れた版が6本である。

結果は、Jevが1本あたり中央値0.35秒、Fable 5.1のhigh effort設定が8.83秒で、およそ25倍の速さだった。推定コストはFableの約580分の1。そしてJevは意図的に仕込んだ7件の欠陥のうち6件を検出し、Fableは7件すべてを検出した。Jevが落とした1件は「親と職員が一緒に教える共有予定表」という一文で、予定表を教えるとはどういうことかという説明のない動作である。Jevはこれを3回の実行すべてで見逃している（AI出力の自動チェックを、どこまで安価な確率モデルに任せてよいか）。

1件の取りこぼしは傾向と呼べる数ではないし、これは文章の検査であってコードレビューではない。読み取れるのは、4種類の検査項目という同じ基準を渡されていながら結果が割れたという一点だけだ。基準を渡せば自動チェックの差が消えるわけではない。どの自動チェックがどれだけ落とすかは、自分の業務の過去の欠陥で測るしかない。Everyの評価責任者であるMike Taylor自身、Jevを本番に入れる前にもっと厳密な精度検査をしたいと留保したうえで、早期警告としては有用だと書いている。代わりの選択肢が「検査しない」だからである。同記事が想定している使い方は、速くて安い検査を作業中に何度も走らせ、問題の可能性を示されたら書き手側のモデルがその箇所を点検して直すかどうかを決める、という形である。

もう1つは、検査の対象に映っていない状態だ。差分は変更された行の一覧であり、動いている画面はそこに映らない。過去の障害とその結果入った安全装置の理由も映らない。Klaassenは、Coraが実行しようとするすべての操作を実行前に永続ログへ書き出している理由を挙げている。あるデータベースの変更でレコードIDと操作の対応が狂い、一晩で数十万件のレコードが壊れたことがあった。意図した操作のログが残っていたので、それを再生して2日で復旧できた。ゼロから作り直さずに済んだのはそれがあったからだ。コードを読めばシステムが何をするかは分かるが、なぜそう作られたかは履歴にしかない。その履歴を持たない読み手は、この安全装置の削除が簡素化なのか、あとで表面化する後退なのかを区別できない——というのがKlaassenの書き方である。なお元記事は、この履歴を人が学ぶべきものとして書いている。自動チェックに渡して効くかどうかは元記事では検証されておらず、本稿の仮説である。

Klaassenは、差分を読む動機についても率直に書いている。

“If your only reason for opening a diff—the line-by-line view of what changed—is suspicion, reading harder will not fix your process.”

（差分——何が変わったかを1行ずつ見る画面——を開く理由が疑いだけなら、もっと熱心に読んだところで工程は直らない。出典: Every by Kieran Klaassen、2026-09-08）

彼自身の文脈では、これは差分を読む目的が検証から学習へ移ったという話である。本稿はこれを、供給の議論に引きつけて読む。読む量を増やす処方は、渡していない情報を見つける行為にはなりうるが、書き戻さなければ次回も同じ欠陥が出る。なお、読む量ではなく判断そのものが人の側で劣化していく問題と、Klaassenが自分に課している4つの習慣の扱いについては、AI時代の人材育成、若手の研修を厚くする前に決めることで別に扱っている。

開発組織が最初に変えるレビューの規則は何か

決めるのは2つの割り当てである。自動チェックに渡す情報を誰がいつ見つけてどこに書き戻すか。そして、渡しようがない判断を誰が毎回持つか。手がかりは3つある。

第一に、変更の種類ごとに、供給する情報の種類を分ける。画面に触れる変更に足りないのは、動いている画面を見た人の基準である。Klaassenの工程では、対象のブランチを取得して開発サーバーを立ち上げ、編集画面の隣でアプリを動かし、自分で操作して違和感を言葉にする。なお同記事が読者に勧めている始め方は、画面のある機能から入り、基盤側は当面飛ばすというものだ。では、データの削除や復旧に関わる変更に足りないものは何か。本稿の見立てでは、そちらで効くのは画面ではなく履歴のほうで、過去の障害とその結果どの安全装置が入ったのかを読める場所に置くことになる。ただし前述のとおり、元記事はこれを人が学ぶ文脈で書いており、自動チェックに渡して効くかは未検証である。この2つを混ぜて「ユーザー目線の確認」と一語で書くと、どちらも行われない。

第二に、自動検査の緑を合格の根拠にしてよい範囲を、検査の種類ごとに決める。型チェックやlintのように判定が決まっている検査と、言語モデルによる確率的な判定は、同じ緑でも意味が違う。後者については、自分の業務の過去の欠陥を使って取りこぼしと誤検知を測ってから根拠にする。測る手順そのものは、AIモデルの評価基準の作り方、ベンチマーク56点のモデルが業務で勝つで扱った工程がそのまま使える。測っていない確率的な検査の緑は、見たことの代わりにはならない。

第三に、書き戻す先と担当を工程表に書く。見つけた基準をどこに置くかが決まっていなければ、その場で直って終わる。Klaassenの工程には、学んだことを次回のために明文化する段階が独立して存在する。同記事が読者に勧めている手順は、その機能を超えて適用できる変更が3〜4件たまった時点で、それらの好みを規則として書き起こすというものだ。自分の組織では、リスクの高い変更の種類を2つか3つ選び、それぞれについて実物を見る担当と、見つけた基準の置き場（レビューエージェントの指示、作る側のエージェントの規則、チェックリスト、テスト）を1つずつ決めるところから始められる。担当を決めないと忙しい四半期には行われなくなる——これは元記事の記述ではなく、本稿の見立てである。

そして、ここまでの3つがすべて済んでも残るのが、見て自分で決めるしかない判断のほうだ。Klaassenの密度の話がそれにあたる。この部分は書き戻しで減らないので、体制としては「誰がその目を持つか」を名指しで決める以外にない。

まとめ: 自動チェックを選ぶ前に、何を渡していないかを見る

AI生成コードのレビューで行き詰まったとき、最初に見るべきは自動チェックの数でも人数でもない。すり抜けた欠陥に対して、自動チェックに何を渡していれば捕まえられたかである。Klaassenのアニメーションは、見つけた基準を規則に書き戻せば次から作る側に効くことを示した。Jevが0.35秒・約580分の1のコストで7件中6件を取ったという結果は、同じ基準を渡しても自動チェックごとに取りこぼしが残ることを示した。そして同じ元記事は、画面の密度のように計画書では伝えられず、見て決めるしかない判断が残ることも示している。いずれも文章の検査とAI製品のトレース検査、そして1人の開発者の工程から引いた話で、コードレビュー体制の検証ではない。それでも経営が今期決められることは2つある。リスクの高い変更の種類について、渡す情報を誰が見つけてどこに書き戻すか。そして、書き戻せない判断を誰が毎回持つか。自動チェックを選ぶのはその後で、選ぶ条件には「見つけた基準を書き戻せること」が入る。