UsercentricsのMCP統制とは？｜AIが顧客データを読む前に

「マーケのAIに顧客管理の仕組みをつないだら、どの顧客の情報まで読んでいるのか誰も説明できなくなった」「同意の記録はきちんと取っているのに、それがAIの読み出しに効いているのかが分からない」——生成AIのエージェントを業務の仕組みにつなぎ始めた会社で、法務と情シスから上がり始めた疑問です。同意管理の大手 Usercentrics は2026年1月14日、AIと業務の仕組みをつなぐMCPの関所を作る MCP Manager を買収しました。月に88億件の同意を処理すると公表している会社が、AIの読み出しに手を伸ばした格好です。ただ、同意を取っていることと、AIがその同意の範囲で顧客データを読んでいることは、別の問題です。この記事では、Usercentrics の MCP Manager が何をする製品かを押さえたうえで、マーケのAIが顧客データを読む場面ごとに、同意と利用目的をどう効かせ、誰が記録を見て、誰が止めるかを整理します。

Usercentrics の MCP Manager とは：AIと業務の仕組みの間に置く関所

MCP Manager は、社員が使うAIの道具と、顧客管理や共有フォルダ、チャットなどの業務の仕組みにつながるMCPサーバーとの間に入る中継の仕組みです。公式の製品ページは「AIの活用を安全に広げるためのMCPの関所」と説明し、情シスが一か所で、どのAIがどの仕組みにどうつながっているかを管理できることを打ち出しています。MCPそのものの仕組みは別の記事で扱っているので、ここでは関所に何を任せられるかに絞ります。

製品ページが標準で備えるとしている機能は、承認済みのMCPサーバーだけを並べる社内の登録簿、役割に応じた権限、通信の記録、個人情報の検出と伏せ字、利用者の一括認証、道具の定義が勝手に差し替えられることへの備え、そして決まりの強制です。つながる先として、Salesforce、HubSpot、Slack、GitHub、Google Drive、Notion、Snowflake などのMCPサーバーと、社内で作ったMCPサーバーが挙がっています。

AIの道具の側は、Claude、Claude Code、Cursor、GitHub の Copilot、ChatGPT、Windsurf などが挙がっています。つまり、社員がどのAIの道具を使っていても、業務の仕組みにつながる経路をこの関所に集めるという発想です。マーケ部門が ChatGPT から顧客管理の仕組みを読み、開発部門が Cursor から社内の文書を読む、といった経路を、同じ関所で記録し、同じ決まりで絞れることになります。

2026年1月の買収：同意管理の会社がMCPに手を伸ばした理由

Usercentrics は、ドイツのミュンヘンに拠点を置く同意管理の会社です。買収の発表文では、自社を「プライバシーを起点にしたマーケティング」の分野の大手と位置づけ、195か国の240万を超えるサイトとアプリを支え、月に88億件の同意を処理していると説明しています。MCP Manager は2025年にニューヨークで立ち上がった製品で、発表文によれば、開発チームにはMCPの公式の仕様に貢献した人が含まれます。買収の金額は公表されていません。

発表文が挙げた買収の理由は、MCPがAIと業務の仕組みをつなぐ一方で、同意や社内の決まり、判断の説明可能性を、仕組みとしては強制しないという点です。例として、AIエージェントが同意の確認なしに顧客管理の仕組みのデータを読むこと、AIの判断を規制当局に説明できないことが挙がっています。Usercentrics は、MCP Manager をプライバシー起点のマーケティングの製品群と統合し、サイト、アプリ、社内の仕組み、顧客と話すAIエージェントにまたがって、同意と好みとデータの統制を扱うとしています。

MCP Manager の創業者マイケル・ヤロシェフスキー氏は、Usercentrics のAI担当の副社長として加わりました。最高経営責任者のドナ・ドロール氏は、EUのAI法が今年から執行の段階に入ることにも触れています。発表から9か月が過ぎた現在も、製品ページは Usercentrics のサイトの中で更新されており、提供終了や新規受付の停止の告知はありません。

何ができて、何が公式には書かれていないか

導入を検討する前に、製品ページで確かめられることと、確かめられないことを分けておきます。確かめられるのは、関所としての機能です。利用者ごとの認証を経てどの接続が誰のものかを結びつけること、承認済みのMCPサーバーを社内の登録簿に並べること、使える道具を人とエージェントごとに絞ること、AIとMCPサーバーの間のデータと道具の呼び出しを記録し、表計算の形式で書き出せることです。記録の保存期間は契約の段階に応じて14日、30日、90日と示されています。

