技術分解 011｜OpenCodeReview:Alibaba オープンソースのハイブリッドアーキテクチャ・コードレビューツール――半分はエンジニアリングのハード制約、半分は Agent による動的意思決定

2026年9月17日、alibaba/open-code-review が GitHub のトレンドランキングにランクインし、1日で 3,231 個の star を獲得、リポジトリの合計は 31.8k に達しました。この増加ペースはツール系プロジェクトでは珍しいものです。このツールのやっていることを一言でいえば:Git diff を読み込み、ツール呼び出し能力を持つ Agent にレビューを委ね、行番号付きの構造化されたレビューコメントを出力します。市場には同種の製品が数十ありますが、その違いはアーキテクチャの主張――「決定論的エンジニアリング × Agent のハイブリッド」にあります:「絶対に間違えてはならない」工程はエンジニアリングのロジックで固定し、柔軟な判断が必要な工程だけをモデルに委ねるのです。この記事では6つのポイントに分けて分解します:これは何か、どうインストールするか、アーキテクチャをソースコードまで分解、Benchmark の読み方、汎用 Agent との違い、導入する価値はあるか。

一、これは何か

OpenCodeReview は、アリババグループ内部の公式 AI コードレビューアシスタントをオープンソース化したもので、実装は Go が主体、ライセンスは Apache 2.0 です。README の自己説明によれば、過去 2 年間でアリババ内部において数万人の開発者にサービスを提供し、数百万件のコード欠陥を発見してきたとのこと。これは公式見解である旨、先に注記しておきます。リポジトリ全体は 858 ファイルで、うち Go ファイルが 340、TypeScript が 62、Python が 8――Go がメインプロセスと Git のやり取りを担い、TypeScript は vscode 拡張の中に、Python はスクリプト側に点在しています。リポジトリには plugins/ ディレクトリ、extensions/vscode ディレクトリ、さらに 2 つの Agent skill 定義（open-code-review、open-code-review-delegate）が同梱されており、このプロジェクトが初日から Claude Code、Codex、Cursor といったコーディング Agent のワークフローの中に住み着くことを狙っていた、つまり孤立したスタンドアロンアプリを作る気はなかったことを物語っています。

その野望は「また一つ AI レビューを作る」ことではなく、一つの本質的な問いに答えることにあります。汎用 Agent によるレビューは、なぜ常に不安定なのか。

二、インストールと使い方

インストールはコマンド一発：

npm install -g @alibaba-group/open-code-review

インストールが完了すれば、グローバルで ocr が使えるようになります。npm 以外にも、6 プラットフォーム分のプリコンパイル済みバイナリ（darwin、linux、win32 のそれぞれ arm64/x64）と install スクリプトが提供されています。ハード依存はただ一つ：Git >= 2.41——diff の生成、コード検索、リポジトリ操作はすべて Git の上に成り立っており、バージョンが足りなければその場で実行を拒否します。

初回利用時は、まずモデルを設定します：

ocr config provider    # 选内置服务商或加自定义端点
ocr config model       # 为当前服务商挑模型

レビューコマンドは Git の状態を軸に展開します：

ocr review                                  # 工作区模式：审全部暂存、未暂存、未跟踪改动
ocr review --from main --to feature-branch  # 分支区间，按 merge-base 算
ocr review --commit abc123                  # 单个提交
ocr scan                                    # 无 diff 审计：整个文件扫描，审陌生代码库
ocr review --preview                        # 干跑：只看会审哪些文件，不烧 token

ocr scan は単独で特筆する価値があります：コミット履歴に依存せず、ファイル全体やディレクトリ全体を直接監査するコマンドで、見知らぬコードベースを引き継いだ際の最初の健康診断として使えます。中断してしまったレビューも、ocr session list でセッションを取り戻し、--resume で再実行できるので、長時間のレビューでもトークンが無駄になりません。

三、アーキテクチャ解体：二つのエンジンがそれぞれ担うもの

ここが記事全体の山場です。README は設計原則をきわめて率直に書いています。「review steps that must not go wrong」はエンジニアリングロジックが保証するのであって、言語モデルが保証するのではない、と。ソースコードを紐解けば、四点セットに二点セットを加えた構成の、どの環もコードの中に確かな落とし所を見つけられます。

3.1 ファイル選択：純粋関数ひとつで入口を固める

