OpenAI Privacy Filter の紹介

 (openai.com)
6 ポイント 投稿者 GN⁺ 2026-04-27 | 1件のコメント | WhatsAppで共有
  • 非構造テキストから 個人識別情報を検出してマスキング するオープンウェイトモデルで、ローカル実行によりフィルタリング前のデータをデバイス外に出さずに済む
  • 双方向トークン分類 と span decoding を組み合わせ、入力を一度にラベリングし、最大 128,000 トークンの文脈で PII span を高速に復元できるよう設計されている
  • 電話番号やメールアドレス形式に依存するルールベース方式と異なり、言語・文脈認識 に基づいて公開情報とマスキングが必要な情報をより適切に区別する
  • 公開データと合成データを併用して学習し、PII-Masking-300k で F1 96%、補正版では F1 97.43% を記録し、少量データでもドメイン適応性能が 54% から 96% に向上した
  • 匿名化ツールやコンプライアンス認証の代替ではなく、高感度領域 では人によるレビュー、ドメイン別評価、追加のファインチューニングが引き続き重要である

製品概要と配布形態

  • 個人識別情報の検出・マスキング に特化したオープンウェイトモデルで、テキストから PII を見つけてマスキングまたは削除できる
  • ローカル実行 をサポートしており、フィルタリング前のデータをデバイス外に出さずに済むため、サーバーへ送って非識別化する場合より露出リスクを減らせる
  • 長い入力を高速に処理するよう設計されており、1 回のパスでマスキング要否を判断できる
  • 開発者は自前の環境で実行し、自身のユースケースに合わせてファインチューニングすることで、学習・インデックス作成・ロギング・レビューのパイプラインにより強いプライバシー保護を組み込める
  • Hugging Face と GitHub で Apache 2.0 ライセンス のもと公開されており、実験・カスタマイズ・商用デプロイまで想定している

従来方式との違い

  • 従来の PII 検出ツールは、電話番号やメールアドレスのような形式に対する 決定的ルール に依存することが多い
  • こうした方式は狭い範囲ではうまく機能しても、より微妙な個人情報を見逃しやすく、文脈処理にも弱い
  • Privacy Filter は、より深い 言語・文脈認識 に基づき、非構造テキストからより広範な PII を検出できる
  • 公開情報として保持すべき情報と、個人に結び付くためマスキングまたは削除すべき情報を、より適切に区別できるよう設計されている
  • 従来水準を超えてプライバシー基準を引き上げることを目的に開発され、内部のプライバシー保護ワークフローでもファインチューニング版を使用している

モデル構造と検出範囲

  • 双方向トークン分類モデル に span decoding を組み合わせた構造を採用している
  • 自己回帰の事前学習チェックポイントから開始し、固定のプライバシーラベル体系上のトークン分類器へ適応させている
  • テキストをトークンごとに生成するのではなく、入力シーケンス全体を一度にラベリングした後、制約付き Viterbi 手順 で一貫した span を復元する
  • この構造により、すべてのトークンを単一の forward pass でラベリングする 高速・高効率 な特性を持つ
  • 周辺文脈を活用して PII span を判定でき、公開モデルは最大 128,000 トークン の文脈をサポートする
  • 運用環境に合わせて再現率と適合率のバランスポイントを調整できる
  • 公開モデルは全体で 1.5B パラメータ を持ち、アクティブパラメータは 50M である
  • 予測カテゴリは private_person, private_address, private_email, private_phone, private_url, private_date, account_number, secret の 8 種類である
  • account_number はクレジットカード番号や銀行口座番号を含むさまざまなアカウント番号のマスキングに使われ、secret はパスワードや API キーのような項目を扱う
  • ラベルは BIOES span タグ としてデコードされ、よりきれいで一貫したマスキング境界を作る

