GitHub Copilotをローカルで使う方法｜Ollama連携・オフライン化・機能制限を解説

GitHub GitHubが提供するAIモデルだけでなく、OllamaやLM Studioなどで稼働するローカルLLMを、VS CodeやCopilot CLIへ接続できます。

ただし、「ローカルモデルを選択すること」「AIの処理を自社端末で実行すること」「完全なオフライン環境で動作すること」は、それぞれ異なる状態です。モデルをローカルへ切り替えても、GitHub認証、テレメトリ、拡張機能、MCPサーバーなどが外部通信を続ける可能性があります。

また、VS CodeのBYOKでローカルモデルを利用できるのは、主にチャットや一部のAgentワークフローです。GitHub Copilotの標準的なインラインコード補完やセマンティック検索まで、ローカルモデルへ置き換えられるわけではありません。

本記事では、GitHub Copilotをローカルで使う仕組み、Ollama・LM Studioとの連携方法、完全オフライン構成、機能制限、必要な環境、企業導入時のセキュリティ設計まで解説します。自社でPoCを実施すべきか判断するために、モデルの実行場所だけでなく、データの送信先や利用できる機能も含めて確認しましょう。

■目次

GitHub Copilotをローカルで使う仕組みと3つの意味
GitHub Copilotをローカルで使う3つの構成
GitHub Copilotのローカル利用と標準Copilot・代替ツールの違い
GitHub Copilotをローカルで使う3つのメリット
GitHub Copilotのローカル利用に必要な環境とモデル選定
GitHub Copilotをローカルで使う設定手順
GitHub Copilotのローカル利用で起きる5つの失敗要因と対策
GitHub Copilotをローカル導入する企業のセキュリティ・運用設計
GitHub Copilotのローカル利用が向く3つの導入シナリオ
GitHub Copilotをローカル導入すべきか判断するチェックリスト
GitHub Copilot ローカルの導入支援は「フリーコンサルタント.jp」へご相談ください
まとめ

GitHub Copilotをローカルで使う仕組みと3つの意味

GitHub Copilotの「ローカル利用」には、ローカルLLM、ローカルエージェント、ローカルサンドボックスという異なる仕組みがあります。

それぞれが制御する対象は、AIモデルの推論先、ファイルやコマンドの操作場所、コマンドの実行範囲です。自社コードがどこへ送信されるかを判断するには、3つを分けて確認する必要があります。

ローカルLLMによるモデル推論

ローカルLLMとは、Ollama、LM Studio、Foundry Local、vLLMなどを利用し、自分のPCまたは社内サーバー上で動かす言語モデルです。

VS Codeでは、BYOK（Bring Your Own Key）機能を利用して、独自のAPIキーやエンドポイントを登録できます。BYOKは名称に「Key」とありますが、外部サービスのAPIキーだけでなく、ローカルPCや社内ネットワーク上のモデルサーバーを接続する用途にも使えます。

ローカルモデルを登録すると、VS Codeのチャット画面にあるモデルピッカーから、GitHub提供モデルと同じように選択できます。GitHubアカウントへサインインせず、Copilotプランを契約していない状態でも、BYOKモデルをチャットに利用できます。

一方で、モデルの推論先がローカルでも、VS Codeや拡張機能を含む端末全体がオフラインになるわけではありません。MCPサーバー、Web検索、GitHub API、外部拡張機能などが別の通信経路を持つ可能性があります。

ローカルエージェントによる端末上の作業

ローカルエージェントは、開発者の端末上でワークスペースを読み込み、ファイル編集、テスト実行、ターミナルコマンドなどを行う仕組みです。

ここで注意したいのは、エージェントの作業場所と、AIモデルの推論場所が一致するとは限らない点です。

例えば、GitHub提供モデルを選択した状態でローカルエージェントを使う場合、ファイル編集やコマンド実行は開発者のPCで行われますが、モデル推論はGitHub側またはモデル提供事業者のインフラで実行されます。

Ollamaなどのローカルモデルを選択すれば、モデル推論とツール操作の両方を自社環境へ寄せられます。ただし、利用するツールや拡張機能が外部通信する場合は、その通信経路を別途確認しなければなりません。

「ファイルがローカルに保存されている」ことと、「ファイル内容が外部へ送信されない」ことは同じではありません。

ローカルサンドボックスによる実行環境の分離

ローカルサンドボックスは、Copilotが実行するコマンドやファイル操作を、制限された環境に隔離する機能です。AIモデル自体をローカルへ移す機能ではありません。

Copilot CLIのローカルサンドボックスでは、ファイルシステム、ネットワーク、システム機能へのアクセス範囲を制限できます。これにより、Agentが意図しないファイルを変更したり、許可されていない通信先へアクセスしたりするリスクを抑えられます。

ただし、ローカルサンドボックス内でコマンドを実行していても、GitHub提供モデルを選択していれば、モデル推論はクラウド側で行われます。

企業のセキュリティ設計では、次の4項目を分けて整理することが重要です。

モデルの推論先
コマンドの実行先
ファイルの保存先
ネットワークの許可範囲

