GitHub Enterprise Server（GHES）3.22では、管理者がGHES上にモデルプロバイダーを一度設定することで、GitHub Cloudへ接続できない閉域・エアギャップ環境でもCopilot CLIを利用できる仕組みが追加されました。利用者はモデルプロバイダーのAPIキーを個別に持つ必要がなく、GHESの資格情報を使って接続できます。(The GitHub Blog)
ただし、2026年8月30日時点で公開されているのは「GitHub Enterprise Server 3.22.0-rc.1」です。閉域向けCopilot CLIはTechnical Previewであり、仕様が変更される可能性があります。さらにRC版は本番環境への導入が推奨されず、RC環境からGA版へ直接アップグレードすることもできません。現段階では、既存の本番GHESを更新するのではなく、新しい検証環境を用意して評価するのが適切です。(GitHub)
GHES 3.22の閉域Copilot CLIで何が変わるのか
従来、Copilot CLIでGitHubが提供するモデルを利用するには、GitHub Cloudへの接続が必要でした。また、独自のLLMを利用するBYOK構成では、利用者の端末ごとにモデルプロバイダーのURLやAPIキーを設定する方法が基本でした。
GHES 3.22では、モデルプロバイダーの接続情報をGHES側に集約できます。構成は次のようになります。
開発者PC
├─ Copilot CLI
└─ GitHub CLI（gh）
│
│ GHESの資格情報で認証
▼
GitHub Enterprise Server 3.22
└─ Copilot Proxy
│
│ 管理者が登録したAPIキーで接続
▼
組織が指定したLLMプロバイダー
├─ OpenAI互換API
├─ Azure OpenAI
└─ Anthropic管理者は、管理用SSHからghe-configを使用してモデルプロバイダーを設定します。利用者側で必要なのは、GHESのホスト名、GHES用トークン、オフラインモードの有効化です。モデルプロバイダーのAPIキーを開発者全員に配布しなくてよいため、秘密情報を中央管理しやすくなります。(GitHub Docs)
通常のBYOK構成との違い
| 比較項目 | 端末ごとのBYOK | GHES 3.22の閉域構成 |
|---|---|---|
| モデル接続先の設定 | 利用者の端末ごと | GHES管理者が一括設定 |
| APIキーの保持場所 | 原則として各端末 | GHES側 |
| Copilot CLIの認証 | モデルプロバイダーの設定に依存 | GHESの資格情報 |
| モデルの統一 | 利用者ごとに異なる可能性 | 組織側で統一しやすい |
| GitHubリポジトリ操作 | 接続先に応じた設定が必要 | 認証済みのgh CLIを利用 |
| 向いている環境 | 個人利用、少人数の検証 | 組織的な閉域・分離環境 |
GHES 3.22の方式は、単に「Copilot CLIをオフラインで動かす機能」ではありません。モデルの接続先と認証情報をGHES側で統制するための企業向け構成と考えると分かりやすいでしょう。
「GitHub Cloud非接続」と「完全なエアギャップ」は異なる
COPILOT_OFFLINE=trueを設定すると、Copilot CLIはGitHub Cloudへの接続を前提としないオフラインモードで動作します。しかし、これだけで全通信が閉域内に収まるわけではありません。
GHESに登録したモデルプロバイダーが外部のOpenAI、Azure OpenAI、Anthropicなどであれば、プロンプトやコードのコンテキストは、その外部サービスへ送信されます。完全なエアギャップを実現するには、OllamaやvLLMなどを含む対応モデルを閉域内に配置し、GHESからその内部エンドポイントだけへ接続する必要があります。GitHubの公式ドキュメントも、オフラインモードで完全なネットワーク分離を保証するには、モデルプロバイダー自体もローカルまたは同じ分離環境内に置く必要があると説明しています。(GitHub Docs)
| 構成 | GitHub Cloud接続 | 外部LLMへの通信 | 完全な閉域 |
|---|---|---|---|
| GHES＋外部OpenAI API | なし | あり | いいえ |
| GHES＋Azure OpenAI | なし | あり | いいえ |
| GHES＋社内vLLM | なし | なし | 可能 |
| GHES＋社内Ollama | なし | なし | 可能 |
COPILOT_OFFLINE=trueのみ | 抑制 | 接続先による | 保証されない |
閉域環境の要件定義では、「GitHub.comに接続しない」だけでなく、次の通信経路を個別に確認する必要があります。
- 開発者端末からGHESへの通信
- GHESからモデルプロバイダーへの通信
- Copilot CLIやGitHub CLIのインストール、更新に必要な通信
- モデルプロバイダーが行うログ送信や監視通信
- 社内MCPサーバーや外部ツールへの通信
導入前に確認すべき要件
GHES 3.22の閉域Copilot CLIを検証するには、GHESだけでなく、モデル、クライアント、認証、ソフトウェア配布まで含めた準備が必要です。
| 分類 | 必要なもの | 確認ポイント |
|---|---|---|
| GHES | GitHub Enterprise Server 3.22 | 現時点ではRC版のため検証環境限定 |
| 管理権限 | GHESへの管理用SSHアクセス | ghe-configとghe-config-applyを実行できること |
| モデル基盤 | 対応するLLMプロバイダー | GHESからエンドポイントへ到達できること |
| APIキー | モデルプロバイダーのAPIキー | GHES側で秘密情報として設定 |
| モデル機能 | Tool Callingとストリーミング | どちらかに未対応だとCopilot CLIがエラーになる |
| クライアント | Copilot CLI | 各開発者PCへ配布 |
| GitHub操作 | GitHub CLI（gh） | Issue、PR、リポジトリ操作に使用 |
| 認証 | GHESのPersonal Access Token | Copilot CLIからGHESへの認証に必要 |
| 環境変数 | GHESホスト、トークン、オフラインモード | Copilot CLI起動前に設定 |
| 更新方法 | 社内配布、ミラー、手動更新 | 閉域では自動更新を前提にしない |
GHES固有のセットアップ要件として、GitHubは管理用SSHアクセス、対応LLMプロバイダーのAPIキー、Copilot CLI、GitHub CLIを挙げています。(GitHub Docs)
モデルはTool Callingとストリーミングに対応している必要がある
Copilot CLIで使用するモデルには、次の2機能が必要です。
- Tool CallingまたはFunction Calling
- ストリーミング応答
モデルがどちらかに対応していない場合、Copilot CLIはエラーを返します。また、GitHubは良好な結果を得るため、少なくとも128Kトークン程度のコンテキストウィンドウを持つモデルを推奨しています。(GitHub Docs)
「OpenAI互換APIに接続できた」というだけでは、導入可否を判断できません。ローカルLLMを評価するときは、次の処理まで確認してください。
- JSONスキーマに沿ったTool Callingを安定して返せるか
- 複数回のツール実行を継続できるか
- 長いコードやログを入力しても指示を維持できるか
- ストリーミング中に接続が切れないか
- 無効なシェルコマンドを繰り返し生成しないか
- 日本語の指示とコードを混在させても精度を維持できるか
特に小規模なローカルモデルは、通常のチャットには使えても、ツール実行を伴うエージェント処理では失敗することがあります。モデル名だけで判断せず、実際の開発タスクで検証することが重要です。
対応するモデルプロバイダー
GHES 3.22の設定で指定できるプロバイダー種別は、openai、azure、anthropicの3種類です。
provider-type | 対応する主なサービス |
|---|---|
openai | OpenAI、Ollama、vLLM、Foundry Local、OpenAI Chat Completions API互換エンドポイント |
azure | Azure OpenAI Service |
anthropic | AnthropicのClaudeモデル |
openaiはOpenAIの公式APIだけを意味しません。OllamaやvLLMなど、OpenAI Chat Completions APIとの互換性を持つエンドポイントも対象です。(GitHub Docs)
ただし、互換APIを提供していても、Tool Callingやストリーミングの実装がCopilot CLIの要求と一致するとは限りません。接続確認だけでなく、ファイル操作やシェル実行を含む一連の処理までテストしてください。
管理者がGHESにモデルプロバイダーを設定する
管理者はGHESへSSH接続し、ghe-configでCopilot Proxyを設定します。
主な設定項目
| 設定値 | 必須 | 内容 |
| —————————————– | -: | —————————- |
| app.copilot-proxy.enabled | 必須 | 機能の有効・無効 |
| app.copilot-proxy.endpoint-url | 必須 | モデルプロバイダーのベースURL |
| secrets.copilot-proxy.endpoint-key | 必須 | モデルプロバイダーのAPIキー |
| app.copilot-proxy.provider-model-id | 必須 | Copilot CLI内部で使用するモデルID |
| app.copilot-proxy.provider-type | 必須 | openai、azure、anthropic |
| app.copilot-proxy.upstream-timeout | 任意 | 上流APIの送受信タイムアウト秒数 |
| app.copilot-proxy.provider-wire-api | 任意 | completionsまたはresponses |
| app.copilot-proxy.provider-wire-model | 任意 | 上流へ送信するモデル識別子の上書き |
| app.copilot-proxy.enable-upstream-probe | 任意 | 起動時の上流接続確認を有効化するか |
設定後はghe-config-applyを実行して変更を反映します。(GitHub Docs)
閉域内のOpenAI互換エンドポイントを設定する例
次の例では、社内に配置したOpenAI互換APIを使用します。
ghe-config app.copilot-proxy.enabled true
ghe-config app.copilot-proxy.endpoint-url 'https://llm.example.local/v1'
ghe-config secrets.copilot-proxy.endpoint-key 'YOUR-API-KEY'
ghe-config app.copilot-proxy.provider-model-id 'YOUR-MODEL-ID'
ghe-config app.copilot-proxy.provider-wire-model 'YOUR-MODEL-ID'
ghe-config app.copilot-proxy.provider-type openai
ghe-config app.copilot-proxy.upstream-timeout 300
ghe-config-applyYOUR-API-KEYとYOUR-MODEL-IDは、実際のプロバイダー設定に置き換えます。
APIキーを作業記録、チャット、チケット、手順書へ直接記載しないようにしてください。検証用と本番用のキーを分け、漏えい時に個別失効できる状態にしておく必要があります。
provider-model-idとprovider-wire-modelの違い
通常は両方に同じモデル名を指定できます。ただし、Copilot CLI内部で扱うモデルIDと、上流APIが要求するモデル名が異なる場合は、provider-wire-modelで上流へ送る値を上書きできます。
例えば、Copilot CLI側では分かりやすい管理名を使用し、モデルサーバー側ではデプロイメント固有の識別子を要求する場合に利用します。
ghe-config app.copilot-proxy.provider-model-id 'internal-coding-model'
ghe-config app.copilot-proxy.provider-wire-model 'deployment-2026-08'起動時プローブを無効にする場合の注意
app.copilot-proxy.enable-upstream-probeは、起動時にモデルプロバイダーへの接続確認を行う設定です。既定では有効です。
ネットワークやモデルサーバーの都合で起動時プローブが失敗する場合は、次のように無効化できます。
ghe-config app.copilot-proxy.enable-upstream-probe false
ghe-config-applyただし、プローブを無効にすると、設定ミスやモデルサーバー停止を起動時に検出できなくなります。単にエラーを消す目的で無効にせず、GHESからモデルAPIへ実際に接続できることを別の方法で確認してください。
利用者側でCopilot CLIを接続する
管理者によるGHES設定が完了したら、利用者はGitHub CLIでGHESへログインし、Copilot CLI用の環境変数を設定します。
Linux・macOSの設定例
gh auth login --hostname ghes.example.local
export COPILOT_PROVIDER_GHES_HOST=ghes.example.local
export COPILOT_PROVIDER_GHES_TOKEN="$(
gh auth token --hostname ghes.example.local
)"
export COPILOT_OFFLINE=true
copilot必要な環境変数は次の3つです。
| 環境変数 | 内容 |
|---|---|
COPILOT_PROVIDER_GHES_HOST | GHESインスタンスのホスト名 |
COPILOT_PROVIDER_GHES_TOKEN | GHESに対するPersonal Access Token |
COPILOT_OFFLINE | trueを指定してオフラインモードを有効化 |
GHESプロバイダーは、COPILOT_OFFLINEが有効な場合にのみ動作します。GitHubは、~/.config/gh/hosts.ymlからトークンを直接コピーするのではなく、gh auth tokenで動的に取得する方法を推奨しています。(GitHub Docs)
Windows PowerShellの設定例
$ghesHost = "ghes.example.local"
gh auth login --hostname $ghesHost
$env:COPILOT_PROVIDER_GHES_HOST = $ghesHost
$env:COPILOT_PROVIDER_GHES_TOKEN = (
gh auth token --hostname $ghesHost
)
$env:COPILOT_OFFLINE = "true"
copilot環境変数へトークンを直接固定保存するより、Copilot CLIの起動時にgh auth tokenから取得するスクリプトを配布する方が安全です。
複数のGitHubアカウントを使っている場合
GitHub.comとGHESなど、複数のホストへ認証している端末では、GitHub CLIが意図しないホストを参照しないようにします。
export GH_HOST=ghes.example.local
export GH_ENTERPRISE_TOKEN="$(
gh auth token --hostname ghes.example.local
)"自動化処理では、GH_ENTERPRISE_TOKENまたはGITHUB_ENTERPRISE_TOKENと、GH_HOSTを使用します。同じホストについて保存済み認証と環境変数の両方が存在する場合は、環境変数が優先されます。(GitHub Docs)
Copilot CLIのインストール方法
Copilot CLIは、WinGet、Homebrew、npm、インストールスクリプト、実行ファイルの直接配布に対応しています。npmを使用する場合はNode.js 22以降が必要です。(GitHub Docs)
| 環境 | 主なインストール方法 |
|---|---|
| Windows | WinGet、npm、実行ファイル配布 |
| macOS | Homebrew、npm、インストールスクリプト |
| Linux | Homebrew、npm、インストールスクリプト、実行ファイル配布 |
| 完全閉域 | 社内パッケージリポジトリ、端末管理製品、承認済み媒体による配布 |
完全閉域では、端末からWinGet、npm、Homebrewへ直接接続できないことがあります。その場合は、外部接続可能な環境で入手した実行ファイルについてハッシュや署名を確認し、組織のソフトウェア配布基盤へ登録してください。
Copilot CLIだけでなく、GitHub CLIの配布と更新方法も必要です。初回導入だけを考えるのではなく、脆弱性修正版やTechnical Previewの更新版を継続的に取り込める運用を準備します。
GHESの閉域構成で使える機能と制限
GHES 3.22のオフライン構成でも、Copilot CLIの基本的なAI支援機能は利用できます。一方、GitHub Cloudへの接続を前提とする機能は利用できません。(GitHub Docs)
| 機能 | GHESオフライン構成 | 注意点 |
|---|---|---|
| プロンプトへの回答 | 利用可能 | 応答品質は設定モデルに依存 |
| コード生成・デバッグ | 利用可能 | モデルのTool Calling対応が必要 |
| シェルコマンド | 利用可能 | 実行権限と承認ルールが必要 |
| ローカルファイル操作 | 利用可能 | 信頼するディレクトリを限定する |
| Issue、PR、リポジトリ操作 | 利用可能 | GHESへ認証済みのgh CLIが必要 |
| GitHub MCPサーバーツール | 利用不可 | GHES操作はgh CLI経由を基本とする |
| Web検索・Web取得 | 利用不可 | インターネット情報の取得はできない |
| GitHubホスト型モデルの選択 | 利用不可 | 管理者が設定したモデルを使用 |
| GitHub側のテレメトリ・利用状況レポート | 利用不可 | モデル基盤側の監視を検討 |
| 自動更新 | 利用不可 | 社内配布や手動更新を設計 |
ここでいう「GitHub MCPサーバーツール」は、GitHub Cloudが提供するGitHub MCP機能を指します。組織が独自に構築したローカルMCPサーバーまで一律に利用できないという意味ではありません。カスタムMCPを組み合わせる場合は、Technical Previewの範囲とは分けて、通信先、認証、許可ツールを個別に検証してください。
閉域化してもシェル実行のリスクは残る
ネットワークを閉じても、Copilot CLIが実行するコマンド自体のリスクはなくなりません。
Copilot CLIは、信頼した作業ディレクトリ内のファイルを読み取り、変更し、コマンドを実行する場合があります。GitHubも、セッションを開始する際は、そのディレクトリ内のファイルを信頼できる場合にのみ処理を許可するよう案内しています。(GitHub)
実運用では、次の対策が必要です。
- Copilot CLIを管理者権限で常用しない
- 本番サーバーへ直接ログインした状態で使用しない
- 信頼するディレクトリをリポジトリ単位に限定する
- 削除、デプロイ、権限変更は人間が確認する
- 本番用の秘密鍵や資格情報を作業ディレクトリへ置かない
- GitHub用トークンを必要最小限の権限にする
- 生成コードをテスト、レビュー、静的解析に通す
- シェルコマンドの実行履歴を監査できるようにする
「外部へ情報が出ないこと」と「AIエージェントが安全に操作すること」は別の問題です。閉域導入では、ネットワーク境界だけでなく、端末上の実行権限も設計してください。
RC版を本番環境に導入してはいけない理由
GHES 3.22 RCは、完成版を早期評価してフィードバックするためのリリースです。GitHubは、性能、安定性、セキュリティの観点から、RC版を本番環境へ導入しないよう明記しています。(GitHub Docs)
特に注意すべき点は、通常のアップグレード検証とは扱いが異なることです。
- サポート中の既存GHESからRCへ更新しない
- 新規のテスト環境としてRCを構築する
- RC環境からGA版へアップグレードできない
- RC環境へホットパッチを適用できない
- 検証終了後はRC環境を破棄する
- GA版では改めて環境を構築または正式な手順で更新する
GHES 3.22のリリースノートでも、GitHubはGA到達後まで、この機能の本格的な検証や利用を待つことを推奨しています。(GitHub Docs)
したがって、Copilot CLIを試すためだけに、本番のGHESをRCへ更新する方法は避けてください。
Technical Previewで特に確認すべき制限
モデル選択の自由度
公開されているGHES設定では、provider-model-idとモデルプロバイダーをインスタンス側で指定します。また、GHESオフライン構成ではGitHubホスト型モデルの選択を利用できません。
少なくとも現時点では、利用者がGitHub Cloudと同じ感覚で複数モデルを切り替えられると想定しない方が安全です。速度重視と精度重視のモデルを使い分けたい場合は、GA版の仕様や正式ドキュメントを確認する必要があります。
利用状況の可視化
GitHub Cloud側のテレメトリや利用状況レポートを利用できないため、次の情報はモデル基盤側で収集する設計が必要です。
- リクエスト数
- 入力・出力トークン数
- 応答時間
- エラー率
- 同時実行数
- 利用者または部門別の使用量
- モデルサーバーのCPU、GPU、メモリ使用率
ただし、プロンプト本文やコードをそのままログへ保存すると、閉域化の目的に反して機密情報が別のログ基盤へ複製されることがあります。本文を保存するのか、メタデータだけにするのかを事前に決めてください。
モデル基盤の性能
GitHubがモデルをホストする構成とは異なり、独自モデルを使用する場合は、モデルサーバーの性能がCopilot CLIの操作感に直結します。
例えば10人が同時に利用するだけでも、長いコードコンテキストと複数回のTool Callingが重なると、単純なチャットより大きな負荷がかかります。1人で応答できたことだけをもって本番利用可能と判断せず、想定利用者数で負荷試験を行ってください。
API互換性
OpenAI互換エンドポイントでは、次の違いが問題になりやすくなります。
- Tool Callingの引数形式
- ストリーミングイベントの形式
- モデル名とデプロイメント名の違い
/v1などのURLプレフィックスcompletionsとresponsesの違い- タイムアウト時間
- 上流プローブへの応答
接続エラーが発生した場合は、「GHESへ接続できない」「GHESからモデルへ接続できない」「モデルは応答するがツール呼び出しに失敗する」を分けて調査します。
実務で使える検証手順
検証用GHESを新規構築する
既存の本番環境を更新せず、GHES 3.22 RC専用のテスト環境を構築します。実データを大量にコピーする必要はありません。権限、リポジトリ操作、PR作成を確認できる最小構成で十分です。
モデルプロバイダーへの通信を確認する
GHESからモデルAPIへの名前解決、証明書、ポート、ルーティングを確認します。
内部CAを使用している場合は、証明書検証を無効化するのではなく、GHESと必要なクライアントへ正しい証明書チェーンを配布してください。
管理者設定を適用する
ghe-configでモデルプロバイダーを登録し、ghe-config-applyを実行します。設定値は作業前後で記録しますが、APIキーそのものは記録へ残さないようにします。
少人数の端末で接続する
最初は管理者と開発者を合わせて2～3人程度に限定します。端末のOS、シェル、プロキシ設定が異なる場合は、それぞれ1台ずつ含めます。
機能を段階的に試す
次の順番で検証すると、障害箇所を切り分けやすくなります。
| 段階 | テスト内容 | 確認するもの |
|---|---|---|
| 接続 | 短い質問へ回答させる | GHES認証、モデル応答 |
| 読み取り | READMEやコードを説明させる | ファイル参照、コンテキスト長 |
| 生成 | テストコードを作成させる | コード品質、ストリーミング |
| ツール | 安全なシェルコマンドを提案させる | Tool Calling、承認動作 |
| GitHub操作 | IssueやPRを参照させる | gh認証、GHES API |
| 書き込み | 検証用Issueを作成させる | トークン権限、操作記録 |
| 負荷 | 複数人で同時利用する | 応答時間、GPU、タイムアウト |
外向き通信を確認する
ファイアウォールやプロキシのログを確認し、開発者端末とGHESから、想定外のGitHub Cloudや外部サービスへの通信が発生していないかを調べます。
アプリケーション設定だけで「通信しないはず」と判断せず、実際の通信ログで確認することが重要です。
更新手順を試す
閉域環境へ新しいCopilot CLIを持ち込む手順を、初回導入時に一度実施します。
- 配布元から入手する担当者
- ハッシュや署名を確認する担当者
- マルウェア検査を行う場所
- 社内配布基盤への登録方法
- 旧版へ戻す方法
- 緊急更新時の承認フロー
これらが決まっていないと、導入後に脆弱性修正版を適用できなくなります。
導入に向いている組織
GHES 3.22の閉域Copilot CLIは、次のような環境と相性があります。
- ソースコードをGitHub Cloudへ送信できない
- すでにGHESを中心に開発している
- 社内または専用環境でLLMを運用できる
- モデルプロバイダーのAPIキーを中央管理したい
- 開発者ごとのBYOK設定を避けたい
- IssueやPR操作もターミナルから行いたい
- 金融、公共、製造、研究など厳格なネットワーク分離がある
一方、次の組織はGA版と正式仕様を待つ方が安全です。
- 本番環境しか用意できない
- RC環境を使い捨てで構築できない
- モデルサーバーを運用する人員がいない
- GitHubホスト型モデルを自由に切り替えたい
- Web検索やGitHub Cloud依存機能が必要
- GitHub側の利用状況レポートを必須としている
- Technical Previewの仕様変更を受け入れられない
よくある疑問
COPILOT_OFFLINE=trueを設定すれば完全に外部通信を止められますか
完全な外部通信遮断を保証するものではありません。モデルプロバイダーが外部にあれば、プロンプトやコードはそのプロバイダーへ送信されます。
完全閉域にするには、GHES、モデルプロバイダー、クライアント、必要なMCPサーバーなどを同じ分離環境内に配置し、ファイアウォールログでも通信先を確認してください。(GitHub Docs)
OllamaやvLLMを利用できますか
provider-typeをopenaiとして、OpenAI Chat Completions API互換エンドポイントへ接続できます。GitHubはOllama、vLLM、Foundry Localを対応例として挙げています。(GitHub Docs)
ただし、使用するモデル自体がTool Callingとストリーミングに対応している必要があります。
利用者ごとにモデルプロバイダーのAPIキーが必要ですか
GHES 3.22の中央設定を使用する場合、モデルプロバイダーのAPIキーはGHES側へ設定します。利用者側はGHESのPersonal Access Tokenで認証します。(GitHub Docs)
GitHub.comのIssueやリポジトリも操作できますか
この構成で公式に示されているのは、GHESへ認証済みのgh CLIを使い、対象GHES上のIssue、PR、リポジトリを操作する方法です。GitHub.comを同時に利用する構成は、完全閉域の前提と矛盾するため、別経路として設計してください。
Copilotのライセンスは必要ですか
一般のCopilot CLIドキュメントでは、利用条件として有効なCopilotサブスクリプションと、組織またはエンタープライズ側でのCopilot CLIポリシー有効化が案内されています。(GitHub Docs)
一方、GHES 3.22のTechnical Preview向け手順は、独自モデルプロバイダー、GHES資格情報、APIキーを中心に説明しています。正式な契約条件やライセンス要件はGAまでに変わる可能性があるため、本番計画を立てる前にGitHubの契約窓口またはGitHub Supportへ確認するのが安全です。
GHES 3.22の閉域Copilot CLIを検証する際の結論
GHES 3.22では、モデルプロバイダーをGHESに一括設定し、利用者がGHES資格情報でCopilot CLIを使う構成が可能になりました。GitHub Cloudへ接続できない組織にとって、開発支援AIを導入するための重要な選択肢です。
ただし、現在はRC版かつTechnical Previewです。既存の本番GHESへ適用せず、次の順番で進めてください。
- GHES 3.22 RCの新規検証環境を用意する
- 閉域内で利用できるLLMとAPIエンドポイントを準備する
- Tool Callingとストリーミング対応を確認する
- 管理者が
ghe-configでモデルプロバイダーを設定する - 少人数の端末でGHES認証とCopilot CLIを検証する
- ファイアウォールログで想定外の外向き通信がないか確認する
- 権限管理、ログ、CLI更新、モデル基盤の負荷を評価する
- GA版の正式仕様を確認してから本番導入を判断する
最大の注意点は、COPILOT_OFFLINE=trueを設定しただけでは完全なエアギャップにならないことです。モデルプロバイダー、ソフトウェア配布、ログ基盤まで含めて閉域内に収められるかを、導入判断の基準にしてください。
コメント