日本語自由記述テキストにおける OpenAI Privacy Filter の個人情報検出性能評価

対象ソフトウェア: OpenAI Privacy Filter (opf) [1]　|　リポジトリ: gghatano/opf-text-masking-demo　|　最終更新: 2026-06-09

本稿は進行中の実証実験の中間報告である。測定が完了した段階の数値のみを記載し、未実施の実験は「未測定」と明記する。性能改善の主軸は 素モデル (B0) → 日本語追加学習 (B2) であり、学習を伴わない後処理 (B1) は「後処理だけでどこまで改善できるか」を測るアブレーションとして位置づける。現時点で B0 評価とアブレーション B1 が完了しており、追加学習 (B2)・他モデルとの本比較・業務適用シミュレーションは未実施である。

Abstract

個人情報を含む自由記述テキストの利活用には、個人識別情報 (Personally Identifiable Information; PII) の検出とマスキングが不可欠だが、人手による作業負担が大きい。本研究は、OpenAI が公開したオープンウェイトの PII 検出モデル OpenAI Privacy Filter (OPF) [1] が、日本語の医療・自治体・その他ドメインの自由記述に対してどの程度実用的な検出性能を持つかを定量評価する。実データは用いず、ドメインごとに作成した合成評価データ 300 文書（医療・自治体・その他 各 100、計 1,520 スパン）を正解として用い、評価用 (test) 225 文書・調整用 (dev) 75 文書に層化分割した。検出の正否は文字単位の IoU ≥ 0.5 によるスパン一致で判定し、見逃しと過剰検出のコストが非対称であることから、両者を統合した F 値は用いず再現率 (Recall) と適合率 (Precision) を個別に報告する。

主軸は素モデル (B0) の特性評価と日本語追加学習 (B2) による改善であり、学習を伴わない後処理 (B1) はアブレーションとして扱う。B0（素の OPF）では、直接識別子（人名・住所・電話・メール・各種 ID）に対する再現率 0.60・適合率 0.76 であり、電話番号・メール・ID といった構造化された識別子はほぼ完全に検出する一方、人名 (Recall 0.38) を取りこぼした。アブレーション B1（OPF 出力への規則ベース後処理）では、人名スパンの境界整形で直接識別子の適合率を 0.65→0.85（再現率 0.60→0.66）、日付の正規表現補完で準識別子である日付の再現率を 0.29→0.99 へ改善できた。一方、人名の再現率や、OPF が出力カテゴリを持たない準識別子（年齢・地域・職業・組織, 再現率 0）は後処理では改善できず、追加学習 (B2) を要する。本中間報告は、OPF が日本語の構造化 PII に有効である一方で人名再現率と一部の準識別子に課題が残ること、そのうち後処理だけで直せる範囲と学習を要する範囲を切り分けて実数で示す。

1. はじめに

1.1 背景

医療記録・自治体の相談記録・コールセンター応対履歴・アンケート自由記述などでは、構造化された項目だけでなく自由記述欄に個人情報が含まれる。これらを二次利用する際には匿名加工・仮名加工が必要となり、自由記述中の PII を人手で探して加工する作業が大きな負担となっている。

近年、OpenAI がオープンウェイトの PII 検出モデル OpenAI Privacy Filter (OPF) を公開した [1]。OPF は軽量でオンプレミス実行が可能であり、匿名加工業務の省力化への応用が期待される。しかし、日本語データ、とりわけ医療・自治体分野の表現に対する性能は十分に検証されていない。

1.2 研究課題

本研究は以下を問う。

1. 素の OPF は日本語自由記述に対して実用的な PII 検出性能を持つか。
2. どの種類の識別子で強く、どこに弱点があるか。
3. 規則ベースの後処理や日本語データでの追加学習によって性能をどこまで改善できるか。

1.3 貢献

• 日本語の医療・自治体・その他ドメインを対象とした、正解ラベル付き合成評価データ 300 文書を構築し、生成手続きを再現可能な形で公開した。
• 統一した一致基準（文字 IoU ≥ 0.5）と再現率・適合率により、素の OPF (B0) のラベル別・ドメイン別の強み弱みを定量化した。
• 学習を伴わない後処理アブレーション (B1) により、「後処理だけで直せる範囲」と「追加学習 (B2) を要する範囲」を切り分けて示した。

2. 評価設定

2.1 評価データ

