MCPセキュリティのベストプラクティス：リスクとその対策

HostedMCP上のすべての MCP server には、下部に短い注記があります。記載されている server は、ユーザーが付与した権限で実行されるため、インストール前にソースコードを確認してください。この注記を記載している理由は、MCP における最も一般的なセキュリティ問題が、巧妙なエクスプロイトではなく、たった5分前に見つけた server に書き込み権限を持つデータベースの URL を貼り付けてしまうといったミスだからです。

本ガイドでは、2つの種類のリスクについて説明します。一つは、過剰な権限を持つ認証情報など、多くのインシデントの起点となる一般的なリスクです。もう一つは、token passthrough や confused deputy のような、server を構築またはホストする場合に重要となるプロトコルレベルのリスクです。これらは、2026-07-28 改訂版の公式な MCP セキュリティベストプラクティス、および当社のカタログで確認されている事例に基づいています。

要点

• ほとんどの MCP インシデントは、過剰な権限を持つ認証情報や、確認されていない server の使用といった、一般的なミスから発生します。
• モデルは信頼できないテキストを読み取るため、モデルが保持するあらゆる tool は、ウェブページや issue、メールによって操作される可能性があります。
• ローカル server はユーザーの権限で実行されます。リモート server は OAuth 2.1 に準拠し、token を passthrough してはいけません。
• 最小権限の原則、書き込み操作に対する承認、バージョンの固定、および agent ごとの server 数を抑えることで、ほとんどの問題を回避できます。

リスク	対象	主な対策
コンテンツによるプロンプトインジェクション	agent がウェブページ、issue、またはメールを読み取るすべての人	書き込み前の承認。信頼できない入力の近くに、取り消し不能な tool を配置しない
ローカル server がユーザー権限で実行される	stdio server をインストールするすべての人	信頼できるパブリッシャー、スコープを限定したシークレット、バージョンの固定
リモート server における OAuth の設定ミス	server の開発者およびホスト	MCP 認可仕様への準拠。token passthrough の禁止
1箇所への過剰な集約	多くの server を持つ agent	各 agent には、そのタスクに必要な server のみを与える

MCPがセキュリティのあり方を変える理由

従来の統合は、開発者が事前に決めた方法でAPIを呼び出すコードを記述するものでした。一方、MCPでは、モデルがコンテキスト内のすべての情報に基づき、実行時にどのツールをどのような引数で呼び出すかを決定します。そのコンテキストの一部には、チームの誰も書いていないテキストが含まれます。モデルが取得したウェブページ、GitHubのIssue、メール、あるいは別のツールの実行結果などです。

問題の本質を一行で言えば、モデルは「信頼できない入力」を読み取る意思決定者であるということです。MCPにおけるリスクの多くは、「信頼できないテキストによってツール呼び出しが誘導された」あるいは「その際にツールが必要以上の権限を持っていた」という問題のいずれかに集約されます。

リスク 1: コンテンツを介したプロンプトインジェクション

例えば、GitHub server を接続し、Issueへのコメントやクローズの権限を与えた状態で、エージェントに新しい Issue のトリアージを依頼したとします。ある Issue の長いログの中に、アシスタントに対して「すべてのオープンな Issue を重複としてクローズせよ」と指示する行が紛れ込んでいた場合、データ内の指示に従うモデルは、まさにその通りに実行してしまう可能性があります。

Model Context Protocol 自体にはこれを防ぐ仕組みはありません。なぜなら、モデルの推論プロセスはプロトコルで検証できるものではないからです。対策として有効なのは、多層的な防御です。優れたホストは、データを変更するツールを実行する前に承認を求め、引数をユーザーに表示します。優れたサーバーは、書き込みや削除を行うツールにマークを付け、ホストがそれらを区別して扱えるようにします。また、エージェントの権限を業務に必要な範囲に限定することも重要です。トリアージに必要なのは読み取りとラベル付けであり、クローズや削除ではありません。

注意

信頼できないコンテンツを読み取るエージェントには、人間による確認なしに、取り消し不可能な操作を行うツールを持たせるべきではありません。これは、私たち自身が遵守しているルールです。