学習過程と評価結果

  • まず プライバシー taxonomy を作成し、モデルが検出すべき span の種類を定義した
    • 個人識別子、連絡先情報、住所、非公開の日付、信用・銀行情報を含む各種アカウント番号、API キーやパスワードのような secret を含む
    広告
  • 事前学習済み言語モデルの language modeling head を token-classification head に置き換えた後、教師あり分類目的で追加学習した
  • 公開データと合成データを混ぜて学習し、現実的なテキストと扱いの難しいプライバシーパターンを同時に捉えられるようにした
    • 公開データでラベルが不完全な部分は、モデル支援アノテーションとレビューでカバレッジを高めた
    • 合成例は、形式、文脈、プライバシー下位タイプ全般の多様性を増やすために使われた
  • 推論時には、トークン単位の予測を 制約付きシーケンスデコーディング によって一貫した span に変換する
  • 標準ベンチマークに加え、より難しい文脈依存ケースを狙った追加の合成評価・チャット形式評価も実施した
  • PII-Masking-300k で F1 96%、適合率 94.04%、再現率 98.04% を記録した
  • レビュー過程で確認されたデータセット注釈の問題を反映した補正版では、F1 97.43%、適合率 96.79%、再現率 98.08% を記録した
  • 少量データだけでもドメイン適応は迅速に進み、評価したドメイン適応ベンチマークで F1 は 54% から 96% に向上した
  • モデルカード には、コードベースの secret 検出や多言語・敵対的・文脈依存の例に対するストレステストも含まれている

制約と利用時の注意点

  • 匿名化ツール でもなく、コンプライアンス認証でもなく、高リスク環境におけるポリシーレビューの代替にもならない
  • プライバシー中心設計のシステム全体を構成する一要素として位置付けられる
  • 動作特性は、学習に用いたラベル taxonomy と判断境界の影響を受ける
  • 組織ごとに望ましい検出・マスキング方針が異なる可能性があり、ドメイン内評価や追加のファインチューニングが必要になる場合がある
  • 学習分布と異なる言語、文字体系、命名規則、ドメインでは性能が変わる可能性がある
  • まれな識別子や曖昧な個人参照を見逃すことがあり、特に短いシーケンスのように文脈が限られる場合は、過剰または不十分にマスキングすることがある
  • 法律・医療・金融のような 高感度領域 では、人によるレビュー、ドメイン別評価、ファインチューニングが引き続き重要である

公開の意図と今後の方向性

  • プライバシー保護は、研究、製品設計、評価、配備全般にわたる 継続的課題 として扱われている
  • 狭く定義された現実のタスクで frontier レベルの性能を発揮する 小型で効率的なモデル の重要性を反映している
  • プライバシー保護インフラは、より容易に監査し、実行し、適応させ、改善できるべきだという目標のもとで公開された
  • モデルが世界について学習しつつ、個人の私的情報 は学習しないよう支援するツールとして位置付けられる
  • 今回のプレビュー公開は、研究・プライバシーコミュニティからのフィードバックを受けて性能をさらに改善するための段階でもある

関連記事

