2026年版 MCP on Windows入門――通常のMCP接続との違いを整理する

はじめに

以前、Windows／SQL Server／MCPのロードマップを追ったときは、「WindowsにMCPが組み込まれると何が変わるのか」がまだ少し見えにくい状態でした。

現在は Microsoft Learn に MCP on Windows の公式ドキュメントがまとまり、MCP server の検出、登録、接続、containment、ユーザーと管理者によるアクセス制御まで説明されています。

そこで今回は、その後の整理として次の疑問を中心に見ていきます。

• 通常のMCP接続と何が違うのか
• WindowsはMCP serverをどこまで管理するのか
• エージェント、MCP server、ユーザー、IT管理者はどう関係するのか

先に結論を書くと、MCP on Windows は別のMCP仕様というより、MCP serverをWindows上で見つけ、信頼と権限を確認し、管理された形で使うためのOS基盤と捉えると分かりやすそうです。

※本記事は個人の整理メモです。2026年6月22日時点のMicrosoft LearnとMCP公式仕様をもとにしています。MCP on Windowsは現在もプレリリース製品に関する情報を含み、正式リリースまでに要件や挙動が大きく変わる可能性があります。

そもそもMCPとは

MCP（Model Context Protocol）は、AIアプリケーションと外部のツールやデータソースを接続するためのオープンなプロトコルです。

基本的な登場人物は次の3つです。

• Host: AIアプリケーションやエージェント本体
• Client: Host内でMCP serverとの接続を担当する部品
• Server: tools、resources、promptsなどを提供する側

たとえば、AIエージェントがファイルを検索するとき、ファイル操作用のMCP serverが search_files のようなtoolを公開し、Host内のClientがそれを呼び出します。

この接続だけなら、Hostの設定ファイルへserverのコマンドやURLを書き、Clientから直接接続する方法でも実現できます。

通常のMCP接続でHostが持つ責任

通常のMCP接続では、MCP serverの管理方法はHostごとに異なります。

たとえば開発者が次のような設定を用意します。

{
  "mcpServers": {
    "files": {
      "command": "example-file-server.exe",
      "args": []
    }
  }
}

※このJSONはHost製品ごとの設定例です。mcpServersという設定形式自体が、MCP仕様で共通化されているわけではありません。

この場合、少なくとも次の判断はHostや利用者側に寄ります。

• どのserverがインストールされているか
• どの実行ファイルやURLへ接続するか
• そのserverを信頼してよいか
• どのファイルや資格情報へアクセスできるか
• 利用をどのように記録・監査するか

開発環境では扱いやすい方法ですが、複数のAIアプリが動く一般ユーザー端末や企業端末では、Hostごとに設定と権限制御が分散しやすくなります。

MCP on Windowsが追加するもの

MCP on Windowsでは、Windows On-device Agent Registry（ODR）が中心になります。

ODRは、ローカルアプリやリモートserverが提供するagent connectorを登録し、Hostから検出できるようにする仕組みです。Microsoft Learnでは、主な利点として次が挙げられています。

• ローカル／リモートMCP serverの標準的なサポート
• 登録済みserverの検出
• MCP serverの既定containment
• ユーザーとIT管理者によるアクセス制御
• 接続や操作のログ、監査
• File Explorer MCP serverなどのWindows connector

大事なのは、ODRがMCP Clientの代わりになるわけではないことです。

公式quickstartでも、HostはODRから登録済みserverを一覧し、返されたcommandとargsを使って StdioClientTransport を作り、MCP Clientとして接続しています。つまり、実際のtools/listやtools/callは引き続きMCPの仕組みです。

Windowsが追加するのは、その接続の前後を管理する層です。

通常のMCP接続との違い

ざっくり比較すると次のようになります。

