GitHub Copilot がサーバー間認証に対応。App で組織名義の利用が可能に

GitHub Copilot が、組織にインストールした GitHub Apps によるサーバー間認証に対応しました。提供形態はパブリックプレビューです。GitHub Copilot SDK で作ったサービスやエージェントが、サインイン中のユーザーの資格情報に頼らず、組織の名義でリクエストを送れるようになります。

この記事では、GitHub の公式 Changelog にある内容だけを整理します。開発者側の設定、課金と制御の考え方、組織オーナーが確認できることの順に説明します。

何が変わったのか

ユーザーの資格情報に頼らない認証

これまで Copilot SDK を使ったサービスは、サインイン中のユーザーの資格情報に認証が結び付く形でした。今回のサーバー間認証では、GitHub App が認証の主体になります。

公式はこれを「workload-owned identity」、つまりワークロード側が持つ ID と説明しています。エージェントや自動化サービスを、より大きな規模で安定して動かすための仕組みです。認証や利用が個々のユーザーに結び付かない点が特徴です。

対象は組織にインストールした GitHub Apps

対象は、組織にインストールされた GitHub Apps です。ここで作られるリクエストは、特定の個人ではなく、App をインストールした組織の名義で処理されます。

提供状況はパブリックプレビューです。

開発者側の設定の流れ

公式が示している手順は、次の 3 つです。

  1. GitHub App に、読み取り専用の「Copilot Requests」組織権限を付与する
  2. その App を組織にインストールする
  3. 短命のインストールアクセストークンを Copilot SDK に渡す

Copilot Requests 権限は読み取り専用

付与する権限は、読み取り専用の組織権限である「Copilot Requests」です。権限の名前と種類が明示されているため、App の設定画面で何を選ぶかは迷いにくいでしょう。

短命のトークンを SDK に渡す

SDK に渡すのは、短命のインストールアクセストークンです。長期間有効な個人のトークンではなく、インストールに紐づく期限の短いトークンを使います。

トークンの発行や更新の具体的な手順は、公式が案内する「server-to-server authentication for the GitHub Copilot SDK」のドキュメントにあります。

課金とポリシーはどう扱われるか

利用と課金は組織に帰属する

公式によると、利用は App をインストールした組織に帰属し、課金もその組織に対して行われます。ユーザー個人ではなく、組織の利用として扱われます。

組織の既存の制御がそのまま適用される

次の制御は、App 経由のリクエストにも適用されると書かれています。

  • 組織のモデルポリシー
  • 予算
  • 支出の制御

App 経由だからといって、組織の制御の外に出るわけではありません。組織側で決めているモデルの利用範囲や予算の上限は、そのまま効きます。

組織オーナーが確認できること

組織のオーナー向けに、公式は次の 3 点を挙げています。

どの App にアクセスがあるかを確認できる

オーナーは、どの App が Copilot へのアクセスを持っているかを確認できます。確認の手順は、公式の「managing GitHub App access to your organization’s Copilot」に案内されています。

利用状況を CSV レポートで特定できる

App による利用は、AI 利用状況の CSV レポート上で app_client_id フィールドを使って特定できます。人の利用と App の利用を切り分けて見るときに使うフィールドです。

フィールド名まで公式に書かれているので、レポートを集計している組織は、このフィールドで絞り込めるかを確認するとよいでしょう。

App を停止またはアンインストールしてアクセスを止められる

App のアクセスを止めたいときは、その App をサスペンド（一時停止）するか、アンインストールします。想定外の利用が見つかった場合の止め方が、あらかじめ用意されています。

誰に関係する話か

Copilot SDK でエージェントやサービスを作る開発者

最も直接関係するのは、Copilot SDK でサービスやエージェントを作っている開発者です。個人のサインインに依存しない認証が使えるようになります。

公式が挙げる狙いは、規模を大きくしても安定して動かすことです。特定のユーザーの認証や利用に結び付かないため、担当者の異動や退職に左右されにくい構成を組みやすくなります。ただし、これは公式の記述ではなく、私の整理です。

Copilot の利用を管理する組織オーナー

組織のオーナーにとっては、App 経由の利用が組織名義で課金され、既存のポリシーと予算の下に置かれる点が要点です。

  • どの App がアクセスを持つかを確認できる
  • CSV レポートで App の利用を特定できる
  • 必要なら停止またはアンインストールで止められる

この 3 つがそろっているため、導入を許可するかどうかを判断しやすくなります。

導入前に確認しておきたいこと

導入の前に、公式ドキュメントで次の点を確認します。

  • 利用できる Copilot のプランや、対象となる組織の条件
  • パブリックプレビュー中の制限や、料金の具体的な扱い
  • トークンの発行と更新の実装方法

詳細は、公式が案内する次の 2 つのドキュメントにあります。

  • server-to-server authentication for the GitHub Copilot SDK（開発者向け）
  • managing GitHub App access to your organization’s Copilot（組織の管理向け）

開発者は前者を、オーナーは後者を先に読むと、自分の作業範囲がつかみやすくなります。

まとめ

今回の対応で、Copilot SDK 製のサービスやエージェントは、GitHub App の ID で組織名義の Copilot 利用ができるようになりました。要点は次のとおりです。

  • 組織にインストールした GitHub Apps が対象で、提供はパブリックプレビュー
  • 読み取り専用の「Copilot Requests」組織権限を付けた App を使う
  • 短命のインストールアクセストークンを Copilot SDK に渡す
  • 利用と課金は、インストールした組織に帰属する
  • 組織のモデルポリシー、予算、支出の制御が適用される
  • オーナーは App の確認、app_client_id による利用の特定、サスペンドやアンインストールによる停止ができる

プレビュー段階の機能なので、まずは小さな範囲で試し、組織のレポートに利用がどう表れるかを確認してから広げるのが安全です。

出典

内容は確認日時点のものです。最新の情報は、出典の公式ページで確認してください。

本記事は、公式情報（GitHub Changelog）の内容を整理したものです。私が実際に使った感想ではありません。アフィリエイトリンクは含みません。 確認日: 2026-10-28 / 出典: https://github.blog/changelog/2026-10-27-github-copilot-supports-server-to-server-authentication