GitHub CopilotのCustom Endpointとは？BYOKで任意モデルをVS Codeに繋ぐ方法と注意点

監修者_SD以外

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

Custom Endpointで何が変わる？

ここでのいちばん大きな変化は、Copilot Chatの画面をそのまま使いながら、GitHub Hosted Models以外のendpointを正式な導線で追加できるようになったことです。OpenAI互換の自前サーバーやローカルモデル、Anthropic互換endpointを、VS Code側のモデル一覧に並べて切り替えやすくなりました。

以前はOpenAI互換の設定を個別に差し込む前提で理解されがちでしたが、執筆時点ではCustom Endpoint providerが新しい入口です。対応するAPIも1種類ではなく、Chat Completions、Responses、Messagesをモデルごとに選べるため、既存の推論基盤をCopilotに寄せやすくなっています。

ただし、これは「Copilotの見た目を保ったまま好きなモデルをつなげる仕組み」であって、あらゆる機能が同じように置き換わる意味ではありません。次の章では、先に知っておくべき制約を整理します。

追加前に知る制約

この設定を試す前に押さえたいのは、BYOKでつないだモデルの主戦場はチャットと補助タスクだという点です。Copilotが持つ体験すべてを、そのまま自前モデルへ載せ替える仕組みだと思って入ると、期待値がずれやすくなります。

もう1つ大事なのは、モデルの互換性だけでなく、利用する環境の条件も影響することです。個人でVS Code上に追加する話と、組織で管理ポリシーの下にBYOKを許可する話は別レイヤーなので、ここを混ぜると手順だけ合っていても使えないことがあります。

以下の3つは、設定画面を開く前に確認しておくと詰まりにくいポイントです。自分が欲しいのは「チャットに応答できること」なのか、「エージェントでツールを使わせたいこと」なのか、あるいは「会社の管理下でも使えること」なのかを分けて考えると整理しやすくなります。

① 使える範囲を確認する

執筆時点では、BYOKで追加したモデルはチャットでの会話とutility tasksに使う前提で案内されています。たとえば、Copilot Chatで質問したり、補助的な内部処理に別モデルを割り当てたりする使い方です。

一方で、semantic searchやinline suggestionsのような機能は同じ前提ではありません。つまり、「会話モデルは自前endpointに切り替えられたのに、補完の挙動まで全部変わると思っていた」というズレが起こりやすいです。

迷ったら次の見方で切り分けると分かりやすくなります。

② tool callingを確認する

モデルをつなげるだけなら動いて見えても、エージェントとしてツールを呼び出したいならtool calling対応が前提です。VS Codeの案内でも、エージェントで使うモデルはその条件を満たしている必要があると整理されています。

ここでいうtool callingは、モデルがただ文章を返すだけでなく、外部ツールを使う判断を返せるかどうかです。たとえば、チャット応答はできるローカルモデルでも、ツール呼び出しの形式に対応していなければ、エージェント用途では期待どおりに使えません。

実務では、最初に「チャットだけ試す」のか「エージェントまで使う」のかを分けて検証すると安全です。チャット用としては十分でも、エージェント用としては不足するケースがあるので、両方を同じ意味で“対応”と考えないほうが失敗しにくくなります。

③ 組織ポリシーを確認する

個人利用ではVS Code上の設定が主役ですが、Copilot BusinessやEnterpriseでは管理者ポリシーが有効化されているかも確認が必要です。設定画面が見えていても、組織側でBring Your Own Language Model Key in VS Codeポリシーが許可されていないと、実際には追加できないことがあります。

もう1つややこしいのが、GitHub Docsにある“組織管理のBYOK”と、VS Codeで自分でCustom Endpoint providerを追加する経路は同じ話ではないことです。前者は組織単位でprovider keyを扱う話、後者はエディタ上で対応endpointを登録する話なので、設定主体が違います。

会社PCで試すときは、まず管理者ポリシーの有無を確認し、そのうえで自分のendpoint登録手順に進むのが安全です。ここを逆にすると、URLやAPI種別が合っていても動かない理由を見失いやすくなります。

VS Codeで追加する手順

実際の流れはシンプルで、追加画面を開く→endpointを登録する→補助モデルも整えるの3段階です。ここを順番に進めれば、Copilot Chatの中で自前モデルを呼べるところまで持っていけます。

ポイントは、URLだけ入れて終わりではないことです。どのAPI形式で話すか、認証はどう渡すか、utility tasksに別モデルを使うかまで揃えておくと、あとで挙動の差を追いやすくなります。

次の3つを上から進めれば、最初のセットアップとしては十分です。途中で迷ったら、まずはChat Completionsなど既に動作確認しやすい形式から始め、あとでResponsesやMessagesに広げると失敗しにくくなります。

① モデル追加画面を開く

最初の入口は、Copilot Chatまわりのモデル追加画面です。執筆時点ではCustom Endpoint providerがStableでも案内されているため、Insiders前提の裏技として扱う必要はありません。

ここで大事なのは、最初から設定ファイルを手で書こうとしないことです。旧設定の情報を先に読むとJSON編集から始めたくなりますが、今はUIからprovider追加の流れに乗ったほうが、必要な項目を取りこぼしにくくなります。

もし画面に目的の選択肢が見当たらないなら、VS Code側のバージョンや組織ポリシーを先に疑うほうが近道です。入力値の正しさを調べる前に、機能が使える前提を確認してください。

