GitHub、Copilotのモデル利用ポリシーをAPIで管理可能に 4階層で正式提供
GitHub CopilotREST APIモデルポリシーガバナンス受託開発
GitHubが、Copilotで使えるモデルを制御する「モデルポリシー」のREST API（GET／PATCH）を正式提供した。エンタープライズ、エンタープライズチーム、エンタープライズアプリ、Organizationの4階層に対応し、権限をOrganizationやチームへ委譲する運用も選べる。
何が発表されたか
- Copilotで利用可能なモデルを制御する「モデルポリシー」の参照（GET）と変更（PATCH）がREST APIで正式提供（GA）
- 対応スコープは4階層
- エンタープライズ：
/enterprises/{enterprise}/copilot/model-policies - エンタープライズチーム：
/enterprises/{enterprise}/teams/{team_slug}/copilot/model-policies - エンタープライズアプリ：
/enterprises/{enterprise}/copilot/apps/model-policies - Organization：
/orgs/{org}/copilot/model-policies
- エンタープライズ：
- エンタープライズのポリシーからOrganizationへ委譲する「organization mode」と、チーム・アプリへ委譲する「enterprise teams mode」を選択できる
- 必要な権限ロールについてはチェンジログ本文に記載がない
開発者への影響
受託でクライアント組織のリポジトリに入る立場だと、ここは**「使えるモデルが管理者側で決まる」前提を見積もりに織り込む**話になる。これまで管理画面でポチポチ設定していたものがAPI化されたということは、クライアント側がCI/CDやIaCでモデル許可リストを管理し始めるということ。つまり「今日はこのモデルで動いていたのに、明日は選択肢から消えている」が運用上ふつうに起こり得る。
実務的な備えは3点。ひとつは提案書や作業手順書でモデル名を固定して書かないこと。「Claude系の上位モデル」のような粒度にしておくと、ポリシー変更で手順書が死なない。ふたつめは、着手時に対象OrganizationのモデルポリシーをGETで確認しておくこと——どのモデルが許可されているかを先に握れば、動かないモデルを前提にした設計をやり直す手戻りが消える。みっつめは、エージェント構成でサブエージェントに安いモデルを割り当てている場合、その下位モデルが許可リストから外れると構成全体が止まる点。フォールバック先を1段用意しておきたい。
補足
GitHub公式チェンジログの2026年10月19日付エントリ。