実データは個人情報そのものであり、評価用の正解付与自体が秘匿対象の取り扱いを伴う。そこで本研究では合成データを既定とする。フォーマットを定めた文書テンプレートに対し固有名詞を規則ベースで差し込み、差し込み位置から正解スパンを機械的に決定する。これにより正解ラベルが生成時に厳密に定まり、個人情報リスクも生じない。合成データの現実性が結果の外的妥当性を左右する点は限界として 5 章に述べる。

評価データは医療・自治体・その他 各 100 文書の計 300 文書（総スパン 1,520）からなる（生成: scripts/00_prepare_data.py、固定シード 20260609）。各ドメインを dev 25 / test 75 に層化分割し、後処理規則の調整は dev のみで行い、最終評価は test 225 文書（総スパン 1,135） に対して 1 度だけ実施する。これは調整データへの過適合による楽観的評価を避けるためである。

文書と正解スパンの例（自治体ドメイン・市民相談記録）を示す。

相談者：清水健、61歳、職業は保健師。住所は宮城県仙台市青葉区北3条西15丁目。契約者番号 C-32991。

この正解は PERSON「清水健」・AGE「61歳」・OCCUPATION「保健師」・ADDRESS「宮城県仙台市青葉区北3条西15丁目」・ID「C-32991」であり、敬称や「相談者：」等の前置きはスパンに含めない。

実データとの乖離の主因となる表記の揺れを意図的に混在させている。test 225 文書における内訳は、日付 83 件のうち西暦「年月日」42・略記（R7.1.18 等）17・和暦（令和7年…）14・スラッシュ 10、人名 376 件のうち外国人氏名 10、本人名を伏字にし PERSON ラベルを持たない（過剰検出を試す）文書 23 である。とりわけ日付の半数近くが和暦・略記であり、これが B0 での日付取りこぼし（3.2 節）の主因となる。

2.2 ラベル体系

検出対象を 10 種類のラベルに整理する。本人を直接特定しうる直接識別子5 種と、単独では特定性が低いが組み合わせで特定につながる準識別子5 種に分ける。日付 (DATE) は、それ単独で個人を直接特定しないが他の属性と組み合わせて再特定に寄与するため、準識別子に分類する（2026-06-09 改訂 #39）。

正解付与の規則（敬称はスパンに含めない／完全住所は ADDRESS・地名単独は REGION／第三者の情報も対象／病院名は ORGANIZATION／1 スパン 1 ラベル）は docs/spec.txt に定める。

2.3 評価指標

検出された区間（スパン）が正解とどの程度重なれば正解とみなすかは、文字単位の IoU（Intersection over Union, スパンの重なり率） が 0.5 以上であることを基準とする。すなわち、予測スパンと正解スパンの文字集合について「重なりの長さ ÷ 和の長さ ≥ 0.5」のとき一致とみなす。境界が多少ずれても許容しつつ、無関係な過大検出は弾く中庸な基準である。

性能は以下で報告する。

• 再現率 (Recall) = 正しく検出できた PII 数 ÷ 正解 PII 数。見逃しの少なさを表す。
• 適合率 (Precision) = 正しく検出できた PII 数 ÷ 検出した総数。過剰検出の少なさを表す。

PII 検出では「見逃し（再現率の低下）」が「過剰検出（適合率の低下）」より高いリスクを持ち、両者のコストは非対称である。したがって両者を平均する F 値は用いず、再現率と適合率を個別に報告する。

検出は 2 つの観点で集計する。untyped（検出のみを問う／型を区別しない） はラベル種別を問わず位置だけを評価する観点、typed（ラベル一致まで要求する） は位置に加えてラベルの一致も要求する観点である。本稿では全体性能（3.1）は untyped、ラベル別性能（3.2）は typed で報告する。OPF は後述のとおり準識別子の多く（年齢・地域・職業・組織）に対応する出力カテゴリを持たないため、untyped は「全 10 ラベルを分母にした場合」と「直接識別子のみを分母にした場合」の両方を報告する。なお一致を見る粒度には、span（スパン（範囲）単位の一致を見る粒度） と token（文字単位の部分一致を見る粒度） がある。既定は span 一致（IoU≥0.5）だが、OpenAI Model Card との比較のために token（文字）レベルの集計も別途報告する（3.6 節）。

2.4 評価モデルと比較対象