個人情報の検出も段階があり、決まった型の文字列を見つける規則、マイクロソフトが公開している検出の仕組み Presidio を使った検出と伏せ字、さらに上位の契約では Amazon Bedrock の安全機能など外部の検出の仕組みをつなぐ形が示されています。既存の持ち出し対策の仕組みと連携する口もあるとしています。

一方で、Usercentrics が持つ顧客の同意の記録を、AIの読み出しの判定に直接使う機能は、買収の発表で方向として語られているものの、製品ページでは具体的な機能として確かめられませんでした。サイトの同意管理の仕組みと MCP Manager が、いまの時点でどこまでつながっているかは、提供元に確認が必要です。

• ここでの機能と保存期間は、2026年10月時点の公式の製品ページの記載に基づきます。契約の段階によって使える機能が変わるため、必要な機能がどの段階に含まれるかを見積の段階で書面にしてもらってください
• 同意の記録との連動は、将来の機能として語られている段階と考えておくのが安全です。導入の判断は、いま確かめられる関所の機能だけで成り立つかで行います

前提：同意と利用目的は、AIの読み出しには自動で効かない

マーケ部門が顧客データを扱う根拠は、多くの場合、プライバシーポリシーで示した利用目的と、メルマガの配信などで取った同意です。日本の個人情報保護法では、個人情報を扱うときに利用目的をできる限り特定し、その目的の範囲を超えて扱う場合には、原則として本人の同意が必要になります。問題は、この目的と同意が、AIエージェントが顧客管理の仕組みを読む経路では、自動的には確かめられないことです。

AIの道具がMCPで顧客管理の仕組みにつながると、AIは利用者の権限の範囲で、顧客の氏名、会社名、問い合わせの内容、商談の記録をまとめて読めるようになります。その読み出しが、もともとの利用目的に含まれるのか、配信を止めた顧客のデータまで読んでいないかは、顧客管理の仕組みの側でも、AIの側でも、誰も確かめていない状態になりがちです。よくある誤解を並べると、次のようになります。

• 同意管理の仕組みを入れているので、AIも同意の範囲でしかデータを読まないと考える
• 顧客管理の仕組みの閲覧権限がある社員のAIなら、何を読ませても問題ないと考える
• AIの道具の法人契約で学習に使われないので、読ませる範囲は気にしなくてよいと考える
• 読んだ記録はAIの道具の側に残っているはずなので、後から調べられると考える
• 配信を止めた顧客も、分析のためなら読ませてよいと、目的を確かめずに決める

MCP Manager のような関所は、この状態を変えるための道具です。ただし関所が自動で正しい判断をするわけではありません。どの目的のAIに、どの顧客の、どの項目を読ませてよいかを決めるのは会社の側で、関所はその決定を経路の上で強制し、記録に残す役割を担います。以下では、マーケの場面ごとにその決定の中身を見ていきます。

シナリオ1：マーケのAIが、顧客管理の仕組みから見込み客の一覧を読む

最初の場面は、マーケ担当が ChatGPT や Claude に「先月のウェビナーに参加した見込み客のうち、製造業で従業員が多い会社を一覧にして」と頼み、AIが HubSpot や Salesforce のMCPサーバー経由で顧客管理の仕組みを読む場面です。作業は数分で終わりますが、AIは担当者の権限で読める範囲のすべての項目を読める状態にあります。氏名、メールアドレス、電話番号、過去の問い合わせの本文まで、一覧づくりに要らない項目も含まれます。

関所でできることは二つです。一つは、道具単位の権限で、AIに使わせる道具を「検索と一覧の取得」に絞り、更新や削除の道具を外すことです。もう一つは、個人情報の検出と伏せ字で、電話番号やメールアドレスをAIに渡す前に消すことです。一覧づくりに要るのは会社名と業種と参加の有無で、個人の連絡先は要らないと決めれば、その決定を関所の設定に落とせます。

ただ、伏せ字は万能ではありません。問い合わせの本文のように、自由に書かれた文章の中の個人情報は、型で見つけにくく、日本語の氏名や住所をどこまで正しく検出できるかは試してみないと分かりません。伏せ字に頼る前に、そもそもAIに読ませる項目を顧客管理の仕組みの側で絞れないかを先に考えます。項目を絞ったAI用のMCPサーバーを用意できれば、伏せ字は二重の備えとして働きます。

