値からデータ構造を⽴ち上げる

■ イベント
golang.tokyo #44
https://golangtokyo.connpass.com/event/399472/

■登壇概要
タイトル：値からデータ構造を⽴ち上げる
登壇者：技術本部 CTO室 AI Solution Development グループ ⿑藤 拓⼰

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

1. Data Engineering Night 値からデータ構造を⽴ち上げる DWHからキーと参照構造を復元し、オントロジーの⾜場を作る Sansan株式会社 技術本部 CTO室 AI Solution Development グループ ⿑藤 拓⼰
2. 齊藤 拓己 （Takumi Saito） 技術本部 CTO室 AI Solution Development グループ 筑波⼤学⼤学院（博⼠: ⼯学） - 機械学習応⽤（進化アルゴ、深層学習が主） - 『Pythonではじめるオープンエンドな進化的アルゴリズム』 2025年4⽉より新卒⼊社 アナリティクスエンジニア / データエンジニア / AIエージェント開発 - Sansan AIエージェント開発 - 社内データ利活⽤
3. データ基盤への依頼対応は、知識のあるアナリストに依存している 依頼 ビジネスユーザー アナリスト データの 抽出‧集計 DWH（中央基盤） 1000↑ tables プロダクトA 業務システム B 業務システム C - 事業側から、集計‧抽出の依頼が継続的に発⽣ - データの知識は⼀部のアナリストに集中 > SQLが書けるだけでは⾜りない：どのデータ∕どうつなぐ∕何を表す - 依頼が増えても、対応能⼒を増やしにくい 3
4. AI に任せたいが、データの関係や意味を知らない - AI はテーブル定義を読める‧SQL を書ける - でも、それだけでは正しく使えない - 必要な 2 種類の知識：関係∕意味 - この 2 つを機械が使える形 ＝ オントロジー（本発表での扱い） 関係＋意味＝オントロジー（機械が扱える形） 関係 どのデータとどのデータが結びつくか 例 注⽂.customer_id → 顧客.id 意味 業務上、何を表すか 例 その customer_id ＝「発注した顧客」 4
5. 意味を正しく捉えるには、まずデータ同⼠の関係を明らかにする - 列名‧description から、個々のデータの意味は分かる - でも「どの customer が、どの product を契約しているか」は、それだけでは⾔えない - テーブルの「つながり」が⾒えて初めて、⼀つの事実になる customer 顧客 customer_id contract product_id 契約 product 商品 つながって初めて customer_A ─ contract_X ─ product_B 「顧客 A は 商品 B を契約している」 5
6. データの値から、関係候補を⾃動で⾒つける - データの値から⾃動で探索する > 関係の制約は値に反映されていて、網羅的 > 列名‧履歴に依存せず、未知の候補も > ⼈⼿で維持せず、変更に合わせて⾃動で再構築できる - 以下の⽅法は取らない > 知識を持つ⼈から集める > 既存の SQL から集める 6
7. 各列の値を調べ、関係探索の対象を絞り込む 列名を隠した「説明⽤の合成データ」。値だけから何が⾔えるか。 A B C D E 8F2K7M4Q1P9X Example Co. D01 Enterprise 2026-04-03 09:15 3N6R2V8C5L1T Sample Works D02 SMB 2026-04-03 10:02 7H4D9S2W6B3K Demo Labs D01 Enterprise 2026-04-04 13:22 5Q9T1A7M3K6P Example Sys. D03 Partner 2026-04-05 08:42 2C8V4N6R1X7L Sample Studio D02 SMB 2026-04-05 11:07 ① ⼀意性 〔A〕 A → distinct率：100 %、null率：0 % → 識別⼦らしい ② 値パターン 〔A‧C‧E〕 A → “[A-Z0-9]{12}”、C → “D\d{2}” → 値の⽂法が⾒える ③ 関数従属性 〔C→D〕 C = D01 → D = Enterprise → 属性の従属が⾒える → キー候補／従属する属性を見分け、探索の対象を絞る 7
8. キー候補の値を⽐較し、テーブル間の参照関係を⾒つける 構造プロフィール uniqueness / pattern / FD 包含の例 A.id = { K01, K02, K03, K04 } B.ref = { K01, K03, K04 } → B.ref ⊆ A.id （参照候補） キー候補を 中⼼に探索 値集合の包含 参照関係 全列ペアを闇雲にでなく、値から作ったプロフィールを⾜場に、 包含から参照候補を作る。 ※ 表記違い‧複数種類への参照など、実データ上の例外も別途考慮。 8
9. 実データ規模でも、関係候補を抽出‧整理できた 1ドメイン内の 数⼗のテーブル （1 億⾏超 / 数千列） 数⼗の関係グループ 数万の列関係候補 （同じキー空間を共有する列群） 関係グループの例 invoice.account_id order.owner_id task.assignee_id comment.author_id user.id 20 列が参照 contract.customer_id account.id 10 列が参照 ticket.company_id 9
10. 関係は構築できた。次は、業務上の意味を与えていく データの関係を構築 ‧使われている参照構造は復元できた ‧運⽤している dbt JOIN の⼤半と対応 ‧ただし、あくまでも関係の候補 ‧employee_count, amount, score などがグループ化 ‧値域が狭い数値列が偶然に包含してしまう → column 名や description で選別する必要がある Next：データの意味を構築 ‧関係グループから意味を実体化する ‧user.id を参照するグループ → 「⼈物」という業務実体 ‧業務上の意味はまだわからない ‧user.id を参照していても、 担当者 / 作成者 / 承認者 / etc. など関係性が不明 → LLM によって意味を構築する 10
11. まとめ：値から関係を構築し、そこから意味へ広げていく - AI が正しくデータを扱うには、データの関係と意味が必要 - まずは、値から関係候補を⾃動構築する⽅法を検証した > 実規模まで適⽤し、実際の JOIN と整合 - 次は、関係を使って意味を構築 - ⽬標：変化に追従できる、AI 利⽤可能なデータ知識 物理データ table / column / value 値からの証拠 構造層 keys / references / dependancies（値から） 意味づけ （LLM 等） 業務オントロジー entity / meaning / relation 11
12. Sansan 技術本部 採⽤情報 https://media.sansan-engineering.com/