AIコードレビューを自動化したいとき、多くの人がまず試すのは「Claude CodeのようなAIエージェントに『このPRをレビューして』と頼む」やり方だ。ところが実際に大きな変更で回すと、一部のファイルしか見てくれなかったり、指摘された行番号が実際のコードとズレていたり、同じPRなのに実行のたびに結果がぶれたりする。この「なんとなく頼りない」を、Alibaba社内で2年間・数万人の開発者に揉まれた設計で解こうとするのが Open Code Review（コマンド名 ocr）である。

Open Code Review（alibaba/open-code-review）は、Git diffを設定可能なLLMに渡し、行単位のレビューコメントを生成するAIコードレビューCLIだ。もともとAlibaba Groupの社内公式ツールとして稼働し、公式によれば累計で数万人が利用し数百万件の欠陥を指摘してきたものを、コミュニティ向けにOSS化したとされる。GitHubスターは約11,400、フォーク約790、ライセンスはApache-2.0、実装はGo。npm（@alibaba-group/open-code-review）でインストールすれば、どのリポジトリからでも ocr コマンドで呼び出せる。

Open Code Reviewの全体像。Git diffを決定論パイプラインとLLMエージェントのハイブリッドでレビューし、行単位コメントを返す。スター約1.1万、Apache-2.0、Alibaba本番実績。
Open Code Reviewの全体像（GitHub API実測値・公式READMEより作成）。決定論パイプラインとLLMエージェントを組み合わせ、diffレビューとfull-fileスキャンの両方を行単位で返す。
30秒でわかる Open Code Review（2026年7月時点）
  • ・正体：Alibaba発のAIコードレビューCLI（OSS）。社内公式ツールをOSS化。GitHubスター約11,400、最新リリース v1.7.15、ライセンス Apache-2.0、実装は Go。
  • ・何ができる：Git diff を LLM（OpenAI/Anthropic互換）に渡して行単位のレビューコメントを生成。diffだけでなくocr scanでファイル全体の棚卸しも可能。
  • ・特徴：決定論エンジニアリング × エージェントのハイブリッド。ファイル選定・ルール適用を機械的に固定し、汎用エージェントの取りこぼし・位置ズレ・品質ブレを抑える設計。
  • ・セキュリティ観点：NPE・thread-safety・XSS・SQLインジェクションに注意を向ける組み込みルールを内蔵。ただし決定論的SAST（Semgrep等）の代替ではなく、AIレビューでの補完的な検出。
  • ・連携：Claude Code / Codex / Cursor へのSkill・Plugin、CI/CD（GitHub Actions・GitLab CI・Gerrit等）、MCPサーバー、Session Viewer。

この記事ではセルフホストできるDevOps/開発支援ツールとしてOpen Code Reviewを解説します。ノーコードからコードまでの自動化ツール全体像は AI自動化ツール｜ノーコードからコードまで2026年版の比較と選び方 をご覧ください。

Open Code Reviewとは：Alibaba本番実績のAIコードレビューOSS

Open Code Reviewが解決しようとしているのは、「変更されたコードを、人間のレビュアーの負担を増やさずに、継続的かつ安定した品質でチェックし続ける」という地味だが終わりのない仕事だ。公式の説明はシンプルで、AIによるコードレビューのCLIツールであり、モデルのエンドポイントを設定するだけで使い始められる、というものだ。

動作の流れはこうだ。まずGitのdiffを読み取り、変更されたファイルを、ツール利用（tool-use）能力を持つエージェント経由で、設定したLLMへ送る。エージェントはファイル全体を読み、コードベースを検索し、他の変更ファイルを文脈として参照しながら、表面的なdiffコメントにとどまらない「深いレビュー」を生成する。出力は自然言語のコメントではなく、行単位（line-level）に紐づいた構造化されたレビューコメントだ。さらにdiffレビューだけでなく、ocr scan を使えば、意味のあるdiffが無い既存ディレクトリや、初めて触る不慣れなコードベースを、ファイル全体を対象に監査することもできる。

