AIエージェントに開発や資料作成を任せる範囲が広がるほど、「生成物をどこまでレビューするか」が課題になります。当社では、人が最終確認する前に別のAIによるレビューを挟んでおり、この記事で扱うのはその掛け方です。全件レビューすれば取りこぼしは減りますが、任せる量が増えるほど時間を消費します。かといって省略すれば品質リスクが残ります。
当社は当初「小規模で単純な変更ならレビュー省略可」という基準で運用していましたが、「小規模」の解釈が判断のたびにぶれ、基準として機能しませんでした。そこでコードレビューの一般的な知見を調べ直し、「その変更が何に触れるか」で要否を決めるチェックリストに作り替えました。この記事では、その判断基準の中身を紹介します。
背景・課題
当社ではAIエージェント（Claude Code）にコードも資料も作らせています。ただし、AIの生成物をそのままお客様や公開の場に出すことはしません。人が確認する前段として、別のAI（Codex）による客観レビューを挟む体制を組んでいました。この役割分担の体制づくりは別記事「AI 1体に全部任せるのをやめた」で詳しく紹介しています。
問題はその「掛け方」です。生成物すべてに毎回フルのレビューを掛けると、任せる量に比例してレビューの時間が膨らみます。かといってノーチェックは品質リスクが大きい。
そこで当初は「小規模で単純な変更なら省略可」という例外を設けていました。ところが、この「小規模」「単純」という線引きが、判断する人によって——そしてAIによっても——ぶれます。同じような変更が「小さいから省略」となったり「念のためレビュー」となったりして、基準として安定しませんでした。
やったこと
そこで、規模の大小ではなく「その変更が何に触れるか」で判定するチェックリストに作り直しました。ポイントは、誰が作ったか（AIか人か）ではなく、成果物の中身だけで判定することです。判定は3段階に分けています。
必ずレビューする（1つでも該当すれば）:
- 認証・決済・パスワード等の重要情報や、外部から受け取るデータの処理に関わる
- 社外の目に触れる（公開記事・お客様への提出物など）
- 失敗すると元に戻せない操作を含む（データ削除・本番環境の設定変更・外部への送信など）
- 実行やテストで事前に確認できない（実行して初めて動く設定ファイルや、公開前の文書など）
省略してよい（すべて該当するとき）:
- 単一ファイル程度ですぐ戻せる変更で、「動作を変えない」か「実行・テストで結果を確認済み」
- 上の「必ずレビューする」に該当しない
- 例: 誤字修正、動作確認用のログ追加、コード整形、社内用のメモ
その中間は、影響度（壊れたときの被害の大きさ）と発生確率（テストの有無・変更の新しさ）の2軸で判断し、迷ったらレビューします。テスト済みであることは発生確率を下げますが、影響の大きい変更をレビュー免除にする理由にはしません。テストとレビューは検出できる問題の種類が異なる、補完関係にあるためです。なお、省略側にだけ「単一ファイル程度」という規模の条件を残しているのは、規模を判定の主軸に戻すためではなく、万一判定を誤っても被害が小さく収まることを担保する安全弁としてです。
依頼の仕方も合わせて決めました。1回のレビュー対象は、当社では目安400行以下（レビュー対象が大きいほど見落としが増えるという知見に基づく運用値で、超える場合は分割して依頼）。依頼時には変更の意図と「リスクだと思う箇所」を添える。そして「重大な指摘を中心に、スタイルなど些末な指摘は不要」と明示する——この3点です。
結果
レビューにメリハリがつき、本当に確認すべき変更に集中できるようになりました。「小さいかどうか」という感覚頼みの判断がなくなり、コードでも資料でも同じ物差しで一貫して判定できます。
正直に書くと、この基準への変更は最近で、「レビュー工数が何%減った」といった数値はまだ取れていません。現時点で言えるのは、判断のばらつきが減り、掛けるべきものに漏れなく掛けやすくなり、省略してよいものに時間を取られにくくなった、という質的な効果です。
つまずきと対処
つまずきは、最初の基準を「小規模で単純なら省略可」という言葉で書いたこと自体でした。分かりやすく聞こえますが、主観に依存する言葉で、運用するとぶれます。
そこで、自分たちの感覚だけで決め直すのではなく、一般的な開発現場のコードレビューの知見を調べました。「1回のレビュー対象が大きいほど見落としが増える」「変更の意図を先に伝えると指摘の質が上がる」といったことは、実務の世界で広く知られています。それらを取り入れ、あいまいな形容詞ではなく「何に触れる変更か」という事実で判定する形に作り替えました。あいまいな言葉のルールは、書いた時点では機能しそうに見えますが、繰り返し判断する場面で使って初めて穴が見えてきます。
まとめ
今回の見直しで整理できたのは、レビューは「やるか・やらないか」ではなく「どこに集中させるか」の設計だ、ということです。全件レビューは一見丁寧ですが、量に紛れて、重要な変更への注意が薄まりがちです。重要なのは、見るべきものを取りこぼさず、省略してよいものに時間を使わない配分です。
そして運用ルールは、一度書いて終わりではありません。運用の中でぶれや矛盾に気づいたら、思いつきで直すのではなく、外部の知見も調べたうえで作り替える——その前提で持つことをおすすめします。
AIを活用した開発で品質をどう担保するか、といったご相談は受託開発サービスで承っています。気になる点があれば、お問い合わせからお気軽にご連絡ください。
