CopilotモデルポリシーAPIで一括管理（2026年10月版）

10月19日の発表を4つの管理階層で整理

GitHubは2026年10月19日、Copilotのモデルポリシーを取得・変更するREST APIを一般提供しました。GitHub Changelogの発表では、Enterprise、Enterprise team、agent apps、Organizationの4階層にGETとPATCHが用意されたと説明されています。

管理階層	2026年10月22日時点のRESTパス	主に扱う範囲
Enterprise	/enterprises/{enterprise}/copilot/model-policies	全体の基準、既定の可否、下位階層への委任
Enterprise team	/enterprises/{enterprise}/teams/{team_id}/copilot/model-policies	Enterpriseから委任されたモデルのチーム向け追加許可
Agent apps	/enterprises/{enterprise}/copilot/apps/model-policies	人やチームとは分けたagent apps全体のモデルポリシー
Organization	/orgs/{org}/copilot/model-policies	Organizationに委任されたモデルと既定可否

GETは状態の取得、PATCHは明示設定の変更です。同じパスにHTTPメソッドを変えてアクセスします。ただし、Enterprise teamのプレースホルダーには注意が必要です。発表記事は{team_slug}と記載していますが、10月22日に取得したEnterprise AI controlsのRESTリファレンス、公式cURL例、パラメータ表は、いずれも整数の{team_id}を使っています。実装では現行RESTリファレンスの表記を確認してください。

APIの一般提供と、管理モード自体の提供段階も分けて考えます。4階層のGET／PATCHは一般提供ですが、Enterprise teams modeはオプトインのプレビューです。APIがGAになったことだけを理由に、Organization単位の運用からチーム単位へ切り替える必要はありません。

管理画面とAPIは、変更件数と再現性で使い分ける

画面とAPIは別のポリシー体系ではありません。同じ上位・下位関係を、手作業で操作するか、機械的に取得・変更するかの違いです。少数の設定を目で確認しながら変更するなら画面が分かりやすく、複数のOrganizationやteamで同じ基準を保つならAPIが向いています。

判断軸	管理画面が向く場面	REST APIが向く場面
対象数	EnterpriseやOrganizationを少数だけ確認する	複数のOrganization、team、agent appsを同じ手順で点検する
変更方法	管理者が状態を見ながら個別に選ぶ	承認済みの期待値とGET結果の差分を作り、対象だけPATCHする
再確認	設定画面を再度開いて確認する	PATCH後にGETを再実行し、レスポンスを保存して比較する
記録	GitHubの監査ログと変更申請を参照する	監査ログに加え、自社の実行者、変更理由、リクエスト、レスポンスを同じ変更記録へ残す

画面で行う設定

Enterprise ownerは、Enterpriseの「AI controls」から「Copilot」「Configure models」と進み、各モデルを全体でEnabled、全体でDisabled、またはOrganizationやEnterprise teams／appsへDelegateできます。Organization ownerは、委任されたモデルを「Settings」「Copilot」「Models」でEnabledまたはDisabledにします。Enterpriseが強制した状態はOrganization側から変更できません。

APIが必要になる場面

APIの利点は、一括変更というより「同じ判定手順を繰り返せること」です。たとえば、全Organizationの期待値を社内の設定ファイルで管理し、GETの結果との差だけをレビュー対象にできます。承認後にPATCHし、再GETした結果とGitHubのモデル選択画面を証跡として残せば、画面を順番に開く運用より差分を追いやすくなります。変更者の範囲を先に決める際は、AIエージェントのガバナンスと権限設計も参考になります。

GitHubのCopilot監査ログに関する公式ドキュメントは、設定やポリシーの変更が監査ログに含まれると説明しています。一方、今回確認したモデルポリシーAPIの資料には、この変更専用のイベント名や、UI変更とAPI変更の記録差までは書かれていません。そのため、APIを自社の承認フローへ組み込み、実行内容も自社側で残す設計が安全です。

6モデル廃止後に管理者が確認する順番