評価対象モデルは OPF（CLI opf 0.1.0、upstream openai/privacy-filter コミット f7f00ca・2026-04-22 取得）である [1]。配布の既定チェックポイント（~/.opf/privacy_filter、トークナイザ o200k_base）を用い、本研究では一貫して CPU 上で推論した。OPF の素モデルが出力する既定のラベル空間は次の 8 カテゴリである（opf/_common/label_space.py）: private_person, private_address, private_phone, private_email, private_date, account_number, private_url, secret。このうち 6 つが本研究のラベルに対応する。内訳は直接識別子 5 種（PERSON / ADDRESS / PHONE / EMAIL / ID）と、準識別子のうち DATE（private_date）である。private_url・secret は対応するラベルを持たない。残る準識別子（年齢・地域・職業・組織）に対応するカテゴリは OPF の出力ラベル空間に存在せず、実測でもこれらの再現率は 0 であった（3.2 節）。すなわち準識別子は「OPF が検出できる DATE」と「OPF に出力カテゴリが無い 4 種」に分かれる。対応関係を表1に示す（対応付けの実装: scripts/labelmap.py）。なお OPF は LoRA 等の省メモリ学習に対応せず、追加学習はフルファインチューニングで行う [2]。

表1. OPF の既定ネイティブカテゴリと本研究の 10 ラベルの対応。

比較対象の評価は本研究の重要な構成要素である。単一モデルの絶対値だけでは見えない強み・弱みは、設計目的の異なるモデルとの同条件比較で初めて明確になる。比較対象として日本語固有表現抽出ライブラリ GiNZA（ja_ginza 5.2.0 / spaCy 3.8.14）を、OPF と同一の評価データ・一致基準・指標で比較した。ただし現時点では小規模な予備パイロット（合成 15 文書）として実装・評価した段階であり（実装: scripts/03_compare_models.py、結果は 3.5 節）、評価データ 300 文書での本比較は今後実施する。GiNZA は汎用の固有表現抽出器であり PII 検出専用の OPF とは設計目的が異なるため、両者の同条件比較は検出対象ごとの相補性（OPF は構造化 PII に、GiNZA は人名・準識別子に強い、等）を示す。さらに Presidio・GLiNER・日本語 NER モデルを同一基準で順次追加する。

2.5 評価段階（B0・B2）とアブレーション（B1）

ここで B はモデル構成の世代を表す記号であり、B0＝素モデル（baseline）、B1＝後処理アブレーション、B2＝追加学習を指す。アブレーションとは、構成要素を 1 つ外す/変えて、その寄与を切り分ける実験である。性能改善の主軸は B0 → B2 の 2 段階である。これに加え、学習を伴わない後処理をアブレーション B1 として測る。いずれも同一の評価データ・一致基準で測定する。

B0（素モデル）. 配布されている OPF をそのまま test に適用する。前処理・後処理・再学習は行わない。本研究の基準点である。

B1（後処理アブレーション）. モデルは再学習せず、OPF の出力に規則ベースの後処理のみを施す。「日本語の弱点のうち、追加学習を伴わない出力整形だけでどこまで回復できるか」を切り分けるためのアブレーションであり、同時に B2 が上回るべき学習不要のベースラインでもある。後処理は OPF 自身が出力するラベルの整形に限定し、評価データのテンプレートに固有の語彙には依存しない汎用的な日本語規則のみを用いる（実装: scripts/05_b1_postproc.py、規則は dev のみで調整）。具体的には次の 2 つである。

• 日付の正規表現補完: OPF の日付カテゴリが取りこぼす和暦（令和7年…）・略記（R7.1.18）・西暦・スラッシュ表記を正規表現で抽出し、既存の検出と重複しないものを日付スパンとして追加する。
• 人名スパンの境界整形: OPF は「退院サマリ：西村千尋」や「佐藤花子（72歳）は」のように前後の文脈を巻き込んだスパンを出力することがある。これに対し、先頭の「ラベル：」前置きの除去、空白区切りでの末尾要素の採用、末尾の括弧・年齢・敬称・助詞・句読点の除去を行い、人名本体のみを残す。

日付の補完は OPF の既存出力カテゴリ（private_date）の取りこぼしを補うものであり、新たなカテゴリを作り出すものではない。一方、年齢・地域等への正規表現追加は OPF が出力カテゴリを持たない識別子を新たに作り出す操作であり、「出力の整形」を越えてアンサンブルに相当する。本段階では行わず、これら準識別子（年齢・地域・職業・組織）への対応は B2 に委ねる。