読者にとって「Open Code Reviewは結局何なのか」を一言でいえば、Git diffやファイル全体をLLMに渡し、行単位の指摘に落とし込むセルフホスト可能なAIコードレビューの実行基盤だ。OpenAIとAnthropicの両方のAPIに対応し、自前のモデルエンドポイントやローカルLLMを指すこともできる。SaaSのAIコードレビューサービスがやっていることを、モデルの選択とデータの流れを自分の手元に置いたまま再現する、と捉えると位置づけがはっきりする。

Open Code Reviewの主要指標。Alibaba社内で2万人以上が利用、採用率30%超、累計100万件超のレビュー、Claude Code比でトークン約9分の1、AACR-Bench（SEM.F1）25.10%。
公式が掲げる主要指標。「Alibaba社内で2万人以上が利用」「累計100万件超のレビュータスク」「Claude Code比でトークン約1/9」などはいずれもAlibaba公式の公称値（出典: alibaba/open-code-review 公式README）。

実測で確認したプロジェクトの規模

記事化にあたり、2026年7月24日時点の実データをGitHub APIで確認した。数字は次のとおりだ。

・⭐ GitHubスター：約 11,400（フォーク約790）
・📦 最新リリース：v1.7.15（2026年7月22日公開）／v1.6〜v1.7系で数日おきに更新される高頻度リリース
・👥 コントリビュータ：約 30人（Alibabaがバックする企業プロジェクト）
・🛠️ 主要言語：Go（CLI本体）。配布はnpm（@alibaba-group/open-code-review）とGitHub Releaseバイナリ
・🗓️ 作成：2026年5月18日／直近プッシュ：2026年7月23日（開発は現役で活発）
・🏢 開発元：Alibaba（社内公式ツールをOSS化）。OpenSSF Best Practices は Silver 認定
・📄 ライセンス：Apache-2.0（Copyright 2026 Alibaba）

2026年5月に公開されたばかりの若いプロジェクトながら、2か月弱でスター1.1万超という立ち上がりは、AIコードレビューという競争の激しいジャンルでも突出している。公式サイト（open-codereview.ai）とDeepWikiによるドキュメントも整備されており、単発の実験的リポジトリではなく、継続運用を前提に体裁が整えられている点が読み取れる。

読者の3つの問いへの答え
① 何ができる：Git diff／ファイル全体をLLMに渡し、行単位の構造化レビューコメントを生成する。② 何を解決する：汎用エージェント任せのレビューで起きる「取りこぼし・位置ズレ・品質ブレ」を、決定論的な工程で抑える。③ 何を代替できる：SaaS型AIコードレビューを、モデルとデータを自分で握るセルフホスト形で置き換える候補になる。

なぜ「決定論エンジニアリング × エージェント」なのか：AIコードレビューの3つの弱点

Open Code Reviewの設計思想を理解する鍵は、公式が名指しする「汎用エージェントによるコードレビューの弱点」にある。Claude CodeにSkillを持たせてコードレビューをさせた経験がある人なら、次の3点に心当たりがあるはずだ、と公式は述べている。

・取りこぼし（Incomplete coverage）：変更量が大きいと、エージェントは「手を抜いて」一部のファイルだけを選んでレビューし、残りを見落とす傾向がある
・位置ズレ（Position drift）：報告された指摘が実際のコード位置と一致せず、行番号やファイル参照が本来の対象からずれることが頻発する
・品質のブレ（Unstable quality）：自然言語で駆動されるSkillはデバッグが難しく、わずかなプロンプトの違いでレビュー品質が大きく揺れる

公式はこの根本原因を「純粋に言語で駆動されるアーキテクチャには、レビュー工程に対する『ハードな制約』が欠けていること」だと整理する。そこで採ったのが、決定論的なエンジニアリングとエージェントを組み合わせ、それぞれが得意な領域を担う設計だ。