シナリオ2：エージェントが問い合わせの履歴を要約し、メールの案を作る

二つ目の場面は、営業支援のエージェントが、問い合わせの履歴と商談の記録を読んで要約し、次のメールの案を作る場面です。一つ目の場面との違いは、人が都度頼むのではなく、エージェントが決まった時間に自動で読み続けることです。誰の権限で動いているか、何件の顧客の記録を読んだかが、担当者の目に入りにくくなります。

MCP Manager の製品ページは、すべての接続を認証し、利用者かエージェントに結びつけると説明しています。エージェントには専用の資格を与え、人の資格を借りて動かさないことが基本です。エージェント専用の資格にしておけば、記録の上で、人の操作とエージェントの操作を分けて追えるからです。人の資格で動くエージェントは、その人が異動や退職をしたときに止まるか、逆に誰の管理下にもないまま動き続けるかのどちらかになります。

この場面で利用目的を効かせるには、エージェントの目的を一文で書き、その目的に要る範囲だけを読ませます。たとえば「商談中の顧客への次の連絡の案を作る」が目的なら、商談中ではない顧客や、配信停止を申し出た顧客の記録は読ませないように、顧客管理の仕組みの側で対象を絞ったうえで接続します。関所の記録は、目的の外の記録を読んでいないかを後から確かめる材料として使います。

シナリオ3：社員が個人の判断で、新しいMCPサーバーをつなぐ

三つ目の場面は、関所の外で起きます。マーケ担当が、便利だと聞いたMCPサーバーを、自分のAIの道具に個人の判断でつなぐ場面です。公開されているMCPサーバーは数千規模にのぼるとされ、その中には、提供元がはっきりしないもの、読み込んだデータを外へ送る作りのものも含まれます。関所を入れても、関所を通らない接続が残れば、記録は穴だらけになります。

MCP Manager の社内の登録簿は、この穴をふさぐための機能です。承認したMCPサーバーだけを並べ、社員はそこから選ぶ形にすることで、許可していない接続を減らします。製品ページも、登録簿が許可されていないAIの利用を止める助けになると説明しています。ただし、登録簿は社員のAIの道具の設定を直接書き換えるものではないため、関所を通さない接続を禁じる規程と、端末の設定の点検を組み合わせる必要があります。

登録簿に載せる前の審査も決めておきます。提供元、読める範囲、書き込みの有無、データの送り先を確かめ、マーケの業務に要るものから順に載せます。審査を待つ時間が長すぎると、社員は登録簿を避けて個人の判断でつなぐため、審査の目安の日数を決め、申請の窓口を一つにしておくことも、関所を機能させる条件になります。

シナリオ4：つないだ道具の説明が、ある日書き換わる

四つ目の場面は、承認したMCPサーバーが後から変わる場面です。MCPサーバーは、AIに対して「この道具は何をするか」という説明を渡し、AIはその説明を読んで道具を使います。提供元の更新や乗っ取りによって、道具の名前や説明が書き換わり、承認したときとは違う動きをすることがあります。説明の中に、AIへの隠れた指示が仕込まれる攻撃も知られています。

製品ページは、道具の名前の変更、新しい道具の追加、説明の書き換えを検知し、知らせる、再承認を求める、接続を自動で止める、のいずれかを選べると説明しています。マーケの業務で顧客データを読むMCPサーバーについては、説明が変わったら自動で止め、再承認されるまで使わせない設定にしておくのが安全です。業務は一時的に止まりますが、顧客データが意図しない動きで外へ出るよりは、はるかに影響が小さく済みます。

再承認の担当も決めておきます。変更の中身を読み、業務に必要な変更か、不審な変更かを判断するのは、情シスの担当です。マーケの担当が急いで再承認してしまうと、この仕組みは意味を失うため、再承認の権限はマーケ部門には渡しません。変更の頻度が高いMCPサーバーは、登録簿から外すことも選択肢になります。

記録の使い方：誰の資格で、何を読んだかを後から追う

関所の価値の中心は、記録です。製品ページは、AIとMCPサーバーの間のデータと道具の呼び出しを、後から調べられる記録として残し、表計算の形式で書き出せると説明しています。顧客から「自分のデータがAIに使われたか」と問い合わせを受けたとき、記録がなければ答えられません。記録は、顧客への説明と、事故のあとの調査の両方の土台になります。