B2（追加学習）. 日本語の合成学習データで OPF をフルファインチューニングし、10 ラベルを直接学習させる。評価データとは固有名詞プールを分離した学習用合成データ（train 675 + 検証 75 文書）と、10 ラベルのラベル空間定義（configs/labels_ja10.json、先頭に O）を用いる（実装: scripts/00_prepare_data.py --target train）。準識別子の検出と人名再現率の向上を狙う。本中間報告の時点では未実施である（4 章）。

3. 結果

成功基準（目標値）は、直接識別子の再現率 90% 以上・適合率 85% 以上、業務面では作業削減率 50% 以上・見逃し率 5% 以下とする（docs/spec.txt）。以下の数値はすべて test 225 文書・IoU ≥ 0.5 による実測である。

3.1 全体性能（直接識別子）

下表は直接識別子 5 種の untyped 検出（本研究の主対象）である。主軸は素モデル (B0) と追加学習 (B2) の比較で、B1 は学習不要の後処理アブレーション（B2 が上回るべきベースライン）として併記する。

素モデル (B0) は直接識別子で再現率 0.60・適合率 0.76 にとどまり、成功基準（0.90 / 0.85）には届かない。後処理アブレーション (B1) は人名スパンの境界整形により適合率を 0.84 へ引き上げるが、再現率の伸びは小さい（0.60→0.66）。これは後処理が OPF の非検出を補えないためで、再現率の本質的な改善は追加学習 (B2) に委ねられる（3.3 節）。

参考として、全 10 ラベルを分母とした untyped 検出では B0 が Recall 0.38 / Precision 0.82、B1 が Recall 0.46 / Precision 0.89 である。準識別子 5 種のうち 4 種（年齢・地域・職業・組織）を OPF が出力しないため、全ラベル基準では再現率が構造的に低く出る。

図1. 検出性能。本図は全 10 ラベル untyped（B0: Recall 0.38 / Precision 0.82、後処理アブレーション B1: 0.46 / 0.89, test 225 文書）を示す。B1 は学習不要の後処理アブレーション点であり、主目標の追加学習 (B2) は未測定。上表の直接識別子のみの値とは分母が異なる（OPF が検出しない準識別子 4 種〔年齢・地域・職業・組織〕を含むため再現率が低く出る）。点線は目標値（Recall 0.90 / Precision 0.85）。

3.2 ラベル別の性能（B0 と後処理アブレーション B1）

ラベル別の数値は typed（位置＋ラベル一致）である。各ラベルの区分と正解数（test）を併記する。B1 列は後処理アブレーションの結果である。

Precision の「—」は検出件数が 0 で適合率が定義されない（0 除算）ことを表し、値 0 とは異なる。電話番号・メール・ID といった構造化された識別子は素モデルでほぼ検出できる。一方、人名（直接識別子）の再現率が低い点と、和暦・略記を含む日付（準識別子だが OPF が検出可）の取りこぼしが B0 の主な弱点であった。

3.3 アブレーション: 後処理 (B1) で直せる範囲

学習を伴わない後処理アブレーション B1（手法は 2.5 節）は 2 つのラベルに効いた。日付（準識別子）の正規表現補完により、和暦・略記を含む日付の再現率が 0.29 から 0.99 へ向上した。人名（直接識別子）スパンの境界整形により、人名の適合率が 0.65 から 0.85 へ改善した。後者により直接識別子全体では再現率 0.60→0.66・適合率 0.76→0.84 となった（3.1 節）。日付の改善は準識別子側に現れるため、直接識別子の指標には寄与しない。

一方、人名の再現率は 0.49 にとどまった。これは OPF が 2 人目以降の人名をそもそも検出していないためであり、検出されていない箇所を後処理で生成することはできない。すなわち素モデルの日本語人名検出能力の上限を表す。準識別子（年齢・地域・職業・組織）も OPF が出力カテゴリを持たないため後処理では補えず（2.5 節）、再現率 0 のままである。これらの改善は追加学習 (B2) に委ねる。

3.4 ドメイン別の性能（B0, 予備）

直接識別子 5 種の untyped 検出（B0）をドメイン別に見ると、医療 Recall 0.62・その他 0.69・自治体 0.55 であり、自治体ドメインがやや低い。

