← ブログに戻る

MCPファイルアップロードを7サービスで実測: 完全対応はゼロだった

/ 8分で読めます / mcp · security · file-upload · anthropic

「file: と書けば送れる」と私は思っていました。

freee公式MCPで領収書を添付しようとしてエラーが返ってきたとき、最初は自分のパス指定が間違っているのかと思いました。次に、公式版がまだ実装していないのかと思いました。三日ほど経ってから、「これはfreee固有の問題ではなくMCPプロトコル自体の話ではないか」と気づき、他のサービスでも同じ検証を回すことにしました。

結果は身も蓋もありませんでした。 7サービスすべてで、MCPプロトコルの標準経路によるファイルアップロードは動きませんでした。 動いている4サービスは全て、プロトコルの外側で実装者が独自の迂回策を用意しているだけです。

MCP 7サービスのファイルアップロード実測結果

検証した7サービスと分類

私が業務で日常的に触っているサービスから、ファイルアップロードが業務上不可欠な7つを選びました。

サービスカテゴリMCP公開ファイルUP業務での重要度
freee会計公式部分対応証憑保存
Jira / Confluenceプロジェクト管理Atlassian公式Remote非対応業務必須
Notionドキュメント公式非対応高頻度
GitHubコード管理公式非対応高頻度
Gmailメールサードパーティ部分対応高頻度
Google Driveストレージサードパーティ部分対応コア機能
SlackチャットCData / 公式部分対応高頻度

完全対応(プロトコル標準経路): 0 / 部分対応(実装側の迂回): 4 / 非対応: 3。

この「部分対応」の内実がこの記事の主題です。全部同じように見えて、内側は全く別のことをしています。

原因はMCP仕様のこの1行

MCP仕様2025-11-25版でツール結果として返せる型は5つ: TextContent / ImageContent (base64) / AudioContent (base64) / ResourceLink / EmbeddedResource 。

FileContent はありません。

AnthropicチームのメンバーがMCP公式Discussion #1197で認めています。

“I don’t think you’re overlooking anything, your use-case is currently finicky in the current state of the protocol.”

「見落としではない。現状のプロトコルではあなたのユースケースは扱いにくい」。公式の言葉です。

SEP-1306は? SEP-2356は?

2025年8月にSEP-1306としてBinary Mode Elicitationが提案されました。2026年3月にはより仕様が固まったSEP-2356 (File input support for tools and elicitation)がドラフト入りし、SEP-1306はこちらに事実上引き取られた形です。

2026-07-28リリース候補にも、コアに FileContent 型は入っていません。 File Uploads Working Groupが動いていて、SEP-2356をアンカーに議論は続いていますが、 「コアが直接バイナリを運ぶ」設計は、今の仕様の方向とは違います。 ファイルはコアの外(Apps / Tasks / elicitation経由)で扱おう、というのが2026年時点の合意です。

つまりこの記事で紹介する「部分対応の4サービス」の迂回策は、SEP-2356が正式採用されたあとも、大枠は残るとみています。コアが直接バイナリを運ばないなら、実装側は結局どこかで迂回する必要があるからです。

部分対応4サービスがやっている「別々のこと」

「仕様書のこの1行を、全員が違う意味で読んでいた」と言いたくなる構図です。同じ「部分対応」に見えて、内側は4通りに分かれます。

MCPファイルアップロード迂回策の4分類

1. freee (公式) — 独自ツール freee_file_upload (stdio限定)

freee公式版は2026-03-10に独自ツール freee_file_upload を追加しました。stdioモード限定です。汎用API経由や Remoteモードでは依然として動きません。

私が試した限りだと、Claude Desktopのstdio接続では動きますが、Cursor経由のリモート接続では動きません。会計SaaSで「Claude Desktopでしか使えない機能」があるというのは、業務用途としては微妙な位置づけです。

2. Gmail / Google Drive (サードパーティ) — ローカルファイルパス経由

GmailおよびGoogle DriveのサードパーティMCPサーバーは、 MCPサーバーがローカルファイルシステムに直接アクセス してファイルを読み、外部APIに転送しています。

