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という緩さ。
これ正直やばい。

サイズは1.5B（15億パラメータ）、
うち実際に動くのは50M（5,000万）。
ノートパソコンでも動く軽量設計です。

NEW: OpenAI releases Privacy Filter, their first open model of 2026! Apache-2.0! It's a bidirectional token-classification adaptation of GPT-OSS, trained to mask personally identifiable information (PII) in text. At only 1.5B params, it can even run locally in your browser!

出典: @xenovacom Xポスト

「2026年OpenAI初のオープンウェイトモデル」という位置づけ。
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精度の前処理」がローカルで無料で動く、
という点が一番デカいと思っています。
これまではトレードオフだったので。

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

まず数字から。
OpenAI公式のベンチマーク（PII-Masking-300k）でF1スコア96%、
修正版で97.43%。
これだけ見ると優秀です。

ただし、
この数字を「だから安全」と読み替えると事故ります。
OpenAI自身がモデルカードでこう注記しています。

Privacy Filter is not an anonymization tool, a compliance certification, or a substitute for policy review.

出典: Decrypt報道（OpenAI公式言及）

For high-sensitivity workflows—legal, medical, financial—human review and domain-specific evaluation and fine-tuning remain important.

出典: HelpNetSecurity掲載のOpenAI公式モデルカード帰属

つまり、
匿名化ツールでもないし、
コンプライアンス認証でもないし、
ポリシー審査の代わりでもない。
法務・医療・金融のような高機密業務では人間レビューと自社データでのファインチューニングが要る、
と公式が明記しています。
これ大事。

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

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

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

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

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

ここが業務利用で一番気になるところです。
日本語については、
複数の検証記事で誤検出が報告されています。

Qiitaに上がっている検証記事には、こんな実例が出ています。

「大阪」がprivate_addressとして、
「JR東海」がprivate_personとして検出される。
英語でも「Gemini」「Jira」がprivate_personとして検出された。
HTMLソースコードを入力するとsecretやprivate_phoneとして過剰反応する。
適合率はまずまずのように思います。
また再現率は評価できていません。

出典: Qiita @suzuki_sh 検証記事

地名の「大阪」やブランドの「JR東海」が個人扱いされる。
ChatGPTやGeminiの製品名も誤検出。
これは実務だと無視できないノイズです。

もう1つ。日本語の日付フォーマットも怪しい。

「山田太郎は1990年1月2日生まれです。
」でテストしたところ、
人名は検出されたが、
日本語日付フォーマット（1990年1月2日）は未検出（マスクされず）。

出典: note s-miyawaki 検証記事

誕生日が日本語表記だと素通りしてしまう。
これGitHub側にissue #11として日本語日付未対応が報告済みで、
リリース時点での既知の弱点です。

欧州の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件くらい流して検証→本番という導入フローが組みやすいんです。

逆に法務は注意が必要。
法律メディアの dataprivacyandsecurityinsider.com はこう書いています。

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単体でコンプライアンスを保証するのは無理筋です。

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 にデモを置いていて、
ブラウザだけで動作確認ができます。
さらに、
Montevive.ai が公開している第三者ブラウザ実装は登録不要・トラッキングなしで、
テキストを貼ってボタンを押すだけ。

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

  1. STEP1: ブラウザで privacyfilter.app を開く。第三者によるブラウザ実装（Montevive.ai系・MITライセンス）。登録もログインも要らない。Chrome または Edge の最新版推奨（WebGPUで動かすため）
  2. STEP2: ダミーテキストを貼って Detect を押す。最初は本物の業務テキストではなく、「山田太郎、東京都新宿区、090-1234-5678、yamada@example.com」のようなダミーから。誤検出傾向を掴むのが目的
  3. STEP3: 自社の業務サンプルを20〜30件分試す。CSなら問い合わせログ、人事なら応募書類の冒頭文。地名・会社名・日付の検出傾向を1件ずつ目視確認する
  4. STEP4: 誤検出パターンをメモに残す。「大阪が住所扱い」「JR東海が人名扱い」のような誤検出を、自社テキストでも別途確認。本番投入の前にここで判断する
  5. STEP5: 社内承認フローを確認。「個人情報含むファイルを別ツール（ブラウザ実装含む）に通すこと自体が制限」という社内ルールがある場合があるので、情シスに確認してから本番運用

引っかかりやすいポイント: privacyfilter.app はOpenAI公式ではなく第三者実装です。
OpenAI公式のデモは Hugging Face Spaces にあるので、
社内承認の文脈ではこちらを引いた方が無難。

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

