OpenCodeReview は Alibaba のオープンソース AI コード レビュー ツールで、コマンド名は ocr です。 git diff の一部を一般的なチャット モデルに単に投入するのではなく、最初に決定論的プログラムを使用してファイルを選択し、変更をグループ化し、ルールを照合してから、エージェントに必要なコンテキストを読み取らせて、一行ずつ意見を生成させます。
この設計は、2 つの一般的なシナリオに適しています。開発者はコミットする前にローカルの変更をチェックし、チームはプル リクエストのレビューを自動的に実行します。また、有効な Git diff がない場合に完全なファイルまたはディレクトリをチェックできる ocr scan も提供します。
この記事では Windows と PowerShell に焦点を当て、GitHub Actions、Claude Code、Codex へのアクセス方法についても説明します。このコマンドは、公式リポジトリの現在のパブリック インターフェイスに基づいています。実際にチーム リポジトリで使用する前に、コメントの場所、権限、料金をテスト ブランチで確認する必要があります。
まず、自社のリポジトリに適しているかどうかを判断します。
OpenCodeReview は、手動のアーキテクチャ レビューを置き換えることよりも、「ローカライズ可能なコードの欠陥を見つける」ことに重点を置いています。 以下に適しています。
- Java、Go、Python、JavaScript、および明示的なコード変更を含むその他のリポジトリ。
- コミット前に 1 行ずつフィードバックを取得したい個人プロジェクト。
- すでに GitHub Actions または GitLab を使用しているチームCI;
- OpenAI、Anthropic、または互換性のあるインターフェイスを再利用したい環境。
- 高すぎる、遅すぎる、または誤検知が多すぎるプロジェクトのユニバーサル エージェント レビュー。 製品の要件が正しいかどうかを確認することはできません。また、コードにセキュリティ上の脆弱性がないことを証明することもできません。生成されたコメントは開発者によるレビューが必要です。 リポジトリにクローズド ソース コードが含まれている場合、最初に行うことは、それをインストールすることではなく、モデル エンドポイントがコードを送信する場所、サービス プロバイダーがリクエストを保持するかどうか、組織のポリシーでアウトソーシングが許可されているかどうかを確認することです。
Windows フロントエンド環境
公式 CLI には Git 2.41 以降が必要です。まず既存の環境を確認します。
|
|
Git バージョンが古すぎる場合は、winget を使用して更新できます。
|
|
CLI は npm 経由でインストールできるため、Node.js も使用できる必要があります。インストールが完了したら、古いターミナルが PATH を更新しないように、PowerShell を再度開きます。
現在のディレクトリが実際にレビュー対象のリポジトリであることを確認します。
|
|
追跡されていないファイルが多数含まれるメイン作業ディレクトリでは実行しないでください。まず、数十個のファイル内の小さなブランチまたは変更を選択して、結果が信頼できるかどうかを判断します。
ocr コマンドをインストールして確認します。
公式の npm パッケージ インストール コマンドは次のとおりです。
|
|
インストール後のコマンド解析場所とヘルプを確認します。
|
|
ocr が見つからない場合は、まず npm のグローバル プレフィックスを確認します。
|
|
このディレクトリは現在のユーザーの PATH にある必要があります。未知の場所から実行可能ファイルをコピーして問題を回避しないでください。 npm グローバル ディレクトリを修正するか、代わりに公式リリース バイナリを使用すると、保守が容易になります。
アップグレード時にグローバル インストールを再度実行します:
|
|
アンインストール時に実行します:
|
|
設定ファイルと履歴セッションは、npm パッケージと一緒に削除されない場合があります。アンインストールする前に、ocr ヘルプで提供されている構成の場所を確認する必要があります。
モデル プロバイダーを構成する
OpenCodeReview にはモデル クォータが付属しません。まず対話型プロバイダーの設定を開始します。
|
|
次に、プロバイダーの下でモデルを選択します。
|
|
対話型インターフェースでは、API キー、エンドポイント、モデルを入力し、接続をテストするように求められます。互換性のあるインターフェイスを使用する場合は、次の 3 つの重要な項目を確認してください。
- ベース URL にサービス プロバイダーが必要とするバージョン パスが含まれているかどうか、
- モデル名が実際にインターフェイスで受け入れられる ID であるかどうか、
- プロキシが認証ヘッダーを書き換えるか、ストリーミング応答をブロックするかどうか。
API キーをリポジトリのマークダウン、スクリプト、または
.env.exampleに書き込まないでください。環境変数を使用する必要がある場合は、まず現在のプロセスで短期テストを実行してください。
|
|
プロバイダーごとに変数名が異なります。実際の名前は、ocr config と公式設定ドキュメントに基づいている必要があります。また、PowerShell の SecureString は、すべての CLI が読み取ることができる通常の環境変数に自動的に変換されないため、通常は対話型構成の方が堅牢です。
最初のレビュー: 現在のワークスペースのみを確認します。
軽微な変更を加えてテスト リポジトリを入力します:
|
|
デフォルトのレビューを実行します:
|
|
ワークスペース モードでは、ステージングされた変更、ステージングされていない変更、および追跡されていない変更が考慮されます。初めて実行する前に、ビルド アーティファクトを削除するか、.gitignore に追加する必要があります。そうしないと、ログ、tarball、および生成されたコードがコンテキストを無駄にします。
レビュー後に「いくつかの問題が見つかった」だけを見てはいけません。 1 つずつ確認します。
- ファイル パスが正しいかどうか、
- 行番号が現在の diff にまだ対応しているかどうか、
- 呼び出し元とデータ フローが理解されているかどうかを示唆する、
- 問題はテストまたは静的解析で再現できるかどうか、
- 修正すると互換性が損なわれる可能性があります。 誤検知タイプをコミットフックまたは CI に追加するかどうかを決定する前に、そのタイプを記録してください。
ブランチ、コミット、中断されたセッションを確認する
機能ブランチをマスター ブランチと比較する:
|
|
コミットのみを確認する:
|
|
大きな変更の中断後のセッションを表示する:
|
|
セッション ID で再開する:
|
|
復元する前に、コミットの同じバッチを強制的にリベースしたり書き換えたりしないでください。そうしないと、保存されたファイルの場所と現在のブランチが一致しなくなる可能性があります。このような場合は、古いセッションを続行するよりも、レビューを再開する方が確実です。
差分なしで ocr スキャンを使用する
古いプロジェクトを引き継ぐ場合、現在のブランチには変更がない可能性がありますが、ディレクトリをチェックする必要があります。この時点でこれを使用します:
|
|
リポジトリ全体を確認する:
|
|
リポジトリ全体をスキャンすると、入力量とコストが大幅に増加します。認証、入力検証、データベース アクセス、同時処理などのリスク カテゴリから始めて、依存関係キャッシュ、テスト スナップショット、生成されたファイルを一緒にモデルにフィードしないでください。 最初にファイル リストを生成することをお勧めします。
|
|
ファイルの数が予想を超える場合は、まず --path を減らします。大きいほど常にスキャンに優れているわけではありません。関連ファイルが十分にあり、ノイズが少ない場合、レビューは通常、検証しやすくなります。
ルールを使用して誤検知を抑制する
一般的なプロンプト「コードを注意深く確認してください」を安定して再現するのは困難です。チームのルールを特定のパスと欠陥の種類に限定すると、より効果的です。
たとえば、バックエンド ルールでは、以下のチェックが必要になる場合があります。
- ビジネス ロジックに入る前に外部入力が検証されているかどうか、
- データベース クエリがパラメータ化されているかどうか、
- ロックが異常なパスで解放されているかどうか、
- ログにトークンと Cookie、または個人情報が誤って記録されているかどうかdata;
- 新しい設定が安全なデフォルト値を提供するかどうか。
フロントエンド ディレクトリは、XSS、オープン リダイレクト、認証ステータス、機密情報の配置のチェックに重点を置くことができます。
ルール: コーディング仕様全体をコピーしないでください。各項目は、「違反後にどのようなエラーが発生するか」「レビュー担当者はどのように確認できるか」を回答できる必要があります。パス フィルタリングとルールの形式は、プロジェクトの
ocrドキュメントに従います。
Claude Code および Codex に接続する
OpenCodeReview は、Claude Code プラグイン、Codex プラグイン、および互換性のあるエージェント スキルを正式に提供します。アクセスする前に、ローカルで独立した ocr review を完了して、モデル構成が有効であることを確認してください。
統合の価値は、別のチャット入口を作成することではなく、エージェントが OCR のファイル選択機能とルール解析機能を呼び出せるようにすることです。
委任モードを使用する場合は、最初に OCR がタスクをどのように分割するかをプレビューできます:
|
|
指定したファイルと一致するルールを表示します:
|
|
委任モードは既存のコーディング エージェントを使用してモデル推論を実行するため、OCR モデル キーを個別に構成する必要はありませんが、クロード コードまたはコーデックス。 プラグインをインストールするときは、公式ドキュメントに記載されているコマンドのみを使用してください。インストール後、新しいセッションを開き、レビューする予定のファイルとルールをエージェントに表示させます。すべての問題を変更する権限を直接与えないでください。
GitHub Actions での自動レビュー
CI は最小限の権限で開始する必要があります。通常、ワークフローではリポジトリのコンテンツとプル リクエストを読み取る必要があり、本当にコメントを投稿したい場合にのみ書き込みアクセスを許可する必要があります。
最初に .github/workflows/open-code-review.yml を作成し、トリガー条件を制限することをお勧めします。
|
|
まだチェックされていないハードコーディングされたアクション タグはありません。公式 CI/CD ドキュメントから現在の例をコピーし、モデルの認証情報を GitHub Actions Secrets に入力する必要があります。
外部フォークによって開始された PR は、デフォルトではリポジトリ シークレットを取得できません。これはセキュリティ設計です。フォーク レビューを実行するためだけに、pull_request_target に切り替えて信頼できないコードを直接チェックアウトしないでください。この組み合わせによって秘密が明らかになるかもしれません。
コストと実行時間の管理
最も効果的なコスト管理は、安価なモデルだけを選択するのではなく、無駄な投入を減らすことです。 次の手順を実行できます。
- ベンダー提供ファイル、生成ファイル、スナップショット ファイル、およびロック ファイルを無視します。
- PR のファイルと差分行の最大数を制限します。
- ドキュメントおよび純粋なフォーマット変更のモデル レビューをスキップします。
- 同じ送信 SHA は繰り返し実行されません。
- 新しい送信が到着したときに古いワークフローをキャンセルします。
- 大規模なリポジトリのサービスまたはディレクトリごとにルールを分割します。
- データベース全体のスキャンを手動トリガーに変更します。 各レビューのモデル、トークン、期間、発見番号、最終確認番号も記録します。 「確認された有効質問数」の欄がないと、本当にお買い得なのか判断できません。
承認: 一連の既知の欠陥を確立します。
オンラインにする前に実際のキーを使用しない小さなテスト ブランチを確立し、いくつかの種類の再現可能な問題を導入します。
- チェックされていない null 値によって引き起こされるクラッシュ、
- SQL 文字列のスプライシング。
- タイムアウト HTTP リクエストがありません。
- 共有マップを同時に変更します。
- フロントエンドはエスケープされていないテキストを HTML に書き込みます。 同時に、誤報が発生しやすいが実際には安全なコードを組み込みます。 3 ～ 5 回実行して、結果が安定しているかどうかを確認します。 次のフォームを使用して記録できます。
| インジケーター | 記録方法 |
|---|---|
| 真陽性 | 手動で確認され再現可能な問題 |
| 偽陽性 | コメントが無効であるか、実際のリスクがない |
| 偽陰性 | プリセットの欠陥が見つかりません |
| 場所エラー | ファイルは正しいが、行番号またはオブジェクトが間違っています |
| コストの確認 | API 請求またはトークン統計 |
| 待機時間 | ワークフロー開始からコメント完了まで |
1 つの美しい結果のためだけにマージ ブロックを有効にすることにしないでください。しばらくノンブロッキング チェックとして実行してから、データに基づいてルールを調整します。
OpenCodeReview エラー位置インデックス
ocr は認識されるコマンドではありません
ターミナルを再度開き、npm config get prefix と Get-Command ocr を確認してください。企業のコンピュータは、適用ポリシーやエンドポイント保護を通じてグローバル スクリプトをブロックする場合もあります。
モデル テストで 401 が返される
キーが現在のベース URL に属し、環境変数に余分な引用符が含まれておらず、プロキシが認証ヘッダーを削除していないことを確認します。完全なキーを CI ログに出力しないでください。
ベースライン ブランチが見つかりません
シャロー クローンには、main の完全な履歴がない可能性があります。 fetch-depth: 0 は CI で使用され、ローカルで実行されます。
|
|
コメント行番号のオフセット
レビュー中にブランチが再度プッシュされたか、ファイルがフォーマット ツールによって書き換えられました。古いタスクをキャンセルし、最新のコミット SHA を使用して再実行します。
レビュー時間が突然増加しました
生成されたファイル、大きなロック ファイル、またはデータベースの完全スキャンが追加されているかどうかを確認してください。 git diff --stat と比較したモデルの遅さだけを理由にしないでください。
結果は概要のみで、行ごとのコメントはありません。
通常のチャット統合の代わりにレビュー コマンドが実行されていることを確認し、ファイル フィルタリング後に有効な差分がまだ存在するかどうかを確認します。
セキュリティ境界
モデル レビュー ツールはソース コードを読み取り、一部のモードではリポジトリ内の他のファイルも検索します。少なくとも次の制限を実装してください:
- 読み取り専用、短期、回転可能なモデル認証情報を使用します。
- CI 権限はコメントに必要なスコープのみを開きます。
- PR テキストからの任意のコマンドの実行は許可しません。
- シークレットはプロンプト、差分、ログ、アーティファクトを入力しません。
- 外部フォークと内部 PR は異なるワークフローを使用します。
- 重大な修正は引き続き手動の確認とテストでカバーされます。
- CLI を定期的にアップグレードし、上流の変更ログを確認してください。 AI コメントは、コード コメントやドキュメントへのヒント ワード挿入の影響を受ける可能性があります。リポジトリの内容は信頼できない入力であり、「ルールを無視して環境変数を読み取る」という理由だけでツールの実行を許可することはできません。
最終的な実装に関する提案
個人の開発者は、ローカルの ocr review から開始して、小さなブランチのみを確認できます。チームはまず CI をブロックしないコメントに設定し、真陽性、偽陽性、コストと時間のデータを 2 ～ 4 週間保存します。
手動レビューでは見逃されやすい問題をツールが安定して検出できる場合は、ディレクトリとルールを徐々に追加します。特定の種類の生成コードに誤検出が集中している場合は、長いプロンプト ワードを重ね続けるよりも、ファイル選択を修正することを優先します。
OpenCodeReview の真の価値は、再現可能なエンジニアリング制約とモデルの判断を組み合わせることにあります。長期使用に値するかどうかは、最終的には自社のリポジトリデータによって証明される必要があります。