問い合わせ票とチャット履歴を送る前、伏せるべき項目

サポートがお客のメッセージを問い合わせ票へ貼る。運用が申込表を Chatwork や Slack に投げる。開発がスタックトレースをスレッドに落とす。この三つは、毎日同じ形で起きる。前回はリンクを転送するとき、消してよいパラメータを書いた。utm_source と fbclid は消してよい。id= は残す。そこで止まる人が多い。本文の 090-1234-5678、12桁の個人番号、カード番号、メールは、アドレスが短くなっても消えない。

問いは「伏せるかどうか」ではない。先に二種類の文字列を分けることだ。人へ直接届く、または口座を動かせる値は伏せる。注文番号、問い合わせ番号、商品 SKU は仕事を指すlocatorであり、人を指すものではない。ここを一律に星印へ替えると、次の担当が同じ一件を開けなくなる。下の対照表、例外、その場で確認できる手順は、この判断だけに絞る。MyPassGen の UTM削除ページも、テキストのマスキングでは同じ境界で動く。本稿はツールの案内ではない。問い合わせやチャットを送る前、どれを伏せ、どれを残すか、伏せたあとどう確かめるかに答える。

URL掃除では本文は消えない

個人情報保護法第2条第1項は、個人情報を、生存する個人に関する情報であって、氏名、生年月日その他の記述等により特定の個人を識別できるもの、または個人識別符号が含まれるものと書く。問い合わせ票やグループチャットの電話番号、個人番号、メールは、まさに「識別できる側」に落ちる。その原文を次のチャネル、次の表、次の「オンラインツール」へ渡せば、識別する力も一緒に渡す。

同条第3項の要配慮個人情報は、人種、信条、社会的身分、病歴、犯罪の経歴、犯罪により害を被った事実など、取扱いに特に配慮を要する情報を指す。カード番号そのものはここに列挙されないことが多い。それでも金融口座と氏名を同じ一文に重ねれば、漏れたときの害は単独の下4桁より大きい。公開チケットに未成年の連絡先を残すのも、「必要な範囲だけ送る」からは外れる。

条文は、星印をどこに打つかまでは決めない。決めるのは現場の初期値だ。送る文面は、次の人が完全な番号を見なくても仕事を続けられる形を既定にする。マスクか問い合わせ番号で足りるなら、それで送る。指定した一人へ今使える鍵を渡す必要があるなら、問い合わせ本文には書かない。一度限りの経路へ移す。

伏せなければならない項目

下の表は、問い合わせ、申込表、デモ資料、貼り付けログで実際に漏れる項目で分けた。法令の網羅リストではない。ベンダーは新しい接頭辞を作る。それでも、転送前に一度は見るべき一群はカバーできる。伏せたあと、読み手は「これは電話 / 番号 / メールだ」と分かるべきで、その値をそのまま使えてはいけない。

電話番号：まだ発信できるなら、終わっていない

ITU-T E.164 は、国際公衆電気通信番号を最大15桁とする。プラス + は記法であり、桁に数えない。日本の携帯電話は日常、11桁で 070 / 080 / 090 から始まり、090-1234-5678 のように 3-4-4 で書くことが多い。固定は 03、フリーダイヤルは 0120、IP電話は 050。問い合わせでよく見る 090-****-5678 は、「電話である」ことは伝え、その場で発信はさせない。

スペース、括弧、+81、全角数字は、先に半角の数字列へ直してから判定する。つながった11桁だけを電話と決めない。逆も同じで、8桁から15桁の数字は注文番号であることがある。+ も区切りもなく、携帯の形でもない連番を、全部電話にしてはいけない。注文番号を伏せて次の担当が請求と突き合わせられない方が、現場ではよく起きる。

マイナンバーと身分番号：真ん中が本人を指す

デジタル庁の説明どおり、マイナンバー（個人番号）は住民票を持つ人に付く12桁で、社会保障、税、災害対策など、法令または条例で定められた手続でのみ使う。12桁目は検査用数字であり、先頭11桁から省令の算式で決まる。12桁に見えるから個人番号だ、とは言えない。検査が通らない列は、注文番号かコピーミスのことが多い。

