AI活用全般

個人情報があってAI活用が止まる人事・法務・CS・総務向け｜OpenAI Privacy Filterで個人情報をローカルで消してから渡す運用

「これ社外秘だけど、AIに聞いていいのかな」で毎回手が止まる業務が、ローカルで個人情報だけ消してからAIに渡す運用で通せるようになります。

OpenAIが2026年4月22日に出した「OpenAI Privacy Filter」が、その前処理を担うモデル。

Apache 2.0で無料、PCのGPUでもブラウザでも動きます。

ただし公式モデルカード自身が「非英語テキストでは精度が落ちる」と明記しています。

マスキング後はChatGPTやClaudeに渡す2段運用が現実的、と私は見ています。

この記事は個人情報を扱う非エンジニア業務担当者（人事・法務・CS・総務）でAI活用の壁が個人情報懸念で止まっている人向け（ChatGPTやClaudeに業務テキストを貼る場面を想像できれば読めます）。

そもそも「OpenAI Privacy Filter」って何のことか

ざっくり言うと、テキストの中から個人情報だけ拾って、自動で「[NAME]」「[EMAIL]」みたいなラベルに置き換えるAIモデルです。

OpenAIが2026年4月22日に公開、Hugging FaceとGitHubで配布中。

ライセンスはApache 2.0で、商用利用も改変も再配布もOKという緩さ。

これ正直やばい。

提供元はOpenAI公式です。

モデルカードに「Developed by: OpenAI」と明記され、配布元も公式の github.com/openai/privacy-filter と Hugging Faceの openai アカウント。

サードパーティ製ではありません。

サイズは総パラメータ1.5B（15億）、実際に動くアクティブパラメータは50M（5,000万）。

公式モデルカードも「Runs in a web browser or on a laptop」と書いていて、ノートパソコンやブラウザで動く軽量設計です。

中身はGPT-OSSと近い作りの土台を、テキスト分類用に組み替えたもの。

Apache 2.0ライセンスで、OpenAIのGitHub・Hugging Face公式orgから2026年4月22日に公開されたオープンウェイトモデルです。

ChatGPTで囲い込んでいるOpenAIが、手元で動くモデルを無料で出した。

私はこの一手を、業務側にも意味のある方向転換だと受け止めています。

なぜ非エンジニア業務向けに注目しているのか

クラウドAIに業務テキストを貼れずに止まっていた仕事が、前段に1ステップ足すだけで動くようになる。

これが大きい。

人事の応募書類、法務の契約書、CSの問い合わせログ、総務の議事録。

どれも個人情報の塊で、ChatGPTやClaudeに丸ごと貼ったら一発アウトの社内ルールが多い業種です。

その壁が「ローカルで個人情報を消してからクラウドに送る」という分業設計でほぐせます。

欧州のAIコンサル innFactory が示している推奨フローはこうです。

Original Data → Privacy Filter (on-premises) → Masked Data → Frontier LLM API

出典: innFactory AI Consulting

原データはローカルで個人情報を抜き、抜いた後のテキストだけをChatGPT/Claudeに渡す。

シンプルですが、これまではローカル側の精度がルールベース止まりで、文脈判断は無理でした。

Privacy Filterは文脈から「これは個人名」「これは会社名」を判別する設計で、そこが今までのオープンソースツール（Microsoft Presidio等）との差になっています。

個人的には、「クラウドAI寄りの精度の前処理」がローカルで無料で動く、という点が一番デカいと思っています。

これまではトレードオフだったので。

性能と限界はどう書かれているか

まず数字から。

公式が参照するベンチマーク（PII-Masking-300k）でF1スコア96%、修正版で97.43%。

これだけ見ると優秀です。

ただし、この数字を「だから安全」と読み替えると事故ります。

OpenAI自身が公式モデルカードでこう注記しています。

Privacy Filter is a redaction and data minimization aid, not an anonymization, compliance, or a safety guarantee.

出典: OpenAI Privacy Filter 公式モデルカード（Hugging Face）

Additional caution is warranted in high-sensitivity settings such as medical, legal, financial, human resources, education, and government workflows.

