個人情報はここで止まれ。PerplexityのPrivacy Gate、その実力と限界

まず初めに

IT Postでは、AIに必要なのは「何でも覚える頭」だけでなく、「それは外へ持ち出すな」と止める門番だと考える。よく気がつく助手ほど、こちらの事情を知りたがる。便利にしたいから資料を渡す。すると今度は、どこまで運んでよいかの仕分けが始まる。助手を雇ったら、こちらに守衛の仕事が増えた。これは困る。Privacy Gateが面白いのは、その守衛の持ち場をパソコン側へ戻そうとしている点だ。

※個人の感想です

正式な呼び方と、3つの役割

公式資料で使われている表記は「Privacy Gate」です。独立した万能チャットAIの名称ではなく、端末とクラウドの間で情報の扱いを制御する機構を指します。研究・製品の説明を読む際には、次の3つを区別すると分かりやすくなります。

名前	役割
Privacy Gate	外部へ送る情報を、製品のルールに従って制御する仕組み
PII-Tracer	個人を識別できる情報が文章のどこにあるかを検出するモデル
PII-TRACE	長い会話で個人情報の検出能力を評価するためのベンチマーク

PIIは、個人を識別できる情報を表す英語の略です。氏名や連絡先などが例に挙がります。ここでいう検出は、文章の中から対象の範囲を見つけることです。見つけた後に送信を止めるのか、伏せるのか、承認を求めるのかは、アプリ側の制御です。

つまり、検出モデルだけを手元へ持ってきても、Computer全体の送信管理や組織向け設定まで付いてくるわけではありません。文章を点検する部品と、情報を運ぶ経路を管理する製品を分けて理解する必要があります。

Macから出す前に、何をするのか

Hybrid Computeの公式発表は、クラウドに調査や計画を任せ、Mac内のモデルに保護対象ファイルなどを処理させる構成を示しています。Privacy Gateは、保護対象の情報がクラウドへ届く前に、内容を伏せる、端末内に残す、処理を拒否する、同意を求めるといった対応を取れます。

Enterprise向けには、端末から出してはいけない情報、伏せて送れる情報、承認が必要な情報を組織全体で設定し、情報が外部へ出た場面を監査できると説明しています。これは企業向けの製品機能であり、個人向けプランの全利用者に同じ管理画面があるという意味ではありません。

仕組みをイメージするなら、架空の「取引先Aの非公開資料を参考に、市場の公開情報を調べる」作業を考えると分かりやすいでしょう。公開市場を調べる問い合わせと、相手の未発表情報を読む処理は、同じ仕事でも性質が違います。どの部分を外へ出せるかを途中で判断する必要があります。この例はIT Postによる説明用で、実機の動作確認結果ではありません。

約6億パラメータの検出モデルも公開

公式Hugging Faceの次のリポジトリでは、会話の個人情報をマスクするモデルが公開されています。

perplexity-ai/pplx-pii-masking

モデルカードは、Qwen3系を基にした約6億パラメータのモデルと説明しています。文章の前後を参照して対象範囲を分類し、会話全体の機微きび性も判定する構成です。コードでは検出位置を得る処理と、検出した部分を置き換える処理が用意されています。ライセンス表記はMITです。

対象の分類には、人名、アカウント番号、非公開のURL、日付、住所、メールアドレス、電話番号、その他の個人情報、秘密情報という9種類があります。ただし、分類名に「秘密情報」があることと、あらゆる会社の機密を理解できることは同じではありません。

例えば、氏名や電話番号を含まない発売前の製品計画も、会社には重要かもしれません。個人情報の分類と、会社ごとの持ち出し禁止基準は一致しない場合があります。製品の保護ルールと、実際に扱う情報の種類を対応させて考える必要があります。

研究で説明されるPII-Tracerと公開モデルには、規模や構造に対応する説明があります。一方、Macアプリ内で動作している版と、この公開ファイルが完全に一致するかは確認できていません。本記事では、公開部品の存在と、製品全体の実装を同一視していません。

長い会話では「一度見つけた」では足りない

PerplexityのPII-TRACEは、同じ個人情報が会話中に繰り返される場面を重視しています。最初の住所を隠しても、後半でもう一度出てきた住所を見落とせば、情報は残ります。会話を一文ずつ別々に検査するだけでは見えにくい課題です。

同社は、繰り返し登場する識別情報を全箇所で検出できた割合を79.4%と報告しています。さらに、入力の窓を重ねながらずらして処理する方法では95.4%へ改善したとしています。これは研究の評価条件下の値です。「利用者の個人情報が95.4%の確率で安全」という数字ではありません。

公開モデルのREADMEも、標準の入力上限が4,096トークンで、長い文書は分割して扱う必要があると説明しています。トークンはAIが文章を処理する単位で、文字数と一対一には対応しません。長い文章をただ渡すだけで、末尾まで点検されると考えないことが重要です。

日本語の精度と、公開状況は分けて確認

研究は13言語の会話を用いた評価を紹介していますが、本文で言語別の結果を示しているのは英語、ドイツ語、フランス語、イタリア語、ロシア語、韓国語の6言語です。その図だけでは日本語での性能は判断できません。

また、研究記事の末尾にはモデルとベンチマークの公開予定が記されています。一方、9月8日時点では前述の検出モデルのファイルは取得可能でした。研究記事の予定表現だけで「何も公開されていない」と扱うのも、モデルが見つかっただけで「評価データまで全部公開済み」とするのも不正確です。

IT Postでは、日本語の架空データを用いた長文検査や、Macアプリから実際に送信される内容の検証は実施していません。したがって、日本語の機密文書を無条件に任せられるという評価はしていません。

IT Postの見方——門番は歓迎。ただし合鍵を配るな

IT Postでは、情報を送る前に検査し、その場で止める仕組みを高く評価する。AIをもっと便利にする競争に、外へ出さないための技術が組み込まれるのは良い方向だ。

ただし、門番を置いたからといって、建物全体が金庫になったわけではない。検出漏れもあれば、個人情報ではない企業秘密もある。毎回面倒だからと承認を何でも通してしまえば、せっかくの門も飾りになる。玄関に立派な門扉を付けて、横に「ご自由にどうぞ」の通路を作っては困る。

ここで欲しいのは、利用者に不可能な注意力を要求しない設計だ。何を検出したか。何が送られるか。止めたら仕事はどう続くか。その説明が読めて、判断できて、後から確認できること。IT Postでは、見栄えのよい安全マークより、その地味な手順こそ製品の実力だと考える。

公開コードがあるのも一歩前進だ。検査の入口や長文の制限を、説明だけでなく実装から確かめられる。ただし、部品を公開することと、組み上がった製品の全経路を検証できることは別だ。その距離まで説明してくれれば、期待は信用へ近づく。

AIに自分の事情を知ってほしい。しかし、知った事情を全部持ち歩いてほしくはない。その二つを同時に求めるのは、利用者のわがままではない。仕事の道具なら当然だ。Privacy Gateには、その当然を毎回の注意書きではなく、実際に働く仕組みへ変える役目を期待したい。