MCPの仕組みとセキュリティの基本概念
Model Context Protocol（MCP）は、LLMと社内ドキュメント、各種SaaS、さらには開発環境をシームレスに接続するための標準仕様です。その利便性は極めて高い一方、認証情報の管理やアクセス権限、通信経路自体が新たな「攻撃面（アタックサーフェス）」となり得る点は無視できない課題です。導入に際しては、構成要素と通信方式の特性を深く理解し、どの境界を守るべきかを明確に定義することが重要です。
ClientとServerとHostの構成要素から見る攻撃対象
MCPのアーキテクチャは、主にHost、Client、Serverの3要素で構成されています。
- Host： UIや実行環境を提供してユーザーとの接点を担う
- Client： LLMと各Server間の橋渡し（仲介）を行う
- Server： 外部サービスや各種機能を「Tool」として公開し、要求に応じた処理を実行する
セキュリティ上の懸念は、これら3つの層すべてに存在します。まずHostおよびClient側では、設定ファイルやログ、さらにはプロンプト内に含まれる機密情報の漏洩が懸念され、APIキーの流出や権限の不正奪取を招くリスクが潜んでいます。対するServer側では、実装上の脆弱性や依存パッケージの不備、アップデート経路の安全性が焦点となるでしょう。
さらに、ClientからServerへ渡される「入力」と、Serverから返される「出力」が形成する境界面も重要です。もし出力結果の中にLLMの挙動を誘導する悪意ある指示が紛れ込んだ場合、意図しない操作を実行させられるといった脆弱性が顕在化する恐れもあります。
stdioとstreamable HTTPの通信方式によるリスクの違い
MCPの通信方式は、同一端末内のプロセス間通信である「stdio」、およびネットワークを介した「streamable HTTP」に大別され、それぞれリスクの性質が異なります。
stdioは通信がローカルで完結するため外部公開を避けやすいメリットがある一方、起動されるServerプロセスが端末内のローカル環境に直接干渉する形態をとります。万が一、悪意あるServerを起動してしまった場合、ファイルの不正読み取りや任意のコマンド実行など、端末側の資産に甚大な被害が及ぶ可能性があります。
一方でstreamable HTTPはServerを別のホストへ分離できるため、端末資産への直接的なアクセスを避ける設計にしやすい点が特徴です。ただし、ネットワークを介する以上、TLSによる暗号化や厳格な認証・認可、到達範囲の制御といった中間者攻撃への対策は必須。複数のクライアントから呼び出しが行われる構成では、設定の不備によって意図しないデータがServer側に集約されてしまうというリスクにも警戒が必要です。
LLMが外部ツールを操作する仕組みとセキュリティの重要性
MCPにおいて、LLMは提示された選択肢から「どのToolを使用するか」を自律的に判断し、Clientがその呼び出しを代行します。この一連の流れにより、ドキュメント参照からチケット作成、コードの変更までを連続的に遂行できる利便性が生まれます。
しかし、LLMは入力や出力に含まれる情報のコンテキストに影響を受けやすいため、解釈の誤りや外部からの誘導が発生した場合、付与された権限を悪用して不適切な操作を実行してしまう懸念があります。例えば、参照した文書内やServerの応答に巧妙に仕込まれた指示によって、本来アクセスすべきでないデータを取得したり、外部サーバーへ情報を送信したりするケースが考えられるでしょう。
こうした事態を防ぐには、重要な操作の直前に人間による承認工程を設ける「Human-in-the-loop」の徹底が欠かせません。Toolごとの実行許可範囲を最小化して、送信前に対象データをユーザーに明示するなど、技術的な対策と運用設計の両面から多層的な防御を固めることが導入の前提となります。
MCP Clientに潜む脅威と情報漏洩リスク
MCP Clientは、LLMと各MCP Serverの間で認証情報や送受信データを一括して取り扱う役割を担います。あらゆるリソースの統合点として機能するその利便性の高さは頼もしいものの、一方で、設定や権限管理のわずかな綻びが組織全体の情報漏洩を招いてしまう起点になるリスクも孕んでいます。まずはClient周辺に潜む典型的なセキュリティ上の落とし穴を整理したうえで、その対策を具体的に講じるべきでしょう。
設定ファイルへのAPIキー平文保存が招く不正アクセス
ClientがServerと接続するために保持するAPIキーやアクセストークンに関し、平文（テキスト形式）で設定ファイル内に保存する運用は極めて高いリスクを伴います。
こうした平文保存は、端末への不正侵入や共有ミスによって、被害を一気に拡大させる要因です。よくある事故の例としては、設定ファイルを誤ってリポジトリへコミットする、チーム内での共有を目的として安易に配布する、あるいはバックアップやログ収集プロセスに機密情報が巻き込まれる、といったケースなど。攻撃者がこれらのキーを入手すれば、Serverを介して社内ドキュメントへ自由にアクセスしたり、外部SaaSを乗っ取られたりする事態を招きます。
これを回避するには、「機密情報を設定ファイルに直接書き込まない」という大原則の徹底が不可欠です。OSの資格情報ストアや専用のSecrets Managerの活用、環境変数の適用範囲の限定、さらには短命な期限付きトークンへの移行なども有効な手段となるでしょう。あわせて、コミットスキャンによる漏洩検知、および即座にキーを無効化できる失効手順を整備しておけば、被害の長期化を防ぐことが可能になります。
最小権限の原則に反した過剰な権限付与の危険性
利便性を優先するあまり、Clientに対して本来不要なほど広い権限を与えてしまう傾向も見られますが、これは「最小権限の原則」に反し、事故や侵害時の被害を著しく増幅させる要因です。
例えば、情報の読み取りだけで完結する業務において「書き込み権限」まで付与されていた場合、LLMの判断ミスや外部からの誘導によって、ドキュメントの改ざんやチケットの大量起票、意図しない外部送信といった操作が実行される恐れがあるでしょう。特に管理者権限を持つトークンを常用していると、一度の漏洩が全社的なセキュリティ・インシデントに直結するリスクもあります。
対策としては、Tool単位で「実行可能な操作」を最小限に絞り込む設計が有効です。読み取りと書き込みの権限を分離し、アクセス対象をプロジェクトやフォルダ単位で限定すべきでしょう。高リスクな操作には専用のアカウントやトークンを割り当て、実行直前に確認画面や承認フローを介在させれば実運用における不慮の事故を抑制できます。
複数のMCP Server接続時に発生する意図しないデータ連携
Clientが複数のMCP Serverと同時に接続している状況下では、LLMのコンテキスト（文脈）が複数のドメインを跨いでしまい、意図しないデータ連携が発生しやすくなります。
具体的なリスクとしては、たとえば、社内ドキュメントを参照するServerと外部SaaSへ投稿するServerを同一セッションで使用しているケース。この場合、社内の機密情報が、要約文や添付データの一部として知らぬ間に外部ツールへ混入してしまう恐れが生じます。これはLLM自体の不備というより、Client側における「コンテキストの共有範囲」と「Tool呼び出しの境界線」が曖昧であることに起因します。
このリスクを回避する有効な対策は、業務の用途に応じて接続先を論理的に分離すること。機密データを扱う際は外部連携用のServerを物理的に無効化し、逆に外部投稿が必要な場面では入力できるデータを厳格に制限します。加えて、送信前にLLMが構成した本文や添付候補をユーザーへ明示し、禁止ワードや機密分類の自動チェックを挟めば、情報の「横漏れ」を防ぐ多層的なガードレールが構築されるでしょう。
MCP Serverの選定基準とサプライチェーンリスク
MCP Serverは、外部ツールや社内データへの「入り口」を司る重要なコンポーネントです。ここでの選定を誤れば、サプライチェーン由来の侵害が組織全体へ波及する起点となりかねません。 公式提供のものとサードパーティ製では信頼の前提が異なるため、配布経路や更新頻度、権限の制御範囲を軸とした厳格な確認ポイントを整理しておく必要があります。
公式リポジトリReference Serversとサードパーティの違い
公式のReference Serversは、仕様策定側が公開するサンプル実装としての位置づけとなるため、プロトコルの動作確認や最小構成の理解には大変適しています。
一方、サードパーティ製は特定のSaaSや社内基盤に特化した豊富な機能を備えているものの、利便性と引き換えにアタックサーフェス（攻撃面）が増大する傾向にあります。特に、コンテナやパッケージ（Docker Hub、PyPI、npmなど）を介した配布形態では、依存関係の乗っ取りや悪意ある更新が紛れ込む余地が生まれます。
選定にあたっては「保守主体は誰か」「更新経路の透明性は保たれているか」を、最優先で確認する姿勢が重要です。決して多機能さだけで安易に採用しないよう注意しましょう。リリースノートの整合性や署名、脆弱性への対応履歴こそが、導入判断における客観的な材料となります。
コミュニティ製サーバーを利用する際の信頼性評価ポイント
広範な選択肢を提供するコミュニティ製サーバーは、開発者の背景が見えにくいうえ、品質に大きなばらつきがあるのが実情です。導入に際しては、以下のような評価軸を設けることが推奨されます。
- 継続性の確認： 最終更新日やIssueへの対応状況、プルリクエストのレビュー実態
- 透明性の担保： LockfileやSBOM（ソフトウェア部品構成表）に相当する情報の提示
- 権限設計： 読み取り専用設定の可否やアクセス対象リソースの限定機能
導入後は、社内リポジトリでフォークしてバージョンを固定（ピン留め）して運用し、更新時には検証環境で差分を確認してから反映させるといった防壁を築くべきです。サプライチェーン対策の観点からは、公開者アカウントの多要素認証やリリース署名の有無を確認することも欠かせません。
マーケットプレイスの審査基準と安全性の確認方法
各種レジストリやマーケットプレイスを経由する場合、仮に一定の審査プロセスが存在していたとしても、それが万能ではないことを理解しておく必要があります。一般的な審査はマルウェア検知やライセンス確認に留まることが多く、各組織の運用環境に特有のリスクまでを担保するものではありません。
利用者は、公開者の身元やバージョン履歴、ソースコードからの配布物の再現可能性（Reproducible builds）を精査すべきです。加えて、実行時に要求される権限（ネットワーク、ファイルシステム、コマンド実行）と外部通信の有無を事前に洗い出しましょう。 最終的には、社内での許可リスト（ホワイトリスト）化やハッシュ値による改ざん検知までを運用プロセスに組み込めれば、導入の安全性を高めることができます。
悪意あるコードやTool Poisoningによる攻撃手法
MCP Server側に悪意あるコードが混入した場合、単純なデータ窃取に留まらず、LLMの推論能力を悪用した攻撃が成立する恐れもあります。その代表例が「Tool Poisoning」です。
これは、Serverが提供するToolの説明文に巧妙な命令を埋め込み、LLMを誘導して別Serverの呼び出しや機密情報の取得を試みる手口です。また、他のServerと同名のToolを用意して呼び出しを横取りする「Tool Name Conflicts」により、通信内容を盗み見されるリスクも報告されています。
これらの対策には、信頼できるServerを優先的に選択することはもちろん、Toolの説明文自体をレビュー対象に含める運用が必要です。重要操作は必ず都度許可を求め、入力値と送信先を人間が確認した上で実行する仕組みを徹底しましょう。 複数のServerを併用する際は、取り扱う機密水準を揃えたうえで、外部送信が絡むServerの物理的・論理的な分離運用が現実的な解となります。
DockerとDenoを活用した技術的な防御策
MCP Serverの安全性を担保するには、実行環境そのものを「信頼しすぎない」設計が大切です。DockerやDenoといった技術を活用して「隔離・権限制御・認証」の3点を軸に据え、万が一の侵害時にも被害を最小限に食い止める「技術的防壁」を構築しましょう。
Dockerコンテナによるサンドボックス化で実行環境を隔離する
MCP Serverをホスト端末上で直接稼働させると、ファイルシステムやネットワークへの広範なアクセスを許してしまいます。これをDockerコンテナ内に「閉じ込める」ことで実行環境を物理的に分離すれば、侵害時の到達範囲を大幅に制限できます。
具体的な実装では、ファイルシステムを読み取り専用（read-only）に設定し、不要な特権（CAPABILITIES）を削除したうえで、業務に必要なディレクトリのみをマウントする構成が基本です。ホスト側の機密情報やSSH鍵などをコンテナに引き渡さない設計を徹底しましょう。
また、実行ユーザーをroot以外に制限し、--privilegedフラグの使用は厳禁です。イメージの取得はタグ名ではなくハッシュ値で固定し、更新時は検証環境で挙動を確認してから反映させることで、サプライチェーン経由の悪性更新にも即座に気づける体制を整えます。CPUやメモリの使用上限も設定し、リソースの枯渇やDoS攻撃の踏み台化を未然に防ぎましょう。
Denoの権限管理機能でネットワークとファイルアクセスを制御する
Denoは「デフォルトで権限が閉じている」という特性を持ち、実行時に必要な権限のみを明示的に許可する設計思想を採っています。MCP Serverの実行エンジンとしてDenoを採用すれば、--allow-netや--allow-readといったフラグを用いて、通信先や参照範囲をピンポイントで制御可能です。
たとえば、通信先を特定のSaaSドメインだけに制限したり、ファイル参照を設定用の特定ディレクトリに限定したりすることで、端末内の探索や意図しない外部へのデータ送信を構造的に抑制できます。 また、原則として環境変数へのアクセス（--allow-env）や外部コマンドの実行（--allow-run）は無効にし、必要不可欠な場合にのみ変数名やコマンドを指定して許可を与えます。社内で「MCP Serverごとの標準許可セット」を定義し、レビューを介して権限を付与するプロセスを確立すれば、導入時のセキュリティ水準のバラつきを抑えることができるでしょう。
npxコマンドによる直接実行のリスクと回避策
npxには、パッケージをインストールせずに即座に実行できる利便性があります。ただし、バージョンを固定しない運用の場合、実行時に外部レジストリから取得されやすくなるため、供給元の改ざんや依存関係への悪意あるコード混入の影響を受けてしまう恐れもあります。
この「動的な取得」は、監査の透明性や動作の再現性を損なう一つの要因です。その回避策として、使用するパッケージは事前に検証を済ませたうえで、社内レジストリやプロキシ経由で取得した「固定バージョン」のみを実環境で動かす運用を徹底すべきでしょう。
万が一悪性コードが含まれていたとしても、ロックファイルによる依存関係の縛りやハッシュ値による改ざん検知を組み合わせ、実行ユーザーの権限を最小化しておけば、その悪影響を限定的なものにできます。SBOM（ソフトウェア部品構成表）を生成し、更新時には差分レビューを行うフローを回すことで、サプライチェーンリスクに対する「気づきやすさ」を底上げしましょう。
OAuthを活用したアクセストークン管理と認証情報の保護
APIキーを平文で管理する手法は漏洩時のリスクが大きいため、可能な限りOAuth 2.0等による「短命なアクセストークン」の運用へ移行すべきです。Server側で権限（スコープ）を細分化し、Clientは業務に必要な最小限の範囲のみを要求する形を採ります。
トークンには必ず有効期限を設定し、重要度の高い「リフレッシュトークン」は、OSの資格情報ストアや専用のSecrets管理基盤で厳重に保護してください。これらの機密情報がエラーログや例外出力に混入しないよう、マスク処理などのフィルタリング設計も必須となります。
また、端末の紛失やアカウント乗っ取りを想定し、多要素認証（MFA）や端末認証を組み合わせた多層防御を構築しましょう。Serverごとにトークンを分離し、用途別に個別のローテーションが可能な設計にしておけば、一つのトークンが流出した際の「横展開」のリスクを効果的に抑制できます。
組織で導入する際の運用ルールとガバナンス
MCP（Model Context Protocol）は、技術的な環境を整えるだけでは不十分です。運用ルールが曖昧なままでは、情報の誤送信やLLMによる予期せぬ操作といったリスクを排除できません。社内SEやセキュリティ担当者は、権限設計と並行して「承認手順」「利用範囲」「検証プロセス」を制度化し、現場で実効性のあるガバナンスを構築することが求められます。
重要な操作実行時に人間による承認を必須とするHuman in the loop
LLMは極めて高い利便性を持つ一方、指示の解釈ミスや外部からの誘導、あるいは「誤クリック」に相当する不適切な実行を選択するリスクも孕んでいます。そのため、リスクの高い操作には必ず人間が介入する「Human in the loop」を運用上の大前提としなければなりません。たとえば「外部へのデータ送信」「権限設定の変更」「データの削除・更新」「大量のリソース消費」など。これらには「Human in the loop」が不可欠なプロセスとなります。
具体的には、LLMが実行候補を提示した段階で、操作内容・対象・送信先・添付データを一覧表示し、ユーザーが「承認」ボタンを押下して初めて実行されるプロセスを組み込みます。あわせて、作業者と承認者の役割を分ける「職務分掌」の考え方も取り入れ、操作ログを改ざん不可能な形で保存します。 運用負荷の増大も想定できることから、その最適化のため「極秘情報を含む場合のみ承認を必須とする」といった機密区分に基づいた閾（しきい）値を設定することも大切でしょう。
扱う情報の機密レベルに応じたMCP Serverの利用制限
MCPを導入する際は、あらかじめ「どの情報を、どのServerに渡してよいか」というデータポリシーを定義しておく必要があります。社内規定や設計資産、個人情報といった機密性の高いデータは、外部送信のリスクがあるServerと同一の作業空間（セッション）で取り扱わないようにしましょう。
たとえば以下のように、情報の機密度に応じて「作業モード」を切り替える運用が有効です。
- 機密モード： 外部連携Serverを強制的に無効化し、社内限定Serverのみを利用可能にする
- 通常モード： 一般的な事務作業や公開情報の検索を想定し、外部ツールとの連携を許可する
加えて各Serverが持つ許可スコープ（権限範囲）を明示し、「どのデータがどこへ渡る可能性があるか」を常に可視化することで、ユーザーによる意図しない情報の投入を未然に防止。権限はロールベースで一括管理し、必要に応じて例外申請を受け付ける体制にしておけば、統制とスピードの両立が可能になります。
ソースコードの検証とDeepResearchを用いたリポジトリ調査
MCP Serverの安全性は、導入前に行う十分なリポジトリ調査に左右されます。導入判断にあたっては、ソースコードの品質だけでなく、開発コミュニティの健全性を含めた「Deep Research（深い裏取り調査）」が必須となります。
まずは、コミット履歴とリリースの整合性、主要開発者の継続性、Issueへの誠実な対応、依存関係の固定状況などを精査。また、CI（継続的インテグレーション）でのテスト実施有無や署名付きリリースの有無、脆弱性報告の受付窓口が整備されているかも確認しましょう。
ソースコードをレビューする際は、「認証情報の取り扱い」「不必要なログ出力の有無」「入力値の検証ロジック」「Tool説明文の自動生成プロセス」を重点的にチェックします。運用面では、社内でリポジトリをフォークして「監査済みバージョン」として固定し、更新時は検証環境で差分を確認してから本番へ反映させるフローを構築させましょう。
まとめ
MCPは、LLMと社内資産をシームレスに統合する強力な枠組みですが、Clientの権限設定からServerの供給経路、さらにはToolの説明文に至るまで、広範な「攻撃面」を内包しているという実情もあります。安全な導入のためには、通信方式に応じたDockerやDenoによる実行環境の隔離をしっかりと行い、認証情報は短命トークンへ寄せる設計が求められます。
運用面では、用途に応じたServerの論理的な分離やデータ送信前の内容明示を徹底しましょう。さらに人間による承認フロー、機密区分に基づく利用制限、そしてリポジトリ調査と監査ログの整備を組み合わせることで、低コストかつ統制の効いた持続可能なMCP運用体制が整います。
