JDMC Presentation 2 0 2 3 年 0 5 月 2 6 日 Compliance Data Lab Making Compliance Closer © C D L . C O M M E R C I A L I N C O N F I D E N C E . D O N O T R E D I S T R I B U T E . V1 CDL WWW COMPLIANCE STATION

agenda 1. データマネジメントの進化 - 企業や行政に必要なもの - データマネジメントの進化 - ツールやニーズがどのように変化しているのか 2. ケーススタディ– 米国大手企業におけるDM, DQ 及びIDR について - 背景、出発点 - 「スピードの必要性」vs 適切なDM - データフリクション vs 一貫性 - アジャイルデータ - 高度なエッジデータマネジメント 3. アイデンティティ・レゾリューション - どこで活用され、その重要性について - IDR: 神話と現実 - 予測性とデータ量（多 vs 少） 4. アジア言語・IDR - 課題、アプローチ - 翻字 - ベストプラクティス

1. はじめに DM（データマネジメント）の進化に関して

視点を保つ – 我々がここにいる理由 企業や政府は、より良いIDRやより多くのデータを必要とするのではなく、データに よって推進されるより良い結果が必要なのです。 我々はデータに溺れてしまっています- より速くより多くのデータで仕事を行う必要があります。 People don't want to buy a quarter-inch drill. They want a quarter-inch hole! “ ” THEODORE LEAVITT, HARVARD BUSINESS SCHOOL 人々は四分の一インチのドリルを買いたいわけではありません。彼らは四分の一インチの穴が欲しいのです！

データとアナリティクスの進化 1995 2000 2005 2010 2015 2020 次は? データ ウェアハウジング MDM の台頭 データレーク “エッジデータ” “データ ファブリック” ナレッジ グラフ クラウド データサイエンスとアナリティクスの台頭 ビッグ データ 2023

リレーショナル NOSQL (ドキュメント) グラフ バーチャル - 冗長なデータを避けることができる - 伝統的なテクノロジー - ACID - 長い歴史がある - 設計とメンテナンスが複雑 - オペレーショナル・オーバーヘッド • 柔軟 • 拡張性が高い • ACIDではない (通常) • 高速 in/out • 複雑な統合には不向き • 殆どの物を接続可能 • 高度なグラフクエリやアナリティクス をサポート • 全く異なるパラダイム • 大規模なデータの「ペイロード」に対 して最適ではない（「膨張」のリスクが ある） • 大規模運用ではコストが嵩む可能性 がある • ETLなしでデータの恩恵を受けられる • ベンダーのエコシステム手動になる 傾向がある • 複雑なセキュリティ体制を必要とする 場合がある (e.g. VPC ピアリング等). e.g. PostgreSQL, MSSQL e.g. MongoDB, DynamoDB e.g. Neo4J, TigerGraph, Neptune e.g. Snowflake データ処理、キュレーション、および統合のオプション { ☰ } MSSQL MONGODB NEO4J / AWS NEPTUNE AMPERITY SAP GIGYA ACXIOM SNOWFLAKE 注意: これは非常に簡 略化されたリストで す！

ケーススタディの前に…チャタムハウスルールについて When a meeting, or part thereof, is held under the Chatham House Rule, participants are free to use the information received, but neither the identity nor the affiliation of the speaker(s), nor that of any other participant, may be revealed. このルールの目的は、会議室の壁の内側で話をする人々に匿名性を保証し、より良い国際関係が達成されることにある。現在、 このルールは国際的に使用され自由な議論を支援している。1927年当初の規則は、1992年10月と2002年に改訂された。 チャタムハウスルールに基づいて会合が開催された場合、参 加者は受け取った情報を自由に使用することができますが、 発言者や他の参加者の身元や所属を明らかにすることはで きません。.

2. ケーススタディ 北米の有名なスポーツリーグの事例

ケーススタディ：スポーツリーグ • 北米の主要スポーツリーグ • 倶楽部、リーグ、スポンサー、パートナーとの複雑なステークホルダー関係 • 1億4千万人以上のファン/顧客 • 3-4千万件の更新/日（~20億件の更新/月）12か月で10倍の増加 • データは日次フルファイル、差分、重複が混在 • 20以上のサプライヤー、10以上のフォーマット • 非常に急速な有機的成長 • 常に、より多くのデータを追い求めている（特にサードパーティ） • 日々、データの種類、信ぴょう性、量が大きく変化する • 短期的成果のみ追い求める 「今日は何をしてくれたの？」という思考 • 2022年までデータ戦略がない • 大規模なサイロ式文化 • アップグレードする余地がない：まるで走行中のバスのタイヤを交換するような感覚 課題：

