AI でコードを書く量が増えるほど、レビューの机に積まれる差分も増えます。問題は量だけではありません。AI slop ——もっともらしく見えるが中身の伴わないコード——が、レビューという仕組みの土台にある「信頼」を静かに溶かしていきます。
AI slop とは
slop は英語で、豚などに与える残飯やぐちゃぐちゃの混ぜ物を指す俗語です。転じて AI slop は、生成 AI が量産する「それらしく見えるが質の低い出力」を指します。コードで言えば、コンパイルは通り一見動くが、設計意図とずれていたり、エッジケースを踏み抜いたり、そもそも著者本人が中身を説明できない差分です。
厄介なのは、slop が 一見すると正しいコードと見分けにくい ことです。明らかなゴミなら一目で弾けます。slop は「読んでみないと分からない」から、レビュアーの時間を確実に奪います。
レビューは信頼の上に成り立つ分業
コードレビューは、著者とレビュアーの分業です。そしてこの分業は、ある暗黙の信頼で回っています。
著者は、自分が出す差分の中身を理解し、最低限の検証を済ませている。
レビュアーはこの前提があるからこそ、全行を疑わずに要点だけ見られます。著者が 9 割の確信を持って出すから、レビューは「最後の 1 割」を詰める作業で済む。この信頼が、レビューを現実的な時間で回す潤滑油です。
AI コーディングは、コードを 生成する コストを劇的に下げました。一方で、出てきたものが正しいかを 検証する コストはほとんど下がっていません。両者の差が開いたぶん、「とりあえず生成して投げる」が割に合うようになります。
slop は信頼ゲームの裏切り
著者には 2 つの手があります。
| 手 | 中身 | その場では |
|---|---|---|
| 握る | 生成物を自分で読み、採点し、理解してから出す | 遅い・面倒 |
| 投げる | slop をそのままレビューに流す | 速い・楽 |
レビュアーが著者を信頼している限り、投げるほうが得 です。レビュアーが「どうせ理解しているはず」と細部を流せば、slop はすり抜けます。これは 囚人のジレンマ と同じ構造です——各人にとって楽な手(投げる/流す)を選ぶと、全体では最悪の結果(質の低いコードが通る)になります。
しかも信頼は、繰り返しの中で更新されます。slop を一度通されたレビュアーは学習します。次からは全行を疑い、細部まで質問し、CI を増やす。レビューは遅く重くなり、チーム全員のコストが上がる。一度の裏切りで、お互いを信頼して速く回す協調の均衡から、すべてを疑う不信の均衡へ滑り落ちる。そして一度落ちると、戻すのは難しい。
信頼を守る側に立つ
理屈が分かれば、守り方も決まります。鍵は、著者が「生成者」ではなく「採点者」であり続けること です。
- 出す前に自分で読む。説明できない差分は出さない。AI に書かせても、最終的な責任は著者が握る(前の記事「AIとの分業設計」で言う「握る」側)。
- 差分を小さく保つ。巨大な PR は slop を隠す。レビュアーが採点できる粒度に割る。
- 機械で弾けるものは機械で弾く。テスト・型・lint・CI を信頼の代わりに置き、人間のレビューを「信頼の最後の砦」にしない。
- 「AI が書きました」を免罪符にしない。誰が書いたかではなく、出した人が中身を保証する——その規範をチームで共有する。
まとめ
- コードレビューは「著者が中身を理解している」という信頼の上で回る分業。
- AI slop は生成コストだけを下げ、検証をレビュアーに丸投げする。これは信頼ゲームの裏切りで、一度通ると不信の均衡へ滑り落ち、全員が遅くなる。
- 守る鍵は、著者が採点者であり続けること。小さな差分と CI で信頼を機械化し、人間のレビューを最後の砦にしない。