3.5 他モデルとの予備比較

参考として、同一の一致基準で日本語固有表現抽出モデル GiNZA を評価した予備実験（合成 15 文書 / 57 スパンの小規模パイロット、実装: scripts/03_compare_models.py）では、OPF が電話・メール（再現率 1.0）・ID といった構造化 PII に強く、GiNZA が人名（このパイロットで Recall 0.94、OPF は 0.41）・年齢・地域・日付といった人名系・準識別子に強いという相補的な傾向が確認された。ただしこれは小規模かつ準識別子が多い構成であり、本評価データ 300 文書での本比較は未実施である。3.1〜3.4 の B0/B1 数値はいずれも 300 文書由来であり、本予備比較（15 文書）とは規模・構成が異なる点に注意されたい。

図2. OPF と GiNZA の untyped 検出（予備実験, 合成 15 文書 / 57 スパン, IoU ≥ 0.5）。準識別子を多く含む構成のため全体では GiNZA が優位に見えるが、ラベル別には上記の相補性が表れる。

3.6 OpenAI Model Card (Table 7) との比較

OPF の Model Card [4] は多言語合成データでの日本語性能を Recall 0.866 / Precision 0.897 / F1 0.881（n=968） と報告する。我々の既定の B0（全 10 ラベル・span IoU≥0.5）の Recall 0.38 とは大きく異なるが、その大半は測定条件の差であり性能差ではない。Model Card の評価条件に合わせて同じ B0 予測を再集計すると、差はほぼ埋まる（実装: scripts/06_openai_alignment.py）。

差を生む要因は次の 4 点である。

1. マッチング粒度: Model Card は主に token レベル（部分一致を加点, Table 1 は "tokens"）。我々の既定は span 一致（IoU≥0.5） で境界ずれを丸ごと不正解とする。token レベルに揃えると Recall は 0.57→0.82 に上がる（最大の要因）。
2. カテゴリ集合: Model Card はベンチマークのラベルを OPF の 8 カテゴリへ写像し、対応の無いカテゴリを分母から除外する [4]。我々の全 10 ラベルは OPF が出力できない準識別子（年齢・地域・職業・組織）を含むため Recall が構造的に低く出る。OPF が出力できる 6 カテゴリに限定して比較する。
3. データセット: Model Card Table 7 は PII-Masking-300k と同形式の合成多言語データ（単純な文・カテゴリ手がかり付き）。我々は医療・自治体の自然な日本語で、手がかりが薄く難しい。Model Card 自身の「手がかり無し」条件は Recall 0.584 と低く、我々の水準に近い。
4. データラベル補正: Model Card は推論モデルによる審査でデータ側の付け忘れを分母から除外し精度を底上げする [4]。我々の合成 gold は構築上厳密で補正を行わない。

要するに、評価粒度とカテゴリ集合を揃えれば素 OPF の日本語 Recall は 0.82（token, OPF6）で Model Card の 0.866 に近く、残差はデータセットの難易度・手がかりの有無・ラベル補正で説明できる。残る我々側の弱点は token レベルでも 人名（R0.57 / P0.48）と住所（P0.43）の境界過延長であり、これは B1 の境界整形と B2 の追加学習で改善を図る。

注: 我々の token レベルは OPF が用いる o200k_base サブワードではなく文字単位の近似であり、データセットも異なるため、本比較は「評価方法を揃えた参考」であってデータセットまで揃えた厳密比較ではない（PII-Masking-300k 日本語 split での直接評価は今後の課題）。

3.7 実用指標：匿名加工業務の観点（#46）

§3.6 で揃えた OpenAI 式の見出し数値（token・OPF6 限定）は 匿名加工業務での有効性とはギャップがある。同一の B0 予測（再推論なし）を業務寄りの 4 視点で再集計し、その距離を定量化した（実装: scripts/07_practical_metrics.py、test 225 文書、IoU≥0.5）。

(a) 文書レベル漏えい率（直接識別子）. 集約 Recall は「1 文書あたり何件漏れるか」を語らない。直接識別子を 1 件以上見逃した文書の割合を測ると、素 OPF (B0) は 78.2%（158/202 文書）、後処理 (B1) でも 71.8%（145/202） が漏えいを含む。文書あたり平均見逃し件数は B0 1.25 → B1 1.07 件。集約 Recall（DIRECT span 0.60→0.66）は改善を示すが、文書単位では大半の文書に取りこぼしが残ることが露わになる。