• ファイルベースのアーキテクチャ • 100以上の S3 Bucket • 1000以上のフォルダ • 何度もコピーされたデータ • 「真実の情報源」がない(MDM) • ガバナンスがない • 一貫性がない • ドキュメント化されていない ケーススタディ：出発点

次のスライド：ケーススタディーからさらに戦略的な学びを得る 1. スタンダードビューの作成及び ドキュメント化 2. MDMの導入 3. 柔軟なユースケースビュー • データサイロの競合は、品質を低下させ、 信頼性を損なわせる • 情報の順位付け • 最適なものを選択する • それらをスタンダードビューとして使用 • 素早く実装でき、優先順位ルールも不要 • 「箱から出してすぐ使える」MDM ソリューション の導入 • 構築は推奨せず：技術的能力がないため • 完全に搭載する必要がなく、データのクラスタリ ングが可能なシステムを利用する • 主要なステークホルダ（デジタルチーム、クラブ、マー ケティングチーム）と実際に何が必要かを検討する • 完全なレコードは必要ない：通常はSuper 6（主 要6項目）で対応可 • ソース及びキュレーションデータを使用し、「目的に 合った」ビューを作成 • 標準的な品質ルールとフィードバックサイクルについて、 上流ソースと連携 ケーススタディ：段階的な解決策

リーグの主な課題: スピードの必要性 vs. 適切な DM どのようにしてボリュームを指数関数的に増やし、同時にレイテンシーを削減するか、一貫性のないデータが不統一 なデータサイロに流れ込むことなく、制御された状態を保つことができますか？ データフリクションはデータを迅速に使用可能な状態にすることを妨げます。しかし、データ処理には障壁が存在し なければならない理由があります： • Identity Resolution（アイデンティティの解決） • 標準化/データクリーニング • コンプライアンスの必要性 • 構造的課題 （例：データサプライチェーンを通じた複数の手続きや再設計を必要とする、複雑なデータ処理） If you need to be able to action data daily, you can’t have a data supply chain that takes 72 hours to deliver it. 日次でデータ処理をする必要がある場合、72時間かけてデー タを届けるようなサプライチェーンはありえない

スピードの必要性 – リスク: データフリクションvs一貫性 • データフリクションを減らすとデータはより簡 単に、より速く流れるようになります。 • しかし、矛盾が増える危険性があります。 • つまり、データが無秩序に環境内で拡散し てしまうのです。 • 結果、企業の様々な場所で、同一企業の 一貫性のないビューが多く存在することに なります。 リスク: フリクションが減っても、不整合が増える… フリクション 不整合

スピードの必要性 – アジャイルデータ 「データレイク」や「レイクハウス」は非常にトレンディなバズワードですが、従来のデータウェハウスを新しいクラウド 技術で構築しただけのものであることがあります。 しかし、アジャイルデータ処理はリアルで非常に価値のあるものです。このアプローチは以下のことを保証しま す： • データを残しません（すべてがレイクハウスに流れます） • 処理（フリクション）はユースケースに見合ったものです（例：目的に合ったDM） • DM チームは、ユースケース（ステークホルダ）毎に異なるSLAを提供できます FRAUD CUSTOMER SERVICE MARKETING IDR “データレイクハウ ス” 利用可能になるまでの時間➔ データクリーニング

ソリューション：中央集権ではなく接続に重点を置く “データレイクハウス” IDRで接続 Match システムはアイデンティティのブローカーとして機能します。データは一 元的に取り込まれ、管理されますが、IDが一貫して提供され、アイデンティティ システムによって記録される限り、組織内のどこでも管理することができます。 アイデンティティのリクエストはどこからもで可能です。 クライアントシステムは、 玲クアハウスや互いに接 続するためのIDを要求す ることができます。

将来：エッジデータマネジメント データの事前準備とクリーニングはここ で（ソースの近く）で行われる。エッジコ ンピューティング/IoTの進化の一部。 課題：DMの「真実のポイント」に至 る経路に、複数のタッチポイントとハ ンドオフがあること。 課題：エッジDQをここからどのよう に管理すべきか？

3. アイデンティティ・レゾリューション(IDR) 1. コンセプトとアイデア

