open-code-reviewとは Alibaba製AIコードレビューCLIの使い方と内蔵ルール

gen

2026/08/03

open-code-reviewというAIコードレビューCLIが、7月末にGitHub Trendingへ飛び出してから一気に1万7,900スターを超えました。

Alibabaが社内で2年回してきたレビュー基盤をそのままOSS化したもので、npmで入れてocr reviewと打てば動きます。

ただこのツールが面白いのはそこじゃなくて、リポジトリのルール定義とコマンド実装を追いかけたら、他のAIレビューツールとは設計の割り切り方がはっきり違っていました。

先に断っておくと、後半のベンチマーク数字は公式が公開しているものです。

そのかわりコマンド仕様と内蔵ルールは、READMEだけでなくソースまで開いて確認しました。

open-code-reviewとは Alibabaが2年動かしてOSS化したAIコードレビューCLI

ocrというコマンド名で動く、ターミナル完結型のAIコードレビューツールです。

Apache-2.0ライセンスで料金はゼロ。

動かすためのLLM APIキーだけ自分で用意します。

GitHub - alibaba/open-code-review: Open-source & free — Battle-tested at Alibaba's scale. Hybrid architecture code review tool: deterministic pipelines + LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI & Anthropic compatible.

Open-source & free — Battle-tested at Alibaba's scale. Hybrid architecture code review tool: deterministic pipelines + LLM Agent, precise line-level comments, built-in multi-language rulese...

github.com

GitHub - alibaba/open-code-review: Open-source & free — Battle-tested at Alibaba's scale. Hybrid architecture code review tool: deterministic pipelines + LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI & Anthropic compatible.

実装はGoで、それをnpmパッケージ@alibaba-group/open-code-reviewとしてラップして配っています。

npmから入るのにGoバイナリ、という組み合わせは最初「あれ？」となりました。

Alibaba社内で数万人が使ってきたルールがそのまま入っている

READMEの言い方を借りると、このツールはAlibaba社内で「過去2年にわたり数万人の開発者に使われ、数百万件のコード欠陥を検出してきた」ものです。

ここがマジで効いてくるポイントで、新規に書き起こされたプロンプト集ではなく、実務で2年間削られ続けたルールが最初から入った状態でスタートできます。

決定論パイプラインとLLM Agentのハイブリッドという構成

リポジトリの説明文にはっきり書かれているのが deterministic pipelines + LLM Agent という言い方です。

レビューの全部をAgentに投げず、ファイル選択・ファイルのまとめ方・ルールの振り分けといった「毎回同じ答えが出るべき部分」はコードで固めて、判断が必要なところだけLLMに渡します。

AIレビューツールでよくある「毎回結果が違う」「関係ないファイルまで読み始める」を、設計で潰しにいっているわけです。

この中身は後半で分解します。

open-code-reviewのインストールと初期設定でやること

セットアップは3手です。

入れる、LLMを繋ぐ、疎通を確認する。

詰まる要素はほぼありません。

npmでopen-code-reviewをインストールする

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

前提はGit 2.41以上。

入ったらwhich ocrでパスを確認しておくと安心です。

npmを使いたくない場合はリポジトリ直下のinstall.shとinstall.ps1が使えます。

ocr config providerでLLMプロバイダを決める

インストール直後は繋ぎ先が空なので、まず対話UIでプロバイダとモデルを選びます。

ocr config provider   # プロバイダ選択（TUI）
ocr config model      # モデル選択（TUI）
ocr llm test          # 疎通確認

対応はOpenAI互換とAnthropicの2系統。

OpenAI互換の口さえ持っていればAzure OpenAIでもvLLMでもOllamaでも刺さるので、社内ゲートウェイ経由やローカルLLMでのセルフホスト運用もできます。

ocr llm testは必ず先に通してください。

ここを飛ばしてレビューを走らせて落ちると、原因がLLM側なのかgit側なのか切り分けに時間を持っていかれます。

open-code-reviewの設定ファイルと環境変数の使い分け

設定は~/.opencodereview/config.jsonに保存されます。

APIキーが入る場所なのでパーミッションは0600で作られます。

非対話で設定するならocr config setです。

ocr config set provider anthropic
ocr config set providers.anthropic.api_key "$ANTHROPIC_API_KEY"
ocr config set language Japanese