出典: OpenAI Privacy Filter 公式モデルカード（Hugging Face）

つまり、匿名化ツールでもないし、コンプライアンス認証でもないし、安全の保証でもない。

医療・法務・金融・人事のような高機密業務では追加の注意が要る、と公式が名指ししています。

人事・法務・CS・総務が読者のこの記事にとって、ここはど真ん中の注意点です。

さらに、Tonic.aiが実データで評価した結果はこんな感じ。

評価対象F1スコア（標準モデル）備考
公式参照ベンチマーク（PII-Masking-300k）96〜97.43%合成データ評価
法務文書・ASR転写などの実データ0.18〜0.65ドメインで大幅低下
EHR（電子カルテ）注記のリコール38%大半を見落とす
EHR注記（ファインチューニング後）F1=0.95自社データ追加学習で回復

出典: Tonic.ai ベンチマーク記事

合成データの96%と実データの18〜65%は別物。

「実務では自社データで追加学習しないと使い物にならない」というのが Tonic.ai の結論で、ここは正直シビアな話です。

日本語精度の正直なところ

ここが業務利用で一番気になるところです。

結論から言える事実として、公式モデルカード自身が日本語のような非英語テキストでの精度低下を認めています。

Performance may drop on non-English text, non-Latin scripts, protected-group naming patterns, or domains that are out of distribution compared to model training.

出典: OpenAI Privacy Filter 公式モデルカード（Hugging Face）

主に英語向けで、日本語のような非英語・非ラテン文字では性能が落ちうる、と公式が明記。

これが業務投入前の大前提です。

具体的に分かりやすいのが日本語の日付です。

公式GitHubにissue #11として「Japanese dates are not anonymized（日本語の日付が匿名化されない）」が報告されています。

Japanese-format dates (年月日) are not redacted in sentence context, while Western-format dates (1990-01-02) are correctly caught.
Input: 山田太郎は1990年1月2日生まれです。 → Actual: <PRIVATE_PERSON>は1990年1月2日生まれです。

出典: OpenAI Privacy Filter 公式GitHub issue #11

「1990年1月2日」のような日本語表記の誕生日が、人名は消えても日付だけ素通りする。

これはリリース時点の既知の弱点として公式リポジトリに残っています。

私の理解では、誕生日・生年月日を含むテキストを扱う人事・総務はここを一番警戒すべきです。

日付以外でも、公式が言う「非英語での精度低下」「学習時と違うドメインでの低下」は、日本語の地名や会社名の誤検出として現れうると私は見ています。

地名が住所扱いされたり、有名企業名が人名扱いされたりすると、実務では無視できないノイズになります。

欧州のAIコンサルも同じ温度感です。

For productive use in the German-speaking market, fine-tuning on German data is practically mandatory.

出典: innFactory

ドイツ語でも自国語データでのファインチューニングが「実質必須」と書かれている。

日本語も同じ位置づけと読むのが妥当です。

というわけで、業務投入する前には必ず自社のテキストサンプルで動作確認するのが先決。

「公式F1スコア96%」だけ見て本番投入すると、地名や会社名のノイズ、日本語日付の素通りで精度議論が止まります。

人事・法務・CS・総務でどう変わるか

業務シーン別に、これまでとこれからの差を整理します。

業務これまで止まっていたタスクローカル前処理を足した後
人事応募書類・面接メモ・人事評価コメントをAIに渡せない氏名・住所・電話・誕生日をマスクし、評価傾向分析や面接質問改善はAIに依頼
法務契約書・覚書・合意書のリスク洗い出しをAIにかけられない担当者名・口座番号をマスクし、文書チェックをAIに依頼。ただし高機密案件は人間レビュー必須
CS問い合わせログCSVをAIに分析依頼できない顧客名・連絡先をマスクし、要望カテゴリ・クレーム傾向の分析をAIに依頼
総務会議議事録・文字起こしをAIで要約できない参加者氏名を[NAME]に置換し、要約・タスク抽出をAIに依頼

特にCSは試しやすい。

問い合わせログのフォーマットが安定している企業が多いので、サンプル30件くらい流して検証→本番という導入フローが組みやすいんです。

