そのAIレビュー、指摘しているようで責任を避けているだけかもしれない

PRを開くと、AIレビューのコメントが並んでいる。命名、責務分離、例外処理、テスト不足、パフォーマンス懸念。見た目はかなり仕事をしている。レビュー欄だけ見れば、チームは品質に向き合っているように見える。

でも、現場で嫌な感じが残るPRがある。コメントが多いPRではなく、誰が何を許容したのか分からないPRだ。AIが指摘した。担当者が修正した。人間は流れを眺めた。最後に承認ボタンが押された。そこに判断の跡がない。

AIレビューが増やすのは、指摘の量だ。責任の所在は、自動では増えない。

この違和感を放置すると、レビューは静かに形を変える。人間がコードと仕様を読む場所から、AIコメントの処理状況を確認する場所へ寄っていく。指摘が消えたから承認する。チェックが通ったから進める。コメントに返信したから終わりにする。そうやってレビューは、判断の仕事から、処理済み確認の仕事へ落ちていく。

怖いのは、AIレビューの精度が極端に低いことではない。むしろ、そこそこ当たることだ。AIはそれっぽい懸念を出せる。レビュー担当者が見落としそうな観点も拾う。境界値、nullの扱い、例外処理、命名、テストケースの不足。かなり便利だ。だからこそ、人間は油断する。

便利なレビュー補助は、人間の覚悟を薄めることがある。

たとえば、AIがこう指摘する。エラーハンドリングを追加した方がよい可能性があります。担当者はtry-catchを足す。ログも出す。AIの指摘は解消される。レビュー担当者も、まあよさそうだと感じる。

でも本当に見るべきだったのは、try-catchの有無ではない。その例外は握ってよいのか。ユーザーに失敗を返すべきか。再試行する処理か。監視で検知できるか。夜間に落ちたとき誰が気づくのか。そもそも、その失敗は業務上どの程度の損失につながるのか。ここを見ないままコメントだけ消すと、レビューした気分だけが残る。

レビューとは、変更を受け入れる判断そのものだ。

この定義をチームで持てていないと、AIレビューは判断を遠ざける道具になる。AIが見つけた問題に反応しているだけなら、レビュー担当者はまだ入り口にいる。実務で価値が出るのは、その先だ。どの指摘を直すか。どれを今は許容するか。どれを設計へ戻すか。どれをリリース条件に変えるか。どれを監視とロールバックで受けるか。

AIは候補を出せる。人間は線を引く。

ここで勘違いすると、コメント数の多いレビューを良いレビューだと思い始める。PRに20件コメントが付く。担当者が10件直す。5件は説明する。残りは別チケットに回す。見た目は活発だ。でも、リリース後に障害や問い合わせが起きたとき、チームが説明できるのはコメントの履歴だけかもしれない。

なぜ通したのか。どのリスクを許容したのか。何を見て問題ないと判断したのか。この説明が出てこないなら、レビュー欄がどれだけ賑やかでも弱い。

AIレビューのコメントは、責任の代替物にならない。むしろ責任の輪郭をはっきりさせるために使うべきだ。

いい使い方はある。まずAIに粗く拾わせる。構文、命名、テスト観点、境界値、セキュリティの初歩、重複、例外処理。この辺りはAIに任せていい。人間が全部を同じ濃度で見る必要はない。レビュー担当者の集中力は有限だ。ならば、機械が拾えるものは機械に拾わせる。

その代わり、人間はもっと嫌なところを見る。仕様の解釈が正しいか。顧客が困る流れになっていないか。運用担当が追えるログになっているか。障害時に切り戻せるか。既存ユーザーに影響が出るか。チームが保守できる複雑さに収まっているか。ここはAIコメントの有無だけで判断できない。

AIレビューを入れたチームほど、人間のレビュー観点を上げないといけない。作業を楽にするためのAIが、人間を下流の確認係に押し込むことがある。これはかなり皮肉だ。レビュー担当者が楽になるはずだったのに、実際にはAIコメントを読んで、担当者の返信を読み、何となく承認するだけの存在になる。

それは、レビュー担当者の価値を自分で手放しているのに近い。

生成AIの時代に仕事を奪われる不安があるなら、見るべき場所はそこだ。AIがコメントを書けるようになったこと自体より、人間が判断を言語化しなくなっていることの方が痛い。コメントはAIにも書ける。判断の理由は、まだチームの文脈を背負った人間が持つべき仕事だ。

