2026年の自動コードレビュー：シートを買わずにすべてのPRで実行させる

自動コードレビューは、差分を言語モデルに送信し、該当行に指摘を投稿し、重大な問題を検出したときにステータスチェックを失敗させるCIジョブです。シート単位のサブスクリプションなしで、すべてのプルリクエストでこれを実行する方法は、オープンソースのハーネスをセルフホストすることです。つまり、リポジトリに約15行のワークフローをコピーし、APIキーを1つ追加すれば、支払うのは各レビューが消費するトークンの分だけです。そもそもシートが存在しないので、購入するシート数もありません。当社が保守しているリファレンス実装はOrca-Code-Reviewリポジトリであり、公開・MITライセンスで、2026年6月25日の作成以来、OrcaCode Review GitHub Actionの背後にあるコードです。同梱のルーティング設定では、レビューパスはデフォルトでDeepSeek V4 Flash、独立検証ジャッジはGLM-5.3に設定されており、いずれも自由に変更できます。この記事では、プッシュのたびに実際に実行される処理、設定が必要な項目、トークン換算のコスト、そして2週間目に遭遇する失敗モードを解説します。

簡単に言うと、すべてのプッシュに対して1回のレビューが行われます。指摘事項は変更行にインラインで投稿されます。P0およびP1の指摘があるとチェックが失敗し、マージがブロックされます。問題がなければパスします。コメントで再レビューを依頼できます：/orcacode-review。ワークフローはあなたのリポジトリに、レビューロジックは公開されたアクションに、モデルの選択は自分のワークスペースで編集できるルーティングレシピにあります。レビュアーは差分とリポジトリのファイルを読み取り、あなたのPRのコードを実行することはありません。そして、正直な注意事項を先に述べておきます：実際のバグは検出できますが、コードがそうなっている理由を知っている人間が必要なバグは、やはり見落とします。

• 1つのワークフロー + 1つのシークレット + トークン請求。どの時点でもシート単位のライセンスは不要です。

• ハーネスはオープンソースです。 コピーして、フォークして、監査して、コミットSHAに固定してください。

• モデルは設定であり、ベンダーではありません。レビュー担当者を変更するには、YAMLを書き換えたりアクションをバンプしたりするのではなく、ルーティングレシピを編集してください。

• 過大な差分はコストがかからない。サイズガードはモデルの前に実行されます。

• それはあなたのコードを読み取り、実行することはありません。それが、pull_request_targetをそもそも安全に使用できるようにする安全性の性質です。

自動コードレビューの実際の仕組み

どんな自動レビューシステムも、同じ3つの材料が違う服を着ているだけだ：イベント、ランナー、レビューアー。

このイベントがトリガーです。同梱のワークフローは、プルリクエストイベント（opened、synchronize（新規プッシュ）、ready_for_review（ドラフトが準備完了になったとき））、およびPRコメントで発火します。そして、実行されるのはpull_request_target上であるため、ワークフロー定義はベースブランチから読み取られます。そのため、ワークフローはPRに対して実行される前にベースブランチに存在していなければなりません。プッシュごとに1回のレビューがあり、concurrencyブロックは前の実行をキャンセルするため、急速な一連のプッシュが古いコードの5つのレビューをキューに入れることはありません。

このランナーは、ubuntu-latest上のGitHub Actionsです。このジョブには3つの権限が必要です：コンテンツへの読み取りアクセス、プルリクエストへの書き込みアクセス（インラインコメントを投稿するため）、およびイシューへの書き込みアクセス（サマリーを投稿し、古いコメントをクリーンアップするため）。

そのレビューアは言語モデルです。このアクションは、PRヘッドを取得し、差分とエンジンが選択するリポジトリコンテキストを組み立て、それをレビューモデルに送信します。結果は、一連の指摘事項であり、それぞれが重要度でタグ付けされ、ファイルと行に関連付けられています。このアクションは、それらをインラインPRコメントとして投稿し、プッシュのたびにその場で置き換えられる1つの要約コメントをPR説明の先頭のマーカー領域に書き込みます。

そのゲートはステータスチェックです。GitHubは「レビュー」が何を意味するかを知りません。ただし、知っているのはそのレビューチェックの成否だけです。ゲートを実際に機能させるには、そのチェックをブランチ保護で必須にします。これがマージブロックの仕組み全体です — 管理者API呼び出しもラベルも不要で、必須チェックの失敗だけでブロックされます。

