同じ人が二人分に数えられている｜アドレスの表記の揺れ

配信の名簿は5,000件あるはずなのに、実際に届いている人はもっと少ない気がする。同じ会社の同じ人が二度返信してくることもある。原因のひとつが、アドレスの表記の揺れです。記号がひとつ違うだけで、名簿の上では別人として扱われます。この記事では、なぜ揺れるのか、何が起きるのか、どこで手を打てるのかを整理します。

名簿の件数と実際の人数が合わない

配信の運用を続けていると、数字の違和感に気づく場面が出てきます。登録の件数は増えているのに開封の数が伸びない。配信の対象が5,000件あるのに、実際に反応する人の顔ぶれがいつも同じに見える。件数と実際の人数がずれている可能性を疑う場面です。

ずれの原因はいくつかあります。届かないアドレスが残っている、退職した人の分が残っている、そして同じ人が複数の行で登録されている。最後のものが今回扱う表記の揺れです。

表記の揺れによる重複は、単純な文字列の比較では見つかりません。文字が違うのだから、機械は別のものだと判断します。しかし、送ってみると同じ受信箱に届きます。この食い違いが問題の核心です。

この現象は特定の提供元の仕様によって起きます。全てのメールで起きるわけではありません。そのため、一律の処理をかけると別の問題を生みます。仕組みを理解したうえで手を打つ必要があります。

影響の大きさは、名簿に含まれる個人の住所の割合によります。法人向けの事業でも、個人の住所で登録する人は一定数います。資料の請求やウェビナーの申込では特にその傾向があります。

この問題が放置されやすいのは、配信が一応は動いているからです。エラーも出ず、届いてもいる。困っている人が社内にいないため、優先度が上がりません。実害が数字の裏側に隠れているのが、この問題の特徴です。費用の無駄も、指標の歪みも、受け手の不快も、どれも「見えない損失」の形を取ります。だからこそ、誰かが意識して点検の対象に載せない限り何年でも残り続けます。

同じ人が別の行に並ぶ

典型的な現れ方を見ておきます。名簿を氏名で並べ替えると、同じ氏名と同じ会社名の行が2つ並んでいる。アドレスを見比べると、よく似ているが少し違う。この「少し違う」の中身が、記号の有無や位置であることが多いのです。

なぜ同じ人が違う表記で登録するのか。多くは意図的ではありません。入力するたびに記号を入れたり入れなかったりする。自動の入力に任せた結果、別の表記が入る。

意図的な場合もあります。どこから届いたメールかを見分けるために表記を変えて登録する。技術に詳しい利用者ほど、この使い分けをします。悪意はありませんが、受け取る側の名簿は二重になります。

さらに、会社の住所と個人の住所の両方で登録している場合もあります。これは完全に別のアドレスなので技術的には重複ではありませんが、人としては同じです。名寄せの観点では同じ問題を生みます。

こうした行が積み上がると、名簿の件数は実態より大きく見えます。報告に使う数字が実態から離れていくため、判断の基礎が揺らぎます。

氏名で並べ替えて気づける重複はまだ幸運なほうです。氏名の入力が任意になっている場合や、登録の経路によって氏名の書き方が違う場合には並べても隣り合いません。姓と名の間に空白を入れる人、入れない人。全角の空白と半角の空白。氏名そのものにも表記の揺れがあるため、突き合わせの軸としては弱いのです。結局、アドレスを軸に据えるほうが確実な突き合わせになります。だからこそ、アドレスの揺れを整理する意味があります。

記号の有無で別人になる

最も広く知られているのが、無料の大手のメールにおけるピリオドの扱いです。利用者名の部分に含まれるピリオドの有無や位置が違っても、同一のアドレスとして扱われます。公式にそう案内されています。

具体的には、ある利用者名について、その間にピリオドを入れた形も、複数箇所に入れた形も、全て同じ受信箱に届きます。利用者から見ればどれも自分のアドレスです。

受け取る側の名簿では、これらが別の文字列として保存されます。3通りの書き方をすれば、3行の登録になります。そして配信すれば、同じ人に3通のメールが届きます。

この仕組みはその提供元に固有のものです。他のサービスではピリオドは通常の文字として扱われます。同じ処理を全てのアドレスに適用すると、別人を同一人物として扱う誤りが起きます。

つまり、対処するにはアドレスの後半部分を見て処理を分ける必要があります。一律の変換では解決しないという点がこの問題を厄介にしています。