気をつけたいのは保存期間です。製品ページでは契約の段階によって14日から90日と示されており、上位の契約では外部の監視の仕組みへ記録を送る機能もあります。個人情報の漏えいの疑いに気づくのが数か月後になることを考えると、関所の中の保存期間だけに頼らず、社内の記録の置き場に定期的に移す運用を決めておく必要があります。逆に、記録には顧客データの断片が含まれる可能性があるため、移した記録の保存期間と、見られる人も決めます。

記録を見る場も決めておきます。月に一度、マーケのAIとエージェントがどの顧客の記録を何件読んだか、目的の外と思われる読み出しがなかったか、伏せ字が働かなかった項目がなかったかを確かめます。AIに記録を集計させてもよいが、目的の外かどうかの判断は人がするという線を守ります。集計させる場合も、集計の対象にした期間と件数を必ず添えさせます。

止め方：接続を切る、道具を外す、エージェントを止める

関所を置く利点の一つは、止める場所が一つになることです。顧客データの扱いに問題が見つかったとき、各社員のAIの道具の設定を一つずつ直すのではなく、関所で接続を切れば、すべてのAIの道具からその経路が止まります。止め方は三つの段階で考えます。特定の道具だけを外す、特定のMCPサーバーへの接続を切る、特定のエージェントの資格を止めるの三つです。

どの段階で止めるかは、問題の大きさで決めます。更新の道具が誤って使われたなら、その道具だけを外します。MCPサーバーの提供元に問題が見つかったなら、接続を切ります。エージェントが目的の外の記録を読み続けているなら、その資格を止めます。止める判断を誰がしてよいかを、段階ごとに先に決めておくことが大切です。夜間や休日に問題が見つかったとき、判断する人が決まっていなければ、止めるまでの時間が延びます。

止めたあとの戻し方も決めます。止めた理由、影響を受けた業務、再開の条件を記録し、再開は止めた人とは別の人が承認する形にすると、急いで再開して同じ問題を繰り返すことを防げます。関所そのものを止める場合の手順も用意しておきます。関所が止まるとAIから業務の仕組みへの経路が全部止まるため、業務への影響を事前に洗い出しておきます。

情シス・法務・マーケの分担

関所を入れても、決める人がいなければ設定は誰も直さない状態になります。AIが顧客データを読む経路の統制は、情シスだけでも、法務だけでも、マーケだけでも決められません。経路の管理は情シス、目的と同意の解釈は法務、業務に要る範囲の申請はマーケと分け、それぞれの持ち場を表にしておきます。

決めること	主な持ち主	相談先	決めた内容の置き場
登録簿に載せるMCPサーバー	情シス	マーケ（業務に要るか）	関所の登録簿と審査の記録
AIに読ませる項目と顧客の範囲	マーケが申請、法務が確認	情シス（設定の可否）	利用目的ごとの一覧
利用目的と同意の範囲の解釈	法務	マーケ（実際の使い方）	プライバシーポリシーと社内の手引き
エージェントの資格の発行と停止	情シス	マーケ（エージェントの持ち主）	資格の台帳
記録の保存期間と閲覧の権限	情シスと法務	監査の担当	記録の管理の規程
説明の書き換え時の再承認	情シス	提供元	変更の記録

表で特に大切なのは、AIに読ませる項目と顧客の範囲を、マーケが申請し法務が確かめる流れにすることです。マーケは業務に要る範囲を一番よく知っていますが、要る範囲と、読ませてよい範囲は同じではありません。法務が利用目的と照らして確かめ、情シスがその決定を関所の設定に落とす。この三者の流れが回れば、関所の設定が実際の業務とずれていくのを防げます。

国内の個人情報保護法への写し方

MCP Manager は海外の製品で、製品ページの説明はEUの規制を意識したものが中心です。日本の会社が使う場合は、国内の個人情報保護法の考え方に写して設計します。中心になるのは三点です。一つ目は利用目的で、AIに顧客データを読ませる用途が、プライバシーポリシーで示した利用目的に含まれるかを確かめます。含まれない場合は、目的を変更できる範囲か、本人の同意が必要かを法務が判断します。

二つ目は、データが社外に出るかどうかです。関所を通るデータは、Usercentrics の仕組みを経由します。関所の提供元が顧客データを扱う場合は、委託として、委託先の監督が必要になります。さらに、処理する場所が海外であれば、外国にある第三者への提供にかかわる確認が必要になる場合があります。製品ページでは、処理する場所の国や地域は確かめられず、上位の契約で個別のデータ処理の契約に対応すると示されています。AIの道具の提供元へデータが渡る点も、同じ観点で確かめます。