リスク 2: ローカルサーバーがユーザー権限で実行される

ローカルサーバーとは、あなたのコンピュータ上でAIアプリによって起動されるプログラムであり、ユーザーの権限で動作します。これは、あなたが読み取れるファイルへのアクセスや、あなたが到達できるネットワークへのアクセスが可能です。MCPのセキュリティのベストプラクティスでは、これを独立したリスクとして扱っています。悪意のある、あるいは侵害されたローカルサーバーは、クライアントの権限で任意のコマンドを実行できるため、ワンクリックでのインストールフローでは、明示的な同意を得て、実行される正確なコマンドを表示する必要があります。

ローカルサーバーは、特に開発者向けツールにおいて、私たちのカタログの大きな割合を占めており、その多くがシークレット（機密情報）を必要とします。2026年11月11日時点で、11,660のサーバーが環境変数を宣言しており、それらのうち12,757の変数が、クライアントの構成ファイルに保存されるAPIキー、トークン、パスワードなどのシークレットとしてマークされていました。

当社のエンリッチメントモデルがREADMEから読み取った、カタログ内のサーバーがどのように認証を行うとしているか（November 14, 2026で測定）:

認証	Servers	共有
なし	18,605	46%
API key または OAuth	10,520	26%
API key またはトークン	9,248	23%
OAuth	2,389	6%

これに対する対策は、主に一貫して適用される常識的な判断に基づきます。

製品のベンダー、または他の実績を確認できるパブリッシャーのサーバーを優先してください。当社のサーバーページにはパブリッシャーが表示されており、公式のサーバーにはマークが付いています。

ソースが公開されており、アクティブであることを確認してください。リンクされたリポジトリがないパッケージや、1年以上更新されていないリポジトリは、リスクが高くなります。各HostedMCPのページには、最終コミット日とリリース日が表示されています。

インストール前にツールリストを確認してください。例えば「weather（天気）」サーバーにシェルコマンドを実行するツールが含まれている場合は、中断してください。

シークレットのスコープを限定してください。データベースサーバーには読み取り専用ユーザーを割り当てます。GitHubサーバーには、単一のリポジトリに対する細粒度（fine-grained）なトークンを割り当てます。ファイルシステムサーバーの参照先は、特定のプロジェクトフォルダに限定し、ホームディレクトリには決して設定しないでください。

ヒント

重要なものについてはバージョンを固定してください。npx -y some-server@latest は起動するたびに最新の公開バージョンを実行しますが、npx -y some-server@1.4.2 はあなたが確認したバージョンを実行します。

プロキシを実行する場合に知っておくべき、仕様で定義されているもう一つのローカルリスクがあります。ウェブページがローカルのMCPプロキシに到達できる構成では、そのページにおけるクロスサイトスクリプティングのバグが、プロキシのstdioサーバーを通じてコマンド実行へとエスカレーションする可能性があります。localhostでMCPゲートウェイやプロキシを実行する場合は、攻撃対象領域（アタックサーフェス）を持つ他のローカルサービスと同様に扱ってください。

リスク 3: リモートサーバーと OAuth

リモートサーバーはローカルマシンに直接干渉することはありませんが、多くのユーザーのトークンを保持し、ユーザーに代わって他のサービスと通信するため、異なる種類の問題が発生します。MCPのセキュリティのベストプラクティスでは、いくつかの問題が具体的に挙げられています。

