AIレビューの指摘が人の手に余るとき、どこで受け止めるのか？

PostgreSQL 19は、ベータ期間に、数え方にもよりますが8〜10個の大きな機能を差し戻しました。経緯を書いたアイゼントラウトさんが理由の1つに挙げたのが、LLM補助のレビューで欠陥が速く見つかり、直す時間が足りなくなったことです。同じ10月、Linuxのリーナス・トーバルズさんが送ったLLM補助パッチには数時間で競合状態の指摘が入りました。GoogleはOSS VRPで、製品の脆弱性報告の受付を一時的に止めています。

AIレビューを自分のPRに入れてから、指摘が溜まる一方になっていませんか？3つの事例は、AIが関わって増えたものを受け止めた場所がそれぞれ違います。AIレビューの話はPostgreSQLだけで、残る2つはLLM補助のパッチと、自動で届く報告です。一次情報で並べて、1人でレビューしている開発に当てはめるところまで書きます。

PostgreSQL 19は、直す前に機能を降ろした

差し戻しの経緯を書いたのは、PostgreSQLのコミッターでEDB副社長のピーター・アイゼントラウトさんです。10月9日のブログで、19に入っていた大きな機能のうち、数え方次第で8〜10個を差し戻し、ベータ期間のかなり遅い時期のものもあったと書いています。The Registerによると、外れた中にはSQLでグラフを問い合わせるSQL/PGQの対応があり、REPACK CONCURRENTLY は残りました。

理由は1つではありません。アイゼントラウトさんは、コードの出来が十分でなかったかもしれないこと、機能が難しすぎて間に合わなかったこと、LLMの補助を受けたコードレビュー、4〜8月のセキュリティ修正で上級開発者が手一杯だったこと、システムの複雑さ、の5つを並べ、「たぶんこれらの組み合わせ」と結んでいます。AIレビューは、そのうちの1つです。

そのAIレビューについての原文を訳すと「この手の問題がずっと速く見つかるようになり、気づけば40件ほどの欠陥報告のリストを前にしている。1件の修正が平均3行で済むとしても、1件ごとに決まった手間がかかり、時間が尽きる」。機能がコミットされたあとで、実質の品質の基準が上がった、とも書いています。

これ、マジで身につまされませんか？3行の修正は「すぐ直せるやつ」に見えます。でも再現して、直して、テストを回してコミットするまでの手間は、件数のぶんだけ積み上がります。

40件という数は、数えた結果ではない

原文は「like forty」で、「約40」という概数です。特定の機能で実際に数えた件数とは書かれていません。報道によるとThe Registerの記事では「like」が落ちて、40件の報告に直面したと読める書き方になっているので、引用するときは気をつけたいところです。

差し戻しはバイブコーディングのせいでもない、とアイゼントラウトさんは書いています。対象のコードはその書き方が出てくる前に書かれていて、増えたのは、AIのレビューで見つかる欠陥の数のほうでした。

11月19日への延期を伝えた連絡に、AIの語は出てこない

日程を動かしたのはリリースチームです。ジョナサン・S・カッツさんが10月10日に開発者向けメーリングリストへ送った連絡では、RC1は予定どおり10月15日、11月12日にRC2を足し、GA（正式版）を11月19日にするとしています。

Updated PostgreSQL RC / GA dates

Hi, The release team has a few updates to the PostgreSQL 19 release schedule to share. First, PostgreSQL 19 RC1 …

www.postgresql.org

理由として書かれているのは、リリース済みの古い版を保守するブランチ（back branch）に入った修正の量で、AIレビューには触れていません。ただ、その修正の量とAIが見つけた不具合がどう関係するのかは、この連絡からは判断できません。9月3日の連絡では10月末のGAを目指していたので、3週間ほど後ろにずれた計算です。

The Registerの見出しは延期とAIレビューを1つにまとめています。本文では、差し戻しの理由が少なくとも一部はLLMのコードレビューに帰せる、という書き方です。一次情報でAIレビューと結べるのは、差し戻しの理由の1つまでです。

トーバルズさんのLLM補助パッチに届いた、レビューの1通

こちらはAIレビューの話ではありません。LLMと一緒に書いたコードの穴を、人のレビュアーが拾った話です。

トーバルズさんは10月13日、10本のパッチ「Improve page refcount scalability」をメーリングリストに送りました。ページキャッシュから読むたびに参照カウントを増減する処理が、CPUの数だけ奪い合いになる問題への手当てです。以前から何人もの開発者が挑んできた問題で、本人は「LLMを助けにして、実際に解いてみることにした」と書いています。

数字は派手です。Ryzen Threadripperの64スレッドで、毎秒1,330万回だった読み出しが3億400万回になり、1回あたり約1万9,900サイクルが約735サイクルに減りました。ただし本人が、同じ小さな範囲を全CPUで読み続ける人工的なケースで、実際の影響はずっと小さいと書き添えています。

