OpenCodeReview 教程 2026：アリババ公開の AI Code Review CLI の入れ方、Git Diff・スキャン・Claude/GPT

なぜ「もう一つ Review Skill」では審査が直らないか

2026 年、多くのチームの痛みは「AI 審査がない」ことではない。審査の入口が汎用 Agent に縛られていることだ。Claude Code に「この PR を review して」と言えば、一部のファイルは読み、別のファイルは落ち、評語の行番号はたまにずれる。次の会話でプロンプトを少し変えると、品質もまた揺れる。公式 README は、この痛みを率直に書いている。カバレッジ不足、位置ずれ、純自然言語 Skill のデバッグ困難。

根因はモデルが足りないことではない。純言語駆動のアーキテクチャが、審査プロセスに硬制約を持たないことだ。どのファイルを今回の審査に入れるか、関連ファイルを束ねるか、どのルールをどの種類のファイルに落とすか——これらは「間違えてはいけない」工程なのに、同じチャットに投げている。GPT に替えても Claude に替えても、漏らし方が変わるだけだ。

非対称な結論はこうなる。分岐点は Claude と GPT のどちらが強いかではない。審査入口が「確定的エンジニアリング＋Agent」かどうかだ——ファイル選定、バンドル、ルール照合は工学が保証し、モデルは動的な証拠集めだけを担う。 上げるべきは入口（ocr review / ocr scan / CI）であり、もっと厚い Review Skill ではない。「harness とは何か」の概念整理は Omnigent Agent Harness 完全理解 に譲る。本稿が解くのは「OpenCodeReview を入れ、Git Diff とスキャンを通し、Claude と GPT を繋ぐ」ことだけだ。

OpenCodeReview とは：Git Diff と全量スキャン

先に分類し、それからコマンドを見る。OpenCodeReview はもう一つのチャット窓ではない。同じ審査ループの、二つの開き方だ。切り口はやはり入口、実行、文脈、向いている人である。

公式サイトと npm パッケージ説明 は思想をはっきり書いている。確定的エンジニアリングが、間違えてはいけない工程を担う——ファイルを正確に選び、関連ファイルを一束にする（例：message_en.properties と message_zh.properties）、ファイル特徴でルールを照合し、外部の位置特定と反省モジュールで行番号と内容を補正する。Agent が担うのは動的な判断と動的な証拠集めだけだ。全ファイルを読む、リポジトリを検索する、同じ変更の他ファイルを見る。公式ベンチマークはオープンソース 50 リポジトリ、実 PR 200 件、10 言語の交差注釈で、汎用 Agent（Claude Code を含む）より高い Precision / F1、約 1/9 の token、より短い完了時間を謳う。一方 Recall は低い——これは精度でノイズを買う、意図的なトレードオフであり、見逃し＝失敗ではない。

OCR vs Claude Code / Copilot / 人手

選定で先に「Claude が強いか、GPT が強いか」と聞くと、本当の差を取り逃がす。OpenCodeReview、汎用 Agent Skill、IDE 内蔵審査、人手を同じ表に置き、入口・実行・文脈・向いている人で揃える。

マルチモデル coding harness の鍵の入れ方は Pi Coding Agent のインストールとマルチモデル を見てほしい。あちらが答えるのは「バックエンドを替えてコードを書く方法」。本稿が答えるのは「審査入口をチャットから、再現可能な CLI に切り出す方法」だ。

インストールと LLM の設定

前提条件

公式の硬要件は Git ≥ 2.41 だ。diff 生成、コード検索、リポジトリ操作はすべて Git を通る。先に git --version を確認し、古いディストリビューションは上げてから CLI を入れる。Node が唯一の導入経路ではないが、npm がドキュメント推奨の既定である。

npm install -g @alibaba-group/open-code-review
ocr version
ocr --help
which ocr

入れ終わったら ocr が PATH にいるはずだ。command not found なら、npm のグローバル bin が PATH に入っているかを見る。「インストール成功」を「審査できる」と取り違えないこと——LLM 設定がないと、Delegation Mode 以外は即失敗する。

その他の導入方法

CI のベースイメージやヘッドレス環境では、インストールスクリプトが使える（GitHub Release のバイナリを包み、検証付き）：