1件のコメント

 
GN⁺ 2026-04-27
Hacker Newsのコメント
  • こういう機能は数年前にすでに実装を試したことがあり、その結果いくつか明確になったことがある
    PIIのサニタイズは、UXを維持するならクライアント側で元に戻す必要がある。たとえば名前が John なのに [NAME] にマスクされた状態でモデルが Hi [NAME] と返したら、ユーザーに見せる前に Hi John に復元しなければならない
    結局、ユーザーがやり取りする層に逆置換メカニズムが必要になる
    それに、マスクされた PII データはほとんどの用途ではほぼ役に立たない。モデルはある程度は実データがないと機能しないが、PII と見なされる項目があまりに多いため、単純なチャットならよくても、ユーザーが LLM と複雑にやり取りする必要がある場合は難易度が大きく上がる。まったく何もできなくなるか、hallucination が起きることもある
    そのためプラットフォームレベルではサポートされていても、こうした限界のせいで実際にはあまり使われていない
    現実的な方法は、セキュリティリスクの高い一部の PII だけを除去し、PII をできるだけ早く破棄する信頼できるモデルを使うことだと思う。そのためにはシステム設計もかなり変える必要がある
  • https://github.com/KevinXuxuxu/anon_proxy を作っている。LLM プロバイダーの前段に置く匿名化プロキシのようなツールだ
    モデルベースの検出と regex PII detection を併用し、API リクエストとレスポンスの両方向で置換と復元を処理する。検出モデルをローカルでホスティングすれば、PII がローカル環境の外に出ることはない
    法務、税務、移民関連のような機微な文書を扱う際に特に有用だった
    • この方式の良い点は、どんなモデルでもつなげられることだ
      ただし会話の全体的な文脈そのものは、依然としてモデルと運営者に見えてしまう
      なので私は、Moxie の Confer のように https://confer.to/ 全体を暗号化して、エンドユーザー以外は平文を見られないようにするアプローチのほうが好みだ
    • レスポンス側の復元処理をどうしているのか気になる
      文書を入力時にマスクしたなら、LLM の出力もマスクされた内容になるはずで、その後どうつなげるのかがよく分からない
  • 今回のリリースには技術的に興味深い部分がかなりある
    Privacy Filter は双方向の token-classification model に span decoding を組み合わせた形で、自己回帰型の事前学習チェックポイントから始めて、固定の privacy label taxonomy 上のトークン分類器に適応させたという
    テキストをトークンごとに生成する代わりに、入力シーケンス全体を一度にラベリングし、constrained Viterbi 手順で一貫した span を復号する
    公開されたモデルは合計 1.5B パラメータで、アクティブなパラメータは 50M とのこと
    また、事前学習済み言語モデルの LM head を token-classification head に置き換え、教師あり分類 objective で追加学習して作ったことも明かしている
    • だとすると、これを他の PII 検出手段に頼らず、非構造化テキスト内で機微情報の位置を見つけるのにも使えそうだ
      原文をフィルターに通して span を取得し、その span をもう一度原文にマッピングすれば、結局 PII の位置情報を一通り確保できることになる
  • OpenAI ほど賢くはないが、ブラウザ上で BERT ベースの NER によって一部の PII をマスクする https://tools.nicklothian.com/webner/index.html を作った
    自分が試した用途ではかなりうまく動いた
    OpenAI のモデルは十分小さく見えるので、自分のツールにもこれを組み込んでみようかと考えている
    • さっき文書で試してみたが、false positive が多くて実用はかなり難しそうに見える
      100行ほどの markdown 文書を入れたところ、matter は frontmatter の一部なのに組織と判定され、end は frontend の一部なのにやはり組織と判定され、MCP も組織に分類された
      Following the discussion in , blahblah のように文法的にも成り立たない結果が多かった
      まさに10年前の NLP に戻ったような感じで、その分野では spaCy が本当に良いプロジェクトだったと改めて思わされた
  • この種のモデルのほとんどはナイーブで初歩的だということは明確にしておくべきだ
    Hi, this is Bob. のような単独で中立的なメッセージ1つならたいてい十分だろうが、データが蓄積し始めると、身元漏えいリスクまで含めてすべて考慮した PII redaction ツールは、私はまだ見たことがない
    それなのに企業がこうしたものを使ってデータが匿名化されたと信じるようになると問題は大きい。それは匿名化ではない
    それでも、データをそのまま公開・共有するのではなく、moderation、human eval、model training のような中間処理段階で使うのであれば、こうしたフィルタリングはかなり有用になり得る
  • 例の大半が regex でも簡単に拾えそうなものなのは少し残念だが、オープンなローカルモデルとして出てきたのはうれしい
    • 私の顧客向けには、個人のメールアドレスや電話番号がウェブサイトに載らないよう正規表現で防いでいる
      それでも追加の安心のためにこうしたモデルを併用するのは悪くなさそうだ
      サーバーに GPU はないが、1回あたり 2k トークン以下なら CPU-only inference でも回せる軽量モデルであってほしい
  • リンクをクリックすると OpenAI サイトの機械翻訳版にリダイレクトされるのだが、意味が完全に壊れている
    redacted をポーランド語の redagować に訳していたが、それは匿名化ではなく、テキストを編集・推敲するという意味に近い
  • これが regex とモデルを組み合わせる Presidio と比べてどうなのか気になる: https://microsoft.github.io/presidio/
    • このモデルをPresidio に組み込んで使うこともできるのではないかと思う
  • https://peyeeye.ai が、このスレッドでみんなが言っている問題を文字どおり全部解決すると思う
    • 他人のデータを許可なくかき集めた会社が作るプライバシーツールとは、皮肉が強すぎる
  • 今回の公開は歓迎したい
    規制産業でなくても、こうしたモデルと実務を備えておく理由は多いし、理論上は EU AI Act の関係で一部は必要にもなる
    私は https://grepture.com に特化した NER モデルで redaction と rehydration を入れてあるので、これもパイプラインに追加するつもりだ
    任意でhot pathに置いて、LLM にリクエストが届く前後を実際に操作できるようにすれば、compliance やユーザーから直接入力を受けるシナリオでかなり有用だ