本人入力データと証明書類の差分を並べて確認できる表を作ったら確認が速くなった話

データ表記揺れが引き起こす本人確認の負荷

本人確認のチェックを行っていると、入力データと証明書類が少し違うだけで手が止まってしまう場面がよくあります。画面に並ぶ二つの文字列。一つは申請者が入力したデータ、もう一つは提出された証明書類から読み取ったデータです。

「山田 太郎」と「山田　太郎」。

まず、人間の目では同一人物に見えるのに、システム上は「不一致」になってしまいます。原因は氏名の間に入った全角スペースです。たったそれだけで確認作業が止まってしまいます。

新人の頃、システムが弾いた「不一致リスト」をそのまま信じて、100件以上の申請を機械的に差戻したことがあります。翌朝は内線電話が鳴り止まず、「全角スペースで差戻しは厳しすぎる」とクレーム対応に追われました。結局その日は手動で再審査をやり直し、判断基準を見直すきっかけになりました。

住所表記揺れ、業務のボトルネック

住所の表記揺れはさらに厄介です。「東京都千代田区1-1-1」と「東京都千代田区一丁目一番地一号」。あるいは「〇〇マンション302号室」と「〇〇マンション 302」。これらもExcelでは別データとして扱われます。`EXACT`関数をかけると`FALSE`が返り、全角半角やスペース、丁目番地とハイフン表記の差がそのまま不一致になってしまいます。

次に、この「システム上の不一致」が、業務のボトルネックそのものでした。一件一件、目視で「これは表記揺れの範囲内」「これは明らかに別人」と判断を下します。その判断に迷うたびに、先輩や上司に確認を取ります。その間、他の申請の処理は完全に止まってしまいます。PayPayのヘルプには本人確認書類の表記に合わせて入力するよう案内がありますが、全てのユーザーがその指示に従ってくれるわけではありません。結果として、確認担当者の元には、微妙に違うデータが絶え間なく流れ込んでくることになります。これが、残業の直接的な原因でした。

住所正規化、完璧より比較の見える化

この泥沼から抜け出すために、多くの人が最初に考えるのは「データの正規化」ではないでしょうか。全角カタカナを半角に、漢数字をアラビア数字に、ハイフンを「丁目番地」に統一する、いわゆるデータクレンジングと呼ばれる処理です。VBAやPythonでスクリプトを組めば、こうした表記揺れを吸収できるのではないかと考えがちです。

ただ、ここに落とし穴がありました。

私自身も最初は住所正規化のVBAを書けば解決できると思っていましたが、すぐに壁にぶつかりました。「髙」と「高」、「﨑」と「崎」のような異体字や、市町村合併前後の住所、建物名の揺れなど、例外が次々に出てきたのです。完璧を目指すほどコードが複雑化し、3日かけても実務で使える形にはなりませんでした。

完璧な自動化を目指した結果、作業だけが増えて前に進まないという状況に陥りました。私自身、このパターンでかなり時間を使ってしまった経験があります。差分確認の初動では、高度な正規化を行うより『どこが違うかをすぐ見える化する表』を先に作る方が、実務では回しやすかったです。

Excel活用、人の判断で作業円滑化

発想を少し変えて、システムに100%判断させるのをやめました。人が見て判断しやすい形に整えるための道具としてExcelを使います。入力データと証明書データを横に並べ、差分が目に入るようにするだけで、最初は十分でした。

そのため、目安として、完璧な住所正規化VBAを自作しようとすると、初期開発だけでも相応の時間がかかってしまいます。

複雑なロジックを最初から組む必要はありません。重要なのは、判断する場所がすぐ分かることです。人が目で見て判断する流れを邪魔しない形にします。正規化の完成度を追う前に、まず比較できる状態を作る。この順番にしたことで、止まりがちだった確認作業が回り始めました。

Excelで実現する3色判定確認表

具体的な確認表の作成はシンプルです。必要なのはExcelの基本関数と条件付き書式だけでした。複雑なマクロは不要です。

まず、以下のような列構成のシートを用意します。A列：申請ID B列：本人入力氏名 C列：証明書データ氏名 D列：氏名判定 E列：本人入力住所 F列：証明書データ住所 G列：住所判定 H列：本人入力生年月日 I列：証明書データ生年月日 J列：生年月日判定

次に、キモとなる「判定列」（D, G, J列）に数式を埋め込んでいきます。ここでの目標は、完全な自動判定ではなく、人間の判断を助けるための「3色のラベリング」です。

緑（一致）：これは最も簡単です。`IF(B2=C2, “一致”, …)` のように、二つのセルが完全に一致する場合です。

表記揺れ検出とデータ確認効率化

しかし、黄（要注意）：ここが工夫のしどころです。完全一致ではないが、表記揺れの可能性が高いものを炙り出します。`SUBSTITUTE`関数でスペースを削除し、`ASC`関数で全角英数字・カタカナを半角に変換した上で比較します。例えば、氏名判定のD2セルには以下のような数式を入れます。 `=IF(B2=C2, “一致”, IF(SUBSTITUTE(SUBSTITUTE(ASC(B2),” “,””),”　”,””)=SUBSTITUTE(SUBSTITUTE(ASC(C2),” “,””),”　”,””), “要注意”, “不一致”))` この数式は、まず完全一致かを確認し、そうでなければ半角・スペース統一後の文字列で比較し、それでも一致しなければ「不一致」と判定します。

