OpenCodeReview AI Code Review 実測：Git Diff・バグ・脆弱性・品質を自動検査して、実プロジェクトで何件出るか

先に揃える：OpenCodeReview は何を見るか

日本語圏でも OpenCode（opencode serve のコーディング Agent）と名前が混ざりやすい。別物だ。OpenCodeReview は Alibaba 社内で2年使われた AI レビュー助手の CLI 公開版で、Git の差分を読み、行単位の構造化コメントを出す。NPE・スレッド安全性・XSS・SQL インジェクションなどの多言語ルールを内蔵し、OpenAI / Anthropic 互換エンドポイントに繋げる。リポジトリは alibaba/open-code-review、導入は open-codereview.ai。

「褒め上手なレビューボット」が欲しいなら違う。チャットモデルは貼った断片しか見ない。呼び出し元も、隣ファイルのロックも知らない。OpenCodeReview の賭けは決定論的な仕分け＋深い Agentだ。見るファイルを決め、言語別チェックリストを注入し、Agent が file_read とリポジトリ検索で文脈を取る。

当サイトにはすでに OpenCode を自前ホストするときの 4GB / 8GB / 16GB がある。あれはコーディング Agent のメモリ話だ。本稿は ocr review だけを扱う。Git Diff・Bug・脆弱性・品質を自動検査したとき、実プロジェクトで何件出るか。

公式は「数万開発者、数百万欠陥」と言う。Alibaba 規模の累計であり、次の PR の約束ではない。マージ前の第二の目が欲しいなら合う。機械の署名で本番に出したいなら、README もこの実測も署名しない。

Git Diff の読み方：3つのモード

「Git Diff を自動検査」で来る読者が知りたいのは「何を変えたか」だ。CLI はそれを排他的な3モードに分ける。混ぜると即エラー。旗は CLI Reference。

範囲モードは merge-base を使う。人間が PR を見るやり方に近い。main に後から入った無関係なコミットは混ざらない。公式 GitHub Action も同じで、merge-base を出してから ocr review --from MERGE_BASE --to HEAD_SHA --format json し、行コメントを PR に返す。

四つ目が ocr scan。意味のある Git 履歴がない、または見知らぬディレクトリ全体を監査するとき、差分ではなくファイル全体を見る。トークンとノイズは増える。日常のマージは diff、遺産リポジトリの引き継ぎで scan を検討する。

本番の前に必ず ocr review --preview。フィルタだけ走り、モデル代はゼロ。各ファイルが will_review か、拡張子・削除・テストパスで落ちたかを出す。実測では画像と lockfile 付き PR の「見た目の巨大さ」の半分が LLM に届く前に消えた。正しい。

5分で動かす：インストール、モデル、preview

推奨は npm グローバル。公式 install.sh と GitHub Release の静的バイナリもある。Git は ≥ 2.41。モデル未設定の ocr review は空転する（Delegation Mode で既存のコーディング Agent に委譲する場合を除く）。

npm install -g @alibaba-group/open-code-review
ocr version
ocr config provider
ocr config model
ocr llm test

cd /path/to/your-repo
ocr review --preview
ocr review --from main --to HEAD --format json --audience agent

設定は ~/.opencodereview/config.json。CI では ocr config set か、既存の ANTHROPIC_* / OCR_LLM_*。コメント言語は ocr config set language 日本語、未設定は英語。リポジトリ規則は .opencodereview/rule.json をコミットできる。キーはリポジトリに書かない。

npm 版は既定でバックグラウンド更新（約18分クールダウン）。CI では OCR_NO_UPDATE=1 とバージョン固定。セッションは ~/.opencodereview/sessions/。ocr viewer は localhost:5483 で再生用。公開サービスではない。

メモリ見積もりを OpenCode 自前ホスト記事からコピーしないこと。重いのは LLM API と並行 Git 子プロセスで、LSP は常駐しない。--concurrency 既定は 8。蓋を閉じると範囲レビューは途中で死ぬ。常時起動の runner の方が、出張ノートで一発賭けるより正直だ。

実測：3つの変更パックで何件出たか

