
OpenAI が OpenAI Privacy Filter を公開した。テキスト中の個人を特定できる情報(PII)を検出し、必要に応じて自動で伏せるためのオープンウェイトモデルだ。2026-04-22 付で OpenAI 公式から発表されている。
問題はここで、近年のエンタープライズ向け生成 AI 導入の最大の足かせは「社員が社外 LLM に個人情報や機密を流してしまう」リスクだった。プロキシ型の DLP 製品や、自前のトークナイザで置換する仕組みは各ベンダーが出してきたが、精度と言語対応でばらつきがあり、本番投入の判断を止めている組織も多い。そこに、検出・マスキングの部分だけを切り出した専用モデルを、OpenAI 自身がオープンウェイトで出してきた。
見落としがちだけど、今回の意義は 3 つに分けて整理しておきたい。
1. オープンウェイトであること。 OpenAI がオープンウェイトで出すモデル自体、ここ 1〜2 年で軸足が変わってきた。Privacy Filter のように「個人情報を扱う前処理」をクラウド呼び出しではなくローカルや自社環境で回せる形で提供したのは、コンプライアンス重視の組織にとって判断が変わるポイントになる。
2. PII 検出・マスキングに特化。 汎用 LLM に「個人情報を外して」とプロンプトを書く運用は、精度が読めない。タスクを狭めた専用モデルは、NIST や個人情報保護委員会のガイドラインに沿った監査体制を組むときに、根拠が揃えやすい。
3. SOTA(state-of-the-art)相当の精度を主張。 これは公式のベンチマーク発表の内訳と照らさないと鵜呑みにはできない。導入検討の際は、自社の日本語データや、業界固有のフォーマット(保険証番号・マイナンバー・医療カルテ表記など)での実測値を必ず取るべきだ。公式値だけで判断しないこと。
2024 年の改正個人情報保護法以降、日本国内でもクラウド LLM への個人データ提供について、「本人同意」「委託」「共同利用」の線引きを問われる場面が増えている。EU AI Act の施行準備も進んでおり、ハイリスク用途での説明責任は強まる方向だ。
Privacy Filter のような前段の検出モデルは、「LLM に送る前にマスクしました」というログが残せるかどうかで、事故時の説明コストが大きく変わる。ローカルで完結させられる前段処理の価値は、実は精度そのものよりも証跡設計のところにある、というのが規制の文脈で言うと筋の通った話だと思う。
1. マスキングの「穴」は必ずある。 PII の定義は地域と業界で揺れる。欧州の GDPR、米カリフォルニア州の CCPA、日本の個人情報保護法で「個人情報」の範囲が微妙に違う。汎用モデルは平均点であって、業界固有のデータパターンでは抜けが出る。
2. 誤マスキングも起きる。 逆に、個人情報ではない文字列(製品コード、取引番号、医学用語など)を過剰に伏せてしまうと、後段の LLM の推論精度が落ちる。監査ログには「何をマスクしたか」と「何を通したか」の両方を残す設計にしておきたい。
3. ローカル運用のリソース試算。 オープンウェイトとはいえ、推論で GPU が必要なサイズかどうか、CPU で回るのか、ここは導入前に必ず確認する。大量のログを前処理するパイプラインに挟む場合、スループットがボトルネックになりやすい。
Privacy Filter を入れることが目的化しないように。導入の順序はこう組むべきだと思う。
ツールが先、運用が後は事故のもと。今回のリリースで判断材料が一段増えたのは前向きに見ているが、「オープンウェイトで出たから即採用」という流れにはならない話だ。動向は追っておきたい。
OpenAI 公式 — Introducing OpenAI Privacy Filter