Open Code Reviewとは何か

Open Code Reviewは、Alibabaが社内で2年間運用してきたAIコードレビュー用CLIツールを、2026年5月にオープンソース公開したものだ。決定論的なパイプライン（ファイル選定・バンドリング・ルール照合）とLLMエージェントを組み合わせるハイブリッド構成が特徴で、Git差分を読み込み、行単位で精度の高いレビューコメントを返す。

開発元はAlibaba Group、ライセンスはApache-2.0、実装言語はGo。npm経由でocrコマンドとして配布され、OpenAI・Anthropic互換のLLMエンドポイントを設定して使う。本稿執筆時点（2026年9月22日）でGitHubスター数は約39,400、フォーク数は約2,800、2026年9月15日にはGitHub Trendingの全言語部門で1位を記録した（Trendshift調べ）。同月20日には技術メディアInfoQでも取り上げられている。

Open Code Reviewの核となる設計思想は「決定論的エンジニアリング×エージェントのハイブリッド」だ。公式READMEは、Claude CodeのようなSkillsベースの汎用AIエージェントでコードレビューを行う場合の課題として、①大規模な差分で一部ファイルしか見ない「カバレッジの欠落」、②指摘位置が実際のコードとずれる「ポジションドリフト」、③プロンプトの微妙な違いで品質が変動する「不安定さ」の3点を挙げている。この根本原因を「言語駆動アーキテクチャにはレビュー工程へのハード制約がないこと」だとし、絶対に間違えてはいけない工程（ファイル選定・バンドリング・ルール照合・位置決め）はエンジニアリングロジックで固定し、動的な判断が必要な部分（コード分析）だけをLLMエージェントに任せる設計を採っている。

公式READMEおよびGitHub上のリポジトリ説明文では、内蔵ルールとしてNPE（null-pointer exception）・スレッド安全性・XSS・SQLインジェクションの多言語ルールセットを持つと明記されている。個々のルールの全リストや対応言語ごとの詳細は、本稿執筆時点でリポジトリ内のドキュメントディレクトリではなく公式サイトの「Review Rules」ページに集約されており、パスフィルタリングでルールの適用範囲を絞れる設計になっている。ルールの完全な一覧は公式サイト側の更新に依存するため、導入時は必ず最新のドキュメントで確認してほしい。

- ファイル種別・パスに応じたルールの絞り込み（テンプレートエンジンベースのマッチングで安定動作）
- NPE・スレッド安全性など言語共通の欠陥パターン
- XSS・SQLインジェクションなどWebアプリのセキュリティ欠陥
- ルール適用はモデルへの丸投げではなく、決定論的な照合ロジックが担う

前提としてGit 2.41以上が必要（差分生成・コード検索・リポジトリ操作に利用するため）。公式にはnpm経由のインストールが案内されている。

インストールスクリプトやGitHub Releaseのバイナリ配布、ソースからのビルドにも対応しているが、具体的な手順は公式サイトの「Installation」ページで案内されている。

通常モード（OCR自身がLLMを呼び出すモード）では、レビュー実行前にLLMプロバイダーの設定が必須になる。対話式のセットアップコマンドでプロバイダー選択・APIキー入力・モデル選択・接続テストまで行える。

OpenAI互換・Anthropic互換のエンドポイントであればカスタムプロバイダーとして登録できる。環境変数や設定ファイルによる詳細設定は公式サイトの「Configuration」ページに記載されている。

最短ルートは、プロジェクト直下でocr reviewを叩くだけだ。ステージ済み・未ステージ・未追跡の変更をまとめて確認してくれる。

手元でClaude CodeやCodex、Cursorなどのコーディングエージェントを既に使っている場合は、Delegation Modeが有効だ。OCR自体はLLMを呼ばず、ファイル選定・ルール解決だけを担当し、実際のレビューはユーザーが使っているエージェントのLLMで実行される。OCR用のAPIキー設定が不要になる。

公式ドキュメントではGitHub Actions・GitLab CI・GitFlic CI・Gerritへの統合が案内されている（具体的なYAML設定例は公式サイトの「CI/CD Integration」ページに掲載されており、本稿執筆時点でREADME本体には記載がない）。PR作成時に自動でレビューを走らせ、結果をコメントとして返す運用が想定されている。CI組み込みを検討する場合は、まずローカルでocr reviewを試し、ルール適用範囲やノイズの量を確認してからパイプラインに組み込むのが安全だ。

AIコードレビューのカテゴリにはすでにCodeRabbit・GitHub Copilotのコードレビュー機能・Greptileなどの選択肢があり、従来型の静的解析ツールであるSonarQubeも根強く使われている。Open Code Reviewの立ち位置を掴むには、これらとの違いを押さえておくとよい。

公式ベンチマーク（50リポジトリ・200件のPR・10言語・80人以上のエンジニアによる1,505件の正解アノテーション、通称AACR-Bench）では、同じモデルを使った場合にClaude Codeより高い的中率とF1スコアを、約1/9のトークン消費で達成したとされる一方、網羅性（Recall）は汎用エージェントより低いことが公式に明示されている。Shopifyのシニアエンジニア Tom Rochette 氏はこの構成を「実際のエージェントの失敗パターンを狙った設計」だと評価しつつ、独立した検証（The Martian Benchmark、10件のPR）では的中率が約12%に留まったと指摘している（開発元はツール呼び出しの異常が原因だとして修正済みとしているが、本稿執筆時点で修正後の独立検証は確認できていない）。HCLTechのDaniel Vaughan氏も、AACR-Bench上で最良設定でも網羅性は20%にとどまり、専門家が見つける欠陥の8割は検出できない計算になると指摘している。数値はいずれも各社・各記事の公表値であり、自社のコードベースで検証することが前提になる。

- 向いている人：誤検知（ノイズ）を減らしてレビューコストを下げたいチーム／LLMのAPIコストを抑えたいチーム／自社インフラでセルフホストしたい・特定のLLMプロバイダーを使いたいチーム／すでにClaude Code等のコーディングエージェントを使っておりDelegation Modeで追加費用なく導入したいチーム
- 向いていない人：見逃しを極力ゼロに近づけたい（網羅性最優先の）チーム／CIへのYAML組み込み例など手厚いサポート付きSaaSを求めるチーム／エンジニアリングリソースをかけずにすぐ本番導入したいチーム

Open Code Reviewは、決定論的パイプラインとLLMエージェントを組み合わせることで、AIコードレビューにありがちな「カバレッジの欠落」「位置ズレ」「品質のブレ」に正面から対処しようとするツールだ。的中率とトークン効率を優先する代わりに網羅性を抑える設計思想は、CodeRabbitやGitHub Copilotのコードレビュー機能、SonarQube等の静的解析とは異なる立ち位置にある。一方で独立検証の結果にはばらつきがあり、公式ベンチマークの数値をそのまま鵜呑みにせず、自社のコードベースで試してから本番導入を判断するのが安全だ。AIエージェントの活用事例はOrcaによる並列開発環境の記事でも紹介している。セキュリティ観点でのIT対策全般は脆弱性診断・ペネトレーションテストの費用相場も参考になる。社内へのAIツール導入や開発体制づくりはソフトウェア開発・AIコンサルティングでも支援している。相談はお問い合わせから。