GitHub Copilot app support for BYOK は、GitHub Copilot app から自分のLLMプロバイダーやAPIキーを使ってエージェントセッションを実行できるようにする機能です。OpenAI、Azure OpenAI、Microsoft Foundry、Anthropic、LM Studio、Ollama、OpenAI互換エンドポイントなどを、GitHubホストのモデルと並べて選択できる点が大きな変更です。GitHub Changelogでは2026年6月23日付の「Release」として公開されており、本記事では2026年6月24日時点で確認できる公式情報をもとに、何ができるのか、誰が対象なのか、表示されない・使えない時にどこを確認すべきかをQ&A形式で整理します。(The GitHub Blog)
GitHub Copilot app support for BYOK のよくある疑問を整理
GitHub Copilot app support for BYOK を一言でいうと、「GitHub Copilot app のエージェント作業に、自社や個人で契約しているAIモデル基盤を持ち込める機能」です。
従来のようにGitHub側が用意したモデルだけを使うのではなく、Azure OpenAI、Anthropic、ローカルLLM、社内ゲートウェイなどを選び、用途に応じてモデルを切り替えられるようになります。特に、企業の開発現場では「既存のクラウド契約を使いたい」「推論トラフィックを自社テナントに寄せたい」「ローカルモデルも併用したい」といったニーズに合いやすい機能です。(The GitHub Blog)
ただし、公式ドキュメントでは BYOK は public preview とされており、仕様が今後変わる可能性があります。導入を検討する場合は、本番利用前に対象プラン、管理者ポリシー、APIキー管理、課金、データ取り扱い条件を確認しておくことが重要です。(GitHub Docs)
GitHub Copilot app の BYOK とは何ですか？
BYOK は「Bring Your Own Key」の略で、自分が契約・管理しているモデルプロバイダーのAPIキーを GitHub Copilot app に設定して使う考え方です。
GitHubの公式説明では、GitHub Copilot app に外部プロバイダーのAPIキーを設定することで、GitHubホストのモデルではなく、自分のLLMプロバイダーを使えるとされています。設定後は、追加したプロバイダーのモデルがモデルピッカーに表示され、セッションごとに利用するモデルを選択できます。(GitHub Docs)
実務的には、次のような使い分けがしやすくなります。
| 使い方 | 向いているケース | 注意点 |
|---|---|---|
| Azure OpenAI を使う | 既存のAzure契約、リージョン、社内統制を活用したい | モデルデプロイ名、エンドポイント、APIキーの設定確認が必要 |
| Anthropic など外部プロバイダーを使う | タスクごとに得意なモデルを選びたい | プロバイダー側の利用規約・課金・レート制限を確認する |
| Ollama / LM Studio を使う | ローカルモデルや検証用モデルを使いたい | PC性能、モデルサイズ、ローカルサーバーの起動状態に依存する |
| OpenAI互換エンドポイントを使う | 社内ゲートウェイや独自基盤を経由したい | API互換性、認証方式、ネットワーク到達性を事前に確認する |
ポイントは、BYOK が「GitHub Copilotの契約を置き換える機能」ではないことです。あくまで GitHub Copilot app の中で、エージェントセッションに使うモデルプロバイダーを追加する機能として理解すると混乱しにくくなります。
何ができるようになりますか？
GitHub Copilot app support for BYOK によって、主に次の3つが可能になります。
まず、自分がすでに使っているモデルプロバイダーを GitHub Copilot app に追加できます。公式Changelogでは、OpenAI、Azure OpenAI、Microsoft Foundry、Anthropic、LM Studio、Ollama、OpenAI互換エンドポイントなどが例示されています。(The GitHub Blog)
次に、追加したモデルを GitHubホストのモデルと並べてモデルピッカーから選べます。たとえば、設計相談や複雑なコード理解には高性能なクラウドモデルを使い、軽い修正や検証にはローカルモデルを使う、といった運用が考えられます。(The GitHub Blog)
さらに、企業や規制対応が必要な環境では、自社のクラウドアカウント、テナント、内部ゲートウェイを経由して推論トラフィックを流す選択肢ができます。これは「GitHub Copilotを使いたいが、データ境界やモデル利用条件をより厳密に管理したい」という組織にとって重要な判断材料になります。(The GitHub Blog)
対象になる人は誰ですか？
公式ドキュメントでは、GitHub Copilot app はすべての有料Copilotプランで利用できるとされています。BYOKを使うには、GitHub Copilot app のインストールと、利用したいモデルプロバイダーのAPIキーが必要です。(GitHub Docs)
対象になりやすいのは、次のような人です。
| 対象者 | BYOK が役立つ理由 |
|---|---|
| 個人開発者 | ローカルLLMや既存のAPIキーを、Copilot app の作業に試せる |
| 企業の開発者 | 会社指定のAI基盤やクラウド契約を使いやすい |
| 管理者・情シス | APIキー、テナント、課金、データ取り扱いを既存ルールに合わせやすい |
| AI基盤担当者 | OpenAI互換ゲートウェイや社内モデル基盤との接続検証がしやすい |
| 規制業界の開発チーム | 推論先やデータ境界をより明確に設計しやすい |
一方で、単に「GitHub Copilotのコード補完を安くしたい」という目的だけなら、BYOKが最初の選択肢になるとは限りません。BYOKではプロバイダー側の課金、レート制限、APIキー管理も発生するため、コスト比較はGitHub Copilot側だけでなく、接続先のモデル利用料まで含めて見る必要があります。
GitHub Copilot app と通常の Copilot Chat の違いは？
今回の対象は、名前の通り「GitHub Copilot app」です。GitHub Copilot全体のすべての画面やIDE機能で、同じようにBYOKが使えるという意味ではありません。
GitHub Copilot app は、サインイン後にクイックチャットを使ったり、リポジトリを接続してエージェントセッションを作成したりするアプリです。公式ドキュメントでは、GitHub Copilot app のクイックスタートとして、アプリのインストール、GitHubへのサインイン、リポジトリ接続、クイックチャット、セッション作成の流れが説明されています。(GitHub Docs)
混同しやすい点を整理すると、次のようになります。
| 項目 | GitHub Copilot app の BYOK | IDEのCopilot補完・一般的なCopilot Chat |
|---|---|---|
| 主な用途 | エージェントセッションで使うモデルを追加・選択する | コード補完、チャット、IDE内支援 |
| 設定場所 | GitHub Copilot app の Model providers | 利用環境や管理者設定に依存 |
| モデル選択 | 追加したプロバイダーのモデルをモデルピッカーで選択 | 機能ごとに対応状況が異なる |
| 注意点 | public preview のため変更の可能性あり | BYOK対応範囲を同一視しない |
「CopilotでBYOKが使える」と聞いた場合は、まずどのCopilot画面・どのクライアント・どの機能を指しているのかを確認してください。ここを曖昧にすると、「設定したのにIDE側に出てこない」といった誤解につながります。
対応しているモデルプロバイダーは？
公式ドキュメントでは、GitHub Copilot app の BYOK でサポートされるモデルプロバイダーとして、OpenAI、Azure OpenAI、Microsoft Foundry、Anthropic、Ollama、Foundry Local、LM Studio、任意のOpenAI互換HTTPエンドポイントが挙げられています。(GitHub Docs)
公式Changelogでは、OpenAI、Azure OpenAI、Microsoft Foundry、Anthropic、LM Studio、Ollama、OpenAI互換エンドポイントへの対応が紹介されています。(The GitHub Blog)
選び方は、単に「高性能なモデルを選ぶ」ではなく、次の観点で判断すると実務に合います。
| 判断基準 | 確認すること | 例 |
|---|---|---|
| データ取り扱い | 入力コードやプロンプトがどこに送信されるか | 自社テナント、外部API、ローカル実行 |
| 課金 | どの契約・予算で利用料が発生するか | Azure課金、外部API課金、ローカル運用コスト |
| レート制限 | チーム利用時に制限に当たらないか | APIのRPM/TPM制限、同時実行数 |
| 性能 | コード理解・修正・長文コンテキストに強いか | 大規模リポジトリの調査、テスト修正 |
| 運用負荷 | APIキー管理や障害対応が可能か | キーローテーション、監査、接続障害時の切り分け |
企業では、まずAzure OpenAIや社内ゲートウェイなど、既存の監査・請求・ネットワーク設計に乗せやすい選択肢から検証すると進めやすいでしょう。個人や小規模チームでは、LM StudioやOllamaを使ってローカルモデルの挙動を試す方法もあります。
設定方法は？
公式ドキュメントでは、GitHub Copilot app の設定から Model providers を開き、Add provider でプロバイダーを追加する流れが案内されています。入力項目はプロバイダーによって異なりますが、表示名、base URL、APIキーなどが含まれる場合があります。(GitHub Docs)
基本的な流れは次の通りです。
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | GitHub Copilot app を開く | 有料Copilotプランでサインインしているか |
| 2 | app settings を開く | 設定画面が見つからない場合はアプリの更新を確認 |
| 3 | Model providers を選ぶ | BYOK設定の入口 |
| 4 | Add provider をクリック | 追加したいプロバイダーを選択 |
| 5 | provider details を入力 | 表示名、base URL、APIキーなど |
| 6 | Add provider で保存 | 保存後、モデルピッカーに表示されるか確認 |
保存後、追加したプロバイダーのモデルは GitHubホストのモデルと並んでモデルピッカーに表示され、セッションで選択できるようになります。(GitHub Docs)
実務では、いきなり本番リポジトリで使うのではなく、検証用リポジトリや小さなタスクで接続確認を行うのがおすすめです。最初は「READMEの説明を改善する」「小さなテストを追加する」「既知の軽微なバグを修正する」など、結果を人間がすぐレビューできる範囲に限定すると安全です。
APIキーはどこに保存されますか？
公式Changelogでは、キーはローカルOSのキーチェーンに保存され、UIから読み戻されることはないと説明されています。公式ドキュメントでも、キーはシステムの資格情報ストアに保存され、UIには表示されないとされています。(The GitHub Blog)
これは、画面上でAPIキーを再表示してコピーできるタイプの設定ではない、という意味です。セキュリティ上は望ましい一方で、運用面では次の点に注意が必要です。
| 注意点 | 実務での対応 |
|---|---|
| APIキーを後から見直せない | パスワード管理ツールやシークレット管理基盤に原本を保管する |
| 退職者・異動者のPCに設定が残る可能性 | 端末管理、アカウント無効化、APIキーのローテーションを行う |
| 個人APIキーの利用状況が見えにくい | チームでは共有キーではなく、用途別キーや管理されたキーを使う |
| キー漏えい時の影響範囲が大きい | 最小権限、利用上限、監査ログ、定期ローテーションを設定する |
特に企業利用では、「開発者が個人で取得したAPIキーを自由に登録する」運用は避けた方が安全です。どのプロバイダーを許可するか、どの契約のAPIキーを使うか、誰が失効できるかを決めてから展開しましょう。
使えない・表示されない時に確認すること
GitHub Copilot app support for BYOK が見えない、Model providers が表示されない、追加したモデルがモデルピッカーに出てこない場合は、機能そのものの不具合と決めつける前に、前提条件を順番に確認してください。
| 症状 | 確認すること | 対処の考え方 |
|---|---|---|
| GitHub Copilot app が使えない | 有料Copilotプランか | 公式ドキュメントでは有料Copilotプランが前提 |
| Business / Enterprise で使えない | 管理者が Copilot CLI policy を有効化しているか | 管理者にポリシー設定を確認する |
| Model providers が見えない | GitHub Copilot app のバージョンが古くないか | アプリ更新、再起動、再サインインを試す |
| プロバイダー追加後にモデルが出ない | APIキー、base URL、エンドポイントが正しいか | 接続先の管理画面やAPI疎通を確認 |
| Ollama / LM Studio が動かない | ローカルサーバーが起動しているか | ホスト、ポート、モデルのロード状態を確認 |
| Azure OpenAI がつながらない | デプロイ名、エンドポイント、リージョン、キーが合っているか | Azure側のデプロイ・アクセス制御を確認 |
| 途中で失敗する | レート制限、クォータ、課金上限に達していないか | プロバイダー側の使用量・ログを見る |
| 会社PCで接続できない | プロキシ、ファイアウォール、証明書検査の影響 | 社内ネットワーク管理者に確認する |
GitHub Copilot Business または Enterprise プランで GitHub Copilot app を使う場合、公式Changelogでは、組織またはEnterprise管理者がポリシー設定で Copilot CLI を有効化している必要があるとされています。(The GitHub Blog)
そのため、個人アカウントでは見えるのに会社アカウントでは見えない場合は、アプリやPCではなく、組織側のポリシーが原因である可能性があります。開発者本人だけで解決しようとせず、管理者に「GitHub Copilot app と Copilot CLI policy の有効化状況」を確認してもらうのが近道です。
BYOK を使うべきケース、使わない方がよいケース
BYOK は便利ですが、すべてのチームがすぐに有効化すべき機能ではありません。特に企業利用では、自由度が上がるほど、APIキー管理・課金・データ取り扱いの責任も増えます。
| 判断 | 向いているケース | 理由 |
|---|---|---|
| 使うべき | Azure OpenAI など既存のAI基盤を標準化している | 既存の請求・監査・セキュリティ設計に合わせやすい |
| 使うべき | ローカルLLMや社内ゲートウェイを検証したい | モデル選択の自由度が高い |
| 使うべき | データ境界やリージョンを重視する | 推論経路を設計しやすい |
| 慎重に使う | 個人APIキーをチームで共有したい | 権限管理・退職時対応・監査が難しい |
| 慎重に使う | コスト管理の仕組みがない | 外部APIの利用料が想定以上になる可能性がある |
| 使わなくてよい | GitHubホストのモデルで十分 | 運用負荷を増やす理由が少ない |
判断のコツは、「BYOKで何を改善したいのか」を先に決めることです。
たとえば、目的が「社内のAzure契約に寄せたい」なら、Azure OpenAIの接続検証を優先します。目的が「ローカルで軽い作業を試したい」なら、OllamaやLM Studioを使った小規模検証が向いています。目的が曖昧なまま複数プロバイダーを追加すると、モデル選択・費用・障害切り分けが複雑になります。
企業導入で先に決めておきたい運用ルール
企業で GitHub Copilot app support for BYOK を使うなら、設定手順よりも先に運用ルールを決めることが重要です。特に、APIキーを誰が発行し、誰が失効し、どのリポジトリやデータに使ってよいかを曖昧にすると、あとから統制が難しくなります。
最低限、次の項目は導入前に整理しておきましょう。
| 決めること | 具体例 |
|---|---|
| 許可するプロバイダー | Azure OpenAIのみ、Anthropicも可、ローカルLLMは検証環境のみなど |
| APIキーの発行元 | 個人発行を禁止し、チーム管理のキーを使う |
| 利用できるリポジトリ | 機密度の高いリポジトリは対象外にする |
| ログと監査 | プロバイダー側の利用ログ、GitHub側の利用状況、社内申請履歴を確認する |
| コスト上限 | 月次予算、クォータ、アラート、利用停止条件を決める |
| 障害時の切り戻し | GitHubホストモデルに戻す、別モデルに切り替える、利用停止する |
BYOK は「開発者が好きなモデルを自由に使える機能」としてだけ見るとリスクがあります。むしろ、組織が承認したAI基盤を GitHub Copilot app のワークフローに組み込むための機能として設計すると、導入後の混乱を減らせます。
よくある質問
GitHub Copilot app support for BYOK は正式提供ですか？
GitHub Changelog上の分類は「Release」ですが、公式ドキュメントでは、GitHub Copilot app で自分のプロバイダーを使うBYOK機能は public preview であり、変更される可能性があると記載されています。導入時は、正式な固定仕様として扱うのではなく、検証・段階展開を前提にするのが安全です。(The GitHub Blog)
GitHub Copilot のすべての機能で BYOK が使えますか？
公式情報で説明されているのは、GitHub Copilot app のエージェントセッションに外部プロバイダーのモデルを接続して使う内容です。IDEの補完、Web版Copilot Chat、その他のCopilot機能まで同じように使えると決めつけないでください。対象は「GitHub Copilot app」として確認する必要があります。(GitHub Docs)
無料プランでも使えますか？
公式ドキュメントでは、GitHub Copilot app はすべての有料Copilotプランで利用できるとされています。BYOKを使いたい場合も、まず利用中のCopilotプランが対象かを確認してください。(GitHub Docs)
Business や Enterprise で見えない場合は何を確認すべきですか？
GitHub Copilot Business または Enterprise で GitHub Copilot app にアクセスするには、組織またはEnterprise管理者がポリシー設定で Copilot CLI を有効化している必要があります。開発者側でアプリを更新しても見えない場合は、管理者設定を確認するのが先です。(The GitHub Blog)
追加したAPIキーはGitHub Copilot appの画面で再表示できますか？
公式情報では、キーはローカルOSのキーチェーンまたはシステム資格情報ストアに保存され、UIから読み戻されたり表示されたりしないとされています。設定後にキーを確認したい場合に備えて、APIキーの原本はプロバイダー側または社内のシークレット管理ツールで適切に管理してください。(The GitHub Blog)
ローカルLLMを使えばコードは外部に送られませんか？
OllamaやLM Studioなどローカル環境で動作するモデルを使う場合、推論先をローカルに寄せられる可能性があります。ただし、実際のデータ経路は設定、接続先、拡張機能、ネットワーク構成によって変わります。「ローカルLLMだから必ず外部通信がゼロ」と断定せず、通信先、ログ、プロキシ、モデル取得元を確認してください。
BYOK にすると GitHub Copilot の利用料は不要になりますか？
BYOK は外部プロバイダーのキーを使う機能であり、GitHub Copilot app の利用条件そのものをなくす機能ではありません。公式ドキュメントでは GitHub Copilot app の利用には有料Copilotプランが前提とされているため、GitHub側のプランと、接続先プロバイダー側の課金を分けて考える必要があります。(GitHub Docs)
導入前の確認チェックリスト
GitHub Copilot app support for BYOK を試す前に、次の順番で確認すると失敗しにくくなります。
| 確認項目 | OKの状態 |
|---|---|
| GitHub Copilot app | インストール済みで、対象アカウントでサインインできる |
| Copilotプラン | 有料Copilotプランを利用している |
| 管理者ポリシー | Business / Enterprise では Copilot CLI policy が有効 |
| プロバイダー | OpenAI、Azure OpenAI、Anthropic、Ollamaなど利用先が決まっている |
| APIキー | 発行済みで、権限・上限・失効方法が明確 |
| エンドポイント | base URL、デプロイ名、ホスト、ポートが確認済み |
| コスト管理 | プロバイダー側の課金上限やアラートを設定済み |
| セキュリティ | 入力してよいコード・データの範囲が決まっている |
| 検証方法 | 小さなリポジトリや低リスクなタスクで試す |
特に重要なのは、最初から全社展開しないことです。まずは少人数で「接続できるか」「モデルピッカーに出るか」「期待した品質が出るか」「課金が想定内か」を確認し、問題がなければ対象リポジトリや利用者を広げていく方が安全です。
まとめ：GitHub Copilot app BYOK は、モデル選択と統制を両立したい人向け
GitHub Copilot app support for BYOK は、GitHub Copilot app のエージェントセッションで、自分のモデルプロバイダーやAPIキーを使えるようにする機能です。GitHubホストのモデルだけでなく、Azure OpenAI、Anthropic、ローカルLLM、OpenAI互換エンドポイントなどを選べるため、既存のAI基盤や企業のデータ管理方針に合わせた運用がしやすくなります。(The GitHub Blog)
一方で、public preview の機能であること、GitHub Copilot app が有料Copilotプラン前提であること、Business / Enterprise では管理者ポリシーが関係すること、APIキーと課金の管理責任が増えることは押さえておく必要があります。(GitHub Docs)
次に取るべき行動はシンプルです。個人利用なら、まず GitHub Copilot app を更新し、低リスクなリポジトリで1つのプロバイダーだけを追加して試します。企業利用なら、先に管理者ポリシー、許可プロバイダー、APIキー管理、コスト上限、利用可能なデータ範囲を決めてから、限定的なパイロット導入を行いましょう。
コメント