他人の自作 MCP サーバーに顧客データを渡してよいか — 便利でも投げてはいけない理由

「うちで自作した MCP サーバーがあるので、御社の顧客データを送って推論させてみませんか？」

コンサルの担当者から、そんな提案をもらったとします。 自動でデータを読み、分析まで返してくれる。便利なのは、はっきり分かる。

でも、頭のどこかで警報が鳴りませんか。 「それ、絶対にやっちゃダメなやつでは……」と。

その直感は正しいです。 この記事では、なぜ他人の自作 MCP サーバーに顧客データを渡してはいけないのか、.env のような設定ファイルまで含めた線引き、そして「便利さを捨てずに安全に活かす」やり方を、いまの議論をふまえて整理します。

そもそも「投げる」と何が起きるのか

まず MCP をひとことで。 MCP（Model Context Protocol）は、AI に外部のツールやデータをつなぐ「共通の差込口」です。くわしくは MCP サーバーとは何か にまとめています。

ここで大事なのは、自作サーバーの中身を書いているのは「相手」だという点です。 あなたが顧客データを送ると、その情報は相手のサーバーを通り、相手のコードが処理します。

図のように、返ってくるのは「便利な推論結果」だけ。 その裏で、データがログに残ったのか、どこかに保存されたのか、別の AI の学習に回ったのかは、送った側からは見えません。

つまり「投げる」とは、中身の見えない箱にデータを預けることとほぼ同じです。 箱の作りを確認できないまま、いちばん大事なものを入れてしまう。ここに危うさがあります。

便利さは本物、でも「行き先が見えない」のが怖い

便利さそのものは否定しません。 手作業の集計や分類を丸ごと任せられるなら、それは強力です。

問題は、便利さと引きかえにデータの主導権を手放してしまうことです。

2026 年時点で、MCP をめぐるセキュリティの議論はかなり進んでいて、次のようなリスクが繰り返し指摘されています。

• なりすましサーバー：信頼できるサービスを装った偽の MCP サーバーに、機密情報を送らされる。
• ツールの後出し変更：導入時は無害でも、あとから「データを集める」動きにこっそり書き換えられる。
• つなぎ先の連鎖：複数のサーバーを数珠つなぎにすると、一つが汚染されただけで全体に広がる（サプライチェーンの問題）。

実際に、あるサービスの MCP 機能の権限設定の不備で、約 1,000 の組織のデータが別の利用者から見えてしまった事例も報告されています。 しかも MCP の仕様そのものには、もともと認証・認可のしくみが組み込まれていません。守りは、つなぐ側が自分で足す前提です。

こういう仕込みが本当にあるかどうかを、送る側は確かめられません。 確かめられない相手に大切なデータを渡すのは、この記事の主役である「顧客データ」では割に合わないのです。 仕込まれた指示に乗っ取られる話は プロンプトインジェクションとは もあわせてどうぞ。

顧客データは、あなた一人で決めていい話ではない

ここが、個人で使うときといちばん違うところです。

顧客データは、あなたの持ち物ではありません。 お客さんから預かったものであって、外に出す判断を、担当者ひとりで下してよいものではないのです。

日本の個人情報保護法では、他社に個人データを渡す行為は「第三者提供」や「委託」として扱われ、場面によって次のような対応が要ります。

• 本人の同意：原則、あらかじめお客さん本人の同意が要る。
• 委託契約：分析を頼む「委託」として整理するなら、きちんと契約（データの扱いを取り決めた文書）を結び、委託先を監督する義務がある。
• 保存先が海外なら追加要件：サーバーが海外にあると、さらに条件が上乗せされる。

個人情報保護委員会も、本人の同意なく個人データを含むプロンプトを生成 AI に入力し、それが応答以外の目的に使われる場合は法に触れうる、と注意喚起しています。

コンサルの「自作サーバー」は、たいてい相手の管理下にあります。 そこへ生の顧客データを流すのは、同意も契約もないまま第三者に渡す形になりかねません。 入れてよい情報／ダメな情報の一般的な線引きは AI に入れてはいけない情報 にまとめています。

