GitHub Copilot app support for BYOK は、GitHub Copilot app から自分で契約・管理しているLLMプロバイダーのAPIキーを使えるようにする変更です。これにより、Copilotが用意するモデルだけでなく、OpenAI、Azure OpenAI、Anthropic、Ollama、LM Studio、OpenAI互換エンドポイントなどを、エージェントセッションごとに選択できるようになります。まず確認すべきなのは、自社のCopilot利用ポリシー、APIキー管理、利用料金の負担先、送信データの扱いです。GitHub Changelog上では、この更新は「Release」として2026年6月23日付で公開されています。日本時間で確認する運用では、2026年6月24日更新として扱われる場合があります。(The GitHub Blog)
GitHub Copilot app support for BYOK は何が変わった？
GitHub Copilot app support for BYOK の主な変更点は、GitHub Copilot app の「Model Providers」設定から外部LLMプロバイダーを追加し、そのモデルをエージェントセッションで使えるようになったことです。
BYOKは「Bring Your Own Key」の略で、直訳すると「自分のキーを持ち込む」という意味です。今回の文脈では、GitHubがホストするモデルだけに依存せず、利用者自身が持つLLMプロバイダーのAPIキーやエンドポイントをCopilot appに登録して使う仕組みを指します。
GitHubの公式情報では、GitHub Copilot app が BYOK に対応し、OpenAI、Azure OpenAI、Microsoft Foundry、Anthropic、LM Studio、Ollama、OpenAI互換エンドポイントなどに対してエージェントセッションを実行できるようになったと説明されています。(The GitHub Blog)
変更前と変更後の違い
| 項目 | 変更前 | 変更後 |
|---|---|---|
| 利用できるモデル | 主にCopilot側で提供されるモデル | Copilot提供モデルに加え、自分のLLMプロバイダーも選択可能 |
| モデル選択 | Copilot側の選択肢に依存 | セッションごとに外部モデルを選択可能 |
| 課金・クォータ | GitHub Copilot側の契約条件が中心 | 外部プロバイダー側の課金、クォータ、リージョン条件も関係する |
| データ境界 | GitHub Copilot側の処理経路が中心 | 自社クラウド、テナント、内部ゲートウェイを経由する構成も検討可能 |
| APIキー管理 | Copilot利用者は通常意識しない | 利用者または組織がAPIキー管理を意識する必要がある |
今回の変更は、単なるモデル追加ではありません。開発者が「どのモデルに、どの経路で、どのデータを送るか」を選べるようになるため、企業利用ではガバナンス設計にも関わります。
対象になる利用者
GitHub Docsでは、GitHub Copilot app は有料のCopilotプランで利用できると説明されています。また、BYOK機能はGitHub Copilot appで自分のLLMプロバイダーAPIキーをローカル端末に設定したい利用者向けの機能として説明されています。(GitHub Docs)
特に影響が大きいのは、次のような利用者です。
- GitHub Copilot appでエージェントセッションを利用している開発者
- OpenAI、Azure OpenAI、Anthropicなどをすでに社内で契約しているチーム
- OllamaやLM Studioなど、ローカルモデルやセルフホスト環境を試している開発者
- Copilot BusinessまたはCopilot Enterpriseを管理している管理者
- 生成AI利用時のデータ送信先、リージョン、ログ管理を厳格に扱う組織
一方で、Visual Studio CodeやJetBrains IDE上の通常のコード補完だけを使っているユーザーに、直ちに大きな操作変更が発生するとは限りません。今回の中心は、GitHub Copilot appのモデルプロバイダー設定とエージェントセッションです。
すぐ確認すべき設定
GitHub Copilot app support for BYOK を利用する前に、まずは設定画面と管理ポリシーを確認してください。
GitHubの手順では、GitHub Copilot appを開き、アプリ設定から「Model providers」を選び、「Add provider」からプロバイダーを追加します。登録時には、プロバイダーに応じて表示名、Base URL、APIキーなどを入力します。追加後は、そのプロバイダーのモデルがGitHubホストモデルと並んでモデルピッカーに表示され、セッションで選択できるようになります。(GitHub Docs)
確認項目
| 確認項目 | 見るべきポイント | 放置した場合のリスク |
|---|---|---|
| GitHub Copilot appの利用有無 | 対象ユーザーがアプリを使っているか | 影響範囲を誤って判断する |
| Model Providers設定 | 外部プロバイダーを追加できる状態か | 個人判断でAPIキーが登録される |
| APIキーの発行元 | 個人キーか、組織管理キーか | 退職・異動時に利用停止できない |
| 課金先 | GitHub側か、外部LLMプロバイダー側か | 想定外のAPI利用料が発生する |
| 利用モデル | クラウドモデルか、ローカルモデルか | データ送信先や性能差を把握できない |
| 管理ポリシー | Copilot CLIやapp利用が許可されているか | ユーザーごとに利用可否がばらつく |
特に重要なのは、APIキーの扱いです。GitHub Docsでは、キーはシステムの資格情報ストアに保存され、UIには表示されないと説明されています。(GitHub Docs) ただし、UIで読み戻せないことと、組織として安全に管理できていることは別問題です。企業利用では、誰が発行し、誰が失効でき、利用量をどこで監視するのかを決めておく必要があります。
対応プロバイダーと使い分け
GitHub Docsでは、BYOKで利用できるプロバイダーとして、OpenAI、Azure OpenAI、Microsoft Foundry、Anthropic、Ollama、Foundry Local、LM Studio、OpenAI互換HTTPエンドポイントが挙げられています。(GitHub Docs)
実務では、単に「高性能なモデルを使えるか」だけでなく、データの扱い、費用、応答速度、社内ルールとの相性で選ぶことが重要です。
| 利用パターン | 向いている選択肢 | 判断ポイント |
|---|---|---|
| 既存のAI契約を活用したい | Azure OpenAI、OpenAI、Anthropicなど | 既存の請求管理、利用上限、監査ログを使えるか |
| 社内テナントやリージョンを重視したい | Azure OpenAI、Microsoft Foundry、内部ゲートウェイ | データ処理リージョン、社内規程、契約条件との整合性 |
| ローカルで試したい | Ollama、LM Studio、Foundry Local | 機密情報の扱い、端末性能、モデル品質 |
| 複数モデルを用途別に使いたい | クラウドモデルとローカルモデルの併用 | 難しい設計は高性能モデル、簡単な実行はローカルモデルなどの分担 |
| 社内LLM基盤を経由したい | OpenAI互換エンドポイント | 認証、ログ、レート制限、プロキシ設定の整備 |
GitHub Changelogでも、BYOKにより既存の請求、クォータ、リージョン、データ処理条件を保ちながらプロバイダーを接続できること、またローカルモデルとフロンティアモデルを組み合わせられることが説明されています。(The GitHub Blog)
Copilot Business・Enterprise管理者が見るべきポイント
Copilot BusinessまたはCopilot EnterpriseでGitHub Copilot appを使う場合は、個々の開発者だけでなく、管理者側の設定確認が必要です。
GitHub Changelogには、Copilot BusinessまたはEnterpriseプランでGitHub Copilot appにアクセスするには、組織またはEnterprise管理者がポリシー設定でCopilot CLIを有効にしている必要があるという注意書きがあります。(The GitHub Blog)
つまり、現場の開発者が「GitHub Copilot appでBYOKを使いたい」と言っても、管理者ポリシーによっては利用できない可能性があります。
管理者が決めておきたい運用ルール
APIキーは個人管理にしない
検証用途なら個人キーでも始められますが、本番に近い開発や業務コードで使う場合は、組織管理のAPIキーや専用プロジェクトを使うのが安全です。
個人キーに依存すると、退職・異動・権限変更のタイミングで利用状況を追いにくくなります。キー漏えい時の影響範囲も把握しづらくなります。
モデルごとの利用範囲を明文化する
たとえば、次のように用途を分けると運用しやすくなります。
| 用途 | 推奨ルールの例 |
|---|---|
| 公開予定のOSSコード | Copilotホストモデルまたは承認済み外部モデルを利用 |
| 社内業務ロジック | 承認済みクラウドプロバイダーのみ利用 |
| 機密性の高いコード | ローカルモデル、社内ゲートウェイ、または利用禁止 |
| 大量生成・リファクタリング | 予算上限を設定した専用キーを利用 |
| 検証・PoC | 本番データを含まないサンプルコードで実施 |
「BYOKが使えるようになったから自由に使ってよい」と捉えると、コストとデータ管理の両方で問題が起きやすくなります。
請求と利用量を別途監視する
BYOKでは、GitHub Copilotの利用料だけでなく、接続先LLMプロバイダーのAPI利用料も関係します。特にエージェントセッションでは、通常のチャットより多くの入力・出力が発生する可能性があります。
社内で使う場合は、少なくとも次の3点を確認してください。
- 外部LLMプロバイダー側の月額上限または予算アラート
- APIキー単位、プロジェクト単位、部署単位の利用量
- 異常な呼び出し増加を検知する仕組み
「Copilotの画面で使っているからGitHub側の課金だけ」と誤解しないことが重要です。
開発者がすぐ試す前に確認したいこと
個人開発者や小規模チームがGitHub Copilot app support for BYOKを試す場合も、最低限の確認は必要です。
まずはテスト用のAPIキーを使う
最初から本番用の高権限キーを登録するのは避けましょう。プロバイダー側で予算上限、レート制限、利用可能モデルを絞った検証用キーを作る方が安全です。
機密コードをいきなり送らない
BYOKを使うと、推論の処理先は選んだ外部プロバイダーになります。プロバイダーの契約条件、データ保持、ログ、学習利用の扱いは必ず確認してください。
たとえば、社内の未公開アルゴリズム、認証処理、顧客データを含むコードをそのまま送る前に、マスキングやサンプル化が必要か判断します。
モデルの得意不得意を把握する
BYOKでは複数モデルを選べるようになりますが、すべてのモデルが同じ品質でコード生成やリファクタリングに強いわけではありません。ローカルモデルはデータ境界を制御しやすい一方、複雑な設計変更や大規模なコンテキスト理解ではクラウドの高性能モデルに劣る場合があります。
実務では、次のように使い分けると失敗しにくくなります。
| 作業 | モデル選びの考え方 |
|---|---|
| 小さなコード修正 | ローカルモデルや軽量モデルでも試しやすい |
| 大規模リファクタリング | 高性能なクラウドモデルを検討 |
| 社内コードの説明 | データ送信先を確認した上で利用 |
| テストコード生成 | コストと品質のバランスで選ぶ |
| セキュリティレビュー | モデル任せにせず、人のレビューを必ず残す |
よくある誤解と注意点
BYOKにすればGitHub Copilotの契約が不要になるわけではない
BYOKは、GitHub Copilot appから外部モデルプロバイダーを使うための仕組みです。GitHub Docsでは、GitHub Copilot appは有料Copilotプランで利用できると説明されています。(GitHub Docs) 外部プロバイダーのAPIキーを持っていても、それだけでGitHub Copilot appの利用条件を満たすとは考えない方がよいでしょう。
APIキーを登録すれば全モデルが使えるとは限らない
外部プロバイダー側で契約していないモデル、リージョン制約があるモデル、組織で無効化されているモデルは使えない場合があります。Azure OpenAIであれば、利用したいモデルのデプロイ有無やリージョンも確認が必要です。
ローカルモデルなら必ず安全とは限らない
OllamaやLM Studioのようなローカル環境は、外部送信を抑えやすいメリットがあります。ただし、端末の管理、モデルファイルの入手元、ログ保存、社内ネットワークからのアクセス制御を考えないと、別のリスクが残ります。
Public Previewである点に注意する
GitHub Docsでは、GitHub Copilot appで自分のプロバイダーを使うBYOKサポートはPublic Previewであり、変更される可能性があると説明されています。(GitHub Docs) 本番運用に組み込む場合は、仕様変更を前提に、手順書や運用ルールを定期的に見直す必要があります。
企業での導入手順
GitHub Copilot app support for BYOK を組織で使う場合は、いきなり全社展開せず、小さく検証してから広げるのが現実的です。
| フェーズ | やること | 判断基準 |
|---|---|---|
| 事前確認 | Copilot app、Copilot CLIポリシー、対象プランを確認 | 対象ユーザーが利用可能か |
| 技術検証 | テスト用APIキーでModel Providersに追加 | 接続、モデル表示、セッション実行ができるか |
| セキュリティ確認 | 送信データ、ログ、キー保管、失効手順を確認 | 社内ルールに合うか |
| コスト確認 | プロバイダー側の利用量と上限を設定 | 想定外課金を防げるか |
| 利用ルール作成 | 使ってよいモデル、禁止データ、レビュー手順を明文化 | 開発者が迷わず使えるか |
| 限定展開 | 少人数の開発チームで試す | 効果、品質、トラブルを確認できるか |
| 本格展開 | 管理者ポリシーと手順を整えて展開 | 継続運用できるか |
この順序で進めると、「便利そうだから使い始めたが、あとから費用やデータ管理で止まる」という失敗を避けやすくなります。
今回の変更でCopilot利用者が取るべき行動
GitHub Copilot app support for BYOK は、Copilot appをより柔軟に使えるようにする重要な更新です。特に、既存のLLM契約を活用したい企業、自社テナントやローカルモデルを使いたい開発チームにとっては、選択肢が広がります。
一方で、BYOKは自由度が高い分、APIキー管理、課金、データ送信先、管理ポリシーの確認が欠かせません。個人利用なら検証用キーと小さなサンプルから始め、企業利用なら管理者がCopilot appの利用可否、Copilot CLIポリシー、外部プロバイダーの利用ルールを先に整理するべきです。
まずは、対象ユーザーがGitHub Copilot appを使っているか、Model Providersに外部プロバイダーを追加する必要があるか、外部LLMの利用を社内規程で許可できるかを確認してください。そのうえで、検証用APIキー、予算上限、利用禁止データのルールを用意してから試すのが安全です。
コメント