はじめに（背景と目的）

最近、Claude Desktop や GitHub Copilot や Cline などの AI ツールが MCP（Model Context Protocol）に対応し、LLM の機能は大きく進化しています。
MCP サーバーを導入するだけで、ファイルシステムへのアクセス、GitHub リポジトリの操作、SNS への投稿など、AI アシスタントが実行可能な範囲は一気に広がります。

でも、ちょっと待ってください。

npm install -g @modelcontextprotocol/server-filesystem

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/"
      ]
    }
  }
}

この MCP サーバー、本当にそのまま起動して大丈夫でしょうか？

「このサーバー、私のファイル全部読めちゃうのでは？」
「AI が勝手にファイル削除したりしない？」

私も最初は「便利そう！」と思って、Cline 上で見つけた MCP サーバーを気軽にインストールしようとしました。
でも、これ、AI に“フルアクセス”を許す行為に等しいのでは？ という危機感を持ちました。

実際、MCP の公式ドキュメントを見てもセキュリティに関する記述はごくわずか。
コミュニティでも「便利！」という声が多い一方で、リスク面に言及した情報はまだ少ないのが現状です。

本記事では、MCP を利用するうえでのセキュリティリスクを明らかにし、実践的な対策までを紹介します。
MCP の利便性を安全に享受するために、最低限知っておきたいポイントを整理していきましょう。

課題認識：MCPのセキュリティ課題とは？

MCP を実際に使ってみると、いくつかの深刻な課題が見えてきます。

🔐 1. 権限管理の粗さと不透明さ

📌 課題：権限が「実行するかしないか」のみ

// 現在の MCP 設定例（All or Nothing）
{
  "filesystem": {
    "command": "npx",
    "args": ["@modelcontextprotocol/server-filesystem", "/home/user"]
  }
}
// → /home/user 以下の全ファイルにアクセス可能

問題点：

ファイルや操作単位での細かい制御ができない
読み取り専用などの制限がサーバー実装依存
一時的なアクセス制御やトークン発行も不可

💼 導入現場のリアル：「リスク評価が不可能」

企業のセキュリティ担当者は次のように戸惑います：

「MCP を使いたい？でも、どこまでアクセスされるか分からないなら承認できないよ」

従来のツール導入では：

✅ ベンダーのセキュリティ認証が確認できた
✅ 権限スコープを明確に定義できた
✅ 監査ログを導入できた

でも MCP では：

❌ ツール提供元が個人開発者であることも多い
❌ 実行時までアクセス対象が不明
❌ LLM の判断で想定外の操作が行われる可能性が排除できない

⚠️ 2. セキュリティ対策のフレームワークが未整備

1）パッケージ安全性の判断基準が存在しない

npm であれば以下のような情報を参考にして安全性を確認することができます。

📈 週間ダウンロード数
🔍 脆弱性スキャン（npm audit）
🔧 メンテナンス状況（最終更新日など）

しかし MCP サーバーには安全性を担保する仕組みが確立されていません。

🚫 共通のセキュリティスキャンが存在しない
🚫 権限要求の記述形式が統一されていない
🚫 第三者レビューのエコシステムが形成されていない

2）アクセス範囲が事前に分からない

// MCP サーバーのコード例
async function readFile(path) {
  // この path は LLM が決定する
  return await fs.readFile(path, 'utf-8');
}

スマホアプリなら「連絡先にアクセスしてもいいですか？」といったダイアログがありますが、MCP サーバーは：

実行時に LLM がパスを生成・決定
事前の確認や許可ダイアログなし
ログの取得も実装依存で標準化されていない

🤖 3. LLMの創造性がリスクに変わる

LLM は「曖昧な指示」にも応答できるのが魅力ですが、それがリスクにもなります。

ユーザー：「プロジェクトの不要なファイルを整理して」
LLM：「了解。全ファイルをスキャンして不要そうなものを削除します」
→ 想定外の重要ディレクトリまで削除される可能性

従来ツールでは：

操作は人間が明示的に指示
実行内容はスクリプトで固定化

MCP＋LLMでは：

LLMが「気を利かせて」範囲を広げる可能性
プロンプトの曖昧さが挙動のブレに直結
同じ指示でも状況次第で異なる処理になる

✅ 具体的な対策と導入時のガイドライン

MCP を安全に活用するために、以下のような対策とルールの整備を推奨します。

🧰 1. MCP サーバーの安全性を事前にチェックする

公開レポジトリにソースコードがあるか、メンテナンスされているか確認する
npx で実行する場合は事前に内容を読み、信頼できる開発者によるものか確認
セキュリティレビューが行われた MCP サーバーだけを利用する
GithubCopilotやClineなどのエージェントを用いてファイルアクセスや通信先を確認する

Filesystem MCP Serverについて調査して
- 外部に通信している箇所
- 内部のファイルにアクセスしている箇所
- シーケンス図も作成して

FETCH https://github.com/modelcontextprotocol/servers/tree/main/src/filesystem

🧠 2. 安全なプロンプト設計を徹底する

明示的な対象ファイル・ディレクトリをプロンプトで指定する（例：「~/logs/ 以下の .log ファイルを削除して」）
「削除」や「書き換え」などの高リスク操作は複数回の確認を求めるように設計
プロンプト内に誤解を生むあいまいな表現を避ける

👥 3. チーム内での運用ルールとガイドラインを整備する

「どのサーバーを許可するか」「どのアクセス範囲まで許容するか」のポリシーを明文化
MCP サーバー追加時にはレビュー・承認プロセスを経る
LLM による自動実行機能は段階的に導入し、初期段階では人間の確認を必須にする

これらの対策を通じて、MCP の利便性を享受しながらも、安全性を確保するバランスのとれた運用が可能になります。

まとめ

MCP は AI の可能性を大きく広げる技術ですが、セキュリティリスクも伴います。適切な対策を講じることで、利便性と安全性を両立した活用が可能です。技術の進化とともにセキュリティ対策も継続的に見直していく必要があるでしょう。