Visual StudioのMCP trust validationとは？警告の意味と安全な承認手順

Visual Studio 2026でGitHub CopilotのMCPツールを使おうとしたときにtrust確認が表示されるのは、MCPサーバーの設定や提供機能が、前回信頼した状態から変わったためです。警告が出ただけで、マルウェア感染や不正アクセスが発生したと判断する必要はありません。

ただし、内容を見ずに承認するのは危険です。MCPサーバーの配布元、接続先URL、起動コマンド、追加されたツール、OAuthやPATに付与する権限を確認し、想定どおりの変更である場合だけAcceptを選びます。変更理由が分からない場合は、いったんRejectを選ぶのが安全です。Always Trustは、将来の変更確認まで省略するため、原則として安易に選ばない方がよいでしょう。

MCP trust validationは、2026年6月9日に公開されたVisual Studio 2026 June Update 18.7.0で既定有効になりました。GitHubは2026年7月14日付のChangelogで、C++ modernization agentの一般提供やlong-distance next editとあわせて、この変更を案内しています。(The GitHub Blog)

MCP trust validationで何が変わったのか

MCPはModel Context Protocolの略称です。GitHub Copilotと外部のファイル、リポジトリ、データベース、クラウドサービスなどを接続し、Copilotから専用ツールを呼び出せるようにします。

たとえば、MCPサーバーを追加すると、Copilotから次のような操作が可能になります。

GitHubのIssueやPull Requestを検索する
Azure DevOpsの作業項目を作成する
データベースへ問い合わせる
ローカルファイルを読み書きする
外部APIを呼び出す
コマンドを実行する

便利になる一方で、MCPサーバーの設定や機能が差し替えられると、以前とは異なる処理が実行される可能性があります。MCP trust validationは、その変化を検出して再承認を求める安全機能です。

Visual Studioでは、MCPサーバーの起動時に次の2段階で検証します。

検証段階	比較される内容	警告が出る主な例
Configuration trust	接続方式、URL、起動コマンド、引数など	接続先ドメインが変わった、実行コマンドが追加された、引数が変更された
Asset trust	tools、prompts、resources、resource templates、instructions	書き込みツールが追加された、サーバー指示が変わった、参照可能なリソースが増えた

Configuration trustはサーバープロセスを起動する前に確認されます。一方、Asset trustはサーバーを起動して機能一覧を取得した後、以前保存したフィンガープリントと比較します。差分が検出されると、変更内容を確認するtrustダイアログが表示されます。(Microsoft Learn)

初回接続ではtrustダイアログが出ない点に注意

重要なのは、初めて認識されたMCPサーバーは自動的に初期ベースラインが保存され、trustダイアログが表示されないことです。

つまり、MCP trust validationは「初めて追加するサーバーが安全か」を判定する仕組みではありません。前回から変更されたかどうかを検知する仕組みです。

新規MCPサーバーを追加するときは、警告が表示されなくても、配布元や設定内容を自分で確認する必要があります。組み込みサーバー、組織のポリシーで事前承認されたサーバー、過去にAlways Trustを選んだサーバーでも、trustダイアログは省略されます。(Microsoft Learn)

MCPのtrust警告が表示される主な理由

trustダイアログは、必ずしも不正な変更を意味しません。通常のアップデートやチーム内の設定変更でも表示されます。

発生場面	変更内容の例	確認する場所
リポジトリをpullした	`.mcp.json`が更新された	Gitの差分、変更したコミット、Pull Request
ブランチを切り替えた	ブランチごとに異なるMCP設定がある	対象ブランチの`.mcp.json`
MCPパッケージを更新した	パッケージのバージョンや公開ツールが変わった	パッケージ公式リポジトリ、リリースノート
コンテナーイメージを更新した	イメージタグや起動引数が変わった	`docker run`設定、イメージの提供元
リモートMCPサーバーが更新された	toolsやresourcesが追加・削除された	trustダイアログの差分、サーバーの変更履歴
認証方式を変更した	OAuth、PAT、ヘッダー、環境変数が変わった	MCP設定、認証画面、トークンの権限
チームメンバーが設定を編集した	URLやcommand、argsが変更された	Gitの履歴、変更者、レビュー記録

特に注意したいのが、npxなどで常に最新版を取得する設定や、固定されていないコンテナーイメージタグです。Visual StudioはMCP設定に書かれたコマンドをそのまま利用するため、バージョンを固定していない構成では、利用者が設定ファイルを編集していなくてもサーバー側の更新が発生しやすくなります。Visual Studioの公式ドキュメントでも、MCPサーバーのバージョンや実行オプションを固定できることが案内されています。(Microsoft Learn)

