GitHub Copilot はワークロード所有の認証と組織の請求を追加します

GitHub は、Copilot SDK で構築されたアプリケーションにサーバー間認証を導入し、自動化されたワークロードが、サインインしている開発者の認証情報に依存せずに Copilot にアクセスする方法を提供します。

10 月 27 日にパブリック プレビューでリリースされたこの機能は、組織にインストールされている GitHub アプリを使用します。アプリは有効期間の短いインストール トークンを取得し、Copilot の使用量はインストールを所有する組織に帰属して請求されます。組織のモデル ポリシー、予算、支出管理は、アプリによって行われたリクエストにも適用されます。

これにより、内部サービス、リポジトリの自動化、または顧客対応の開発者ツールに Copilot を組み込むチームの運用モデルが変わります。認証は、ワークロードを承認した従業員ではなく、ワークロード自体を表すことができるようになりました。

ユーザー認証情報からアプリケーション ID まで

多くのエージェント統合は、個人のアクセス トークンまたは個々の開発者に関連付けられた別の認証情報から始まります。これはプロトタイプの段階では便利ですが、統合が永続的なサービスになると問題が発生します。従業員が役割を変更したり、資格情報が期限切れになったり取り消されたりすると、監査記録によって自動化されたアクティビティが人間のアクティビティのように見える可能性があります。

GitHub の新しいパスは、GitHub アプリに発行されたインストール トークンを使用します。インストール トークンの有効期間は短く、アプリのインストールと権限によって範囲が定められるため、有効期間の長いユーザー認証情報よりも無人ワークロードに適しています。

この区別はガバナンスにとって重要です。組織は、すべてのリクエストを名目上のオペレーターに帰するのではなく、Copilot の使用を担当するアプリケーションを特定できます。 GitHub には AI 使用状況 CSV レポートに app_client_id フィールドが含まれており、所有者は分析中にアプリ由来の使用状況を区別できます。

開発者チーム向けに AI API コントロール プレーンを構築しているチームにとって、これは便利な ID パターンです。人間のユーザー、自動化アカウント、およびデプロイされたアプリケーションは、区別できない認証情報や請求記録を共有すべきではありません。

請求は組織に従います

この方法で認証されたリクエストは、組織の Copilot 許容量を消費し、既存のモデル ポリシー、予算、支出管理によって管理されます。これにより、管理者は、アプリケーションが使用できるモデルと、組織が許可する AI 支出の総額を 1 か所で決定できるようになります。

これは、アプリケーション所有者がサーバー間のアクセスを独立した容量プールとして扱うことができないことも意味します。多忙な統合では、他の適格な Copilot アクティビティと同じ組織予算を活用できます。チームは、インタラクティブな使用と並行して自動化された消費を監視し、インシデント、再試行、予期しないリクエスト ループが共有制限にどのような影響を与えるかを決定する必要があります。

現在のプレビューでは、アプリまたはインストールごとに個別の予算を設定することはサポートされていません。 app_client_id フィールドは遡及的な帰属に役立ちますが、アプリケーションごとのレポートは、アプリケーション固有の厳密な上限を強制することと同等ではありません。分離が必要な組織でも、自動化されたワークロードの前に独自の計測レイヤーや AI API チームの支出管理が必要な場合があります。

開発者が変更する必要があるもの

この機能を採用する開発者は、GitHub アプリを作成し、関連する組織にインストールし、アプリの資格情報をインストール トークンと交換する必要があります。その後、アプリケーションは、Copilot SDK を介して呼び出すときに、その有効期間の短いトークンを使用します。したがって、展開システムは、静的な開発者トークンを無期限に保存するのではなく、トークンの発行と更新を処理する必要があります。

運用記録には、GitHub アプリ ID と各リクエストに対して請求された組織の両方を保存する必要があります。これは、複数の組織にサービスを提供するプラットフォームにとって特に重要です。あるインストール用に発行されたトークンを別の顧客のワークロードのルーティングに再利用してはならず、使用量のエクスポートは正しいテナントに対して調整される必要があります。

モデルはオフボーディングにも影響します。 1 人の開発者を削除しても、組織所有の統合を無効にする必要はなくなりましたが、GitHub アプリをアンインストールしたり、その権限を変更したりすると、アプリケーション自体をより直接的に制御できるようになります。実際の結果として、Workforce Identity と Workload Identity がより明確に分離されます。

残りの制限

サーバー間認証はまだパブリック プレビューであるため、GitHub は一般公開前に契約を変更する可能性があります。 GitHub は、この認証パスを介したエンタープライズ レベルのインストールまたは個人アカウントのサポートを発表していません。

アプリごとの予算の欠如は、最も直接的な制御ギャップです。組織は、どのアプリが使用量を生成したかを確認できますが、各アプリまたはインストールに独立した Copilot 予算を割り当てることはまだできません。企業が 1 つの組織の下で複数のコーディング エージェントを導入し、サービスとリポジトリの自動化をレビューするにつれて、このことはさらに重要になります。

そのような制限があっても、このリリースでは、機械生成された Copilot トラフィックに対するより明確な所有権モデルが確立されています。認証、ポリシー、課金はインストールされたアプリケーションとその組織に関連付けられるようになり、開発者の資格情報を借用するよりも永続的な自動化のためのより防御可能な基盤が作成されます。