メインコンテンツまでスキップ

Open Code Review：AlibabaのハイブリッドAIレビュアー vs Claude Code、Codex、あらゆるモデル（2026年）

中級
What you'll learn
  • open-code-reviewが、Claude CodeやCodexに「PRをレビューして」と頼むのと何が違うのかを説明する：どのステップがコードで、どのステップがモデルなのか
  • ベンチマークを正直に読む — 4.7倍という精度の見出し、20%という再現率の上限、そしてなぜ新しいClaudeモデルのスコアが低かったのか
  • 任意のプロバイダー（Claude、GPT、Gemini、Qwen、DeepSeek、ローカルのOllamaモデル）で最初のレビューを実行し、トークンを1つも使わずにファイルフィルターをプレビューする
  • OCR管理のレビューと、Claude CodeやCodexのサブスクリプションが思考を担う委任モードのどちらかを選ぶ
  • pull_request_targetと誤検知の罠にはまらずにCIへ組み込む

2026年にコーディングエージェントを導入したチームはどこも同じ壁にぶつかりました。コードが、誰かが読めるよりも速く届くのです。「レビューもエージェントに頼めばいい」というのは当然の答えですが、たいていは誰も信用しないコメントの山を生むだけです。open-code-review（ocr CLI）はAlibabaの答えです。社内で約2年間使われた後、2026年5月18日にオープンソース化され、今週27.5kスターと9月15日のリリースで再びGitHub Trendingに登場しています。

1ページを割く価値があるのは、その核となる考え方が、Claude、GPT、オープンモデルで構築するあらゆるものに応用できるからです：間違ってはならないステップはモデルから取り上げ、モデルには判断だけを任せる。

考え方：レールはコードで、判断はモデルで​

メンテナーは、汎用エージェントがスキルやプロンプトでコードをレビューするときに見た3つの失敗モードを挙げており、それはClaude Codeユーザーの不満とほぼ一対一で対応します：

純粋なエージェントレビューの失敗OCRが代わりにコードで行うこと
カバレッジの欠落 — 大きな差分では、エージェントが一部のファイルだけをレビューし、他を黙って飛ばす決定論的な5段階のファイルフィルターがレビュー対象のファイルを正確に決め、それぞれがディスパッチされる。モデルがファイルを「忘れる」ことはできない
位置のずれ — コメントが間違った行やファイルを指す独立したポジショニングモジュールが、モデルが引用したコード片を差分と、次にファイル全体と照合して各コメントをアンカーし、それでも駄目な場合にのみモデルに再配置を依頼する
品質の不安定さ — プロンプトの小さな変更で結果が大きく揺れるルールはglobパターンでファイルにマッチされ、モデルが選ぶのではない。関連ファイル（例えばmessage_en.propertiesとmessage_zh.properties）はバンドルされ、各バンドルは独立したサブエージェントとして実行される

モデルには本当に得意な部分が残ります：次に何を見るかを決め、コンテキストを取り込むことです。モデルには小さく目的特化したツールセットが与えられます — ファイルの範囲を読む、別ファイルの差分を読む、リポジトリをgrepする、名前でファイルを探す、コメントを出力する、終了する — チームによれば、これは本番のツール呼び出しトレースから抽出したものです。最後のリフレクション／フィルター工程が、あなたの目に触れる前に弱いコメントを捨てます。

Guided walkthrough1 of 5
  1. ワークスペース（ステージ済み、未ステージ、未追跡）、merge-baseから計算したブランチ範囲、単一コミット、または差分なしでファイル全体を対象にする`ocr scan`。Git 2.41以上が必要です。

ベンチマークを注意深く読む​

Alibabaは結果をAACR-Benchで公開しています。これはHugging Face上の自社データセットで、50のオープンソースリポジトリ、200件の実際のプルリクエスト、10言語、そして80人以上のシニアエンジニアが注釈付けとクロスチェックを行った1,505件の問題から成ります。README内のリーダーボードから選んだ行：

レビュアーモデルF1精度再現率レビューあたりトークン時間
OCR v1.3.1Claude Opus 4.625.1%33.9%（889件中301件）20.0%385K1m23s
OCR v1.8.7Qwen3.8-Max23.0%33.9%17.4%334K5m14s
OCR v1.3.1GPT-5.521.0%32.1%15.5%422K2m51s
OCR v1.3.1Claude Opus 4.817.9%37.8%11.7%352K1m06s
Claude Code v2.1.169Claude Opus 4.814.1%15.9%12.7%2,062K5m38s
Claude Code v2.1.169Claude Opus 4.611.6%7.2%（5,980件中435件）28.9%5,664K13m06s
Codex v0.140.0GPT-5.58.4%27.8%4.9%525K2m58s

この表には、見出しよりも興味深い点が3つあります。

