この記事のポイント
- GitHub Copilotが、個人のサインインに依存しない「サーバー間認証」をパブリックプレビューで公開しました。
- 認証の主体は組織にインストールしたGitHub Appで、利用量・課金は組織に帰属します。
- 組織オーナーはApp単位でアクセスの確認・一時停止・削除ができます。
GitHub Copilotが2026年10月27日、サービスやエージェントが組織の代理としてCopilotを呼び出せる「サーバー間認証」を公式発表しました。パブリックプレビューの仕組みと、組織で運用する際の管理条件を整理します。
組織に導入したGitHub AppのIDで呼び出す
Copilot SDKは、Copilotを使う自作サービスやエージェントのための開発キットです。今回の方式では、サービスが利用者個人の認証情報に頼らず、組織の代理としてリクエストを送れます。新しいサーバー間認証では、まず開発者がGitHub Appに「Copilot Requests」という読み取り専用の組織権限を与え、そのAppを組織にインストールします。発行された短期間だけ有効なインストールアクセストークンをCopilot SDKに渡すと、個人ではなくApp自体が持つIDとしてCopilotを呼び出せるようになります。利用量と課金はApp経由であっても組織に帰属し、組織が設定したモデルポリシーや予算、支出管理の設定がそのまま適用されます。
公式の管理ドキュメントでは、Copilot BusinessまたはEnterpriseの組織オーナーが対象です。組織にインストールしたApp用の方式で、個人アカウントやエンタープライズ自体へのインストールには使えません。GitHub Actionsの組み込みトークンを使う認証とは別の方式です。
Appごとの利用を確認し、アクセスを停止できる
自動化サービスやエージェントが個人のアカウントに紐づかずに動けるようになる一方、組織オーナー側には管理のための手段が用意されています。Appに与えたアクセス権はいつでも確認できますし、AI利用量のCSVレポートには「app_client_id」という項目があり、どのAppがどれだけ利用したかを特定できます。想定外の挙動や不要になったAppは、Suspend(一時停止)やアンインストールでアクセスを止められます。組織の利用枠を消費する権限なので、「読み取り専用」でも料金は発生し得ます。App別の予算は作れず、予算超過時に利用を止めたい場合は組織の停止設定が必要です。Appを一時停止すると、そのAppによる他の組織リソースへのアクセスも止まります。
SDKの認証手順によると、インストールトークンの有効期間は1時間です。個人のサインインを不要にしても、継続運用には期限前のトークン更新と実行環境への反映が必要になります。
まとめ
サーバー間認証は、Copilotを使った自動化やエージェントを「誰かのサインインに依存させない」ための仕組みです。組織が費用を負担するサービスとして運用したい場合に、個人の認証とは別に検討できる選択肢です。Copilotの管理機能をまとめて見直したい場合はGitHub CopilotのモデルポリシーAPI管理、個人の認証情報を見せない別の仕組みは1PasswordのAIエージェント向けログインも参考になります。
導入を検討する際は、Appの用途と想定利用量を確認し、トークン更新を担う仕組みと、停止時に影響する範囲を整理するとよいでしょう。App単位の利用記録を組織全体の予算管理につなげることが運用の判断点になります。
※ 2026年10月時点の情報です。