何が起こらないのか：PRのコードを実行するものは何もない。エンジンは読み取りのみを行う。この唯一の不変条件こそが、特権的なpull_request_targetトリガーを、有料APIキーと一緒に使っても安全なものにしている。

オープンソースのハーネスが差別化要因です。

上記のことは多くのツールにも当てはまります。しかし、ほとんどのツールに当てはまらないのは、全体が検査可能でセルフホスト可能であるという点であり、それがOrca-Code-Reviewリポジトリが提供するものです。これはMITライセンスの公開GitHubリポジトリ（JavaScript、2026年6月25日作成）で、レビューを再利用可能な複合GitHub Actionとインストーラーとしてパッケージ化したものであり、そしてそれは同じコードです。ホスト型OrcaCode Reviewアプリはそれを実行します。

ツリーで10分過ごせば、あなたのPRに触れるすべてのパーツを挙げられる。

• action.yml — 複合アクションです。文書化された入力が約15個あり、モデル名はそのどこにもハードコードされていません。

• workflows/orca-code-review.yml — コンシューマーワークフローの例で、.github/workflows/。

• recipes/ — ルーティングDSL。ここで実際にモデルが選択されます。

• rules/ — 重大度ルーブリック（P0〜P3）、必須の出力形式、およびプロジェクト自身の規約ドキュメントを信頼されない参照データとしてレビューに供給する規約ディレクティブ

• scripts/ — 精度フィルター（L1 と L2 判定器）、diff ガード、マージゲート、実行レポート、トークンメーター。それぞれが小さく読みやすい .mjs ファイルで、テストが付属しています。

• skills/setup-orca-code-review — インストーラーがコーディングエージェントに配置するスキルで、インストール、再構成、トラブルシューティング、アンインストールをカバーします。

• .claude-plugin/ — Claude Code がスキルを自己更新プラグインとしてインストールできるようにする仕組み。

インストールは、AIに製品が何かを教えて、それで終わるワンライナーです：

npx @orcarouter/code-review

CLIは、あなたが使用するコーディングエージェントを検出します。カタログは、Claude Code、Cursor、Codex、OpenCode、Windsurfから、GitHub Copilot、Gemini CLI、Amazon Q Developer、Cline、RooCodeなど、36のプラットフォームに及びます。スキルをインストールして、後はあなたに委ねます。その後、平易な言葉でエージェントに尋ねます：「このリポジトリでOrcaCode Reviewをセットアップして」 「P0のみブロックして」 「なぜレビューが実行されなかったの？」スキルがライフサイクルを担います。ワークフローを作成し、APIキーの設定手順を案内し、ゲートを設定し、あなたにしか答えられない質問だけをします。

Claude Code は代わりにスキルをプラグインとしてインストールできます。これにより、リポジトリの変更に合わせてスキルも更新された状態に保たれます：

/plugin マーケットプレイスに Continuum-AI-Corp/orca-code-review を追加

/plugin install orca-code-review

エージェントなし？同じライフサイクルは単なるサブコマンドです — initはワークフローを書き込み、reconfigureはブロッキングルールと差分制限を変更し、doctorは実行されない、または投稿されないレビューを診断し、uninstallは（必須チェックを最初に外して）それを削除します。スキルは正面玄関であって、唯一の入口ではありません。または手動で配線します: ワークフローをコピーし、次の名前のシークレットを1つ追加します: ORCAROUTER_API_KEY、そして review チェックを必須にします。

その基盤となっているエンジンは Ali​baba の Open Code Review で、正確なバージョンに固定され、Apache-2.0 ライセンスが適用されています。OrcaCode はレビューの方法を決定し、OrcaRouter はどのモデルがそれを実行するかを決定します。セルフホストとホステッドの収支比較、つまりオープンソースのレビュアーをセルフホストするときに「無料」が実際にはいくらかかるかという点は、オープンコードレビューに関する記事で詳しく説明されています。

プッシュのたびに順番に実行されるものは何ですか

順序を知っておくと役立ちます。各ステップは独立して失敗またはスキップされる可能性があるからです:

• 差分ガードは、モデルが実行される前に最初に動作します。 マージベースの差分が512KBを超えるか、300ファイル以上に及ぶ場合、レビューはスキップされ、通知が投稿されます。デフォルトは on-oversized-diff: fail であり、制限を超えて水増しされた差分は必須ゲートを未レビューのまま通過できません。これはコスト管理でもあります。サイズ超過のPRはトークンを消費しません。