観点	通常のMCP接続	MCP on Windows
serverの所在	Hostごとの設定ファイルなど	ODRへ登録し、Hostから検出
接続	Host内のClientが直接接続	ODRで発見後、ClientがMCP接続
登録・削除	Hostや導入手順ごと	アプリ導入／削除との連動、MCP bundle、手動登録
実行環境	serverの実装・起動方法による	条件を満たすserverは既定で別のagent sessionにcontainment
ユーザー制御	HostのUIや設定に依存	Windows Settingsによる制御を用意
企業管理	製品ごとの管理に依存	Microsoft Intuneなどの管理ツールを想定
監査	Host側で実装	ODRの利点としてログと監査可能性を提供

つまり違いは、MCPメッセージの形式よりも、serverのライフサイクルと信頼境界を誰が管理するかにあります。

エージェント・MCP server・権限制御の関係

関係を順番に追うと、次の流れになります。

1. アプリやインストーラーがMCP serverをWindowsへ登録する
2. Host／エージェントがODRから利用可能なserverを検出する
3. ユーザー設定と管理ポリシーによって、そのHostから利用できるかが決まる
4. Host内のMCP Clientがserverへ接続する
5. serverが公開するtoolをエージェントが選び、必要な引数を渡して呼び出す
6. 接続や操作をユーザー／管理者が記録・監査できる

ここで権限は一枚岩ではありません。

• serverを検出できるか
• 特定のHostからserverへ接続できるか
• serverがユーザーのファイルなどへアクセスできるか
• 個々のtool呼び出しを実行してよいか

これらは別の判断です。「一覧に見える」ことと「自由にユーザーデータへ触れられる」ことは同じではありません。

なお、serverの検出・接続やユーザーファイルへのアクセスはWindows／ODRの制御対象ですが、個々のtool呼び出しをどのように確認・承認するかは、Hostの実装にも依存します。

containmentで何が制限されるのか

ODR経由でアクセスされるMCP serverのうち、Windowsが提供するserverや、containment要件を満たしてMSIXまたはexternal location付きpackageで登録されたserverは、既定では別のWindows sessionと専用のagent user accountで実行されます。

containmentされたserverは、ユーザーのsessionへ直接アクセスできません。公式ドキュメントでは、既定で次のような対象へ直接アクセスできないと説明されています。

• ユーザーファイル
• ユーザー設定、レジストリ、資格情報
• ユーザーが利用中のアプリやウィンドウ
• ユーザーsessionを変更する実行ファイル

一方で、agent側のファイルやレジストリへのアクセス、agent user environmentでの実行可能ファイルの実行、インターネットへのアクセスは可能です。また、ユーザー同意があれば、特定のユーザーファイルへアクセスできます。

これは「MCP serverなら安全」という意味ではありません。serverの実行場所と初期権限を分離し、prompt injectionやtool悪用が起きた場合の影響範囲を小さくするための境界です。

ファイル権限はserver単位ではなくHost単位

特に注意したいのが、ユーザーファイルへの権限です。

公式ドキュメントでは、権限はMCP serverごとではなく Hostに対して付与される とされています。あるserverが要求したファイルアクセスをユーザーが許可すると、そのHostが同じsessionで使用する他のMCP serverもユーザーファイルへアクセスできる可能性があります。

そのためHost側でも、接続するserverを必要最小限にし、どのserverが同じsessionへ参加するかを慎重に扱う必要があります。

serverの登録方式で保護レベルが変わる

Windowsへの登録方法は大きく3つに整理できます。

1. package identityを持つアプリ

MSIXなどでpackage identityを持つアプリは、パッケージのメタデータによってMCP serverを登録できます。アプリのインストール／アンインストールに合わせて、OSがserverを登録／解除します。

また、通常のunpackaged appでも、MSIXのexternal locationを利用してpackage identityを付与できます。MSIXまたはexternal location付きpackageで登録され、containmentの要件を満たすserverは、contained agent sessionで実行できます。

2. MCP bundle