1. 精度の差は、実はコメント量の差です。 Opus 4.6では、Claude Codeは200件のPRに5,980件 — PRあたり約30件 — のコメントを投稿し、そのうち7%が実際に注釈された問題と一致しました。OCRは889件（PRあたり約4.4件）を投稿し、34%が一致しました。実はClaude Codeのほうがより多くの本物の問題を見つけています（435件 vs 301件、つまり再現率が高い）。違いはノイズであり、ノイズこそがAIレビュアーを無効化される原因です。あるHacker Newsのコメント投稿者はこう表現しました：「指摘の8件中7件が問題なしなら、人は警告を無視するようになる」。

2. ボード上で最良のレビュアーでも、本物の問題を5件に1件しか見つけません。 全体での最高再現率はClaude Codeの28.9%で、OCRの最高は20%です。厳格で主観的な正解データ（HNで指摘された点）を考慮しても、ここにあるどの構成もマージゲートにはなりません。どんなAIレビュアーも、一部のバグを安価に捕まえるフィルターとして扱い、PRが安全だと判定するものとしては扱わないでください。これはAILmanacが検証のボトルネックで扱うより大きなパターンに合致します。

3. 新しいモデルのスコアが低く、見出しの倍率もそれとともに縮みます。 OCR内部では、Opus 4.8がボード上で最高の精度（37.8%）を記録しましたが、再現率（11.7%）はOpus 4.6より低く、F1は25.1%から17.9%に下がりました。より強力なモデルほど保守的でした — HNのテスターがGPT-5.xで報告したのと同じ現象です。Opus 4.8のClaude Codeと比べると、OCRの優位は精度約2.4倍、トークン約6分の1であり、Opus 4.6の行から得られる4.7倍・約1/15ではありません（READMEは全体の主張を「~1/9」に丸めています）。また、Claude CodeとCodexの行は数バージョン古いものです。

さらに、これはツールを作っているチーム自身が作ったベンダーのベンチマークであることも忘れないでください。HNでの初期の独立テスト（別のベンチマークの10件のPR）では精度はおよそ12%でした。メンテナーはその原因を壊れたツール呼び出しに突き止め、修正済みだと述べています。どの行を信じる前にも、自分の最近のPRで実行してみてください。

任意のモデルで最初のレビューを実行する​

ocrはnpm経由で配布されるGoバイナリです。Anthropic、OpenAI Chat Completions、OpenAI Responses、Bedrockの各プロトコルに対応し、Anthropic、OpenAI、Gemini、DeepSeek、Kimi、Z.ai、MiniMax、xAI、DashScope（Qwen）などのプリセットを備えています。それ以外は、URLとプロトコルを指定するカスタムプロバイダーになります。

インストール、設定、フィルターのドライラン

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

# Interactive: pick a provider, paste a key, pick a model; it runs a connectivity test
ocr config provider
ocr config model
ocr llm test

cd your-repo
# See exactly which files would be reviewed, and why others are excluded — no LLM call
ocr review --preview

# Review your branch against main, with context the model can't infer
ocr review --from main --to my-branch --background "Adds rate limiting to the public API"

ドキュメントに明記されている、午後の時間を節約してくれるポイント：

  • すでにClaude Codeを使っていますか？ 設定ファイルもOCR_LLM_*変数も設定されていない場合、ocrはANTHROPIC_BASE_URL、ANTHROPIC_AUTH_TOKEN、ANTHROPIC_MODELにフォールバックします。見つけた最初の完全なURL・トークン・モデルの組を使うため、古い設定ファイルが環境変数を黙って上書きします。
  • ローカルモデルにはネイティブのツール呼び出しが必要です。 OCRはレビュー全体をツール呼び出しで駆動します。ツール呼び出しをテキストとして書くだけのモデル（FAQではdeepseek-r1が挙げられています）は「No tool calls parsed」でループし、コメントを0件返します。qwen3のようなツール対応タグのOllamaモデルを選んでください。モデルをローカルで実行するを参照してください。
  • --effortは品質とコストのダイヤルです。 lowは1ラウンド、medium（デフォルト）は2、highは3で、グループごとのタイムアウトもそれに比例します。--max-tokens-budgetは総トークンにハード上限をかけ、それでも部分的な結果を公開します。
  • --backgroundは重要です。 CLIリファレンスはこれを最も効果の高いフラグの1つと呼んでいます：モデルが見るのは差分と自分で読むことにしたものだけで、あなたのチケットは見えません。
  • start_line: 0のコメントは本物ですが、アンカーできなかったものです — たいていはモデルがコードを引用せずに言い換えたか、差分にCRLFや混在したインデントがあります。

カスタムルール​

