Summary

  • GitHubの公開プレビューでは、組織に導入したAppが組織権限Copilot RequestsをRead-onlyで持つと、インストール用アクセストークンでCopilotを呼べる。利用者のサインインは不要で、AIクレジットは組織が負担する。モデル制限と組織の支出設定は適用されるが、Appやインストール単位の予算は作れない。
  • App別の利用元は画面上のAI利用表示には出ず、CSVのapp_client_idをインストール一覧のclient_idと照合して調べる。特定のAppを止めるにはインストールを停止または削除する。その操作は、当該Appのほかの組織資源へのアクセスも断つ。

読み取り権限が請求を止めてくれるわけではない

Appの権限審査では、Read-onlyという語が安心材料になりやすい。しかしGitHubの説明では、組織権限Copilot Requests: Read-onlyはCopilotへの要求を認め、その要求は組織のAIクレジットを使う。Appはインストール用トークンで呼び出し、従業員がその都度ログインする必要はない。権限名はAPI操作の種類を示す。料金が発生するかどうかは別の勘定だ。

この認証経路は組織にインストールされたApp向けで、個人アカウントやエンタープライズへのインストールには使えない。利用できるモデルは組織のCopilotポリシーの範囲内であり、組織の請求・支出設定も適用される。利用者本人の認可、組織負担のCopilot CLIを許す設定、ActionsのGITHUB_TOKENとは異なる経路だ。自動化を一つの箱に入れて費用を眺めると、どの鍵が財布を開けたのか見失う。

組織はAppの利用をCopilot予算に算入できる。一方、GitHubは個々のAppまたはインストールに専用予算を作れないと明記する。警告だけの予算なら、設定額に届いても利用は止まらない。追加の利用を止めたい場合はStop usage when budget limit is reachedを有効にする。これは組織全体の支出を守る仕組みで、特定のAppだけを絞る小さな栓ではない。

ダッシュボードの外にある名前

GitHubのAI利用画面にはAppへの帰属が表示されない。組織の所有者はAI利用レポートをCSVで出し、organization列に自分の組織が入り、app_client_idに値のある行を探す。次に組織のAppインストール一覧APIで、その値をclient_idと照合する。そこで得られるapp_slugがAppを特定する。利用の証拠はあるが、画面上の総額を見ただけでは誰が使ったか分からない。

空のapp_client_idを「Appは使っていない」という結論に使うのも危うい。GitHubによれば、利用者に帰属する利用、Actions、GitHub自身のApp、帰属機能より前の履歴などでは空になる。値のある行はインストール経路を示すが、不正や無駄遣いの判定まではしない。金額を確かめるには、その組織の実際の利用レポートが要る。

Copilotの従量利用はAIクレジットで計算され、GitHubは1クレジットを0.01米ドルとする。BusinessとEnterpriseではライセンスに基づく月次の共有枠から先に使い、Copilot accessにはその枠がない。Chat、CLI、クラウドエージェントなどが計量対象で、インライン補完と次の編集候補はこのAIクレジット計量の対象外だ。したがってAppの要求量と現金請求額は同じ数字ではない。公開資料には特定の導入Appの請求額は載っていない。

止めるレバーは別の回路も切る

組織所有者は、特定のAppインストールを停止または削除すれば、そのAppからのCopilot要求を止められる。ただしGitHubは、同じインストールが持つ他の組織資源へのアクセスも失われると説明する。モデルの制限、組織予算の強制停止、インストール停止はそれぞれ作用する範囲が違う。App専用予算がない以上、承認時に費用と停止時の業務影響を同時に決めるしかない。

誰が導入を申し出たのか。どのモデルを使うのか。CSVでそのAppの消費を誰が追うのか。停止したらどの連携まで止まるのか。権限欄の短いRead-onlyより、その四つの答えが長く効く。

出典