• エンジンは差分をレビューします。 1パスで、ファイルごとの並行度はデフォルトで24、1パスあたりの実時間の上限は20分です。

• 精密フィルタは、生の検出結果を後処理します。 L1は決定的フィルタであり、各検出結果が主張する既存コードスニペットをレビュー対象のコミットと照合し、一致しないものを再配置または破棄します。L2はLLM判定器であり、検出結果を根本原因ごとにクラスタリングし、信頼度の低いクラスタを破棄します。どちらのレイヤーもソフトフェイル方式です。エラーが発生しても前段階の検出結果は保持され、レビューが中断されることはありません。

• ゲートが適用されます。 P0およびP1の指摘はチェックを失敗させます。PRサマリーは、diffからミュートされたものも含めて、すべての指摘をカウントします。

• メーターは、かかった費用を出力します。このメーターの入力は、呼び出しごとのトークン会計（プロンプト、完了、キャッシュされたトークン、およびルーターが決定したモデル）を記録し、ジョブログに合計表を出力します。

• 任意の実行レポートは、重大度カウントとゲートメタデータを分析ダッシュボード用にOrcaRouterコントロールプレーンへ送信します。コード、差分、検出結果テキストは一切含まれません。

実際に設定するもの

3つのサーフェスがあり、それぞれの爆発半径は大きく異なります。

1. ワークフローファイル。コンシューマワークフローは意図的に薄くしている。触れる価値のある入力はアクション内にある：block-on （チェックを失敗させる重大度 — デフォルトはP0,P1）、fix-first （網羅的レビューを早期に停止する重大度）、auto-review-authors （自動レビュー対象者の許可リスト）、max-diff-kbとmax-diff-filesとon-oversized-diff （サイズガード）、timeout-minutes、concurrency、meter、およびreport。それぞれにドキュメント化されたデフォルトがあり、新しいワークフローはYAML5行とシークレットで済む。

2. ダッシュボード。 設定が settings: true （デフォルト）の場合、各実行はOrcaRouter → Apps → OrcaCode Reviewからリポジトリごとの設定を取得します：モデル、レビューモード、マージポリシー、レポートの重大度、クワイエットモード、徹底レビュー、カスタムルーブリック、ガードレール。設定を settings: "false" にすると、ワークフローファイルが優先され、ダッシュボードの値で上書きできません。コンソールを開かなくても、ハーネスの機能を失うことはありません。YAMLで設定するだけです。

3. ルーティングレシピ——多くの人が見落とすもの。アクションはモデル名を一切指定しません。その代わりに、実行がどのティアとして記録されたか、前回のパスでP0/P1が見つかったかどうか、リクエストがL2ジャッジの場合はレンズマーカー、といった生の事実をリクエストヘッダーとして注入します。ワークスペースルーターのDSLレシピは、それらのヘッダーを具体的なモデルにマッピングします。標準搭載のレシピは、レビューのデフォルトをDeepSeek V4 Flashに、ジャッジのデフォルトをGLM-5.3に設定し、この2つを意図的に別々のモデルにルーティングしています。コードをレビューするモデルを変更するには、自分のワークスペースにあるそのレシピを編集するだけです。アクションのバージョンアップも、YAMLの書き直しも、再デプロイも不要です。

重大度契約は、1つの設定ではなく2つの独立した設定です。マージポリシーは、何がマージをブロックするかを決定します。レポート重大度は、何をdiffに投稿するかを決定します。既定値は、P0/P1がブロック、P2/P3がパスです。ブロックする重大度は、レポート設定にかかわらず常に投稿されます。—— その失敗を説明するものがdiffに何もないチェックは、ノイズの多いチェックよりも悪いです。P0は、悪用可能なセキュリティ脆弱性、データ損失、通常のパスでのクラッシュ、またはビルドの破損を意味します。P1は、実際に存在するが影響が限定されたバグを意味します。P2は、異常な前提条件下でのみ発生する実際の欠陥を意味します。P3はスタイルです。2つのレベル間で迷った場合は、評価基準は低い方を選ぶとしています。

料金