GitHub Copilotをローカルで使う3つの構成

GitHub Copilotの操作性を維持しながらローカルモデルを利用する方法は、主に次の3つです。

VS Codeとローカルモデルの接続
Copilot CLIとローカルモデルの接続
GitHub Copilotアプリとローカルモデルの接続

GUIでのチャットを重視する場合、閉域網でのターミナル操作を重視する場合、複数のAgentセッションを管理する場合で、適した構成が異なります。

VS Codeとローカルモデルを接続する構成

VS Codeでは、「Chat: Manage Language Models」からモデルプロバイダーを追加し、チャット画面のモデルピッカーでローカルモデルを選択できます。

Ollamaやローカルモデル対応の拡張機能を追加すれば、既存のVS Code Chatの画面を維持したまま、モデルの推論先を開発端末や社内サーバーへ変更できます。

ローカルモデルがツール呼び出しに対応している場合は、ファイル参照、コード編集、ターミナル操作などを伴うAgentワークフローにも利用できます。

ただし、VS CodeのBYOKが適用されるのは、主にチャットとユーティリティタスクです。標準のインラインコード補完、セマンティック検索、埋め込みモデルを利用する機能には適用されません。

GitHubアカウントにサインインしない場合は、タイトル生成や意図判定などに使われるユーティリティモデルも、次の設定でローカルモデルへ変更します。

chat.utilityModel
chat.utilitySmallModel

2026年7月時点では、VS Codeに内蔵されていたOllamaプロバイダーは非推奨です。新規構築では、Ollama公式のVS Code拡張機能など、現在案内されている接続方法を選択します。

機能	ローカルBYOKモデル	補足
チャット	利用可能	モデルピッカーから選択
コード編集	利用可能	モデル能力に依存
Agentワークフロー	条件付きで利用可能	ツール呼び出し対応が必要
タイトル生成・意図判定	利用可能	ユーティリティモデルの設定が必要
標準インライン補完	利用不可	GitHub Copilotサービスが必要
セマンティック検索	利用不可	GitHubアカウントとサービス接続が必要
埋め込み依存機能	利用不可	BYOKの対象外

Copilot CLIとローカルモデルを接続する構成

Copilot CLIでは、環境変数を設定して、Ollama、vLLM、Foundry LocalなどのOpenAI互換エンドポイントへ接続できます。

主に設定する環境変数は次のとおりです。

export COPILOT_PROVIDER_BASE_URL=http://localhost:11434
export COPILOT_MODEL=使用するモデルID

認証を必要としないローカルOllamaの場合、COPILOT_PROVIDER_API_KEYは省略できます。また、BYOKを利用する場合はGitHubアカウントによる認証も必須ではありません。

完全な閉域構成を目指す場合は、次の環境変数を追加します。

export COPILOT_OFFLINE=true

COPILOT_OFFLINE=trueを設定すると、Copilot CLIはGitHubサーバーへ接続せず、GitHub認証を実行しません。テレメトリも無効になります。

ただし、接続先として外部のAPIやインターネット上のモデルサーバーを指定している場合、プロンプトやコードはその接続先へ送信されます。完全なエアギャップ構成になるのは、モデルプロバイダーも同じ閉域環境内にある場合だけです。

GitHub認証を行わない構成では、次のホスト型機能を利用できません。

/delegate
GitHub MCPサーバー
GitHubコード検索

GitHub Copilotアプリとローカルモデルを接続する構成

GitHub Copilotアプリは、複数のAgentセッションをGUI上で管理できるデスクトップアプリです。2026年6月にBYOKへ対応し、Ollama、LM Studio、OpenAI互換エンドポイントなどをモデルプロバイダーとして追加できるようになりました。

設定画面でモデルプロバイダーを追加すると、GitHub提供モデルと独自モデルがモデルピッカーに表示されます。セッションごとに異なるモデルを選べるため、定型作業にはローカルモデル、複雑な作業には高性能なクラウドモデルという使い分けが可能です。

登録したAPIキーはOSのキーチェーンに保存され、設定画面から値を読み戻せない仕様です。

複数リポジトリのAgent作業を並列に進めたい場合に向いていますが、完全オフライン要件については、Copilot CLIのオフラインモードと同じ機能ではありません。利用前に認証、通信先、クラウド機能への依存を確認する必要があります。

Copilot Business・Enterpriseで利用する場合、組織またはEnterpriseの管理者がCopilot CLIポリシーを有効にする必要があります。

項目	VS Code	Copilot CLI	Copilotアプリ
主な操作画面	IDE	ターミナル	デスクトップGUI
ローカルモデル	利用可能	利用可能	利用可能
完全オフライン	条件付き	構成しやすい	要個別確認
Agent操作	利用可能	利用可能	利用可能
インライン補完	BYOK対象外	対象外	対象外
複数セッション管理	限定的	ターミナルごと	適している
主な用途	チャット・編集	閉域網・ターミナル	並列Agent作業

GitHub Copilotのローカル利用と標準Copilot・代替ツールの違い