三つ目は安全管理措置です。関所の記録、道具単位の権限、伏せ字は、個人データの安全管理措置として説明できる材料になります。ただ、道具を入れただけで措置が完了するわけではなく、誰が設定を変え、誰が記録を見て、どんな周期で見直すかという組織の手当てとあわせて初めて措置になります。条文の当てはめは会社の事情で変わるため、最終的な判断は法務部門や顧問弁護士に確認してください。

費用の増え方とやめ方

MCP Manager の製品ページには、月額の料金が段階ごとに示されており、無料の試用期間もあります。段階が上がるにつれ、記録の保存期間が延び、個人情報の検出の仕組みが強くなり、利用者の一括認証や独自の役割が加わります。料金の一覧を並べることはしませんが、費用の考え方として押さえておきたいのは、顧客データを扱う前提で必要な機能は、上位の段階に寄っていることです。

具体的には、日本語を含む個人情報の検出、会社の認証の仕組みとの連携、長めの記録の保存、個別のデータ処理の契約が、マーケの顧客データを扱う場合にほぼ必須になります。最下位の段階の価格で予算を組むと、実際に必要な段階に上げた時点で費用が数倍になることがあります。試用の段階で、必要な機能がどの段階に含まれるかを確かめ、その段階の価格で費用対効果を考えます。

やめ方も確かめておきます。関所をやめると、AIの道具と業務の仕組みの間の経路は、元の直接の接続に戻ります。そのとき、関所で絞っていた道具の権限や伏せ字は効かなくなります。やめる前に、各MCPサーバーの側で読ませる範囲を絞れているかを確かめ、関所に頼り切った設計にしないことが、乗り換えやすさにもつながります。記録は、やめる前に社内の置き場へ書き出しておきます。

導入前に確かめる項目

ここまでの内容を、導入の判断の前に確かめる項目として並べます。すべてに答えが出ていなくても構いませんが、答えが出ていない項目は、試行の段階で確かめる項目として残しておきます。

• マーケのAIとエージェントが、いまどのMCPサーバーにつながっているかの一覧があるか
• AIに顧客データを読ませる用途が、プライバシーポリシーの利用目的に含まれるかを法務が確かめたか
• 読ませる項目と顧客の範囲を、用途ごとに一覧にしたか
• エージェントに人の資格を借りさせず、専用の資格を発行する運用にしたか
• 道具の説明が変わったときに自動で止め、情シスが再承認する設定にしたか
• 記録の保存期間を、関所の中の期間とは別に社内で決めたか
• 止める判断を段階ごとに誰がするかを決めたか
• 処理する場所の国と、委託・越境の扱いを提供元と契約書で確かめたか
• 同意の記録との連動が、いまどこまで提供されているかを提供元に確かめたか

最後の項目は、Usercentrics を選ぶ理由そのものにかかわります。同意管理の会社の関所を選ぶ価値は、同意の記録とAIの読み出しが将来つながることにあります。いま必要なのが関所の機能だけなら、ほかの選択肢と比べる意味もあります。逆に、サイトの同意管理ですでに Usercentrics を使っている会社なら、連動の見通しを確かめる価値は高くなります。

小さく試す手順

関所は、全社のAIの経路を一度に集めようとすると、設定と審査が追いつきません。マーケ部門の一つの用途から始め、記録を読んで設定を調整してから広げます。

試行で確かめたいのは、日本語の氏名や住所、自由記述の問い合わせの本文で、伏せ字がどこまで働くかです。伏せ字が効かない項目は、関所ではなく接続の段階で読ませないと決めるのが確実です。試行の結果をもとに、関所に任せる範囲と、業務の仕組みの側で絞る範囲を切り分けていきます。

まとめ

Usercentrics の MCP Manager は、AIの道具と業務の仕組みの間に置く関所で、承認済みの接続の一覧、道具単位の権限、利用者とエージェントの認証、通信の記録、個人情報の検出と伏せ字を備えています。同意管理の会社が2026年1月に買収したことで、同意とAIの読み出しをつなぐ方向が示されましたが、同意の記録がAIの読み出しに自動で効く段階には、まだ確かめられる形では至っていません。マーケのAIが顧客データを読む場面ごとに、読ませる項目と顧客の範囲を法務と決め、関所で記録し、止める人を決めておくこと。そのうえで、処理する場所と契約の条件を確かめ、小さな用途から試すこと。この順で進めれば、AIの活用と顧客の同意の両方を守る形に近づけます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。