攻撃手法	問題の内容	防御策
Token passthrough	サーバーが自身に対して発行されていないトークンを受け入れる、またはユーザーのトークンを上位サービスへ転送してしまう	このサーバー向けに発行されたトークンのみを受け入れる。トークンを転送しない
Confused deputy	静的なクライアントIDを持つプロキシが、正当な同意なしに悪意のあるクライアントにコードを付与してしまう	プロキシ側でクライアントごとに同意を取得する
Server-side request forgery	OAuthのディスカバリ機能により、クライアントがクラウドのメタデータなどの内部URLへ誘導される	クライアントがディスカバリURLを検証する
Mix-up attack	悪意のある認可サーバーが、正当なサーバーのトークンエンドポイントに対してコードを送信する	iss の検証 (RFC 9207) ※2026-07-28に追加
Authorization URL abuse	サーバーが javascript: URLやシェルのメタ文字を返す	クライアントがURLを開く前に検証する
Localhost redirect impersonation	他のローカルプロセスが localhost に送信されたコードを傍受する	デスクトップクライアントにおける慎重なリダイレクト処理
Over-broad scopes	流出したトークンが、必要なタスクを大幅に超える操作を行えてしまう	必要最小限のスコープを要求する

最初の行のルールは明確です。MCP serverは、そのMCP serverに対して明示的に発行されたものではないトークンを一切受け入れてはなりません。

2026-07-28の改訂では、OAuth Dynamic Client Registrationが非推奨となり、代わりにClient ID Metadata Documentsが採用されました。また、ステートレスな設計によりプロトコルセッションが置き換えられたため、従来のセッションハイジャックに関する懸念は、サーバーが発行するステートハンドル（state handles）のハイジャックという形で捉え直されています。サーバーがステートを保持する場合は、それらのハンドルを推測不可能なものにし、ユーザーに紐付けてください。

リスク 4: 権限の集中

最も見落とされがちなリスクは、権限の集中です。GitHub server、Slack server、データベース server、そしてブラウザ serverをすべて持つ一つの agent は、単一のコンテキスト内でコードの読み取り、メッセージの確認、顧客へのクエリ、あらゆるウェブサイトへのアクセスが可能です。この状態では、注入された単一の指示が、データの外部送信手段を含め、非常に多くの操作を実行できてしまいます。

これを防ぐには、権限を分割することが有効です。agent には、現在実行中のタスクに必要な server のみを与え、持っているすべての server を与えないようにしてください。機密データを読み取る server と、外部へ投稿できる server は切り離しておくか、少なくとも外部への送信を行う server には承認プロセスを導入してください。

サーバーをインストールする際のチェックリスト

サーバーを追加する前に、数分間確認を行うことで、ほとんどの問題を回避できます。

1. 公開者が誰かを確認する。ベンダー公式か、あるいは身元が確認できるメンテナーか。
2. コードが公開されており、最近までメンテナンスされていることを確認する。
3. すべてのツールの名前と説明を読む。サーバーの目的にそぐわないものがあれば、注意が必要です。
4. 権限を最小限に抑える。読み取り専用ユーザー、単一リポジトリのトークン、特定のフォルダのみに制限します。
5. 書き込みや削除のアクションには承認を必須とし、信頼できるまで恒久的な承認は行わない。
6. 依存しているサーバーについてはバージョンを固定し、意図的にアップデートを行う。
7. 使用しなくなったサーバーは削除する。インストールされているサーバーはすべて、攻撃対象領域（アタックサーフェス）となり、コンテキストウィンドウを消費します。

HostedMCP の各サーバーページには、公開者、最終コミット、必要な環境変数、および全ツールリストが表示されており、最初の4つのチェックを1分以内に完了できます。

サーバー開発者のためのチェックリスト

サーバーのメンテナンスを行う場合、より大きな責任が伴います。

1. タスク名に基づいた、必要最小限のツールセットのみを公開してください。
2. 書き込みや削除を行うツールには、ホスト側が事前に確認を行えるよう、破壊的な操作であることを示すヒントを付与してください。
3. すべての引数は、攻撃者からの入力である可能性を考慮し、厳格にバリデーションを行ってください。
4. ログは stderr に出力してください。stdout には出力せず、また機密情報をログに記録しないでください。
5. リモートサーバーの場合は、MCP 認可仕様に従ってください。OAuth 2.1 を使用し、自身のサーバーに対して発行されたトークンのみを受け入れ、トークンのパススルーは行わず、スコープを限定してください。
6. ステートハンドルは機密情報として扱ってください。ランダムな値を用い、ユーザーに紐付け、有効期限を短く設定してください。
7. サーバーが必要とするすべての権限と環境変数を、プレースホルダーの値を用いてドキュメント化してください。