ローカルモデルをGitHub Copilotへ接続しても、GitHub Copilotの全機能をローカル化できるわけではありません。

インライン補完までローカル化したい場合や、モデルごとの設定を細かく管理したい場合は、ContinueやClineなどの代替ツールも比較対象になります。

GitHub提供モデルとローカルBYOKモデルの機能差

GitHub提供モデルは、GitHub Copilotサービスと連携したインラインコード補完、セマンティック検索、埋め込み処理などを利用できます。

一方、ローカルBYOKモデルの主な対象は、チャット、コード編集、ユーティリティタスク、対応モデルを利用したAgentワークフローです。

標準のインラインコード補完はBYOKの対象外であり、GitHub Copilotの全機能をローカルモデルだけで再現することはできません。

タスクによって、次のように使い分ける方法があります。

機密コードの説明や要約：ローカルモデル
小規模なコード修正：ローカルモデル
インラインコード補完：GitHub提供モデル
大規模な設計や複雑なリファクタリング：承認済みクラウドモデル
閉域網でのコード解析：Copilot CLIとローカルモデル

ローカルモデルの推論では、GitHub提供モデルのリクエスト枠を消費しません。ただし、GPU、共有サーバー、電力、保守工数などのコストが別途発生します。

比較項目	GitHub提供モデル	ローカルBYOKモデル
推論先	GitHubまたはモデル提供基盤	開発端末・社内サーバー
チャット	利用可能	利用可能
Agent	利用可能	モデル能力に依存
インライン補完	利用可能	BYOK対象外
セマンティック検索	利用可能	BYOK対象外
GitHubリクエスト枠	消費する場合がある	原則として消費しない
主なコスト	Copilot契約・リクエスト	GPU・サーバー・保守
オフライン	原則として不可	構成可能

GitHub Copilot・Continue・Clineの違い

GitHub CopilotのBYOKは、VS Code ChatやCopilotのAgent体験を維持しながら、モデルの接続先を変更しやすい点が特徴です。

Continueは、チャット、編集、インライン補完などに別々のモデルを割り当てやすく、Ollamaや社内推論サーバーを含むモデル設定の自由度が高い傾向にあります。GitHub Copilotの標準インライン補完をローカルモデルへ置き換えたい場合の候補です。

Clineは、ファイル操作、コマンド実行、複数ステップの処理など、Agent型のタスクを重視する場合の候補となります。

選定時は、単に「ローカルモデルへ接続できるか」だけでなく、次の観点を比較します。

Copilotの操作性を維持できるか
ローカルモデルによるインライン補完が必要か
Agentによるファイル編集を重視するか
モデル設定を組織で統制できるか
GitHubのコード検索やMCPを利用するか
開発者ごとの設定負担を許容できるか

GitHub CopilotとContinueを併用し、Copilotのクラウド補完とContinueのローカル補完を使い分ける構成も考えられます。ただし、複数のAI拡張機能が同時にコードを読み込むため、通信先とログ保存先をそれぞれ確認する必要があります。

GitHub Copilotをローカルで使う3つのメリット

GitHub Copilotをローカル構成にする主なメリットは、データ境界の管理、閉域網での利用、モデルとコストの選択肢です。

ただし、ローカル化によって安全性やコスト削減が自動的に保証されるわけではありません。データフローや運用費を確認したうえで判断します。

機密コードの送信範囲を自社環境へ限定しやすい点

モデルを開発端末または社内推論サーバーで稼働させれば、プロンプトやコードコンテキストの送信先を自社管理下へ置きやすくなります。

ネットワーク経路、アクセス権、ログ保存期間、モデルの更新方法なども、自社のセキュリティ基準に合わせて設計できます。

ただし、確認対象はモデルだけではありません。

VS CodeやCopilot CLI
OllamaやLM Studio
MCPサーバー
Web検索機能
GitHub API
外部拡張機能
プロキシやログ収集基盤

これらを含むデータフローを確認した場合に限り、送信範囲を自社環境へ限定できたと判断できます。

オフライン・閉域網でも利用できるAI支援

VS Codeでは、GitHubアカウントやCopilotプランを使用せず、ローカルBYOKモデルによるチャットをオフラインで利用できます。

Copilot CLIでは、COPILOT_OFFLINE=trueを設定することで、GitHubサーバーへの接続、GitHub認証、テレメトリを停止できます。

閉域網内に社内推論サーバーを設置すれば、各開発者のPCへ大型モデルを配置せず、複数人でGPUリソースを共有することも可能です。

一方、閉域網ではモデルファイルや拡張機能の更新が難しくなります。導入時には、次の運用手順も決めておく必要があります。

モデルファイルの持ち込み
脆弱性情報の確認
拡張機能の更新
依存パッケージの更新
モデルバージョンの切り戻し
障害発生時の代替手段

AIクレジットと利用モデルの自社管理

ローカルモデルの推論は、GitHub提供モデルのリクエスト枠ではなく、自社端末や社内GPUサーバーの計算資源を使用します。

定型的なコード説明や小規模修正には軽量なローカルモデルを使用し、複雑な設計や大規模なリファクタリングには高性能なクラウドモデルを使う運用が可能です。