同じ設定（OpenAI 互換、中規模チャットモデル、システム規則＋プロジェクト規則のマージ）で、実際に PR になる形の3パックを見た。おもちゃの10行ではない。各パックで --preview のあと ocr review --from --to --format json。コメントを必須修正・すべき修正・スタイル・誤検知に手分けした。一回のスナップショットで、モデルを換えると数は揺れる。内訳の方が合計より役に立つ。

必須（7）はセキュリティ3、欠陥4。セキュリティは文字列連結クエリ、未エスケープの HTML 出力、内部エラー文のクライアント返却。欠陥は nil をオブジェクト扱い、ロックなしの map 書き込み、%w なしで原因が消えるエラー。公式ルールセット（NPE、スレッド、XSS、SQL）にそのまま落ちる。随筆ではない。

すべき（6）はタイムアウト未設定、非冪等の再試行、メールや本文を含むログ。人が金曜午後に言い淀む類だ。Agent は疲れない。

スタイル（10）が最大桶。命名、早期 return、関数抽出。有用だが信号を薄める。放置すると3週目でレビュー全体を折りたたむ——ノイズの多い PR ボットと同じ病理だ。

誤検知（4）は地味で良い。テスト用 SQL を本番注入扱い、すでにパラメータ化されたクエリへの再指摘、Go 1.22 以降直ったループ変数。4件中3件は --preview のあとテストパス除外で消える。先にフィルタを疑え。

公式例の規模とも合う。範囲レビュー1回は「9ファイル、十数コメント、1分前後、2万トークン前後」が多い。今回は独立した3範囲なのでその約3倍。トークン窓の約80%を食う単一ファイル diff は LLM 前に捨てられる。巨大生成物と lockfile は preview で消えるべきで、請求書に残すべきではない。

Bug・セキュリティ・品質：拾えるもの、拾えないもの

27件をタイトルの4語で切った方が、「何件見つかった」より使い方に近い。

Agent はファイル全体を読めるので「緑の行だけ」より一段強い。公式の「ロックなし map 書き込み」が典型で、diff は代入1行、共有状態はファイル上部に既にある。diff 専用ボットは見逃し、file_read が文脈を引き込む。パッチだけ見る Copilot Review 系との宣伝上の差でもある。あちらは速く静かで、ファイル横断が弱い。

わざと入れた見逃しも見た。誤った割引式、通貨フィールドの取り違え、未承認では開けてはいけない API。コメントはゼロ。モデルにドメイン辞書はない。--background で PR 説明を足すと少し良くなる。要件レビューの代替にはならない。

セキュリティ指摘は手がかりであり判決ではない。「ここで SQL を連結している」は、ドライバと権限とデータの格を自分で確認する話だ。本稿は悪用手順を示さない。印が付いたかどうかだけを記録する。書き込み境界も絞りたいなら Agent がファイルを安全に編集する VFS を見よ。レビューは読み取り専用、ディスクを書くのはコーディング Agent だ。

CI：GitHub Actions、ルール、誤検知

手元が通ったら、欲しいのは PR 上の行コメントだ。公式 composite Action は信頼できる base を checkout し（fork の作業ツリーを展開しない）、head の git オブジェクトを取り、merge-base を計算し、ocr review --format json して Review API で行コメントと sticky 要約を付ける。トリガは PR の open/synchronize、または /open-code-review コメント。

権限は最小。contents: read、コメントを書くなら pull-requests: write。キーは Secrets、モデル名は Variables。fork は既定でリポジトリ Secret を読めない。保護であり故障ではない。外部貢献を自動審査したいからといって、信頼できないコードの checkout と pull_request_target を組むな。秘密漏洩の組み合わせだ。GitHub 自身の硬化は Security hardening for GitHub Actions。

ルールは4層。--rule、プロジェクト .opencodereview/rule.json、ホームのグローバル、内蔵システム。ocr rules check でどの層が勝ったかを見る。merge_system_rule: true で、ログ2行のカスタムが Java の NPE 一覧を消さないようにする。テスト・生成物・vendor の除外は、後から誤検知で争うより安い。

macOS で Xcode 差分を同じ流れに載せるなら、runner の方が ocr より手がかかる。構築と検収は GitHub Actions macOS セルフホスト Runner。眠らないマシンと、ノートと奪い合わないキーが、再現性になる。