そして送ってから数時間のうちに、レビューの返信が届きます。送り主は、この問題に以前取り組んでいた開発者の1人、キリル・シュツェマウ（Kiryl Shutsemau）さん。読み出しの途中でfolio（ページをまとめて扱う単位）が入れ替わり、そのあとファイルサイズが伸びると、書かれていないデータを読めてしまう、という競合状態の指摘でした。確かめ直す処理を足す修正案も添えてあります。

LWNも10月14日の記事で、レビューで競合状態がすでに見つかっていて、さらに作業が要ると書いています。使ったLLMの名前は、LWNにも13日のメールにも出てきません。別のブランチ説明にClaude Codeとあるという報道もありますが、一次は確認できていないので、ここでは「LLM」とだけ書きます。

約23倍という数字が派手なぶん、穴を見つけたのが1通の返信だった点が際立ちます。パッチはLWNの記事の時点で、まだ入ってはいません。言えるのは、AIの助けで書いたコードにも、レビューで穴が見つかる段階があった、というところまでです。

Google OSS VRPは、製品脆弱性報告の入口を一時的に止めた

Googleは、OSSの脆弱性に報奨金を払うプログラム（OSS VRP）で、10月1日から製品の脆弱性報告の受付を一時的に止めました。BleepingComputerやSecurityWeekが引く声明では、理由は「自動で送られてくる報告が大きく増え、その大半が有効ではない」こと。続報は2027年の第1四半期に出すとしています。

止めたのは入口の一部です。サプライチェーンの報告、受付済みの報告、Google Cloud向けのCloud VRP、修正パッチに最大15,000ドル（約225万円）を払うPatch Rewardsは続いています。

声明の語は「automated」までで、AIという言葉は出てきません。AI生成の報告と結びつけているのは報道の側です。似た判断は前にもあり、curlは2026年1月末で報奨金プログラムを終えています。

報奨金という入口に、自動で届く報告が流れ込み、その大半が有効ではなかった。これはヤバいです。curlのダニエル・ステンバーグさんは、無効な報告を出す動機を断つために終了すると説明していました。

3つの事例で、AIが増やしたものを受け止めた場所は？

3つの受け止め方は同じではありません。PostgreSQLは出荷する範囲を減らし、GAの日程も後ろにずらしました。Googleは製品脆弱性の報告を受け取る量を減らしました。カーネルは、レビューで穴が見つかり、作業が続いています。

共通して言えるのは、AIが関わるコードや報告の流れに、人が確かめる場所、または絞る場所がどの事例にもあったことです。人数も経験もある大きなプロジェクトや企業でこうなっています。あなたのPRをレビューしているのは、何人ですか？

AI由来の指摘や変更を1人で受け止めるなら

ここからは、3つの事例から僕が考えた受け止め方です。自分のリポジトリで試した結果ではありません。

1. 今回は直さない指摘の置き場を作る

PostgreSQLの「品質の基準が後から上がった」は、AIレビューを入れた個人のリポジトリでも起きます。前なら誰にも言われなかった指摘が、PRに並ぶようになるからです。

壊れる、漏れる、データが消える類いだけをそのPRで直し、残りはIssueや TODO.md に「今回は見送り」として移す。置き場があれば、1件3行の修正が積み上がってPRが止まる事態は避けやすくなります。

2. 外せる単位で機能を入れる

PostgreSQLは機能単位で戻せました。たとえばSQL/PGQは、52のコミットを1つのrevertコミットで戻しています。機能ごとにまとめて戻せる形で入っていたのだろう、というのは僕の推測です。個人開発なら、1機能を1つのPRにまとめる、未完成の機能は設定のフラグの裏に置く。こうしておくと、指摘が積み上がったときに「直す」より先に「今回は出さない」を選べます。

3. AIに見せる入口を絞る

Googleが減らしたのは、受け取る量そのものでした。AIレビューを全PRに回せば、指摘もそのぶん増えます。認証や課金のように事故ると痛いディレクトリだけに絞る、ドキュメントだけの変更は外す、と入口で決めておけば、読む量は最初から減ります。

Anthropicのエンジニアが10月15日にclaude.devのブログへ書いたコードレビューの記事にも、AIのレビューと人の承認を段に分け、人の承認は変更のリスクに応じて0〜2人にする運用が出てきます。claude.devが公式のドメインかまでは、確認できていません。

AIレビューの最初の一歩は、見送り用のラベル1つ

次にAIレビューを回すPRで、GitHubに ai-review-later のようなラベルを1つ作ってみてください。そのPRで直さない指摘はIssueに移してラベルを付け、PRは直すと決めた分だけでマージする。ラベルを1つ作るだけなので、5分もかかりません。

1か月たってラベル付きのIssueを見返すと、AIが何を言いがちで、何を本当に直すべきだったかが、自分のリポジトリの言葉で見えてきます。PostgreSQL 19のGAは11月19日の予定なので、差し戻された機能のその後も追いかけておきたいところです。