trust承認とツールの実行許可は別の確認

MCPを安全に運用するには、次の3種類の承認を分けて考える必要があります。

確認の種類	判断する内容	主な確認対象
サーバーのtrust	更新されたMCPサーバーを起動してよいか	URL、command、args、tools、prompts、resources
認証・認可	MCPサーバーにどのデータへのアクセスを許可するか	OAuthスコープ、PAT権限、接続アカウント
ツール実行の許可	今回の具体的な操作を実行してよいか	ファイル変更、コマンド実行、Issue作成、データ更新

trustでAcceptを選んでも、すべてのMCPツールが無条件で実行されるわけではありません。Visual Studioでは、MCPサーバーが提供するツールは既定で無効になっており、必要なツールを利用者が選択します。さらに、ツール実行時には確認が表示され、現在のセッション、現在のソリューション、将来の実行など、許可する範囲を選べます。(Microsoft Learn)

反対に、ツールの実行確認があるからといって、不明なMCPサーバーをtrustしてよいわけでもありません。trustはサーバー自体、認証はアクセス可能なデータ、ツール確認は個別の操作を制御するものです。

MCP trustを安全に承認する手順

MCPサーバーの配布元を確認する

最初に、表示されたサーバーが自分または所属組織で利用を認めているものか確認します。

確認対象は、サーバー名だけでは不十分です。次の情報まで照合してください。

開発元または管理元
公式リポジトリ
接続先ドメイン
パッケージ名
コンテナーイメージの提供元
バージョン
社内で承認されたサーバー一覧

サーバー名は任意に付けられるため、githubやazureという名前だけで公式サーバーとは判断できません。リモートサーバーではURL、ローカルサーバーでは実行コマンドとパッケージ名が重要です。

どのMCP設定ファイルが読み込まれたか確認する

Visual Studioは複数の場所からMCP設定を検出します。代表的な保存場所は次のとおりです。

保存場所	影響範囲
`%USERPROFILE%\.mcp.json`	そのユーザーが開くすべてのVisual Studioソリューション
`<SOLUTIONDIR>\.vs\mcp.json`	特定ソリューション、特定ユーザー
`<SOLUTIONDIR>\.mcp.json`	特定ソリューション。ソース管理への登録も可能
`<SOLUTIONDIR>\.vscode\mcp.json`	同じリポジトリを利用する別エディターと共有される可能性がある
`<SOLUTIONDIR>\.cursor\mcp.json`	別エディター向けの設定をVisual Studioが検出する場合がある

グローバル設定が変更されていれば、複数のソリューションに影響します。一方、リポジトリ内の.mcp.jsonは、Gitのpullやブランチ切り替えによって変更される可能性があります。(Microsoft Learn)

リポジトリ管理されたMCP設定は、単なるエディター設定ではなく、外部プログラムやサービスを起動する実行設定として扱うべきです。コードレビューの対象にし、必要に応じてCODEOWNERSなどで承認者を限定すると安全性を高められます。

URL、command、argsを比較する

trustダイアログやGitの差分で、次の項目を確認します。

url
接続方式やtransport
command
args
パッケージ名
パッケージのバージョン
コンテナーイメージとタグ
環境変数
HTTPヘッダー
認証情報の参照方法

特に次の変更があった場合は、すぐに承認せず理由を確認してください。

公式ドメインから別ドメインへ変更された
cmd.exe、PowerShell、シェルスクリプトなどの実行が追加された
新しいダウンロード処理が加わった
ホームディレクトリやドライブ全体をコンテナーへマウントする設定が追加された
@latestなど、実行のたびに内容が変わり得る指定になった
トークンやパスワードを渡す環境変数が追加された
PATやAPIキーが設定ファイルへ直接記載された

変更が正当なアップデートであっても、利用目的に対して必要以上の構成になっていないか確認します。

追加されたtoolsやresourcesを確認する

Asset trustの警告では、MCPサーバーが提供する次の要素が変更されている可能性があります。

tools
prompts
resources
resource templates
instructions

ツール名だけでなく、そのツールが何を読み、何を変更できるかを確認してください。

機能	リスクの目安
公開ドキュメントの検索	比較的低い
リポジトリやIssueの読み取り	中程度
ローカルファイルの読み取り	対象範囲によって高い
ファイルの作成・上書き	高い
Pull RequestやIssueの作成・更新	高い
データベースへの書き込み	高い
任意コマンドの実行	非常に高い
シークレットや資格情報へのアクセス	非常に高い
クラウドリソースの作成・削除	非常に高い