ChatGPT/Claudeとどう繋ぐか

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

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

  1. STEP1: 業務テキストを準備。問い合わせログ・議事録・契約書ドラフトなど
  2. STEP2: privacyfilter.app または Hugging Face Spaces デモ にテキストを貼ってマスキング実行。氏名・メール・電話・住所がラベル化される
  3. STEP3: マスキング後のテキストをコピー。「[NAME]さんから[DATE]に届いたメール」のようにラベル化された状態
  4. STEP4: ChatGPT/Claudeに貼って依頼。「このログを要望カテゴリ別に分類して」「このメールの優先度を判定して」など
  5. STEP5: AIの返答を受け取る。AI側は実名を知らないが、傾向分析・要約・優先度判定の品質は維持される

引っかかりやすいポイント: マスキング後のテキストは「[NAME]さんが[ADDRESS]について問い合わせ」のような状態になります。
AIへの指示文は「ラベル化された個人情報部分は無視して傾向だけ分析して」と添えると、
AI側がラベルを意味のある単語として誤読するのを防げます。

あと1つ。
Hacker News のコメント欄で出ていた指摘ですが、
マスキング後のデータは「文脈が薄い」状態になるので、
用途によっては実用性が落ちます。

Redacted PII data is practically useless for most intents and purposes.

出典: Hacker News コメント（_pdp_）

これ全部の業務に当てはまるわけじゃないですが、
「個人を識別した上で個別対応する」タイプのCS業務には合いません。
マッチするのは「集計・傾向分析・カテゴリ分類」のような匿名のままで成立する業務です。

競合ツールとの位置づけ

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

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

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

Privacy Filterの差別化点は「ローカル動作＋文脈AI判断＋128k長文対応＋無料」の組み合わせ。
これまではローカル無料ツールはルールベース止まりで、
文脈判断はクラウド送信が必要だった。
そのトレードオフを崩した初のオープンウェイトモデル、
というのが業界の評価です。

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

出典: innFactory

個人的には、
構造化データ（フォーム入力・CSVの決まった列）はPresidio、
自由記述の散文（議事録・問い合わせ本文）はPrivacy Filter、
という分業も実務的だと思います。
実際にHacker News上でも併用パターンが言及されていました。

料金とライセンスの話

モデル本体は無料、
Apache 2.0。
商用利用OK、
改変OK、
再配布OK。
ファインチューニングして自社モデル化することも認められています。
これは業務投入のハードルとしては最低クラス。

動作環境はGPU版でVRAM約3GB（GeForce RTX 3060クラス以上）、
CPU版でRAM 4〜8GB。
ノートPCで普通に動くサイズ感です。

2026年4月30日時点ではダウンロード82,887件、
いいね1,110件、
OpenAIアカウントのフォロワー34,800人。
Hugging Face上ではトレンド入りしている状態。

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

FAQ

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

使えますが、
自社のテキストサンプルで動作確認してからの本番投入が必要です。
Qiita・noteの検証記事で「大阪」「JR東海」の誤検出、
日本語日付（1990年1月2日形式）の未検出が報告されています。
GitHub上にもissue #11として日本語日付未対応が報告済み。
本番投入前に20〜30件のサンプルで挙動を確認する手順を必ず通してください。

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

なりません。
Privacy Filterは個人情報の検出・マスキング専用モデルで、
文章生成や要約はできない設計です。
実務的には「Privacy Filterで個人情報をマスク → ChatGPT/Claudeに渡して分析・要約・要望分類」の2段運用が想定されています。
innFactoryもこのフローを推奨アーキテクチャとして提示しています。

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

OpenAI公式が「匿名化ツールでもコンプライアンス認証でもポリシー審査の代わりでもない」と明記しています。
法務・医療・金融などの高機密業務では人間レビューと自社データでのファインチューニングが必要、
と公式モデルカードに書かれている通り。
Privacy Filterはあくまで補完的な前処理ツール、
社内コンプライアンスや法的要件の代替にはなりません。

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

まずブラウザで privacyfilter.app または Hugging Face Spaces デモ で挙動確認 → ダミーテキストと自社サンプルでの誤検出パターン把握 → 情シスに「OpenAIが公式リリースしたローカル動作のPII検出モデル」と説明して承認フロー確認、
の順がおすすめです。
「クラウドに送らずにローカルで前処理する」という構造が情シス側に伝わると、
これまで止まっていた業務AI活用の話が前に進みやすくなります。

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

構造化データ（フォーム入力・決まった列のCSV・IBANやメールアドレス等パターン固定）はMicrosoft Presidio、
自由記述の散文（議事録・問い合わせ本文・契約書ドラフト）はPrivacy Filter、
という併用パターンがHacker Newsで言及されています。
クラウド送信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活用全般
-, ,

← 戻る