GitHub Copilot CLIは1.0.94-0以降、/modelの一覧に手元で起動中のOllamaのモデルを並べ、その場で追加できるようになりました。この記事では、Copilot CLIとOllamaをつなぐ3つの経路（/modelでの追加、ollama launch copilot、環境変数）をコマンド付きで示します。あわせて、GitHubとOllamaの公式docsでベースURLの書き方が食い違う点の切り分け、既定4kのコンテキスト長の引き上げ、ローカルモデルを選んでもGitHubへの通信は止まらない点を整理しました。最後に、ローカルモデルを採用する条件と見送る場面を言い切ります。
まとめ｜Copilot CLIとOllamaをつなぐ3経路と、送信先を止める設定の要点
手早く試すなら、Ollamaを起動してモデルを取得し、Copilot CLIの/modelで検出されたモデルを追加するのが最短です。シェル設定やCIで固定したい場合は、COPILOT_PROVIDER_BASE_URLとCOPILOT_MODELを環境変数で渡します。
見落としやすいのは2点です。1つはOllamaの既定コンテキスト長で、VRAMが24GiB未満の環境では4kのまま動き、エージェント用途には足りません。もう1つは送信先で、ローカルモデルを選んでもオフラインモードは有効にならず、GitHubへの通信を止めるにはCOPILOT_OFFLINE=trueの明示が必要です。モデル名に:cloudが付くものは推論自体がOllamaのクラウドで行われます。
採用を勧めるのは、コードを社外に出せない案件と、ネットワークを切った検証環境の2つです。VRAMが24GiB未満でAutopilotに長い修正を任せたい場合は、ローカルモデルに切り替えず、Copilotのクラウドモデルを使うほうが作業は進みます。
Copilot CLIのOllama対応で10月に変わった点と、接続の仕組みの全体像
1.0.94-0以降の/modelが起動中のOllamaを検出して一覧に並べる動作
2026年10月7日のGitHub Changelogによると、Copilot CLI 1.0.94-0以降では/modelが起動中のOllamaから対応モデルを検出し、設定済みのモデルやCopilotのクラウドモデルと同じ一覧に表示します。検出されたモデルは自動では追加されません。選んだうえでプロバイダーとエンドポイントを確認し、「Add and use for this session」か「Add without switching」を押すと、CLIを再起動せずに使えます。
この機能はOllama本体もモデルもダウンロードしません。Ollamaの導入とモデルの取得は事前に済ませておく前提です。接続に失敗した場合は、理由が選択画面に表示されます。
GitHubのreleasesでは、1.0.94の安定版は2026年10月8日、2026年10月16日時点の最新安定版は1.0.98系です。1.0.96ではモデルIDが大文字小文字を区別しなくなり、正規のIDで保存されるようになりました。
BYOK接続：OpenAI互換APIとCOPILOT_PROVIDER系変数の設定
Ollama対応は単独の機能ではなく、自前のLLMプロバイダーを使うBYOK（Bring Your Own Key）の上に乗っています。GitHub DocsのBYOKの解説では、プロバイダー種別はopenai（既定）・azure・anthropicの3つで、OllamaはvLLMやFoundry Localと並んでopenai互換エンドポイントの扱いです。
| 環境変数 | 必須 | Ollamaでの設定 |
|---|---|---|
| COPILOT_PROVIDER_BASE_URL | 必須 | Ollamaの接続先URL |
| COPILOT_MODEL | 必須 | 取得済みのモデル名 |
| COPILOT_PROVIDER_TYPE | 任意 | 省略でopenai扱い |
| COPILOT_PROVIDER_API_KEY | 任意 | ローカルなら不要 |
| COPILOT_PROVIDER_WIRE_API | 任意 | 通信するAPIの種類 |
| 入力トークン上限の変数 | 任意 | 入力トークンの上限 |
表の「入力トークン上限の変数」はCOPILOT_PROVIDER_MAX_PROMPT_TOKENSです。表の6つ以外に、モデルの能力判定に使うCOPILOT_PROVIDER_MODEL_ID、出力上限のCOPILOT_PROVIDER_MAX_OUTPUT_TOKENSなどもあります。/modelで追加する経路も、内部ではこのプロバイダー設定を作る操作だと捉えると、後の切り分けが楽になります。
ローカルモデルを選んでもテレメトリは止まらない、COPILOT_OFFLINEとの関係
Changelogは、ローカルモデルを選んでもオフラインモードは有効にならず、GitHubのテレメトリも止まらないと明記しています。オフラインモードはCOPILOT_OFFLINE=trueで明示的に有効にする設計です。
逆向きの注意もあります。GitHub Docsによると、オフラインモードで完全なネットワーク隔離になるのはプロバイダーもローカルか同じ隔離環境にある場合だけです。COPILOT_PROVIDER_BASE_URLがリモートを指していれば、プロンプトとコードのコンテキストはそのプロバイダーへ送られます。「ローカルモデルを選んだから社外に何も出ない」とは言えません。
検証環境の準備：Ollamaの導入、モデル取得、コンテキスト長の設定手順
ツール呼び出しとストリーミングに対応したモデルを選ぶ基準と推奨例
Copilot CLIはファイルの読み書きやコマンド実行をツール呼び出しで行うため、GitHub Docsはツール呼び出し（function calling）とストリーミングの両方への対応を必須としています。どちらかが欠けるとエラーになります。コンテキストウィンドウは128kトークン以上が推奨です。
OllamaのCopilot CLI連携docsは、推奨モデルとしてローカルのqwen3.5と、クラウドのglm-5.3:cloud・kimi-k3:cloudを挙げています。手元で完結させたいなら選択肢はqwen3.5系になります。
ollama pull qwen3.5
ollama list取得後はollama listでモデル名とサイズを確かめます。モデル名はこの一覧の表記をそのままCOPILOT_MODELに渡します。
VRAM24GiB未満は既定4kのため、64000トークン以上へ引き上げる設定
Ollamaのコンテキスト長のdocsによると、既定値はVRAMで決まり、24GiB未満は4k、24〜48GiBは32k、48GiB以上は256kです。同じページは、エージェントやコーディングツールには64000トークン以上を設定するよう求めています。Ollamaの連携docsも64k以上を推奨しています。
OLLAMA_CONTEXT_LENGTH=64000 ollama serve
# 別のターミナルで割り当てを確認する
ollama psollama psのCONTEXT列が設定値になっているか、PROCESSOR列が100% GPUかを見ます。CPUへの退避が出ている場合は応答が大きく遅くなるため、モデルを小さくするかコンテキスト長を下げて調整します。コンテキスト長を上げるほど必要なメモリも増える点に注意が必要です。
Copilot CLIを4つの方法で導入し、1.0.94以降の版かを確認する手順
Ollamaの連携docsが示すインストール方法は、Homebrew、npm、インストールスクリプト、wingetの4つです。
# macOS
brew install copilot-cli
# Node.js環境
npm install -g @github/copilot
# Windows
winget install GitHub.Copilotnpmで入れた場合は、npm ls -g @github/copilotで入っている版を確認できます。/modelでの検出を使うには1.0.94-0以降が必要なので、それより古ければ更新してから次の手順に進みます。
Copilot CLIからOllamaへ接続する3つの方法を、手順とコマンドで試す
方法1：/modelで検出されたモデルを選び、セッションに追加する操作
Ollamaを起動した状態でCopilot CLIを立ち上げ、/modelを開くと、検出されたローカルモデルが一覧に入ります。
ollama serve（またはOllamaアプリ）でOllamaを起動しておく- リポジトリのディレクトリで
copilotを起動する /modelを入力し、検出されたOllamaのモデルを選ぶ- プロバイダーとエンドポイントを確認し、「Add and use for this session」を選ぶ
今のセッションのモデルを変えずに登録だけしたい場合は「Add without switching」を選びます。一覧に出てこないときは、Ollamaが起動していないか、モデルが対応条件を満たしていない可能性があります。
方法2：ollama launch copilotで、変数の設定ごと起動する手早い経路
Ollama側には、Copilot CLIの接続設定をまとめて行う起動コマンドがあります。連携docsでは次の形です。
ollama launch copilot
ollama launch copilot --model qwen3.5
# 対話なしで1回だけ実行する
ollama launch copilot --model qwen3.5 --yes -- -p "how does this repository work?"--yesを付けるとモデル選択の画面を飛ばしてモデルを自動で取得するため、--modelの指定が必須です。--より後ろの引数はそのままCopilot CLIに渡ります。同じ仕組みでCodexを起動する手順はOllamaでCodexをローカルLLM実行する方法で解説しているので、エージェントを併用するチームは比べてみてください。
方法3：環境変数を書いて起動、シェル設定やCI向けに固定する書き方
接続先を固定したい場合は、環境変数を書いてからcopilotを起動します。Ollamaの連携docsの手動設定は次のとおりです。
export COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1
export COPILOT_PROVIDER_API_KEY=
export COPILOT_PROVIDER_WIRE_API=responses
export COPILOT_MODEL=qwen3.5
copilotOllamaを別のマシンで動かす場合は、localhostをそのホスト名に置き換えます。ただし社内ネットワークを経由する時点で、プロンプトとコードの送信先は、そのOllamaを動かしているマシンです。BYOKの設定はGitHub Copilot CLIのAutopilotなどの動作モードと組み合わせて使えます。
つながらないときの切り分け：/v1の有無とWIRE_APIで公式docsが割れる点
公式docsの接続例の差：/v1の有無とresponses指定の比較
2026年10月16日時点で、2つの公式docsはOllamaの接続例が一致していません。GitHub DocsのBYOK解説はhttp://localhost:11434とCOPILOT_MODELの2行だけを示し、Ollamaの連携docsは/v1を付けたうえでCOPILOT_PROVIDER_WIRE_API=responsesまで指定しています。
OllamaのOpenAI互換APIのdocsを見ると、互換エンドポイントは/v1/chat/completionsや/v1/responsesなど/v1配下に並んでいます。/v1付きから始めるのが筋です。なお/v1/responsesはステートレスな形式だけの対応で、previous_response_idは使えません。responses指定でエラーが出る場合は、WIRE_APIを外して既定の方式に戻して比べます。既定値はGitHub Docsの表に書かれていないため、copilot help providersの出力で確かめてください。
curlで/v1/modelsとツール付きリクエストを送り、CLIより先に疎通を確かめる
Copilot CLIのエラーだけで原因を探すより、Ollamaの互換APIを直接叩くほうが早く切り分けられます。
# 1. 互換APIからモデル名が返るか
curl http://localhost:11434/v1/models
# 2. ツール定義付きのリクエストが通るか
curl http://localhost:11434/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{"model":"qwen3.5","messages":[{"role":"user","content":"今の時刻を調べて"}],
"tools":[{"type":"function","function":{"name":"get_time","description":"現在時刻を返す",
"parameters":{"type":"object","properties":{}}}}]}'1で応答が無ければOllamaの起動かURLの問題で、Copilot CLI側の設定を触っても直りません。2で応答にtool_callsが含まれていれば、そのモデルはツール呼び出しを返せます。2の応答で使うモデル名は、1で返ったidの表記に合わせてください。
does not support toolsと文章だけ返すモデルの失敗判別
失敗には2つの型があります。1つはモデルがツール定義を受け付けず、Ollamaがdoes not support toolsを返す型です。この場合はエラー文にモデル名と理由が出るため、原因はすぐ分かります。
厄介なのはもう1つの型です。エラーは出ないのに、ファイルを作る指示に対してコードを文章で返すだけで、実際の書き込みが起きません。ツール定義を受け付けても、呼び出しを返す精度が足りないモデルで起きます。前の手順のcurlでtool_callsが返らないモデルは、Copilot CLIでも同じ挙動になると見て、モデルを替えるのが近道です。コンテキスト長が4kのままだと、ツール定義と会話が入りきらない状態で動くことになるため、モデルを替える前にollama psで割り当てを確認します。
社外にコードを出さない構成：オフラインモードと:cloudモデルの落とし穴
COPILOT_OFFLINE=trueを付けた、手元で完結する構成の起動スクリプト例
プロンプトもコードも手元から出したくない場合は、ローカルのOllamaを指したうえでオフラインモードを明示します。次のスクリプトは、Ollamaの疎通を確かめてから起動する例です。
#!/usr/bin/env bash
set -euo pipefail
export COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1
export COPILOT_PROVIDER_API_KEY=
export COPILOT_MODEL=qwen3.5
export COPILOT_OFFLINE=true
# Ollamaが応答しなければ起動しない
curl -sf http://localhost:11434/v1/models > /dev/null || { echo "Ollama not running"; exit 1; }
case "$COPILOT_MODEL" in
*:cloud) echo "cloud model is not allowed"; exit 1 ;;
esac
exec copilot "$@"モデル名が:cloudで終わる場合に止める分岐を入れたのは、次のh3で述べる送信先の問題を防ぐためです。エージェントが実行するコマンド自体も制限したい場合は、GitHub Copilotのサンドボックスの設定と組み合わせます。
:cloudタグのモデルはOllamaのクラウドで推論される、選ぶ前の確認点
Ollamaの連携docsの例にはkimi-k2.5:cloudやglm-5:cloudが並びます。OllamaのCloudのdocsによると、これらはダウンロード不要でOllamaのクラウド上で動くモデルで、利用にはサインインが必要です。プロンプトと応答はOllama側で処理され、モデルの学習には使わないと説明されています。
つまりollama launch copilotや/modelの画面から選べても、:cloud付きは「ローカルLLM」ではありません。社外に出せないコードを扱うなら、モデル名の末尾を見て除外する運用にします。Ollama本体の版はOllamaのreleasesで確認でき、2026年10月時点では0.40系です。
Copilot CLIでローカルOllamaを採用する条件と、クラウドモデルに残す場面
採用する場面：コードを社外に出せない案件と、オフラインの検証環境の2つ
ローカルのOllamaに切り替える価値がはっきりあるのは2つの場面です。1つは、契約や社内規程でソースコードを外部のAIサービスへ送れない案件です。COPILOT_OFFLINE=trueとローカルのOllamaを組み合わせれば、プロンプトとコードが手元のマシンから出ない構成を作れます。
もう1つは、ネットワークを切った検証環境や、外部への通信が許可されていない開発端末です。この場合はクラウドモデルという選択肢自体がありません。ローカルLLMの基盤選びや必要スペックの考え方はローカルLLMとは、同時に複数人で使う推論サーバーを立てるならvLLMとはが参考になります。
見送る場面：VRAM24GiB未満のまま、Autopilotに長い修正を任せたいとき
VRAMが24GiB未満の端末で、複数ファイルにまたがる修正をAutopilotに任せたい場合は、ローカルモデルを採用しません。既定のコンテキスト長は4kで、64000まで上げるとメモリが不足しやすく、CPUへの退避で応答も遅くなります。GitHub Docsが推奨する128kにも届きません。この条件では、Copilotのクラウドモデルのまま使い、送信してよいコードの範囲を組織のポリシーで決めるほうが現実的です。
もう1つの見送り条件は、モデルの見極めに時間を割けないチームです。ツール呼び出しの精度はモデルごとに差があり、エラーを出さずに書き込みをしない失敗は気付きにくい性質があります。社内の閉じた環境でコーディングエージェントとローカルLLMを組み合わせる基盤を設計する場合は、生成AI開発・AI受託開発でモデル選定から推論基盤の構築まで相談を受けています。
よくある質問
Copilot CLIとOllamaの組み合わせについて、設定時によく出る疑問をまとめました。
Copilot CLIでOllamaを使うと、Copilotの契約は不要になりますか？
GitHub DocsのBYOKの解説は、前提条件としてCopilot CLIの導入と、プロバイダーのAPIキーまたはローカルで動くモデルを挙げています。ただし契約や課金との関係は同じページに書かれていないため、この記事では断定しません。組織で使う場合は、Enterprise向けのカスタムモデル設定の案内と、自社の契約条件をあわせて確認してください。
/modelの一覧にOllamaのモデルが出てこないのはなぜですか？
確認する順番は3つです。まずCopilot CLIの版が1.0.94-0以降か、次にOllamaが起動していてollama listにモデルがあるかを見ます。最後に、そのモデルがツール呼び出しとストリーミングに対応しているかです。Changelogによると、検出機能はOllamaやモデルをダウンロードしないため、取得していないモデルは一覧に出ません。
COPILOT_PROVIDER_BASE_URLに/v1は付けるべきですか？
2026年10月時点で、GitHub Docsは/v1なし、Ollamaの連携docsは/v1付きの例を載せています。Ollamaの互換APIは/v1配下に公開されているため、/v1付きから試すのが妥当です。つながらない場合は、curlで/v1/modelsが応答するかを先に確かめると、URLの問題かCopilot CLI側の問題かを切り分けられます。
Ollamaをチームの共用サーバーで動かして、各自のCopilot CLIから使えますか？
環境変数のCOPILOT_PROVIDER_BASE_URLをそのサーバーのアドレスに向ければ接続できます。ただしプロンプトとコードの送信先はそのサーバーとなるため、運用前に決めておく事項は、社内ネットワークの通信経路と認証の扱いです。同時に複数人が使う規模なら、Ollamaより同時処理に強い推論サーバーも比較の対象になります。
ローカルモデルとCopilotのクラウドモデルは、作業中に切り替えられますか？
切り替えられます。Changelogによると、検出したモデルは「Add without switching」で登録だけしておけるため、/modelからクラウドモデルとローカルモデルを行き来できます。社外に出せないファイルを扱う間だけローカルモデルにする使い方ができますが、オフラインモードはこの操作では有効にならない点に注意してください。
関連記事
- GitHub Copilot CLIのAutopilotとは｜使い方・止まる条件・料金と導入手順【2026年9月】：Copilot CLIの動作モードと導入手順の全体を扱っています。
- OllamaでCodexをローカルLLM実行する方法｜ollama launch codex・chatgpt（旧codex-app）の設定【2026年10月】：同じOllamaの起動コマンドで別のエージェントを動かす手順です。
- GitHub Copilotのサンドボックスとは？有効化手順と組織で強制する管理設定【2026年10月】：ローカルモデルと組み合わせて、実行するコマンドを制限する設定です。
- Copilot CLIのRubber Duckとは｜クロスモデルレビューの仕組み・対応モデル・導入手順【2026年最新】：複数のモデルを使い分けるCopilot CLIの機能です。
- ローカルLLMとは？クラウド型との違い・必要スペック・Ollamaでの構築手順を解説：ローカルで動かす判断の前提となる概念と必要スペックの解説です。