番号法の利用範囲を外れて、問い合わせ本文へマイナンバーを書くこと自体が、すでに広い。伏せる以前に、書かない。どうしても突合が必要なら、下4桁だけ残すか、社内システム上の問い合わせ番号で済ます。米社会保障番号のよくある形 ***-**-1234、英国の国民保険番号で先頭2文字と末尾1文字を残すやり方も、原則は同じだ。「これは番号だ」という形は残し、「誰の番号か」を示す中間は取る。

越境チケットに、18桁で末尾が X の住民身分番号が混ざることもある。真ん中8桁は生年月日だ。末尾4桁だけ伏せて生年月日を残すと、年齢と地域の手がかりまで転送することになる。ここでも同じ規則を使う。形は残し、中間は取る。

カード：表示の上限は、目指す値ではない

支払カードの主口座番号（PAN）の検査数字は、Luhn アルゴリズムで計算する。ISO/IEC 7812-1 附属書 B に書かれている。Luhn が捉えるのは入力ミスであり、「今使えるカードだ」という証明ではない。長さはおおむね13から19桁。PCI DSS が示す表示の上限は、先頭6桁と末尾4桁まで。BIN を見る正当な業務がなければ、上限まで使わない。

外へ出す問い合わせに BIN が要ることは、ほとんどない。下4桁で「末尾 4242 のカードか」は足りる。完全な番号と名義を同じ Chatwork の一文に書くのは、金融口座と身元を重ねることになり、下4桁だけより危ない。Luhn を通る長い数字だけをカードとして扱う。通らない列は、業務番号として残す。物流の追跡番号まで「念のため」伏せない。

メール、鍵、アドレス

メールの識別力の大半は @ の前にある。先頭1文字を残し、残りを伏せ、ドメインを残す。社用か個人かの見当は付き、宛先としては使えない。 local@domain をそのまま転送すれば、スレッドを開く全員へ連絡経路を渡す。

APIキーには系統の接頭辞が付きやすい。sk- / sk_live_、AKIA / ASIA、AIza、ghp_ / github_pat_、glpat-、npm_、xoxb-、および Bearer の後ろのトークン。接頭辞は系統を示すためであり、呼び出しを続けるためではない。伏せた文字列でまだ API が通るなら、伏せ方が足りないか、使える鍵を問い合わせに書いてはいけなかったかのどちらかだ。完全な鍵はワンタイムへ。鍵は URL の # の後ろに置く。閲覧ページに登録は要らない。

IPv4 は先頭2オクテットを残す（文書用の試験網 203.0.113.0/24 を 203.0.*.* と書く）と、回線や事業所の塊は分かり、ホストまでは届かない。貼り付けログに出る社内アドレス、VPN 出口、自宅回線のグローバルも、後ろ2オクテットを同じ規則で伏せる。

触ってはいけない数字列

クエリと同じ分裂が、本文にもある。乱数に見える数字でも、次の人が同じ一件を開くためのものがある。そこを伏せると、引き継ぎが切れる。

• 注文と配送：店舗の注文番号、運送会社の追跡番号、返品・交換の受付番号。桁数は電話やカードと重なりやすいが、電話の形も Luhn も持たない。
• 問い合わせとオブジェクト ID：チケットキー、社内の利用者番号、商品 SKU、データベースの連番。メモを転送する理由が、相手にその行を開いてもらうことである場合が多い。
• ビルドと時刻：ビルド番号、コミットハッシュの短い先頭、日時。ここを伏せると、再現手順が途切れる。

メモアプリでその場にできる試験がある。送る文面をコピーし、種類を一つずつ処理する。先に電話、次に番号、次にカード。一種類終わるごとに読み返す。業務番号は残っているか。文は通るか。長い数字を一度に全部星印へ替え、どこが壊れたかを後から推測しない。

旅券に似た「英字1〜2字＋数字6〜9桁」は、航空券の予約番号や車両番号と混同しやすい。検査が通らない、または前後が便名と座席なら、残して手で黄線を引く。正規表現ひとつに任さない。

マスキングは匿名加工ではない

