Windowsの「Model Context Protocol (MCP) on Windows overview」は、AIエージェントがWindows上のアプリや外部サービスに安全に接続するための共通基盤を示した公式情報です。結論から言うと、重要なのは Windows On-device Agent Registry（ODR） によって、MCPサーバーの発見・利用・管理・監査をWindows側で扱えるようにする点です。(Microsoft Learn)
管理者は「どのエージェントに、どのMCPサーバーを使わせるか」「ファイルアクセスを許可するか」「保護を弱める設定を有効にしていないか」を確認する必要があります。開発者は、MCPサーバーをWindowsに登録する方法、MSIXなどのパッケージID、manifest.json、odr.exeによる検証、権限要求の設計を見直すことが重要です。
なお、Microsoft Learnでは一部がプレリリース情報として扱われており、商用リリースまでに仕様が変わる可能性があります。現時点では、全社展開を急ぐよりも、検証環境で影響範囲・権限・ログ・展開方法を確認する段階と捉えるのが安全です。(Microsoft Learn)
Model Context Protocol (MCP) on Windows overviewの要点
Model Context Protocol（MCP）は、AIアプリケーションが外部のツールやデータソースと連携するためのオープンなプロトコルです。WindowsにおけるMCPのポイントは、単に「AIからツールを呼び出せる」ことではありません。Windows上でMCPサーバーを発見し、利用し、管理するための入口としてODRが用意される点にあります。(Microsoft Learn)
これにより、AIエージェントは個別アプリごとの独自連携ではなく、Windowsに登録されたMCPサーバーを通じて、ファイル操作やアプリ機能、リモートサービスなどの機能を利用できるようになります。
| 観点 | これまで起きやすかった課題 | MCP on Windowsで重視される方向性 |
|---|---|---|
| 連携方法 | アプリやAIツールごとに個別実装が必要 | MCPサーバーを標準的な方法で発見・利用 |
| 管理 | どのAIが何に接続するか把握しにくい | ODR、Windows設定、管理ツールで制御 |
| セキュリティ | ツール実行時の権限境界が曖昧になりやすい | 既定で分離されたエージェントセッションを利用 |
| 展開 | 手動設定や独自インストーラーに依存 | MSIX、MCP Bundle、odr.exeなど複数の登録方法 |
| 監査 | AIと外部ツールのやり取りを追跡しにくい | ログ記録・監査を前提にした管理が可能 |
特に重要なのは、MCP on Windowsが「便利なAI連携機能」ではなく、「AIエージェントに作業を任せるためのWindows側の管理基盤」として位置付けられていることです。
何が変わるのか：ODRがMCPサーバーの入口になる
MCP on Windowsでは、Windows On-device Agent Registry（ODR）が中心になります。ODRは、ローカルアプリやリモートサーバーが提供するMCPサーバーを、AIエージェントが発見して利用するための管理されたインターフェースです。Microsoftの公式説明では、ODRの利点として、標準化されたMCPサポート、発見しやすさ、セキュリティ、ユーザーと管理者による制御、ログと監査、Windows標準コネクタが挙げられています。(Microsoft Learn)
実務上の変化は、次のように整理できます。
| 変更点 | 実務への影響 |
|---|---|
| MCPサーバーをWindowsに登録できる | AIエージェントが利用できる機能をOS側で発見しやすくなる |
| ユーザーや管理者がアクセスを制御できる | 部門ごと、端末ごとに利用可否を管理する設計が必要 |
| 既定で分離された環境で実行される | MCPサーバーがユーザーセッションへ直接アクセスしにくくなる |
odr.exeで確認・管理できる | 展開後の登録確認やトラブルシュート手順に組み込める |
| File Explorer MCP connectorが含まれる | AIからファイル検索・読み取り・作成・編集などを扱う場面が出てくる |
ここで注意したいのは、MCPサーバーが「情報を返すだけの安全な部品」とは限らない点です。ファイル作成、ファイル移動、テキスト編集、zip作成など、環境を変更する操作を提供するMCPサーバーもあります。File Explorer MCP connectorの公式情報でも、ファイルの読み取りだけでなく、作成・移動・編集・圧縮・展開などのツールが示されています。(Microsoft Learn)
影響を受ける対象者
MCP on Windowsの影響は、AIアプリを開発する人だけに限られません。Windows端末を管理する情報システム部門、セキュリティ担当、業務アプリの開発者、アプリ配布を担当するチームにも関係します。
| 対象者 | 確認すべきこと |
|---|---|
| Windows管理者 | MCPサーバーの利用可否、端末設定、Intuneなどでの管理方針 |
| セキュリティ担当 | ファイルアクセス、権限境界、ログ、監査、プロンプトインジェクション対策 |
| アプリ開発者 | MCPサーバーの登録方法、manifest.json、MSIX、パッケージID |
| AIアプリ開発者 | ODRからMCPサーバーを列挙・接続・呼び出す実装 |
| ヘルプデスク | ユーザー許可、ファイルアクセス拒否、コネクタ利用不可時の問い合わせ対応 |
| エンドユーザー | AIがファイルやアプリ機能へアクセスする際の許可判断 |
企業利用では、最初に「誰がMCPを使うか」ではなく、「AIエージェントが何にアクセスできる状態になるか」を棚卸しするのが現実的です。
管理者が確認すべき設定と運用ポイント
対応Windowsビルドを確認する
Microsoftのクイックスタートや登録関連ドキュメントでは、前提条件としてWindows build 26220.7262以降が示されています。これはプレリリース段階の情報を含むため、本番端末で一斉に利用する前に、検証用リングで実際の設定項目、odr.exeの挙動、MCPサーバーの登録結果を確認してください。(Microsoft Learn)
展開前の確認としては、次の順番が実務向きです。
| 手順 | 確認内容 |
|---|---|
| 端末条件の確認 | 対象Windowsビルド、エディション、更新チャネル |
| ODRの確認 | odr.exeが利用できるか、MCPサーバー一覧を取得できるか |
| 権限の確認 | ファイルアクセス時にユーザー許可が必要になるか |
| 管理設定の確認 | Windows設定やIntuneなどで制御できる項目があるか |
| 監査の確認 | 利用ログをどの範囲で取得・保管できるか |
| 展開範囲の決定 | 開発者端末、検証端末、特定部門、本番端末の順に広げる |
「Reduce protections for agent connectors」は安易に有効化しない
特に注意すべき設定が、Settings > System > Advanced > AI components > Reduce protections for agent connectorsです。Microsoftのドキュメントでは、この設定を有効にするとMCPサーバーがより多くのアクセス権や特権で動作し、追加のセキュリティリスクにさらされる可能性があると説明されています。(Microsoft Learn)
この設定は、原則として検証用途に限定すべきです。社内展開で有効化する場合は、少なくとも次の条件を満たしてから判断します。
| 判断項目 | 確認ポイント |
|---|---|
| 利用目的 | なぜ既定の分離実行では不十分なのか説明できるか |
| 対象端末 | 開発者端末など限定された範囲か |
| MCPサーバーの入手元 | 社内開発、信頼済みベンダー、署名済みパッケージか |
| 代替策 | MSIX化、パッケージID付与、設計変更で回避できないか |
| 監査 | いつ、誰が、何のために有効化したか記録できるか |
便利だからという理由で全社的に有効化すると、MCP on Windowsが本来意図している分離・制御のメリットを弱めることになります。
ファイルアクセスは「ユーザー許可」と「ホスト単位の権限」に注意する
MCPサーバーは、既定ではユーザーのファイルへ直接アクセスできません。ユーザーファイルにアクセスするには、MCPサーバー側がAppxManifest.xmlで既知フォルダーのcapabilityを宣言し、利用時にユーザーの許可を得る流れになります。(Microsoft Learn)
見落としやすいのは、許可がMCPサーバー単位ではなくホストアプリ単位で付与される点です。Microsoftの説明では、あるホストが利用するMCPサーバーの1つに対してファイルアクセスが許可されると、同じホストアプリで使われる他のMCPサーバーもそのリソースへアクセスできる可能性があります。(Microsoft Learn)
つまり、管理者は「このMCPサーバーなら安全か」だけでなく、「同じホストアプリから呼び出される他のMCPサーバーも含めて許可してよいか」を考える必要があります。
開発者が確認すべき登録・移行ポイント
推奨はパッケージIDを持つアプリとして登録すること
MCPサーバーをWindowsに登録する方法は複数あります。公式情報では、パッケージIDを持つアプリ、パッケージIDを持たないアプリ、手動登録という選択肢が示されています。パッケージIDを持つアプリでは、必要なメタデータをアプリパッケージに含めることで、アプリのインストール・アンインストールに合わせてOSがMCPサーバーを自動登録・解除します。(Microsoft Learn)
| 登録方法 | 向いているケース | 注意点 |
|---|---|---|
| MSIXなどパッケージIDあり | 本番配布、企業配布、セキュアな運用 | manifestと署名、パッケージ設計が必要 |
| MSIX external location | 既存の非パッケージアプリにIDを付与したい場合 | インストーラー設計を見直す必要がある |
| MCP Bundle | スタンドアロン配布や検証 | 既定の分離実行では利用できない制約がある |
odr.exeによる手動登録 | リモートMCPサーバー、細かな検証 | 本番運用では手順管理と削除手順が重要 |
MCP Bundleは便利ですが、公式情報では、MCP Bundleで登録されたサーバーはエージェントセッションでサポートされず、既定ではWindows ODRからアクセスできないと説明されています。検証のために保護を弱める設定を使う選択肢はありますが、本番前提ならMSIXやパッケージIDを持つ形への移行を検討すべきです。(Microsoft Learn)
manifest.jsonの内容と実行時の応答を一致させる
WindowsでMCPサーバーを既定の保護モードで動かすには、manifest.jsonの内容が重要です。特に_meta内のcom.microsoft.windows、static_responses、tools/listは、ODRがMCPホストにツールを発見させるために使われます。(Microsoft Learn)
開発時にありがちな失敗は、コード側でツール名や入力スキーマを変更したのに、manifest.jsonを更新し忘れることです。Microsoftのドキュメントでは、MCPBファイルに宣言された値と実行時にサーバーが返す値が一致しない場合、既定モードで動作しなくなる可能性が示されています。(Microsoft Learn)
チェックすべき項目は次の通りです。
| チェック項目 | 確認内容 |
|---|---|
nameとversion | manifestと実行時のserverInfoが一致しているか |
tools/list | ツール名、説明、入力スキーマ、出力スキーマが一致しているか |
| 動的変更 | 実行時にツール一覧やスキーマを変えていないか |
_meta | com.microsoft.windows配下に必要な静的応答があるか |
| 更新手順 | サーバー更新時にmanifestも同時更新する仕組みがあるか |
AIエージェント向けの機能は、少しのスキーマ差異でも呼び出し失敗や意図しない挙動につながります。CIでmanifestと実装の整合性を検証する仕組みを入れると、配布後のトラブルを減らせます。
odr.exeで登録状態を確認する
ODRには、MCPサーバーの発見・管理に使うコマンドラインツールとしてodr.exeが用意されています。公式のCLIドキュメントでは、MCP関連のコマンドとして、実行、一覧表示、追加、削除、構成が示されています。(Microsoft Learn)
検証時は、少なくとも次の確認を行います。
odr.exe --help
odr.exe listまた、CLIの説明ではodr mcp [command]形式も示されています。プレビュー段階ではドキュメントやビルドによって表記が変わる可能性があるため、実際の対象ビルドで--helpを確認し、社内手順書には確認済みのコマンドを記載してください。(Microsoft Learn)
MCP Inspectorで機能を先に検証する
MCPサーバーをWindowsアプリに組み込む前に、MCP Inspectorで単体テストを行うと問題を切り分けやすくなります。公式ドキュメントでは、Node.jsをインストールしたうえで、PowerShellから次のように実行する手順が示されています。(Microsoft Learn)
npx @modelcontextprotocol/inspector <path to your .exe>テストでは、単にツールが呼べるかだけでなく、危険な入力、存在しないファイル、権限不足、ネットワークエラー、タイムアウト、空の応答なども確認してください。AIエージェントは人間のUI操作よりも多様な入力を生成するため、通常のアプリテストよりも「曖昧な指示」「誤ったパス」「権限のない操作」を厚めに検証するのが実務的です。
File Explorer MCP connectorで注意すべきこと
Windows File Explorer MCP connectorは、MCPサーバーを通じてファイルにアクセス・変更するためのツール群を提供します。対象にはDocuments、Desktop、Downloads、Music、Videos、Pictures、パブリックフォルダーなどの一般的なユーザーフォルダーが含まれます。ただし、ファイルアクセスには明示的なユーザー許可が必要で、ユーザーや管理者が拒否できる点が明記されています。(Microsoft Learn)
提供される操作には、読み取り系と変更系があります。
| 種類 | 例 | 管理上の見方 |
|---|---|---|
| 読み取り系 | ファイル詳細取得、ファイル読み取り、ディレクトリ一覧、検索 | 情報漏えいリスクを確認 |
| 変更系 | ディレクトリ作成、ファイル移動、テキストファイル作成、テキスト編集 | 誤操作・改ざん・削除相当の影響を確認 |
| 圧縮・展開 | zip作成、zip展開 | 大量ファイル生成や意図しない展開先に注意 |
| 検索 | ファイル名、拡張子、日付範囲、スニペット検索 | 検索結果に機密情報が含まれる可能性を確認 |
Copilot+ PCでは、自然言語によるセマンティックなファイル検索が含まれる場合があります。便利な一方で、ユーザーが明示的なファイル名を指定していなくても関連ファイルが見つかる可能性があるため、機密フォルダーの扱い、DLP、共有端末での利用方針をあらかじめ決めておく必要があります。(Microsoft Learn)
展開前に確認したいチェックリスト
MCP on Windowsを検証・展開する際は、機能確認だけでなく、管理とセキュリティを同時に確認することが重要です。
| フェーズ | 確認項目 | 失敗しやすいポイント |
|---|---|---|
| 企画 | どの業務でMCPを使うか | 「AI活用」の名目で対象業務が曖昧になる |
| 技術検証 | 対応ビルド、ODR、odr.exe、MCP Inspector | 開発端末では動くが管理端末で動かない |
| 権限設計 | ファイル、ネットワーク、ユーザー許可 | ホスト単位の許可を見落とす |
| パッケージ設計 | MSIX、外部ロケーション、署名、manifest | MCP Bundleの制約を本番直前に知る |
| 管理設計 | Windows設定、Intune、監査ログ | 正式な管理項目名を決め打ちして手順化する |
| ユーザー周知 | 許可ダイアログ、AIの操作範囲、問い合わせ先 | ユーザーが意味を理解せず許可する |
| 本番展開 | 段階展開、ロールバック、無効化手順 | 問題発生時に止める方法が決まっていない |
特に企業環境では、「使えるようにする手順」よりも「使わせない、止める、調査する手順」を先に決めておくべきです。AIエージェントはファイルやアプリ機能を横断して使うため、通常の単体アプリよりも影響範囲が広くなります。
よくある誤解と注意点
MCPはAIの回答精度を自動で保証するものではない
MCPは、AIアプリケーションと外部システムを接続するためのプロトコルです。Microsoftの概要でも、AI生成の応答や出力はユーザーの意図を反映しない場合があり、正確性を確認する必要があると説明されています。(Microsoft Learn)
つまり、MCPを導入しても、AIの判断が常に正しくなるわけではありません。MCPによってAIが実行できる作業が増える分、承認フロー、確認画面、ログ、取り消し手段がより重要になります。
「ローカル実行だから安全」とは限らない
MCPサーバーがローカルで動作していても、インターネットアクセス、ファイル操作、別プロセスの実行などが絡む場合があります。Microsoftの分離実行に関する説明では、含まれたMCPサーバーはユーザーのファイル、設定、レジストリ、資格情報、ユーザーが使っているアプリやウィンドウへ直接アクセスできない一方、エージェント側のファイルやレジストリ、インターネット、一定のユーザーファイルには条件付きでアクセスできるとされています。(Microsoft Learn)
安全性を判断するときは、「ローカルかリモートか」ではなく、「どの権限で、どのリソースへ、どの操作ができるか」で評価してください。
MCPサーバーを増やすほど便利だが、管理対象も増える
MCPの強みは、AIエージェントがさまざまなツールを動的に発見して利用できることです。一方で、登録されるMCPサーバーが増えるほど、管理者が把握すべき接続先、権限、ログ、更新管理も増えます。
開発チームごとに自由にMCPサーバーを追加させる前に、最低限の登録ルールを決めておくとよいでしょう。
| ルール | 具体例 |
|---|---|
| 命名規則 | 部門名、用途、環境を含める |
| 所有者 | 問い合わせ先と保守担当を明記 |
| 権限 | 読み取り専用か、変更操作を含むかを分類 |
| 配布方法 | MSIX、社内配布、手動登録を明確化 |
| 更新 | manifest更新、署名、検証手順を必須化 |
| 廃止 | 使われなくなったMCPサーバーを削除する基準を決める |
まず取るべき行動
MCP on Windows overviewを読んで最初に行うべきことは、機能を試すことではなく、影響範囲を小さく区切って確認することです。
管理者は、検証端末でODRとodr.exeの状態を確認し、File Explorer MCP connectorのようにファイル操作を伴うコネクタがどのように許可を求めるかを把握してください。開発者は、MCPサーバーをMSIXなどパッケージIDのある形で登録できるか、manifest.jsonと実行時応答が一致しているか、MCP Inspectorで単体検証できるかを確認します。
現時点のMCP on Windowsは、AIエージェント活用をWindowsの管理下に置くための重要な基盤です。だからこそ、導入判断では「何ができるか」だけでなく、「誰が許可し、誰が監査し、問題が起きたときにどう止めるか」までセットで設計することが、実務上の成功条件になります。
コメント