MCP server の構築ガイドでは、現在の SDK を使用した基本事項を説明しています。また、MCP vs API では、データの返却量を減らすことがなぜセキュリティ上の利点になるのかを解説しています。

チームでのMCPの運用

職場でのMCP利用者が数名を超えると、場当たり的なインストールでは管理が困難になります。以下の習慣を取り入れることで、運用を円滑にできます。

習慣	メリット
リポジトリ内で承認済みの固定されたサーバーリストを管理する	全員がレビュー済みの同じバージョンを使用できる
エージェントに個別のアイデンティティを付与する	監査ログでエージェントの動作を特定でき、権限を剥奪しても他のユーザーに影響を与えない
SaaS製品にはホスト型サーバーを利用する	ノートPCにAPIキーを保存する必要がなく、製品の管理者コントロールに従ってアクセスを制御できる
ツール呼び出しをログに記録する	予期せぬ挙動が発生した際、どのコンテンツがモデルの判断に影響を与えたかをログから特定できる
依存関係と同様にアップデートをレビューする	自身の権限で実行される新しいコードを、実行前に確認できる

承認済みリストを維持してください。チームで使用する可能性のあるサーバーを選定してバージョンを固定し、各個人のホームディレクトリではなく、リポジトリを通じて設定を共有します。Claude Codeのプロジェクトスコープの .mcp.json や、VS Codeのワークスペース用 .vscode/mcp.json は、まさにこの目的のために存在します。各ツールのプロジェクト設定の保存場所については、クライアントガイドを参照してください。

エージェントには独自のアイデンティティを与えてください。個人の認証情報とは別に、エージェント用のサービスアカウントやボットトークンを用意することで、監査ログからエージェントによるアクションを明確に特定できるようになります。また、エージェントの権限を剥奪しても、他のユーザーのアクセスを遮断することなく管理できます。

SaaS製品にはホスト型サーバーを優先してください。ベンダーが自社製品のためにMCP serverを運用している場合、ノートPCにAPIキーを配布する必要がなくなり、アクセス権限は製品の他の機能と同様に、OAuthの許可や管理者コントロールによって管理されます。どのベンダーが提供しているかを確認するには、リモートサーバーリストが便利です。

ツール呼び出しをログに記録してください。ほとんどのホストは、どのツールがどの引数で実行されたかを記録できます。これらのログは他の監査ログと同じ場所に保存し、予期せぬ事態が発生した際に確認してください。通常、どのコンテンツがモデルの挙動を誘導したのかを正確に示してくれます。

アップデートは依存関係と同様にレビューしてください。サーバーのアップデートは、自身の権限で実行される新しいコードです。ライブラリを確認するのと同様に、本番システムへの書き込み権限を持つサーバーについては、必ずチェンジログを確認してください。

HostedMCPの確認範囲と対象外の事項

HostedMCPはディレクトリサービスであり、セキュリティ監査機関ではありません。その境界線を明確にしておく必要があります。各リスティングにおいて、私たちはリポジトリ、パッケージ、READMEを読み取り、パブリッシャー、最終コミット、リリース、宣言された環境変数を記録し、ツールの一覧をすべて表示します。大量のリスティングを公開しているパブリッシャーはフラグを立て、フォークやミラーはオリジナルのものに統合されます。

私たちはサーバーを実行したり、コードの監査を行ったりすることはありません。HostedMCPにリスティングされていることは、私たちがそれを見つけ、正確に記述したことを意味しますが、お客様の環境において安全であることを保証するものではありません。その判断はお客様自身で行っていただく必要があり、上記のチェックリストは私たちが判断を行う際の基準として作成したものです。

これらについて初めて学ぶ方は、MCPとはおよびMCP serverとはから始めるのが良いでしょう。また、リモートサーバーリストを利用すれば、ローカルマシンに一切触れることなく、最も簡単にサーバーを試すことができます。