Column
MuPPET:複数参加者会話におけるLLMアシスタントの文脈的プライバシーベンチマーク
Slack ボットや Teams Copilot のようにグループ会話に組み込まれた LLM が、誰の情報をどの文脈で開示するかを評価するベンチマーク MuPPET が登場。現行 LLM の文脈的プライバシー判断の脆弱性が明らかになった。GDPR 対応を含む安全展開のために、法務・セキュリティ部門が今すぐ参照すべき評価プロトコルを解説する。
こんにちは。Affectosphere Group の井下です。
「Slack の AI ボットに話しかけたら、他のメンバーの個人情報が漏れた」
そんなインシデントは、まだ多くの組織では起きていないと思います。 でも、その「まだ」がいつ崩れるかは分かりません。
グループチャットへの LLM 統合が急速に進んでいます。 Slack ボット、Teams の Copilot、グループカスタマーサポートへの AI 組み込み。 複数の参加者が一つの会話に関わる場面に、LLM が日常的に入ってきています。
2026 年 6 月にarXivで公開された研究(arXiv:2606.23217)は、この文脈で非常に重要な問いを立てています。
「グループ会話に組み込まれた LLM は、誰の情報をどの文脈で開示してよいかを、本当に理解しているのか」
今日の 3 点
- MuPPET は「文脈的インテグリティ」の観点から LLM のプライバシー判断を評価する初のベンチマーク。
- 現行の主要 LLM は複数参加者会話における文脈的プライバシー判断に顕著な脆弱性を持つ。
- GDPR 対応企業はグループ会話 AI の展開前に MuPPET 評価プロトコルを参照した事前審査を行うことが有効。
① 「文脈的インテグリティ」という考え方
まず、この研究の核心にある「文脈的インテグリティ(contextual integrity)」という概念を押さえておきましょう。
もともとは哲学者 Helen Nissenbaum が提唱したプライバシー理論です。 情報のプライバシーは「秘密かどうか」ではなく、「その情報がどの文脈で流通するかが適切かどうか」によって決まる、という考え方です。
たとえば、こんな状況を想像してください。 グループカスタマーサポートのチャットで、Aさんが自分の住所を入力した。 そのスレッドを見ている他の顧客 B さんが、AI に「さっきの人の住所を教えて」と聞く。
AIがこの質問に答えてはいけないことは直感的に分かります。 でも、なぜいけないか——それは「住所という情報は、Aさんがサポート担当に伝えた文脈でのみ適切であり、他の顧客に開示する文脈では適切でない」からです。
MuPPET はこの「文脈的な適切さ」を LLM が判断できているかをテストするためのベンチマークです。
② LLM が苦手とするグループ会話特有のプライバシーリスク
一対一の会話と比べて、複数参加者が関与するグループ会話では何が難しいのか。
この研究が指摘するのは、グループ会話固有の情報フローの複雑さです。
まず、参加者が複数いるため、「誰の情報か」「誰に向けた発話か」が混在します。 AさんとBさんが同じスレッドにいるとき、AさんがLLMに共有した情報は、Bさんへの開示が自動的に許可されているわけではありません。
次に、会話の中で情報が「自然に流れて」しまうケースがあります。 LLM が要約や紹介をする際に、個人情報を適切な文脈の外で言及してしまう場面です。
さらに、グループの設定(社内チームか、顧客混在の場か、公開フォーラムか)によって、同じ情報でも開示の適切さが変わります。 現行のLLMはこの文脈の違いを十分に識別できていないことが、MuPPETの評価で示されています。
③ MuPPET 評価プロトコルとは何か
MuPPETは具体的にどのような評価を行うのか。
ベンチマークは、実際のグループ会話シナリオを模した設定で LLM に問いかけを行います。 名前、所属、連絡先、会話内容など複数の個人情報を含む複数参加者の会話ログに LLM が関与する状況を設定し、「誰の何の情報を、誰に対して開示するか」の判断を評価します。
文脈的インテグリティの枠組みに沿って、「この開示は適切か不適切か」を正解ラベルとして判定します。 そして LLM の判断と照合することで、文脈的プライバシー判断の精度を定量的に測定します。
重要なのは、これが「秘密情報を守れるか」という単純なテストではないという点です。 「どの情報がどの文脈で誰に伝わってよいか」というより繊細な判断を問うものです。 この点で、既存のプライバシー評価ベンチマークとは異なるアプローチを取っています。
④ 企業展開へのインプリケーション:法務・セキュリティ・DX部門が今すべきこと
では、この研究の知見をどう実務に活かすか。
具体的なユースケースとして、グループカスタマーサポートへの LLM 導入を考えてみましょう。
複数の顧客が同じチャットスレッドに参加する形式のサポートでは、LLM が「誰の情報か」「この顧客に開示してよいか」を適切に判断できなければ、プライバシー侵害リスクが生じます。 GDPR の観点からは、個人データの不適切な第三者開示は罰則の対象になりえます。
MuPPET 評価プロトコルを活用した事前審査のステップとして、以下を提案します。
まず、導入を検討している LLM ベースのグループ会話 AI について、MuPPET のシナリオセットを使って文脈的プライバシー判断の精度を評価します。 論文に基づくシナリオ設計で、自社の利用ケース(Slack ボット、Teams Copilot、サポートチャット)に当てはめたカスタマイズが可能です。
次に、評価結果をもとにシステムプロンプトやアクセス制御の設計を見直します。 「この参加者には開示しない」「この文脈では個人情報に言及しない」というルールをシステムプロンプトで明示する設計が有効です。
さらに、定期的な再評価サイクルを設計します。 LLM モデルのアップデートで動作が変わるため、半期ごとに MuPPET ベースの評価を実施することを社内プロセスに組み込むことをお勧めします。
この評価プロトコルは、GDPR のデータ保護影響評価(DPIA)の一部として文書化することもできます。 「グループ会話プライバシーリスク審査を実施した」という記録は、規制対応の根拠として機能します。
漏洩リスクは「知らなかった」では済まない
グループ会話への LLM 統合は、利便性の点で非常に魅力的です。
でも、「誰の情報を、誰に、どの文脈で伝えてよいか」という判断は、LLM 単体では現時点では不完全です。 MuPPETはそれを実証したベンチマークです。
導入前に「このシステムは文脈的プライバシーの判断を正しくできているか」という問いに答えを出しておくこと——それが、安全な展開の出発点だと思います。
では!
参考論文
- Welch, M., & Diab, M. (2026). MuPPET: A Multi-Party Privacy Evaluation Test for LLM Assistants in Multi-Party Conversational Contexts. arXiv preprint arXiv:2606.23217.
※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。