この文書は元の英語版を機械翻訳したものです。翻訳版と英語版の間に相違がある場合は、英語版が優先されるものとします。 英語版の原文を読む
オンデバイス仮名化ツール：開発とベンチマーク
2026-05-22 · Caiioo Team
私たちは、AIシステムが実在の個人情報を学習・保持するというプライバシー問題の解決を目指しました。「データ保持ゼロ」ポリシーや契約はリスクを軽減しますが、例外だらけです。それらは本質的にこう言っています。「セキュリティ目的、政府の監視、訴訟ホールド、製品開発、エラーログ、サービス改善など、膨大な例外リストを除き、プロンプトや出力は保存しません。」
これを解決するために、ユーザー自身のマシンで動作し、デバイスから離れる前にメッセージを確認し、フィルターなしで入力した場合と同じ回答を返す個人データフィルターを構築しました。
そして完成しました。Caiiooの次期バージョンには、この仮名化ツール（Pseudonymizer）が含まれます。エージェントチャットのシールドアイコンや設定からアクセス可能です。
このホワイトペーパーでは、当社のプライバシーフィルタリングシステムの根拠、アーキテクチャ、評価プロセス、および設計原則の概要を説明します。
私たちが目指したもの
データ最小化による一般的なプライバシー保護。 ユーザーがリモートモデルとチャットする際、モデルがユーザーの質問に答えるために、本名、住所、実際のメールアドレス、あるいは顧客の電話番号は必要ありません。モデルが必要とするのは質問の「形状」であり、LLMがそのクエリをテスト用として却下しないための、本物の質問のような外観です。そのため、フィルターはAIに送信されるデータから実際の識別子を取り除き、戻ってくる際に実際の値を再結合します。モデルには合成された名前や識別子が表示され、ユーザーには実際の会話が表示されます。
HIPAAコンプライアンス支援。 第二のモードは、HIPAA Safe Harborルール（§164.514）における18の識別子、およびより緩やかなLimited Data Setバリアントを対象としています。臨床医、医療管理者、または対象となるワークフローに従事する誰もが、保護対象保健情報（PHI）をAIに送信することなく、実際の症例について汎用モデルと対話できます。私たちは対象組織のコンプライアンス責任者ではありませんが、PHIがそもそもラップトップから流出しないようにするレイヤーになることができます。私たちの評価は、組織がコンプライアンスおよびプライバシー基準に対するフィルターの適合性を評価するために使用できる、測定可能なベンチマークを提供します。すべてのプライバシーおよびセキュリティ対策は、ユーザーまたはユーザー組織の責任において行われる判断事項です。
私たちがこの両方を選択したのは、エンジニアリングが同一であり、PHIのユースケースは、Personal Dataカテゴリーのより一般的なデータよりも編集が容易な、明確な名前付きエンティティを使用するため、技術的には実際にはより簡単だからです。HIPAAフィルタリングは、一般的に英語またはスペイン語であるという事実によっても助けられています。私たちは識別子を検出し、同じ形式の安定した仮名および置換された識別子に置き換え、戻ってくる際にそれらを復元し、実際の値をログに記録することはありません。合成情報と実際の情報の間のマップはユーザーのデバイス上にのみ保持されるため、ユーザーはエージェントの応答内で実際の情報を読み取ることができます。モード間で変更されるのは、カテゴリーリストとポリシーゲートです。
なぜ正規表現と機械学習の両方を使うのか、片方だけではない理由
当社の匿名化ツールには、2つの主要なフィルタリング技術が搭載されています。決定論的なパターン認識言語である正規表現（regex）と、トレーニング済みの機械学習（ML）モデルです。
正規表現は、表面的なフォーマットにおいて無類の強さを発揮します。メールアドレスには特定の形式（[email protected]）があります。IPアドレス、クレジットカード、IBAN、VIN、SSN（XXX-XX-XXXX）、API キーも同様です。フォーマットが信頼できるものであれば、正規表現はモデルのロードや推論コストをかけることなく、毎回決定論的にそれらを捕捉します。
しかし、正規表現は**コンテキスト（文脈）**の把握には全く歯が立ちません。「先週の火曜日の Sarah のチャート」には人物名と日付が含まれていますが、どちらもフォーマットだけでは判別できません。「14 Elm の患者」には住所が含まれていますが、これは住所ではない何千もの文字列と重複します。「彼らの MRN は 7741032 です」という文では、数字の意味を理解するために周囲の単語が必要になります。
コンテキストの処理は、微調整（fine-tuned）された小型の言語モデルが担当します。当社のモデルは、多言語の小型言語モデルから蒸留された、特別にトレーニングされた110Mパラメータのエンコーダーです。これは部分文字列ではなく文章全体を読み取り、デバイス上（モバイル端末であっても）で極めて高速に動作するほど軽量です。
ベンチマークの結果は、これら2つのレイヤーが互いに補完し合っていることを示しています。各レイヤーが実際に役割を果たしているかを確認するため、2つのレイヤーを個別にベンチマークしました。モデルのトレーニングには明示的に使用されていない150問の PrivacyBench-PD 問題セットでの結果は以下の通りです。
| レイヤー | 捕捉された PII | 捕捉率 |
|---|---|---|
| 正規表現のみ | 205 / 670 | 30.6 % |
| ML のみ | 516 / 670 | 77.0 % |
| 両方（プロダクション環境） | 625 / 670 | 93.3 % |
正規表現だけでは、識別子の4分の3を見逃してしまいます。これは、実際の文章に含まれるほとんどの識別子が構造化されていないためです。ML だけでは、正規表現レイヤーが捕捉できたはずの16パーセントポイントを見逃します。これらは純粋にその形状に依存するもの（クレジットカードはクレジットカードに見えるものであり、モデルが追加できるシグナルはありません）です。両者を組み合わせることで、どちらか一方ではカバーできない領域を補完しています。
各レイヤーがどこで決定的な役割を果たしているかを詳しく見ると、同じデータセットにおいて、16個のテスト値は正規表現のみで捕捉され（メール、IP、金融口座、構造化 ID）、327個は ML のみで捕捉されました（名前、文脈依存の識別子、多言語の言い回し）。
軽量、スマート、高速 — そしてどこでも動作する
フィルターをデバイス上で動作させることは、エンジニアリング上の大きな挑戦でした。
アプリはブラウザ拡張機能、macOS、iOS、Android、Windows、Linuxなど多くのシステムで動作するため、軽量である必要があります。バンドルサイズはモデルあたり約113MBです。一般的な個人データ用と保護対象保健情報（PHI）用の2つのモデルがあり、セーフハーバーモードでは両方を並列で実行します。これらの中で低スペックのAndroidデバイスが最もパフォーマンスが低いですが、システムは問題なく動作します。
スマートである必要もあります。偽陰性（見逃し）はリモートLLMへの実データの流出を招き、偽陽性（過剰な検知）は会話を台無しにするからです。名前は伏せ字にする必要がありますが、代名詞はそのままにしなければなりません。転送されたスレッド内の医師のメールアドレスは伏せ字にすべきですが、フッターの [email protected] はおそらくその必要はありません。
ユーザーが送受信するすべてのメッセージの経路上に直接位置するため、高速でなければなりません。シングルCPUスレッドでの往復オーバーヘッドは200ms未満（主にトークン化）であることを計測しました。WebGPUやAppleのNeural Engine上では、LLM呼び出し自体のネットワーク遅延に比べれば微々たるものです。
Caiiooはマルチプラットフォームであるため、複数のランタイムで動作する必要があります。Chrome拡張機能、macOS、iOS、Android、Windows、Linuxで同じシステムが動作します。1つの検出モデル、1つの正規表現ライブラリ、1つのマージャー、1つのポリシーにより、Caiiooが動作するあらゆる環境で同一の挙動を実現しています。
スコア
数回にわたるテストとトレーニングを経て、モデルの第16バージョンを採用しました。以下に、それぞれ異なる側面を測定する3つのベンチマーク結果を示します。
独自テストセット：モデルが一度も目にしたことのない150の質問
公開ベンチマークでテストする前に、トレーニングデータから意図的に除外した内部テストセットに対して Personal Data フィルターを実行しました。したがって、検出器はこれらの質問を一度も見たことがありません。150の質問は4つのグループ（コードスニペット、ドキュメントの文章、意図的に馴染みのない言い回し、および10の非英語言語）に分けられ、さらにプライベートデータが一切含まれていない「ネガティブ」グループ（過剰な秘匿化を行わないかを確認するためのサニティチェック）が追加されています。統合された regex + ML パイプラインの結果は以下の通りです：
| サブベンチマーク | 検出数 | 検出率 |
|---|---|---|
| code_bench | 69 / 74 | 93.2 % |
| doc_bench | 233 / 247 | 94.3 % |
| generalization_bench | 123 / 133 | 92.5 % |
| multilingual_bench | 200 / 216 | 92.6 % |
| 全4つのポジティブベンチ合計 | 625 / 670 | 93.3 % |
（ネガティブグループには検出されるべきプライベートデータはありませんでした。フィルターは、本来すべきでない箇所を1箇所マスクしましたが、これは後述する適合率の数値と一致しています。）
採点基準は厳格です。期待されるすべてのプライベートデータが、マスクされた出力から完全に消えていなければ、その質問は得点になりません。部分点はなく、「ほぼ正解」も認められません。これは、別の LLM を判定役とするベンチマーク（LLM の判定は寛大になりがちです）よりも厳しい基準です。他システムとの直接的な比較数値については、後述の直接対決セクションを参照してください。
PrivacyBenchHIPAA — 40のヘルスケアに関する質問
各質問には、秘匿化すべき保護対象保健情報（PHI：氏名、診療録番号など）と、保持すべきシグナル（日付、地理情報、90歳未満の年齢 — HIPAA Limited Data Set ルールに基づく）がリストされています。採点者は両方向をチェックします。削除すべきものを削除したか、そして残すべきものをそのまま残したかです。
| モード | PHI 秘匿化 | 保持情報の維持 |
|---|---|---|
| Limited Data Set (日付/地理/89歳以下の年齢を保持) | 79 / 79 (100 %) | 34 / 34 |
| Safe Harbor (日付を含むすべてを秘匿化) | 99 / 104 (95.2 %) | — |
Limited Data Set サブモードはこのベンチマークにおいて完璧でした。秘匿化対象が多く、見落としの機会が増える Safe Harbor は 95.2% をカバーしました。
独自データによるカテゴリ別結果（各モード200サンプル）
公開ベンチマークはすべてをひとまとめにします。当社の内部テストデータは、結果をカテゴリ（氏名、メールアドレス、住所など）ごとに分類し、それぞれを regex のみ、ML のみ、および両方の組み合わせの3通りで実行します。これにより、どの技術がどの種類の識別子を捉えているのか、そしてどこで互いを補完する必要があるのかが正確にわかります。最新の実行結果（2026-05-20）：
3つのフィルターモード全体のサマリー
| モード | 統合再現率 | 適合率 | F2 | サンプル数 |
|---|---|---|---|---|
| Personal Data フィルター | 97.3 % | 97.8 % | 97.4 | 200 |
| HIPAA フィルター — Limited Data Set | 92.3 % | 92.3 % | 92.3 | 200 |
| HIPAA フィルター — Safe Harbor | 91.9 % | 91.5 % | 91.8 | 200 |
これらの数値には URL は含まれていません。URL は意図的にそのままにしています。URL を破壊すると、「このリンクを開く」や「そのページを取得する」といったダウンストリームのアクションが機能しなくなるためです。これについては、後述のワークフローセクションで詳しく説明します。
カテゴリ別テーブルの前の全体像：すべてのモードにおいて、実際に個人を特定する識別子は、ほぼ100% の確率で捕捉されています。氏名、メールアドレス、電話番号、郵便住所、政府発行 ID、バイオメトリック ID、正確な位置情報、診療録番号、生年月日、社会保障番号などは、すべてのサンプルとテストで捕捉されました。100% を下回るカテゴリは予測可能です。デバイス ID（実際のテキストでは形式が非常に多様）、その他の組織 ID（ロイヤリティ番号、従業員 ID — 同様の問題）、および写真（テキスト専用フィルターは画像の中身を見ることができません）です。これらはいずれも、漏洩において真に重要となる「カルテ上の名前」や「下書き中のメールアドレス」のような識別子ではありません。リスクの高いカテゴリは信頼性が高いことが証明されています。
Personal Data フィルター
統合再現率（高い順）、次にリスク層（T1 = 最も機密性が高い）でソートされています。
| カテゴリ | 層 | Regex 再現率 | ML 再現率 (生) | 統合再現率 | 正解数 n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| email_address | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| government_id | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| person_name | T1 | 13.3 % (4/30) | 96.7 % (29/30) | 100.0 % | 30 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| postal_address | T1 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| precise_geolocation | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| birth_date | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| online_handle | T2 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 50.0 % (5/10) | 100.0 % (10/10) | 100.0 % | 10 |
| authentication_secret | T4 | 40.0 % (4/10) | 100.0 % (10/10) | 100.0 % | 10 |
| financial_account | T1 | 90.0 % (18/20) | 100.0 % (20/20) | 90.0 % | 20 |
| institutional_id | T3 | 80.0 % (8/10) | 90.0 % (9/10) | 90.0 % | 10 |
| device_id | T3 | 40.0 % (4/10) | 50.0 % (5/10) | 80.0 % | 10 |
全体を見ると、2層設計が功を奏していることがわかります。郵便住所、生年月日、氏名は regex 単体では 0–13% のスコアです。これらは一致させるべき特定の形状がないため、ML モデルのみが捕捉できます。メールアドレス、電話番号、IP、政府発行 ID、バイオメトリック ID、正確な位置情報は regex 単体で 100% を記録しており、ML モデルが苦労せずとも表面的な形式で捉えられます。オンラインハンドル、車両 ID、認証シークレットは混合型です。regex が標準的な形式を捉え、ML がそれ以外を補完します。すべてのカテゴリにおいて、統合再現率は、単層のどちらか強い方の数値を維持または上回っています。
デバイス ID とその他の組織 ID は 100% を下回るカテゴリですが、その理由は明確です。これらは実際のテキストにおいて最も多様な形式を持つためです。フィルターがどこでも完璧であるかのように装うよりも、再現率が低下するカテゴリについて正直であることを選択します。
HIPAA フィルター — Limited Data Set サブモード
Limited Data Set サブモードは、設計上、日付、地理情報、および 89 歳以下の年齢を保持します。これらは、HIPAA が正当な臨床研究および業務のために組織が保持することを許可しているシグナルです。
| カテゴリ | 層 | Regex 再現率 | ML 再現率 (生) | 統合再現率 | 正解数 n |
|---|---|---|---|---|---|
| biometric_id | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| email_address | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| medical_record_number | T1 | 100.0 % (26/26) | 100.0 % (26/26) | 100.0 % | 26 |
| person_name | T1 | 15.4 % (4/26) | 100.0 % (26/26) | 100.0 % | 26 |
| phone_or_fax | T1 | 100.0 % (13/13) | 100.0 % (13/13) | 100.0 % | 13 |
| social_security_number | T1 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| account_number | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| health_plan_id | T2 | 0.0 % (0/13) | 100.0 % (13/13) | 100.0 % | 13 |
| ip_address | T2 | 100.0 % (12/12) | 100.0 % (12/12) | 100.0 % | 12 |
| license_number | T2 | 0.0 % (0/12) | 100.0 % (12/12) | 100.0 % | 12 |
| vehicle_id | T2 | 25.0 % (3/12) | 100.0 % (12/12) | 100.0 % | 12 |
| device_id | T3 | 41.7 % (5/12) | 100.0 % (12/12) | 100.0 % | 12 |
| photo | T2 | 0.0 % (0/12) | 0.0 % (0/12) | 0.0 % | 12 |
写真は既知の欠落項目です。テキスト専用フィルターは画像の中身を見ることができません。画像内の PHI は、まだリリースしていない別の課題です。このモードにおける他のすべてのカテゴリは 100% です。
HIPAA フィルター — Safe Harbor サブモード
Safe Harbor は、Limited Data Set サブモードが保持していたもの（日付、89 歳を超える年齢、地理情報）をすべて削除します。最も厳格なカバレッジを実現するために、HIPAA 特化型モデルと一般的な個人データ用モデルの2つのフィルターモデルを並行して実行します。
| カテゴリ | 層 | Regex 再現率 | ML 再現率 (生) | 統合再現率 | 正解数 n |
|---|---|---|---|---|---|
| age_over_89 | T1 | 100.0 % (18/18) | 0.0 % (0/18) | 100.0 % | 18 |
| biometric_id | T1 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| email_address | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| medical_record_number | T1 | 100.0 % (20/20) | 100.0 % (20/20) | 100.0 % | 20 |
| person_name | T1 | 20.0 % (4/20) | 100.0 % (20/20) | 100.0 % | 20 |
| phone_or_fax | T1 | 100.0 % (10/10) | 100.0 % (10/10) | 100.0 % | 10 |
| social_security_number | T1 | 90.0 % (9/10) | 100.0 % (10/10) | 100.0 % | 10 |
| account_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| general_date | T2 | 100.0 % (27/27) | 29.6 % (8/27) | 100.0 % | 27 |
| health_plan_id | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| ip_address | T2 | 100.0 % (9/9) | 100.0 % (9/9) | 100.0 % | 9 |
| license_number | T2 | 0.0 % (0/10) | 100.0 % (10/10) | 100.0 % | 10 |
| vehicle_id | T2 | 10.0 % (1/10) | 100.0 % (10/10) | 100.0 % | 10 |
| device_id | T3 | 22.2 % (2/9) | 88.9 % (8/9) | 77.8 % | 9 |
| photo | T2 | 0.0 % (0/9) | 0.0 % (0/9) | 0.0 % | 9 |
興味深い2つの行は、一般的な日付（regex 100%、ML 30%）と 89 歳を超える年齢（regex 100%、ML 0%）です。Safe Harbor では、これら両方を意図的に regex に処理させています。日付には regex が常に捉えられる形状があり、また「>89」のような数値の閾値を確率モデルに推測させたくないためです。決定論的なルールは、ML モデルに同じルールを学習させるよりも信頼性が高くなります。
全カテゴリにわたる総合数値
すべてを合計すると、フルパイプライン（regex + ML の統合）は、いずれかの単層のみと比較してどうでしょうか？
| モード | レイヤー | 再現率 | 適合率 | F2 |
|---|---|---|---|---|
| Personal Data | regex のみ | 65.8 % | 93.0 % | 69.9 % |
| Personal Data | ML のみ | 95.4 % | 92.4 % | 94.8 % |
| Personal Data | 両方 (フル) | 96.9 % | 98.0 % | 97.1 % |
| Limited Data Set | regex のみ | 55.9 % | 95.0 % | 60.9 % |
| Limited Data Set | ML のみ | 92.9 % | 84.5 % | 91.0 % |
| Limited Data Set | 両方 (フル) | 92.9 % | 89.3 % | 92.1 % |
| Safe Harbor | regex のみ | 58.9 % | 93.6 % | 63.6 % |
| Safe Harbor | ML のみ | 82.4 % | 88.3 % | 83.5 % |
| Safe Harbor | 両方 (フル) | 92.4 % | 88.9 % | 91.7 % |
Personal Data フィルターの「フル」行は、すべての指標で単層バージョンを上回っています。表面的な形式のための regex と、文脈のための ML モデルを組み合わせることで、どちらか一方では不可能な成果を真に提供しています。この記事の冒頭にある 97.3% という見出しの数値は、実際のユーザーが得られる結果を反映したものです。上の表の数値がそれより少し低いのは、リンクやツール呼び出しを壊さないために意図的に保持している URL カテゴリが含まれているためです。
他の専用プライバシーフィルターとの直接対決
当社のフィルターのようなオンデバイスでほぼ瞬時に動作するプライバシーフィルターの公正な比較対象は、1メッセージあたり数秒かかりネットワークの往復が必要な巨大なクラウドホスト型 LLM ではなく、他のオンデバイスでほぼ瞬時に動作するプライバシーフィルターです。このクラスのすべてのシステムを、同じマッチングルールを使用して同じテストセットで実行しました。全員に同じ基準を適用しています。
比較対象クラス：
- openai/privacy-filter — OpenAI のオープンソース専用プライバシーフィルター。約5,000万パラメータで、最新のブラウザならどこでも動作するほど小型です。
- piiranha-v1 — iiiorg による 2億7,800万パラメータの検出器。ライセンスにより研究および評価のみに制限されています（測定は可能ですが、商用出荷はできません）。
- Microsoft Presidio — 最も広く導入されているオープンソースの秘匿化ツールで、伝統的なパターンマッチングと文脈把握のための小型言語モデルを組み合わせています。
- GLiNER PII ファミリー — 小型で汎用的なエンティティ分類器のファミリー。Knowledgator は small (~44M)、base (~86M)、large (~304M) のバリアントを出荷しており、NVIDIA は 2025年10月に 570M バリアントをリリースしました。
- Caiioo（Personal Data、HIPAA Limited Data Set、HIPAA Safe Harbor の全3モード）。
5つのテストセットすべてにおける再現率（Caiioo を先頭にソート）：
| システム | PrivacyBench PD-25 | Caiioo 合成 PD-200 | PrivacyBenchHIPAA-40 | Caiioo 合成 PHI-200 | 多言語 PD-40 (10地域) |
|---|---|---|---|---|---|
| Caiioo — Personal Data | 96.2 % (76/79) | 99.0 % (198/200) | — | — | 92.6 % (200/216) |
| Caiioo — HIPAA Limited Data Set | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| Caiioo — HIPAA Safe Harbor | — | — | 100.0 % (79/79) | 100.0 % (200/200) | — |
| openai/privacy-filter (50M) | 96.2 % (76/79) | 83.0 % (166/200) | 93.7 % (74/79) | 77.0 % (154/200) | 94.9 % (205/216) |
| gliner_pii_nvidia (570M) | 94.9 % (75/79) | 85.5 % (171/200) | 84.8 % (67/79) | 85.0 % (170/200) | 76.9 % (166/216) |
| gliner_pii_large (~304M) | 72.2 % (57/79) | 86.5 % (173/200) | 84.8 % (67/79) | 93.0 % (186/200) | 50.0 % (108/216) |
| gliner_pii_base (~86M) | 87.3 % (69/79) | 66.0 % (132/200) | 74.7 % (59/79) | 66.0 % (132/200) | 51.4 % (111/216) |
| gliner_pii_small (~44M) | 88.6 % (70/79) | 84.5 % (169/200) | 91.1 % (72/79) | 83.0 % (166/200) | 68.5 % (148/216) |
| Microsoft Presidio | 82.3 % (65/79) | 76.5 % (153/200) | 84.8 % (67/79) | 76.5 % (153/200) | 69.0 % (149/216) |
| piiranha-v1 (~278M) | 60.8 % (48/79) | 58.5 % (117/200) | 43.0 % (34/79) | 47.0 % (94/200) | 82.4 % (178/216) |
Caiioo は、2つの最大のテスト（PD-200 および PHI-200）で専用フィルタークラスをリードし、公開ベンチマークでも同等またはトップであり、多言語では2位でした。最小のテスト（PrivacyBench PD-25、わずか25問）では、Caiioo と openai/privacy-filter が 96.2% で並びました。多言語では、openai/privacy-filter が 94.9% で依然としてリードしており、Caiioo は 92.6% です。当社が最も遅れをとっている言語は中国語です。それ以外ではトップまたはそれに近い位置にいます。多言語対応がミッションクリティカルである場合、openai/privacy-filter は合理的な選択肢です。それ以外のほとんどのワークロードにおいては、Caiioo が最適です。
HIPAA の結果が最大の見出しです。Caiioo の両方の HIPAA モードは、すべての HIPAA テストで 100% の再現率を達成しました。すべての患者名、診療録番号、生年月日、口座番号が捕捉されました。2番目に優れたシステムは openai/privacy-filter の 93.7%（PrivacyBenchHIPAA）であり、6.3ポイントの差があります。このベンチマークにおいて、1つの見落としは現実世界での情報漏洩を意味します。
もう一つ注目すべき数値は、過剰な秘匿化（実際にはプライベートデータではないものをマスクすること）です。過剰な秘匿化はプライバシーの侵害ではありませんが、ユーザビリティの低下を招きます。あまりに多くのものをマスクしすぎると、LLM の推論能力が低下し、返される回答の質が下がります。Caiioo がテストセット全体で不必要にマスクしたのは 1–24 回でした。Presidio は 10–51 回。NVIDIA の GLiNER は HIPAA テストだけで 31–64 回でした。露出を最小限に抑えつつ、可能な限り最高の回答を得るという目標において、適合率は再現率と同じくらい重要です。
フロンティア LLM をフィルターとして使うのはどうでしょうか？
それも可能です。生の再現率においては、彼らが勝利します。クラウドまたはローカルで動作する巨大な汎用 LLM（Llama 3.1 8B、Gemma 4、Qwen 3.5 9B など）は、多言語を含むすべてのテストで 95–100% を記録できます。これは、最大限の再現率を必要とし、そのためのコストを支払う用意があるユーザーにとっては現実的な選択肢です。
しかし、重大な欠点があります：
- 遅い。 1メッセージあたりミリ秒単位ではなく、数秒かかります。フィルターはユーザーが送信するすべてのメッセージの前に位置します。
- メッセージがユーザーの端末を離れるか、モデルが端末に来るかのどちらか。 クラウドでフィルタリングするには、メッセージをクラウドに送る必要があり、本末転倒です。オンデバイスでフィルタリングするには、1–17 GB のモデルをダウンロードする必要があります。
- 騙される可能性がある。 生成モデルは、メッセージの途中で秘匿化を行わないように説得される（「プロンプトインジェクション」攻撃）可能性があります。当社のような小型の分類器では不可能です。
- 同じ入力に対して異なる出力。 生成モデルは常に同じ回答を2回出すとは限りません。これは往復の整合性を壊します。送信時にマスクし、戻ってきた時にマスク解除するには、同じ実数値が常に同じ偽の値にマッピングされる必要があります。
Caiioo は、このトレードオフの反対側のために構築されています。ユーザーが送信ボタンを押す前にコンポーザー内で動作する、予測可能で 1秒未満の極小フィルターです。会話内で同じ実数値に対して常に同じ偽の値を生成するため、往復の整合性が保たれます。上記の同クラス比較表は、そのようなユースケースにおける適切な比較を示しています。
論より証拠
ベンチマークは出発点に過ぎず、ゴールではありません。このフィルターは、Caiiooの新機能であるpseudonymizer（仮名化エンジン）に組み込まれています。これは、コンポーザーとモデルの間に実際に介在するコンポーネントです。
ユーザーが送信ボタンを押した際に実行されるプロセスは以下の通りです。
- 検出（Detect）。 まず正規表現（regex）レイヤーが実行されます。これは決定論的であり、マイクロ秒単位の高速処理を実現します。次に、残りのテキストに対してMLモデルが実行されます。2つのレイヤーが同じテキスト箇所で重複した場合は、シンプルなルールを適用します。表面的な形式については正規表現を優先し、文脈についてはMLを優先します。
- 自己と他者のタグ付け（Tag self vs. other）。 Caiiooは、「ユーザー自身」を指す識別子と「他者」を指す識別子を分離します。ユーザーは、片方のみを秘匿するか、あるいは両方を秘匿するかを選択できます。ユーザーが個人辞書に追加した名前は、常に「自己」としてカウントされます。
- 置換（Substitute）。 各実数値は、スタイルが一致した固定の仮名に置き換えられます。例えば「Sarah Goldberg」は「Maya Hartwell」となり、会話全体を通じて「Maya Hartwell」のまま維持されます。これにより、その人物に関するモデルの推論がターンをまたいで断片化することはありません。実数値と偽数値の対応表はユーザーのデバイス上に保持され、プラットフォームのキーチェーンからのキーを使用して暗号化されます。
- 送信（Send）。 モデルは完全に偽装されたメッセージを受信します。実体のある識別子がネットワークを通過することはなく、当社の監査ログにはカウントのみが記録され、値自体が記録されることは決してありません。
- 復元（Restore）。 ストリーミングレスポンスは、到着と同時に元の値にマッピングし直されます。モデルの返答内の「Maya Hartwell」は、画面に表示される前に「Sarah Goldberg」に戻され、小さなグローピル（光るカプセル状のUI）と共にレンダリングされるため、ユーザーは何が保護されたかを一目で確認できます。
- ツール引数の復元。 モデルがツール（メール送信、チケット作成、ドキュメントへの書き込みなど）を呼び出し、その引数に偽数値が含まれている場合、ツールが実行される「前」に実数値に置き換えます。モデルは偽数値に基づいて推論を行い、アクションは実数値を用いて実行されます。
このフィルターは、どのAIサービスが使用されているかを問いません。メッセージがモデルに到達する前に実行されるため、OpenRouter、Anthropic、Google、OpenAI、そしてローカルのOllamaのすべてが、同じようにマスクされたペイロードを受け取ります。新しいプロバイダーを追加しても、プライバシーの穴が再び開くことはありません。
誰を保護するか
ユーザー。 ユーザーの名前、メールアドレス、住所、電話番号、IP、生体識別子など、集約されると個人を特定できてしまう情報は、フィルターがオンのときはデバイスから離れることはありません。
ユーザーが話題にする人々。 ほとんどのプライバシーツールは入力している本人に焦点を当てますが、見落とされているのは「社会的契約」、つまり私たち全員が自分自身だけでなく他者に対しても責任を負っているという事実です。「サンダース氏の無能な行為を分析してください」という内容をLLMに送信し、それがシステムログに無期限に記録される可能性がある状態は無責任です（そして名誉毀損の可能性もあります）。1,000件のビジネス連絡先が含まれるGoogleスプレッドシートについてLLMに助けを求めることは、それらすべてをデータ保持の罠に投げ込むことになります。Caiiooのフィルターは第三者もカバーします。契約書の作成対象であるクライアント、記録を分析している患者、コンテキストに貼り付けられたメールの同僚などです。彼らは自分の識別子がリモートLLMに見られることに同意していません。フィルターはデフォルトでこれを尊重します。ワークフローで必要な場合は、ユーザーが「自分のみ」または「他人のみ」に切り替えることも可能です。
組織 — 企業、病院、事務所。 口座番号、免許番号、医療記録番号、財務ルーティングの詳細、内部ID、APIキー、顧客名簿。企業も個人と同様にデータ最小化の利益を持っています。Caiiooを使用して退院サマリーを作成する臨床医は、患者の医療記録番号をOpenAIに送ることはありません。弁護士はクライアントの口座番号をAnthropicに送ることはありません。サポートエンジニアは顧客のログからAPIキーをGoogleに送ることはありません。フィルターは識別子が個人に属するものか組織に属するものかを問いません。ただ、それをデバイス内に留めるだけです。
最大の有用性、最小の露出
重要なのは、ユーザーがフィルターの存在を感じないことです。
多くのプライバシーツールは、過激に伏せ字にしてモデルの回答を悪化させるか、プロンプトの使い勝手を優先してプライバシーの約束を形骸化させるかという選択を強いてきました。私たちはそのトレードオフを拒否しました。モデルには依然として完全に形成されたプロンプトが渡されます。文法的に正しい位置に、名前、場所、日付、医療記録番号が表示されます。ただ、それらは偽物に置き換わっています。推論は同一であり、文字列だけが洗浄されています。
それを可能にしているのが「安定した置換」です。会話内では、同じ実数値は常に同じ偽数値にマッピングされます。ユーザーのメッセージ、その名前に言及して返ってくるツールの結果、それに言及したモデルの以前の返答など、会話全体で一貫性が保たれるため、モデルは一貫した人物、場所、物事について推論できます。マルチターンの会話が混乱することはありません。ツール呼び出しが壊れることもありません。サブエージェントは親の会話のマップを継承し、タスク全体で一貫性を維持します。
ユーザーが見る出力は本物の会話です。プロバイダーが見るデータは一貫したフィクションです。処理はその2つの視点の隙間で行われ、その隙間を不可視にすることこそが、唯一の目標です。
邪魔になるプライバシーフィルターはオフにされてしまいます。ワークフローの中に消えてしまうプライバシーフィルターこそが、提供する価値のある唯一の形です。
それが、私たちが構築した基準です。