逆に法務は注意が必要。

法律メディアの Data Privacy + Security Insider はこう書いています。

privacy risk is not limited to obvious identifiers, and even where direct personal data has been masked, context can still allow a person to be identified. A filtering tool such as Privacy Filter may reduce some risk, but it does not solve the broader concerns.

出典: Data Privacy + Security Insider

名前を消しても、文脈から個人が特定できるケースがある。

これGDPRや日本の特定個人情報保護法でも同じ論点で、マスキングしたから安全、ではない。

私の理解では、Privacy Filter単体でコンプライアンスを保証するのは無理筋です。

OpenAI公式自身が「コンプライアンス保証ではない」と書いている通りです。

Tonic.aiの研究者もここを強調しています。

The model is the easy part. The hard part is still the same as it's always been: getting the right data, labeled the right way, and iterating on it until it covers the long tail of ways PII shows up in real text.

出典: Tonic.ai

モデル選びは簡単。

難しいのは手元の業務テキストに合わせ込むところ。

これ私も同感で、Privacy Filterは「ベース部品」と見る位置づけが正しい気がします。

非エンジニアが最短で挙動を確認する手順

まず触らないことには、手元の業務テキストで使えるかが判断できません。

環境構築なしで試せる入口が用意されています。

OpenAI公式が Hugging Face Spaces にデモを置いていて、ブラウザだけで動作確認ができます。

さらに、第三者がブラウザ実装を公開していて、登録不要・テキストを貼ってボタンを押すだけで試せます。

非エンジニア向けに最短ルートを示します。

  1. STEP1: ブラウザでOpenAI公式デモを開く。Hugging Face Spaces の公式デモが一番無難。社内承認の文脈でも「OpenAI公式デモ」と言える。Chrome または Edge の最新版推奨（WebGPUで動かすため）。
    期待結果: テキスト入力欄とDetect系のボタンが表示される。詰まりどころ: WebGPU非対応の古いブラウザだと動作が重い、または動かない
  2. STEP2: ダミーテキストを貼って検出を実行。最初は本物の業務テキストではなく、「山田太郎、東京都新宿区、090-1234-5678、yamada@example.com」のようなダミーから。
    期待結果: 氏名・住所・電話・メールが[NAME]等のラベルに置き換わる。詰まりどころ: 誤検出傾向を掴むのが目的なので、ここで何が拾えて何が漏れるかをメモしておく
  3. STEP3: 自社の業務サンプルを20〜30件分試す。CSなら問い合わせログ、人事なら応募書類の冒頭文。
    期待結果: 地名・会社名・日付の検出傾向が見えてくる。詰まりどころ: 日本語日付（1990年1月2日形式）が素通りする既知の弱点があるので、誕生日を含むテキストは特に1件ずつ目視確認する
  4. STEP4: 誤検出パターンをメモに残す。地名が住所扱い、有名企業名が人名扱いといった誤検出を、自社テキストで洗い出す。
    期待結果: 「この種類の文では精度が足りない／足りる」の判断材料がそろう。詰まりどころ: ここを飛ばして本番投入すると、後から精度クレームで運用が止まる
  5. STEP5: 社内承認フローを確認。「個人情報含むファイルを別ツールに通すこと自体が制限」という社内ルールがある場合があるので、情シスに確認してから本番運用。
    期待結果: 承認が下りれば運用へ。詰まりどころ: 第三者実装のWebアプリは、たとえローカル処理でも社内規定で引っかかることがある

引っかかりやすいポイント: 第三者が公開しているブラウザ実装はOpenAI公式ではありません。

OpenAI公式のデモは Hugging Face Spaces にあるので、社内承認の文脈ではこちらを引いた方が無難です。

もう1つ。

ブラウザ実装は手元のPCで処理が完結するので、テキストはどこにも送信されない設計ですが、社内ルール上「未承認のWebアプリにテキストを貼ること自体が違反」になる組織もあります。

情シスへの確認は必須です。

ChatGPT/Claudeとどう繋ぐか

業務シナリオで一番使い勝手が出るのは「Privacy Filterで前処理 → ChatGPT/Claudeで分析」の2段運用です。