ただし、気合いで読めという話にすると一気に現場から離れる。PRは増える。AIがコードを書く。担当者も速くなる。レビュー待ちは積み上がる。そんな状況で、人間が全部を丁寧に読むべきだと叫んでも、チームは回らない。だから必要なのは精神論ではなく、レビュー責任の設計だ。

たとえば、AIレビュー後の人間レビューには、最低限この三つを残す。

今回の変更で一番大きいリスクは何か。パフォーマンスなのか、データ不整合なのか、権限なのか、既存仕様とのズレなのか。次に、そのリスクを何で抑えたと判断したか。テスト、ログ、Feature Flag、ロールバック手順、段階リリース、運用監視。最後に、残したリスクを誰が引き受けるか。リリース後に見る人、問い合わせを受ける人、次に直す人。

この三つが残っているPRは強い。AIのコメントが少なくても、人間がレビューした跡がある。逆に、この三つがないPRは弱い。AIコメントが大量にあっても、チームとして通した理由が見えない。

レビューコメントの量で安心するチームは、承認の意味を軽く見ている。

承認ボタンは、読んだという印ではない。許容したという印だ。ここを曖昧にすると、リリース後の問題はいつも宙に浮く。実装者は、レビューで通ったと言う。レビュー担当者は、AIも見ていたと言う。チームは、テストは通っていたと言う。そうやって、誰も嘘をついていないのに、誰も判断していない状態が生まれる。

現場で本当に消耗するのは、この状態だ。問題が起きたあとに、原因分析の場でみんなが少しずつ正しいことを言う。AIの指摘は処理していた。レビューも承認されていた。CIも通っていた。リリース手順も踏んでいた。けれど、誰がどのリスクを見て通したのかだけが抜けている。

プロセスの上では通っている。判断の上では薄い。この差が、生成AI時代のレビューで目立つようになる。

AIレビューを入れるなら、レビューの完了条件も変えた方がいい。AIコメントがすべて処理されたことを完了条件にすると、チームはコメント消しに向かう。人間レビューの完了条件は、変更を受け入れる理由が説明できることに置くべきだ。

具体的には、PRテンプレートに一行足すだけでも変わる。

今回、人間が確認した判断ポイント。

ここに、仕様影響、運用影響、リリース判断、残リスクのどれかを書く。長文はいらない。むしろ短い方がいい。重要なのは、承認者が何を見たかを残すことだ。

たとえば、在庫数を更新するAPIなら、レビューコメントはこうなる。AI指摘の例外処理は対応済み。人間レビューでは、二重送信時の在庫差分とリトライ時の冪等性を確認。残リスクは既存バッチとの競合で、初回リリースは対象店舗を限定して監視する。これなら判断が見える。

完璧なレビューを目指す必要はない。完璧を装ったレビューが一番厄介だ。AIコメントを全部処理して、テストを増やして、承認も二人ついている。それでも、通した理由が誰の口からも出てこないPRはある。形式だけ整っているぶん、あとで揉める。

AIレビューで速くなるチームと、AIレビューで責任が薄まるチームの差は、ここに出る。前者はAIに観点を増やさせ、人間が判断を濃くする。後者はAIにコメントを増やさせ、人間が承認を軽くする。

そして、これは個人のスキル評価にもつながる。これからのレビュー担当者に求められるのは、細かい指摘を大量に出す能力だけではない。AIが出した指摘の中から、事業、顧客、運用、設計に効くものを選び、通す条件を決める能力だ。

この力を持つ人は、AIが入っても価値が落ちにくい。むしろ上がる。なぜなら、AIによって指摘候補が増えるほど、選ぶ力の差が表に出るからだ。全部直せと言う人は現場を止める。全部通す人は信頼を削る。必要なのは、どこで線を引くかを説明できる人だ。

AIレビューを使っているなら、次のPRから見る場所を変えた方がいい。AIが何を指摘したかだけを見るな。人間が何を許容したかを見る。AIコメントが消えたかだけを見るな。通した理由が残っているかを見る。レビュー担当者が賢そうなコメントを書いたかだけを見るな。リリース後に自分の判断として説明できるかを見る。

AIが見つけた指摘より、人間が黙って通した判断の方が、あとで重くなる。