MicrosoftとGitHubは2026年10月7日、GitHub Copilotが作業内容に応じて、PC上のAIモデルとクラウドのAIモデルを自動で使い分ける機能を発表した。GitHub Copilot CLI、GitHub Copilotアプリ、Visual Studio Code（VS Code）を対象に、Windows向けの試験的プレビューを10月下旬から提供する予定だ。開発者がローカルモデルを直接指定する方法も用意され、処理先をCopilotに任せるか、自分で選ぶかを切り替えられる。PC上でAIモデルを動かすこと自体は以前から可能だったが、今回の特徴は、作業内容に応じた処理先の判断をCopilotに任せられる点にある。実際にどれだけ便利になるかは、長時間のコーディングで作業の品質やメモリ使用量、クラウドとの通信がどう変わるかによって決まる。

AD

手動のモデル選択から、ローカル・クラウドの自動振り分けへ

VS Codeでは、独自のAPIキーや接続先を登録するBYOK（Bring Your Own Key）機能を使い、OllamaやFoundry Localで動かすモデルをチャット画面から選択できる。Microsoftは6月18日の公式解説で、ローカルモデルを使った開発作業をすでに紹介していた。今回の更新では、こうした既存の仕組みに加え、Ollamaで動作するモデルを簡単に登録する機能と、ローカル・クラウド間の自動振り分けが導入される。

機能 開発者が選ぶもの 公式資料で確認できる提供状況
VS CodeのBYOKによるローカル接続 接続先とチャットで使用するモデル 6月18日の解説時点で利用可能
Copilot CLIのOllama検出 検出されたモデルを追加するかどうか 10月7日発表、CLI 1.0.94-0以降で利用可能
ローカル・クラウド間のAuto 処理先の判断をCopilotに任せるかどうか 10月下旬に試験的プレビューを提供予定

表は2026年10月9日時点のMicrosoftとGitHubの公式情報をもとに、各機能の操作方法と提供状況を整理したものだ。6月18日はBYOKの提供開始日を示すものではない。また、すでに利用できるOllamaの検出機能と、今後提供されるAutoは別の機能である。

Copilot CLIでは、/modelコマンドを使うと、起動中のOllamaで利用できる対応モデルを検出できる。開発者はモデルの提供元や接続先を確認したうえで、使用するモデルを追加する仕組みだ。ただし、Ollamaやモデルそのものを自動的にインストールするわけではないため、事前の準備が必要になる。また、モデルにはツール呼び出しと、回答を生成しながら順次返すストリーミング出力への対応が求められる。

一方、Autoは会話の文脈やキャッシュの状態を考慮し、ローカルモデルとクラウドモデルのどちらで処理するかを自動で判断する。GitHubが9月4日に研究プレビューとして発表したHydraFusionは、単一モデルで処理する方法に加え、必要に応じて高性能なモデルへ切り替えたり、別のモデルに回答を検証させて修正したりする仕組みだった。今回の更新では、その選択肢にPC上で動作するローカルモデルが加わる。

処理先を自分で指定したい開発者向けには、Windows MLを通じてMicrosoftの「MAI Code 1.1 Flash」を利用する方法と、OpenAI互換のローカルAPIに接続する方法が用意される。ここでいうOpenAI互換とは、APIの仕様に互換性があるという意味であり、OpenAIのクラウドに推論処理を送るということではない。実際の通信先は、開発者が設定した接続先によって決まる。

53GBのモデルでも、実行時には75.5GBのメモリを使用

ローカル版のMAI Code 1.1 Flashは、総パラメーター数1,370億、推論時に使用するアクティブパラメーター数68億のMoE（Mixture of Experts）モデルだ。MoEは、複数の専門ネットワークのうち、入力に応じて必要な部分だけを動かす仕組みである。計算量を抑えられる一方、モデル全体の重みを保持するためのメモリは必要になる。したがって、アクティブパラメーター数が68億だからといって、小さなメモリで動作するとは限らない。

Microsoftは、モデルの重みなどを少ないビット数で表現する「量子化」によって、モデルサイズを53GBまで削減したと説明している。Bfloat16形式のクラウド版と比べて約80%の削減に相当する。技術解説によると、重み当たり約3.3ビットの混合精度量子化を採用している。