なぜ、今、IDRが重要なのか 1:1 大規模な範囲での関与 • 消費者は、マーケティングとエンゲージメントが高 度にパーソナライズされ、適切であることを期待し ます。 • .最適なリーチを保証するため、消費者が誰なの か知る必要があります。 コンプライアンス、同意、プライバシー • 消費者規制の体制が「プライバシーファーストになりつつ あります：GDPR（EU)、CCPA（カリフォルニア）、CPA （コロラド）」等。 • 対象者が誰なのかわからなければ、データを適切に管 理することはできません。 • 法律は、消費者の視点から（受動的に）書かれてい ます。企業が、その人が誰であるかを知っていると仮定 します。 • 積極的なコンプライアンスには、効果的なIDRだけでなく、 継続的な活動関しが必要です。

神話：企業は我々の事を全て知っている 19 • 企業や政府は、対象者のことを何でも知っているという認識があ るようです。 • 確かに、多くのデータを収集しているのは事実です • しかし、それを実際に繋げることはできているのでしょうか？ • 法的に、倫理的にどうでしょうか？

アイデンティティ・レゾリューションの本当の姿とは… 20

21

実証主義 vs 建設主義 アイデンティティモデル（と現実） 22

2. コンセプトと用語の一致 3. アイデンティティ・レゾリューション(IDR)

データポイントの「スープ」からのIDR ? ? does something with

データポイントの「スープ」からのIDR ? ? does something with

データポイントの「スープ」からのIDR ? ? does something with

マッチング の「パイ」 マッチ環境 参照ファイル 入力データ

マッチ率 マッチ率と正確性は同じものではありません。 マッチ率は、アルゴリズムによって生成されたケースの数を示しています。 「信頼度」は正確性の測定に基づいて、どの程度の割合の「一致」が正しい可能性が高いかを示しています。 「90%のマッチ率を達成しました... …しかし全ての一致は誤りでした」

マッチ率 vs 信頼度/正確性 マッチ率は数学的に導き出されており、結果を計算します。 信頼度は経験的に導かれるもので、品質を測定します。 （正確には、正確性はサンプルに対し測定したもので、信頼度はその測定値から導き出した結論となります）

IDRの成果を表現する 良いアプローチ: 「80%の信頼度で、60%のマッチ率を得ることができた」 これにより、より強力で有用なステートメントを作成することができるようになります 例： 次のような「マッチ率」を受け取りました： 「次のようなマッチ率を受け取りました： • ファイルの25%を100%の信頼度で算出しました – これらを「A」マッチと呼びます • ファイルの25%を70%の信頼度で算出しました – これらを「B」マッチと呼びます • ファイルの40%を50%の信頼度で算出しました – これらを「D｝マッチと呼びます - 実際に欲しい結果はどれだけありますか？ A B D 0% 25% 50% 75% 100%

「ゴールデンレコード」が必ずしもゴールデンでない理由 • 「ゴールデンレコード」や「ベストビュー」の作成はごく当たり前の事です。 • 多くのMDMシステムがこれを実現しています。 • 進化するDMの世界では、最適な方法とは言えなくなってきています – 多くの異なるソースに基づくスーパーセットのレコードを維持することは非 常に困難です（複雑な優先順位ルール） – ゴールデンレコード制度は、サードパーティデータを試金石として最適に機 能することが多く、このデータの取得が問題になってきています（同意とプ ライバシー規制） – 高速（低摩擦）なデータサプライチェーン（DSC）のニーズは、非常に 迅速に処理する必要があります。複数の「目的に適した」ビューは単一 のゴールデンレコードに代わる、実用的な選択肢です。 – つまり、ユースケースごとに異なるビューを作成することです。

MDM-IDR のアプローチ 従来のMDMは、ETLとデータモデルを使用して、あらゆるユースケースを サポートするように設計された「ゴールデンレコード」にデータをまとめます。 別のアプローチとしては、データをより緩やかに接続し、文脈に応じた複数のビューを作 成することです。 ロード ➔ 変換 ➔ 識別 ➔ 保存 ➔ 利用 段階 ➔ 接続 ➔ 結合 ➔ 利用 GOLDEN RECORD

3. 参照 VS 非参照クラスタリング及びマッチング 3. アイデンティティ・レゾリューション(IDR)