APIの一般提供と同じ2026年10月19日、GitHubはCopilot Chat、inline edits、Ask／Agent mode、code completionsなど、多くのGitHub Copilot体験で6モデルを廃止しました。廃止対象と公式が示した代替は次のとおりです。

廃止モデル	10月19日の公式な代替案
Gemini 3.7 Flash	Gemini 3.8 Flash
GPT-5.5	GPT-6.1 Sol
GPT-5.4	GPT-6.1 Sol
GPT-5.4 mini	GPT-6 Luna
GPT-5 mini	GPT-6 Luna
Grok 4.5	Grok 4.7

廃止内容そのものは、Uravationの既刊GitHub Copilot提供終了の対象6モデルで詳しく整理しています。ここでは、廃止後の管理作業に絞ります。

1. 管理モードを確認する：Organization modeかEnterprise teams modeかを先に確認します。管理先を取り違えると、Organizationで変更できない、teamでモデルを追加できないといった行き違いが起きます。
2. GETで現在値を取得する：Enterpriseを起点に、運用中のOrganization、team、agent appsの順でpolicy_stateを確認します。team／appsではモデルごとのeditable、Organizationではdefault_availability.editableも確認します。モデル名は記憶で入力せず、GETが返したmodel_nameを使います。
3. 代替モデルを必要な範囲で有効にする：全員に必要ならEnterprise、Organizationごとに判断させるなら委任、特定teamやagent appsだけならEnterprise teams modeの下位ポリシーを使います。
4. PATCH後にもう一度GETする：HTTP 200だけで完了とせず、期待した階層の状態が変わったかを再取得します。OrganizationのPATCHはアトミックで、適用できない変更が1件あると同じリクエスト内の変更は保存されません。
5. 利用者の画面で確認する：VS Codeとgithub.comのCopilot Chatをそれぞれ開き、代替モデルが選択肢に現れるかを確認します。

10月19日の廃止告知は、廃止モデルを管理者が手動で削除する必要はないとしています。必要なのは、利用する代替モデルがポリシーで許可されているかを確かめることです。

VS Codeとgithub.comは別々に確認する

VS CodeではCopilot Chatを開き、Chat view下部の「CURRENT-MODEL」から対象モデルを探します。github.comではCopilot Chat下部の同じモデル選択欄を確認します。VS Codeでモデルを変更する公式手順は、Chatのモデル変更がinline suggestionsのモデルには影響しないと明記しています。したがって、Chatに表示されたことを、コード補完を含む全機能の確認済み扱いにはしません。

また、github.comでCopilot Chatを使う公式手順では、Copilot Businessの利用者がモデルを切り替えるにはOrganization側の許可が必要とされています。Enterpriseでモデルを有効にしたあとも、プラン、利用クライアント、Organizationの制約を含めて確認します。利用者側で複数モデルを振り分ける考え方は、CopilotのHydraFusion解説に整理しています。

APIで現在値を取得してから変更する

以下は2026年10月22日に取得したGitHub RESTリファレンスの形です。APIのサンプルは公式ページに掲載された値だけを使っています。実際の変更では、まずGETのレスポンスから対象のmodel_nameと編集可否を取得してください。

共通ヘッダーと必要な権限

公式cURL例は、Accept: application/vnd.github+json、Bearer token、X-GitHub-Api-Version: 2026-03-10を送ります。GHE.comを利用している場合は、api.github.comではなくEnterprise専用のAPIサブドメインを使います。

対象	GET	PATCH	fine-grained token
Enterprise／team／apps	Enterprise ownerまたはread_enterprise_ai_controls。OAuth app tokenとclassic PATはread:enterprise	Enterprise ownerまたはwrite_enterprise_ai_controls。OAuth app tokenとclassic PATはadmin:enterprise	GitHub App user access tokenまたはinstallation access token。Enterprise AI controlsのread／write
Organization	Organization owner。OAuth app tokenとclassic PATはadmin:orgまたはrepo		GitHub App user access token、installation access token、fine-grained PAT。GET／PATCHともOrganizationのAdministration権限はwrite

