GitHub Copilot CLIのBYOK機能でOllamaのローカルモデルを使ってみた

GitHub Copilot CLIのBYOK機能でOllamaのローカルモデルを使ってみた

2026.04.10

どうも!オペ部の西村祐二です!

2026年4月7日、GitHub Copilot CLIBYOK(Bring Your Own Key)機能が公式ブログで紹介されました。ローカルモデルをCopilot CLIに接続できる機能です。さっそくOllamaを使ってローカルLLMでの動作を試してみました。

BYOKとは

BYOK(Bring Your Own Key)は、GitHubが提供するモデルルーティングの代わりに、ユーザー自身のLLMプロバイダーを接続できる機能です。

対応プロバイダーは以下の通りです。

プロバイダー COPILOT_PROVIDER_TYPE 概要
Azure OpenAI azure Azure上のOpenAIモデル
Anthropic anthropic Claude系モデル
OpenAI互換エンドポイント openai(デフォルト) OpenAI API、Ollama、vLLM、Foundry Local等

BYOKモード時はGitHub認証が不要で、プロバイダーの認証情報だけで利用を開始できます。GitHubにもサインインすると/delegateCopilot coding agentへのタスク委任)やGitHub Code Searchなどの追加機能が使えるようになります。

設定方法の概要はcopilot help providersで確認できます。

$ copilot help providers
Custom Model Providers (BYOK):

  Use your own model provider instead of GitHub Copilot's model routing.
  Set the COPILOT_PROVIDER_BASE_URL environment variable to activate BYOK mode.
  GitHub authentication is not required when using a custom provider.

Environment Variables:

  COPILOT_PROVIDER_BASE_URL          API endpoint URL (required to activate BYOK)
  COPILOT_PROVIDER_TYPE              "openai" (default), "azure", or "anthropic"
  COPILOT_PROVIDER_API_KEY           API key (optional for local providers like Ollama)
  COPILOT_PROVIDER_BEARER_TOKEN      Bearer token (takes precedence over API key)
  COPILOT_PROVIDER_WIRE_API          "completions" (default) or "responses"
  COPILOT_PROVIDER_AZURE_API_VERSION Azure API version (default: versionless v1)
...

モデルの要件として、以下が必須とされています。

  • Tool Calling(function calling)に対応していること
  • ストリーミングに対応していること
  • 128k以上のコンテキストウィンドウが推奨

試してみる

環境

  • macOS(Apple M2 Max / 32GB)
  • Ollama 0.20.3
  • GitHub Copilot CLI 1.0.21

Ollamaには以下のモデルがインストール済みです。

$ ollama list
NAME               SIZE
gemma4:latest      9.6 GB
gpt-oss:20b        13 GB
gemma3:latest      3.3 GB
qwen3:latest       5.2 GB
llama3.2:latest    2.0 GB

1. Ollamaでの基本接続

OllamaでCopilot CLIを使うには、環境変数を2つ設定するだけで接続できます。

export COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1
export COPILOT_MODEL=gemma4

試しに簡単な質問を投げてみます。

$ COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1 \
  COPILOT_MODEL=gemma4 \
  copilot -p "Hello, what model are you?"
I am a large language model, trained by Google.

API time spent:         21s
Total session time:     24s
Total code changes:     +0 -0
Breakdown by AI model:
 gemma4                   4.1k in, 12 out, 0 cached

gemma4からの応答が確認できました。セッション統計にモデル名gemma4が表示され、Ollamaのローカルモデルが使われていることが分かります。APIキーの設定なしで接続できています。

2. オフラインモード

COPILOT_OFFLINE=trueを設定すると、GitHubサーバーへの通信を完全に遮断できます。

$ COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1 \
  COPILOT_MODEL=gemma4 \
  COPILOT_OFFLINE=true \
  copilot -p "What is 2+2? Answer in one word."
Four

API time spent:         11s
Total session time:     11s
Total code changes:     +0 -0
Breakdown by AI model:
 gemma4                   4.1k in, 2 out, 0 cached

オフラインモードでも問題なく応答が返ってきました。テレメトリも無効になるため、コードのコンテキストが外部に送信されることはありません。ローカルモデルとの組み合わせで、外部通信なしで閉じた開発環境を構築できます。

3. Tool Calling(エージェント機能)の検証