curl -fsSL https://raw.githubusercontent.com/alibaba/open-code-review/main/install.sh | sh
# OCR_INSTALL_DIR=/usr/local/bin（デフォルト）
# OCR_VERSION=v1.2.3   # 任意：特定の release に固定

Node を入れたくないなら、GitHub Releases から静的バイナリを取る。OCR 自体を直したいときだけソースからビルドする（Go ≥ 1.25 + Make）。プラットフォームの細部は インストールガイド を正とする。バージョン番号は変わる。コマンドの形のほうが「ある月のある日のモデル名」より安定している。

先にモデル、それから審査

設定は ~/.opencodereview/config.json に書く。対話が一番手間が少ない。ocr config provider で組み込みまたはカスタムのプロバイダを選び、鍵を入れ、モデルを選ぶと、接続テストまで自動で走る。そのあと ocr config model でモデルを替える。スクリプトと CI は非対話の ocr config set を使う。

ocr config provider    # 選ぶ anthropic / openai / カスタム
ocr config model       # 現在のプロバイダのモデルを選ぶ
ocr llm test           # 接続をもう一度試す
ocr llm providers      # 組み込みプロバイダを列挙

Git Diff の 3 つの審査モード

インストールの合格点は ocr version ではない。本物のリポジトリで、行番号付きの第一条意見が出ることだ。三つの入口で、手元の変更、ブランチ比較、単一コミットを覆う。

cd your-project

# ワークスペース：staged + unstaged + untracked
ocr review

# ブランチ：merge-base 基準で feature の main 差分を審査
ocr review --from main --to feature-branch

# 単一の commit
ocr review --commit abc123

# 中断後に再開
ocr session list
ocr review --from main --to feature-branch --resume <session-id>

# ホスト Agent または CI へ書き出す
ocr review --format json --output result.json

ワークスペースモードは「直したばかりでまだ PR を切っていない。先に自分で一回殴る」向きだ。ブランチモードは CI 向き：base は既定ブランチ、head は PR ヘッド。単一 commit は、問題のあった提出を再生するときに使う。大きな変更は複数バンドルに割れ、各バンドルは文脈を隔離した子 Agent になる。公式はこの分割統治で、巨大 changeset の漏審を抑えている。

初回で no valid LLM endpoint configured と出たら、設定鎖に (URL, token, model) が揃っていない。公式 FAQ どおり、~/.opencodereview/config.json を書くか、OCR_LLM_URL / OCR_LLM_TOKEN / OCR_LLM_MODEL を出すか、既存の Claude Code の ANTHROPIC_* を再利用する。OCR が取るのは最初に揃った三組であり、最後の一組ではない——設定ファイルが揃っていると、環境変数は無視される。

ocr scan 全量スキャンの使い方

ocr review が答えるのは「今回何が変わったか」。ocr scan が答えるのは「このディレクトリは今、安全か／読みやすいか」。意味のある diff がないとき——クローンしたばかりの見知らぬリポジトリ、審査ベースラインをゼロから作る、ディレクトリにほとんどコミットがない——空の commit を捏造して review をだましてはいけない。

ocr scan                          # リポジトリ全体をスキャン
ocr scan --path internal/agent    # ディレクトリまたは具体ファイル
ocr scan --resume <session-id>    # 中断後に再開

スキャンは diff より高い。token も時間も「ファイル全体」で数え、「何行直したか」では数えない。既定では、本当に引き継ぐサブツリーから先に掃く。vendor/ と生成物をいきなり全リポジトリで掃かない。ルールとパスフィルタは公式の Review Rules を見る。依存と成果物を先に除外してから、モデルの話をする。

Claude と GPT の繋ぎ方と結果の読み方

組み込みプロバイダでは、anthropic は https://api.anthropic.com を通り、鍵の環境変数は ANTHROPIC_API_KEY。openai は https://api.openai.com/v1 を通り、鍵の環境変数は OPENAI_API_KEY。providers.*.api_key を書いていないときは、対応する環境変数へフォールバックする。すでに Claude Code 環境がある場合、OCR は ANTHROPIC_* も拾う。

# Claude
ocr config set provider anthropic
ocr config set model claude-opus-4-6
ocr config set providers.anthropic.api_key "$ANTHROPIC_API_KEY"
ocr llm test

# GPT（OpenAI）
ocr config set provider openai
ocr config set model gpt-4o
ocr config set providers.openai.api_key "$OPENAI_API_KEY"
ocr llm test

