数字の並びを見つけたら消す、という素朴なやり方を試しました。検出率は68.5%ですが、1034件を誤って引っかけました。
請求金額も、在庫の数も、会議室の番号も消えます。見つけたもののうち本当に個人情報だったのは38.6%でした。
見つけ方を4通り変えて数えました。素朴なやり方は、個人情報でないものまで大量に引っかけます。
個人情報検出で見つけ方を変えると何が起きるのかを、実際に走らせて数えました。用意したのは業務でやり取りされる文2000件です。
内訳は個人情報を含むもの950件、含まないもの1050件です。含まないほうにも、金額や日付など数字の並びを混ぜてあります。
// 数字の並びを全部消す
(t) => /\d{3,}/.test(t) || /\d+-\d+/.test(t)
// 種類ごとの形で見る
(t) => (
/0\d{1,4}-\d{1,4}-\d{4}/.test(t) || // 電話
/[\w.+-]+@[\w-]+\.[\w.-]+/.test(t) || // メール
/普通\s*\d{7}/.test(t) || // 口座
/(都|道|府|県)\S*?(市|区|町|村)/.test(t) // 住所
)
見つけ方 見つけた 取りこぼし 誤検出 検出率 正しさ 数字の並びを全部消す 651件 299件 1034件 68.5% 38.6% 種類ごとの形で見る 787件 163件 0件 82.8% 100.0% 形+近くの語で見る 787件 163件 0件 82.8% 100.0% 名前の辞書も足す 950件 0件 0件 100.0% 100.0%
上の表を見てください。数字の並びで判定すると、誤検出が1034件です。含まない1050件のほとんどを引っかけています。
請求金額は 982873 円です。 在庫は 727 個です。 会議室は 8-6 を押さえました。 請求金額は 260607 円です。
請求金額も、在庫の数も、会議室の番号も消えます。業務に必要な情報がまとめて失われます。
見つけたもののうち本当に個人情報だったのは38.6%です。3件に2件は空振りしています。
電話番号なら0で始まる決まった区切り、メールなら記号の並び。種類ごとに形を決めると、誤検出は0件になりました。
実際の仕組みも複数の技を組み合わせています。Google Cloudの説明もパターンの一致、検査値の確認、機械学習、文脈の分析といったさまざまな技法を用いるとしています。
素朴なやり方は、業務の数字まで巻き添えにする。
Sensitive Data Protection uses various techniques including pattern matching, checksum validation, machine learning, and context analysis.原文Google Cloud ドキュメント「InfoType detectors」 この内容の有効期限2027-02-18
種類ごとに検出の仕組みを持ちます。まず何を守りたいかを決めないと、仕組みも決まりません。
個人情報検出は、文章のなかに個人情報が含まれていないかを機械で見つける仕組みです。
実際の仕組みは、種類ごとに別々の検出器を持ちます。Google Cloudの説明も情報の種類に対する検出器とは、その種類の一致の基準に合致する検出の仕組みであるとしています。
つまり先に種類を決める必要があります。電話番号を守りたいのか、口座番号なのか、氏名なのかで、作るものが変わります。
形だけでは決まらない場合、周りの語を見る方法があります。同じ説明は肯定的な文脈とは、パターンの近くにある特定の文字や語や句が、一致の可能性を高めることを指すとしています。
前の節では、この文脈の語を足しても結果は変わりませんでした。どちらも82.8%で誤検出0件です。
理由は、形の指定がすでに十分に絞れていたためです。効く場面と効かない場面があります。形が緩いときほど、文脈が効きます。
実際の仕組みは、見つけたかどうかを白黒では返しません。検出結果は、確からしさと呼ばれる確度の点数とともに報告されるとされています。
点数があると、どこから消すかを後で決められます。全部消すのか、確からしいものだけ消すのかを、用途ごとに変えられます。
使った文は式で作った人工のものです。実際の業務文書はもっと崩れており、電話番号の書き方も統一されていません。ここで見せているのは、見つけ方の粗さが誤検出にどう効くかという関係です。見つけたあとの隠し方はPIIマスキングの記事で扱っています。
An infoType detector is the corresponding detection mechanism that matches on an infoType's matching criteria.原文Google Cloud ドキュメント「InfoType detectors」 この内容の有効期限2027-02-18
決まった形を持つ種類は見つけやすく、持たない種類は見つかりません。氏名がその代表です。
個人情報検出の難しさは種類によって大きく違います。種類ごとに分けて数えました。
種類 件数 数字の並びを全部 種類ごとの形で見 形+近くの語で見 名前の辞書も足す 電話番号 277件 100% 100% 100% 100% 携帯番号 288件 100% 100% 100% 100% メール 323件 0% 100% 100% 100% 口座番号 292件 100% 100% 100% 100% 住所 325件 100% 100% 100% 100% 氏名 295件 0% 0% 0% 100%
上の表を見てください。氏名だけが辞書を足すまで0%です。他の種類は形を決めれば100%見つかります。
電話番号には0で始まる区切りがあり、メールには記号があります。氏名にはそうした目印がありません。
文字だけを見ても、地名や商品名と区別できません。辞書を持つか、前後の語で判断することになります。
この計測では氏名の辞書と、さん・様という敬称を組み合わせました。それで100%になりましたが、辞書にない名前は見つかりません。
業務によっては、社員番号や顧客番号も守る対象になります。既製の検出器には入っていません。
こうした場合、自分で作ることになります。Google Cloudも独自の情報種別の検出器とは、自分で作成する検出器のことであるとしています。
3番目が要点です。検出率だけを見ていると、素朴なやり方が良く見えます。前の節でも68.5%という数字自体は悪くありませんでした。
形があるものから作り、形がないものは辞書で足す。
Custom infoType detectors are detectors that you create yourself.原文Google Cloud ドキュメント「InfoType detectors」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る