オープンコードレビュー – AI搭載のコードレビューCLIツール

14時間前原文(github.com)

概要

Open Code Review はAlibaba Group発の AIコードレビューCLIツール
大規模運用実績 を経て オープンソース化
決定論的エンジニアリング とエージェントの ハイブリッド設計
CLI・CI/CD・AIエージェント連携 など多彩な導入方法
柔軟なレビュー規則・高精度なコメント位置特定 を実現

Open Code Reviewとは

Open Code Review は、 AIを活用したコードレビューCLIツール
元は Alibaba Group社内公式AIコードレビューアシスタント として開発
- 過去2年間で 数万人以上の開発者、 数百万件のコード欠陥検出実績
大規模な社内検証 を経て オープンソース化
モデルエンドポイント設定のみ で即利用可能
Git diff読み取り、 LLMへの送信、 構造化されたレビューコメント生成
- 行単位の精密なコメント付与 が可能
ファイル全体の読取・コードベース検索・変更ファイルの文脈把握 など 深いレビュー を実現

一般的なAIエージェントの課題

カバレッジ不足 ：大規模変更時に 一部ファイルのみレビュー し、他を見落とす傾向
コメント位置のズレ ： 行番号やファイル参照が不一致 となる問題
品質の不安定さ ：自然言語駆動型スキルは デバッグ困難 で品質が揺らぎやすい
根本原因 ： 完全な自然言語駆動 では レビュー工程にハードな制約を設けられない

コア設計：決定論的エンジニアリング × エージェントハイブリッド

決定論的エンジニアリング （ハード制約担当）
- 正確なファイル選択 ：レビュー対象/除外をロジックで厳密管理
- 関連ファイルのスマートバンドル ：例）多言語プロパティファイルを1ユニット化
  - 各バンドルが 独立したサブエージェント として動作し、 大規模変更にも安定対応
- きめ細かなルールマッチング ：ファイル特性ごとに モデルの注意を集中 させ 情報ノイズ排除
- 外部コメント位置・反映モジュール ： コメント位置と内容の精度向上
エージェント （動的意思決定担当）
- シナリオ最適化プロンプト ：コードレビュー専用に設計、 トークン消費削減
- 専用ツールセット ：大規模運用データから 呼び出し頻度・繰返し率・効果検証 済み
  - 汎用エージェントよりも安定・予測可能

インストール・導入方法

CLIインストール（推奨）
- npm install -g @alibaba-group/open-code-review でグローバル導入
GitHub Releaseからバイナリ取得
- macOS/Linux/Windows向けに各種バイナリ提供
ソースからビルド
- git clone → make build → sudo cp ...
LLM設定必須
- 対話式設定 or 環境変数でエンドポイント・APIキー・モデル名等を指定
- 設定ファイル：~/.opencodereview/config.json
接続テスト ：ocr llm test
レビュー実行
- ワークスペース全体：ocr review
- ブランチ差分：ocr review --from main --to feature-branch
- 単一コミット：ocr review --commit abc123

AIコーディングエージェント連携

Skillとして組込
- npx skills add alibaba/open-code-review --skill open-code-review
Claude Codeプラグインとして追加
- /plugin marketplace add alibaba/open-code-review
- /plugin install open-code-review@open-code-review
コマンドファイル直接コピー
- チーム単位・ユーザー単位で.claude/commandsや~/.claude/commandsへ設置
前提：CLI本体とLLM設定が必要

CI/CD統合

CIパイプライン対応 ：Merge Request/Pull Request自動レビュー
コアコマンド ：
- ocr review --from "origin/main" --to "origin/feature-branch" --format json
  - --format jsonで 機械可読な出力 をCIスクリプトで解析可能
サンプルディレクトリ
- github_actions/（GitHub Actions用）
- gitlab_ci/（GitLab CI用）

主なコマンド・フラグ一覧

ocr review（ocr r）: コードレビュー開始
ocr rules check <file>: 指定ファイルに適用されるレビュー規則を確認
ocr config set <key> <value>: 設定値の変更
ocr llm test: LLM接続テスト
ocr viewer（ocr v）: WebUIセッションビューア起動（localhost:5483）
ocr version: バージョン情報表示

