見えない文脈を扱えるデータへ─ビジネスコンテキストを構造化するための第一歩 / Making Invisible Context Visible in Data

2026/08/19 開催の Data Engineering Night 〜Sansan ×MEDLEY が語るデータエンジニアのリアル〜 での登壇資料です。
登壇者 : 医療プラットフォーム本部 プラットフォーム開発室 データ戦略グループ 武永 拓
イベント URL : https://sansan.connpass.com/event/398213/

Transcript

1. 見えない文脈を 扱えるデータへ ビジネスコンテキストを構造化するための第一歩
2. 自己紹介 担当業務 • 複数医療プロダクトを展開する医療プラットフォーム本部を横断する組織として共通データ基盤／データモ デリングを担当 • 医療データをメインで扱う 最近の取り組み • データモデリング設計方針の策定 • dbtモデル実装方針の策定／自動化 武永 拓 関心のあるテーマ Taku Takenaga • データモデリング全般 株式会社メドレー • AI Readyなデータ基盤 医療プラットフォーム本部 プラットフォーム開発室 データ戦略グループ © 2026 MEDLEY, INC. 01
3. 今日話すこと • ビジネスコンテキスト(見えない文脈)とは？ • ビジネスコンテキストを構造化するための手法 © 2026 MEDLEY, INC. 02
4. 01 見えない文脈 AI Readyなデータ基盤に、今足りていないもの © 2026 MEDLEY, INC. 03
5. AI時代のデータは「スキーマ」だけではない AI時代はAIがより多くのデータにアクセスできる状態が理想。業務の解像度を上げるためビジネスコンテキストも必要になる。 システムが持つ文脈(スキーマ) AI ACCESSIBLE DWHやリポジトリに構造化された実体があり、AIが解釈しやすい 人が持つ文脈(ビジネスコンテキスト) NOT AS DATA Slackやドキュメントに実態はあるが、断片的な記述に埋もれてお り、AIにとっては解釈しづらい • テーブル／カラムの定義 • 業務上の概念定義 • データ型・制約 • 概念同士の意味的な繋がり • エンティティ間のリレーション • 同義語、別名 • 指標の集計ロジック • 「〜は含めない」という例外 • ドメイン知識、傾向や因果の勘所 © 2026 MEDLEY, INC. 04
6. ビジネスコンテキストは断片的な記述に埋もれている AIによる断片的な記述からビジネスコンテキストを正しく抽出できない。 ビジネスコンテキストの種類 ドキュメント上の断片的な記述 業務上の概念定義 最近利用しているユーザーをアクティブユーザーとしてカウントする 概念同士の意味的な繋がり 医療法人社団hogehoge会のhogehoge総合クリニックが〜 同義語・別名 hogehogeクリニックに商談中、fugafuga病院の打ち合わせも進行中 営業部: hogehoge病院が年間プランを契約し、今月売上120万(年間契約金額) 指標の集計ロジック ドメイン知識、傾向や因果の勘所 経理部: hogehoge病院の年間プランによる今月売上は10万(売上計上された金額) 先月は期末で数字が上振れた © 2026 MEDLEY, INC. 05
7. ビジネスコンテキストデータの必要性 ビジネスコンテキストデータを明確にし、人間・AIが正しく認識することによって、より実態に沿った分析が可能になる。 分析項目 システムデータだけで分析すると・・・ ビジネスコンテキストデータを加えると・・・ アクティブユーザー数の推移 アクティブユーザーの解釈が担当者ごとに変わた め、DAU/WAU/MAU等、結果が揺らぐ 1ヶ月以内にログインした人(MAU) = アクティブユー ザと定義することで結果が揺らがない。 契約法人数の集計 法人と医療機関の関係が抜けており、同一法人内 の医療機関を別カウントしてしまう 法人と医療機関の関係が定義されており、法人単 位で正しく束ねられる。 前月比での増減 期末の季節性による上振れを知らずに 「施策の効 果が出た」と誤った分析をしてしまう。 季節性が定義されており、季節性を考慮した 上で比較ができる。 FOR HUMAN FOR AI • 分析結果が担当者に依存しづらい • 専属のデータアナリストのような、より実態に沿った精緻な集計 / 分 • 確認や手戻りが減り、実装・レビューの工数も下がる 析が可能になる • 探索と試行のやり直しが減り、トークン使用量と実行時間も抑えられ る © 2026 MEDLEY, INC. 06
8. 02 概念設計 ビジネスコンテキストを構造化するための、第一歩 © 2026 MEDLEY, INC. 07
9. 概念設計とは 分析ごとに下記内容についてデータエンジニアとビジネス担当者でビジネス目線で整理する。 目的を整理する 対象業務を構造化する どのように分析したいかを決める 1. 分析依頼・目的 依頼元、主な利用者 、何を分析したい か、想定成果物、利用頻度等を整理 する。 分析結果をどのように扱い、何を判断 したいのかを明確にする。 2. 業務の流れ・出来事 いつ何が起き、何が変わるか 6. 分析要件 指標、集計単位、分析軸 3. 業務概念の定義 ヒト／モノ／コトの定義、1件として数える単位 、種別、状態遷移・Tips 7. 時間・履歴・鮮度 履歴管理、対象期間、更新頻度 4. 業務概念同士のつながり 双方向の関係性、必ず1件／0〜1件／0件以上 8. 取り扱い注意 個人情報などの制限 5. 集計上の決まり フィルタ条件、計算ルール、値の制約 データエンジニア 対象業務についてヒアリングし、関連する業務概念を整理 する ⇄ ビジネス担当者 壁打ち 実務と照らし合わせながら回答する © 2026 MEDLEY, INC. 08
10. 例: 「診療予約」の構造化 業務の流れ・出来事 業務概念の状態遷移 対面診療予約 医療機関を → 検索する オンライン 診療予約 → キャンセル する → 予約数を 集計する 概念名 種類 1件として数える単位 予約 コト 患者が申し込んだ予約1件 医療機関 モノ 医療機関1施設 医療法人 モノ 医療法人1件 ヒト 状態の流れ 状態が変わる条件 予約 予約 → キャンセル 業務概念同士のつながり 業務概念の定義 患者 業務概念 患者1人 A つながり (A→B／B→A) B AあたりのB の件数 B あたりのA の件数 医療法人 運営する／運営 される 医療機関 1件以上 0〜1件 医療機関 受け付ける／受 け付けられる 予約 0件以上 必ず1件 患者 申し込む／申し 込まれる 予約 0件以上 必ず1件 業務概念の種別 集計時の決まり 業務概念 種別 種別 決まり 理由 予約 対面診療予約、オンライン診療予約 計算ルール 予約キャンセルは考慮しない 患者 アプリユーザー、Webユーザー 集客施策以外の要因を取 り除くため © 2026 MEDLEY, INC. 09
11. 概念設計は実装の手戻りを減らす 概念設計を通し、対象業務の解像度を上げることで、実装の手戻りも減る。 STEP 01 STEP 02 STEP 03 概念設計 論理設計 実装 業務を構造化し、解像度を上げる データモデル構成に落とし込む データモデルを実装する • 出来事とヒト／モノ／コト • エンティティ、粒度、キー • dbtモデルごとの設計と実装 • 1件として数える単位 • 参照仕様、カーディナリティ • 設計を基準にした評価 • 種別、状態の遷移 → • 変換、導出仕様、履歴管理 • つながりと業務上の決まり • メジャー仕様、BI集計利用仕様 • 見たい指標と計算式 • レイヤー別のdbtモデル構成案 → (staging/intermediate/mart) © 2026 MEDLEY, INC. 10
12. Context Layerサービスの限界 Context Layerサービスによるコンテキスト収集は万能ではない。 Context Layerサービスとは データ、メタデータ、クエリ・ドキュメント等の業務資産やその利用状況から、AIがビジネスコンテキストを自動的に抽出し、継続的に更新し てくれる神サービス。 • AWS Context • Databricks Genie Ontology Context Layerサービスによる収集の限界 メタデータ、クエリ履歴、利用状況、ドキュメントからAIが自動収集しても組織固有のビジネスコンテキストを網羅的・体系的に捉えること ができない。 • 言語化・記録されていないコンテキストは取得できない • 断片的な情報から収集するため関連コンテキストが拾えず、コンテキスト同士の関係が不完全になりやすい • AIによる補完では、組織固有の暗黙知や判断基準が抜け落ちる可能性がある © 2026 MEDLEY, INC. 11
13. まとめ AI Readyなデータ基盤にはビジネスコンテキストが必要 業務概念の定義・種別・状態遷移、同義語、集計ロジック、季節性といったビジネスコンテキストまで揃って、人もAIもはじめて業務の実態と 一致した精緻な分析ができる。 しかし、ビジネスコンテキストは各所に断片的な形で埋もれている。 概念設計でビジネスコンテキストを掘り起こし、構造化する ビジネス担当者と壁打ちしながら、ビジネスコンテキストを掘り起こし、構造化する。 概念設計を通して対象業務の解像度を深めることで、実装の手戻りも減り、一石二鳥。 Context Layerサービスは銀の弾丸ではない Context Layerサービスを使って収集できるビジネスコンテキストには限度がある。 ビジネスコンテキストの掘り起こしと構造化はデータエンジニアの使命であり、今後データエンジニアが注力すべき業務。 © 2026 MEDLEY, INC. 12