# カスタム OpenAI 互換ゲートウェイ
ocr config set provider my-gateway
ocr config set custom_providers.my-gateway.url https://gateway.internal.com/v1
ocr config set custom_providers.my-gateway.protocol openai
ocr config set custom_providers.my-gateway.model llama-3-70b
ocr config set custom_providers.my-gateway.api_key "$MY_API_KEY"

モデル ID はプロバイダのカタログとともに変わる。公式例には claude-opus-4-6、gpt-4o が出た。本番では ocr config model が列挙する選択肢を正とし、ブログのスナップショットを埋め込まない。401 / 403 のときは先にプロトコルを照合する。Anthropic は /v1/messages、OpenAI 互換は /v1/chat/completions。llm.protocol / use_anthropic は URL と同じ一族でなければならない。

同じリポジトリ、同じ diff でバックエンドを替えたとき、何を読むか

実測で「どちらの文が長いか」を比べない。小さな PR を固定する。ヌル参照リスク一箇所、明らかなテスト欠落一箇所、スタイルのノイズ一箇所。Claude と GPT でそれぞれ ocr review --from main --to HEAD --format json --output out.json を走らせ、三つのことだけ見る。報じるべき欠陥に行番号が乗っているか、スタイルノイズが抑えられているか、token と壁時計が CI 予算に入るか。公式ベンチの志向は高精度、低ノイズ、低 token だ。GPT が安くても nit を三倍出せば、CI の人はパイプラインごと切る。

- name: Open Code Review
  uses: alibaba/open-code-review@main
  with:
    provider: openai
    model: gpt-4o
    api-key: ${{ secrets.OPENAI_API_KEY }}

GitLab CI、Gerrit、GitFlic もサポートする。鍵はリポジトリの Secrets に入れ、ワークフローファイルに書かない。自前の macOS runner とクラウド Mac の層分けは GitHub Actions macOS 自前ランナーとクラウド Mac を見る。

シナリオの選び方

本当に聞くべきは「OpenCodeReview を入れるか」ではない。第一制約は何かだ。再現可能な diff 審査が要るのか、diff のないディレクトリを監査したいのか、チャット窓の口頭意見で足りるのか。

推奨組み合わせ

ツールは重ねてよい。OpenCodeReview が解くのは「再現可能な審査入口」だ。蓋を閉じない Mac を渡す役でも、Claude や GPT の請求を肩代わりする役でもない。

• 個人の日常組み合わせ：グローバル ocr ＋ ANTHROPIC_API_KEY または OPENAI_API_KEY ＋ワークスペース ocr review。PR を切る前に一度走らせ、ルールファイルはリポジトリに入れる。
• PR / CI 組み合わせ：ocr review --from base --to head --format json ＋公式 GitHub Action ＋ Secrets。失敗戦略は先に「コメントして止めない」。誤報率が落ち着いてから硬門禁にする。
• ベースライン監査組み合わせ：初回の引き継ぎは ocr scan --path で問題一覧を作り、そのあとは増分だけ review。PR ごとに全リポジトリをスキャンしない。
• 既存 Coding Agent 組み合わせ：手元では Claude Code / Cursor で書き、審査は ocr delegate または OCR 自身のモデル。書くことと審査することは分ける。鍵も分けてよい。
• 最小検証組み合わせ：CLI だけ入れ、鍵は一本だけ、小さなリポジトリで ocr review とワークスペース変更を走らせる。四拍（インストール→資格情報→一度の review→一度の scan）が通ってから CI に入れる。

よくある誤解

• OCR を Claude Code の無料クローンだと思う。ファイル選定と行番号は、意図的にモデルの手から取り上げている。欲しいのは審査カバレッジであり、また一つの、ファイルを直せるチャット窓ではない。
• LLM を設定せずに「入れ方が壊れた」と責める。Delegation Mode 以外は、端点の三組が揃っていなければならない。ocr llm test が通る前に、Git 引数をいじり始めない。
• scan を毎回の PR 審査の代わりにする。全量スキャンは高く、歴史のノイズをまた報じる。増分は review、ベースラインは scan。
• ブログのモデル ID を Action に固定する。カタログは変わる。Action の model は変えられる入力として扱い、先に手元で ocr config model を検証する。
• 個人サブスクの鍵を CI にコミットする。CI はリポジトリ Secrets、または権限を絞ったマシン級 config.json。社内コードを監査していないゲートウェイに向けない。
• スリープするノートで全リポジトリ scan を走らせる。セッションは --resume できるが、壁時計と請求は見苦しくなる。長時間スキャンは常時稼働ノードへ。