ocr review主なフラグ

--repo: レビュー対象のGitリポジトリルート
--from/--to: 比較元/先リファレンス
--commit（-c）: 単一コミット指定
--preview（-p）: 対象ファイルのみプレビュー（LLM呼び出しなし）
--format（-f）: 出力形式（text/json）
--concurrency: 並列レビュー数
--timeout: タスクタイムアウト（分）
--audience: human/agent（進捗表示 or サマリのみ）
--rule: カスタムJSONルールパス
--max-tools: ファイルごとの最大ツール呼出し回数
--tools: カスタムツール設定パス

使用例

対象ファイルのプレビュー：ocr review --preview
単一コミットのプレビュー：ocr review -c abc123 -p
デフォルト設定でワークスペースレビュー：ocr review
ブランチ差分を高並列でレビュー：ocr review --from main --to my-feature --concurrency 4
JSON出力で詳細レビュー：ocr review --commit abc123 --format json --audience agent
カスタムルール適用：ocr review --rule /path/to/my-rules.json
ファイルごとのルール確認：ocr rules check src/main/java/com/example/Foo.java
WebUIで履歴表示：ocr viewer --addr :3000

セッションビューアのセキュリティ

ローカルのみ許可 （localhost, 127.0.0.1, ::1等）
ワイルドカードバインドや非ローカルの場合 は環境変数OCR_VIEWER_ALLOWED_HOSTSで許可ホスト指定
DNSリバインディング攻撃防止策 を実装

レビュー規則

4層優先度チェーン によるルール解決（最初にマッチしたものを適用）
1. --rule指定（CLI明示上書き）
2. プロジェクト設定（.opencodereview/rule.json）
3. グローバル設定（~/.opencodereview/rule.json）
4. システムデフォルト（組込rules）
ルールファイル形式 ：JSON（pathパターンとrule内容のペア）
パターン ：**の再帰一致、波括弧展開（例：{java,kt}）
レイヤー内は宣言順優先、ルールファイルがなければスキップ

設定ファイル・環境変数

設定ファイル ：~/.opencodereview/config.json
- llm.url（例：https://api.openai.com/v1/chat/completions）
- llm.auth_token（APIキー）
- llm.model（モデル名）
- llm.use_anthropic（Anthropic利用有無）
- language（English/Chinese、デフォルトはChinese）
- テレメトリ関連設定
優先順位 ：環境変数 > 設定ファイル
主な環境変数
- OCR_LLM_URL：LLMエンドポイントURL
- OCR_LLM_TOKEN：APIキー/認証トークン
- OCR_LLM_MODEL：モデル名
- OCR_USE_ANTHROPIC：Anthropic利用有無

Hackerたちの意見

これ試してみたいな。うちでは内部の自動レビューをやってて、いい結果が出てるんだけど、もっと良いものがあればそっちに切り替えたい。コードレビューが今のボトルネックだから、もっと自動化できる可能性があれば大歓迎だよ。

└

最近このコードレビューのスキルが好きで、いい改善点を指摘してくれるんだ。https://github.com/cursor/plugins/blob/main/cursor-team-kit/...

└

誰かが提案したサーモ核はいいね。マット・ポコックがそのデモや解説をやってるよ: https://www.youtube.com/watch?v=mh5XZ-L5SFQ 彼は「improve-codebase-architecture」スキルも持ってる: https://github.com/mattpocock/skills/blob/main/skills/engine... いくつかは一般的なコーディングガイドラインやコード品質に関するもので、必ずしも現在のPRを仕様に照らしてチェックするわけじゃない！AbsolutelySkilledにはクリーンコードやクリーンアーキテクチャがあるよ。古いバージョンのリポジトリにリンクしてるのは、もうトランクにないみたいだから: https://github.com/AbsolutelySkilled/AbsolutelySkilled/tree/... 自分のJavaコーディングを助けるためにいくつかルールを作ってる: https://github.com/bitkentech/shipsmooth/tree/main/skills/ex.... このスキルファイルテンプレートが作られるときに、これらはSKILLファイルにまとめられるよ: https://github.com/bitkentech/shipsmooth/blob/main/skills/ex...