ただし、ローカルモデルは必ずしも無料ではありません。

GPU端末の購入費
共有GPUサーバーの構築費
電力費
モデル更新の保守工数
障害対応
利用者サポート
監視とログ管理

ローカル化は、クラウド利用料を単純にゼロへする方法ではなく、AI利用コストをクラウド課金からインフラ・運用費へ移す選択と捉える必要があります。

GitHub Copilotのローカル利用に必要な環境とモデル選定

GitHub Copilotとの接続に成功しても、モデル能力や端末性能が不足していると、実務では使えません。

モデル実行基盤、Agentに必要な能力、GPU・メモリを順に確認し、実際のリポジトリを使ったPoCで判断します。

Ollama・LM Studio・社内推論サーバーの選択

Ollamaは、コマンドラインを中心にモデルの取得・起動を管理する実行基盤です。ローカルAPIを提供するため、VS CodeやCopilot CLIから接続しやすい特徴があります。

LM Studioは、GUI上でモデルの検索、ダウンロード、ロード、APIサーバーの起動を管理できます。コマンド操作に慣れていない利用者でも、モデルの状態を確認しやすい点が特徴です。

vLLMなどを使った社内推論サーバーは、複数の利用者でGPUリソースを共有し、モデル、ログ、アクセス権を一元管理する場合に向いています。

少人数のPoCでは個人PC方式が始めやすい一方、全社展開ではモデルの乱立やログ管理が課題になります。利用人数が増える場合は、社内共通サーバーへの集約を検討します。

比較項目	Ollama	LM Studio	社内推論サーバー
操作方法	CLI中心	GUI中心	サーバー運用
導入難易度	比較的低い	比較的低い	高い
個人PoC	向いている	向いている	過剰になりやすい
複数人利用	個別構築が必要	個別構築が必要	向いている
モデル統制	端末ごと	端末ごと	一元管理しやすい
GPU共有	難しい	難しい	可能
ログ管理	端末ごと	端末ごと	一元管理しやすい

Agentモードに必要なモデル能力

Copilot CLIで利用するモデルは、ツール呼び出しとストリーミングに対応している必要があります。

ツール呼び出しとは、モデルがファイル読み込み、コード編集、テスト実行などの外部機能を、決められた形式で選択する仕組みです。単純なチャットに対応するモデルでも、ツール呼び出しへ対応していない場合はAgentとして動作しません。

GitHubの公式ドキュメントでは、Copilot CLIで良好な結果を得るための目安として、少なくとも128,000トークンのコンテキストウィンドウを持つモデルを案内しています。

モデル選定では、コーディング性能だけでなく、次の項目を評価します。

ツール呼び出しへの対応
ストリーミングへの対応
JSON形式の出力精度
長いコードの読み取り能力
複数ファイルの関係理解
指示への追従性
誤ったツール選択の頻度
コンテキストウィンドウの長さ

小型モデルは短いコード説明には利用できても、複数ファイルの編集や長いAgentタスクでは失敗が増える可能性があります。

GPU・メモリ・応答速度の考え方

必要なGPUやメモリは、モデルのパラメータ数、量子化方式、コンテキスト長、同時利用人数によって変わります。

量子化とは、モデルの数値表現を圧縮し、必要なメモリを減らす方法です。圧縮率を高めると軽い環境で動かしやすくなりますが、回答品質が低下する場合があります。

モデル全体がGPUのVRAMに収まらない場合、一部の処理がRAMやCPUへ移され、応答速度が大きく低下する可能性があります。

開発端末でモデルを動かす場合は、VS Codeだけでなく、Docker、ビルド、テスト、ブラウザーなども同じCPU・GPU・メモリを使用します。AI単体の速度ではなく、開発環境全体への影響を測定しなければなりません。

PoCでは、次の項目を記録します。

初回応答時間
1秒当たりの生成量
最大コンテキスト
RAM使用量
VRAM使用量
IDE操作への影響
ビルド時間への影響
Agentタスクの成功率
複数ユーザー利用時の待ち時間

特定のGPU製品を基準に導入判断するのではなく、候補モデルを自社の実際のリポジトリで検証することが重要です。

GitHub Copilotをローカルで使う設定手順

GitHub Copilotとローカルモデルを接続する際は、利用方式の決定、モデルの起動、VS CodeまたはCopilot CLIとの接続、通信確認の順に進めます。

接続できたことだけで完了とせず、利用できる機能と通信先まで記録します。

事前条件と利用方式の決定

最初に、ローカル環境で実現したい機能を整理します。

チャット
Agentによるファイル編集
ターミナル中心の操作
インラインコード補完
完全オフライン
GitHubコード検索
MCP連携

チャットやAgent編集が主目的ならVS Code BYOK、ターミナル操作や閉域網での利用が主目的ならCopilot CLIが候補です。

ローカルモデルによるインラインコード補完まで必要な場合は、Continueなどの拡張機能を含めて検討します。

検証前には、次の情報を記録します。

