GitHub Copilot CLIでBYOKモデルとローカルモデルが追加されたことで、Copilotのターミナル体験をGitHubホスト型モデルだけでなく、自社契約のLLMやローカルLLMに向けられるようになりました。GitHubは2026年4月7日にこの変更を公開しており、任意のmodel providerへの接続、ローカルモデル利用、COPILOT_OFFLINE=true によるオフライン運用、GitHub認証なしのBYOK利用を案内しています。(The GitHub Blog)
結論を先に言うと、このアップデートで強くなるのはコスト管理、データ経路の選択肢、隔離環境への適合性です。一方で、GitHub Copilot CLIのガバナンスはこれまで以上に「GitHubのAI controlsで管理できる範囲」と「各ユーザーの端末や接続先provider側で管理すべき範囲」に分かれます。特に、環境変数で接続するユーザー設定型BYOKは enterprise policy の対象外なので、「GitHubでCopilotを管理しているからCLIのモデル経路も全部統制できる」と考えるのは危険です。(GitHub Docs)
この記事では、GitHub Copilot CLIでBYOKモデルとローカルモデルを追加した変更点を整理したうえで、BYOKとローカルモデルの違い、Copilot CLIガバナンスへの影響、導入パターンの選び方、最小手順、運用ルールまで実務目線でまとめます。
2026年4月7日の変更点を3分で把握する
今回のアップデートは、単に「選べるモデルが増えた」という話ではありません。GitHub Copilot CLIのモデルの置き場所と責任の持ち方が変わったのが本質です。(The GitHub Blog)
| 変更点 | 実務上の意味 |
|---|---|
| 任意のmodel providerへ接続できる | 既存契約済みのLLMや独自endpointをCopilot CLIで使える |
| ローカルモデルを使える | 機密性の高い環境やオンプレ前提の検証に向く |
COPILOT_OFFLINE=true が使える | GitHubサーバーへの接続を止め、テレメトリを無効化できる |
| GitHub認証が任意になった | AI応答だけ自前providerに任せ、GitHub連携機能は別で考えられる |
この整理はGitHub changelogと公式ドキュメントをもとにした要約です。(The GitHub Blog)
BYOKモデルとローカルモデルの違い
ここでいうBYOKは、Bring Your Own Key の略です。GitHub Copilot CLIに対して、GitHubホスト型のモデルルーティングではなく、自分のAPIキーや自前のendpointを使ってLLMへ接続する考え方を指します。公式ドキュメントでは、OpenAI互換endpoint、Azure OpenAI、Anthropicに接続でき、OpenAI互換には Ollama、vLLM、Foundry Local のようなローカル実行系も含まれます。つまり、Copilot CLIではローカルモデルも「BYOK設定の一形態」として理解すると整理しやすいです。(GitHub Docs)
| 項目 | BYOKモデル | ローカルモデル |
|---|---|---|
| 接続先 | 外部LLM providerや自社endpoint | ローカルPCやオンプレ内のendpoint |
| 代表例 | OpenAI互換、Azure OpenAI、Anthropic | Ollama、vLLM、Foundry Local |
| APIキー | 多くは必要 | ローカルendpointでは不要なことがある |
| 向く場面 | 既存契約の活用、課金統合、独自provider利用 | air-gapped、機密開発、社内閉域網 |
この比較はCopilot CLIのprovider仕様と認証仕様をもとに整理しています。(GitHub Docs)
注意したいのは、Copilot CLIで動けば何でも良いわけではないことです。GitHubは、利用するモデルにtool calling と streaming の対応を求めており、実用上は128k以上のコンテキストウィンドウを推奨しています。また、組み込みサブエージェントも同じprovider設定を引き継ぐため、単発のQ&Aだけ動けば十分とは言えません。レビューやタスク実行まで含めて評価したほうが、導入後のズレが減ります。(GitHub Docs)
Copilot CLIガバナンスで本当に変わること
まず押さえるべきは「BYOKが2種類ある」こと
同じBYOKでも、実務上は次の2系統があります。
- GitHub管理型BYOK
enterprise / organization が GitHub の AI Controls から custom models を追加し、組織に公開する形 - ユーザー設定型BYOK
開発者が自分の端末でCOPILOT_PROVIDER_*環境変数を設定し、直接providerへつなぐ形
前者はGitHubの管理画面と model picker に乗りますが、後者はユーザーレベル設定で enterprise policy では制御できません。ここを混同すると、ガバナンス設計を誤ります。(GitHub Docs)
GitHubで管理できる範囲と、できない範囲
GitHubの公式ドキュメントでは、Copilot CLIに適用される enterprise-level AI controls と、適用されないものが明確に分かれています。(GitHub Docs)
| GitHubのAI controlsで管理できる | GitHubのAI controlsでは管理できない |
|---|---|
| Copilot CLI の有効 / 無効 | ユーザー設定型BYOK provider |
| enterpriseで有効化したモデル | MCP server policies |
| enterprise-configured custom agents | IDE固有ポリシー |
/delegate に必要な cloud agent policy | content exclusions |
| seat assignment と policy変更の audit log | 各端末のローカルendpoint設定 |
この表は GitHub の「Administering Copilot CLI for your enterprise」をもとに整理しています。(GitHub Docs)
実務で言い換えると、GitHub Copilot CLIはこのアップデートで「1枚の管理画面で全部統制できるCLI」ではなくなりました。GitHub側の統制と端末・network・provider側の統制を併用する前提で考えるほうが現実的です。特に regulated な環境では、この境界を曖昧にしたまま導入しないほうが安全です。(GitHub Docs)
GitHub認証を外せることは、自由でもあり制約でもある
BYOKを使う場合、GitHub認証は必須ではありません。ただし、GitHub認証なしでは使えない機能も明確です。公式には /delegate、GitHub MCP server、GitHub Code Search は認証が必要です。逆にいえば、BYOKとGitHub認証を併用すれば、AI応答だけ自前provider、GitHub連携はGitHub側という分担ができます。(GitHub Docs)
この違いは運用設計でかなり重要です。たとえば、閉域・審査済みの環境では「ローカルモデル + offline + GitHub認証なし」が合います。一方で、レビュー委譲やGitHub検索まで使いたい開発チームは「BYOK + GitHub認証あり」が現実的です。機能要件を先に決めずに認証方式だけ変えると、「動くと思っていた /delegate が使えない」といった混乱が起きやすくなります。(GitHub Docs)
「ローカルモデル = 完全オフライン」ではない
ここは誤解が非常に多いポイントです。COPILOT_OFFLINE=true を設定すると、Copilot CLIはGitHubサーバーへ接続せず、認証も試みず、テレメトリも無効になります。ですが、完全にair-gappedになるのは、provider自体もローカルまたは同じ隔離環境にある場合だけです。COPILOT_PROVIDER_BASE_URL がインターネット越しのendpointを指していれば、プロンプトやコードコンテキストはそのproviderへ送られます。(GitHub Docs)
つまり、セキュリティレビューでは「GitHubに送るかどうか」だけでなく、最終的にどのendpointへ送るのかまで見ないと不十分です。BYOKはデータ経路を選べるようにする機能であって、何もしなくても経路が安全になる機能ではありません。(GitHub Docs)
可視化は改善したが、GitHubだけに依存しないほうがいい
2026年4月10日には、GitHubは Copilot CLI activity を top-level usage metrics と feature breakdowns に統合しました。これにより、標準的なCopilot CLI利用は enterprise / organization の usage metrics で把握しやすくなっています。Copilot usage metrics 自体も、IDEとCopilot CLIを含む複数surfaceの telemetry から導出されると説明されています。(The GitHub Blog)
ただし、offline mode では telemetry が無効化されます。そのため、ローカルモデルや閉域運用を本格導入するなら、GitHubのメトリクスだけで全体把握する前提は置かず、provider側のログ、請求ダッシュボード、endpoint監査、repository hooks のログも併用したほうが安全です。これは公式仕様を並べるだけでは見えにくいですが、実務ではかなり重要な視点です。(GitHub Docs)
どの導入パターンを選ぶべきか
GitHub Copilot CLIでBYOKモデルやローカルモデルを追加できるようになったことで、実際の選択肢は3つに増えました。迷ったら、まずはどのパターンを標準運用にするかを決めると整理しやすくなります。(The GitHub Blog)
| パターン | どう使うか | 向くケース | 強み | 注意点 |
|---|---|---|---|---|
| GitHubホスト型 | 既定のCopilotモデルを使う | 標準展開、運用をシンプルにしたい | GitHub管理に乗せやすい | provider選択の自由度は限定的 |
| GitHub管理型BYOK | enterprise / org が custom models を追加して公開する | 契約済みproviderを統制付きで展開したい | model picker と組織公開設定に乗る | custom models は public preview |
| ユーザー設定型BYOK / ローカル | 開発者が環境変数で直接つなぐ | PoC、air-gapped、ローカル検証 | 最も柔軟で、データ経路を選びやすい | enterprise policy では制御できない |
この比較は、Copilotのmodel access設定、enterprise / organization向けBYOK custom models、Copilot CLIのenterprise controls仕様をもとに整理しています。(GitHub Docs)
ガバナンス優先なら、まず検討したいのはGitHub管理型BYOKです。enterprise / organization は custom models を追加でき、enterprise ではそのモデルをどのorganizationに公開するかも選べます。追加したモデルは model picker に表示されるため、開発者にとっても運用がわかりやすいです。なお、この custom models 機能は public preview とされています。(GitHub Docs)
逆に、ユーザー設定型BYOKやローカルモデルは、自由度は高いものの統制は弱くなります。本番リポジトリではGitHub管理型BYOK、検証や隔離環境ではユーザー設定型BYOK / ローカルのように、リポジトリやネットワーク区分ごとに使い分けるのが現実的です。
GitHub Copilot CLIにBYOKモデルやローカルモデルを追加する最小手順
ユーザー設定型BYOKやローカルモデルを試す最小手順はシンプルです。Copilot CLIは、起動前に設定した環境変数を読んでproviderへ接続します。(GitHub Docs)
まず使う環境変数を確認する
| 環境変数 | 必須 | 役割 |
|---|---|---|
COPILOT_PROVIDER_BASE_URL | 必須 | provider APIのbase URL |
COPILOT_PROVIDER_TYPE | 任意 | openai、azure、anthropic を指定 |
COPILOT_PROVIDER_API_KEY | 任意 | providerのAPIキー。ローカルOllamaなどでは不要な場合がある |
COPILOT_MODEL | 必須 | 使用するmodel identifier |
この表は GitHub Docs の provider 設定仕様をもとに整理しています。(GitHub Docs)
ローカルモデルを追加する最小例
以下は Bash の例です。
export COPILOT_PROVIDER_BASE_URL=http://localhost:11434
export COPILOT_MODEL=<ローカルモデル名>
copilotローカルOllamaのように認証不要のendpointなら、COPILOT_PROVIDER_API_KEY は不要です。モデル名は、その環境で実際に利用できる名前に合わせる必要があります。(GitHub Docs)
リモートBYOKを追加する最小例
OpenAI互換endpointなら、基本形は次のイメージです。
export COPILOT_PROVIDER_BASE_URL=https://<provider-endpoint>/v1
export COPILOT_PROVIDER_API_KEY=<your-api-key>
export COPILOT_MODEL=<model-id>
copilotAzure OpenAI を使うなら COPILOT_PROVIDER_TYPE=azure、Anthropic を使うなら COPILOT_PROVIDER_TYPE=anthropic を指定します。COPILOT_MODEL は --model フラグでも指定できます。詳細な接続例は copilot help providers で確認できます。(GitHub Docs)
セットアップ時に安心材料になるのが、設定が壊れていても GitHubホスト型モデルへ勝手にフォールバックしないことです。GitHubは、provider設定が無効な場合はCLIが分かりやすいエラーを返し、silent fallback はしないと案内しています。「ローカルで試したつもりが、実はGitHubホスト型へ送っていた」という事故を防ぎやすい仕様です。(The GitHub Blog)
導入前に決めるべき運用ルール
手順より大事なのは、どこまでをGitHubで管理し、どこからを端末やproviderで管理するかを先に決めることです。Copilot CLIは、信頼したフォルダ配下のファイルを読み取り、変更し、コマンド実行を試みます。一方で、GitHubの content exclusions は Copilot CLI に適用されません。つまり、ユーザー設定型BYOKやローカルモデルを許可するなら、GitHubのAI Controlsだけでは不十分です。(GitHub Docs)
| 決めること | 最低限のルール例 | |
|---|---|---|
| 利用経路の区分 | 本番はGitHub管理型BYOKまで、検証だけユーザー設定型BYOK / ローカルを許可 | |
| APIキーの扱い | 個人ベタ書きを避け、秘密情報管理ツール経由で配布。権限は最小にする | |
| GitHub連携機能の扱い | /delegate、GitHub Code Search、GitHub MCP を使う環境と使わない環境を分ける | |
| 監査の一次ソース | GitHub metrics、provider請求、endpointログ、hooksログのどれを見るか決める | |
| 危険コマンドの扱い | rm -rf、curl | bash、権限昇格系は自動実行しない | |
| 作業場所 | 信頼済みリポジトリでのみCLIを起動し、秘密ファイル混在ディレクトリでは使わない |
このルール例は、GitHubのtrusted directory仕様、enterprise controls、BYOK custom models の最小権限推奨、hooks と tool permissions の機能を前提にした実務向けの整理です。(GitHub Docs)
技術的にすぐ効く補完策
まず効くのは、許可ツールを事前に絞ることです。GitHubは --allow-tool と --deny-tool による事前設定を案内しており、たとえば copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)' のように、ローカル変更や確認系だけ許し、pushは止めるといった設計ができます。許可を広げすぎた場合は /reset-allowed-tools で戻せます。(GitHub Docs)
さらに統制を強めたいなら、repository-scoped hooks を使う方法が有効です。.github/hooks/*.json で sessionStart、userPromptSubmitted、preToolUse などを設定でき、preToolUse はツール実行前にツール名や引数を見て拒否できます。GitHub自身も、危険コマンドのブロック、プロンプト監査、ポリシーバナー表示を行う Copilot CLI hooks のチュートリアルを公開しています。GitHubのenterprise policyが届かないユーザー設定型BYOKを補うには、かなり相性の良い仕組みです。(GitHub Docs)
よくある誤解と失敗しやすいポイント
- 「BYOKなら enterprise のモデル制御にそのまま乗る」
乗るのは GitHub管理型BYOK custom models です。ユーザーが環境変数で設定する BYOK provider は enterprise policy で制御できません。(GitHub Docs) - 「ローカルモデルなら自動で完全オフラインになる」
完全にair-gappedになるのは、COPILOT_OFFLINE=trueを設定し、providerもローカルまたは同じ隔離環境にある場合です。remote endpoint なら、そのproviderへは通信します。(GitHub Docs) - 「GitHub認証を外しても
/delegateや Code Search は使える」
これらはGitHub認証が必要です。BYOKだけでは使えません。(GitHub Docs) - 「content exclusions を設定していれば CLI も安全」
file path ベースの content exclusions は Copilot CLI に適用されません。CLI側の trusted directory、tool permissions、hooks で補う必要があります。(GitHub Docs) - 「設定ミス時は GitHubホスト型に自動フォールバックする」
GitHubは silent fallback をしないと明記しています。誤設定時はエラーになります。(The GitHub Blog) - 「軽いローカルモデルなら何でも使える」
Copilot CLIでは tool calling と streaming が必要です。ここを満たさないとエラーになります。(GitHub Docs)
次にやること
GitHub Copilot CLIでBYOKモデルとローカルモデルが追加されたことで、Copilot CLIはより柔軟になりました。ただし、ガバナンスの観点では「GitHubで統制するCopilot」と「端末側で直接つなぐCopilot CLI」を分けて考える必要があります。中央統制を重視するなら GitHub管理型BYOK custom models、隔離環境やPoCを重視するならユーザー設定型BYOK / ローカルモデルが向いています。(The GitHub Blog)
導入を進めるなら、次の順番が失敗しにくいです。
- まず、GitHubホスト型 / GitHub管理型BYOK / ユーザー設定型BYOK・ローカル のどれを標準にするか決める。
- 次に、1つのリポジトリで小さくPoCし、単発チャットだけでなく、レビューやタスク実行まで含めて評価する。
- 最後に、tool permissions、hooks、trusted directory、provider側ログ をセットで整備してから広げる。
この順番なら、モデル経路、利用機能、監査方法を切り分けながら段階的に検証できます。(GitHub Docs)
コメント