alibaba/open-code-review

コードレビューを AI にやらせる、ターミナルで動く道具。変更の差分を読み、変わったファイルを、設定したモデルに渡す。返ってくるのはどの行への指摘かまで付いた形の講評で、モデルは差分だけでなく、ファイル全体を読んだり、リポジトリの中を検索したり、同じ変更にある別のファイルを見に行ったりできる。差分が無いコードをまとめて見たいときのために、ファイル全体を対象にする ocr scan も用意されている。README によると、もとはアリババ社内の公式の AI レビュー係として2年ほど使われてきたもので、それを社外に出したのがこのリポジトリだという。

作りの中心にあるのは、決まった手順と AI の分担という考え方。README は、汎用のコーディングエージェントにレビューをさせたときに起きることを3つ挙げている。変更が大きいと一部のファイルだけ見て済ませてしまう、指摘の場所が実際のコードとずれる、書き方を少し変えただけで結果が揺れる。原因は「全部を言葉で指示している」ことにある、という立場だ。そこで、間違えては困る工程は言葉ではなくプログラムの側で決める。どのファイルを見るかの選別、関連するファイルを一つの単位に束ねること、ファイルの性質に応じた規則の割り当て、そして指摘の位置合わせと見直し。束ねられた単位はそれぞれ別の文脈を持つ子エージェントとして動くので、変更が大きくなっても分けて進められる。

AI の側に残すのは、その場で決める仕事と、必要な材料を自分で取りに行く仕事に絞られる。プロンプトはレビュー向けに練り直してあり、効きをよくしながらトークンの消費も抑えられる、と書かれている。渡す道具のほうも、実際の運用で集めた呼び出しの記録を分析したうえで、この用途のために組み直したものだという。README はこの設計の裏づけとして自前の測定を載せていて、同じモデルを使った汎用エージェント（Claude Code）と比べると、指摘の当たっている率と F1 は上回り、使うトークンはおよそ9分の1、ただし見つけられる欠陥の割合（再現率）は下回るとしている。取りこぼしより誤検知を減らすほうを選んだ、意図的な交換だと書かれている。測定の土台は、50 のリポジトリ・200 件の実際のプルリクエスト・10 の言語から作り、80人以上の技術者が突き合わせた 1,505 件の正解データだという。

変更が大きく、AI に見てもらっても全部は見てくれないとき

README が最初に挙げている不満がこれで、対象を選んで束に分ける工程を、モデルではなくプログラムの側に持たせてある。束はそれぞれ別の文脈で動くので、まとめて1回のやりとりに詰め込む形にはならない。

指摘の場所が実際のコードと合わず、毎回読み替えているとき

指摘を行に当て直す部分と、内容を見直す部分が、レビュー本体とは別に置かれている。README がこの道具を作った理由として挙げているのも、この「場所のずれ」だ。

取りこぼしは増える前提で選ばれている。 README 自身が、汎用エージェントより再現率は低いと明記している。誤検知を減らすためにそう振ったと書かれているので、漏れなく洗い出したい用途には向きの違う道具になる。

掲載されている比較は、作った側が出した測定。 条件（同じモデルを使い、比較相手は Claude Code）は書かれていて、正解データのほうは80人以上で突き合わせたうえで公開もされている。ただし測定そのものを第三者がやり直した結果ではないので、数字をそのまま自分の環境の見込みにはできない。

モデルの用意は自分でする。 使う前にモデルの接続先を設定する必要がある（README には、手元のコーディングエージェントにレビューそのものをやらせる「委任」の使い方もあり、そちらはモデルの設定が要らないと書かれている）。動かすには Git 2.41 以上が要る。

ライセンスは Apache-2.0。