Fableが再レビュー省略を判定

この仕組みは、エンジニアのツール構成にあった特定の不整合から生まれた。MaxプランのClaudeにはレビューエージェントを増やす余裕があった一方、TeamプランのCodeRabbitはレート制限に何度も達していた。アップグレード後もインターフェースに「1時間2回」と表示され、40〜50分待つ日もあった。2製品で6リポジトリを抱え、各アプリの修正がE2EテストPRと文書PRを伴うため、作業量に対してPR数が多かった。

エンジニアはすでに自動レビューをリクエスト時のみに絞り、1つのE2EリポジトリはCodeRabbitではなくFableにレビューさせていた。残る無駄は2つだった。1行修正の再レビューと、文書のみのPRをCodeRabbitに通すことだ。新しいスキルを文書のみのPRに初めて使うと「まず修正」と4件の指摘が返り、いずれも文書内の不整合だった。古いスキル数の記載や更新ログ行の欠落などだ。修正後、差分のみを再確認すると「合格」が返り、スキルがdiffの目視では見落としがちな整合性の問題を捉えることが示された。

設計ではまず線引きをした。コードを含むPRは最低1回CodeRabbitを通す必要があり、後の差分と文書のみがFableの対象になる。ガードレールはプロンプトだけでなくスクリプトに置いた。不明な判定テキストやマーカー欠落は不合格になり、マージチェックは現在の40桁のheadに一致する判定しか受け付けない。エンジニア自身の結論は、AIツールを組み合わせると最もレート制限の厳しいツールがプロセス全体のペースを決めるというものだ。