ルールはglobでマッチされるプレーンなJSONです。プロジェクトファイルは.opencodereview/rule.jsonで、各エントリにはpathパターン、ruleテキスト、そしてそのファイルに組み込みルールも残すためのmerge_system_ruleがあります。最初にマッチしたパターンが優先されるため、具体的なパスを一般的なパスより前に置いてください。ocr rules check <file>は、どのレイヤーとパターンがマッチしたかを表示します。リポジトリ自身のルールファイルは良いテンプレートです：フィールド順序の強制、4つの翻訳ドキュメントをコード表と同期させること、新しいプロバイダーごとに名前付きテストを必須にすることをレビュアーに指示しています — 汎用モデルには推測できない社内ルールです。

組み込みのカバレッジはAlibabaのスタック寄りです（Javaのnullポインターとスレッドセーフティのチェック、JS/TSのXSS、mapper XMLファイルのSQLインジェクション）。その後、コミュニティのPRによってPython、Rust、Kotlin、C/C++、Terraformなどが追加されています。

OCR管理モードか委任モードか​

コーディングエージェントの中から実行する方法は2つあり、違いは誰が思考の費用を払うかです。

OCR管理（プラグイン、スキル、CLI）委任モード
モデルを呼び出すのは誰かocr（自身のAPIキーで）ホストエージェント（Claude Code、Codex、Cursor、OpenCode…）
OCRが行うこと上記のパイプライン全体ファイル選択とルール解決のみ
コスト従量課金のAPIトークンエージェントのサブスクリプションの枠
ベンチマークの保証を維持するかはい — アンカリング、ラウンド、リフレクションフィルター部分的に — カバレッジとルールは維持されるが、レビュー自体はエージェント次第

Claude Codeでは、/plugin marketplace add alibaba/open-code-reviewの後に/plugin install open-code-review@open-code-reviewを実行すると、/open-code-review:review（OCR管理、自動修正ステップ付き）と/open-code-review:delegate-reviewが使えるようになります。Codexは同じリポジトリをプラグインマーケットプレイスとしてインストールします。

手動での委任モード（スキルが自動化する内容）

# 1. Which files, in which mode, and why others were excluded
ocr delegate preview --from main --to my-branch

# 2. The rule checklist for those files, grouped so shared rules appear once
ocr delegate rule src/api/handler.go src/api/limits.go

# 3. Your agent then reads each diff with git (git diff <merge_base>..<to> -- <path>),
#    reviews each file against its rule group, and reports
#    Critical/High always, Medium with context, Low only if clearly valuable.

OCRをインストールしなくても、委任は良いパターンです：どのファイルをカバーし、どのチェックリストを適用するかを正確にエージェントに伝える小さな決定論的ヘルパーが、「これをレビューして」を願望から、エージェントが途中で打ち切れないループへと変えます。

CI：2つの罠​

同梱のGitHubワークフローはpull_request_targetと/open-code-reviewコメントで起動し、ocrをインストールし、範囲をJSON（--format json --audience agent）でレビューし、インラインコメントを投稿します。行のない指摘はサマリーにまとめられます。llm_modelやllm_reasoning_effortなどの入力を持つコンポジットaction.ymlもあります。コピーする前に決めておくべきことが2つあります：

  • pull_request_targetはフォークからのPRにシークレットへのアクセスを与えます。 ドキュメントはフォークでもレビューが動くようにこれを選んでおり、OCRは差分を読むだけでPRのコードを実行しないと注記しています。しかし差分は、投稿用トークンを持つモデルにそのまま渡される信頼できないテキストです。推論であり、文書化されたインシデントではありません： 悪意あるPRは、レビュアーにプロンプトインジェクションを仕掛けて黙らせたり、誤解を招くコメントを投稿させたりしようとする可能性があります。ジョブの権限は投稿に必要な範囲に留め、AIレビューをマージの承認者にしないでください。そしてGitHubのissueがCIシークレット漏洩につながった経緯を読んでください。
  • 展開する前にノイズを見込んでおきましょう。 Actionのデフォルトのリクエストボディは互換性のためにモデルの「thinking」をオフにしており、推論モデルの挙動がローカル実行時と変わります。ocrのバージョンを固定し（入力のデフォルトはlatest）、少数のリポジトリでコメント専用トリガーから始め、チームが実際に対応したコメントの数を数えてください。

理解度チェック

0/6
  1. Claude Opus 4.6を使ったAACR-Benchで、Claude Codeの精度は7.2%、OCRは33.9%でした。注釈付きの本物の問題をより多く見つけたのはどちらのレビュアーですか？
  2. 公開リーダーボードで、いずれかのレビュアーが達した最高の再現率はどれですか？
  3. OCR内部で、Claude Opus 4.8のF1はOpus 4.6より低くなりました。なぜですか？
  4. OCRをローカルのOllamaモデルに向けたところ、すべてのファイルが「Max tool requests reached」とコメント0件で終わります。最も可能性の高い原因は？
  5. 委任モードでは、何がOCRからコーディングエージェントに移りますか？
  6. シェルでOCR_LLM_MODELを設定したのに、ocr llm testが別のモデルを表示します。なぜですか？

出典とさらに読む​

次へ​