languageをJapaneseにするとレビューコメントが日本語で返ります。

llm.urlやllm.modelを直接指定する書き方、custom_providers.で社内ゲートウェイを足す書き方もあります。

CIではファイルではなく環境変数を使います。

export OCR_LLM_URL=https://api.anthropic.com/v1/messages
export OCR_LLM_TOKEN=<your-key>
export OCR_LLM_MODEL=claude-opus-4-6
export OCR_USE_ANTHROPIC=true

ocr reviewコマンドでdiffをレビューする

ocr review（エイリアスはr）が主役のコマンドです。

モードが3つあって、違いはgit参照の指定方法だけです。

ワークスペースモードで未コミットの変更をまとめて見る

引数なしで叩くと、ステージ済み・未ステージ・未追跡の変更を全部拾ってレビューします。

ocr review

コミット前に自分で気づけるので、ここが一番出番が多くなるはずです。

ブランチ間diffは from と to で指定する

ocr review --from main --to feature/payment
ocr review --commit <hash>

--fromと--toでブランチ間、--commit（-c）で単一コミット。

PRを出す前のセルフレビューにそのまま使えます。

--background（-b）でビジネス文脈を渡せるのは覚えておく価値があります。

「この変更は決済のリトライ処理を追加している」と一言添えるだけで、レビューの当たり判定が変わります。

長い文脈はMarkdownにして--background-file（-B）で渡せます。

previewでLLMを呼ばずに対象ファイルだけ見る

ocr review --preview

--preview（-p）はLLMを呼ばずに「今回どのファイルが対象になるか」だけを出します。

デカいdiffにいきなり本番実行して課金だけ溶かす、を防げるので最初の数回は必ず挟んでほしいところです。

そのほかよく触るのがこのあたりです。

フラグ

効果

既定値

--concurrency

ファイル単位の並列数

--timeout

ファイルあたりのタイムアウト（分）

--exclude

gitignore形式で対象から除外

なし

--audience

humanは進捗表示あり、agentはサマリのみ

human

--rule

カスタムルールJSONのパス

なし

走らせたセッションはocr session listとocr session show で後から追えて、トークン使用量まで確認できます。

ocr scanでdiffがないコードベースを丸ごと監査する

ocr reviewはdiffが前提ですが、ocr scan（エイリアスs）はdiffなしでファイル全体を読みます。

ocr scan
ocr scan --path internal/payment

引き継いだばかりのリポジトリや、git履歴が意味をなさない状態のコードに使う想定です。

ocr scanが4フェーズに分かれている理由

ocr scanはPLAN・MAIN・DEDUP・PROJECT_SUMMARYという4フェーズで走ります。

PLAN: どこから読むかの計画を立てる
MAIN: 実際に読んで指摘を出す
DEDUP: 重複した指摘を潰す
PROJECT_SUMMARY: 全体サマリにまとめる

DEDUPが独立フェーズとして切られているのが個人的にアツいところです。

リポジトリ全体をスキャンすると「同じ問題を20ファイルで20回指摘される」が普通に起きますが、そこを畳む工程が最初から入っています。

トークンの上限は--max-tokens-budgetで切れて、丸ごとスキャンは金額が読みにくいのでこれが事実上の安全装置になります。

open-code-reviewの内蔵ルールセットはファイル種別ごとに分かれている

ここが今回いちばん「うわ、そういうことか」となった部分です。

内蔵ルールは1つの巨大プロンプトではなく、ファイル種別ごとに別ドキュメントとして持たれています。

globパターンで32個のルールドキュメントを振り分ける

internal/config/rules/system_rules.jsonが振り分けテーブルの実体で、中身はこんな構造でした。

{
  "default_rule": "default.md",
  "path_rule_map": {
    "**/*.java": "java.md",
    "**/*.{ts,js,tsx,jsx}": "ts_js_tsx_jsx.md",
    "**/*{mapper,dao}*.xml": "mapper_dao_xml.md",
    "**/package.json": "package_json.md",
    "**/*.{tf,hcl,tfvars}": "terraform.md"
  }
}

抜粋ですが、実際は31個のglobパターンが並び、rule_docs配下に32本のルールMarkdownが置かれています。

Java・Go・Python・TypeScript・Rust・Kotlin・C++・PHP・Terraform・GraphQL・Prisma・ArkTSまでカバー範囲が広い。