OSとバージョン
VS Codeのバージョン
Copilot CLIのバージョン
利用する拡張機能
OllamaまたはLM Studioのバージョン
モデル名と量子化方式
RAMとVRAM
接続先URL
GitHubへのサインイン有無

Copilot Business・Enterpriseでは、組織管理者がBYOKやCopilot CLIを無効化していないか確認します。

最初の検証では、機密情報を含まない小規模なリポジトリを使用してください。

OllamaまたはLM Studioでのローカルモデル起動

OllamaまたはLM Studioをインストールし、コーディング用途の候補モデルを取得します。

Ollamaでは、次のようなコマンドでモデルを取得・起動します。

ollama pull モデル名
ollama run モデル名

モデルを起動した後、ローカルAPIへ接続できることを確認します。Ollamaの標準的な接続先は、ローカル環境のhttp://localhost:11434です。

LM Studioでは、モデルをロードした後、DeveloperまたはLocal Serverに該当する画面からAPIサーバーを起動します。表示されたエンドポイントURLとモデルIDを記録します。

確認時は、ローカルモデルではなく、外部APIへ処理を転送するモデルやプロバイダーを選択していないか確認してください。

社内推論サーバーを使う場合は、次の設定も必要です。

TLS
利用者認証
IPアドレス制限
アクセスログ
同時接続数
タイムアウト
モデルの利用権限

VS Codeのモデルピッカーへのローカルモデル追加

VS Codeからローカルモデルを追加する基本的な流れは次のとおりです。

コマンドパレットを開く
「Chat: Manage Language Models」を実行する
「Add Models」からモデルプロバイダーを追加する
Ollama公式拡張機能または利用するプロバイダーを設定する
モデルを表示状態にする
チャット画面のモデルピッカーからモデルを選択する

Agentモードで利用する場合は、対象モデルがツール呼び出しに対応していることを確認します。

GitHubアカウントへサインインしない場合は、chat.utilityModelとchat.utilitySmallModelもローカルモデルへ変更します。変更しない場合、タイトル生成や意図判定などのユーティリティ機能が動作しない可能性があります。

設定後は、次の順番で動作を確認します。

短い質問への回答
開いているファイルの説明
指定ファイルの参照
小規模なコード編集
テスト実行
複数ファイルの編集
Agentによるツール呼び出し

Copilot CLIとローカルモデルの接続

Copilot CLIをOllamaへ接続する場合は、モデルサーバーを起動した状態で環境変数を設定します。

macOS・Linuxでは、次のように設定します。

export COPILOT_PROVIDER_BASE_URL=http://localhost:11434
export COPILOT_MODEL=使用するモデルID
copilot

完全オフラインで利用する場合は、COPILOT_OFFLINE=trueを追加します。

export COPILOT_PROVIDER_BASE_URL=http://localhost:11434
export COPILOT_MODEL=使用するモデルID
export COPILOT_OFFLINE=true
copilot

Windows PowerShellでは、次のように設定します。

$env:COPILOT_PROVIDER_BASE_URL="http://localhost:11434"
$env:COPILOT_MODEL="使用するモデルID"
$env:COPILOT_OFFLINE="true"
copilot

社内推論サーバーや認証が必要なエンドポイントでは、APIキーも指定します。

export COPILOT_PROVIDER_API_KEY=APIキー

起動後は、ファイルの読み込み、コード修正、テスト実行、ツール呼び出しを順に確認します。

GitHubコード検索やGitHub MCPサーバーを利用したい場合は、オフラインモードでは利用できないため、認証と通信を許可するオンラインBYOK構成との使い分けが必要です。

通信先と利用機能の検証

設定後は、「回答が返ってきた」ことだけで導入可能と判断せず、実際の通信先と機能制限を確認します。

通信先は、少なくとも次の単位へ分けます。

ローカルモデルまたは社内推論サーバー
GitHub
モデル提供事業者
MCPサーバー
Web検索先
VS Code拡張機能の提供元
ログ収集サーバー

Copilot CLIのオフラインモードでは、GitHub認証が実行されず、テレメトリが無効になることを、プロキシログやネットワーク監視で確認します。

機能については、次の可否を記録します。

チャット
ファイル参照
Agent編集
ターミナル実行
ツール呼び出し
インラインコード補完
セマンティック検索
GitHubコード検索
MCP
Web検索

検証用の文字列を入力し、モデルサーバー、VS Code、Copilot CLI、プロキシなどのどのログへ保存されるかも確認します。

GitHub Copilotのローカル利用で起きる5つの失敗要因と対策

GitHub Copilotとローカルモデルの接続では、モデルが表示されない問題だけでなく、Agentの失敗、性能低下、外部通信の残存、インライン補完に関する誤解が起こりやすくなります。

症状、原因、対策を切り分け、闇雲な再インストールやモデル変更を避けましょう。

ローカルモデルがモデルピッカーに表示されない問題

Ollamaではモデルが動作しているにもかかわらず、VS Codeのモデル一覧に表示されない場合は、次の原因が考えられます。