OrganizationではSAML authorizationとOAuth app access restrictionsも適用されます。GETだからfine-grained permissionをreadにできる、と自己判断しないでください。Organization向けRESTリファレンスはGETにもAdministrationのwriteを指定しています。

EnterpriseのGET

Enterprise全体の現在値を取得する公式例です。トークンは環境変数やシークレット管理機能から渡し、コマンド履歴へ実値を残さないでください。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/enterprises/ENTERPRISE/copilot/model-policies

EnterpriseのGETレスポンスは、既定の状態とモデルごとの状態を返します。次は公式リファレンスの例です。

{
  "default_availability": {
    "policy_state": "enabled"
  },
  "models": [
    {
      "model_name": "gpt-5.6-sol",
      "display_name": "OpenAI GPT-5.6 Sol",
      "policy_state": "enabled"
    }
  ]
}

EnterpriseのPATCH

変更例もRESTリファレンスに合わせています。ここに出てくるgpt-5.6-solは公式サンプルのモデル識別子であり、廃止モデルの代替を一律に指定する例ではありません。実運用では、直前のGETが返した識別子を使います。

# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
curl -L -X PATCH \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  https://api.github.com/enterprises/ENTERPRISE/copilot/model-policies \
  -d '{"default_availability":{"policy_state":"enabled"},"models":[{"model_name":"gpt-5.6-sol","policy_state":"enabled"}]}'

階層によって指定できる状態が違う

階層	主なリクエスト形	変更時の状態
Enterprise	default_availabilityとmodels[]	既定はenabled、disabled、条件を満たす場合のdelegate_to_organizations。モデルはこれらにdelegate_to_teams_and_appsを加える
Enterprise team／apps	models[]	enabledまたは、保存済みの下位ポリシーを外すoptionalを中心に使う。更新できるのはeditable: trueのモデルだけ
Organization	default_availabilityとmodels[]	enabledまたはdisabled。Enterpriseから継承したモデルはロックされる

teamとappsのRESTスキーマはdisabledも許容値として列挙していますが、管理画面の説明ではteamの明示的なDisabledはなく、委任されたモデルはOptionalまたはEnabledです。この記事の操作例は、説明本文と公式cURL例で確認できるenabled、保存済みポリシーを外すoptionalに限定します。

Enterprise系のGETは200、401、403、404、503、PATCHはこれらに422が加わります。OrganizationのページではGETに200、401、403、404、PATCHに200、401、403、404、422が列挙されています。エラー本文の形式やリトライ条件は今回のページに具体例がないため、独自仕様を足しません。

Organization modeとEnterprise teams modeを混ぜない

Enterpriseのモデルポリシーは、全体の基準を設定したうえで、追加判断をOrganizationへ任せるか、Enterprise teamsとagent appsへ任せるかを選びます。どちらの管理単位を使うかで、呼び出すAPIが変わります。

Organization mode

• 既定の管理方式です。
• Enterpriseでモデルをdelegate_to_organizationsにすると、Organization ownerがEnabled／Disabledを選べます。
• Organizationで明示設定されていない対象モデルは、OrganizationのDefault availabilityに従います。
• OrganizationのPATCHはアトミックです。変更できないモデルを同じリクエストに含めると、適用可能な変更も保存されません。

Enterprise teams mode

• 2026年10月22日時点ではオプトインのプレビューです。
• 切り替えるとOrganizationレベルのモデル設定は無効化され、Organization APIの利用条件から外れます。
• EnterpriseでDisabledのモデルはteamでEnabledにできません。EnterpriseでEnabledのモデルはteamでも有効です。
• teamはEnterpriseの基準に追加する形でモデルを有効化します。複数teamに所属するユーザーは、Enterpriseと所属teamで許可されたモデルの和集合を利用します。

移行前にOrganizationへ委任していたモデルは、teams modeへ切り替えただけではteamへ自動付与されません。公式ガイドは、必要なモデルを対象teamでEnabledにするまで利用できないと説明しています。切り替え前後はGETのスナップショットを保存し、対象teamの設定を照合してください。

Agent appsは人やteamとは別のポリシーとして扱う

