Copilot SDKにサーバー間認証の公開プレビュー：個人トークンに依存しない運用へ

GitHubは2026年10月27日、Copilot SDK向けのサーバー間認証を公開プレビューとして発表した。組織にインストールしたGitHub Appを通じて、特定の利用者のログイン情報に依存せず、組織のサービスとしてCopilotへ依頼できる。

退職や担当者変更で個人の認証が切れる運用を見直す際に関係する更新だよ。一方で、組織に使用量と費用が付くため、認証方法だけでなく予算と停止手段も確認したいね。

認証する主体が、利用者からアプリへ

公式の手順は、Copilot Requestsという組織権限をRead-onlyで持つGitHub Appを作成し、対象の組織へインストールするもの。短期のinstallation access tokenをCopilot SDKへ渡して使う。

このRead-onlyという名前は、GitHub Appに与える該当権限の設定名。エージェントが動く端末や別のサービスまで、一律に読取り専用になる意味ではないよ。ファイル操作やツールの権限は、実行環境でも別に制御する必要がある。

短期トークンには更新処理が必要

公式資料ではinstallation tokenの有効期間は1時間。長時間動くサービスでは、期限を考慮した更新が必要になる。生成したトークンを固定値として長期間使う設計にはできないね。

さらに、組織側でGitHub AppのインストールからCopilotへリクエストできる状態になっている必要がある。SDKへ値を渡しただけで、組織の許可・課金条件も整うわけではないよ。

実装時は個人の保存済み認証へ意図せず戻らないかも確認する。SDKの明示的なトークン指定と、自動の認証探索を無効にする設定の組合せは、公式資料の対象言語を見て合わせよう。

GitHub Actionsは別の公式経路を先に見る

公式資料は、組織所有のリポジトリ内のGitHub Actionsでは、組込みのGITHUB_TOKENを使う方法を案内している。Copilotリクエスト用の権限と、組織への課金を許可するポリシーが必要だよ。

そのため「自動実行するなら、必ず新しいGitHub Appと秘密鍵を保存する」とは限らない。Actionsか、それ以外のCI・常設サービスかを先に分け、公式に案内される認証経路を選ぼう。

導入前に管理者と揃えること

以下は編集部の確認案だよ。

1. 対象組織、アプリの担当者、利用目的を定める。
2. モデルの利用可否、予算、支出上限と利用量の確認先を揃える。
3. トークンの生成・更新と、個人認証へ戻らない設定を確認する。
4. 本番から分けた環境で、許可時・期限切れ・停止時の挙動を見る。
5. app_client_idで利用を追えるか、停止担当者が操作できるかを確認する。

この記事は公開プレビューの公式仕様を確認したもの。GitHub Appの作成や実際のCopilot呼出しは行っていない。CLIの期限付き認証とは用途が違い、組織のモデル設定はモデル方針APIも参考になるよ。