赤（不一致）：上記のいずれの条件にも当てはまらない、明らかに異なるデータです。

色分け表示による確認効率化

最後に、この判定結果を視覚的に分かりやすくするため、条件付き書式を設定します。「ホーム」タブの「条件付き書式」から「セルの強調表示ルール」→「文字列」を選び、「一致」という文字列を含むセルを緑に、「要注意」を黄色に、「不一致」を赤に塗りつぶすよう設定します。

さらに、これで完成です。この表を開けば、担当者はまず赤と黄色のセルに集中すれば済みます。緑のセルは機械的にOKと判断できるため、確認作業の多くをスキップできます。ランダムなデータを総当たりで見るより、色で目印がある方が判断しやすく、確認速度も上がりやすい傾向にあります。

グレーゾーン対応と心理的負担軽減

ツールを作っても、運用ルールが変わらなければ効果は出にくいものです。3色判定の確認表を導入すると同時に、私たちは「少しでも違えば差戻し」という運用を見直す必要がありました。

以前は「少しでも違えば差戻し」という硬直した運用だったため、申請者からのクレームが増え、現場は疲弊していました。新しい確認表は、我々に「グレーゾーン」を明確に示してくれました。それが「要注意（黄色）」のセルです。問題は、この黄色をどう扱うかでした。

まず、チームで話し合い、運用ルールを明文化しました。氏名：「渡邊」と「渡辺」、「齋藤」と「斎藤」のような異体字は同一人物と見なして承認する。明らかに名前が違う場合は差戻し。住所：「3-2-1」と「3丁目2番地1号」のような表記揺れ、マンション名の有無は承認。市区町村名や番地そのものが異なる場合は差戻しとしました。この判断は、SMBCのFAQで住所相違の場合に追加書類で対応する運用が紹介されているように、金融機関でも柔軟な対応が行われている事実が後押しとなりました。

判断事例集による業務改善と自信

ルール策定後も、最初は担当者ごとに黄色判定のばらつきが出ました。そこで、迷った事例を週1回共有し、判断事例集として社内Wikiに蓄積しました。半年ほど続けると、多くのケースは事例集を見れば自己解決できるようになり、判断基準の平準化と新人教育の短縮につながりました。

重要なのは、判断ログを残してチームで共有し、少しずつ改善を回すことです。赤（不一致）は差戻し、緑（一致）は承認、黄色（要注意）は決めたルールで処理する。この流れが定着すると、作業の詰まりが減っていきました。

次に、導入前後で見ると、1件あたりの確認処理時間は短縮傾向になりました。

確認担当者の精神的な負荷も大きく軽減されました。「自分の判断は正しかっただろうか」という不安が、「ルール通りに処理した」という自信に変わったのです。これは、数値には表れない、しかし非常に大きな成果でした。

生きるExcelシートの継続改善

一度作った仕組みが、ずっと有効なまま続くことはありません。業務で使うExcelがいつの間にか作成者しか触れない状態になって古くなるのはよくある話です。3色判定表も放置すれば同じことになってしまいます。

一方で、申請フォームの項目が追加されたり、新しいパターンの表記揺れが登場したりと、外部環境は常に変化します。この変化に追随できなければ、ツールの精度は徐々に落ちていきます。そこで、私たちは「作って終わり」にしないための、ごく簡単なルールを設けました。

それは「毎月第1金曜日の16時から30分間、チーム全員で確認表を見直す」というものです。

30分という短い時間で、ダラダラと議論するのを防ぐため、アジェンダは3つに絞りました。1. この1ヶ月で「要注意（黄色）」の判断に迷った事例はなかったか？ 2. 新しい表記揺れのパターンは発生していなかったか？（例：海外の住所表記など） 3. 判定列のExcel数式は、もっとシンプルで分かりやすいものに改善できないか？

Excelで脱出、未来の自動化基盤

そのため、この短い定例で出た課題や改善案は、すぐに判断ルールやExcelの数式に反映させます。例えば、特定のマンション名が頻繁に表記揺れを起こすなら、`SUBSTITUTE`関数でその名称をあらかじめ削除する、といった修正を加えます。

この地道なメンテナンスを続けることで、確認表は常に「生きている」状態を保つことができます。そして、このExcel表は単なる一時しのぎのツールではありません。将来、本格的なRPAや業務システムを導入する際、この表で蓄積された判断ルールや表記揺れのパターンは、そのまま要件定義の貴重な資料となるはずです。

完璧な自動化という遠いゴールを目指す前に、まずは目の前の現実に向き合い、人間の判断を助ける賢い仕組みを作ること。差分確認地獄からの脱出は、たった一枚のExcelシートから始まったのです。

関連リンクとチェックリスト

学習サービスとアンケート