Ollamaプロセスが停止している
エンドポイントURLが誤っている
必要な拡張機能が導入されていない
モデルが非表示になっている
VS Codeの再起動が必要
旧Ollamaプロバイダーを使用している

切り分けは、次の3段階で行います。

モデルサーバー単体で回答できるか
VS Codeからモデルサーバーへ接続できるか
モデルピッカーでモデルが表示状態になっているか

VS Code内蔵のOllamaプロバイダーは非推奨となっているため、旧設定を使っている場合はOllama公式拡張機能への移行を確認します。

Agentモードでのファイル編集・ツール呼び出し失敗

チャットには回答できるものの、ファイル読み込み、コード編集、コマンド実行で停止する場合、モデルの能力不足が考えられます。

主な原因は次のとおりです。

ツール呼び出しに対応していない
ストリーミングに対応していない
コンテキスト長が不足している
ツール用のJSON形式を正しく出力できない
依頼範囲が広すぎる
モデルに渡すファイル量が多すぎる

ツール呼び出し対応モデルへ変更し、モデル設定の能力情報や最大入力トークンを確認します。

また、「リポジトリを調査して修正し、テストして報告する」という大きな依頼を、調査、計画、編集、テストに分けることで成功率が改善する場合があります。

モデル負荷によるIDE・ビルド処理の低下

高性能なモデルを選んでも、開発端末全体の生産性が下がる場合があります。

代表的な症状は次のとおりです。

回答開始までの時間が長い
生成中にVS Codeの操作が重くなる
Dockerコンテナが停止する
テストやビルドが遅くなる
PCの発熱や消費電力が増える

モデルサイズ、長いコンテキスト、VRAM不足、CPUへのオフロードなどが主な原因です。

短い質問には軽量モデル、複雑なAgent作業には高性能モデルを使うなど、用途ごとにモデルを分けます。開発端末での実行が難しい場合は、社内GPUサーバーへ推論処理を移す方法もあります。

ローカルモデル選択だけでの完全オフライン判断

最も注意が必要なのは、Ollamaを選択しただけで完全オフラインになったと判断することです。

モデルがローカルでも、次の通信が残る可能性があります。

GitHub認証
Copilotのテレメトリ
MCPサーバー
Web検索
GitHub API
外部拡張機能
外部ログ収集サービス

Copilot CLIでは、BYOKを設定しただけではテレメトリが通常どおり送信されます。GitHubサーバーへの接続を停止するには、COPILOT_OFFLINE=trueの設定が必要です。

VS Codeでは、モデル以外の通信を機能別・拡張機能別に確認します。ファイアウォール、プロキシログ、パケット監視などを利用し、実際の通信を検証してください。

インラインコード補完までローカル化できるという誤解

VS CodeのBYOKは、チャットとユーティリティタスクが主な対象です。GitHub Copilotの標準インラインコード補完には、ローカルBYOKモデルを割り当てられません。

インライン補完が必須の場合は、次の選択肢があります。

Continueなどのローカル補完対応拡張機能を利用する
インライン補完のみGitHub提供モデルを利用する
機密コードのチャットや編集だけローカルモデルへ分離する

ハイブリッド構成では、どのリポジトリやタスクをクラウドモデルへ送信できるか、チーム内でルールを定める必要があります。

失敗要因	主な症状	リスク	対策
モデルが表示されない	モデルピッカーに出ない	PoC停止	API・拡張機能・表示設定を段階確認
Agent能力不足	編集やツール実行で停止	誤操作・作業失敗	ツール呼び出し対応モデルへ変更
端末性能不足	IDEやビルドが遅い	開発生産性低下	軽量モデルまたは社内GPUを利用
オフライン設定不足	外部通信が残る	情報管理違反	オフライン設定と通信監視
補完機能の誤解	インライン補完が使えない	利用者の不満	Continue併用またはハイブリッド化

GitHub Copilotをローカル導入する企業のセキュリティ・運用設計

技術的にローカルモデルへ接続できても、企業として安全に利用できるとは限りません。

データフロー、モデル・エンドポイントの統制、PoCの評価基準を整備し、開発部門とセキュリティ部門が同じ資料を使って判断できる状態を作ります。

コード・プロンプト・ログのデータフロー整理

最初に、AIへ入力される可能性がある情報を分類します。

ユーザーが入力したプロンプト
開いているファイル
参照対象として指定したファイル
ターミナル出力
Git履歴
エラーログ
MCPから取得した情報
Web検索結果

次に、送信先を分類します。

開発端末上のローカルモデル
社内推論サーバー
GitHub
外部モデルAPI
MCPサーバー
拡張機能の提供元

保存先も別に整理します。

VS Codeのチャット履歴
Copilot CLIの履歴
モデルサーバーのログ
OSログ
プロキシログ
監視基盤

「学習に利用されない」「ログへ保存されない」「ネットワークへ送信されない」は、それぞれ異なる条件です。ひとつの項目を満たしていても、ほかの項目を満たすとは限りません。

モデル・エンドポイント・権限の統制

開発者が任意のモデルや外部エンドポイントを追加できる状態では、ローカル化による情報管理が形骸化する可能性があります。

