最終ゲートキーパーとしての AI とは、人間のレビュアーがプルリクエストを承認した後に AI によるチェックを置き、人ではなくエージェントをマージ前の最後のゲートにするプラクティスである。この考え方の核心は順序にある。通常、AI レビューは人間のレビューの前か並行して実行され、その指摘は人間が後で下す判断の材料となる。これに対しここでは、人間の判断が先に来て、エージェントはその判断が残した状態を監査する。
用法
コミット数2倍でもレビュー品質を維持！AI時代のコードレビューフロー再設計 は、これを採用したチームについて述べており、その動機を次のように説明している。人間が関わるプロセスには、見落としや運用上のミスの可能性が避けがたくつきまとう。このゲートは、誠実なレビューでもなお見逃すものを捕まえるためにあるのであって、レビューの代わりになるためではない。
この説明によれば、承認後のチェックは四つの事柄を対象とする。すべてのレビューコメントに実際に対応がなされたか、差分に欠陥が含まれていないか、チームの開発ガイドラインに違反するものがないか、そしてマージ後に変更をどう検証するかについての提案があるか、である。チェックは判定を、その根拠とともに返す。投稿は例として「マージ OK」「懸念ありでマージ」「マージ非推奨」を挙げており、判定はレビュアーとレビュイーの双方が読めるコメントとして投稿される。
投稿の説明では、このチェックが返すのは行動ではなく、人が読むための判断である。何も指摘されなければ人間はそのままマージしてよく、懸念が挙げられれば、それに対応する価値があるかを人間が決める。したがって、その名前にもかかわらず、マージの決定権は人間に残っている。このチェックがどのように組み込まれているか、つまりマージをブロックできるのかどうかについて、投稿は述べていない。
適用される場面
このチェックに必要なものは、投稿がチェックさせている四つの事柄から読み取れる。エージェントに参照させられる、明文化された開発ガイドライン（投稿のチームはこれを信頼できる唯一の情報源としてリポジトリ内に置いている）、それに加えて、エージェントが読めるスレッド上のレビューコメントと、エージェントが推論の対象にできる差分である。規約が人々の頭の中にしかないチームでは、このゲートが照合する対象が何もない。これらの前提条件は、投稿が要件として述べているものではなく、チェックの内容から導いたものである。
一つの失敗モードは、同じチームがフローの残りの部分をどう組み立てているかに見て取れる。エージェントは誤った、あるいは誇張された指摘を出しうるが、投稿のより広いレビュー設計はまさにそこに専用のサブエージェントを置き、AI の各コメントが投稿される前に、それが妥当か、捏造されたものでないか、どの程度深刻かを判定させている。これをこのゲートが役に立つための条件と読むのは、投稿の主張ではなくこのウィキによる推論である。
どの程度確立したものかについて言えば、これは一つのチームのプラクティスであり、一本のエンジニアリングブログ記事で報告されたものにすぎない。レビュアーとレビュイーが今では自信を持ってマージでき、品質が担保されているという投稿の評価は著者自身の判断であり、測定や、置き換えられる前のフローとの比較なしに示されている。
関連用語
エージェント型コードレビュー、コードレビューエージェント、レビューのボトルネック、ヒューマン・イン・ザ・ループ、リスクベースのゲート、LLM-as-a-Judge