MCPのファイル添付7サービス実測: 対応ゼロ

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

2026年3月、当時使っていた @him0/freee-mcp(同じリポジトリが2026-02-24にfreee社へ移管されて freee-mcp として公式化される前の版)で領収書を添付しようとしたら、Content-Type must be "multipart/form-data" というエラーが返ってきました。これは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モードでは依然として動きません。冒頭で私が詰まった @him0/freee-mcp の時点では、この独自ツールはまだ存在していませんでした。

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年で、これは致命的です。

脅威カテゴリで並べ直す

「動かない」だけならまだ生活できます。動くようにするために各サービスが用意した迂回策は、セキュリティの観点で並べ直すと、それぞれ別の脅威カテゴリに落ちます。

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

私が確定申告で使った回避策

私が2026年3月の確定申告で落ち着いたのは、 MCPを主、CLIを補 にするハイブリッド構成です。取引の作成と確認・検証はMCPに任せ、領収書のアップロードだけをMCPの外のCLIスクリプトで行いました。MCPだけでは完結しませんが、ファイルを扱う動線だけを「MCPが介在しない経路」に切り分ければ、残りの自動化は活かせます。

MCPファイルアップロードの構造的な話と、署名付きURL方式などのワークアラウンドやガードレール設計は、書籍にまとめています。

MCP実践セキュリティ（インプレス）

まとめ

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

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