日本の金融機関にとって、制裁スクリーニングやコンプライアンスに関する厳格な基準は、データ品質を単なるバックオフィスの問題にとどめません。データの質は、金融機関が規制当局に対して自らの判断を適切に説明できるかどうかを左右する、極めて重要な要素です。高品質なデータは、あらゆる業種におけるリスク管理や法令遵守の基盤であり、とりわけ金融機関では不可欠です。
規制の要求が進化し、レガシーシステムと新しいプラットフォームが混在する環境で業務が行われる中、データ品質の弱点はこれまで以上に露呈しやすくなっています。データが不整合であったり、不完全であったり、古いまま更新されていなかったりすると、重要な内部統制が弱まり、業務コストの増加やコンプライアンス対応の複雑化につながります。
本記事は全2回シリーズの第1回として、当社が日本各地の商用データを扱う中で特に多く見られた「5つの代表的なデータ課題」について解説します。
これらの現象がビジネスにとってなぜ重要なのかを説明するとともに、問題を早期に発見し適切に対処することで、企業が信頼性を高め、エラーを減らし、業務効率を向上させ、将来的な規制リスクを軽減できることを示します。
|
【豆知識】 半角カナは「日本語を扱えない初期コンピュータの制約」を乗り越えるための工夫だった 。 |
半角カタカナと全角カタカナの不一致は、システムごとに日本語文字の扱い方やエンコード方式が異なることから生じます。特に金融機関では、古いシステムや表示スペースが限られた画面などで、今でも半角カタカナが使われ続けているケースが多く見られます。
古いシステムと、新しいシステム（全角文字を前提とする）が連携する場面では、さまざまな問題が起こり得ます。最低限でも、半角と全角を変換する作業が必要になり、いわば「日本語から日本語への翻訳」のような手間が発生します。さらに、半角カタカナは“情報が欠ける”表記方法であり、半角に変換した時点で元の情報の一部が失われます。そしてこの情報の欠損は基本的に元に戻せないため、後から完全に復元することはできません。
日本の金融システムに初めて関わる海外企業や外国人にとって、これはさらに複雑さを増す要因になります。書類や申込フォーム、入力欄によっては、半角カタカナを使うよう求められたり、逆に全角カタカナを使うよう促されたりすることがあります。
しかし、こうしたルールは明確に説明されていないことも多く、システムごとに基準が異なるため、
- 入力ミス
- チェック（バリデーション）の失敗
- 申込や口座開設手続きの遅延
といった問題につながりがちです。
運用面では、こうした問題が原因で「人手による確認作業」が増えることがよくあります。本来のリスクとは関係なく、文字の表記ゆれが原因でデータが一致しなかったり、不審な記録に見えてしまったりするため、担当者が調査しなければならないケースが増えるのです。また、重複データが発生するリスクも高まります。
たとえば、
- 1つは全角の漢字で登録
- もう1つは一部が半角（さらに悪い場合はローマ字）で登録
といった形で、同じ顧客や企業が別人・別会社として扱われてしまうことがあります。
こうした状況が続くと、
- 業務コストの増加
- 処理時間の遅延
- 社内データへの信頼性低下
といった問題につながっていきます。
このような表記ゆれは、顧客データや取引先データを大量に扱う場面では、より深刻な問題になります。大量データを処理するには自動化が欠かせませんが、人間なら気づけるようなわずかな文字の違いでも、システムでは追跡・照合・統一が難しくなることがあります。その結果、データの管理や整備が複雑になり、業務全体の効率にも影響が出てしまいます。
半角データにおける「濁点（゛）」の扱いは、よく知られた問題です。半角カタカナでは、濁点が文字本体とは別の文字として保存される仕組みになっています。たとえば「ﾀﾞｲｽｹ」は、まず「ﾀ」という文字、その後に「゛（濁点）」が続いて記録されます。
市販の変換ツールや一般的なシステムでこのデータを全角に変換する際、この構造の違いを正しく考慮していないことがよくあります。その結果、濁点が誤って解釈されたり、正しく結合されなかったりして、名前の表記が間違ったり不統一になったりすることが起きてしまいます。
この問題に対応するため、当社では「文字の表記ゆれ」を単なるフォーマットの違いとして扱うのではなく、より大きな「顧客識別（ID解決）」の課題の一部として捉えるアプローチを開発しています。データ処理の段階で、日本語特有の例外ケースや細かな表記の違いを考慮することであいまいさを減らし、コンプライアンス業務におけるデータ照合の信頼性を高めることを目指しています。
外来語（特に固有名詞）を日本語に訳すとき、またその逆を行うときに「読みの変換の不一致」が起こることがあります。たとえば 「Michael」 という名前は、日本語では マイケル とカタカナ表記され、ローマ字にすると MAIKERU のように、日本語の発音に近い形になります。しかし、このように日本語の音に合わせて表記したものを、再びローマ字に戻すと、本来の綴りとは異なる「誤ったスペル 」になってしまうことがあります。
図 1：外国人名のカタカナ表記とローマ字表記の対応
「マイケル」を見かけたら「Michael（マイケル）」だと認識するように、現代のデータシステムは学習させることができるため、「マイケル問題は本来それほど大きな不便ではありません。適切に設計されたシステムであれば、この種のあいまいさは比較的簡単に回避できます。しかし残念ながら、私たちが使っている多くのシステムはそこまでの判断力を備えていないため、本来は些細な現象であるはずのものが、慢性的な問題として広がってしまうことがあります。
より厄介なのは、半角と同じように、外国語の表記変換が「情報が失われる（ロスが出る）」タイプの場合です。この場合、システムに特定のパターンを「学習」させても、元の形を確実に復元することができません。こうしたロスが生じる変換には、次の2つの種類があります。
1) その言葉自体が新しく、「既知の」変換ルールが存在しない場合
2) 同音語や似た発音の語であり、複数（場合によっては非常に多く）の表記ゆれが存在する場合
グローバル化の進展と、日本企業の国際取引が歴史的に大きな成功を収めてきたことにより、海外由来のデータが日本のシステムに大量に流入するようになりました。その内容は、日本に進出する海外ブランド、海外在住の株主、そして特に日本企業の海外取引先など、多岐にわたります。
当社のCTOであるWarwick Matthewsは、良い例と言えます。姓の “Matthews” は特に珍しい名前ではありませんが、決まった表記揺れ対策（標準的なカタカナ表記）がないため、「マセウス」「マテウス」「マシューズ」など、さまざまな表記になり得ます。そのため、システムによっては元のローマ字表記に正しく戻せたり、戻せなかったりと、精度にばらつきが出てしまいます。
一方、名の “Warwick” は世界的に見てもかなり珍しい名前で、もともとはイギリスの伯爵位に由来します。また、名よりも姓として使われることのほうが一般的です（例：1980年代の米国歌手ディオンヌ・ワーウィック）。さらに “Warwick” は、オーストラリア、イングランド、英国各地で発音が大きく異なるため、「ウォリック」「ワーリック」「ウォーウィック」など、複数のカタカナ表記が生まれます。このように標準的なカタカナ表記が存在しない場合、カナとアルファベットの間で非常に奇妙な変換が生じることがあり、今回の例では “WORIK” のような表記になってしまうこともあります。
外国語にも日本語と同じように、同じ発音の固有名詞が多数存在します。その一例が、発音は似ているにもかかわらず綴りが異なる複数の外国人名が、日本語のカタカナ表記にすると同じ読みになってしまうケースです。
たとえば “Mya” と “Maya” は綴りは違いますが、どちらも同じ発音です。しかしカタカナにすると、どちらも「マヤ」と表記されます（図 2）。一見すると問題なさそうに見えますが、では入力として「マヤ」と与えられたとき、どちらの “Mya”／“Maya” を指していると判断すべきでしょうか。
図2：マヤのさまざまな表記例
これらの発音変換の不一致は、データ品質に影響を及ぼす潜在的な問題を生み出します。1つのカタカナ表記が複数の外国語の綴りに対応してしまったり、日本語の音声体系の制約から外国人名を近似的に表記せざるを得なかったりすると、データにあいまいさが入り込みます。このあいまいさが原因で、重複登録が発生したり、誤ったデータ統合が行われたり、多言語データベースで照合に失敗したりする可能性があります。その結果、名前に基づく識別や検索システムの正確性や一貫性が低下してしまいます。
その結果、制裁対象者を特定するスクリーニングシステムでは、大量の「誤検知（false positive）」が発生する可能性があります。1つのカタカナ表記が複数の外国語の綴りに対応してしまったり、逆に1つの外国人名に複数のカタカナ表記が存在したりするためです。このため、記録が「一致の可能性あり」として多数フラグされても、詳しく調べると該当しないケースが多く発生します（図3）。こうした過剰な誤検知は、業務プロセスを遅らせ、本来対応すべきリスク案件へのリソースを奪ってしまいます。
図 3：複数の日本語表記が存在する外国人名を照合すると、誤検知（false positive）が発生しやすくなる
この問題を軽減するために、当社ではファジーマッチング（あいまい一致）アルゴリズムを活用し、候補を照合する際に補助的なデータも組み合わせて評価しています。たとえば、氏名データに加えて、役職や所属組織といった属性情報も参照することで、照合精度を高め、誤検知（false positives）を減らしています（図4）。
図4 ：補助的なデータを活用することで、照合の確度が向上する
次回の記事では、残りの3つの課題を紹介します。
3.ノイズ”の多い企業名
4.変動しやすい住所データ
5.旧字体（古い漢字）の残存
さらに、より良いデータ活用につながるベストプラクティスについてもご紹介します。
著者のご紹介
ウオリック・マセウス
ウオリック・マセウス(Warwick Matthews)
最高技術責任者 兼 最高データ責任者
複雑なグローバルデータ、多言語MDM、アイデンティティ解決、「データサプライチェーン」システムの設計、構築、管理において15年以上の専門知識を有し、最高クラスの新システムの構築やサードパーティプラットフォームの統合に従事。 また、最近では大手企業の同意・プライバシー体制の構築にも携わっている。
米国、カナダ、オーストラリア、日本でデータチームを率いた経験があり、 最近では、ロブロー・カンパニーズ・リミテッド（カナダ最大の小売グループ）および米国ナショナル・フットボール・リーグ（NFL）のアイデンティティ・データチームのリーダーとして従事。
アジア言語におけるビジネスIDデータ検証、言語間のヒューリスティック翻字解析、非構造化データのキュレーション、ビジネスから地理のIDデータ検証など、いくつかの分野における特許の共同保有者でもある。