トークン単位であり、シート単位ではありません。OrcaRouterでモデルを選択し、課金は消費トークン単位で発生します。そして、メーターによって、実行ごとの数値が不明瞭ではなく可視化されます。GitHubの仕組み、2026年6月1日からのCopilotの従量制コードレビュー、そしてサードパーティのレビュアーがそのワークフローにどう組み込まれるかについては、当社のGitHubコードレビューガイドで解説しています。シート単位の製品とトークン単位の製品の、計算例付きの全項目にわたるコスト比較は、当社のAIコードレビューツール比較にあります。また、レビュアーが実際にリポジトリを調査する場合（ボットとエージェントの違い）に、1回のレビューパスがトークンでいくらかかるかという問題は、当社のコードレビューエージェントの記事にあります。この記事が付け加える点は、請求の形です。すなわち、請求額はレビューするコード量に比例し、レビューする人数には比例しません。

初日に重要な支出管理は2つあります。パブリックリポジトリでは、pull_request_targetがGitHubのフォーク承認ゲートを迂回し、レビューキーはウォレットメーター制のため、見知らぬ人がPRを開くと有料レビューが発生します。キーにアラート付きのウォレット予算を設定し、設定するのは、auto-review-authorsをたとえばOWNER,MEMBER,COLLABORATOR,CONTRIBUTORのような値にすることです。これにより未知のコントリビューターは自動レビューされません。そして、前述のとおり、diffガードにより、過大なPRはコストが一切かかりません。

何が壊れる

自動レビューはCIである。それはCIのように壊れ、失敗モードはほとんどモデルのせいではない：

• ワークフローが実行されません。 の場合、pull_request_targetワークフローはベースブランチから読み込まれます。PRブランチだけで追加されたワークフローは、マージされるまで実行されません。また、アプリが有効になっていること、auto_review がオンになっていること、PR がドラフトではないこと（ドラフトは ready_for_review モードではスキップされます）、リポジトリで Actions が有効になっていること（フォークされたリポジトリではデフォルトでオフになっています）を確認してください。

• /orcacode-review は何もしません。コメントトリガーが機能するには、コメントが次の4つの表記のいずれかで始まる必要があります — /orcacode-review、/orcacode review、@orcacode-review、@orcacode review — そして、コメント投稿者がOWNER、MEMBER、またはCOLLABORATORである必要があります。先頭にスペースがあるとマッチしません。外部のコントリビューターのコマンドは、意図的に黙って無視されます。なぜなら、そのコマンドは有料キーを保持する特権ワークフローを実行するからです。

• 認証エラーです。シークレットの名前が間違っているか存在しない、キーが失効しているか予算を使い切っている、またはワークフローがpull_requestに切り替えられた（フォークからシークレットを読み取ることができません）。

• チェックは赤で、「diff too large」という通知が表示されます。 これはサイズガードが設定どおりに動作しているだけです。PRを分割するか、制限値を引き上げるか、あるいは on-oversized-diff: pass を設定してください。そして、必須チェックがある場合、pass は十分に大きなPRがレビューされずにそのままゲートを通過することを意味することを理解してください。

• レビューは実行されますが、コメントは表示されません。原因は3つあり、いずれも無害または設定によるものです。クリーンな実行では、インラインコメントではなくサマリーが投稿されます。クワイエットモードが投稿時にP2をミュートしている場合（ゲートとレポートではカウントされています）。または、精度フィルターが結果を除外した場合です。L1はコミットと一致しないスニペットの結果を除外し、L2は信頼性の低いクラスターを除外します。ジョブログの重大度カウントで、どの原因かを確認できます。

セキュリティ態勢は、設計全体の安全性を支えるものだからこそ、明確に述べる価値がある。エンジンはdiffとリポジトリのファイルを読むだけで、PRコードを実行することは決してない。レビューアはマージ権限を持たない。検出結果はマージをブロックしたりコメントを追加したりできるが、モデルの出力がリポジトリを承認または変更するコード経路は存在しない。タグ付けされていない検出結果はフェイルセーフとなり、助言ではなくブロックとして扱われる。また、実行レポートにはコードや検出結果のテキストは含まれない。シングルパスレビューでは見逃される問題を捕捉する2層構成は、当社のAIコードレビューセキュリティ記事の主題である。上記の脅威モデルはリポジトリのSECURITY.mdに文書化されている。

自動レビューが不適切なケース

これはツールベンダーが認めるよりも頻繁に間違っています。以下の場合は見送ってください：

• 問題は量ではなく、文脈です。 レビューが遅い理由が、レビュアーがコードの意図を理解する必要があることにあるなら、LLMが差分を読んでもほとんど意味がありません。LLMには先月のスレッドの記憶も、システムの歴史の把握もありません。