② endpointと認証を登録する

登録時に見る項目は、provider名、base URL、APIタイプ、認証方法の4つです。ここが曖昧なまま進むと、モデルが出ないのか、認証が通らないのか、API形式が合わないのかを切り分けにくくなります。

目安としては次の順で埋めると分かりやすいです。

1. 接続先の名前を決める
2. Base URLを入れる
3. Chat Completions / Responses / Messagesのどれで話すか選ぶ
4. APIキーなどの認証方式を設定する

無認証BYOKやair-gapped運用を考えている場合も、発想は同じです。違うのは“鍵をどこから受け取るか”と“接続先が隔離環境内にあるか”で、登録の流れ自体は大きく変わりません。まずは接続方式を整理し、そのあとでネットワークや認証の制約を詰めると迷いにくくなります。

③ utility modelも整える

会話用のモデルがつながっても、補助的な処理に使うutility modelが別のままだと、期待した挙動にならない場面があります。執筆時点の設定リファレンスでは、chat.utilityModelやchat.utilitySmallModelといった項目も案内されています。

ここは「全部同じモデルにする」か「軽い処理だけ別モデルにする」かを分けて考えると整理しやすいです。たとえば、本文生成は大きいモデル、軽い補助処理は小さいモデルという形にすると、応答体験を崩しにくくなります。

最初は無理に細かく分けず、まず1つのCustom Endpointでチャットが安定するかを見てからutility modelを調整する順番でも十分です。原因切り分けをしやすくするためにも、初期設定では一度に変更しすぎないほうが安全です。

APIタイプをどう選ぶ？

APIタイプ選びで迷ったら、自分のendpointがどの形式を正式に案内しているかを優先して考えるのが基本です。Copilot側が複数形式に対応していても、接続先が得意ではない形式を選ぶと、あとで挙動が不安定になりやすくなります。

考え方としては、互換性の広さを取りたいならChat Completions、新しいOpenAI系の流れに合わせたいならResponses、Anthropic互換の設計に寄せたいならMessages、と覚えると整理しやすいです。

次の3つは優劣ではなく向き不向きの違いです。手元の推論基盤やAPIゲートウェイがどれを前提にしているかを見て、無理のない形式を選んでください。

① Chat Completions向き

Chat Completionsは、既にOpenAI互換として運用しているendpointをつなぎたいときに選びやすい形式です。自前ゲートウェイやローカルサーバーがこの形を前提にしているなら、最初の成功率を上げやすくなります。

メリットは、既存のクライアント実装や検証済みの運用フローを流用しやすいことです。まずつながる状態を作りたい、PoCを早く始めたい、古い互換レイヤーを含めて幅広く試したい、という場面と相性がいいです。

逆に、接続先がResponsesを正式ルートとして案内しているのに、慣れているからという理由だけでChat Completionsを選ぶと、あとで差分を自分で吸収する手間が増えます。互換性の広さは強みですが、公式推奨とずれていないかは確認してください。

② Responses向き

Responsesは、新しいOpenAI系endpointに寄せたいときに候補になります。接続先のドキュメントがResponses APIを前提にしているなら、こちらを選ぶほうが説明どおりに動かしやすいです。

この形式を選ぶ価値は、今後の互換機能や設計の流れに合わせやすいことです。新規に構築する環境で、古い互換レイヤーに引っ張られたくない場合は、最初からResponsesを試すほうが整理しやすい場面があります。

ただし、手元のendpointがChat Completions互換しか明確に案内していないなら、無理にResponsesへ寄せる必要はありません。大事なのは“新しいから選ぶ”ではなく、接続先の正式な案内に合わせることです。

③ Messages向き

Messagesは、Anthropic互換のendpointやMessages形式を前提にしたサーバーを使うときに検討する選択肢です。接続先がこの形式での利用例を出しているなら、無理に別形式へ寄せるより素直に合わせたほうが分かりやすくなります。

この形式を選ぶときに意識したいのは、単に“Anthropic系だから”で決めるのではなく、APIゲートウェイ全体がMessages準拠で組まれているかどうかです。ローカル推論基盤でも、表向きの互換形式が何かで適切な選択は変わります。

もし迷うなら、接続先ドキュメントに最初に出てくるリクエスト例を基準にしてください。Messagesの例が前面に出ているならMessages、そうでなければ他形式を検討する、という順番のほうが判断しやすいです。

旧customOAIModelsとの違い

旧customOAIModelsとのいちばん大きな違いは、今の主役が設定値の差し込みではなく、providerとしての登録導線になったことです。執筆時点の設定リファレンスでも、旧設定はdeprecatedとして扱われています。

実務上の違いをまとめると、次のように見ると分かりやすいです。

既存設定がすぐ壊れると決めつける必要はありませんが、これから新しく試すならCustom Endpoint provider前提で覚えるほうが遠回りしにくいです。古い記事を読むときは、その説明が現行導線なのか移行前提なのかを必ず見分けてください。

Custom EndpointのFAQ

まとめ

GitHub CopilotのCustom Endpoint providerは、Copilot Chatの使い勝手を保ちながら任意endpointやローカルモデルを組み込むための、今の正規導線です。

次にやることは1つで、使いたいendpointがどのAPI形式を正式に案内しているかを確認し、VS CodeのCustom Endpoint providerでまず1モデルだけ登録してみることです。そこでチャットが安定してから、utility modelやエージェント用途へ広げると失敗しにくくなります。