「コード検索だけに使っていたサーバーへ、ファイル削除ツールが追加された」といった変更は、利用目的と一致しません。理由が確認できるまでRejectを選び、必要なツールだけを有効にします。

Visual StudioはMCPサーバーからツール一覧の変更通知を受けると、既存のツール承認をリセットして一覧を取得し直します。これは、最初は安全な機能だけを提供し、後から危険な機能へ差し替える攻撃を抑えるための動作です。(Microsoft Learn)

OAuthやPATの要求権限を確認する

MCPのtrustと、接続先サービスへのアクセス権限は別です。リモートMCPサーバーで認証画面が表示された場合は、次の内容を確認します。

接続するアカウント
対象の組織やリポジトリ
読み取り権限か書き込み権限か
IssueやPull Requestの更新権限
Actionsやワークフローの操作権限
管理者権限
トークンの有効期限
トークンを利用できるリポジトリの範囲

GitHub MCP serverをOAuthで利用する場合、サーバーはサインイン時に承認したスコープの範囲でアクセスします。PATを使用する場合は、そのPATへ付与したスコープがMCPサーバーのアクセス範囲になります。目的に必要な最小限の権限だけを付与することが重要です。(GitHub Docs)

コードやIssueの参照だけが目的であれば、書き込み権限や管理者権限を求める構成は見直すべきです。認証画面の要求が想定より広い場合は、その場でキャンセルし、MCPサーバーの設定と公式ドキュメントを確認してください。

Accept、Always Trust、Rejectの選び方

trustダイアログでは、変更内容に応じて次の判断を行います。

選択肢	動作	適切な場面
Accept	現在の変更を承認し、新しい状態をベースラインとして保存する	公式アップデートや承認済みの設定変更と確認できた
Always Trust	今後、そのサーバーについてtrust確認を表示しない	組織が一元管理し、変更経路も厳格に管理している特殊な環境
Reject	サーバーの起動を中止する	変更理由が不明、接続先が変わった、権限が広がった、確認担当者が不在

Acceptを選んでも、次回さらに設定や機能が変われば再び確認されます。通常はこの選択が適切です。

Always Trustを選ぶと、将来の設定変更や機能追加に対する警告が表示されなくなります。便利さよりも変更検知を失う影響の方が大きいため、個人が追加した外部MCPサーバーや、常に最新版へ更新されるサーバーでは避けるのが安全です。

Rejectを選ぶとサーバーは起動されず、次回有効化を試みた際に再度trustが検証されます。拒否してもMCP設定そのものが削除されるわけではないため、落ち着いて差分や配布元を確認できます。(Microsoft Learn)

警告が出たら承認を見送るべきケース

次のいずれかに該当する場合は、いったんRejectを選ぶのが妥当です。

そのMCPサーバーを追加した記憶がない
サーバー名は同じだがURLが別ドメインへ変わっている
ローカルコマンドやスクリプトが新たに追加されている
パッケージの配布元が変わっている
追加されたツールの用途を説明できない
読み取り専用だったサーバーに書き込み機能が追加された
OAuthやPATの権限が以前より広くなった
リポジトリのPull Requestで.mcp.jsonが十分にレビューされていない
環境変数やヘッダーに不明な資格情報が追加された
正式なアップデート情報を確認できない

業務端末では、自己判断でAlways Trustを選ばず、セキュリティ担当者やGitHub Copilot管理者へ確認してください。

MCP trust validationの設定場所

MCP trust validationはVisual Studio 2026 version 18.7以降で利用できます。設定は次の場所にあります。

［ツール］→［オプション］→［GitHub］→［Copilot］→［Copilot Chat］

その中の次の設定で、更新されたMCPサーバーに対するtrustダイアログを制御します。

Show trust dialog before running tools from an updated MCP server

この項目が見つからない場合は、Visual Studio 2026 version 18.7以降へ更新されているか確認してください。UIの表示名は、Visual Studioの言語や更新状況によって異なる場合があります。(Microsoft Learn)

trustダイアログを無効にしても、MCPサーバーの変更が安全になるわけではありません。更新前後の差分を確認する機会を失うため、特別な運用上の理由がない限り、既定の有効状態を維持する方が安全です。

組織ではMCPサーバーのallowlistも利用する

GitHub Copilot BusinessやEnterpriseを組織で利用している場合は、個々の利用者によるtrust判断だけに依存しない運用が重要です。

