MCP実践セキュリティ

「タスクの90%を自動化しながら、最も重要な10%で手作業を強いられる」。それがMCPの現実だ。

この本を書いた理由

2026年3月、確定申告の締め切りが迫る中、私はfreeeのMCPサーバーで経費精算を自動化しようとしていました。

取引の作成、勘定科目の設定、金額の入力。ここまでは完璧に動きました。Claude Desktopからfreeeに「12月の電気代8,500円を水道光熱費で登録して」と指示するだけで、数秒で仕訳が完成する。「これがMCPの力か」と感動したのを覚えています。

しかし、次のステップで手が止まりました。

領収書の添付ができない。

Tool: mcp_server__api_post
Parameters: path: /api/v1/receipts
            body: {"company_id": "xxx", "description": "電気代 7月"}
Response: API Error: 400
          Detail: Content-Type must be "multipart/form-data"

経費精算で領収書の添付は任意ではありません。法的に必須です。タスクの90%を自動化しながら、最も重要な部分で手作業を強いられることになりました。

CLIスクリプトで外側から対応すれば動く。でもそれなら、MCP連携を公開する意味は何なのか？

この体験がきっかけで、MCPの「できること」と「できないこと」を徹底的に調べることにしました。7つのサービスでファイルアップロードを検証し、OWASP MCP Top 10のセキュリティリスクを読み込み、4つのMCPサーバーでトークンコストを実測しました。調べれば調べるほど、MCPの世界には「知らないと痛い目を見る」落とし穴が多いことに気づきました。

• 60日間で30件のCVE が報告されている
• 500以上のMCPサーバーをスキャンした結果、 38%が認証なし
• ファイルアップロードを完全にサポートしているサービスは 7つ中ゼロ
• ツール定義を読み込むだけで 年間約1,000円のトークンコスト が発生する

世の中には「MCPは便利！」という記事はたくさんあります。しかし、本番導入で直面する現実的な問題(セキュリティ、コスト、ファイルの制約)を体系的にまとめた情報は、まだほとんどありませんでした。

そのため、自分で書くことにしました。

本書の構成

本書は大きく3つのパートで構成されています。

第1部：基礎と実践 (第1章〜第4章) MCPの全体像から通信仕様、トークンコストの実測、freeeでの確定申告自動化の実体験まで。MCPを初めて使う方は、ここから読んでください。

第2部：制約とセキュリティ (第5章〜第6章) 本書の核心部分です。ファイルアップロード問題の7サービス検証と、OWASP MCP Top 10の全解説。MCPを本番に導入する前に、必ず読んでほしい章です。

第3部：実践と展望 (第7章〜第8章) 本番環境で使えるワークアラウンド集と、SEP-1306やFileContentなどMCPの未来。すでにMCPを使っている方にとって、実践的なヒントが詰まっています。

対象読者

• MCPを使ってAI自動化を検討しているエンジニア
• MCPサーバーを本番環境に導入しようとしている方
• MCPのセキュリティリスクを把握したい方
• freee、Jira、Notion、GitHub等のMCP連携を検討している方

本書で扱わないこと

• MCPサーバーの開発チュートリアル(SDK の使い方等)
• 特定のLLMの使い方
• MCPの仕様策定プロセスへの参加方法

著者について

ken imoto。エンジニア歴8年。AI/LLMとWebRTCを組み合わせたリアルタイムシステムの設計を専門としています。freeeのMCPサーバーで実際に確定申告を行い、その過程でMCPの可能性と限界の両方を体験しました。

本書は、その体験から得た知見を余すところなく詰め込んだ一冊です。成功した手法だけでなく、失敗から学んだことも含めて、できるだけ正直に書いています。

それでは、MCPの現実の世界へようこそ。

この続きはKindleで →

「MCPはAIの”手”を作るプロトコルだ。ただし、その手はまだ不器用だ。」

LLMの「できない」を解消するプロトコル

2025年以前、LLMに「freeeで経費を登録して」と頼んでも、こう返ってきました。

「申し訳ありませんが、外部サービスに直接アクセスすることはできません。freeeのWebサイトで手動で登録してください。」

LLMは賢い。文章を書ける、コードを書ける、分析もできる。しかし、 外部の世界に触ることができなかった 。

MCPはこの制約を突破するために生まれました。

MCP(Model Context Protocol)は、Anthropicが策定したオープンプロトコルで、LLMと外部ツール・データソースを接続する標準規格です。簡単に言えば、 LLMに”手”を与えるプロトコル です。

APIを直接叩けばいいのでは？

ここで疑問が浮かぶかもしれません。「LLMにAPIを叩かせればいいだけでは？」