internal/agent/selection.go の selectFiles はレビューの唯一の決定論的入口です。変更のあった各ファイルに対して、静的なパスと拡張子のゲート、削除ファイルのチェック、単一ファイル diff の token 上限を順に適用し、ファイルごとの裁定（審査する / 審査しない / どんな理由で審査しないのか）を出力します。この関数は純粋です――副作用を生まず、Git にも LLM にも触れない――そのため --preview のドライランと実際の実行は同じ答えを受け取ります。ユーザーがプレビューで確認できるカバレッジこそが、実際のカバレッジです。一般的な Agent レビューにありがちな「大きな changeset で手を抜いてファイルを見落とす」という悪癖は、この層で構造的に塞がれています。モデルがまだ登場しないうちに、どのファイルを審査すべきかはすでに確定しているのです。

3.2 ファイルのグルーピング：小グループはローカルで直接分割、大グループだけモデルを動かす

internal/agent/grouping.go は、関連するファイルをレビュー単位にまとめる役割を担います。設計には三段階の抑制があります。第一に、小さな change set はそもそも LLM リクエストを送りません。テンプレート内の GroupingPlan がファイル数と変更行数に応じてローカル直接分割の戦略を決め、少数のファイルはそのまま一つのグループにまとめるか、ファイル単位で振り分けます。コメントには理由がはっきり書かれています――「too few files for the call to buy any information」。一度の LLM 往返で情報が買えないなら、その金は払いません。第二に、大きな change set はモデルにグルーピングさせますが、返させるのはパスではなくインデックスです。prompt では各ファイルの先頭に [i] の番号が印字され、モデルは JSON 内の整数インデックスだけを返します。コメントの言い方は極めて率直です――インデックスなら output token を数個しか消費しないが、パスはその全長を消費する。出力サイズは一桁小さくなり、大きな change set が completion の上限で打ち切られることはもうありません。第三に、二つのバルブが最後の砦として機能します。maxFilesPerGroup = 10 が上限超過のグループを細切りにし、token 予算でもう一段削り込みます。どのステップで失敗しても、一律で単一ファイルのグルーピングへフォールバックします――グルーピングに失敗するとは、すなわち各ファイルが少なくとも一度は審査されることを意味し、失うのは「関連するものを一緒に審査する」という利得だけです。

「コンテキスト分離、並列実行可」という約束もここで果たされています。各 FileGroup は独立したサブ Agent を一度実行し、グループ同士は互いのコンテキストを見えないため、自然に並列化できます。

3.3 ルールマッチング：テンプレートエンジン方式、自然言語の言い含めには頼らない

internal/config/template/prompts/ の下にはタスクごとにテンプレートが並んでいます。main、grouping、plan、re_location、review_filter、memory_compression の各タスクに、独立した system と user の二種が用意されます。ルール側では internal/config/rules/system_rules.json がデフォルトルールとパスマッチのルールテーブルを担い、allowlist ディレクトリ内の拡張子ホワイトリスト、デフォルト除外パターン、シークレットパスパターンがこれに添えられます。ルールとは「どの種類のファイルにどの種類の検査を割り当てるか」を記した構造化データであり、テンプレートエンジンが prompt へレンダリングします。要求を自然言語の段落にしたためて、モデルの暗記に期待する――そんなやり方ではありません。README の判断は硬いのです。純粋に言語駆動のルール誘導はデバッグしにくく、品質が prompt の微調整につれて揺れ動く。テンプレートエンジン駆動のマッチングは「より安定し、より予測可能」だと。レビュー出力にはさらに構造化された severity（critical から low まで）と category（bug、security、performance など）が伴い、下流ではレベル別にフィルタできます――低レベルの誤検知が多いという問題は、フォーマット層で捨てることが許されているのです。

3.4 コメントの位置特定とリフレクション：二段構えのリトライ、失敗すればロールバック