法第2条第5項の仮名加工情報は、他の情報と照合しない限り特定の個人を識別できないよう加工した情報だ。同条第6項の匿名加工情報は、特定の個人を識別できず、かつ元の個人情報を復元できないよう加工したものだ。個人情報保護委員会のガイドラインは、この二つを分けて書く。問い合わせの 090-****-5678 に氏名、住所、注文番号が並べば、社内の問い合わせシステムと照合して本人へ戻せる。これは仮名の側であり、匿名加工ではない。公開してよい免罪符でもない。

目標は正確に書く。次の転送、次のスクリーンショット、次のチャネルでのその場での可用性を減らすことだ。処理後の表を公開ページへ載せる許可にはならない。必要最小限の代わりにもならない。氏名、住所、顔、子どもの情報、今使える鍵は、規則が見ない場所に残りやすい。表の別列、画像の画素、スペースで割った数字。

氏名、電話、個人番号、自宅住所を一文に重ねると、マスク済みの電話ひとつより感度が上がる。分けられるなら、四つを同じ Chatwork の一行に書かない。相手が自分でシステムを開ける問い合わせ番号だけで足りるなら、顧客ファイルを外へコピーしない。

その場で確かめる：並びの文面、星印、Network

スローガンは照合できない。文字はできる。次の手順はブランドの約束に依存しない。メモアプリと開発者ツールで足りる。

1. 送る原文を、手元のエディタへすべて貼る。手を入れる前のコピーを残す。記憶だけで伏せない。
2. 上の対照表に沿い、先に電話だけ処理する。次に個人番号、カード、メール。一種類ずつ。業務番号はまだ動かさない。
3. 原文と結果を左右に置く。処理した項目には星印か同等のマスクがある。注文番号、SKU、日付は読める。
4. 結果のなかで、原文の完全な電話、12桁の個人番号、@ より前のローカル部を検索する。まだ見つかるなら、終わっていない。
5. ブラウザ内でヒット種別を一覧するツールを使うなら、一覧の種別と結果の星印を突き合わせる。一覧にあって、対応する位置が伏せてあるなら、その種類は終わる。一覧にあるのに完全な値が残るなら、終わっていない。
6. 開発者ツールの Network を開き、「ログを保持」を入れてから、もう一度マスキングする。文書と API のリクエストに、今貼った原文は出てはいけない。解析送信も、個人番号やメール全文を運んではいけない。

MyPassGen のUTM削除は、この境界で動く。テキストのマスキングでは、電話、個人番号、カード、メール、APIキー、IP を一度に一種類選び、原文と結果を並べる。北米の番号は下4桁、E.164 は国番号の手がかりを残す。18桁の住民身分番号は ISO 7064 を確認してからマスクする。カードは Luhn のあと下4桁だけ残す（「先頭6＋末尾4」より狭い）。メールはローカル部の先頭1文字を残す。処理は今のタブで終わる。原文はアップロードせず、分析ログにも書かない。登録は要らない。ページ自身が、補助だと書く。重要な場面は、人がもう一度見る。

日本の携帯を 090-1234-5678 とハイフン付きで書くと、区切りのある電話として拾いやすい。ハイフンなしの11桁や、12桁のマイナンバーは、注文番号との見分けが難しい。現行の「個人番号」判定は、18桁の住民身分番号、米英の番号形式、英字混じりの旅券型を主に見る。マイナンバー専用の検査数字確認はしていない。12桁は結果を検索し、残っていれば手で伏せる。全角数字、画像の中の番号、規則がまだ知らない鍵の接頭辞も、同じ目視の対象だ。

画面、表、「伏せたつもり」

表は段落より難しい。電話が A 列、氏名が B 列、身分証のスキャンが3ページ目の画像。テキスト規則は画素を見ない。資料を送る前に、裁っていない身分証写真、番号が残った画面録画、Excel の非表示列や二つ目のシートに残る原文を見る。

チャットの「返信」は、前のメッセージを再掲する。最新行は伏せても、引用の一层は完全な番号のままだ。Slack のスレッド、LINE WORKS の引用、メールの転送も同じことをする。送る前に引用を展開するか、引用なしの新しいメッセージにする。スレッド全体を転送すれば、初期の未マスクの署名と本文も一緒に送る。