非参照クラスタリング FILE 1 F1-1 WILLIAM SMITH F1-2 RICHIE DAVIES F1-3 DAVID SMITH F1-4 SARAFINA NICKELBY F1-5 DR RAJIV SUBRAMANIAN F1-6 DAVE SMITH FILE 2 F2-1 WILLIAM SMITH F2-2 RISHI DAVE F2-3 SMITH DAVID F2-4 JOHN GLEESON F2-5 RAJIV SUBRAMANIAN MATCHED FILE F1-1 WILLIAM SMITH F2-1 WILLIAM SMITH F1-3 DAVID SMITH F1-6 DAVE SMITH F2-3 SMITH DAVID F1-4 SARAFINA NICKELBY F2-4 JOHN GLEESON F1-5 DR RAJIV SUBRAMANIAN F2-5 RAJ SUBRAMANIAN 一致 一致 ?? 不一致?? F2-2 RISHI DAVE F1-2 RICHIE DAVIE 34 孤立レコード?? 孤立レコード??

参照マッチング IDR 環境 マッチ参照ファイル FanID 1 WILLIAM SMITH FanID 2 JOHN GLEESON FanID 3 SMITH, DAVID ★ DAVE SMITH FanID 4 DAVID SMITH FanID 5 SARAFINA NICKELBY FanID 6 RICHIE DAVIES ★ RISHI DAVE FanID 7 RAJIV SUBRAMANIAN F1-1 FanID 1 WILLIAM SMITH F2-1 FanID 1 WILLIAM SMITH F2-3 FanID 3 SMITH DAVID F1-6 FanID 3 DAVE SMITH F1-2 FanID 6 RICHIE DAVIES F2-2 FanID 6 RISHI DAVE ! F2-5 FANID 7 RAJIV SUBRAMAN F1-5 FANID 7 DR RAJIV SUBRAMANIAN F1-3 FanID 4 DAVID SMITH ! • 独立してキュレーションされている • 独立した更新プロセス FILE 1 F1-1 WILLIAM SMITH F1-2 RICHIE DAVIES F1-3 DAVID SMITH F1-4 SARAFINA NICKELBY F1-5 DR RAJIV SUBRAMANIAN F1-6 DAVE SMITH FILE 2 F2-1 WILLIAM SMITH F2-2 RISHI DAVE F2-3 SMITH DAVID F2-4 JOHN GLEESON F2-5 RAJIV SUBRAMAN 36

4. 予測性と、より多くのデータ VS より少ないデータ 3. アイデンティティ・レゾリューション(IDR)

郵便番号は非常に興味深く、汎用性の高いデータです。郵便番号と他のデータ も収集することで人口密度の指標として使用することができます。 例えば、モンタナ州の小さな町で同じ生年月日の二人の「ジョン・スミス」が別人 である可能性は、ニューヨーク州の都市部と比べると、はるかに低いと考えられま す。 このようなデータポイントは、アイデンティティがユニークでないという、リスクを示すス コアを作成するのに役立ちます。 Flushing NY 面積 2.17 mi² 人口 54,878 人口密度スコア 25324 Beaverhead County, MT 面積 2,169,78 mi² 人口 7,963 人口密度スコア 4 予測性：郵便番号の事例 39 11354 59725 https://www.unitedstateszipcodes.org/59725/

? ? ? ? ? Allison Bojanski Ally Bojarski Allison Bojarski Alison Bojarski A L Bojarski ? 名前には何があるのか？ Q: 名前のデータしかなく、「 Allison Bojarski 」に似た名 前を持つ人物が他にいた場合、同一人物であるか特 定できますか？ A: NOです! © 2022 WARWICK MATTHEWS. ALL RIGHTS RESERVED. 40 予測性：名前のみ

Geekタイム：名前 X X ✓ ✓ ! Allison Bojanski Paul Ballew Ally Bojarski Caleb Bojarski Allison Bojarski Paul Ballew Joseph Ruggiero Alison Bojarski Joe Ruggiero A L Bojarski ? 隣接する名前も見てみるとどうでしょうか？ 一つの名前だけでは不十分でも、いくつかの共通で隣接する名前を 見ることでリンクが生まれます… © 2022 WARWICK MATTHEWS. ALL RIGHTS RESERVED. 41 名前には何かあるのか？ Q:名前のデータしかなく、「 Allison Bojarski 」に似た名 前を持つ人物が他にいた場合、同一人物であるか特 定できますか？

4. アジアの言語とIDR 課題とベストプラクティス

表意文字の一致に関する課題 全てのマッチングにおけるカギは「類似性」です。 日本 vs 豪州 EASY DIFFERENT 鈴木 vs 鐸木 DIFFICULT ??? 日本 vs ニッポン EASY SAME ローマ字 vs Romanji DIFFICULT ???