Codexを使ってるなら、Codexのデフォルトアプリに対して何が追加されるの？ちょっと混乱してるんだけど、別のタブでCodexにコードレビューを頼むだけじゃダメなの？

└

ベンチマークが必要だね。

└

おそらく何もないと思う。出版社に注目してほしい—Alibabaはライセンスを取るよりも、自社のツールやモデルを使いたがるだろうね。内部のツールをオープンソースにしてることも多いから、彼らのアプローチを見るのはいつも興味深い。

└

別のタブでCodexにコードレビューを頼むだけじゃダメなの？同じモデルでレビューをするより、コードを書いたモデルとは違うモデルを使った方が良い結果が得られるよ。私は通常、コード編集にはOpusを使って、ピアレビューにはスキルを使った自動化でGPT 5.5を使ってる。モデルごとにトレーニングセットが違うからね。一つのモデルにカバーのギャップがあれば、違うモデルにその作業をレビューさせたい。二つ目のモデルにもギャップはあるけど、そのギャップリストは同じじゃないから。

└

開発者は、自分たちが書いたコードをレビューするために使うツールを絶対に使うべきだと思う。私たちは、ループの中でこれを行うスキルを持ってるんだ。サブエージェントを回して、（私たちのコーディング基準に基づいて）レビューして、別のサブエージェントでレビューをトリアージして、適用可能なものを修正して、そうでないものには反論する。これをループで回してるんだ。PRを開く前にね。PRのアイデアは、他の人が見落としていることを見つけたり、考え方の痕跡を残すことなんだ。例えば、何かが修正されなかった場合、その理由やコメントの履歴が残る。もしこれをローカルだけでやったら、そのコンテキストは失われちゃう。自己レビューのループを何度もやっても、他のモデルやツール、あるいは「部族知識」を持つ人間を通じて問題が見つかることに気づいたんだ。いつかAIが完璧なコードを書いて自分でレビューできるようになるかもしれないけど、バグが0.1%の確率であるとか、100万分の1でちょっと悪意のあることをする（例えば、シャットダウンしようとしたらバックドアを開く）可能性があるなら、やっぱり人間が何かをレビューする必要があると思う。

└

ローカルマシンの外でも使えるよ。似たようなものを作ったんだけど、ボットが追加された新しいPRを探してレビューを行うんだ。コードが似たルールに合わせて調整される。開発者が自分でコードレビューのツールを使うとは限らないし（ビルドを自分でやるとは思わないから、私たちもビルドを回してるし）、人間以外の視点でのコードレビューって感じだね。残念ながら、トークンをたくさん使うし、Anthropic、OpenAI、GitHub Copilotがトークンベースの価格設定に移行したことを考えると、かなりお金がかかる。

└

コマンドを実行するメカニクスはさておき、主な価値はすべてのルールにあると思う。https://github.com/alibaba/open-code-review/tree/main/intern... 一般的な「SKILL」ファイルと同様に、プロンプトエンジニアリングに関係してるね: https://en.wikipedia.org/wiki/Prompt_engineering#Rationale

会社のハッカソンで、ノードイメージを使ってClaudeのコードをインストールして、/reviewみたいなコマンドを実行してPRにインラインコメントを入れるものを作ったんだ。OCRを再実行する時に古いコメントを削除するのも面白いけど、やりすぎかな。あのCEOがここでちょっと高飛車な態度を取ってたから、Code Rabbitは絶対使わないけど。要するに、Git自体でのAIコードレビューはそんなに難しくないし、すぐに価値を加えられるよ。

└

CEOはどれくらい高飛車だったの？

└