Visual Studio 2026は、GitHub側で設定されたMCPサーバーのallowlistを参照できます。allowlistが構成されている場合、承認されていないMCPサーバーへの接続はVisual Studioでブロックされます。これにより、機密データを処理できるMCPサーバーを組織側で限定できます。(Microsoft Learn)

組織運用では、次のルールを決めておくと安全です。

利用可能なMCPサーバーをallowlistで限定する
.mcp.jsonをコードレビュー対象にする
MCP設定の承認者を決める
パッケージやコンテナーのバージョンを固定する
OAuthやPATを最小権限にする
読み取り専用ツールと書き込みツールを分ける
Always Trustを選択できる条件を明文化する
本番データへ接続するMCPサーバーは検証環境で先にテストする

C++ modernization agentも同更新で一般提供

Visual Studio 2026 June Updateでは、GitHub Copilot modernization agentのC++向けMSVCアップグレード機能がプレビューを終了し、一般提供になりました。

C++ modernization agentは、C++プロジェクトを分析し、互換性の問題を特定したうえで、最新のMSVC Build Toolsへ移行する計画を実行します。

モード	動作	向いている場面
Automated	評価、計画、変更を一連の処理として進める	小規模な検証用プロジェクト、変更をすぐ戻せる環境
Guided	評価、計画、実行の各段階を確認しながら進める	業務システム、大規模プロジェクト、慎重な移行

利用するには、ソリューションエクスプローラーでプロジェクトまたはソリューションを右クリックしてModernizeを選ぶか、Copilot Chatで@ModernizeにMSVCの更新を依頼します。(Microsoft Learn)

一般提供になった機能でも、生成された変更が自動的に正しいとは限りません。業務プロジェクトではGuidedモードを利用し、専用ブランチでビルド、単体テスト、静的解析、動作確認を行ってからマージするのが安全です。

long-distance next editは既定で無効

同じJune Updateには、long-distance next edit suggestionsも含まれています。

従来のnext edit suggestionsは、カーソル位置の近くを中心に次の編集候補を提案していました。long-distance next editでは、現在開いているファイル内の離れた場所にも関連する編集を提案できます。

たとえば、メソッド名を変更したときに、ファイル下部にある呼び出し箇所やコメントの修正を提案するといった使い方が想定されます。

ただし、MCP trust validationとは既定値が異なります。

機能	既定状態
MCP trust validation	有効
long-distance next edit suggestions	無効

long-distance next editを試す場合は、次の場所で有効にします。

［ツール］→［オプション］→［テキストエディター］→［Inline Suggestions］→［Enable extended range suggestions］

提案範囲がファイル全体へ広がるため、承認する前に変更箇所を一つずつ確認してください。(Microsoft Learn)

Visual Studio更新前に確認しておくこと

Visual Studio 2026 version 18.7以降へ更新する前に、次の項目を整理しておくと、trust警告が表示された際に判断しやすくなります。

現在利用しているMCPサーバーの一覧
各サーバーの開発元と管理担当者
グローバルおよびリポジトリ内のMCP設定ファイル
現在のURL、command、args、バージョン
有効にしているMCPツール
OAuthやPATに付与している権限
本番環境へ書き込み可能なツール
組織のallowlist設定
AcceptとAlways Trustの判断ルール
問題発生時にトークンを失効させる手順

特に.mcp.jsonがソース管理されている場合は、Visual Studioの更新だけでなく、Pull Requestのレビュー手順も見直してください。MCP設定の変更は、依存パッケージの更新やCI/CD設定の変更と同じように扱う必要があります。

MCP trust validationは無効化せず、差分を確認して承認する

Visual StudioのMCP trust validationは、MCPサーバーの設定や提供機能が前回から変わったことを知らせる安全機能です。警告自体は攻撃の証拠ではありませんが、内容を確認せずに承認してよいものでもありません。

trustダイアログが表示されたら、まずサーバーの配布元とMCP設定の変更履歴を確認します。次に、URL、起動コマンド、追加されたtoolsやresources、OAuthやPATの要求権限を確認してください。

正当な更新と確認できた場合はAccept、理由を確認できない場合はRejectが基本です。Always Trustは将来の変更検知を失うため、厳格に管理されたサーバー以外では避けます。

最初に行うべきことは、Visual Studioを更新する前に、現在の.mcp.jsonと認証権限を棚卸しすることです。そのうえでMCP trust validationを有効なまま運用し、必要なMCPツールだけを最小権限で利用してください。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。