ふだんの作業フローはこんな感じになります。

  1. STEP1: 業務テキストを準備。問い合わせログ・議事録・契約書ドラフトなど。
    期待結果: 元データが手元にそろう。詰まりどころ: CSVなど列が決まった形式は、後段のラベル化がきれいに効きやすい
  2. STEP2: 公式デモまたはブラウザ実装にテキストを貼ってマスキング実行。氏名・メール・電話・住所がラベル化される。
    期待結果: 「[NAME]さんから[DATE]に届いたメール」のような状態になる。詰まりどころ: 日本語日付は素通りすることがあるので、結果を一度確認する
  3. STEP3: マスキング後のテキストをコピー。ラベル化された状態のまま、次に渡す。
    期待結果: 実名が消えたテキストが手元に残る。詰まりどころ: 漏れがないかをここで最終チェックする
  4. STEP4: ChatGPT/Claudeに貼って依頼。「このログを要望カテゴリ別に分類して」「このメールの優先度を判定して」など。
    期待結果: 分析結果が返る。詰まりどころ: ラベルを意味のある単語と誤読されないよう指示文を工夫する（下記）
  5. STEP5: AIの返答を受け取る。AI側は実名を知らないが、傾向分析・要約・優先度判定の品質は維持される。
    期待結果: 個人を特定せずに集計・要約が得られる。詰まりどころ: 個別の人を名指しで追う業務には向かない

引っかかりやすいポイント: マスキング後のテキストは「[NAME]さんが[ADDRESS]について問い合わせ」のような状態になります。

AIへの指示文は「ラベル化された個人情報部分は無視して傾向だけ分析して」と添えると、AI側がラベルを意味のある単語として誤読するのを防げます。

あと1つ。

マスキング後のデータは「文脈が薄い」状態になるので、用途によっては実用性が落ちます。

これ全部の業務に当てはまるわけじゃないですが、「個人を識別した上で個別対応する」タイプのCS業務には合いません。

私の見方では、マッチするのは「集計・傾向分析・カテゴリ分類」のような匿名のままで成立する業務です。

競合ツールとの位置づけ

同じ領域で動くツールはいくつかあります。

ツール動作料金特徴
OpenAI Privacy Filterローカル無料（Apache 2.0）文脈AI判断・長文対応・1.5Bでブラウザ動作可
Microsoft Presidioローカル無料正規表現+NER。パターン固定カテゴリは得意、文脈は苦手
Google DLP APIクラウド従量課金高精度マネージドサービス。クラウド送信が前提
AWS Comprehendクラウド従量課金マネージドサービス。クラウド送信が前提
Tonic Textualクラウド商用実データ評価でF1=0.92〜0.99（自社調べ）。ただし中立性に注意

出典: Tonic.ai ベンチマーク、innFactory 比較記事

Privacy Filterの差別化点は「ローカル動作＋文脈AI判断＋長文対応＋無料」の組み合わせ。

これまではローカル無料ツールはルールベース止まりで、文脈判断はクラウド送信が必要だった。

そのトレードオフを崩した初のオープンモデル、というのが業界の評価です。

the first context-aware model from a leading AI company to enter the open-source space

出典: innFactory

個人的には、構造化データ（フォーム入力・CSVの決まった列）はPresidio、自由記述の散文（議事録・問い合わせ本文）はPrivacy Filter、という分業も実務的だと思います。

両方ともローカル無料なので、併用のコストはほぼゼロです。

料金とライセンスの話

モデル本体は無料、Apache 2.0。

商用利用OK、改変OK、再配布OK。

ファインチューニングして自社モデル化することも認められています。

これは業務投入のハードルとしては最低クラス。

動作環境はGPU版でVRAM約3GB（GeForce RTX 3060クラス以上）、CPU版でRAM 4〜8GB。

ノートPCで普通に動くサイズ感です。

公開からの伸びも速くて、Hugging Faceのモデルページでは直近1か月のダウンロードが30万件超、いいねも1,000超。

トレンド入りしている状態です。

注意点として、Apache 2.0は将来変更される可能性ゼロではない（OpenAIが商用条件を変える前例はあります）ので、本番投入時はライセンスと配布元URLを社内記録に残しておくのが安全です。