ただし、モデルのサイズが53GBでも、実行時のメモリ使用量が53GBで済むわけではない。Microsoftの測定結果では、Surface Laptop Ultra上で256kトークンの文脈を処理した際、ピークメモリ使用量は75.5GBに達した。モデル自体のサイズと、実際の作業中に必要なメモリ容量は区別する必要がある。

AIエージェントは、ソースコードを読み込み、ツールの実行結果を受け取りながら作業を進める。その過程では、処理済みのトークンに関する情報を保持する「KVキャッシュ」も増えていく。さらに、OSやエディター、推論ソフトウェアもメモリを使用する。短い質問に答えられることと、大規模なリポジトリの修正を最後まで処理できることは、同じではない。

測定に使用されたSurface Laptop Ultraは、NVIDIA RTX Sparkを搭載し、最大128GBの統合メモリを備える。CPUとGPUが同じメモリ領域を共有できる構成だが、すべての容量をAIモデルに割り当てられるわけではない。また、最大128GBという仕様は、今回のモデルを動かすための最低要件を示すものでもない。

モデルをメモリに読み込んだままにしておけば、要求のたびに読み込む時間を省ける。しかし、会話が長くなり、ほかのアプリとの間でメモリの競合が起きれば、応答速度が低下する可能性がある。ローカルAIを評価する際には、単に起動できるかどうかだけでなく、普段の開発環境で長時間使い続けても、十分な性能を維持できるかを確かめる必要がある。

AD

モデルを小型化しても、コーディング品質は維持できるか

量子化によってモデルの重みを低精度で表現しても、生成するコードには正確さが求められる。識別子やツール呼び出しが一つ違うだけで、構文エラーや意図しない変更につながりかねない。そのためMicrosoftは、モデルのサイズや処理速度だけでなく、実際にコーディング課題を完了できるかどうかも評価している。

同社が10月7日の技術解説で公開したベンチマーク結果では、量子化による性能への影響が評価指標によって異なっていた。

評価指標 課題数 MAI Code 1.1 Flash ローカル量子化版
SWE-Bench Verified 500 72.6% 70.80%
Terminal-Bench 2.1 89 62.9% 66.29%

出典はMicrosoftが公開した評価結果であり、独立した第三者による測定ではない。SWE-Bench Verifiedでは量子化版の成績がわずかに低下した一方、Terminal-Bench 2.1では逆に上回った。

この結果からは、モデルを小型化しても、一定のコーディング能力を維持できていることがうかがえる。ただし、あらゆる開発作業で元のモデルと同等の品質が得られることや、量子化によって必ず性能が向上することを示すものではない。

処理速度を高めるために採用されたもう一つの技術が「投機的デコード」だ。小型のモデルが先に生成候補を作り、元のモデルがその候補を検証する。候補を効率よく採用できれば、生成速度を高められる。ただし、候補の生成と検証には追加の作業用メモリが必要になる。つまり、量子化で削減したメモリ容量の一部を、処理の高速化に振り向ける設計だ。

速度の数値についても、何を測定したのかを見極める必要がある。Microsoftは、64kトークンの文脈で毎秒923.5トークン、128kトークンでは毎秒769.8トークンという性能を示した。技術解説の本文では、これらをプロンプトの入力処理速度として説明している。

一方、同じ資料の図の説明や脚注では、デコード速度として記載されており、指標の表記に食い違いがある。そのため、これらの数値を、そのまま一般的な使用環境での回答生成速度と解釈するのは適切ではない。

測定は10月5日、Windows ARM64向けのllama.cpp CUDA実行環境で、DFlash2による投機的デコードを使用して実施された。脚注では人工的なコード生成負荷を使った測定であることも説明されており、実際の端末や設定、作業内容によって結果は変わる。

今回の自動振り分けが目指しているのは、すべての処理をPCへ移すことではなく、それぞれの作業に適したモデルと実行環境を選ぶことだ。クラウドへの依存を減らせたとしても、コードの修正や作業のやり直しが増えれば、開発時間の短縮にはつながらない。処理速度だけでなく、最終的な成果物の品質も含めて評価する必要がある。

推論先と、通信・ツール実行の権限は別の問題

