要約

  • 必要な設定を有効にした組織では、Copilotのライセンスを持たないメンバーもコードレビューを利用できる。そのAI creditsは追加の有料利用として組織または企業に直接計上され、個人予算には割り当てられない。
  • プッシュや下書きのレビューを組織側のルールが要求すれば、本人の設定では止められない。レビューの頻度を定める人が、購入の頻度も定める。

社員全員にCopilotの席を用意しなくても、会社はその社員のレビュー代を払える。GitHubが用意したこの仕組みは、たまにコードを提出する人にも点検を届ける。購買担当者が数えるライセンスと、実際に動くレビューの範囲が、ここで離れる。

席のない人にもサービスを開くことには合理性がある。短い修正のために月々の契約を増やす手間を減らせるし、会社が必要だと考える点検を広く適用できる。ただし、レビューを自動化すると、買うと決めた瞬間は「レビューを依頼」のクリックより前に移る。社内ルールを保存した人が、後日の作業についても発注している。

個人の利用表に出ない購入

GitHubの製品説明によれば、ライセンスのないメンバーへの開放には、AI creditsの有料利用と、そうしたメンバーのコードレビュー利用という二つのポリシーが必要になる。後者は初期状態では無効だ。有効にすると、対象メンバーの自動・手動レビューのAI利用は、組織または企業へ追加利用として直接請求される。この機能の個人向け月間枠はなく、個人予算にも計上されない。

有料ライセンスを持つメンバーでは、本人の利用権益を使うのが標準だが、組織・企業の所有者は組織払いを選べる。有料利用の許可は必要でも、予算の設定は任意となる。支払先の変更だけで利用権限が付くわけではなく、アクセスは別に決める。

この分かれ方は、支出を説明するときに効いてくる。個人別の消費が少ないという表を見ても、組織のレビューが少なかったとは判断できない。組織に直接付けた分を加えなければ、会議に出てくるのは買い物の一部だけだ。全員の財布を調べても、会社の掛け払い帳は見つからない。

同じ変更でも、依頼の経路で負担先が変わる

標準の帰属では、自動レビューはプルリクエストの作者に、別の利用者が手動で依頼したレビューはその依頼者にAI利用が付く。Copilot cloud agentが作成した変更なら、まず対応する人間の共同作者が対象となり、その人に課金できなければ組織に回る。他のボットが作者である場合や、ボットがレビューを依頼した場合は、組織への直接計上になる。

コードを書いた人だけを費用の責任者として扱うと、こうした経路を見落とす。同僚が追加点検を依頼することも、チームがボットに変更を任せることも、仕事の進め方として自然だ。自然な作業の違いが、会計上の帰属を動かす。

また、レビューの継続可否は選んだ支払元に適用される予算に従う。個人払いならその人の上限、組織払いなら該当する組織、コストセンター、企業側の上限が関係する。誰の枠を使うかという設定は、誰の枠が尽きたときに仕事が止まるかという設定でもある。

会社払いは、会社が要求した点検を一部の社員の残高に依存させずに済む。そこで必要になるのは、個人への倹約の呼びかけより、共通サービスに対する購入方針だ。どの変更に、何度、どの深さで点検を付けるのか。その決定が支出の入口になる。

「毎回」の二文字はよく働く

自動レビューの設定資料には、新しいプッシュごとのレビューと、下書き段階からのレビューがある。個人設定とリポジトリ・組織のルールは別々に評価される。同じタイミングで複数の設定が当てはまってもレビューは一つだが、ルールで有効にしたプッシュや下書きの点検を本人が取り消すことはできない。

繰り返しの費用は、設定の重複ではなく、変更が進むたびに新たな点検機会が生じるところにある。修正、再提出、再修正と作業が進めば、「毎回」という指示がその都度働く。プルリクエストの本数だけを数えると、その中で動いたレビューを見失う。

早い段階で欠陥を拾えば、人が読み始める前に直せる。一方、細かな調整を重ねるたびに同じ部分を点検する価値は、変更の性質によって違う。会社が買うべきなのは安心した回数なのか、修正に役立つ発見なのか。ルールを設定する段階で問うほうが、月末に消費の多い社員を探すより筋が通る。

深さにも購入の余地がある。組織の既定のレビュー強度はリポジトリで調整できるが、組織が設ける最大強度は越えられない。既定値は通常の選び方を示し、最大値は使える範囲を制約する。おすすめを置いただけで、注文を制限した気になるのは危うい。

推論の隣で、実行時間も動く

GitHubの2026年4月27日の告知は、6月1日からコードレビューがAI creditsとGitHub Actionsの実行分数を消費するとした。モデルとのやり取りと、文脈収集やツール利用を担う実行環境を分けて計る仕組みだ。非公開リポジトリで標準のホスト型実行環境を使う場合、含まれる計算利用分と超過利用を分けて見る必要がある。

実行環境の資料では、GitHubのホスト型ランナーを無効にするとエージェント機能が使えず、限定されたレビューに移る。自社運用を選ぶこともでき、公式に対応する方法はARC管理のUbuntu x64ランナーで、ネットワーク制御も自社で整える。

自社運用ならActionsの分数は消費しない。その代わり、実行環境を維持する仕事が社内に来る。また、レビューのコメントが出続けていても、文脈を調べる能力が同じとは限らない。費用を比べるなら、どこで支払うかと、何が提供されるかを一緒に見る必要がある。

公開資料には個別顧客の実行履歴、照合済み請求額、有用な発見数がなく、それらがそろえば追加レビューの採算を判断できる。今ある設定だけでも、購入を発生させる権限の所在は追える。コードを慎重に扱う会社なら、慎重さを注文する人の権限も、同じくらい丁寧に扱いたい。