しかもpom.xmlとpackage.jsonとCargo.tomlにそれぞれ専用ルールが当たるので、依存追加のPRには依存管理の観点でレビューが飛んできます。

どれにも当たらないファイルにはdefault.mdが使われます。

正確性・セキュリティ・パフォーマンス・保守性・テストカバレッジの5軸で、境界条件、例外処理、スレッドセーフティ、SQLインジェクションとXSS、権限チェック、N+1クエリ、リソースの解放漏れといった項目が並んでいました。

JavaScript向けルールにはXSSとReactの落とし穴が並ぶ

ts_js_tsx_jsx.mdを開いたら、想像よりずっと具体的でした。

var禁止、==と!=禁止で===と!==を強制。anyは使うなら理由をコメントで残す
ユーザー入力をinnerHTMLに直接差し込むことを禁止
eval()、Function()コンストラクタ、文字列形式のsetTimeout、document.write()を禁止
ネイティブプロトタイプ（ArrayやObject）の改変を禁止
Reactのhooksがコンポーネントのトップレベルでのみ呼ばれているか
useEffectの依存配列とクリーンアップ関数の妥当性、レンダー内での副作用の有無
React.memoやuseMemoは性能上の根拠があるときだけ使う
非同期関数はエラーハンドリング必須。独立した処理はPromise.all、依存する処理は逐次

「セキュリティに気をつけましょう」ではなく、関数名レベルで書かれています。

ESLintで弾ける項目も混ざっていますが、ESLintには判定できない「useMemoに性能上の根拠があるか」のような判断はLLM側に残す、という分担です。

ocr rules checkでどのルールが当たるか確認できる

このルール振り分け、レビューを走らせなくても確認できます。

ocr rules check src/main/java/com/example/Foo.java
ocr rules check --rule custom.json src/main/resources/mapper/UserMapper.xml

ocr rules checkは「そのファイルにどのルールが適用されるか」を、ルールの出どころのレイヤーとマッチしたパターン付きで返します。

ocr rules listなら現在有効なルール一覧。

触るならまずここから入るのが安全だと思います。

AIコードレビューに決定論パイプラインとLLM Agentを混ぜる意味

「どこまでをコードで固めて、どこからLLMに渡すか」の線引きが、このツールは異様にはっきりしています。

ファイル選択とルール振り分けは決定論側の仕事

公式が決定論パイプラインの担当としているのは、精密なファイル選択、スマートなファイルバンドリング、細粒度のルールマッチング、指摘位置の特定と検証まわりです。

さっきのglob振り分けが、まさに「細粒度のルールマッチング」の実体でした。

.javaファイルにJava用ルールを当てる判断にLLMは要らないし、任せると毎回ブレます。

何度実行しても同じ答えが出るべき工程が、コード側に寄せられています。

Agentは差分の外まで読みに行く

一方でAgent側は、レビュー用にチューニングされたプロンプトとツール群を持っていて、渡された差分の中だけを見て終わりにしません。

ファイル全体を読む、コードベースを検索する、同じPRで変わった他のファイルを確認する。

ここまでやってから指摘を出します。

効くのは、たとえば呼び出し側のnullチェックが消えているケースです。

diffの範囲内だけ見れば「引数の型が変わっただけ」に見える変更でも、呼び出し元まで辿れば落ちるパターンが見えます。

コンテキストを絞りきる設計のAIレビューツールとは、ここが正反対です。

片方は「読ませる範囲を最小にして精度とコストを守る」、こちらは「必要なら能動的に広げる。ただし広げる前の絞り込みは決定論でやる」。

出た指摘はHigh・Medium・Lowの3段階に分かれます。

Highは明らかなバグとセキュリティ問題、Mediumは文脈依存の懸念やスタイル・性能の提案、Lowは誤検知やnitpickで、これは黙って落とされます。

ベンチマークで見るopen-code-reviewの精度とトークン消費

公式が公開しているベンチマークは、条件がわりと具体的です。

50リポジトリ 200PR 10言語 1,505件のイシューで検証

OSSリポジトリ50個、PR 200本、10言語、注釈付きイシュー1,505件というデータセットで、汎用エージェントと比較しています。

指標

汎用エージェント比

大幅に上回る

Precision

Claude Code比で明確に改善