• 差分のほとんどは、生成コードまたはベンダーコードです。自動整形された出力、スキャフォールドされたファイル、依存関係のスナップショットなどです。これらをレビューするとトークンを消費し、ノイズが生まれます。そして、conventionsディレクティブが最も役に立たないのも、まさにこうしたコードです。というのも、そのコードは意図的にプロジェクトのスタイルに合わせているわけではないからです。

• チームはすでにすべてをペアレビューしている。自動レビューは量を増やすためのレバーである。すべての変更がすでにその場にいた人間によってレビューされているなら、機械が追加するセカンドオピニオンは、通常、最初の意見より情報量が少ない。

• 誰も調査結果を読みません。 誰も対応しないレビューは、永遠にグリーンで失敗するワークフローです。これは最も一般的なサイレント障害であり、精度フィルターでは修正できません。

• レビューはコードを実行する必要があります。 PRに対するテストスイートが必要な場合、LLMレビューは間違ったツールです。LLMは読み取るだけで、実行しません。アーティファクトをビルドして実行する必要があるセキュリティスキャンは、別途、慎重に範囲を設定したジョブに属します。レビューワークフローは、PRが制御するコードを実行するために拡張してはならないことを忘れないでください。

• リポジトリが小さい、または使い捨てである。 変更頻度が一定以下であれば、レビューは検出されるバグよりもオーバーヘッドの方が大きくなる。

誤検知、および精度フィルタリングで解決できる問題とできない問題

すべてのAIレビュアーに対する非難は、狼少年のように嘘の警告を発することだ。ハーネスはこれを2つの層で攻撃するが、どの層がどの失敗を修正するのかを正確に把握することが役立つ。

この決定的レイヤー（L1）はゴーストファインディングを排除します。エンジンが時々、実際にはそこに存在しないコードを主張することがあります。たとえば、移動してしまったスニペットや、兄弟ファイルにコピーされたファインディングなどです。L1は、各ファインディングの既存コードスニペットを実際にレビューされたコミットと照合し、不一致を再配置するか破棄します。これにより、「この行は存在すらしない」というクラスの誤検知が修正されます。この修正は機械的で検証可能です。

このジャッジレイヤー(L2) は、重複した所見と裏付けのない所見を排除する。LLM ジャッジは、所見を根本原因ごとにクラスタリングし、信頼度がジャッジのしきい値（デフォルト 0.5）を下回るクラスタを破棄する。これにより、「同じバグが3つの方法で報告される」という問題と、推測による所見が解消される。

どちらの層も修正しない問題は、はっきりと言う価値がある。間違っているが自信に満ちた指摘事項は審査を生き延びる。審査はLLMであり、確信に満ちた口調のLLMは、真実の指摘事項とは同じではない。レビュアーと同じモデルで動く審査は自分自身と一致し、パスは成功を報告しながらも不活性になる。だからこそ、製品版のレシピでは審査がレビュアーとは別のモデルにルーティングされるのだ。また、重大度ルーブリックは意図的に控えめに設計されている。「2つのレベルの間で迷ったら、低い方を選ぶ」— つまり、実際に存在するが条件付きのバグは、ブロッキングなP1ではなくP2アドバイザリとして扱われる可能性が高い。これはすべてをブロックしてはいけないツールにとって正しい調整だが、調整であることに変わりはない。つまり、見逃したブロッカーをより少ない誤報と引き換えにするのだ。PRサマリーには常にすべての指摘事項がカウントされるので、抑えられたP2もそこに読める形で残っている。そのトレードオフが自チームにとって間違っているなら、ルーブリックと審査のしきい値は、サポートチケットではなく設定の問題である。

結論

すでにGitHub Actionsで開発しているチームにとって、オープンソースのハーネスは、すべてのPRで自動コードレビューを得る最も安価な方法です。必要なのは、ワークフローファイル1つ、シークレット1つ、レビューするコード量に応じて増えるトークン費用、そして自分で選べるモデルです。運用ゼロと問い合わせ先のベンダーが必要なら、シート単位の製品を購入してください。レビューが優れているからではなく、自分で運用する代わりに誰かの問題を買っているのです。そして、その設定を始める前に、レビューが実際に読まれるかを問うてください。ハーネスはレビューを自動的に発生させることはできますが、誰かにそれを読ませることはできません。

同じレビュアーを自分で実行せずに利用したいですか？ OrcaCode Reviewは、このまったく同じハーネスをホスト型GitHub Appとして実行します — 同じオープンレシピ、同じトークン単位の課金、シート不要です。