.env は「鍵束を丸ごと渡す」のと同じ

顧客データと並んで、絶対に渡してはいけないのが .env ファイルです。

.env には、API キーやパスワード、接続情報といった「鍵」がまとめて入っています。 これを渡すのは、家じゅうの鍵束を、知らない人にそのまま手渡すようなものです。

やっかいなのは、.env は「意図せず」一緒に流れやすいこと。 「このリポジトリごと読ませて」「このフォルダを全部渡して」とやった瞬間、隠れていた .env まで送られてしまいます。

• 単体で渡さないのはもちろん、
• フォルダやリポジトリごと渡すときは、.env が混じっていないかを先に確認する。

Claude Code のように手元のファイルを触るツールでの事故を防ぐ設定は、Claude Code を安全に使う設定 にまとめています。読み込ませてよい範囲を最初に決めておくと安心です。

それでも活かしたいなら、生のままでは渡さない

「便利さは捨てたくない」。その気持ちは正しいと思います。 ダメなのは「生データの丸投げ」であって、活かす道はあります。

• マスク・仮名化する：「田中様」→「A 様」、番号や社名も記号に置きかえる。
• 必要な部分だけ渡す：全部ではなく、相談に要る列や範囲だけを抜き出す。
• 自分の管理下で動かす：どうしても MCP を使うなら、他人任せにせず、自分が中身とログを確認できる形で立てる。
• 契約と同意を先に整える：業務で本気で使うなら、委託契約と本人同意を先にそろえる。順番を逆にしない。

実際にあった話

じつは私も、一度ヒヤッとしています。

AI に実績データをまとめさせようとしたとき、その中に社内だけの独自のやり方（ノウハウ）まで混じっていて、そのままアップロードしかけました。 送信の直前で気づいて、ギリギリで手を止めたのです。「便利だから」と手が先に動いているときほど、この見落としは起きます。

もうひとつ、ハッカソンで聞いて印象に残った話があります。 名前は伏せますが、大手のシステム会社ですら、AI にかける前にデータへマスクをかけて処理している、と。 体力のある大企業でさえ生データは流さないのに、個人や中小がコンサルの自作サーバーへ丸投げするのは、やはり無理があります。

今回のコンサルの件は、まだ「提案」の段階のはずです。 その場で「やってみます」と即答せず、いったん持ち帰る。 「顧客データは渡せません。渡すとしてもマスク済みで、契約と同意を整えてから」と線を引くだけで、あとから安全に活かす道は残せます。

よくある疑問

Q. 自作の MCP サーバーって、それ自体が危ないのですか？ 自作かどうかが問題ではありません。危ないのは「誰が管理し、渡したデータがどこへ行くか、自分から見えない」状態です。自分で管理すれば行き先は見えますが、他人が用意したものは中身もログも確認できません。

Q. 相手を信用しているなら、顧客データを渡してもいいですか？ 信用と、渡してよいかは別の話です。顧客データは本人から預かったもので、あなた一人の判断で外に出してよいものではありません。第三者提供や委託にあたり、同意や契約が必要になります。

Q. マスクをかければ渡してもいいですか？ リスクはぐっと下がりますが油断は禁物です。断片から個人が特定できてしまうこと（再識別）や、フォルダごと渡して .env が紛れ込むことがあります。伏せたうえで、必要な部分だけに絞りましょう。

まとめ

コンサルの自作 MCP サーバーに顧客データを投げる。 その直感的な「ダメでしょ」は、理由をたどると、しっかり筋が通っています。

• 行き先が見えない：他人のサーバーを通ったデータが、どこに残るか確かめられない。
• 一人で決めていい話ではない：顧客データは第三者提供・委託の問題で、同意や契約が要る。
• .env は鍵束：単体でも、フォルダごとでも、絶対に渡さない。
• 活かすならマスク前提：生データの丸投げはしない。大企業でさえ伏せてから使っている。

便利さは、安全な形にととのえてから取りにいけば十分間に合います。 まずは次にその提案が来たとき、「いったん持ち帰ります」と言えること。ここから始めてみてください。