AIにプルリクエストを読ませてみたが、指摘が多すぎて誰も読まなくなった。レビューのコメント欄が機械の発言で埋まり、人の指摘が流れていく。導入して数週間でそうなり、静かに止めてしまう。AIのコードレビューを試すと、こうした経過をたどることがあります。
AlibabaがOSSとして公開しているOpenCodeReviewは、この「うるさくなる」問題を、AIの賢さではなく担当範囲の切り方で避けようとしています。仕組みを見ると、受託開発に入れるときに何を決めるべきかも見えてきます。
AIに任せていないところが多い
GitHubのリポジトリとREADMEによると、OpenCodeReviewはGo製のコマンドラインツールで、Apache-2.0ライセンスで公開されています。Alibaba社内で2年ほど使われてきたものを2026年5月に公開し、GitHubのスター数は4ヶ月あまりで4万を超えました（2026年9月24日時点）。
特徴は、レビューの工程を決定的な処理とAIの処理に分けている点です。どのファイルを対象にするか、どうまとめて渡すか、どのルールに当てはまるか、指摘をコードのどの行に付けるか。こうした間違えてはいけない作業は通常のプログラムが担当し、コードを読んで判断する部分をAIに任せます。組み込みの検査項目として、ヌルポインタ参照、スレッド安全性、XSS、SQLインジェクションなどが用意されています。
モデルは自分で選ぶ形で、Anthropic、OpenAIのChat Completions、OpenAIのResponses、AWS Bedrockの接続方式に対応するとされています。開発元が公開しているベンチマーク（50の公開リポジトリから集めた10言語・200件のプルリクエスト）では、同じモデルを使った場合に、適合率（Precision）とF1値がClaude Codeより高く、使用トークンはおよそ9分の1だったと説明されています。一方で、実際の不具合を拾える割合（再現率）はClaude Codeより低く、誤検知を減らす側に寄せた設計だとしています。
指摘の位置合わせをAIとは別の仕組みに担わせているのは、実務上の意味が大きいと考えます。存在しない行への指摘が混じるだけで、レビュー全体の信用が落ちるからです。
受託で最初に決めるのは、コードの行き先
ここまでは道具の話です。受託開発の工程に入れるとなると、最初の論点は精度ではなくなります。預かっているのは顧客のコードだからです。
| 決めること | 具体的に確認する内容 |
|---|---|
| コードの送信先 | どのモデル提供者に渡るか、保存・学習の扱い |
| 契約上の可否 | 秘密保持契約に第三者サービスの利用条項があるか |
| 顧客への説明 | 使う旨を事前に伝えるか、成果物にどう記載するか |
| 責任の所在 | AIが見逃した不具合の扱いは従来のレビューと同じか |
モデルの提供者を選べるということは、選択がそのまま契約の問題になるということです。READMEの説明では、変更されたファイルを設定したLLMへ送り、エージェントがファイル全体の読み込みやコードベースの検索も行います。送られる範囲は差分だけとは限りません。顧客のコードを社外のAPIへ送る前に、契約書のどの条項で許されているのかを確認します。ここを曖昧にしたまま導入すると、便利さと引き換えに説明できない状態を抱えます。AIによる点検を誰が担い、最後に誰が確かめるかはAIが生成したコードのレビューをどう組むかでも扱っています。
人のレビューを減らす道具ではない
もう一つ決めておくのは、AIの指摘をどう扱うかです。機械が出した指摘をそのまま顧客へ「レビュー済み」として提出することはできません。受託の成果物に対する責任は、道具を変えても移りません。
現実的な組み方は、AIを人のレビューの前に置くことです。明らかな不具合と規約違反をAIが先に落とし、人は設計の判断と業務仕様の妥当性に時間を使う。この分担なら、レビューの総量は減らないまま、人は判断が要る箇所に時間を回せます。人のレビューで何を指摘すべきかの整理はコードレビューの2種類のコメントにまとめています。
公開されているベンチマークの数字も、そのまま自社に当てはまるとは限りません。対象は10言語200件で、言語構成もコードの規模も自社の案件とは違います。導入するなら、自社の過去のプルリクエストのうち顧客のコードを含まないものを何十件か流して、実際に出る指摘と見逃しを読んでから判断するのが確実です。
試すときの進め方
社内の案件を1つ選び、顧客のコードを含まないリポジトリから始めてください。指摘の量と質を見てから、契約上の確認を済ませた案件へ広げます。順番を逆にすると、便利さが分かった後で止めることになり、それがいちばん角が立ちます。
2026年9月24日に、GitHubのリポジトリ情報とREADME、同梱のスキル説明（SKILL.md）を確認しました。ベンチマークの数値は開発元の発表で、編集部では再現していません。OpenCodeReviewのインストール、実行、指摘精度の検証も実施していません。本記事は導入判断の論点と進め方の整理です。
開発プロセスへのAI導入や、レビュー体制の設計の相談は、グリームハブへご相談ください。