(b) IoU 閾値スイープ（token と span の乖離）. スイープとは、閾値を一定範囲で走査して指標の変化を見ることである。同じ予測で IoU を 0.1→1.0 に振ると、span Recall は単調に低下する一方、文字 token Recall は閾値に依存しない上限として残る（図 figures/iou_sweep.png）。直接識別子で token 0.855 に対し span(IoU≥0.5) 0.602、全 10 ラベルで token 0.703 に対し span 0.383。token 値は境界ずれを部分加点するため、実務有効性を 0.25 ポイント前後 過大評価しうる。

(c) 準識別子を分母に戻した被覆. 準識別子（年齢・地域・職業・組織, n_gold=417）を分母に含めると untyped Recall は 0.000（B0・B1 とも）。OPF は設計上これらの出力カテゴリを持たず、再識別リスクに関わる準識別子は素通しである。直接識別子のみの 0.60 という数字は、準識別子を分母から外したことに支えられている。

(d) 過剰マスキング（有用性コスト）. gold を越えてマスクした文字数（over-redaction）は B0 で 760/6,395 文字（11.9%）、B1 で 430/6,261 文字（6.9%）。token-precision が隠す境界の過延長が主因で、ラベル別では 住所（340 文字）と人名（B0 401→B1 71 文字）が大半を占める。B1 の人名境界整形は過剰マスキングを約 1/5 に圧縮するが、住所の過延長は素 OPF のまま残る。

まとめ. 「ベンチ token R0.82」と「業務で安心して使えるか」の間には、(a) 文書単位で約 7 割が取りこぼしを含む、(b) span で測ると Recall は 0.60、(c) 準識別子は 0 被覆、(d) 検出できても 1 割前後を過剰マスク、という説明すべき距離がある。これらは #14 の業務適用シミュレーションの KPI（作業削減率・見逃し率）に直結する。

主指標の位置づけ（#46）. 本稿の主指標は OpenAI Model Card 流の token（文字）レベル（§3.6）とし、外部ベンチ・公開数値との整合を担保する。一方、本節 (a)〜(d) の実務指標は、その token 値が匿名加工業務の有効性を過大評価しうるという課題提起であり考察として併記する（主指標は置き換えず、補助指標として継続測定する）。実務適用の合否は #14 の業務 KPI（作業削減率・見逃し率）で別途判断する。

3.8 カテゴリ手がかりアブレーション（日本語版・Model Card Table 5 の再現, #46）

§3.6 の差異要因③（カテゴリ手がかり）を日本語で切り分けるため、直接識別子 1 件のみを含む短文を 同一の値・同一シードで 3 条件（前置「電話番号：090-…」／後置「090-…（電話番号）」／無し「本日の記録は090-…」）に振り、素 OPF の untyped Recall を比較した（実装: scripts/08_clue_ablation.py、6 カテゴリ×17 文=各 102 文、IoU≥0.5）。

カテゴリ手がかり（特に前置）は Recall を押し上げ、Model Card Table 5 が示す「手がかり依存」を日本語でも定性的に再現した。ただし本実験での効果量（前置 +0.11）は Model Card の clue 有無差（0.584→0.863, +0.28）より小さい。これは(1) 短文・少数（n=17/カテゴリ）の標本誤差、(2) 後置の括弧が境界に干渉し精度を 1.00→0.85 に下げること、(3) 電話・メール・住所は手がかり無しでも高 Recall で天井効果が出ること、による。カテゴリ別では DATE が全条件で低い（前置 0.18／無し 0.29）——和暦・略記・短文の単独日付に対する素 OPF の弱さ（§3.2 の DATE R0.29 と整合）で、手がかりでは補えない。実データの自由記述は手がかりが薄いため、本結果は §3.6 の「自然文ギャップ」の一因が手がかり要因であることを支持する。

3.9 業務適用シミュレーション：検出性能から工数削減・見逃し率へ（#14, モデル #13）