ローカルモデルを選択したからといって、Copilotのセッション全体がオフラインになるわけではない。GitHubはOllama検出機能の発表で、ローカルモデルを選んでも、オフラインモードが有効になったり、GitHubへの利用状況データの送信が自動的に停止したりするわけではないと明記している。

Copilot CLIでは、COPILOT_OFFLINE=trueを設定することで、GitHubのサーバーへの接続を無効にできる。ただし、モデルの接続先として外部のサービスを指定している場合は、オフラインモードでもプロンプトやコードの情報がそのサービスに送信される可能性がある。

通信をどこまで制限できるかは、GitHubの公式ドキュメントに記載された設定と、実際に使用するモデルの接続先によって決まる。また、これはCopilot CLIの設定であり、VS Codeのすべての機能に適用されるわけではない。

AIモデルがどこで推論するかという問題と、AIエージェントがどのような操作を実行できるかという問題も分けて考える必要がある。

GitHubは同じ10月7日、ローカルサンドボックス機能の一般提供も発表した。対象はCopilot CLI、Copilotアプリ、Agent Hostを使用するVS Codeのセッションで、追加料金なしで利用できる。

この機能は、Microsoft Execution Containers（MXC）を利用し、エージェントが実行するコマンドのファイルアクセスやネットワーク接続、認証情報へのアクセスを制限する。使用するモデルがローカルかクラウドかにかかわらず、エージェントの実行権限を適切に制御する必要がある点は変わらない。

ただし、すべてのツールが同じ方法で隔離されるわけではない。

サンドボックスを有効にすると、シェルコマンドに加え、原則としてローカルのMCPサーバーや言語サーバーも、OSによってアクセスが制限されたプロセス内で実行される。

一方、Copilotに組み込まれたファイル操作ツールでは、Copilot自身が操作要求をポリシーと照合する。これは、OSが独立したプロセスのアクセスを制限する仕組みとは異なる。また、遠隔のMCPサーバーはローカルサンドボックスの隔離対象に含まれず、接続に関する制限はCopilot側で確認する。

機密性の高いソースコードを扱う開発チームにとって重要なのは、単に「ローカルモデルを使用している」と表示されることではない。どの情報がどこへ送信され、AIエージェントにどの操作が許可されるのかを把握できることが重要だ。

今回のAutoについて、MicrosoftとGitHubは会話の文脈やキャッシュの状態を考慮して処理先を決めると説明している。しかし、クラウドへ送信される情報の具体的な範囲や、振り分けを判断する詳細な条件までは明らかにしていない。導入にあたっては、モデルの実行場所と、外部へのデータ送信を許可する条件をそれぞれ確認する必要がある。

AD

自動振り分けの実用性は、実際の開発作業で見極める

PC上でもAIモデルを実行できるようになれば、クラウドだけに依存する場合よりも、利用できる計算資源の選択肢が広がる。ただし、今回の発表では、新しいAuto機能による具体的な料金削減率や、対応するすべての端末・利用プランの条件は示されていない。既存のHydraFusionの実験で得られた費用削減率を、ローカルモデル対応による効果としてそのまま当てはめることもできない。

10月下旬のプレビューで実用性を確かめるなら、普段使っているリポジトリで同等の修正課題を用意し、Auto、クラウドモデル、ローカルモデルのそれぞれで作業を実行して比較する方法が考えられる。

確認したいのは、単に最初の回答が返ってくるまでの速さではない。最終的に生成されたコードの品質、修正ややり直しを含む作業全体の所要時間、長時間のセッションでのメモリ使用量などが重要になる。クラウド側で消費したトークン数も記録すれば、ローカルモデルを活用することで、どの程度の負担を減らせるのか判断しやすくなる。

Autoの利点は、開発者が作業のたびにモデルや処理先を選び直さなくても、Copilotが適切な実行環境を判断してくれることにある。一方、処理先を厳密に管理する必要がある場合には、モデルを明示的に指定できる仕組みが役立つ。

最終的に重要なのは、自動振り分けによって、開発の品質を落とさずに作業時間やクラウドへの依存を減らせるかどうかだ。さらに、データの送信先やエージェントの実行権限も適切に管理できれば、PCの計算資源を日常的なAIコーディングに活用する価値は高まる。