導入ステップ

1. 譲れない条件を書く：手元の自己審査だけか、CI コメントだけか、両方か。初週に Claude と GPT を同時に繋ぐ必要があるか。CI は先にコメントするか、いきなり止めるか。
2. CLI を入れ、空走りを一度する：npm install -g @alibaba-group/open-code-review、ocr version、PATH と Git ≥ 2.41 を確認する。
3. 鍵は一本だけ繋ぐ：ocr config provider または ocr config set。ocr llm test が通ってから先へ進む。
4. 本物の小さな PR で ocr review を走らせる：ワークスペース、または --from/--to。合格点は「行番号が合い、報じるべきものが報じられた」であり、「評語が長い」ではない。
5. ocr scan --path を一度足す：引き継ぐサブツリーだけ掃き、review との分業を確認する。ベースライン対増分。
6. それから二社目のモデル、または Delegation を決める：同じ diff で Claude / GPT を替え、誤報と費用を比べる。すでにホスト Agent があるなら ocr delegate を試す。
7. 実行環境を決めてから CI に入れる：手元の試用はよい。夜間スキャンと門禁は、常時稼働のクラウド Mac または自前 runner へ。ログはマスキングし、鍵は成果物に入れない。

FAQ

OpenCodeReview と Claude Code の関係は？

Claude Code は Anthropic 公式の coding ワークフローで、コードを書くことと口頭審査を同じ窓でできる。OpenCodeReview はアリババ公開の審査 CLI で、モデルは Claude、GPT、互換端点に替えられる。代替するのは「公式の深いファイル改変」ではない。「審査カバレッジと行番号を、プロンプトだけに頼るやり方」だ。

Claude と GPT を同時に設定しなければならないか？

しなくてよい。鍵一本でインストール検証は通る。二社目の鍵の意味は、同じファイル選定とルールのうえで、費用と誤報に応じてバックエンドを替えることだ。二社目の請求がないなら、「比較評価」のために運用面を増やさない。

ocr review と ocr scan は互いに代替できるか？

同じコマンドとしては使えない。review は Git Diff を食べ、PR と手元の変更向き。scan はファイル全体を食べ、diff のない監査向き。入口を間違えるのは、モデルが足りないからではない。工学層に、違う入力を見せているからだ。

Windows とヘッドレスのクラウド Mac に入れられるか？

入れられる。npm グローバルパッケージはクロスプラットフォーム。インストールスクリプトは darwin / linux の amd64 と arm64 を覆い、Windows は Release バイナリまたは npm を使う。ヘッドレス機は非対話の ocr config set と --format json を使い、TUI に頼らない。クラウド Mac では、Git、PATH、~/.opencodereview の権限を先に固める。

なぜクラウド Mac が要るのか。手元の npm では足りないのか？

手元はコマンドを学ぶには足りる。夜間の全量スキャン、蓋を閉じたあとの PR 門禁、Xcode / 署名と同じ環境の CI には足りない。ocr はモデルを切り離したが、Git とファイルツールは、プロセスが走っているそのマシンにまだ縛られている。

まとめ

OpenCodeReview の導入記事は、表向きは npm、環境変数、ocr review / ocr scan だ。本当に載せるべきは一枚の層分けである。確定的エンジニアリングとモデルを分ける。Git Diff 入口と全量スキャン入口を分ける。対話設定と CI 設定を分ける。2026 年 9 月に耐える使い方は、手元で鍵一本の review を通し、ルールをリポジトリに入れ、CI は Secrets で JSON を落とし、scan はベースラインにだけ使うことだ。

非対称な結論は、なお立つ。分岐点は Claude と GPT のどちらが強いかではない。審査入口を硬制約にできるかどうかだ。先に鍵一本の ocr review を通し、それから scan と二社目のモデルを足す。実行面が要るなら、プロセスをスリープするノートからクラウド Mac へ移す。上げるべきは入口、資格情報、ノードであり、もう一つの Review Skill ではない。