agent appsは、GitHub上でエージェントを提供するGitHub Appsです。Organization modeの既定では、インストール先のOrganizationまたはpersonal accountで有効なモデルにアクセスします。Enterprise teams modeでは、agent appsが利用できるモデルをEnterprise側で管理します。

運用手順は、Enterpriseのモデルをdelegate_to_teams_and_appsにし、apps用GETでeditableを確認し、必要なモデルをPATCHでenabledにする流れです。画面では「AI controls」「Copilot」「Configure app models」と進み、モデルをOptionalからEnabledへ変更します。

個別のagent appごとに割り当てるAPIではありません。/enterprises/{enterprise}/copilot/apps/model-policiesにはapp IDやapp slugがなく、公式資料もagent apps向けのモデル群として説明しています。App AにはモデルX、App BにはモデルYという個別割り当てができるとは、2026年10月22日時点の一次情報から確認できません。

また、apps用GETが返すpolicy_state、enterprise_policy_state、editableは、個々のユーザーの最終的なアクセス可否を保証するものではありません。上位ポリシー、インストール先、プラン、対応クライアントを含め、実際の利用面で確認します。

API運用で起きやすい4つの行き違い

発表記事のteam_slugをそのまま実装する

❌ 発表ページだけを見て{team_slug}を組み込む。
⭕ 2026年10月22日時点のRESTリファレンスに合わせ、整数の{team_id}を使い、実装時にも最新ページを再確認します。

GETせずにmodel_nameを推測する

❌ 表示名からAPI識別子を作り、いきなりPATCHする。
⭕ 対象階層でGETし、返されたmodel_name、policy_state、editableをもとに変更対象を決めます。

下位階層なら上位のDisabledを解除できると考える

❌ EnterpriseでDisabledのモデルをteamやOrganizationからEnabledにする。
⭕ Enterpriseの基準と委任状態を先に確認し、ロックされたモデルは上位階層の管理者が判断します。

PATCHの200だけで利用可能と判定する

❌ APIが200を返した時点で、全利用者・全クライアントに反映済みと報告する。
⭕ 再GETで設定を確認し、VS Codeとgithub.comのモデル選択欄を対象ユーザーの条件で確かめます。Chatの確認とinline suggestionsの確認も分けます。

あわせて確認したいAIgent Labの既刊

• HydraFusionとは｜Copilotの複数モデル振り分け【2026年9月】：複数モデルを使い分ける利用側の考え方を確認できます。
• GitHub Copilot、Agent SkillsとMCPがGA化：agent appsやエージェント機能を管理する背景の理解に役立ちます。
• AIエージェント ガバナンス・権限設計2026：モデルを許可する前に、誰が変更できるかを整理する際の補助になります。

2026年10月22日時点で、まだ分からないこと

• team pathの表記差：発表記事の{team_slug}と、現行RESTリファレンスの{team_id}が一致していません。本稿の実装例はRESTリファレンスを優先しています。
• Grok 4.5の文書更新：10月19日の告知は廃止対象としていますが、10月22日に取得した対応モデル一覧にはGrok 4.5がGAとして残り、退役履歴にも載っていません。
• クライアント別の表示：廃止告知は有効化後にVS Codeとgithub.comで確認するよう案内していますが、対応モデル一覧のクライアント別表には代替モデルの掲載差があります。両方に必ず表示されるとは断定できません。
• 反映時間：PATCHまたは画面変更からモデル選択欄へ反映されるまでの時間やSLAは、今回確認した一次情報に書かれていません。
• 個別app単位の割り当て：apps用APIはagent apps全体を対象にしており、個別appを指定する方法は確認できません。
• 監査イベント名：Copilotの設定・ポリシー変更が監査ログの対象であることは確認できましたが、このAPI専用のevent名は確認できません。
• 料金の倍率：モデルポリシーAPIと10月19日の廃止告知には、代替モデルごとのpremium requests倍率がありません。2026年10月22日時点で、今回確認した一次情報から数値を確認できていないため、本稿には掲載していません。

よくある質問

