OpenCodeReview - Git差分と文脈を分担して調べるAIコードレビューCLI

開発元のREADMEは、Claude Codeのような汎用エージェントにレビューを任せる場合の課題として、対象ファイルの確認漏れ、指摘位置のずれ、プロンプト変更に伴う品質の揺れを挙げる。これらは欠陥を見抜く能力とは異なる問題だ。変更ファイルが増えるほど、何を調べるか、どの周辺コードを読むか、最終的な指摘を差分のどこへ結び付けるかという工程も増える。自然言語の指示で一連の工程を扱える柔軟さはあるが、結果が変わったとき、対象の選び方と欠陥判断のどちらが原因かを切り分けにくい。OpenCodeReviewが扱おうとするのは、この工程の混在である。

普段の変更確認なら、レビューの入口はGit差分になる。OpenCodeReviewにはワークスペース、ブランチ間、単一コミットを対象とするコマンドが示されており、たとえばocr review --from main --to feature-branchで比較範囲を指定できる。一方、変更差分のない既存コードを調べたいとき、差分を入口にすると対象を表せない。そこでocr scanはファイル全体や指定ディレクトリを対象にする。両者の違いはレビュー対象の決め方にあり、その後は対象ファイルに文脈と規則を与えてレビューするという同じ設計思想で読める。

ここでいう決定論的な処理は、READMEで確認できる範囲では、対象の選別と除外、関連ファイルの分割、ファイル別規則の対応付け、コメント位置の特定などを指す。これを、NPEやSQLインジェクションなどの欠陥を静的解析エンジンが確定検出する仕組みと読み替えるべきではない。欠陥かどうかの判断には、ファイル全文の参照やコード検索ができるLLMエージェントが残る。したがって、この設計を理解する鍵は「AIレビューの前後を固定しやすくする」ことであり、判断そのものが常に再現可能になるという意味ではない。

差分レビューでは、まずGit差分から対象ファイルを選別し、除外すべきファイルを外す。全ファイル監査では、ocr scanが指定されたファイルやディレクトリを入口にする。次に、関連するファイルを一つのレビュー単位へまとめる。ファイルをただ個別に投げるのではなく、関連性を保った単位で渡すため、エージェントは変更同士のつながりを同じ文脈で確認できる。各レビュー単位は独立した文脈のサブエージェントで処理されるというのが開発元の説明だ。どのファイルを対象にし、どのファイルを一緒に読むかを、欠陥判断の前段に置く構成になっている。

対象が決まると、ファイルの特徴に応じてテンプレートベースのレビュー規則が対応付けられる。規則はレビュー時の観点をファイルへ結び付ける仕組みであり、規則の対応付けだけで指摘が完成するわけではない。レビュー単位を受け取ったエージェントは、必要に応じてファイル全文を参照し、コードを検索し、ほかの変更ファイルも確認できる。差分の断片だけでは判断しにくい指摘でも、周辺の実装を調べる余地がある。前段が対象と観点を与え、エージェントが追加の文脈を集めて判断する、というデータの流れだ。

エージェントが指摘を作った後には、コメント位置の特定と指摘内容の再検討を担う独立モジュールが置かれる。最終的な出力は行単位の構造化コメントだ。レビューで有用な指摘があっても、ファイルや行がずれていれば、受け手は根拠を探し直さなければならない。この設計は、欠陥の判断と、その判断を変更箇所へ結び付ける処理を分けている。ただし、位置特定の工程があることから、すべてのコメントが正しい行に置かれるとまでは言えない。実際の差分で、指摘内容と位置の両方を確かめる必要がある。

通常の実行では、レビュー前にLLMを設定する必要がある。Delegation Modeでは分担が変わり、OpenCodeReviewが対象ファイルの選別と規則の解決を担い、ホスト側のコーディングエージェントがレビューする。READMEはClaude Code、Codex、Cursor、Kimi Codeなどとの連携を案内している。既存のエージェントを使う場合でも、対象と規則を準備する工程をOpenCodeReview側に置けるわけだ。レビューとスキャンには中断したセッションを再開するコマンドもある。長い処理を扱う際には有用だが、再開できること自体は指摘の正しさを示さない。

複数ファイルにまたがる変更で、まずレビュー対象を明確にし、関連ファイルを一緒に読み、指摘を行へ結び付けたいチームには、この工程分担が合う。ブランチ間や単一コミットのレビューは日常の変更確認に、ocr scanは既存コードやディレクトリの監査に使える。READMEはGitHub Actions、GitLab CI、GitFlic CI、Gerritとの連携も案内している。ただし、CIへ置く場合も、どの変更を対象にするか、どのLLM設定で実行するか、出力を誰が確認するかは運用側で決める必要がある。自動実行と自動採用は同じではない。

Claude CodeにSkillや自然言語の指示を渡すレビューと比べると、OpenCodeReviewは対象ファイルの選別、関連ファイルの分割、規則の対応付け、コメント位置の特定を専用の工程に分担させる。比較の中心は、基盤モデルそのものよりレビューの組み立て方だ。すでに汎用エージェントを使っているチームなら、Delegation Modeによって、そのエージェントの判断を残しながら対象と規則の準備を任せる選択もできる。逆に、レビュー対象を人が厳密に絞り、エージェントとの対話で調査を進める運用では、専用CLIを挟む利点を個別に確かめたい。

開発元は、50のオープンソースリポジトリ、200件のPull Request、10言語、1,505件の注釈付き正解指摘を用い、同じ基盤モデルのClaude Codeと比較したと説明する。その条件で、レビュー当たりのトークン消費は約9分の1、PrecisionとF1は高く、Recallは低かったという報告だ。取得されたREADME本文にはPrecision、F1、所要時間の具体的な数値はない。トークン差や品質差は開発元の評価条件に結び付いた報告として読むべきで、自分たちのリポジトリでも同じ差が出るとは言えない。特に見逃しを減らすことが第一のレビューでは、低いと報告されたRecallを重く見る必要がある。

Git 2.41以降が前提であり、それを使えない環境には適合しにくい。Delegation Mode以外ではレビュー前にLLMの設定も必要になる。設定したプロバイダーやカスタムモデルエンドポイントを使う運用では、どのコードを参照させ、どの権限を与え、どの程度のトークンを消費するかをチームの条件で確認したい。READMEのベンチマークだけでは、個々のCI環境での所要時間や費用は判断できない。また、テンプレートによる規則対応付けが、利用言語や独自のレビュー基準にどこまで合うかも、実際の変更で検証すべき点だ。