この提供元にはかつて使われていた別の後半部分もあります。そちらで登録している人も同じ受信箱に届きます。古くから使っている利用者にこの形が残っています。後半部分が違うため、文字列としては全く別のものに見えます。突き合わせの処理を書くときは、この対応も考慮に入れておくと拾える範囲が広がります。件数としては多くありませんが、長く付き合っている顧客ほどこの形を使っている傾向があります。取りこぼしたくない層と重なる点で無視しにくい項目です。

独自の住所では扱いが逆になる

さらに複雑な点があります。同じ提供元でも、組織が自前の住所で使っている場合は扱いが変わります。独自の住所ではピリオドが含まれると別のアドレスとして扱われる、と案内されています。

これは実務上非常に重要な違いです。法人向けの名簿では会社の住所が大半を占めます。そこにピリオドを無視する処理をかけると、本来別人である2人を、同じ人として統合してしまいます。

たとえば、姓と名をピリオドで区切る形式を採用している会社は多くあります。この形式ではピリオドが意味を持ちます。取り除いてしまうと別の人のアドレスと衝突する可能性すらあります。

統合の誤りは重複より重い問題です。片方の人の情報がもう片方に上書きされる、解除の意思が別の人に適用される。取り返しの付かない形で名簿が壊れます。

したがって、ピリオドを無視する処理はその提供元の無料の住所に限って適用する必要があります。後半部分を判定してから処理を分ける。この設計が必須になります。

同じ提供元で扱いが分かれる理由は、組織が自前の住所を運用するとき利用者名の付け方を自由に決められるためです。姓と名をピリオドで区切る規則を採る組織もあれば、社員の番号を使う組織もあります。提供元が一律にピリオドを無視すると、組織の設計と衝突します。そのため、独自の住所では文字どおりに扱う仕様になっていると整理できます。仕様の理由まで理解しておくと、処理を書く人にも説明しやすくなります。「そういう決まりだから」ではなく「こういう理由で分かれる」と伝えられます。

プラス記号を使った書き分け

もうひとつの仕組みがプラス記号による別名です。記号の後ろに任意の文字を付けても、同じ受信箱に届きます。設定は不要で、その場で作れます。

利用者はこれを送信元を見分けるために使います。登録するときにサービス名を付けておけば、後でどこから来たメールかが分かる。迷惑なメールが増えたときに出所を特定できます。

受け取る側から見ると、これも別のアドレスとして保存されます。同じ人が複数のサービスに登録すれば、複数の表記が生まれます。自社の名簿の中で重複することはそれほど多くありませんが、起こり得ます。

注意したいのは、この記号を含むアドレスを入力の段階で弾いてしまう例です。記号が使えると知らずに入力の検査で除外すると、正しいアドレスを持つ人が登録できなくなります。

弾かれた利用者は多くの場合問い合わせをせずに離脱します。何人が弾かれたかは、こちら側から見えません。入力の検査は厳しくしすぎないほうが取りこぼしが減ります。

大文字と小文字の扱い

大文字と小文字についても揺れが起きます。同じアドレスを先頭だけ大文字で書く人、全て小文字で書く人。見た目は違いますが、多くの場合同じ受信箱に届きます。

仕様の上では、記号の前の部分について大文字と小文字を区別することが許されています。しかし、実際の運用では区別しないサービスがほとんどです。区別すると利用者が混乱するためです。

記号の後ろの部分については、大文字と小文字は区別されません。こちらは明確です。したがって、後半部分を小文字に統一する処理は安全に行えます。

前半部分についても、実務では小文字に統一する運用が広く行われています。区別するサービスに当たる確率より、重複を放置する損失のほうが大きいという判断です。

ただし、統一する場合は元の表記も保存しておきます。表示や差し込みで元の形を使いたい場面があるためです。比較用の値と表示用の値を分けて持つ設計にします。

どの表記が同じ人かを判断する

ここまでの整理を表にまとめます。処理を分ける判断の材料として使えます。

表記の違い	同じ人に届くか	処理の方針
後半部分の大文字と小文字	届く	小文字に統一してよい
前半部分の大文字と小文字	多くの場合届く	比較用に小文字化する運用が一般的
無料の大手のメールのピリオド	届く	後半部分を判定したうえで無視する
独自の住所のピリオド	届かない	そのまま扱う。取り除いてはいけない
プラス記号より後ろの文字	届く	比較のときのみ取り除く

この表の四行目が最も注意すべき点です。独自の住所でピリオドを取り除くと、別人を統合する事故になります。処理を書くときは必ず後半部分の判定を先に入れます。

判定の対象になる後半部分は限られています。無料の大手のメールと、その旧称の住所。この2つを対象にすれば足ります。他の提供元については特別な処理は不要です。

なお、こうした仕様は提供元の判断で変わることがあります。実際の扱いは、その時点の公式の案内で確かめてください。この記事の内容は公表されている説明に基づく整理です。