flowchart TD A["Git diff / 対象ファイル"] --> B["【決定論】ファイル選定
レビュー対象と除外を機械的に確定"] B --> C["【決定論】ファイルのまとめ方
関連ファイルを1レビュー単位にバンドル"] C --> D["【決定論】ルールマッチング
ファイル特性に応じてルールをテンプレ適用"] D --> E["【エージェント】動的レビュー
ファイル読込・コード検索・文脈参照"] E --> F["【決定論】位置特定・リフレクション
コメント位置と内容を外部モジュールで補正"] F --> G["行単位の構造化レビューコメント"]

決定論エンジニアリング（ハードな制約） が担うのは、「間違えてはいけない」工程だ。公式が挙げるのは次の4つである。

・精密なファイル選定：どのファイルをレビューし、どれを除外するかを正確に決め、重要な変更の見落としを防ぐ
・スマートなファイルのまとめ方（bundling）：関連ファイル（例：message_en.properties と message_zh.properties）を1つのレビュー単位にまとめる。各バンドルは文脈を分離したサブエージェントとして走るため、巨大な変更でも安定し、並列レビューにも自然に対応する
・きめ細かなルールマッチング：各ファイルの特性に合わせてレビュールールを対応づけ、モデルの注意を絞り込む。言語による曖昧なルール指示より、テンプレートエンジンでのルール適用のほうが安定して予測可能だとする
・外部の位置特定・リフレクションモジュール：コメントの位置決めと内容の見直しを独立したモジュールが担い、AIの指摘の「どこに・何を」の精度を系統的に引き上げる

一方、エージェント（動的な意思決定） の強みは、動的な判断と動的な文脈取得という「本当に価値が出る」ところに集中させる。公式は、コードレビュー向けに深く最適化したプロンプトテンプレートと、本番の大規模データからツール呼び出しの傾向（呼び出し頻度の分布・ツールごとの反復率・新ツールが呼び出し連鎖に与える影響）を分析して蒸留した専用ツールセットを用意した、と説明している。要するに、汎用エージェントの「なんでもできるツール箱」ではなく、コードレビューという場面に絞って安定させた道具立てに作り替えている、というわけだ。

このハイブリッド設計は、当サイトで以前解説した CloudflareのAIコードレビューシステム解剖｜7専門エージェント並列実行の仕組みと実績 が「複数の専門エージェントに分業させる」方向で品質を担保しているのと、狙いは似ていて実装の重心が異なる。Cloudflareがエージェントの分業に寄せているのに対し、Open Code Reviewは「エージェントに任せる前後を決定論で固める」ことに重心を置いている。

Open Code Reviewの主要機能：diffレビュー・full-fileスキャン・delegation・CI連携

Open Code Reviewの機能は、「どこをレビュー対象にするか」と「どう組み込むか」の両輪で構成されている。READMEと公式ドキュメントが挙げる主要機能を、実務での使いどころとともに整理する。

Open Code Reviewの主要機能。ocr review・ocr scan・delegate・CI/CD・MCPサーバー・Session Viewerの6機能。
Open Code Reviewの主要機能を機能単位で整理（出典: alibaba/open-code-review 公式README・open-codereview.ai/docs）。

diffレビュー（ocr review）：もっとも基本的な使い方で、変更内容をレビューする。作業ツリー全体（staged・unstaged・untrackedを含む）を対象にする「workspaceモード」、--from main --to feature-branch のように2つのref間を比較する「ブランチ範囲モード」、--commit abc123 で単一コミットを対象にするモードがある。長い範囲やコミットのレビューが途中で中断しても、ocr session list で確認したセッションIDを --resume に渡せば再開できる。

full-fileスキャン（ocr scan）：diffではなくファイルの中身全体をレビューする。意味のあるdiffが存在しない既存コードや、初めて触るリポジトリ・ディレクトリの棚卸しに向く。ocr scan でリポジトリ全体を、ocr scan --path internal/agent で特定ディレクトリやファイルだけを対象にできる。後述するセキュリティ観点の「自分のリポで確認する」使い方は、この ocr scan が主役になる。

Delegation Mode（ocr delegate）：レビューを、自分が使っているAIコーディングエージェント（Claude Code等）自身に実行させるモードだ。Open Code Reviewはファイル選定とルール解決だけを担い、LLMの設定は不要になる。ocr delegate preview でプレビューし、ocr delegate rule src/main.go src/handler.go のように対象を指定する。API課金を避けつつ、OCRの「決定論的な前処理」だけを借りたいときに効く。

CI/CD統合とエージェント連携：GitHub Actions・GitLab CI・GitFlic CI・Gerrit への統合が用意され、PRやMRのパイプラインに組み込める。加えて、SkillやPluginとしてClaude Code / Codex / Cursor に組み込む導線、外部ツールを足せるMCPサーバー、ブラウザでレビューセッションを閲覧・再生するSession Viewer、そしてOpenTelemetryによる可観測性連携も持つ。対応OSはWindows・macOS・Linuxだ。

読者の3つの問いへの答え
① 何ができる：diffレビュー（workspace/ブランチ範囲/単一コミット）とファイル全体スキャンを、行単位コメントで返す。② 何を解決する：レビューの実行基盤を、CIにもエージェントにも組み込める形で標準化する。③ 何を代替できる：SaaSのレビューbotや、手作業のセルフレビュー工程の一部を自動化する。

XSS・SQLi・NPE・thread-safetyを自分のリポジトリで確認するコマンド

Open Code Reviewを当サイトの読者に薦めたい最大の理由が、セキュリティ観点のレビューを自分のリポジトリで手軽に回せる点だ。GitHubのリポジトリ説明にも明記されているとおり、本ツールにはNPE（Null Pointer Exception）・thread-safety・XSS・SQLインジェクションといった典型的な欠陥に注意を向けるよう作り込まれたルールセットが組み込まれている。ここでは、インストールから「自分のコードにこれらの兆候が無いかを確認する」までのコマンドを追ってみる。

まず、npmでグローバルインストールする（前提としてGit 2.41以上が必要）。

# インストール（ocr コマンドが使えるようになる）
npm install -g @alibaba-group/open-code-review
ocr --version

次に、レビューに使うLLMを設定する。対話UIがプロバイダ選択・APIキー入力・モデル設定を案内し、接続テストまで自動で行う。

# LLMプロバイダとモデルを設定（OpenAI / Anthropic 互換）
ocr config provider   # 組み込みプロバイダを選ぶ or カスタム追加
ocr config model      # そのプロバイダで使うモデルを選ぶ

設定が済んだら、自分のリポジトリでファイル全体スキャンを回す。diffが無い既存コードでも、コード全体を対象にレビューが走るため、「今あるコードに危ういパターンが無いか」を棚卸しできる。

cd your-project

# リポジトリ全体をスキャン（既存コードの棚卸し）
ocr scan

# 気になるディレクトリやファイルだけに絞る
ocr scan --path internal/handler internal/auth

# 変更分だけをセキュリティ観点も含めてレビューしたいとき
ocr review --from main --to feature-branch

ocr scan は変更の有無に関係なくファイルの中身を読むため、XSSにつながる未エスケープの出力や、SQLインジェクションの温床になる文字列連結クエリ、NPEを招く未チェックの参照、共有状態への非同期アクセス（thread-safety）といった、組み込みルールが狙う欠陥クラスを指摘の候補として拾い上げる。指摘は行単位で紐づくため、「どのファイルの何行目か」がはっきりする。

⚠️ 正確に理解しておきたい「AIレビュー」と「SAST」の違い
  • ・ocr scan はLLMを呼び出すAIレビューであり、Semgrep・CodeQL のような決定論的な静的解析（SAST）ではない。抽象構文木を機械的に走査する手法とは仕組みが異なる。
  • ・したがって網羅性・再現性は保証されない。同じコードでもモデルやプロンプト条件で結果が変わりうるし、実行にはLLMの設定（API課金）が必要。
  • ・専用SASTや npm audit／依存関係スキャンを置き換えるものではなく、レビュー工程でセキュリティ観点の指摘を早めに拾う補完と位置づけるのが正確。AIコードレビューとセキュリティの橋渡しとして使う。

この「自分のリポジトリで確認するコマンド」を持てることが、単なるレビューbot以上の価値だ。サプライチェーンや脆弱性そのものへの体系的な備えは、別途 サプライチェーンセキュリティ2026｜攻撃手法・防御ツール・実践チェックリスト（当サイトのセキュリティピラー）のような専門的なチェックリストと、専用のSAST/依存監査を組み合わせるのが本筋である。Open Code Reviewはその手前で、日々のレビューにセキュリティ観点を織り込むための入口になる。

他のAIコードレビューツールとの比較：Kodus・CodeRabbit・汎用エージェント

AIコードレビューのOSS・SaaSは数多い。Open Code Reviewの立ち位置を、代表的な選択肢と並べて整理する。数値・特徴はいずれも各ツールの公称情報に基づく（優劣を断定するものではなく、設計思想の違いを示すためのものだ）。

観点 Open Code Review Kodus（Kody） CodeRabbit 等SaaS 汎用エージェント直（Claude Code等）
提供形態 OSS・CLI（セルフホスト） OSS・セルフホスト SaaS中心 エージェント＋自作Skill
ライセンス Apache-2.0 MIT系OSS プロプライエタリ 各エージェント準拠
アーキテクチャ 決定論パイプライン×LLMエージェント AST＋LLMハイブリッド 各社独自（多くはLLM＋独自解析） 純・言語駆動
セキュリティ観点ルール NPE/thread-safety/XSS/SQLi の組み込みルール ルールを.kody/rules/でgit管理 各社の検出ルール プロンプト次第
対象 diff＋full-fileスキャン 主にPR/diff 主にPR 指示した範囲
モデル選択 OpenAI/Anthropic互換・自前EP可 Ollama含む自由選択 各社指定が中心 エージェントのモデル
CI連携 GitHub Actions/GitLab/Gerrit等 各種CI 各社連携 要自作

同じOSSのAIコードレビューでも、当サイトで解説した Kodus（Kody）入門｜AIコードレビューのチーム標準を.kody/rules/でgit管理するOSS は「チームのレビュー標準を .kody/rules/ としてgit管理し、レビュー履歴からルールを育てる学習ループ」に重心がある。対してOpen Code Reviewは「決定論的な前処理でエージェントの弱点を封じる」ことに重心を置く。狙う課題が微妙に違うため、両者は排他ではなく併読して自分のチームの痛点に近いほうを選ぶのがよい。SaaSも含めた横断比較は AIコードレビューツール比較2026｜CodeRabbit・Greptile・Qodo・Bito・Sourcery・Codacyを使い分け解説 に、レビューそのものの原則は Google Engineering Practices完全解説：GitHubで公開されたGoogleのコードレビュー指針を読み解く にまとめている。

なお、コードベースを知識グラフ化してレビューのトークン消費を削るアプローチ（当サイトで扱った Code Review Graph など）は、Open Code Reviewとは目的が異なる別系統のツールだ。前者が「AIに渡す文脈の作り方」を最適化するのに対し、Open Code Reviewは「レビュー工程そのものの制御」を最適化する。

ベンチマーク：同一モデルでの精度とトークンのトレードオフ

Open Code Reviewは、自社で構築した実世界ベンチマーク「AACR-Bench」の結果を公開している。50の人気OSSリポジトリ・200の実PR・10言語から作られ、80人以上のシニアエンジニアがクロス検証した1,505件の正解データを持つ、とされる。

AACR-Benchのランキング表。同一モデルでも、Open Code Review経由のほうがClaude Code経由よりF1・Precisionが高く、消費トークンが大幅に少ない。
Alibaba公式のベンチマーク「AACR-Bench」（Open Code Review v1.3.1時点の公称値）。同一モデルでの Open Code Review 経由と Claude Code 経由を比較している（出典: alibaba/open-code-review 公式README）。

このベンチマークで公式が強調しているのは、汎用エージェントと同じ土台モデルを使った場合、Open Code Reviewは Precision と F1 が高く、消費トークンは約9分の1で、レビューも速いという点だ。たとえば表では、同一モデルをOpen Code Review経由で回した行がClaude Code経由の行より上位に並び、消費トークンは数百K対数百万Kという桁の差がついている。一方で Recall（実在する欠陥のうち見つけられた割合）は汎用エージェントより低い。これは公式自身が「ノイズより精度を優先した意図的なトレードオフ」と明記している。つまり「取りこぼしを完全に無くす」より「誤検知を減らして、指摘の信頼度を上げる」方向に振った設計だ、と読める。

ここで注意したいのは、AACR-BenchはAlibaba自身が設計・測定した自社ベンチマークであり、比較対象や指標の取り方も含めて提供元の公称値だという点だ。数値は「Open Code Reviewがどういう方向に最適化されているか」を理解する材料としては有用だが、第三者が同条件で再現・検証したものではない。導入判断では、自分のリポジトリで小さく試して、指摘の質とトークン消費を実測するのが確実だ。

導入手順とAIコーディングエージェント連携（Claude Code / Codex / Cursor）

改めて、導入から連携までの流れを通しで整理する。前提はGit 2.41以上のみとシンプルだ。

インストールはnpmが最短だが、インストールスクリプト・GitHub Releaseのバイナリ・ソースからのビルドも公式ドキュメントに用意されている。設定は対話UIが接続テストまで案内してくれる。

Open Code Reviewのプロバイダ設定画面。対話UIでプロバイダ選択・APIキー入力・モデル設定・接続テストを案内する。
`ocr config provider` の対話UI。プロバイダ選択からAPIキー入力・モデル設定・接続テストまでを案内する（出典: alibaba/open-code-review 公式README）。

CIに組み込む場合は、レビュー対象のブランチ範囲を指定して ocr review を呼ぶのが基本形だ。GitHub Actionsなら、PRのheadとbaseを渡す形になる（詳細な設定は公式のCI/CDドキュメントに従う）。

# CIでの基本形（例：baseブランチと比較してレビュー）
ocr review --from "$BASE_REF" --to "$HEAD_REF"

# レビュー結果をJSONなどで取り出してPRコメントに反映する運用も可能
ocr session list

AIコーディングエージェントと組み合わせる場合は、大きく2通りある。1つは Skill / Plugin としてClaude Code・Codex・Cursorに組み込み、エージェントの中からOpen Code Reviewのレビュー能力を呼ぶ形。もう1つは前述の Delegation Mode で、レビューの実行自体はエージェント側のLLMに任せ、Open Code Reviewは「どのファイルをどのルールでレビューすべきか」という前処理だけを担う形だ。API課金を一元化したい、あるいは既にエージェントを日常的に使っているチームには、Delegation Modeが馴染みやすい。

運用が回り始めたら、ブラウザでレビュー履歴を再生するSession Viewerでレビューの傾向を振り返ったり、OpenTelemetry連携でレビューのレイテンシやトークン消費を可観測性基盤に流したりできる。レビューを「一回きりの実行」ではなく「継続的に計測・改善する対象」として扱える作りになっている点は、本番運用を経てきたツールらしい配慮だ。

Open Code Reviewの注意点と向き・不向き

最後に、導入前に織り込んでおきたい注意点を正直に整理する。

・Recallは高くない（意図的）：公式が明言するとおり、精度優先で取りこぼしが出る設計だ。「これを通せば重大な欠陥はゼロ」という安全網ではなく、レビュアーの負担を減らす補助として捉える
・ベンチマークは自社測定：AACR-Benchの数値は提供元の公称値であり、第三者検証ではない。導入判断は自分のリポジトリでの実測を優先する
・LLMのコストと設定が必要：レビュー実行にはLLM呼び出しが伴い、API課金が発生する。避けたい場合はDelegation Modeでエージェント側に委譲する
・セキュリティはSASTの代替ではない：XSS/SQLi等の組み込みルールは有用だが、決定論的SASTや依存監査と併用する前提で使う
・若いプロジェクト：2026年5月公開でコントリビュータは約30人。Alibabaバックで更新は活発だが、機能・CLIのインターフェースは今後も変わりうる
・ライセンスはApache-2.0：商用利用・改変・再配布に寛容で、セルフホストの障壁は低い

向いているのは、モデルとレビューデータを自分たちで握りたいチーム、CIやエージェントにレビューを組み込みたい開発者、そして巨大な変更でも取りこぼしなく安定してレビューを回したい現場だ。逆に、SASTのような網羅的・決定論的な検査を求めるユースケースや、レビューにコストをかけたくない個人の小規模プロジェクトでは、無理に置き換える必要はない。まずは ocr scan を1つのディレクトリに当てて、指摘の質とトークン消費を自分の目で確かめるところから始めるのが、いちばん確実な評価方法である。

参照ソース

・alibaba/open-code-review — GitHubリポジトリ（README・ライセンス・リリース。2026年7月24日にGitHub APIで実測）
・Open Code Review 公式サイト（機能・ベンチマーク・ドキュメント）
・Open Code Review Documentation（Quickstart・CLI Reference・CI/CD・MCP・Delegation Mode 等）