FAQ

Q1. 日本語の業務テキストでも使えますか？

使えますが、自社のテキストサンプルで動作確認してからの本番投入が必要です。

公式モデルカード自身が「非英語テキストでは精度が落ちうる」と明記しています。

さらに公式GitHubのissue #11として、日本語日付（1990年1月2日形式）が素通りする弱点が報告済み。

本番投入前に20〜30件のサンプルで挙動を確認する手順を必ず通してください。

Q2. ChatGPTやClaudeの代わりになりますか？

なりません。

Privacy Filterは個人情報の検出・マスキング専用モデルで、文章生成や要約はできない設計です。

実務的には「Privacy Filterで個人情報をマスク → ChatGPT/Claudeに渡して分析・要約・要望分類」の2段運用が想定されています。

innFactoryもこのフローを推奨アーキテクチャとして提示しています。

Q3. これを通せばコンプライアンス的に安全ですか？

OpenAI公式モデルカードが「匿名化・コンプライアンス・安全の保証ではない（not an anonymization, compliance, or a safety guarantee）」と明記しています。

医療・法務・金融・人事などの高機密業務では追加の注意が必要、とも公式が名指ししている通り。

Privacy Filterはあくまで補完的な前処理ツールで、社内コンプライアンスや法的要件の代替にはなりません。

Q4. 非エンジニアが社内に提案するとき、どこから話を進めればいいですか？

まずブラウザでOpenAI公式の Hugging Face Spaces デモで挙動確認 → ダミーテキストと自社サンプルでの誤検出パターン把握 → 情シスに「OpenAIが公式リリースしたローカル動作のPII検出モデル」と説明して承認フロー確認、の順がおすすめです。

「クラウドに送らずにローカルで前処理する」という構造が情シス側に伝わると、これまで止まっていた業務AI活用の話が前に進みやすくなります。

Q5. 競合ツールとどう使い分けるのが現実的ですか？

構造化データ（フォーム入力・決まった列のCSV・IBANやメールアドレス等パターン固定）はMicrosoft Presidio、自由記述の散文（議事録・問い合わせ本文・契約書ドラフト）はPrivacy Filter、という併用が実務的です。

どちらもローカル無料なので併用しやすい。

クラウド送信OKな業務ならGoogle DLP API・AWS Comprehendも選択肢、ただし従量課金とクラウド送信のリスクがついて回ります。

このページに出てきた言葉

PII（Personally Identifiable Information）
氏名・住所・メール・電話番号など、組み合わせると個人を特定できる情報の総称。
マスキング
テキスト中の個人情報を「[NAME]」のようなラベルに置き換える処理。
Apache 2.0
商用利用・改変・再配布が無料で認められているオープンソースライセンス。
オープンモデル（オープンウェイト）
AIモデルの中身（重みデータ）を公開する配布形態。手元にダウンロードして動かせる。
F1スコア
検出の正確さを測る指標。精度と再現率の両方を加味した数値で、1.0が満点。
ファインチューニング
既存モデルに自社データを追加学習させて、手元の業務に合わせ込む調整。
WebGPU
ブラウザの中でGPUの力を使ってAI処理を高速化する仕組み。Chrome・Edge最新版で対応。
VRAM
GPUに搭載されているメモリ。AIモデルを動かす作業領域。
GDPR
EUの一般データ保護規則。個人情報の取扱いを厳しく規制している。
正規表現
「@が入って.が続く文字列はメールアドレス」のような決まったパターンで文字を引っかけるルール記法。
固有表現認識（NER）
テキスト中から人名・地名・組織名のような固有のものを機械的に拾う技術。
Hugging Face
AIモデルが集まる公開の置き場所サービス。エンジニア界隈の標準的な置き場所。
EHR
Electronic Health Record の略。電子カルテのこと。
情シス
情報システム部門。社内のIT・セキュリティを管轄する部署。

参考リンク

※この記事の内容は執筆時点のものです。AIは進化が速い分野のため、最新の仕様は公式サイトでご確認ください。

-AI活用全般
-, ,

← 戻る