package identityを持たない .exe やMSI配布アプリなどは、MCP bundleとして登録できます。ただし、現在のプレビューではMCP bundleはcontained agent sessionで実行できません。package identityを付与してcontained実行したい場合は、前述のexternal locationを利用する方法もあります。

ODRから利用するには、Windows Settingsの次の項目で保護を下げる必要があります。

Settings > System > Advanced > AI components
  > Reduce protections for agent connectors

公式ドキュメントも、この設定はserverへより広いアクセスと権限を与え、追加のセキュリティリスクにつながり得ると注意しています。

3. odr.exeによる手動登録

リモートMCP serverや、ローカルserverを細かく制御して登録したい場合は、ODRのCLIを利用します。

odr.exe mcp list
odr.exe mcp add <manifest file path>
odr.exe mcp remove <server id>
odr.exe mcp configure <server id>
odr.exe mcp run

これを見ると、ODRは単なる構想ではなく、serverの登録、一覧、設定、起動を扱う管理面を持っていることが分かります。

File Explorer MCP connectorで考える

Windowsの公式例として分かりやすいのが File Explorer MCP connector です。

このconnectorは、ファイル検索、読み取り、テキスト編集、ディレクトリ作成、移動、ZIP圧縮／展開などのtoolsを提供します。Copilot+ PCでは自然言語によるセマンティックファイル検索も説明されています。

たとえばユーザーがエージェントへ次のように依頼したとします。

ダウンロードフォルダから今月の請求書を探して、Documentsに整理して

エージェントはODRからFile Explorer connectorを見つけ、tools/listで検索や移動のtoolを把握し、ユーザーと管理者が許可した範囲で実行します。

ここでも重要なのは、File Explorer connectorが存在するだけでファイルへ自由にアクセスできるわけではないことです。公式ドキュメントでは、ファイルアクセスには明示的なユーザー権限が必要で、ユーザーと管理者はアクセスを拒否できるとされています。

2026年時点で実装前に確認したいこと

MCP on Windowsを試す場合、少なくとも次を確認しておくとよさそうです。

• 対象Windows buildがプレビュー要件を満たすか
• Hostがpackage identityを持つか
• serverをMSIX、MCP bundle、手動登録のどれで配布するか
• contained実行の要件を満たすか
• 要求するknown folder capabilityは何か
• 同じHost sessionで利用するserverを絞れているか
• ユーザー同意とIT管理ポリシーの両方を設計したか
• 「Reduce protections for agent connectors」を安易に前提としていないか

公式quickstartでは Windows build 26220.7262 以上が前提で、Hostのpackage identityはpublic previewでは未強制ですが、stable releaseでは必要になる予定と記載されています。ここは今後変わりやすいため、実装時に最新ページを確認したいところです。

まとめ

MCP on Windowsを通常のMCP接続と比べると、整理しやすいポイントは次の3つです。

• Discovery: Hostごとの設定だけでなく、ODRから登録済みserverを見つける
• Trust & Permission: containment、ユーザー同意、管理ポリシーで利用範囲を制御する
• Lifecycle & Audit: serverの登録／解除と、接続・操作のログ記録や監査可能性をOS側の管理へ寄せる

MCP on Windowsは、MCPそのものをWindows専用に作り替える仕組みではありません。

MCPという共通の接続方法に、Windows端末で実用するための「発見・隔離・権限・管理」を重ねる仕組みです。AIエージェントがWindowsの機能へ自然に触れるほど、この地味な管理層が重要になってきそうです。

参考・引用情報

• Model Context Protocol (MCP) on Windows overview - Microsoft Learn
• Quickstart: MCP host on Windows - Microsoft Learn
• MCP servers on Windows overview - Microsoft Learn
• Securely containing MCP servers on Windows - Microsoft Learn
• The Windows on-device agent registry command-line tool (odr.exe) - Microsoft Learn
• Windows File Explorer MCP connector - Microsoft Learn
• Model Context Protocol specification