企業利用では、次の情報をホワイトリスト化します。

利用を許可するモデル
モデルのバージョン
量子化形式
モデルの配布元
ライセンス
接続先エンドポイント
利用可能な拡張機能
利用可能なMCPサーバー

APIキー、エンドポイントURL、モデル更新、ログ閲覧などの権限も分離します。

Copilot Business・Enterpriseでは、管理者がVS CodeのBYOK利用やCopilot CLIの利用をポリシーで制御できます。加えて、Agentが実行できるコマンド、書き込み可能なディレクトリ、ネットワークアクセスを、サンドボックスや端末管理で制限します。

PoCで測定する品質・速度・安全性

PoCでは、担当者の主観的な使用感だけでなく、品質、速度、安全性、コストを測定します。

品質の評価項目例は次のとおりです。

生成コードの正答率
テスト成功率
レビュー時の修正数
ツール呼び出し成功率
複数ファイル編集の成功率
誤ったファイル変更の回数

速度の評価項目例は次のとおりです。

初回応答時間
生成速度
タスク完了時間
IDEの操作性
ビルド時間
同時利用時の待ち時間

安全性の評価項目例は次のとおりです。

外部通信先
ログへ保存される内容
権限外ファイルへのアクセス
危険なコマンドの実行可否
機密情報を含むファイルの参照可否
通信遮断時の挙動

同じタスクを、GitHub提供モデル、軽量ローカルモデル、高性能ローカルモデルで実行し、結果を比較します。

平均的な回答品質だけでなく、失敗率と失敗時の復旧方法まで含めて導入可否を判断することが重要です。

GitHub Copilotのローカル利用が向く3つの導入シナリオ

以下は、実在企業の導入実績ではなく、業務条件をもとに整理した想定シナリオです。

ローカル構成が向くかどうかを、業界名だけでなく、ネットワーク要件、データの機密性、運用体制から判断してください。

【想定シナリオ：製造業】閉域網の保守開発

工場や制御システム周辺の保守開発では、ソースコードを外部サービスへ送信できない場合があります。

閉域網内にOllamaまたはvLLMの推論サーバーを設置し、Copilot CLIをCOPILOT_OFFLINE=trueで起動する構成が候補です。

主な用途は、次のような作業です。

旧式コードの説明
影響範囲の整理
テストコードの雛形作成
コメントの追加
障害ログの要約

生成された変更は自動適用せず、人によるレビューと既存のテストを必須とします。

効果は架空の削減率で示さず、調査時間、テスト作成時間、レビュー修正率、Agent成功率をPoCで測定します。

【想定シナリオ：金融業】社内共通モデルサーバーによるレビュー補助

機密性の高いリポジトリでAIレビューを使いたい場合、開発者ごとにローカルモデルを配置すると、モデル更新やログ管理が難しくなります。

社内GPUサーバーへ承認済みモデルを配置し、VS Code BYOKから社内エンドポイントへ接続する構成が候補です。

集中管理によって、次の項目を統制しやすくなります。

モデルバージョン
利用者権限
アクセスログ
同時接続数
モデル更新
利用停止

用途は、コード説明、レビュー観点の抽出、テスト観点の提案などに限定し、生成コードにはCI、静的解析、人によるレビューを適用します。

【想定シナリオ：SIer】ローカルとクラウドのハイブリッド運用

すべてのタスクをローカル化すると、モデル性能や開発者体験が低下する場合があります。

定型的なコード説明、コメント作成、小規模修正にはローカルモデルを使い、複雑な設計、複数リポジトリの分析、大規模なリファクタリングには承認済みクラウドモデルを使う構成が現実的です。

モデルの選択を開発者個人へ任せず、次のようなルールを定めます。

リポジトリの機密区分
クラウド送信可能なデータ
タスクごとの利用モデル
人によるレビューが必要な変更
利用禁止モデル
例外申請の手順

コスト評価では、AIクレジットだけでなく、再生成回数、レビュー工数、GPU運用費も含めます。

GitHub Copilotをローカル導入すべきか判断するチェックリスト

GitHub Copilotのローカル利用は、外部送信を制限したい企業に有効ですが、モデル管理やGPU運用の負担が増えます。

ローカル、クラウド、ハイブリッドのどれを選ぶか、セキュリティ要件と運用体制の両面から判断しましょう。

GitHub Copilotのローカル利用が適する条件

次の項目に多く該当する場合は、ローカル構成を検討する価値があります。

機密コードや顧客データを外部モデルへ送信できない
閉域網またはオフライン環境で開発している
GPU端末または社内推論サーバーを保有している
モデル更新を担当する人材がいる
障害対応や性能評価を担当する人材がいる
チャットやAgent編集が主目的である
標準インライン補完をローカル化できない制約を許容できる
通信先や利用モデルを組織で統制できる
PoCに必要な期間と予算を確保できる

簡易的な目安として、7項目以上に該当する場合はローカル構成、4〜6項目の場合はハイブリッド構成、3項目以下の場合はクラウド構成を中心に比較します。