コーダラビットやSaaSに特に文句があるわけじゃないけど、これが理由で使うのをやめたんだよね。https://kudelskisecurity.com/research/how-we-exploited-coder... 基本的なコードレビューのツールを作るのは簡単だけど、開発者が「誤検知が多いからオフにして」って言わないようなものを作るのは難しいよね（次のバグを見逃すようなツールも）。もしツールが単にコードレベルのレビューをするだけなら（開発者はPRを開く前に絶対にやるべきだと思うけど）、これってちょっとレビューのパフォーマンスみたいじゃない？ PRをドラフトから出す前に、/loopで/review-triage-fixスキルを使わない開発者へのガードレールみたいなもん？世界中で、何人かの開発者が互いのコードにコメントして、誰も何も読まずにgh cliやMCPを使ってコメントを投稿したり問題を修正したPRがどれだけあるんだろう。コード生成は指数関数的に増えていくし、AIコードレビューからは逃げられないけど、Claude Codeがコードを書いて自分でレビューするのと、遅くてダウンタイムが多い「PRコメント」を通じてコミュニケーションを取るのに実際の違いはないよね。要するに、AIコードレビューを人間がチェックしたり、AIが見逃した部分をざっと見ることがない限り、「コードレビュー」を使う理由はないと思う。CI/CDの一部として実行して、AIが何も見逃さないことを願うだけでいいんじゃないかな（私のLinkedInフィードによると、そう考えてる人もいるみたいだけど…）。

インストール後、ocrコマンドはグローバルに利用可能です。別の略語を選んでほしかったな…

このベンチマークの50のPRのうち10のサブセットで試したんだけど、リコールは非常に良かった（約74%、例えば多くのゴールデンイシューを見つけた）。でも、精度はあまり良くなかった（約12%、例えば多くの誤検知があった）。精度が低いとF1スコアが落ちちゃう（約20%、もしこれが50のサンプル全体でも同じなら、ほぼ最下位になっちゃう、Kilo+Grokよりも低いかも）。

└

でも、リコールが最も重要な指標だと思う。すべての問題をキャッチしてほしい。誤検知は無視するのが簡単だから。

└

決定論的監査からの誤検知は、すごく厄介な問題だね。いろんな方法やLLMの監査を比較して重複を排除するのが唯一の解決策っぽい。

└

どのLLMを使ったの？それによってかなりの違いが出ると思うよ。

こんなことをやったことがあるけど、逆の感じで。君がコードをレビューして、AIにコードレビューのコメントを通じて指示を出すんだ。https://parley.cloudflavor.io そう考えると、最初にアリババのツールを使って、その後にパーレイを使うのが面白そうだね。数日前にここに投稿したよ。https://news.ycombinator.com/item?id=48369782 AIに関しては、今はShow HNが多すぎて、フィードバックをもらったことがないな。

└

ちょっとしたメモだけど、君のサイトのフォントが読みにくくてイライラする。文字が横に揃ってない（WindowsのChromeで）。スケーリングの問題みたいで、200%にズームするとちゃんと表示される。

ルールファイルはここにあるよ: https://github.com/alibaba/open-code-review/tree/main/intern...（中国語）

└

Java.mdの英語版（Google翻訳）: https://github-com.translate.goog/alibaba/open-code-review/b...

専用のCLIやハーネスを作って、コーディングエージェントに使い方を教えるスキルを作るのがいいと思う。うちの会社では、セキュリティレビューのための徹底したワークフローを構築したんだけど、これは採用を簡単にするための純粋なスキルなんだ。https://www.synthesia.io/post/automating-code-security-revie... でも、ユーザー体験はちょっと難しい。偽陽性を極力減らそうとすると、この手のワークフローの実行時間が長くなっちゃって、PRをブロックする理由を正当化するのが難しくなる。

各ルールファイルの英語翻訳をGoogle翻訳で作成したリポジトリ: https://github.com/pramodbiligiri/open-code-review-rules. 元のルールファイル（中国語）: https://github.com/alibaba/open-code-review/tree/main/intern...

└

あなたがここにコメントをコピペしたみたいだけど、もっと適切で正確な翻訳を含めてないから、もう一度私の別のコメントを載せておくね。比較のために、ここに3つのバージョンがあるGitHubのギストを貼っておくよ。最初は元の中国語、次にあなたが載せたGoogle翻訳版、最後にChatGPT Proで翻訳したもの: https://gist.github.com/embedding-shapes/7a51d565214bd676890... こういう風にしたのは、Google翻訳版とChatGPTの翻訳を比較するためだよ（修正: https://gist.github.com/embedding-shapes/7a51d565214bd676890...）

それのランディングページはレビューしたの？iOSで壊れてるみたいなんだけど。

ハクソク