Copilot CLIのエージェント機能(ファイルの作成・編集、シェルコマンドの実行など)にはモデルのTool Calling対応が必須です。実際にファイル作成を指示して、各モデルの挙動を確認しました。

$ COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1 \
  COPILOT_MODEL=gemma4 \
  copilot -p "Create a file called hello.py that prints 'Hello from Ollama'" --yolo
I can write the Python code for you, but I cannot directly create files on
your local system.

Here is the Python code you can copy and paste into a file named `hello.py`:

print("Hello from Ollama")

API time spent:         22s
Total session time:     25s
Total code changes:     +0 -0
Breakdown by AI model:
 gemma4                   4.1k in, 186 out, 0 cached

ファイルは作成されず、テキストでコード例を返すだけにとどまりました(Total code changes: +0 -0)。Tool Callingが発動していればCopilot CLIがファイルを直接作成するはずですが、gemma4はツールを呼び出していません。

他のモデルでも同様に試した結果を一覧にまとめます。

モデル 接続 テキスト応答 Tool Calling 備考
gemma4(12B) OK OK NG 応答は高速(12秒)だがツールを呼び出さない
qwen3(8B) OK OK NG ツールの存在は認識するが、実際には呼び出さない
llama3.2(3B) OK OK NG 同上。テキストでコード例を返すのみ
gemma3(4B) NG - - does not support toolsエラーで起動不可
gpt-oss:20b OK 不安定 NG 出力が不安定でツール呼び出しも発生せず

gemma3は明確に「tools非対応」のエラーが返り、起動自体ができませんでした。

400 registry.ollama.ai/library/gemma3:latest does not support tools

gemma4はgemma3と異なりtools非対応エラーは出ず、テキスト応答は高速に返ってきます。ただしファイル作成の指示に対してはTool Callingが発動せず、テキストでコード例と手順を提示するだけにとどまりました。

qwen3とllama3.2も同様に、ツール定義は受け取っているものの、実際の関数呼び出しまでは至らない状態です。

Tool Callingが動作しない原因を調べてみる

gemma4自体はTool Callingに対応しているはずなので、原因を切り分けてみました。

検証1: Ollama APIを直接呼び出す

Copilot CLIを介さず、OllamaのAPIにシンプルなツール定義を渡してみます。

$ curl -s http://localhost:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gemma4",
    "messages": [{"role": "user", "content": "Create a file called hello.py"}],
    "tools": [{
      "type": "function",
      "function": {
        "name": "write_file",
        "description": "Write content to a file",
        "parameters": {
          "type": "object",
          "properties": {
            "path": {"type": "string"},
            "content": {"type": "string"}
          },
          "required": ["path", "content"]
        }
      }
    }]
  }'
{
  "tool_calls": [{
    "function": {
      "name": "write_file",
      "arguments": "{\"content\":\"print(\\\"Hello, World!\\\")\",\"path\":\"hello.py\"}"
    }
  }]
}

gemma4単体ではwrite_fileツールを正しく呼び出せています。ツールを10個に増やしても同様に成功しました。

gemma4単体では問題ないことが分かったので、次にCopilot CLIがモデルにどのようなツール定義を渡しているかを確認してみました。プロキシを挟んでリクエストを覗いてみたところ、38個のツールが定義されていました。主なものは以下の通りです。

=== TOOLS (38 total) ===
  - bash: Runs a Bash command in an interactive Bash session.
  - write_bash: Sends input to the specified command or Bash session.
  - read_bash: Reads output from a Bash command.
  - view: Tool for viewing files and directories.
  - create: Tool for creating new files.
  - edit: Tool for making string replacements in files.
  - grep: Fast and precise code search using ripgrep.
  - glob: Fast file pattern matching using glob patterns.
  - web_fetch: Fetches a URL from the internet.
  - skill: Execute a skill within the main conversation.
  - sql: Execute SQL queries against SQLite databases.
  - task: Launch specialized agents in separate context windows.
  - github-mcp-server-*: GitHub MCP Server tools (issue, PR, search, etc.) x20+
  ...

ファイル作成ツールの正式名はcreateでした。これを踏まえて追加の検証を行います。

検証2: 正しいツール名createを指定して指示する

Copilot CLI経由で、正しいツール名createを明示的に指定してみます。

