10月8日、Microsoft Command Lineが「Bringing local models and sandboxed tools to Windows and GitHub Copilot」と題した記事を公開した。ローカルデバイス上で137Bパラメータのコーディング特化モデルを動かし、クラウドと自動的に使い分け、さらにエージェントの実行環境をOSネイティブのサンドボックスで保護する——GitHub Copilotのオンデバイス対応がここまで来たかと思わせる内容だ。

ローカルで動く137Bモデル「MAI Code 1.1 Flash」

今回の発表の核心は、MAI Code 1.1 Flashというコーディング特化モデルのオンデバイス版だ。

このモデルはMixture-of-Experts（MoE）アーキテクチャを採用し、総パラメータ数137B、アクティブパラメータ数6.8Bという構成になっている。MoEは推論時に全パラメータを使わず一部のみを活性化するため、大規模モデルでも推論コストを抑えられるアーキテクチャだ。

デバイス上での動作を実現するために、以下の2つの技術が適用されている。

• 量子化（Quantization）: モデルの重みと活性化の精度を下げてメモリ使用量を削減。混合精度量子化で約3.3 bits per weightを実現し、クラウド版（BFloat16）と比べてモデルサイズを80%削減（53GB）している
• Speculative Decoding（スペキュラティブデコーディング）: 小さなドラフトモデルがトークン候補を先読みし、メインモデルが検証するという手法で、デコードスループットを向上させ遅延を削減する

コードは「1トークン間違えば構文エラー、誤った識別子、壊れたdiff」になるため、量子化の精度劣化がそのまま動作不良に直結する。そのため、ベンチマークは特に重視されている。

量子化後もクラウド版とほぼ同等のスコアを維持している点が目を引く。なお、Terminal-Bench 2.1では量子化版がクラウド版をわずかに上回る結果（66.29% vs 62.9%）となっており、この数値は元記事に記載されたものをそのまま反映している。

Surface Laptop Ultra（NVIDIA RTX Spark搭載。MicrosoftがSurface向けに新たに投入したGPUアーキテクチャ）上では、64kコンテキストで923.5トークン/秒のプロンプト処理スループットを達成している。

動作には128GBの統合メモリを持つSurface Laptop Ultraが前提となっており、256kコンテキスト時のピークメモリ使用量は75.5GBに達する。モデルの重みだけでなく、OSやアプリケーション、KVキャッシュ（モデルがすでに処理したトークンのアテンション状態を保持するメモリ領域）も含めたメモリ全体の設計が重要になる点は記事中でも強調されている。

ローカルとクラウドの自動オーケストレーション

GitHub Copilotはローカルモデルとクラウドモデルの使い分けを自動で行う「Auto」モードと、開発者が明示的にモデルを選ぶ直接選択モードの2つをサポートする。

Autoモードでは、マルチターンのセッション中にタスクのコンテキストやキャッシュ状態を考慮しながら、ローカルとクラウドへの処理の振り分けをCopilotが自律的に行う。これはGitHubが以前発表したProject HydraFusion（複数モデルを組み合わせてコスト・性能・遅延を最適化するオーケストレーター）の発展版に位置づけられており、複数モデルにとどまらずエッジ（ローカルデバイス）を含む複数の計算環境にまたがるオーケストレーションという段階に進む。

なお、「ローカルモデルを使う＝オフラインで完結する」ではない。記事内では「ローカル推論はセッションをオフラインにしない」と明記されており、ツール呼び出しやMCPサーバーへの接続は引き続きネットワークを利用する場合がある。

明示的な選択では、MAI Code 1.1 FlashをWindows MLプロバイダー経由で選択するか、OpenAI互換のローカルエンドポイントに接続して任意のモデルを使用できる。

サンドボックスで守るエージェントの実行環境

エージェントがシェルコマンドを実行する際、通常は実行ユーザーのアクセス権限をそのまま継承する。ローカルでモデルを動かしてもこの点は変わらない。

そこで導入されるのが**Microsoft Execution Containers（MXC）**だ。Windowsチームが開発したオープンソースライブラリで、ポリシーをOSネイティブのアクセス制御に変換する。

• Windows: BaseContainer tier（ProcessContainerバックエンド）
• macOS: Seatbelt
• Linux: bubblewrap

各プラットフォームのOSネイティブ機能を使うため、別途VMやコンテナイメージは不要だ（将来的にはMXC経由でそれらもオプションとして提供予定）。

サンドボックスが有効な状態では、シェルコマンド、ローカルのModel Context Protocol（MCP）サーバー、言語サーバーがプロセス境界の内側で実行される。一方、リモートMCPサーバーはローカルのプロセスサンドボックス外にあり、接続ポリシーはGitHub Copilot内でチェックされる。

実際の使い方：毎朝のリポジトリダッシュボード生成

記事では、サンドボックスとローカルモデルを組み合わせた具体的なユースケースが紹介されている。

毎朝9時に自動実行する「リポジトリのトリアージダッシュボード生成」タスクだ。GitHubのIssueとPRメタデータを読み取り、./dashboard/index.html（インラインCSS・SVG付き）と最大7日分の履歴を./history.jsonに書き出す。

設定手順はシンプルで、GitHub Copilotアプリの設定からプロジェクトを選択し「Sandbox new sessions」を有効化。その後「Automations」セクションでトリガー時刻とプロンプトを設定し、使用モデルにMAI Code 1.1 Flashを選択するだけだ。

サンドボックス有効時は、カレントディレクトリが読み書き可能で残りのシステムは基本的に読み取り専用またはアクセス不可になる。エージェントがスクリプトを生成・実行しても、意図しないシステム変更を防ぐ基本的な保護が働く。

提供時期

10月末までにGitHub Copilot CLI、Copilotアプリ、VS Codeに順次ロールアウト予定とされている（記事公開は10月8日）。現時点でSurface Laptop Ultra（NVIDIA RTX Spark）が対象ハードウェアとして明示されており、128GB統合メモリという高スペック要件が一般的な普及の課題となることは否めない。

詳細はBringing local models and sandboxed tools to Windows and GitHub Copilotを参照していただきたい。