短縮URLと二次元コードは、本文を直さない。前回、短縮URLはジャンプ層だと書いた。ここへ一文足す。「ユーザー 090-1234-5678 の注文」をページタイトルや utm_content に書く人がいる。追跡名を消したあとでも、タイトルと本文は残る。リンク掃除とテキストのマスキングは、別の工程だ。片方でもう片方を代替しない。

よくある勘違い

「下4桁を隠せば電話は足りる。」国内携帯で先頭7桁を残し、下4桁だけ隠すと、名簿と組み合わせる余地が残る。先頭と下4桁は現場の折衷であり、数学的な証明ではない。マイナンバーで下4桁だけ残し、残りを公開チャネルへ載せるのも、同じ未完了だ。

「HTTPS があるからプライバシーは守られる。」HTTPS が止めるのは、経路上の盗聴者だ。受信者、チャネルの全員、問い合わせシステムの管理者は、貼った平文を見る。減らす対象は、送るその一份に載せる、不要な完全な番号だ。

「伏せたから公開してよい。」仮名のあとでも、問い合わせシステムは本人へ戻せる。公開ページ、対外事例、研修資料に要るのは、追加情報なしでは復元できない状態だ。それが匿名加工であり、星印いくつかではない。

「規則が走ったから、見直さなくてよい。」分割した番号（090 1234 5678）、漢字で書いた「ゼロキュウゼロ」、画像の中の番号、規則が未収録の鍵接頭辞は漏れる。人が見る対象は二つだ。結果から完全な原文をまだ検索できるか。残った文脈で、同じ一人を組み立てられるか。

どこから手を付けるか

今日これから送る一段落から始める。手元へコピーし、先に電話だけ伏せ、原文と照合し、番号とメールを同じ工程にするか決める。チャネルの古いトピックやナレッジの過去分は後回しでよい。履歴全体を一度に消す必要はない。

同じ貼り付けに URL と本文が混ざるなら、前回の対照表で UTM とクリック ID を先に除き、それから本文を伏せる。一文に注文番号と電話があるなら、注文番号を残し、電話を伏せ、文が通るかを読み返す。ここまでできれば、見出しの問いに答えられる。伏せるのは、人へ届く、または口座を動かす項目だ。残すのは、同じ業務記録を開くために必要な番号だ。

指定した一人へ、今使えるパスワード、復旧コード、APIキーを渡すなら、完全な秘密を問い合わせに書かない。マスクを「送っていないことにする」手段にもしない。ワンタイムで一度限りのリンクを作る。何度も復号したい添付はファイル暗号へ。この端末で .lock / .enc を作り、パスフレーズは別メッセージで送る。テキストのマスキングが解くのは、「議論のときに完全な番号を減らす」ことであり、鍵交換ではない。

よくある質問

伏せたあと、相手はまだ誰だか分かるか。

分かることが多い。問い合わせ番号、氏名、マスク済み電話を重ねれば、社内システムでは本人へ戻る。マスキングが減らすのは、「そのシステムの外にいる人が、完全な番号で発信したりなりすましたりする」ことだ。文面を匿名の統計には変えない。

この11桁は、なぜ電話として扱われなかったか。

携帯の形もなく、+ も区切りもない長い数字は、注文番号のことが多い。すべてを電話にすると、次の担当が要るlocatorまで伏せる。迷うなら残し、070 / 080 / 090、+、区切りのある項だけ処理し、残りは手で印を付ける。

カードを下4桁だけ残すのは、基準を満たすか。

PCI DSS の表示上限は先頭6＋末尾4だ。下4桁だけは、より狭い。末尾の確認には大抵足りる。公開チャネルへ載せてよい許可にはならない。完全な番号と氏名を Chatwork に並べない。

マスキングに登録は要るか。原文は送られるか。

登録は要らない。原文をアップロードするサイトへ問い合わせ全文を渡したとき、ログのリスクが始まる。端末内で処理するなら、原文は今のタブに残る。確かめるのは、Network が個人番号やメール全文を第三者へ送っていないこと、結果から未マスクの完全な番号をまだ検索できるかどうか、の二つだ。