この記事はNTTドコモソリューションズ Advent Calendar 2025 21日目の記事です。
本記事は、AIや開発の専門家ではまったくない立場の筆者が、MCPサーバを触ってみたところ、リスクを考慮した"範囲設計” が重要だと感じた――という点を整理しています。
技術的な網羅性や厳密さよりも、業務利用上の感覚的な気づきを重視しています。
流行りに乗りインフルエンザ罹患中に書いた記事ですので、広い心でお読みいただければ幸いです^^
自己紹介
NTTドコモソリューションズ 技術革新本部の濱田と申します。
事務系の立場で働きつつ、情報セキュリティや AI 分野に関わっています。
技術的対策だけでは防ぎきれないセキュリティ事故やリスクに関心があり、人や組織の行動、ルール運用といった側面からのアプローチも含めて考えることを大切にしています。
表に出ることは多くありませんが、社内の開発・運用を支える裏方として、現場での気づきや試行錯誤を積み重ねてきました。
MCPサーバとは何か(ざっくりと)
MCP(Model Context Protocol)は、
AI(LLM:Large Language Model:大規模言語モデル)が、
外部のツールやシステムを呼び出すための共通的な仕組み(プロトコル)です。
この仕組み(プロトコル)をもとに実装されているサーバがMCPサーバとなります。
共通のプロトコルを利用して、様々な機能を外部から取り込むことができます。
数年前までのAIは主に「文章を考える」主たる役割だった印象でしたが、
MCPを使うと、
- ファイルを読む・書く
- コマンドを実行する
- ブラウザを操作する
といった、実際の作業(業務)そのものに関与できるようになります。
よくある比喩として、
MCPによる接続は「Type-CのUSBハブによる接続」のようなもの
と言われるようです。
AI本体に対して、
ファイル操作ツール・ブラウザ操作ツール・テストツールなどを 接続するための
「中継ポイント」というイメージでよいと思います。
VSCodeでPlaywrightを動かしてみた
初心者が良く扱う素材として、今回VSCode上でPlaywrightをMCP経由で動かしてみました。
出典：Visual Studio Codeの画面とブラウザ画面(筆者ローカル環境/スクリーンショット取得日：2025年12月16日）
※上図の設定例は、「一例」です。実際の環境では、認証やネットワーク設計などを含めて調整してください。
事前のNode.jsインストールに少し手こずりましたが、公式に公開されているMCPサーバ関連の設定は簡易であり、基本的／限定的な機能をみてみたところ、感想としては、
「指示さえすれば、人がやっていた作業を肩代わりしてもらえる良い仕組みだな」
というものでした。この利用のあと、簡易なMCPサーバなど作成してみていろいろ動かしてみました。
そこで感じた魅力といえば、例えば
- 手順確認の自動化
- 画面操作の再現
- テストの自動実行
といったことを、自然言語でAIに指示できそうだという体験はとても魅力的に思えました。自然言語でというのが良いですね。
業務効率化という観点では、
「現場で使いたくなる理由がよく分かる」と感じたところです。
なぜMCPが効くのか
いろいろと触ってみて感じたのは、「LLM単体」「エージェントモード」「MCP経由」の3つの違いの感触です。
エージェントは「自動化」を実現しますが、使えるツールが開発者依存で統一しにくいのではないかと思います。一方で、
MCPの強みは「共通プロトコル(規則)」
にあると思います。
従来のエージェントでは、サーバ側のツールに変更があるとクライアント側でも大幅な修正が必要になることが多い印象ですが、MCPの共通プロトコルに準拠していれば、サーバ側に変更が生じてもクライアント側の変更追従は最小限で済むことが利点ではないでしょうか。
例えばPlaywright MCP(Playwright用のMCPサーバ)に新機能が追加された場合を想定しますと、MCPの共通プロトコル準拠であれば、設定変更するだけで対応できるようなイメージです。この「バージョン互換性＋標準化」により、複数ベンダのツールを混在させたとしても、統一管理が可能になると思われます。
便利なので企業でも積極的に利用する方向が望ましいなぁとの思いの半面、「利便性と情報セキュリティのバランス」も考えないといけないんだろうなぁという思いから、この記事では以下の”MCPのリスクを7つの範囲で整理”してみました。
これまで多くの方が論じてきた情報セキュリティの「戦略」の考え方から、大きく外れているわけではないと思います。MCPという仕組みができたことから、それに応じた「戦術」をうまく考える必要がありそうですね。
MCPの「標準化＋統制可能性」があるからこそ、以下の7つの範囲設計が重要です。
「誰でも簡単に使える」仕組みだからこそ、逆に「どこまで使うか」の線引きなどが肝心だと思います。
| 範囲名 | 主な検討ポイント | アクション例 |
|---|---|---|
| 権限の範囲 | MCPが何を実行できる | 最小権限で動作させる |
| 利用範囲 | 誰がどこから利用できるか | ローカルor特定社内端末限定 |
| 接続範囲 | 外部接続元の制御 | IPフィルタ・VPN制限など |
| 回数や量の範囲 | 過剰実行防止 | レート制限設定・モニタリング |
| 情報資産の範囲 | 触れてよい情報 | データの分離・検証環境専用化 |
| 通信・信頼の範囲 | 配置・提供元の確認 | 提供元の公式性・暗号化通信の確保 |
| 検証範囲 | 入力と動作の安全性 | 入力サニタイズ・ログ監査 |
ここでいう「利用範囲」は誰がどの用途で使えるかという運用ルールを指し、「接続範囲」は技術的にどこからアクセスできるようにするかという通信・ネットワーク設定を指すイメージです。
完全に独立した項目として挙げているわけではありませんが、これらのことを意識するだけでもリスク管理に一定の役割は果たせるのではないかな？と推察します。
権限の範囲：便利さの裏側にある「強さ」
触ってみてすぐに気づいたのが、
MCPサーバの持つ操作権限の強さの可能性です。
MCPサーバは単なるAPIではなく、
- ファイルにアクセスする
- コマンドを実行する
- (上述のように)ブラウザを操作する
といった、
業務システムで言えば管理者寄りの操作を行える可能性を秘めています。
ここで、こんな疑問が浮かびました。
「MCPサーバ、ある一定以上の権限を持って、どこからでも使える状態になっていたら危なくないか？」
権限の制御を見誤ると、“便利”が一瞬で“リスク”になります。
利用範囲：便利な仕組みほど、利用範囲の定義が重要
ここでは、どの立場の人が、どのような目的でMCPサーバを使ってよいのかという「運用ルール」の話を記載します。
MCPサーバを使うと、AIが指示を出し、MCPサーバ側が実際の操作（例えばファイル操作や外部サービスの呼び出しなど）を実行するという形で、従来よりも一段踏み込んだ自動化が可能になります。
その分、
- どこから使えるのか
- 誰が使えるのか
を曖昧にしたまま使い始めると、
意図しない操作や情報の扱いにつながりかねません。
これはMCP特有の話ではなく、
影響範囲が広い仕組みほど、先に利用条件を決める必要がある という、
従来の業務システムと同じ考え方だと思います。
ただ「便利機能だから使おう！」という意識が先行すると、従来意識していたはずのこの考え方が外れてしまうことがあり得るのではないでしょうか。
接続範囲：どこから使えるかを決める
こちらは、ネットワークや端末など、技術的に「どこからアクセスできるようにするか」という設定に関する話です。
「通信設定」「接続範囲の制御」と聞くと難しく感じますが、
平たく言えば、
「このMCPサーバは、どこから使えるのか」を決めることです。
企業利用で、まず目指すべき状態は、
- 自分の管理できるPCだけ
- 社内の特定端末だけ
から使える構成です。
これは、
- 社内システムがインターネットから容易に直接触れない
- 社員が自席のPCからだけ操作できる
といった、
ごく一般的な社内システムの考え方と同じです。
回数や量の範囲：レート制限という「使いすぎ」を防ぐ設計
もう一つ意識しておきたいのが、
どれくらいの頻度でMCPサーバを使えるのかという点です。
MCPサーバはAI経由で自動的に処理が実行されるため、
- 想定以上の回数でツールが呼ばれる
- ループ的に処理が繰り返される
- システムや外部サービスに過剰な負荷がかかる
といった事態も起こり得ます。
MCPはイメージとして「USB Type-Cハブのように多くのツール接続が可能」なものですが、制御不足で負荷・不安定化のリスクがあります。
便利だからといって、
「つなげるだけ・使わせるだけ」にしてしまうと、
全体としてうまく動かなくなる可能性があります。
そのため、
- 一定時間あたりの実行回数を制限する
- 異常な頻度の呼び出しを検知・停止する
といったレート制限の設計も、
最初に考えておくべきポイントだと感じました。
情報資産の範囲：MCPサーバが触れる「情報資産の範囲」を意識する
企業利用で見落としやすいのが、
「そのMCPサーバが、どの情報資産に触れるのか」
という観点です。
MCPサーバは、
- ファイルシステム
- リポジトリ
- テストデータ
- 業務システムへの接続情報
などに、間接的・直接的にアクセスできます。
重要なのは、
「業務上、触ってよい」という感覚と
「技術的に触れてしまってもよい」こととは別
という点です。
例えば、
- 本番データではなく検証用データだけに限定する
- 特定のディレクトリ配下のみ許可する
- 個人情報や機密情報を含む領域は対象外にする
といった形で、
情報資産の範囲を意図的に絞る設計が重要になります。
企業では情報資産台帳などで、情報資産を管理されているケースも多いかと思います。情報資産から見て、どのような範囲まで触れさせてよいのかは意識しておく必要がありそうですね。
通信・信頼の範囲：MCPサーバの配置形態と通信、公開されているMCPサーバを使う場合の考え方
ここでは通信路およびサーバ自体の信頼についてざっくりとまとめます。
MCPサーバは、
- 自分が管理できるPC上(いわゆるローカル環境)
- 社内ネットワーク
- インターネット上の外部環境
など、さまざまな場所に配置できます。
特に社外に配置する場合は、
- 情報が社外に出ることの是非
- データの保存や再利用
- 通信経路の安全性
を、最初から前提として考えておく必要があります。
特にクラウドなど社外環境にMCPサーバを配置する場合は、その設計自体が直ちに危険というわけではありませんが、
- どのような情報を外部へ送るか
- どの程度のログやデータが保存・再利用されるか
といったことを事前に整理しておく必要があります。
また、インターネット上には、
誰でも利用できる形で公開されているMCPサーバも存在します。
そのようなサーバを利用する場合は、
- 公式に提供されているものか
- 提供元や運用主体が明確か
- ドキュメントや利用実績が確認できるか
といった点を、事前に確認する必要があります。
MCPサーバは、
業務に直接影響する操作を担う仕組みです。
そのため、
「正体の分からないサーバを業務に組み込む」
ことにならないよう、
提供元の信頼性を前提に選定する必要があると感じました。
継続利用の場合には、脆弱性管理プロセスについても気にしておきたいですね。万が一、公開されているサーバに脆弱性が見つかった場合のパッチ適用など、留意したいものです。
検証範囲：入力検証・インジェクションへの向き合い方
現時点では、一般的なWebアプリケーション向けなどと比べると、「MCPサーバに特化した脆弱性診断やスキャンツール」は、未だ多くない印象です。今後、MCP向けのセキュリティツールやベストプラクティスがさらに整備されていく段階だと考えています。
ただ「入力を受け取って外部ツールを実行する」構造 については、 中身は見えにくいですが、動作を意識的にチェックしておくべきポイントだと思います。
もちろん、悪意ある指示に従って、意図しない悪い動作をしてしまうことについては注意が必要ですね。入力サニタイズやログ監査を意識することもよいかと思います。
検証の範囲・実施可否、リスク許容度を事前に決めておくことが重要です。
まとめ：便利だからこそ、最初にさまざまな範囲を決める
MCPサーバは非常に便利で、
業務効率化の可能性を強く感じる仕組みです。
一方で、
- 強い権限を持つかも
- AI経由で自動的に操作されうる
という懸念が存在する以上、
様々な”範囲”を意識的に決めないまま導入すると、
想定外のリスクを抱えやすいとも感じました。
企業で使うなら、まずは
- 自分のPCだけ
- 社内の特定端末だけ
という、管理された範囲から始める。
その上で、
- 本当に外部連携が必要か
- 権限を広げても統制できるか
を一つずつ確認しながら進める。
便利だからこそ、最初に絞る。
考え方が少し窮屈に感じられるかもしれませんが、それが、AIと人間の業務を安心して共存させるための第一歩ではないかと思います。便利な仕組みだからこそ、リスクを想定しつつ適切に管理し、企業でも前向きに活用が進んでいけばいいですね。
コメント・補足・免責
本記事は筆者個人の体験と所感に基づきます。
特定製品やサービスのセキュリティを断定・保証するものではありません。
内容に誤りがあれば、ぜひ建設的なご指摘をお願いいたします。
商標・著作権に関する注意
記載の製品名・サービス名・会社名は各社の商標または登録商標です。
本記事は各企業・製品・サービスの公式見解を示すものではありません。