表を運用に落とし込むときは、処理の順序も決めておきます。後半部分の判定を先に行い、その結果によって前半部分の処理を分ける。この順序を守らないと、独自の住所にまでピリオドの処理が及びます。処理の順序そのものが、事故を防ぐ設計になっています。実装を外部に依頼する場合は、この順序を仕様として明記します。「重複を消してほしい」という依頼だけでは、一律の処理が書かれる可能性があります。何をしてはいけないかまで伝えるのが要点です。

重複が生む実害

重複を放置すると何が起きるかを整理します。まず、同じ人に複数通が届きます。受け取る側からは、しつこい会社という印象になります。丁寧に案内しているつもりが逆の効果を生みます。

次に、配信の費用が余計にかかります。多くの配信の仕組みは登録の件数か送信の通数で料金が決まります。重複の分だけ無駄な支出になります。

三つ目に、数字が実態から離れます。開封率は送信の通数を分母にするため、重複が多いほど開封率は低く出ます。改善の判断を誤ります。

四つ目に、営業の現場が混乱します。同じ人が別々の見込み客として担当者に割り振られると、同じ相手に二人から連絡が行きます。

五つ目に、行動の履歴が分散します。資料を3回請求した人が3人の1回ずつとして記録されると、関心の高さが見えません。優先度の判断を取り違えることになります。

解除の取りこぼしが最も重い

実害の中で最も重いのがこれです。配信の解除は、押されたアドレスにしか適用されないのが通常です。別の表記で登録されている分は残り続けます。

利用者から見れば、解除したのにまだ届く状態です。「解除したはずですが」という問い合わせが来ればまだよいほうで、多くは黙って迷惑なメールとして扱います。

迷惑なメールとして扱われる数が増えると、送信元としての評価が下がります。評価が下がれば、他の受信者への到達にも影響します。一人の取りこぼしが全体に波及する構造です。

さらに、配信の停止を求められたのに送り続ける形になるため、規制の観点でも問題になり得ます。解除の意思は確実に反映する必要があります。

したがって、解除の処理では同じ受信箱に届く全ての表記を対象にする設計が望ましいことになります。登録の重複を許容する場合でも、解除だけはまとめて適用する。この非対称な設計が実務的な落としどころです。

解除の仕組みを設計するときは、比較用の値を使って同じ受信箱に届く行を全て探し、まとめて停止の印を付けます。この処理は統合とは違います。行を消すのではなく、配信の対象から外すだけです。統合の危険を冒さずに、解除だけを確実にできる方法です。もし判定を誤って別人の行まで停止してしまっても、被害はその人にメールが届かなくなることに留まります。情報が上書きされるわけではありません。統合と比べればはるかに軽い失敗で済みます。この非対称性が、解除だけを広く適用してよい理由です。

入力の段階で減らす

最も効くのは、そもそも揺れた表記が入らないようにすることです。入力の段階での対処が、後の全ての工程を楽にします。

基本は、入力された値をそのまま保存しつつ、比較用の値を同時に作ることです。後半部分を小文字にし、対象の提供元ならピリオドを取り除き、プラス記号より後ろを落とす。

この比較用の値で既存の登録を検索し、見つかれば新規に作らず既存の行を更新する。これだけで、重複の大半は生まれなくなります。

入力の画面での工夫もあります。確認のために2回入力させる方式は打ち間違いには効きますが、表記の揺れには効きません。同じ人が同じ揺れ方をするためです。

むしろ、既に登録がある場合にその旨を伝える設計が有効です。「このアドレスは既に登録されています」と表示すれば、利用者も重複させる意図がないことが多いものです。

取り込みの段階で正規化する

既にある名簿を整えるときの手順を整理します。既存のデータを触るため、必ず控えを取ってから始めます。

四つ目の目視は省略しないようにします。処理の誤りは、この段階でしか見つかりません。件数が多い場合は無作為に抜き出して確かめるだけでも効果があります。

正規化しすぎる危険

整えようとしてやりすぎる例もあります。統合の誤りは、重複を放置するより深刻な結果を招きます。

• 後半部分を判定せず、全てのアドレスからピリオドを取り除く
• プラス記号を含むアドレスを、入力の段階で無効として弾く
• 似た氏名というだけで、別のアドレスの行を統合する
• 控えを取らずに統合の処理を実行する
• 解除の処理を、押された表記だけに適用する

一つ目は最も重い誤りです。独自の住所でピリオドを取り除くと、存在しないアドレスになるか、別人のアドレスと一致してしまう可能性があります。処理を書くときは必ず条件分岐を入れます。

