GitHub Enterprise Server 3.22のrelease candidateでは、Copilot CLIをdisconnectedまたはair-gapped環境で使うための構成がtechnical previewとして案内されました。2026年8月11日時点の公式情報では、管理者がGHES側でモデルプロバイダを1回設定し、利用者はGHES資格情報でCopilot CLIへ接続できます。いっぽうでRCは本番導入向けではなく、GitHub自身もGA後の検証を推奨しています。先に結論を言うと、今すぐ本番切替する話ではなく、社内閉域網でCopilot CLIを使いたい企業が検証計画を前倒しできる更新です。
何が発表されたのか
GitHub Changelogによると、GHES 3.22 RCではCopilot CLIをGitHub Cloudへ接続しない環境でも動かせるようにする新機能が追加されました。ポイントは、モデル接続先を各開発者が個別設定するのではなく、GHES管理者がinstance側に一度だけ設定することです。これにより、閉域環境の開発者はGHESの認証情報を使いながら、CLI上でコード生成、デバッグ、シェル操作、GitHub操作をまとめて扱える構成を試せます。
最初に押さえるべき制約
ここは見落とし厳禁です。公式release notesでは、3.22.0-rc.1はlatest releaseではなく、RCはtest environment専用、production environmentへ入れるべきではないと明記されています。さらに、サポート中の旧版からRCへupgradeしないこと、RCからGAへupgradeできないこと、hotpatchも不可とされています。つまり今回の発表は「閉域網でのCopilot CLI本番展開が解禁された」ではなく、「GAに備えて検証観点を早めに固められる」アップデートだと理解するのが正確です。
管理者が設定する項目
管理者はGHESへSSHできること、対応するLLM providerのAPI keyを持つこと、client側にCopilot CLIとgh CLIが入っていることを前提に準備します。設定の中心はghe-configで、最低でもapp.copilot-proxy.enabled、endpoint-url、endpoint-key、provider-model-id、provider-typeを定義し、必要に応じてprovider-wire-api、provider-wire-model、upstream-timeout、enable-upstream-probeを追加します。provider-typeはopenai、azure、anthropicが案内されており、OpenAI互換endpointもopenaiとして扱える点は設計の自由度があります。
閉域網でのAI開発基盤をどう設計するか迷う場合は、 要件整理から相談する のが安全です。認証、監査、モデル接続先、運用責任の切り分けを先に決めるとPoCのやり直しを減らせます。
利用者が設定する項目
利用者側は、COPILOT_PROVIDER_GHES_HOST、COPILOT_PROVIDER_GHES_TOKEN、COPILOT_OFFLINE=true の3つが必須です。GitHub Docsでは、まず gh auth login --hostname でGHESへ認証し、その後 COPILOT_PROVIDER_GHES_TOKEN="$(gh auth token --hostname YOUR-GHES-HOSTNAME)" のように動的取得する方法を推奨しています。複数hostを扱う場合やautomationでは、GH_HOSTとGH_ENTERPRISE_TOKENまたはGITHUB_ENTERPRISE_TOKENを明示して、GitHub操作の向き先をGHESへ固定する案内もあります。
何が使えて何が使えないか
Docsのcapability表では、AI-assisted coding、shell commands、file operations、gh CLI経由のissuesやPR操作は利用対象に含まれます。一方で、GitHub cloud servicesへの接続に依存する機能は使えません。具体例として、GitHub-hosted modelsのmodel selection、telemetry and usage reporting、auto-update、web searchやweb fetch、GitHub MCP server toolsはGHES offline構成では非対応です。つまり、閉域運用で便利になるのは「手元と社内GitHubで完結する作業」であり、クラウド前提の補助機能まで同じ体験になるわけではありません。
導入前チェックリスト
検証の優先順位は4つです。1つ目は、RCを本番へ入れない前提で隔離されたtest environmentを確保すること。2つ目は、利用予定モデルがopenai互換か、azureか、anthropicかを先に決め、endpointとwire APIの整合を確認すること。3つ目は、開発者が使うPAT、GH_HOST、CLI認証方式を標準化し、監査や失効手順を文書化すること。4つ目は、web検索やusage reportingがない前提で、どの作業をCopilot CLIへ任せ、どこから先を既存運用へ戻すかを決めることです。閉域網企業では、技術要件より運用境界の定義が先に来ます。
FAQ
Q. 今すぐ本番導入してよいですか。 A. 2026年8月11日時点では非推奨です。RCはtest environment向けで、GitHubはGHES 3.22がGAに到達してからこの機能をvalidateして使うことを推奨しています。 Q. 既存のGitHub Cloud版Copilotと同じ機能が出ますか。 A. 同じではありません。閉域構成ではGitHub cloud services依存機能が落ちるため、用途は社内repoの調査、コード生成、デバッグ、CLI操作に絞って設計するのが現実的です。
今回の発表は派手な新機能というより、閉域網や規制産業で「Copilot CLIを使える余地があるか」を判断しやすくする土台づくりです。特に、管理者がghe-configでproviderを集中設定し、利用者はGHES認証で接続できる流れは、運用責任の所在を明確にしやすい構成です。GA前の今は、PoC範囲を限定し、どの開発フローならオフライン構成でも十分な価値が出るかを見極める段階と考えるのがよいでしょう。