実際、LLMにPythonスクリプトを書かせてfreee APIを叩くことは以前からできました。しかし、このアプローチには3つの問題がありました。

問題1: サービスごとに異なる認証方式 freeeはOAuth 2.0、GitHubはPersonal Access Token、SlackはBot Token。サービスごとに認証フローを実装する必要があります。

問題2: 動的なツール発見ができない LLMは「このサービスで何ができるのか」を事前に知る必要があります。APIドキュメントを読ませるのは非効率で、トークンも大量に消費します。

問題3: 安全な実行環境がない LLMが書いたPythonスクリプトを無制限に実行させるのは、セキュリティ上の悪夢です。

MCPはこれら3つの問題を、標準化されたプロトコルで解決しようとしています。

MCPの3つの構成要素

MCPのアーキテクチャはシンプルです。3つの要素だけで構成されています。

1. MCPホスト/クライアント

Claude Desktop、IDE(VS Code等)、AIツールなど。ユーザーの自然言語リクエストを受け取り、MCPサーバーに標準化された形式で転送します。

ポイントは、 ホストはサービスの詳細を知らなくていい ということ。freeeのAPIがどんなエンドポイントを持っているか、どんなパラメータが必要かは、すべてMCPサーバーが知っています。

2. MCPサーバー

外部サービスとの接続を担う軽量プログラム。各サービスごとに1つのMCPサーバーが存在します。

MCPサーバーの役割は3つ：

• ツールの定義: 「何ができるか」を標準形式で公開
• 認証の管理: OAuth等のサービス固有の認証を内部で処理
• API呼び出し: 実際の外部API呼び出しを実行

3. 外部サービス(リソース)

freee、GitHub、Slack、Google Driveなど。実際のデータや機能を提供するサービスです。MCPサーバーがこれらのAPIを呼び出します。

MCPが提供する3つの機能

機能	説明	例
Tools	LLMが呼び出せる関数	取引作成、メール送信、Issue作成
Resources	LLMが参照できるデータ	ファイル内容、DB、設定値
Prompts	再利用可能なプロンプトテンプレート	コードレビュー用プロンプト等

実際にはToolsが最も多く使われます。freeeのMCPサーバーが270ものツールを公開しているのは、会計・HR・請求書・勤怠・販売管理のすべての操作をToolsとして定義しているからです。

MCPと従来のアプローチの違い

項目	従来(API直接呼び出し)	MCP
認証	サービスごとに個別実装	MCPサーバーが統一管理
ツール発見	APIドキュメントを読ませる	tools/list で動的取得
実行環境	LLMが生成したコードを実行	MCPサーバーが安全に仲介
標準化	なし(独自実装)	JSON-RPC 2.0ベースの統一規格

エコシステムの現状

2026年3月時点で、MCPエコシステムは急速に拡大しています。

• 公式MCPサーバー: GitHub、Slack、Notion、freee、Salesforce等
• サードパーティ: LobeHub、Composio、CData等のプラットフォームで数百のMCPサーバーが公開
• 対応クライアント: Claude Desktop、VS Code、Cursor、n8n等

しかし、この急速な普及には影の部分もあります。500以上のMCPサーバーをスキャンした調査では、 38%が認証なし で公開されていました。この問題については第6章で詳しく解説します。

この章のまとめ

• MCPはLLMと外部サービスを標準的に接続するプロトコル
• ホスト/サーバー/リソースの3層構成
• 認証の統一管理とツールの動的発見が主なメリット
• エコシステムは急拡大中だが、セキュリティは追いついていない

次章では、MCPの通信仕様を掘り下げます。JSON-RPCベースの設計が、なぜファイルアップロード問題を引き起こすのか。その根本原因が見えてきます。

この続きはKindleで →

「MCPがJSON-RPCを選んだ瞬間、ファイルアップロード問題は運命づけられていた。」

JSON-RPCという設計判断

MCPの通信はJSON-RPC 2.0をベースにしています。すべてのやり取りはJSONテキストで行われます。

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "create_deal",
    "arguments": {
      "company_id": "1568817",
      "amount": 8500,
      "description": "電気代 12月",
      "account_item": "水道光熱費"
    }
  }
}

この設計判断には明確な理由があります。JSON-RPCは軽量でパースが容易、言語に依存せず、デバッグもしやすい。LLMとのテキストベースのやり取りに最適化されたプロトコルです。

しかし、この選択には代償がありました。 バイナリデータの直接転送が仕様に含まれていない のです。これが後述するファイルアップロード問題の根本原因です。