トークン消費

約9分の1

Recall

下回る

Precisionとトークンで勝ち recallでは負ける設計

recallが低いことを公式が隠さず書いているのが、むしろ好印象でした。

「拾える件数を捨てて、指摘の当たり率を取る」という意図的なトレードオフだと明言しています。

これ、レビューツールとしては正しい割り切りです。

誤検知だらけのコメントが50件付いたPRを想像してください。

人間が全部読まなくなって、結局ツールごと使われなくなります。

トークンが9分の1で済むのは、自分のAPIキーで回したときの請求額もそれに近い比率になるということでもあります。

open-code-reviewをCIとエディタに組み込む

手元で回すだけならCLIで十分ですが、チームで使うならCIかエディタに寄せた方が続きます。

GitHub ActionsでPRに行レベルコメントを付ける

リポジトリ直下にaction.ymlがあり、composite actionとしてそのまま呼べます。

- uses: alibaba/open-code-review@main
  with:
    llm_url: ${{ secrets.OCR_LLM_URL }}
    llm_auth_token: ${{ secrets.OCR_LLM_AUTH_TOKEN }}
    llm_model: ${{ vars.OCR_LLM_MODEL }}
    llm_use_anthropic: ${{ vars.OCR_LLM_USE_ANTHROPIC }}
    sticky_summary: 'true'
    incremental: 'true'

内部ではgit merge-baseを計算してocr review --from --to を走らせ、JSON出力をパースしてFiles changedタブに行レベルコメントを投げます。

運用で効くのがsticky_summaryとincrementalです。

前者はサマリコメントを新規投稿ではなく既存の書き換えにするので、pushのたびにコメントが積み上がりません。

後者は既に指摘済みの行と重複するコメントを飛ばします。

重複判定はIoUのしきい値で、既定は0.6。

PRコメントに/open-code-reviewと書いて再レビューを走らせるトリガもあります。

Claude CodeやCodexにコードレビュープラグインとして入れる

CLIを入れた状態なら、コーディングエージェント側からも呼べます。

/plugin marketplace add alibaba/open-code-review
/plugin install open-code-review@open-code-review

これで/open-code-review:reviewと/open-code-review:delegate-reviewが使えます。

Codexはcodex plugin marketplace add alibaba/open-code-review、Cursorはplugins/open-code-review/を~/.cursor/plugins/local/open-code-review/にコピーする方式です。

delegateモードが変わっていて、ocr delegateはocr自身がLLMを呼ばず、レビュー仕様を構造化して外部エージェントに渡します。

つまりClaude Code側のコンテキストとサブスクリプションでレビューを実行させる形です。

この経路ならocr config providerすら不要になります。

open-code-reviewをどう使い分けるか

未知のコードベースを引き継いだときが一番効く

ocr scanはdiffが要らないので、引き継いだばかりのリポジトリに最初にかける監査として噛み合います。

Java・Go・TypeScript・Terraformが混ざった雑多なリポジトリほど、ファイル種別ごとのルール振り分けが活きます。

日常運用ならCIにincremental: 'true'で組み込んで、レビュー担当者が見る前の一次スクリーニングに置くのが現実的です。

人間のレビュアーは、機械が拾えない設計判断とドメインの妥当性に時間を使えます。

open-code-reviewを触る前に知っておきたい注意点

いいところばかり書いてきたので、気になった点も残しておきます。

recallは低い。取りこぼす前提で、人間のレビューを置き換えるのではなく前段に足す使い方が正解です
ツールは無料でもLLMの利用料は自分持ちです。--previewと--max-tokens-budgetを使わずに大規模リポジトリへocr scanを投げると請求が読めません
コードがLLMプロバイダに送られます。社内コードで気になるなら、OpenAI互換の口を持つローカルLLMや社内ゲートウェイをcustom_providersに設定してください
まだv1.8.5でリリース間隔が短い。CIではocr_versionにバージョンを固定した方が安全です

入れて壊れるものではないので、まずはnpm install -g @alibaba-group/open-code-reviewしてocr rules checkに自分のリポジトリのファイルを1本投げてみるところからで十分です。

LLMを呼ばないので無料で、どのルールが当たるかだけ見えます。

そこで「あ、このルール当ててほしかったやつだ」となったら、ocr review --previewに進んでください。