レビュアーごとに指摘の観点が違い、同じアンチパターンが何度も繰り返される。ZOZOの開発基盤本部がClaude Code SkillsとAWS Bedrockで作ったPR自動レビュー基盤は、その"暗黙知の壁"を崩すために、判断基準をガイドライン化してAIに渡すという設計を選んでいる。
暗黙知のレビュー観点をNG/OKペアのガイドラインに変換する手順と、Confidence×Severityで「投稿しない」基準を作る設計、PRサイズでモデルを切り替える発想を、個人開発の運用にどう持ち帰るかまで。
ZOZOの開発基盤本部が抱えていたのは、判断の根拠がドキュメントに載っていないという壁だった（ZOZO TECH BLOG）。レビュアーごとに指摘する観点が違い、レビュー品質にばらつきが出る。新規参画者はドメイン知識をキャッチアップするまでに時間がかかる。そして厄介なことに、同じアンチパターンの指摘が、異なるPRで何度も繰り返される。
指摘の中身自体は間違っていない。問題は、その判断基準が特定の人の頭の中にしかなく、似たケースが来るたびに同じ説明を一から繰り返していたことにある。ここでのポイントは、いきなりレビューを自動化するのではなく、その暗黙知を形式知に変える一段階を先に挟んだことだ。
単にAIにレビューさせるだけでは、指摘が増えすぎてノイズになる。この設計は「精度を上げる」より「投稿しない基準を先に作る」方向に寄っている。
小規模・単一ファイルの変更にはClaude Haikuを、中〜大規模のPRにはClaude Sonnetを割り当てる。大きなPRではやり取りのターン上限も引き上げる。「軽い判定に高いモデルを使わない」という発想は、以前このブログで書いたモデル使い分けで費用を下げる話と同じ線上にある。
最初のReviewer Passは「網羅的に拾うペルソナ」として指摘候補を出し切る役に徹する。次のValidator Passは「批判的に再検証するペルソナ」として、その候補の根拠を一つずつ洗い直す。役割を意識的に分離した2段構成が、単一パスより誤検知を抑えられたという。
指摘の重大度（Severity）はImportant・Pre-existing・Nitの3段階で、確信度の閾値がそれぞれ違う（Importantほど厳しく、Nitほど緩い）。Validator Passでは「根拠コードを再読み込みしたか」「PR説明文を踏まえているか」といったチェック項目を採点し、合計値をConfidenceとする。Reviewer Passが拾い上げていても、このConfidenceが閾値に届かない候補は投稿しない。
ここが核心。この設計が効いているのは、「精度を上げる」のではなく「投稿しない基準を先に作る」方向に倒していること。指摘の的中率をモデルの賢さだけに頼らず、仕組み側でノイズの下限を切っている。
収集源は過去のPRレビューコメントだ。そこから「同種の指摘が繰り返し発生しているか」「既存ドキュメントでカバーされていないか」「チーム全体で共有すべき内容か」という3つの観点で、ガイドライン化する項目を抜き出す。
実装は、アーキテクチャレイヤーごとにファイルを分割し（責務・データ整合性・エラー設計など）、それぞれをNG例とOK例のペアで記述する。さらに「どの変更ファイルパスがどのガイドラインを参照すべきか」を対応表で管理し、AIが該当箇所だけを読みに行けるようにしている。ガイドライン更新は毎月実行するワークフローで自動提案され、書きっぱなしで陳腐化する事態を防ぐ仕組みまで組み込まれている。
記事執筆時点では運用開始から日が浅く、削減率のような具体的な数値は公開されていない。書かれているのは「ドメイン色の強い論点も自動レビューで捕捉できるようになった」「新規参画者の学習リファレンスとしても機能している」という定性的な効果にとどまる。数値を先に誇張せず、まだ検証中の部分は検証中と書く姿勢は、以前ここで扱った「AIのできました」を信じない検品文化の話とも重なる。
これだけの規模でPRレビュー履歴を溜め込んでいなくても、応用できる部分は具体的にある。