CopilotのモデルポリシーAPIで何ができますか？

Enterprise、Enterprise team、agent apps、Organizationの4階層で、GETによる現在値の取得とPATCHによる変更ができます。Enterpriseでは全体の基準と委任、下位階層では委任された範囲の設定を扱います。

Copilot Businessでもモデル管理を使えますか？

はい。Enterpriseのモデル管理ガイドはCopilot BusinessとCopilot Enterpriseを対象にしています。ただし、利用できる階層は契約とアカウント構成に依存します。Enterprise teamやagent appsのエンドポイントはEnterprise配下の管理を前提としています。

なぜPATCHの前にGETが必要ですか？

モデルの公開識別子、現在の継承状態、下位階層で編集できるかを確認するためです。特にteamとappsでは、editable: falseのモデルは更新できません。OrganizationでもEnterpriseから継承したモデルはロックされます。

代替モデルを有効にすれば、すぐ全員に表示されますか？

API資料は反映時間を明記しておらず、利用可能なモデルはプラン、クライアント、上位ポリシー、Organizationの設定に左右されます。再GETに加え、VS Codeとgithub.comのCopilot Chatで実際に確認してください。

agent appごとに別のモデルを設定できますか？

2026年10月22日時点で確認できたAPIはagent apps全体向けで、個別appの識別子を受け取りません。人やteam向けとagent apps向けを分けることはできますが、個々のappへの別々の割り当ては公式資料から確認できません。

モデル変更の記録はどこに残せばよいですか？

GitHubの監査ログでCopilotの設定・ポリシー変更を確認しつつ、自社の変更申請にAPIの実行者、対象階層、変更理由、リクエスト、再GETの結果を残す方法が実務的です。専用の監査イベント名は公開ページで確認できていないため、APIだけに記録を依存しない方が安全です。

premium requestsの倍率はどこで分かりますか？

今回のAPI発表、RESTリファレンス、モデル廃止告知には倍率が記載されていません。2026年10月22日時点で今回確認した一次情報からは確認できていないため、モデル選定時はGitHubの最新料金ページを別途確認してください。

ここまでの要点

• 最初にEnterpriseのGETで基準と委任先を確認し、Organization modeとEnterprise teams modeを混ぜません。
• モデル名はGET結果から取得し、編集可能な範囲だけをPATCHします。teamの実装用パスは、現行REST docsの{team_id}を使います。
• 10月19日の廃止後は代替モデルを有効化し、再GET、VS Code、github.comの順で確認します。agent appsは個別appではなくapps全体のポリシーとして分けます。

運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）

参考・出典

• Copilot model policy API for enterprise, orgs, and teams — GitHub Changelog、2026年10月19日（参照日: 2026年10月22日）
• REST API endpoints for enterprise AI controls — GitHub Docs（参照日: 2026年10月22日）
• REST API endpoints for Copilot model policy management — GitHub Docs（参照日: 2026年10月22日）
• Managing availability of models in your enterprise — GitHub Docs（参照日: 2026年10月22日）
• GitHub Copilot models deprecated on October 19, 2026 — GitHub Changelog、2026年10月19日（参照日: 2026年10月22日）
• Supported AI models in GitHub Copilot — GitHub Docs（参照日: 2026年10月22日）
• Changing the AI model for GitHub Copilot Chat — GitHub Docs（参照日: 2026年10月22日）
• Asking GitHub Copilot questions in GitHub — GitHub Docs（参照日: 2026年10月22日）
• Reviewing audit logs for GitHub Copilot — GitHub Docs（参照日: 2026年10月22日）

このテーマの関連記事

• ▸ Copilot Fusionとは｜正式版の料金・使い方・設定【2026年10月】
• ▸ 【速報】ChatGPT API無料クレジット月最大500ドル
• ▸ ConoHa AI Canvasの料金・使い方｜申し込める？【2026年10月】
• ▸ GPT-6.1 Terra API｜移行手順・画面操作・料金【2026年10月】
• ▸ LiteLLM 1.107.0改ざん｜確かめ方と取り替える鍵【2026年10月】