検出性能（P/R）と工数削減は業務フローを介してのみ結びつく（循環論法の回避）。検出結果を仮想業務フロー「原文書 → AI 検出・加工 → {加工不要: 人が通読し見逃し確認／要加工: AI 候補を人が確認・修正} → 最終チェック」に流し込み、作業削減率と見逃し率（spec §9）を感度分析で試算した（実装: scripts/09_workflow_sim.py、台帳の直接識別子 B0/B1 集計値を入力、再推論なし）。1 文書あたりの工数を 人手単独 ≒ c_read + c_mark·G + c_final、支援併用 ≒ c_conf·(TP+FP) + ρ·c_read + c_fix·FN + c_final とし、作業削減率 = 1 − Σ支援併用/Σ人手単独を計算する。最大の仮定である通読削減係数 ρ（0=通読ゼロ … 1=AI 加工後に人が全通読）と、最終チェック捕捉率 q をスイープした。係数 c_*（秒）は仮の初期値で、校正（社内実測パイロット）は #13 の論点として未確定である。

入力（直接識別子・IoU≥0.5・test, §3.7 と同一）: B0 TP=382/FP=124/FN=253、B1 TP=419/FP=82/FN=216、G=635・文書数 202。

(a) 作業削減率は ρ に強く依存する. 削減率は通読をどれだけ AI で短縮できるか（ρ）にほぼ線形で支配される。

ρ=1（「AI が加工・分類した後、人が全部を通読して加工し直す」パターン）では削減率は負（−0.10 前後）——AI 候補確認の手間が純増となり逆効果。一方「人が一度は通読するが AI 支援で通読を短縮する」パターンでは、spec §9 の目標（削減率≥50%）達成には ρ≤0.15 程度の積極的な通読短縮が必要で、通読を半分にする（ρ=0.5）程度では削減率は 24〜26% に留まる。後処理 B1 は FP を減らす（124→82）ことで削減率をわずかに押し上げるが（break-even ρ を 0.14→0.16 に緩める）、支配項は ρ である。

(b) 見逃し率は最終チェックの捕捉率に依存する. 見逃し率を 2 定義で報告する（spec §9 目標 ≤5%）。

検出器単体の見逃し率は 0.34〜0.40 で目標（≤5%）に大きく未達。残存見逃し率 (1−R)(1−q) を 5% 以下にするには、最終チェックが検出漏れの 86〜88% を拾う必要がある——これ自体が強い前提であり、かつ §3.7(c) の通り準識別子は被覆ゼロなので、この残存見逃し率は直接識別子に限った楽観値である。

まとめ. 現状の検出性能（B0/B1）では、作業削減率は通読短縮 ρ に支配され、目標 50% は ρ≤0.15 という積極的な前提でのみ達成する。見逃し率 KPI（≤5%）は検出単体では満たせず、最終チェックの高い捕捉率に依存する。すなわち安全側の運用（高 q）ほど通読工数が残り削減率は下がるというトレードオフが定量的に現れる。B2（日本語追加学習）で Recall を上げれば、FN 減少を通じて両 KPI（削減率の底上げと残存見逃し率の低下）を同時に緩める方向に効く。係数 c_* の校正と ρ の妥当域は #13 の論点として残す。

4. 未実施の実験

本中間報告の時点で以下は未測定である。

• B2（日本語追加学習）: 学習用合成データ（train 675 + 検証 75 文書、評価データと固有名詞プールを分離しリーク防止）と 10 ラベルのラベル空間定義は準備済みだが、フルファインチューニングは未実施である。これにより準識別子の検出と人名再現率の向上を狙う。
• 他モデルとの本比較: GiNZA・Presidio・GLiNER 等を評価データ 300 文書で同一基準により比較する。
• 業務適用シミュレーションの係数校正: 工数モデル自体は §3.9 で実装・感度分析済みだが、係数 c_*（通読・確認・修正の単価）と通読削減係数 ρ の妥当域は仮置きであり、社内実測パイロットによる校正が未実施である（#13）。
• Model Card とのデータセット整合比較: PII-Masking-300k の日本語 test split で OPF を直接評価し、評価方法（§3.6）に加えてデータセットも揃えた apples-to-apples 比較を行う。

5. 考察と限界

強みと弱み. OPF は構造化された直接識別子（電話・メール・番号）に対し、追加の工夫なしに日本語でも高い性能を示す。一方、人名の再現率が低く、和暦・略記の日付を取りこぼす。日付は汎用的な正規表現後処理でほぼ解消できるが、人名の再現率向上と準識別子への対応は素モデル＋後処理の枠を越え、追加学習を要する。