コメント位置のドリフトは、汎用 Agent レビューにおける第二のペインポイントであり、OpenCodeReview はこれを二段階に分けて対処している。第一段階は internal/diff/resolver.go の仕事である。各コメントにはモデルが提示した ExistingCode スニペットが添付されており、まずそれを使って diff hunk 内でテキスト照合を行い行番号を特定し、照合できなければフォールバックとしてファイル全体を走査して一行ずつ比較する。第二段階は relocation.go の仕事である。二段階のテキスト照合がどちらも失敗した後、LLM をもう一度呼び出し、元の diff・既存スニペット・提案内容をまとめて re_location テンプレートに流し込み、モデルに正確なコードブロックを再生成させ、新しいスニペットで解析を再試行する。再試行でも失敗した場合は ExistingCode を原文にロールバックする。このコメントの位置特定が失敗することになっても、誤った行番号を書くことはしない、という姿勢である。「外部位置特定＋リフレクションモジュール」も、ソースコードの上ではこうした素朴な二段階リトライ＋ロールバックにすぎない。いわゆるリフレクションに対応するのが、テンプレートディレクトリ内の review_filter タスクである。1 ラウンドのレビュー結果が出た後にもう一度フィルタを通し、根拠の弱いコメントを出力の手前で退ける。位置特定は「コメントをどの行にピン留めするか」を司り、リフレクションは「このコメントは出力に値するか」を司る。この二つは独立したタスク・独立したテンプレートに分けられており、互いに薄め合うことはない。

3.5 Agent 側：prompt の深いチューニングと、本番 trace から蒸留したツールセット

モデルに許された働きは二つだけである：動的な意思決定と、動的なコンテキスト取得である。prompt はレビューシナリオ向けに深く調整されたテンプレートで、公式の説明によれば効果がより高く、token も節約できるという。ツールセット（ファイル全体の読み取り、コード検索、同一 change set の他ファイルの閲覧）は、大規模な本番環境の tool-call trace から蒸留したものだとされる——呼び出し頻度の分布、単一ツールの重複率、新しいツールが呼び出しチェーン全体に与える影響を分析したうえで、レビュー専用のツールリストを切り出したという。このうち内部の本番データに由来する結論は公式の見解にすぎず、外部から検証することはできないが、token 消費を汎用 Agent の約9分の1まで圧し込める理由を説明してはくれる：ツールが少なく専用的であるぶん、1 回 1 回の呼び出しの目的性が強く、回り道が少ないのである。

四、Benchmark の読み方

公式ベンチマークは AACR-Bench と呼ばれる：50 のオープンソースリポジトリ、200 件の実際の PR、10 種類の言語、80 名以上のシニアエンジニアによるクロス検証を経て、1,505 件の正解問題がアノテーションされており、データセットは HuggingFace（Alibaba-Aone/aacr-bench）で公開されている。比較対象は同一の基底モデルを使う Claude Code で、結論は 3 つ：Precision と F1 は顕著に高く、token 消費量は約 1/9、速度も速い。一方で README では、Recall がより低いことも自ら明かしている——「精度を優先し、ノイズは避ける」という意図的なトレードオフだ。

この一連の数字は正しく読む必要がある。第一に、比較対象は「汎用 Agent + skill」という形態であって、素のモデルではない。勝因は、エンジニアリング上の強固な制約によってカバレッジと問題箇所の特定を釘付けにしたことにあり、これはモデルの勝利ではなくアーキテクチャの勝利だ。第二に、Recall が低いということは検出漏れが多いということである。レビューの主戦場が「誤検知ノイズの削減、シニアエンジニアの triage 時間の節約」であるチームには適しているが、もし「誤報が増えても見逃しは許されない」というシナリオなら、この曲線の方向は真逆になる。第三に、1,505 件の正解データ、80 名によるクロス検証は、評価規模としては本格的だ。ただし構築したのはアリババ自身であり、アノテーションの基準は避けがたく自社ツールの強みに偏るため、第三者による再現が成されるまでは「公式の主張」として扱うべきだ。このトレードオフの論理そのものは覚えておく価値がある：Precision を Recall と引き換えにすることで、節約できるのは人間の注意力であり、犠牲になるのはモデルのカバレッジだ——CI ゲートのシナリオにとって、この取引はほぼ常に割に合う。

五、汎用エージェントレビューとの違い

その違いを一つの表にまとめると：

観点	汎用エージェントレビュー（Claude Code など）	OpenCodeReview
カバレッジ保証	モデルの裁量に任されるため、大きな change set ではファイルの見落としが発生しやすい	純関数による選択で、preview と一致したカバレッジ
コメントの位置特定	モデルが行番号を直接報告するため、ずれやすい	テキストの2段階マッチング + LLM による再生成 + 失敗時のロールバック
ルールの方式	自然言語の skill、デバッグが難しい	テンプレートエンジン + 構造化されたルールデータ
コンテキスト	単一の巨大なコンテキスト	関連性ごとにグループ化、サブエージェントを分離・並列実行可能
ツール	汎用のフルセット	本番環境の trace から蒸留したレビュー専用セット
token	ベースライン	公式の数値で約 1/9