三つ目も注意が要ります。氏名が同じでも別人であることは珍しくありません。アドレスが技術的に別であれば、別の登録として扱うのが安全です。

統合するかどうか迷う組み合わせは、統合しないほうを選びます。重複は後から直せますが、統合の誤りは戻しにくい。この非対称性を判断の基準にします。

よくある質問

運用の現場で受ける質問のうち、判断に迷いやすいものを整理します。いずれも、名簿の設計に関わる論点です。

重複を全て消してしまってよいですか

消すより、残す行を決めて他を停止の状態にするほうが安全です。消してしまうと、統合を誤ったときに戻せません。行動の履歴も引き継いでおきます。

配信の道具に重複を排除する機能がありますが使えますか

機能の中身によります。文字列が完全に一致する行だけを対象にする機能なら、今回の揺れには効きません。後半部分を判定しているかどうかを提供元に確かめます。

会社の住所だけを受け付ける設定にすべきですか

無料の住所を弾く設定にすると、取りこぼしが生まれます。個人の住所で情報収集をする担当者は一定数います。弾くより、受け入れて整理するほうが機会を失いません。

会社の住所での名寄せ

法人向けの事業では、個人ではなく会社の単位で見たい場面があります。後半部分を使えば、同じ会社からの登録をまとめられます。

この方法は商談の管理と相性が良いものです。同じ会社から複数の担当者が資料を請求している。この事実は検討が進んでいる兆候として読み取れます。

ただし、無料の住所で登録している人はこの方法では拾えません。会社名の入力欄と組み合わせて判断する必要があります。

グループ会社が異なる後半部分を使っている場合もあります。この場合は対応の一覧を作ってまとめる処理が要ります。主要な取引先だけでも整理しておくと役立ちます。

会社の単位での集計は、個人の単位の重複とは別の話です。両方を持っておくと、報告のときに使い分けられます。

定期的な棚卸し

一度整えても、運用を続ければまた揺れが入ります。定期的に確かめる仕組みを作っておきます。

頻度は四半期に一度で十分です。前回からの新規の登録だけを対象にすれば、確認の量はそれほど多くなりません。

確かめるのは、比較用の値が重複している組み合わせと、解除されているのに別の表記で残っている組み合わせです。後者は優先して処理します。

あわせて、届かないアドレスの整理も行います。表記の揺れとは別の問題ですが、名簿を整える作業としては同じ機会にやるほうが効率的です。

この作業を誰がやるかも決めておきます。配信の担当が変わると止まりがちな作業です。手順書と担当をセットで残しておきます。

• ピリオドを無視してよいのは、対象の提供元の無料の住所に限られる
• 組織向けの独自の住所では、ピリオドは意味を持つ
• プラス記号を含むアドレスを入力の段階で弾かない
• 解除の処理は、同じ受信箱に届く全ての表記に適用する
• 仕様は変わることがあるため、公式の案内で確かめる

運用の確認項目

最後に、運用に組み込む項目を並べます。入力、取り込み、解除の3か所に手を打てば大半は防げます。

• 入力の時点で、比較用の値を作って既存の登録を検索しているか
• 後半部分を判定してから、ピリオドの処理を分けているか
• プラス記号を含むアドレスを、入力の検査で弾いていないか
• 元の表記と比較用の値を、分けて保存しているか
• 解除の処理を、同じ受信箱に届く全ての表記に適用しているか
• 統合の前に控えを取る手順があるか
• 統合した組み合わせを記録に残しているか
• 四半期に一度、重複と解除の残りを確かめているか
• 会社の単位での集計を、別に持っているか
• この作業の担当と手順書があるか

この一覧の五番目が最も優先度の高い項目です。解除の取りこぼしは、利用者との関係と送信元の評価の両方を損ないます。他の項目が未整備でも、ここだけは先に手を打つ価値があります。

一番目と二番目は仕組みの改修が要るため、次の見直しの機会に合わせて進めます。改修までの間は取り込みの段階での処理で補います。

まとめ

名簿の件数と実際の人数がずれる原因のひとつが、アドレスの表記の揺れです。無料の大手のメールでは利用者名の部分のピリオドが無視され、同じ受信箱に届きます。一方、同じ提供元でも組織向けの独自の住所ではピリオドが意味を持ちます。扱いが逆になる点がこの問題を厄介にしています。

実害として重いのは重複そのものより解除の取りこぼしです。解除したのに届く状態は、利用者との関係も送信元としての評価も損ないます。入力の段階で比較用の値を作り、解除は同じ受信箱に届く全ての表記に適用する。この2点を押さえれば、名簿は実態に近づきます。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。