ただし、該当数だけで決定せず、「外部送信が禁止されている」などの必須条件を優先してください。

クラウドまたはハイブリッド利用が適する条件

次の条件では、クラウドまたはハイブリッド構成が適しています。

高性能なモデルを安定して利用したい
インラインコード補完を重視する
セマンティック検索やGitHubコード検索を利用したい
GPUやモデルサーバーの管理担当者を置けない
対象コードを承認済みクラウドサービスへ送信できる
機密度の高いタスクだけをローカルへ分離できる
複数のモデルをタスク別に使い分けたい

ハイブリッド構成では、リポジトリの機密区分、タスク分類、利用モデルの対応表を整備します。

判断項目	ローカル	クラウド	ハイブリッド
機密コード	外部送信不可	送信可能	機密度で分離
閉域網	適している	適さない	一部可能
モデル性能	自社環境に依存	高性能モデルを利用しやすい	タスク別に選択
インライン補完	制限あり	利用しやすい	クラウド側で利用
運用負荷	高い	低い	中程度
GPU管理	必要	不要	一部必要
コスト構造	インフラ・運用費	契約・従量課金	両方を管理

GitHub Copilot ローカルの導入支援は「フリーコンサルタント.jp」へご相談ください

フリーコンサルタント.jpでは、事業会社やコンサルティングファーム出身のプロ人材が、生成AI・DX活用の戦略設計から現場のルール整備、社内への知見移転までを伴走支援します。実務経験豊富な人材が、上流の方針づくりから実行段階まで一貫して関わることで、導入後の定着まで見据えた支援が可能です。

まずは自社のどの業務・データで試すか、小さく始めるところから相談してみるのがおすすめです。

フリーコンサルタント.jpによるAI導入支援の事例

フリーコンサルタント.jpでは、AI・DX推進領域全般で企業の支援実績があります。ここでは、社内に専門人材が不足していた企業の支援事例を2件紹介します。

事例①｜大手飲食企業：需要予測・発注レコメンドAIの開発支援

200店舗以上・400品目の発注業務を店舗担当者の経験と勘に頼っており、業務が属人化していた大手飲食企業の事例です。データサイエンティストなどAI活用の経験者が社内に不足し、AIの本格運用に向けたデータ活用の進め方が分からない状態でした。

当時の課題	・データサイエンティスト・データアナリスト人材、AI活用の経験者が社内に不足・店舗情報・POSデータをもとにした需要予測を、複数人が同じ精度で行うことが困難・発注業務が現場の勘に依存し、担当者の休暇・退職で業務が滞るリスクを抱えていた
実施したこと	・店舗ごとの特徴を踏まえた変数を定義し、データを整理・PoC（概念実証）を経て、店舗ごとに高い精度で需要予測ができるAIモデルを構築・運用

需要予測AIの活用により発注業務の多くを自動化し、作業時間を削減。バックオフィス業務の負荷が軽減し、店舗担当者が接客などの対応に時間を割けるようになりました。

事例②｜大手通信キャリア企業：デジタル活用推進に向けたCoE組織の立ち上げ支援

業務効率化を目的に、デジタル活用組織（CoE＝Center of Excellence。複数部門の知見を集約する専門組織）の立ち上げを決定したものの、組織立ち上げの推進とデジタル技術活用の両方を担える人材が社内に不足していた大手通信キャリア企業の事例です。

当時の課題	・デジタル領域の知見と組織立ち上げ経験を併せ持つ人材が社内に不足・業務効率化ツールの開発・運用体制をゼロから構築する必要があった
実施したこと	・CoE組織の立ち上げから全体設計・運用構築・実運用までを一気通貫で伴走支援・事業部門への課題ヒアリングをもとにしたツール開発の仕組みを構築し、プロパー社員が自走できる体制へ知見を移転

CoE組織の立ち上げと運用の安定化により、組織立ち上げ前と比較して業務工数を約25%削減。プロパー社員が主体的に運用できる体制を構築し、外部人材への依存から段階的に脱却しています。

まとめ

GitHub Copilotでは、VS Code、Copilot CLI、GitHub Copilotアプリから、OllamaやLM Studioなどのローカルモデルを利用できます。

VS CodeのBYOKは、チャットや一部のAgentワークフローに適用できますが、標準のインラインコード補完やセマンティック検索など、GitHub Copilotサービスへの接続が必要な機能までは置き換えられません。

Copilot CLIでは、ローカルモデルとCOPILOT_OFFLINE=trueを組み合わせることで、GitHub認証とテレメトリを無効にした閉域構成を作れます。ただし、完全オフラインになるのは、モデルの接続先も同じ閉域環境内にある場合だけです。

ローカル利用の可否は、モデルの実行場所だけでなく、エンドポイント、拡張機能、MCP、Web検索、認証、ログを含むデータフロー全体で判断する必要があります。

導入前には、機能、品質、速度、通信、安全性、総コストをPoCで比較してください。すべてをローカル化するのではなく、機密性が高い作業はローカル、複雑な設計はクラウドというハイブリッド運用も有力な選択肢です。