テキストを流暢に操るLLMにとって、JSON-RPCは母国語のような存在です。しかし、領収書の画像やPDFといったバイナリデータを扱おうとすると、途端に「言葉が通じない」状態になります。

2つのトランスポート層

MCPは2つのトランスポートをサポートしています。用途によって使い分けます。

1. stdio(標準入出力)— ローカル向け

MCPクライアントとサーバーが同一マシン上で動作する場合に使用します。Claude Desktopでの一般的な使い方です。

1. stdio: ローカル向け

メリット: セットアップが簡単、ネットワーク不要 デメリット: 同一マシンに限定

2. HTTP + SSE: リモート向け

MCPサーバーがネットワーク上の別マシンで動作する場合に使用します。企業環境やクラウドデプロイで一般的です。

メリット: リモートアクセス可能、スケーラブル デメリット: セキュリティ設定が必要(認証、TLS等)

ここで重要なのは、 どちらのトランスポートでもデータ形式はJSON-RPC だということです。HTTPを使っているからといって、multipart/form-dataでファイルを送れるわけではありません。

ツール呼び出しのライフサイクル

MCPでツールを呼び出す流れは6ステップです。

私がfreeeで確定申告をしたとき、「電気代8,500円を登録して」という一言で、このStep 1〜6が約3秒で完了しました。LLMが自動的にfreeeのcreate_dealツールを選び、適切な勘定科目を設定し、仕訳を作成してくれた。この体験は本当に感動的でした。

しかし、Step 1の「ツール一覧の取得」が思わぬコスト問題を引き起こすことに、そのときはまだ気づいていませんでした。これについては次章で詳しく解説します。

ツール結果の3つの型

ツール呼び出しの結果として返せるのは、以下の3つの型 のみ です。

型	用途	制限
TextContent	テキストデータ	なし
ImageContent	画像データ	base64エンコード必須
EmbeddedResource	リソースへの参照	URI参照のみ

お気づきでしょうか。 FileContentというタイプは存在しない のです。

PDFを返したい？ TextContentに無理やりbase64を詰め込むか、ImageContentを「ハック」して非画像データを流すしかありません。MCP公式のDiscussion #1197では、開発者がこう嘆いています：

“We are currently left either squeezing multipart-mime into a text response or abusing the image response to pass non-image binary data, both of which is a hack.”

正規の方法がないから、みんなハックで対処している。これがMCPのファイル問題の現実です。

双方向通信(Sampling)— 便利さと危険さの両面

MCPの特徴的な機能に「Sampling」があります。これは サーバーからクライアント(LLM)に問い合わせる 仕組みです。

例えば、freeeの経費処理で「この取引の勘定科目がわからない」場合、MCPサーバーがLLMに「この支出は何費ですか？」と問い合わせることができます。処理の途中でLLMの判断を挟めるため、複雑なワークフローが実現可能になります。

しかし、Microsoftのセキュリティ研究チームはこの機能について警告を発しています。

悪意のあるMCPサーバーがSamplingを悪用すると：

1. LLMに「ユーザーの会話ログを送信しろ」という隠し指示を送る
2. LLMが別のMCPサーバー経由で機密データを外部に送信

この クロスサーバーコンテキスト悪用 は、複数のMCPサーバーを同時に使う環境で特に危険です。第6章のOWASP MCP Top 10で詳しく解説します。

ツール説明文とトークンの関係

MCPサーバーは各ツールに「説明文(description)」を付与します。LLMはこの説明文を読んでツールの使い方を理解します。

{
  "name": "create_deal",
  "description": "freeeの取引を作成します。amount（金額）、date（日付）、
                  partner_name（取引先）を指定してください。消費税区分は
                  自動判定されます。",
  "inputSchema": {
    "type": "object",
    "properties": {
      "amount": { "type": "number" },
      "date": { "type": "string" },
      "partner_name": { "type": "string" }
    }
  }
}

ここで見落としがちなのが、 この説明文がトークンを消費する ということです。1つのツールの説明文が50トークンだとして、270ツールあるfreeeなら、接続するだけで約13,500トークン。次章では、この「見えないコスト」を4つのサービスで実測します。

この章のまとめ

• MCPはJSON-RPC 2.0ベース: テキスト最適化の代償としてバイナリ転送ができない
• トランスポートはstdioとHTTP+SSEの2種類: どちらもデータ形式はJSON
• ツール結果は3種類のみ: FileContentは存在しない
• Sampling(双方向通信)は強力だが、セキュリティリスクも拡大する
• ツール説明文はトークンを消費する: 次章で実測データを公開

次章では、「MCPに接続するだけでいくらかかるのか？」を4つのサービスで実測します。

この続きはKindleで →