$ COPILOT_PROVIDER_BASE_URL=http://localhost:11434/v1 \
  COPILOT_MODEL=gemma4 \
  copilot -p "You have a tool named 'create'. Call it to create hello.py." --yolo
I cannot use the tool `create` because it is not provided to me. I can only
use the tools that have been explicitly defined in our current conversation.

API time spent:         22s
Total session time:     26s
Total code changes:     +0 -0
Breakdown by AI model:
 gemma4                   4.1k in, 33 out, 0 cached

Tool Callingは発動せず、「createツールは提供されていない」とテキストで回答されました。

検証3: MUST付きでツール呼び出しを強制する

ツール名を明示したうえで、MUSTを付けてツール呼び出しを強制してみます。

$ copilot -p "You MUST call the tool named 'create' with file_path='hello.py'. Only make a tool call to 'create'." --yolo
✗ file_write hello.py
  └ Tool 'file_write' does not exist.

createと指定しましたが、file_writeという別のツール名で呼び出してしまいました。

存在しないツール名write_fileを指定した場合も試してみます。

$ copilot -p "You MUST call the tool named 'write_file' with path='hello.py'. Only make a tool call." --yolo
✗ write_file hello.py
  └ Tool 'write_file' does not exist.

こちらはプロンプトで指定したwrite_fileをそのまま呼び出しています。今回のケースだとTool Calling機能を利用することは難しそうです。

原因のまとめ

検証 結果
Ollama API直接(ツール1〜10個) Tool Calling成功
Copilot CLI経由(ツール38個) Tool Calling不発動
Copilot CLI経由 + 正しいツール名createを指示 ツール定義を認識できず不発動
Copilot CLI経由 + 正しいツール名createで強制指示 Tool Call発動するが、file_writeで呼び出す
Copilot CLI経由 + 存在しないwrite_fileで強制指示 write_fileをそのまま呼び出す(定義を参照していない)

gemma4のTool Calling機能自体は正常に動作することが確認できました。現状はCopilot CLIが38個のツールを含む複雑なプロンプトを前提としているため、12Bクラスのモデルではツール定義の解釈がうまくいかない可能性があります。BYOK/ローカルモデル対応はリリースされたばかりの機能なので、今後のCopilot CLIのアップデートでローカルモデル向けの最適化が進むことに期待したいところです。

試してみた感想

テキスト応答は実用的に動く

Ollamaのローカルモデルでもテキストベースの質問応答は問題なく動作しました。環境変数2つの設定だけで接続でき、セットアップのハードルは低いです。

エージェント機能はローカルモデル向けの最適化待ち

今回試したモデルではCopilot CLI上でのTool Callingは動作しませんでしたが、gemma4はOllama APIを直接呼び出せばTool Callingに成功しています。Copilot CLI側でローカルモデル向けの最適化(渡すツール数の調整やプロンプトの軽量化など)が進めば、エージェント機能も動作するようになりそうです。copilot help providersの公式例ではdeepseek-coder-v2:16bが使われており、コーディング特化モデルとの組み合わせも気になるところです。

オフラインモードはセキュリティ要件を満たす場面で有用

COPILOT_OFFLINE=trueでGitHubへの通信を完全に遮断できるため、機密性の高いコードベースを扱う場面で有用です。ローカルモデルとの組み合わせで、データが外部に一切出ない環境を構築できます。

まとめ

GitHub Copilot CLIのBYOK機能を使って、Ollamaのローカルモデルとの接続を試しました。

  • セットアップ: 環境変数2つ(COPILOT_PROVIDER_BASE_URLCOPILOT_MODEL)で接続可能。APIキー不要
  • テキスト応答: 問題なく動作
  • エージェント機能: ローカルモデル単体ではTool Calling可能だが、Copilot CLI経由では未動作。今後の最適化に期待
  • オフラインモード: COPILOT_OFFLINE=trueでGitHub通信を完全遮断可能

BYOK機能はOllama以外にもAzure OpenAI、Anthropic、OpenAI互換エンドポイントに対応しています。ローカルモデルの性能向上とCopilot CLIの最適化が進めば、完全ローカル環境でのAIエージェント開発も現実的になりそうです。

誰かの参考になれば幸いです。


参考リンク:

この記事をシェアする

関連記事