表意文字の一致に関するアプローチ 従来のIDRシステムの中には、日本語に不向きなものもあります： • レーベンシュタイン (編集距離) • ジャロウ・ウィンクラー / メタフォン （同音異義語多し） 代わりとして以下を使えます: • 画数 • カナベースの音声比較 – m:m 比較内臓で • 表音文字 （部首） • 意味論 効果的なイデオグラムマッチングは、アルファベットベースのマッチ ング（アルゴリズムに基づく傾向あり）よりも、辞書に基づくこと が多いです。 辞書はファジー検索をサポートすることができます： • 地域データ：道路、近隣地域、都道府県 • 名前：苗字、名前 • 種類：役職、業種

音訳 – 大きな課題 「日本」 • Japan • Nippon • Japon (🇫🇷) • Japón / Japona (🇪🇸) • Riben (transliteration from Chinese) 「和牛」 • “Wagyu Beef” （tautological) • “Japanese-style Beef” • 和牛ビーフ 「Chris」➔ 「 クリス 」 • Chris (男, 女) • Christopher (男) • Kris (男, 女) • Chrissy (女) • Christina (女) 「Matthews, Warwick」 • ワーウィック・マシューズ • ウオリック・マセウス • ワリク・マテウス ファーストネームは どっち？

グローバルデータ - ベストプラクティス • 全てをユニコードに • タイプを明示的に設定します！（UTF8 BOM 等） • ビジネスデータの受渡では、エクセルやノートパッドは避けましょう！ • 「受領した状態」で保存、マッチ (低摩擦 / データレイクハウスコンセプト） • 可能な限り辞書を整備する • データモデルが複数のバリアントを扱えるようにする • 優先的な名前、受領した名前、推定された名前等に分類 • 言語にとらわれない、またはアジア言語に最適化されたIDR/MDMシステムを 使用する • ベンダーにフィードバックについて確認 – Yes/Noだけではない • 実際に使用されるアルゴリズムについて確認 • Soundex ❌ • Levenshtein ❌ • Metaphone 🔶 • Fellegi-Sunter🔶 • 文字カウント🔶 • ローカルウェブサービス検索✅ ✅

APPENDICES Extra Slides Compliance Data Lab Making Compliance Closer

MEASURED ACCURACY MATCH SCORE Monotonic: Good MEASURED ACCURACY MATCH SCORE Multimodal: VERY VERY BAD What % of the time the matched answer is correct Confidence score returned by the system “Accuracy” in Identity Resolution.

MEASURED ACCURACY MATCH SCORE ① False negative ② False positive “Accuracy” in Identity Resolution (2) ① ②

0 25 50 75 100 COUNT SCORE Should quality be expected to fit a normal distribution (bell curve)? ? A B C D Quality Distribution in Matching

Indicia-level Scores Match Score “Right / Wrong” IDR Feedback Maturity Pyramid

Indicia-level Scores Match Score “YES / NO” IDR Feedback Maturity Pyramid Easy, Simplistic MATCH FEEDBACK:

Indicia-level Scores Match Score “YES / NO” IDR Feedback Maturity Pyramid MATCH FEEDBACK:

Indicia-level Scores Match Score “YES / NO” IDR Feedback Maturity Pyramid MATCH FEEDBACK:

IDR Feedback Maturity Pyramid Indicia-level Scores Match Score “YES / NO” Custom Rules MATCH FEEDBACK: Advanced, Powerful

Indicia-level Scores Match Score “YES / NO” IDR Feedback Maturity Pyramid Custom Rules Easy, Simplistic Advanced, Powerful MATCH FEEDBACK:

“Planetary Accretion Model” of Data Clustering.

Planetary accretion model of clustering. The indicia that we bring together to make a “person” ... …come together and generate their own kind of “gravity”, like a planet… SPOUSE NAME TITLE DOB ADDRESS ZIP PHONE WWW SOCIAL MEDIA EMAIL

Planetary accretion model of clustering. The more “mass” (indicia) the planet accretes, the bigger it gets… …and the bigger it gets the more mass it attracts…

Planetary accretion model of clustering. Eventually our “planet” gets so big (has so many indicia) that it can eat up just about anything (because anything will match to it). This is runaway accretion, and something we have to watch out for.

Thank You J D M C 2 0 2 3 年 0 5 月 2 6 日 Compliance Data Lab Making Compliance Closer 【お問合せ先】 コンプライアンス・データラボ株式会社 東京都千代田区丸の内3-2-2 丸の内二重橋ビル2F E-mail: info@c-datalab.com Tel: 03-6837-9665 Web: https://www.c-datalab.com