AIコードレビューをCIに組み込みたいけど、コードを外部サービスに送るのは気が引ける——そう感じているチームに向けて、alibaba/open-code-review（以下 OCR）をGitHub Actionsに組み込む手順を実務目線で整理します。
「なぜこのツールを選ぶか」の判断材料から入り、設定ファイルの最小構成・ワークフローYAMLの実例・誤検知の調整まで、動かして終わりではなくチームで使い続けられる状態まで連れていくのがこの記事のゴールです。
セルフホストを選ぶ判断と、open-code-review がそこに収まる理由
CodeRabbitのようなクラウド型SaaSは、手軽さという点では申し分ありません。
ただ、コードが外部サーバーに送信される点と、月額コストの問題は正直に向き合う必要があります。
特に受託開発や金融・医療系のプロジェクトでは、顧客コードを外部に送ること自体が契約上アウトになるケースもあります。
「APIキーを自分で管理すれば、SaaSと同等のことが自前でできる」というのが、セルフホスト型を選ぶ基本的な判断軸です。
LLMのAPIを直接叩く形にすれば、コードはOpenAIやAnthropicのエンドポイントにしか飛ばない。
どこに何を送っているかが明確になるので、情報管理の説明責任を果たしやすくなります。
セルフホスト型のOSSレビューツールとしては pr-agent（Qodo）が先行していますが、OCRと比べたときの実務上の差分は大きく3点あります。
まず、Alibabaが社内で2年間・数万人規模とされる開発者に使い続けて磨いてきた 組み込みルールセット が最初から入っている点です。
ゼロから自前でプロンプトを書いてルールを育てる手間が省けます。
次に、OpenAI互換エンドポイントとAnthropicネイティブの両方に対応しているので、 既存のAPIキーがそのまま使える 点。
OpenRouterのようなプロキシ経由でも動くので、モデルの切り替えも柔軟です。
そして、npmでのグローバルインストール一発で動き始める 導入の手軽さ です。
OCRはGoで書かれたツールですが、npm経由での配布が主流になっており、CI環境でも追加のランタイム設定なしに組み込めます。
ただし、セルフホストが向かないケースもあります。
小規模チームで「APIコストの管理・モニタリングに割く時間がない」「設定ファイルを誰がメンテするかが曖昧」という状況なら、SaaSを素直に使うほうが運用コストは低くなります。
ツールの導入は手段であって目的ではないので、チームの実情に合わせて判断してください。
決定論的パイプライン＋LLMエージェントという二段構えの設計
OCRの設計で面白いのは、LLMに全部任せていないところです。
「静的ルールで先に絞り込み、LLMは判断だけに集中させる」という二段構えになっています。
LLMだけにコードレビューを任せると、いくつかの問題が起きやすいです。
コンテキストウィンドウに収まらない大きなdiffを渡すと重要な部分が抜け落ちる。
ハルシネーションで存在しない関数名を指摘してくる。
「37行目に問題があります」と言われても実際の行番号とズレている——こういった経験、心当たりがある方も多いのではないでしょうか。
OCRはこれを 決定論的パイプライン で解決しています。
どのファイルをレビュー対象にするか、指摘をどの行に紐付けるか、といった「位置決め」は静的なロジックで確定させる。
LLMエージェントはその上で「このコードに問題があるか」という判断だけに集中できる構造です。
結果として、行番号のズレや的外れな指摘が減り、PRのインラインコメントとして自然に読める形で出力されます。
組み込みルールセットがカバーしている主なカテゴリは以下のとおりです。
- NPE（NullPointerException）：nullチェックが漏れているメソッド呼び出し。外部APIのレスポンスをそのままフィールドアクセスしているコードを検出する
- スレッドセーフ：共有状態への非同期アクセス。複数のgoroutineやスレッドから同一変数を排他制御なしに読み書きしているケース
- XSS：ユーザー入力をエスケープせずにHTMLに埋め込んでいる箇所。テンプレートエンジンのautoescapeを無効化しているパターンなど
- SQLインジェクション：文字列結合でクエリを組み立てているコード。プレースホルダーを使わずに外部入力を直接埋め込んでいる箇所
対応言語はJava・TypeScript・Go・Python・Kotlin・C++・Cなど10言語以上です。
一方で、検出できないことも明確にしておきます。
ビジネスロジックに依存したバグ（「この計算式は仕様と合っているか」）、仕様書との整合性チェック、テストの品質評価は、OCRの守備範囲外です。
この領域は人間のレビュアーが担う部分として割り切っておくと、期待値のズレが起きにくくなります。
インストールから最小構成の設定ファイルまで
インストールはnpmグローバルインストールが現実的です。
npm install -g @alibaba-group/open-code-review
Goソースからビルドする方法もありますが、CI環境では毎回ビルドするのはコストが高いので、npmが無難です。
後述するGitHub Actions公式アクションを使う場合は、インストールステップ自体がアクション側で処理されます。
LLMの設定は ocr config set コマンドで行います。
OpenAI互換エンドポイント（OpenRouter経由を含む）を使う場合と、Anthropicネイティブを使う場合で設定が少し変わります。
OpenRouter（OpenAI互換）経由の場合：
ocr config set llm.url https://openrouter.ai/api/v1/chat/completions
ocr config set llm.auth_token sk-or-xxxxxxxxxxxx
ocr config set llm.model anthropic/claude-sonnet-4-5
Anthropicネイティブを使う場合：
ocr config set llm.url https://api.anthropic.com/v1/messages
ocr config set llm.auth_token sk-ant-xxxxxxxxxxxx
ocr config set llm.model claude-sonnet-4-5
ocr config set llm.use_anthropic true
ocr config set llm.auth_header x-api-key
これらのコマンドは設定ファイルに書き込まれます。
実体は以下のようなJSONで、パスは ~/.opencodereview/config.json です。
{
"llm": {
"url": "https://api.anthropic.com/v1/messages",
"auth_token": "sk-ant-xxxxxxxxxxxx",
"model": "claude-sonnet-4-5",
"use_anthropic": true,
"auth_header": "x-api-key"
}
}
CI環境ではシークレットから動的に書き込む形になるので、ローカルの設定ファイルをそのままリポジトリにコミットしないよう注意してください（APIキーが含まれます）。
GitHub Actionsに組み込む前に、ローカルで一度 ocr review を手動実行して疎通を確認しておくことを強くおすすめします。
Actions上でデバッグするより、ローカルで「指摘が出るか・行番号がズレていないか」を確認してから進むほうが、トラブルシュートがずっと楽になります。
GitHub Actions への組み込みとシークレット管理
OCRはリポジトリルートに action.yml を持つ composite action として公開されています。
自前でインストールスクリプトを書かずに済むので、これを直接参照するのが一番シンプルです。
ワークフローの基本形は以下のようになります。
name: AI Code Review
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
review:
runs-on: ubuntu-latest
permissions:
contents: read
pull-requests: write
steps:
- uses: alibaba/open-code-review@main
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
LLMのAPIキーや接続先の設定については、action.yml の実際の inputs キー名を 公式リポジトリの action.yml で確認してから記述してください。
キー名を誤るとサイレントに無視されるか、エラーで落ちるかのどちらかなので、コピーペーストではなく公式ソースを参照するのが確実です。
シークレット管理で特に注意が必要なのは、 fork PRからのシークレット漏洩リスク です。
pull_request_target イベントを使うと、forkされたリポジトリからのPRでもシークレットにアクセスできてしまいます。
悪意のあるコードをPRに混ぜてシークレットを抜き取る攻撃が成立するため、pull_request_target は原則使わないでください。
通常の pull_request イベントを使う場合、forkからのPRではシークレットが渡されないという制約があります。
これは意図した挙動で、外部コントリビューターのPRにはAIレビューが走らないという割り切りをするのが現実的です。
社内リポジトリ（forkを使わない運用）であれば、この制約は気にしなくて構いません。
base_ref と head_sha のオーバーライドオプションも action.yml に用意されています。
PRイベント以外——たとえば issue_comment トリガーで「/review」コメントが来たときにレビューを走らせたい場合——は、これらを明示的に渡す必要があります。
- uses: alibaba/open-code-review@main
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
base_ref: ${{ github.event.pull_request.base.ref }}
head_sha: ${{ github.event.pull_request.head.sha }}
diffサイズが大きいPRへの対処も実務上は重要です。
数百ファイルを一度に変えるようなPRをそのままレビューにかけると、APIコストが跳ね上がり、かつ指摘の質も下がります。
運用上の対処としては、1PRのdiffをある程度の規模に抑えるチームルールを先に作るか、レビュー対象のファイルパスをフィルタリングする設定を入れるのが現実的です。
APIコストは使用モデルとdiffサイズに比例するので、最初の数週間はコストをモニタリングしながらモデルを選ぶことをおすすめします。
誤検知を減らしてチームに定着させる
「動かして終わり」になりがちなのが、AIコードレビュー導入の一番の失敗パターンです。
最初の数週間は、指摘の内容を意識的に観察する時間として使ってください。
「どのファイルでノイズが多いか」「どのカテゴリの指摘が的外れか」を把握することが、定着への近道です。
ノイズが出やすいのは、経験上こういったファイルです。
- テストコード（意図的にエラーケースを書いている箇所をバグと誤認する）
- 自動生成ファイル（gRPCのスタブやORMのスキーマファイルなど）
- マイグレーションSQL（文字列結合が仕様上必要なケースでSQLインジェクションとして誤検知する）
これらは除外設定でレビュー対象から外すのが基本です。
OCRはファイルパスのフィルタリングをサポートしているので、テストディレクトリや自動生成ディレクトリを除外するだけでノイズはかなり減ります。
もう一つ有効なのが、CLIの --background オプション でコンテキストを渡すことです。
PRの背景や要件をLLMに伝えることで、「なぜこのコードがこう書かれているか」を踏まえた判断ができるようになります。
コミットメッセージや要件メモをbackgroundとして渡す運用を習慣にしておくと、的外れな指摘が減る実感があります。
チームへの導入で一番大事なのは、 「AIレビューはノイズも出る」という前提を最初に共有すること です。
「AIが言ったから直さなきゃ」という空気が生まれると、的外れな指摘への対応に時間を取られてチームが疲弊します。
「AIは形式面を見る、人間は仕様面を見る」という役割分担を明確にして、AIのコメントを無視してよいケースの基準をチームで決めておくと運用が安定します。
具体的には「テストコードへの指摘は原則スキップ」「セキュリティカテゴリの指摘は必ず確認」のような簡単なルールを最初に決めるだけで、レビュアーの判断コストが下がります。
AIレビューをチームに定着させるのは技術的な問題より合意形成の問題であることが多いので、ツールの設定と同じくらい、この会話に時間を使う価値があります。
株式会社ホコサキは、山口県宇部を拠点にWeb制作・業務システム開発・AI活用支援・DX推進に取り組んでいます。
OCRのような開発ツールの導入支援から、AIを組み込んだシステム開発まで、実務ベースで一緒に考えます。
ご相談は お問い合わせページ からどうぞ。