この方式は「MCPプロトコルとしてはファイルを転送していない」ものです。ローカルパスを渡す時点で、MCPサーバーがユーザーのファイルシステムに広くアクセスできる前提が要ります。Docker環境やリモート実行では、そもそもファイルが見つかりません。

3. Slack (CData版) — UploadFile ツール

CData版Slack MCPサーバーは独自の UploadFile ツールを提供しています。ここでも本体はSlack APIへの直接転送で、MCPコアのバイナリ経路ではありません。Slack公式MCPサーバー(Anthropicが取り上げているもの)は検索とメッセージ送信中心で、ファイルアップロードは非対応です。

4. Jira / Notion / GitHub — 非対応

Atlassianコミュニティの公式回答:

“file uploads or image attachments via the MCP Remote Agent are not supported.”

Notion公式ドキュメント:

“Image and file uploads are not currently supported in Notion MCP, but this is on our roadmap.”

github-mcp-server Issue #738:

“the MCP needs to be able to upload images and at the moment that doesn’t seem to be possible.”

「UIの変更をスクリーンショット付きでPRに出す」という開発者なら誰もが欲しい動作は、2026年7月時点でもGitHub公式MCPからは実現できません。

さらに深刻なのがmcp-atlassian Issue #618で、Jira/Confluenceの添付機能はMCPサーバーのファイルシステム上のパスを要求するため、 Docker環境では動作しません 。コンテナ化が当たり前の2026年で、これは致命的です。

OWASP MCP Top 10 の視点で並べ直す

「動かない」だけならまだ生活できます。動くようにするために各サービスが用意した迂回策は、OWASP MCP Top 10と Anthropic 2026 MCP セキュリティ勧告のレンズを通すと、それぞれ別の脅威カテゴリに落ちます。

サービス迂回方式OWASP MCP Top 10 該当実務上の懸念
freee公式stdio限定 独自ツールLLM06 過剰権限stdio接続の権限境界がゆるむ
Gmail / Google DriveローカルFSアクセスLLM06 過剰権限 / LLM07 データ漏洩MCPサーバーがFS全域を読める
Slack CData独自 UploadFileLLM01 プロンプトインジェクション経路攻撃者がツール引数でパスを注入
Jira / Notion / GitHub添付不可のまま(該当なし)業務動線が止まる

私が本番で採用しているのは、この表の一番下です。「動かないままで運用を組む」。「動くようにしたら別のリスクが載る」ことが分かっているので、無理に迂回しません。証憑や添付が要る動線は、MCPを経由せず既存のWeb UI経由で人間が処理する運用を残しています。

私が本番で回している運用

まず、業務ワークフロー上、 ファイルを扱う動線は「MCPが介在しない経路」に切り分けています 。具体的には次の3つ:

  1. freeeの領収書アップロードは、freee本体のUIかスマホアプリ経由。Claude Codeでの補助は「勘定科目の推定」と「摘要文の下書き」に限定
  2. Jira/GitHubのスクリーンショット添付は、人間が手でドラッグ&ドロップ。エージェントには「PRの本文だけ書き換える」を任せる
  3. Google Driveは、必要なファイルは事前に人間がアップロード。エージェントは「そのファイルを引用したドキュメントの生成」だけ

「動かない機能を無理に動かす」よりも「動かない領域を運用で切る」ほうが、結果的に事故が少なかったです。 3ヶ月試して、この分業がいちばん静かに回っています。

MCPファイルアップロードの構造的な話と、私が本番で使っているガードレール設計は、書籍にまとめています。

Model Context Protocol 実践セキュリティ入門

まとめ

  • 7サービス実測で、MCPプロトコルの標準経路によるファイルアップロード対応は ゼロ
  • 部分対応の4サービスは全て、プロトコル外での独自迂回策
  • 迂回策はそれぞれ別の脅威カテゴリに落ちる(過剰権限 / データ漏洩 / インジェクション)
  • SEP-2356が来ても、コアが直接バイナリを運ぶ方向ではないため、この構図は大枠残る見込み

「部分対応の4サービスが安全に見えるのは、たぶん実装者が仕様通りに書かなかったからだ」と、私は今のところ思っています。仕様通りに書いた3サービス(Jira / Notion / GitHub)は動きません。安全と便利は、MCPのこのレイヤーでは両立していません。

関連する記事

記事一覧を見る →