合成データの外的妥当性. 本評価は合成データに基づくため、実データに対する性能を直接保証しない。テンプレートと固有名詞プールに由来する表現の偏りがあり、結果は「想定した分布における上限性能」と解釈すべきである。和暦・略記・外国人氏名・部分匿名といった表記の揺れは一部混在させているが、実データとの乖離は残る。専用の難例セットによる乖離の可視化は今後の課題である。

統計的信頼性. 本報告の数値は、固定シード（20260609）による単一の合成データ生成と単一の決定的推論に基づく点推定であり、信頼区間を付していない。ラベル別の正解数は ID 56・ADDRESS 59・PHONE 64 など小さく、再現率・適合率の標本誤差は無視できない。複数シードでの生成・複数試行・信頼区間や有意差検定による厳密化は今後の課題である（#19）。

評価設計上の妥当性. 一致基準・分母・調整/評価データの分離を統一し、調整は dev のみ・評価は test 1 回に限定することで、過適合による楽観的評価を避けた。後処理規則は評価データの語彙に依存しない汎用規則に限定し、自己循環的な性能水増しを避けた。

6. 結論と今後

素の OPF (B0) は日本語の構造化 PII（電話・メール・番号）に有効である一方、人名再現率と準識別子への対応に明確な課題を持ち、直接識別子は成功基準（再現率 0.90・適合率 0.85）に未到達である。学習不要の後処理アブレーション (B1) は、人名スパンの境界ずれ（適合率 0.65→0.85）と日付の取りこぼし（準識別子, 再現率 0.29→0.99）を低コストで補えることを示した。しかしこれは「整形で直る範囲」に限られ、人名再現率の本質的改善や、OPF が出力カテゴリを持たない準識別子（年齢・地域・職業・組織）への対応はできない。これらは性能改善の主軸である日本語追加学習 (B2) に委ねられ、B2 はこの学習不要ベースライン (B0+B1) を上回ってはじめて意義を持つ。業務適用シミュレーション (§3.9) は、現状の検出性能では作業削減率が通読短縮 ρ に支配され、見逃し率 KPI（≤5%）が最終チェックの捕捉率に依存することを定量的に示した——いずれも検出 Recall の向上（B2）が両 KPI を同時に緩める方向に効く。今後は B2 を実施し、他モデルとの本比較を加えるとともに、工数係数の校正を通じて削減率推定の確度を高める。

付録A 再現手順

推論を伴うコマンドは opf を含む仮想環境で実行する必要があるため、再現性のため全コマンドを uv run で統一する。

git clone https://github.com/gghatano/opf-text-masking-demo.git && cd opf-text-masking-demo
bash scripts/setup_env.sh
uv run python scripts/00_prepare_data.py                  # 合成評価データ 300 文書を生成（seed 20260609）
uv run python scripts/00_prepare_data.py --target train   # B2 用 学習データ 750 文書を生成（seed 20260610）
uv run python scripts/04_b0_baseline.py                   # B0: 素 OPF を test で評価
uv run python scripts/05_b1_postproc.py --split dev        # B1 後処理の調整（dev のみ）
uv run python scripts/05_b1_postproc.py --split test       # B1 後処理の最終評価（test, 1 回）
uv run python scripts/plot_progression.py                 # 図を再生成

数値は outputs/metrics_ledger.csv に追記方式で記録し、段階間の変化を追跡する。評価データ・学習データはともに上記スクリプトと固定シードから同一内容を再生成できる（リポジトリには含めない）。

付録B 手法詳細ページ

モデル個別の仕様・生データ・型対応・落とし穴・定性的所見は手法ページに分離する: OPF ／ GiNZA（以降、Presidio・GLiNER・日本語 NER を追加予定）。

References

• [1] OpenAI Privacy Filter. https://github.com/openai/privacy-filter （本評価は opf 0.1.0 / コミット f7f00ca・2026-04-22 取得）
• [2] OPF CLI・学習/評価の調査メモ: docs/findings-opf-cli.md
• [3] 実験計画・仕様: docs/verification-plan.md ／ docs/spec.txt
• [4] OpenAI Privacy Filter Model Card（評価条件・Table 7 多言語性能）. https://cdn.openai.com/pdf/c66281ed-b638-456a-8ce1-97e9f5264a90/OpenAI-Privacy-Filter-Model-Card.pdf （ローカル写し: docs/OpenAI-Privacy-Filter-Model-Card.pdf）