この違いの本質は哲学的な分裂にあります。汎用エージェントはモデルがプロセス全体を管理できると信じており、OpenCodeReview はコードとして書ける制約を確率に委ねるべきではないと信じているのです。その代償もこの表に表れています。アーキテクチャがレビューという単一のシナリオに縛られており、汎用エージェントがついでに行えること（コードの修正、テストの実行、要約の作成）は行いません。注目すべきは、その解決策が力任せの対抗ではなく delegate モデルである点です。ファイル選択とルールマッチングという、得意とする2つの処理だけを完了させ、残りの実行はあなたが現在使用しているコーディングエージェントに委ね戻します。両者がそれぞれの強みを発揮する形です。この姿勢は賢明です。汎用エージェントと優劣を競うのではなく、「誰が審判役を務めるか」を競っているのです。

六、使う価値はあるか

対象層で分けて考える。チームのCIへの組み込みが最もスムーズなシナリオだ。diff駆動で、Gitが唯一のハード依存であり、出力は構造化JSONなのでゲートやコメントボットにそのまま流し込める。--preview がコストを予測可能にし、中断しても再開でき、token消費が汎用Agentの約9分の1ということは、同じ予算でより多くのPRをレビューできることを意味する。個人開発者はモデルエンドポイントを1つ用意するだけでワークスペースレビューを実行でき、インストール後すぐに使える。すでに Claude Code、Codex、Cursor を使っている人にとっては、リポジトリ同梱のskillとプラグインディレクトリのおかげで、ocr は既存のワークフローに組み込め、習慣を移行し直す必要はない。

導入を見合わせるべきケースもはっきりしている。「多少の誤検知はいとわない」式の高リコール監査が求められるセキュリティ・コンプライアンスのシナリオでは、その低いRecallは逆指標になる。1つのツールでレビューと修正を同時に済ませたい人にとって、これはそのためのツールではない。Alibaba が自己申告している内部戦績やbenchmarkの数値については、第三者による再現が現れるまでは割り引いて読むべきだ。ルール面の「多言語ルールと複数モデル接続に対応」という記述はリポジトリのドキュメントを基準とし、具体的なルール一覧は一件ずつの確認は行っていない。

結論

OpenCodeReview の 31.8k スターと単日 3,231 の増加が裏付けているのは、繰り返し検証されてきたエンジニアリングの常識である。LLM Agent に垂直領域のタスクを任せる場合、勝敗の分かれ目は往々にしてモデルにあるのではなく、どの工程で決定論的なコードによる固定をあえて行うかにある。ファイル選択は純粋関数、ファイルのパッケージングはまずローカルで処理してからモデルへ、返すのはパスではなくインデックス、二段のゲートに失敗時のフォールバック、ルールマッチングはテンプレートエンジンを使用、コメントの位置特定は2段階のリトライと失敗時のロールバック──この4点セットの一つひとつがソースコードの中で確かに立証できる。Agent には動的な意思決定と動的なコンテキスト取得だけを残し、その見返りとして公式発表ベースで約 1/9 の token とより高い Precision を獲得する。その代償が、より低い Recall である。AI レビューを CI に組み込みたいチームにとって、これは現時点で最も完成度の高いオープンソースの答えの一つであり、Agent アーキテクチャを研究する者にとっては、そのまま読める「ハイブリッドアーキテクチャ」の教科書である。

参考資料

• alibaba/open-code-review README（GitHub；What is / Benchmark / Why / How to Use / Quick Start の各セクション）
• OpenCodeReview ソースコード（ローカルクローン、mainブランチ）：internal/agent/selection.go、internal/agent/grouping.go、internal/config/rules/system_rules.json、internal/config/template/prompts/、internal/diff/resolver.go、internal/diff/relocation.go、skills/open-code-review/SKILL.md
• AACR-Bench データセット（HuggingFace、Alibaba-Aone/aacr-bench；README の公式記載）
• リポジトリデータ：31.8k star、単日 +3,231（ユーザー提供、2026-09-17）