Data Engineering Summit AI時代のデータ基盤における メタデータの重要性と AI Agentについて

1. AI時代のデータ基盤における メタデータの重要性と AI Agentについて © 2025 Techtouch, Inc.
2. © 2023 Techtouch. confidential 2 自己紹介 名前: まえはらたける 社内ではtaker(ていかー）などと呼ばれています 所属： テックタッチ株式会社 DataEnablingチーム マネージャー これまでの経歴 : PureData → Redshift → Bigquery・Redshift・TreasureData→Snowflake ８年間でいろんな DWHを使ってきました。懐かしい。
3. © 2023 Techtouch. confidential テックタッチ株式会社 設立 2018年3月1日 住所 〒105-7105 東京都港区東新橋1-5-2 汐留シティセンター5階 ワークスタイリング内 従業員数 1２3名（2024年8月時点）※正社員のみ 累計資金調達額 24億円 投資家 DNX Ventures アーキタイプベンチャーズ株式会社 DBJキャピタル株式会社 三菱UFJキャピタル株式会社 SMBCベンチャーキャピタル株式会社 みずほキャピタル株式会社 その他 受賞歴 週刊東洋経済「すごいベンチャー100」選出（2020年） 日本DX大賞支援機関部門 ファイナリスト選出（2022年） グッドデザイン賞 受賞（2022年度） SAP AWARD OF EXCELLENCE2023 Partner Innovationアワード 受賞（2023年） 経済産業省「J-Startup」選出（2023年） など 認証 3
4. © 2023 Techtouch. confidential テックタッチで、ノーコードで画面上でのナビゲーション表示が可能に。 テックタッチ導入前 テックタッチ導入後 4 プログラミング不要なので、非エンジニアが直接UXの改善に取り組めます。
5. © 2023 Techtouch. confidential 5 テックタッチの事業概要 導入した業務システムや、自社で開発したwebアプリケーション にテックタッチを導入できます。 システム利用者の「わからない」を画面上で解決できるため、マ ニュアルを見なおす時間や、入力不備、問い合わせ件数、差し戻 し件数が削減できます。 情報量が多く複雑になりがちな行政システムを、直感的に使え るようにします。 開発したシステムの操作案内としてテックタッチを導入すれば、 チュートリアルの仕組みを実装する必要がありません。問い合わ せ削減や解約防止、UI/UX向上に繋げることができます。 DX支援 （社員向け） CX支援 （顧客向け） 大企業社内 
 システム提供者 
 公的セクター 

6. © Techtouch, Inc. confidential 導入企業一覧 6
7. © Techtouch, Inc. confidential 7 フロント開発と切り離した UIUX調整が可能となります。 弊社での活用例（よくある質問やおすすめ情報をCSやデザイナーが直接画面上に実装、リリース）
8. はじめに - 様々な分野におけるAIの活用は非常に進んでいるかと思います。 - データ基盤・データ活用のあらゆるシーンにおいても、 皆様においても様々な活用がなされているかと思います。 - 弊社がどのようなことを行っているか、 なるべく具体的 にお話し、なにか持ち帰っていただければ幸いです。
9. アジェンダ 本日お話しする内容 • 「データ基盤の開発」・「データの活用」にAI活用するための課題と最初の壁 • AI活用のための、メタデータ整備と次の壁 • データ活用を促進するためのAI Agentの開発 • 今後の課題 © 2025 Techtouch, Inc. 2
10. 「データ基盤の開発」・「データの活用」に AI活用するための課題と最初の壁
11. テックタッチのデータ基盤 Snowflakeを中心とし、 dbtでモデリングを行うデータ基盤
12. テックタッチのデータ マスターデータ • 「表現力が非常に高い」プロダクトのマスター ◦ 半構造で格納/高度に正規化 ◦ 機能の利用・設定を示すカラムが点在 →機能とデータの対応関係が複雑になる 利用データ • 各種機能の利用を示すログデータ ◦ Google Analyticsなどのサービスの データを想像いただくのがわかりやすい • 歴史的経緯でマスターデータとの ひも付きが複雑 • 1つの指標をだすのにも明瞭なロジックではない ◦ 機能・設定が複雑であれば、指標も複雑
13. テックタッチのデータ マスターデータ • 「表現力が非常に高い」プロダクトのマスター ◦ 半構造データ・高度に正規化 ◦ 機能の利用・設定を示すカラムが点在 利用データ • 似たような指標が多すぎる問題 • (例: 再生数/能動再生数/自動再生数…) • ドキュメントを読み込ませても、正しい定義 のデータを作れない • 意図しないカラムを利用されてしまう とある機能の設定 対応するデータ(一部） 対応するデータ(一部）
14. テックタッチの利用ユーザーとユースケース カスタマーサクセス(CS) • 日々のCS活動を効率よく実行するための、 ダッシュボード（利用データ） • 各種設定項目を確認・チェックするためのツール (マスターデータ） • テックタッチの効果を顧客にFBするための分析 （利用データ） プロダクトチーム • 機能の利用状況からアウトカム・改善の検討 (マスター・利用データ） • 障害対応時の影響範囲の特定・推測 （マスター・利用データ）
15. テックタッチの利用ユーザーとユースケース カスタマーサクセス(CS) • 日々のCS活動を効率よく実行するための、 ダッシュボード（利用データ） • 各種設定項目を確認・チェックするためのツール (マスターデータ） • テックタッチの効果を顧客にFBするための分析 （利用データ） プロダクトチーム • 機能の利用状況からアウトカム・改善の検討 (マスター・利用データ） • 障害対応時の影響範囲の特定・推測 （マスター・利用データ） CS活動・プロダクト開発/運用において、 欠かすことが出来ない重要なデータ基盤
16. データ基盤における2つの側面と課題 一方で弊社のデータ基盤には、開発・利用のそれぞれに課題がありました 開発上の課題 • パイプラインが横・縦に肥大化 ◦ 指標の改修で、どのモデルを 直すべきなのか特定が大変 ◦ オンボーディングコスト ◦ レビューコスト 利用上の課題 • チーム外のメンバーが自走してデータを 取得できない ◦ わからないだらけ ▪ 指標をどのように作ればいいのか ▪ どのようにSQLを書けば良いのか © 2025 Techtouch, Inc. 4
17. データ基盤における2つの側面と課題 一方で弊社のデータ基盤には、開発・利用のそれぞれに課題がありました 開発上の課題 • パイプラインが横・縦に肥大化 ◦ 指標の改修で、どのモデルを 直すべきなのか特定が大変 ◦ オンボーディングコスト ◦ レビューコスト 利用上の課題 • チーム外のメンバーが自走してデータを 取得できない ◦ わからないだらけ ▪ 指標をどのように作ればいいのか ▪ どのようにSQLを書けば良いのか © 2025 Techtouch, Inc. 4
18. データ基盤における2つの側面と課題 一方で弊社のデータ基盤には、開発・利用のそれぞれに課題がありました 開発上の課題 • パイプラインが横・縦に肥大化 ◦ 指標の改修で、どのモデルを 直すべきなのか特定が大変 ◦ オンボーディングコスト ◦ レビューコスト 利用上の課題 • チーム外のメンバーが自走してデータを 取得できない ◦ わからないだらけ ▪ 指標をどのように作ればいいのか ▪ どのようにSQLを書けば良いのか © 2025 Techtouch, Inc. 4 モデルリネージュ
19. データ基盤における2つの側面と課題 一方で弊社のデータ基盤には、開発・利用のそれぞれに課題がありました 開発上の課題 • パイプラインが横・縦に肥大化 ◦ 指標の改修で、どのモデルを 直すべきなのか特定が大変 ◦ オンボーディングコスト ◦ レビューコスト 利用上の課題 • チーム外のメンバーが自走してデータを 取得できない ◦ わからないだらけ ▪ 指標をどのように作ればいいのか ▪ どのようにSQLを書けば良いのか © 2025 Techtouch, Inc. 4 モデル数
20. データ基盤における2つの側面と課題 一方で弊社のデータ基盤には、開発・利用のそれぞれに課題がありました 開発上の課題 • パイプラインが横・縦に肥大化 ◦ 指標の改修で、どのモデルを 直すべきなのか特定が大変 ◦ オンボーディングコスト ◦ レビューコスト 利用上の課題 • チーム外のメンバーが自走してデータを 取得できない ◦ わからないだらけ ▪ 指標をどのように作ればいいのか ▪ どのようにSQLを書けば良いのか © 2025 Techtouch, Inc. 4 1. factモデルのPVの定義をいじりたい 2. factモデルでは集計していない 3. 依存してるintモデルAを見る 4. intモデルAでもない …. 5. intモデルCだった こんなことがよく起きていた
21. データ基盤における2つの側面と課題 一方で弊社のデータ基盤には、開発・利用のそれぞれに課題がありました 開発上の課題 • パイプラインが横・縦に肥大化 ◦ 指標の改修で、どのモデルを 直すべきなのか特定が大変 ◦ オンボーディングコスト ◦ レビューコスト 利用上の課題 • チーム外のメンバーが自走してデータを 取得できない ◦ わからないだらけ ▪ 指標をどのように作ればいいのか ▪ どのようにSQLを書けば良いのか © 2025 Techtouch, Inc. 4
22. データ基盤における2つの側面と課題 一方で弊社のデータ基盤には、開発・利用のそれぞれに課題がありました 開発上の課題 • パイプラインが横・縦に肥大化 ◦ 指標の改修で、どのモデルを 直すべきなのか特定が大変 ◦ オンボーディングコスト ◦ レビューコスト 利用上の課題 • チーム外のメンバーが自走してデータを 取得できない ◦ わからないだらけ ▪ 指標をどのように作ればいいのか ▪ どのようにSQLを書けば良いのか © 2025 Techtouch, Inc. 4 カタログ(dbt docs) ある指標を検索しても様々な粒度のモデルが存在する
23. データ基盤における2つの側面と課題 一方で弊社のデータ基盤には、開発・利用のそれぞれに課題がありました 開発上の課題 • パイプラインが横・縦に肥大化 ◦ 指標の改修で、どのモデルを 直すべきなのか特定が大変 ◦ オンボーディングコスト ◦ レビューコスト 利用上の課題 • チーム外のメンバーが自走してデータを 取得できない ◦ わからないだらけ ▪ 指標をどのように作ればいいのか ▪ どのようにSQLを書けば良いのか © 2025 Techtouch, Inc. 4 また、そもそもSQLを書く、ということもむずかしい
24. Coding Agentの登場！！ テーブル定義・descriptionをAgentに食わせれば、 全部解決するのでは！！？？
25. AI使ってみた・・・が・・・・ Coding Agent（Devin, Claude等）の登場で期待したが、使える状態にならなかった 開発課題への適用と問題点 • 人が苦労するものはAIも苦労する • 人はリネージュのUIを見れるが、 　AIには難しい →遡るためには逐一モデルを遡る必要 各モデルを遡るうちに、 Contextが枯渇 利用課題への適用と問題点 • 似たような指標が多すぎる問題 　(例: 再生数/能動再生数/自動再生数…) • ドキュメントを読み込ませても、正しい定義 のデータを作れない 　・指標の集計定義はすべてSQLに言語化も ふわっと • 意図しないカラムを利用されてしまう © 2025 Techtouch, Inc. 7
26. 当時のメタデータ © 2025 Techtouch, Inc. 7 「ドメイン」と「データ構造」がある程度分かる人向け
27. 開発課題への適用と問題点 どんなコンテキストが足りなかったのか？ - モデルを参照するための 効率的な道しるべ=リネージュ - 各カラムがどこでなにと 集計されているのか →カラムレベルリネージュ 利用課題への適用と問題点 - 利用するためのメタデータ - 結合関係 - 指標の集計定義 - フィルタの定義 - データのシノニム →セマンティックレイヤー 自分たちが抱える問題は、先人がすでに解決方法を提示している 「AIだから必要」なものではなかった
28. AI活用のための、メタデータ整備と次の壁
29. 方向性 © 2025 Techtouch, Inc. 10 • カラムリネージュにしろセマンティックレイヤにしろ、様々なOSS・SaaSがある ◦ カラムリーネージュ ▪ dbt Fusion engine ▪ Dagster ▪ OpenMetadata ◦ セマンティックレイヤ ▪ dbt Semantic Layer ▪ Cube • これらの導入は行わなかった ◦ 私達がほしいのはコンテキストにするための「情報」だけであった ◦ 「情報」を取得・管理するために上記を運用・維持するのはコストメリットに合わないし、 AIが読み取るにはテキストデータが最適とも考えていた。 →特別ななにか入れずに、テキストベースのメタデータを整えていく方向性に
30. メタデータ整備の3原則 メタデータを整備すると決めたが、以下の原則をチームで合意した 1. 二重管理は絶対にしない dbtをモデリングに利用しているため、dbt docsをメタデータにおけるSSoTとして扱う 2. 運用負荷をかけない 負荷が高いと、様々な理由で付与・更新されない。原則として、自動で更新できる仕組みを構築。 © 2025 Techtouch, Inc. 10
31. 整備した3種類のメタデータ 「開発」と「利用」それぞれの課題に対応 Column Lineage カラムレベルのリネージュ情報 【用途: 開発】 Relationship テーブル間の結合（外部キー） 情報 【用途: 開発・利用】 Semantic モデルの「使い方」の定義情報 【用途: 利用】 © 2025 Techtouch, Inc. 11
32. Column Lineage 「dbt manifest」と「sqlglot」の組み合わせ 概要 • dbtのmetadataとして、該当カラムがどこで 加工・集計されたのかを付与 • dbt docsを見るだけで、カラムの加工元モデ ルに即座にジャンプ可能に ・sqlglotのLineage APIと、 　manifest.jsonと併用し、metadataを 自動構築 © 2025 Techtouch, Inc. 12
33. 構築手法: Column Level Lineage 「dbt manifest」と「sqlglot」の組み合わせ 概要 • dbtのmetadataとして、該当カラムがどこで 加工・集計されたのかを付与 • dbt docsを見るだけで、カラムの加工元モデ ルに即座にジャンプ可能に © 2025 Techtouch, Inc. 12 metadataの詳細 - 加工がない場合 - 該当カラムが生成された モデル名を明示 →ジャンプすれば定義がわかる - 加工がある場合 - 利用されたモデルと カラムが明示 開発時もレビュー時に非常に有用 かつ AIフレンドリーなmetadata
34. Relationship 特別なものはないです。 概要 • テーブル間の結合情報 - 基本は外部キー制約を利用している ・ いくつか問題があった 1. 外部キー制約が貼られていない問題 2. relationがdatabaseをまたぐ問題(microservice) 3. 利用データ(streaming data)は直接Snowflakeに 取り込まれる →ルールベースとマニュアル定義により自動付与 © 2025 Techtouch, Inc. 13
35. Semantic 他のメタデータとは異なり、定義自体は手で作る。 手動で作るが、なるべく工数をかけずに運用する。 概要 • モデルの「使い方」の定義（マート層のみ） - 「filter, fact, dimension」を定義 • ルールベースのtemplateを用意 - 例: XXXカラムがあればfilter YYY を追加 ・ マッチすれば、マートのmetadataに適用 © 2025 Techtouch, Inc. 13
36. 構築手法: Semantic 他のメタデータとは異なり、定義自体は手動で作る。 手動で作るが、なるべく工数をかけずに運用を可能。 概要 • モデルの「使い方」の定義（マート層のみ） - 「filter, fact, dimension」を定義 • ルールベースのtemplateを用意 - 例: XXXカラムがあればfilter YYY を追加 ・ マッチすれば、マートのmetadataに適用 © 2025 Techtouch, Inc. 13 metadataの詳細 - モデルのどのカラムをどのように 使うのかを明示 - dimensions - facts - カラムを組み合わせて 利用可能な指標を定義 - filters - カラムを組み合わせて 利用可能なフィルタを定義 (Snowflake Cortex Analystにほぼ準拠）
37. Semantic 他のメタデータとは異なり、定義自体は手で作る。 手動で作るが、なるべく工数をかけずに運用する。 概要 • モデルの「使い方」の定義（マート層のみ） - 「filter, fact, dimension」を定義 • ルールベースのtemplateを用意 - 例: XXXカラムがあればfilter YYY を追加 ・ マッチすれば、マートのmetadataに適用 © 2025 Techtouch, Inc. 13 templateのイメージ
38. 開発・利用に必要なメタデータは作った どうなった？
39. メタデータ追加後の変化 開発面は大きく改善したが、利用面にはまだ課題が残った 開発面 利用面 課題解決度 ◎ 大幅改善 △ まだ難しい 所感 リネージュをエディタ上で即座に確認 Agentが読み込むモデルもスキップでき、 大きなメリットがあった SQLをかける人であれば、自走できる また、適切な指示を与えればAIがSQLを 作ることも一定できた 適切な指示を与えることが出来れば・・・ © 2025 Techtouch, Inc. 15
40. なぜ利用面の課題は解決しなかったのか？ 1. 暗黙的な要件 2. ユーザーの誤り・曖昧さ 3. 既存のデータ資産の軽視 © 2025 Techtouch, Inc. 16
41. 暗黙的な要件 • 何かのデータをみたいときには多くの当たり前と認識していることがある ◦ 「契約中だけに絞る」 ◦ 「削除されているものは除外する」 • この当たり前はデータの誤りに直結する一方で「AI」側からの確認はなかなか難しい ◦ 当然ユーザー側からすれば当たり前となっているので、明示はしない • これまではデータチームが依頼を受けたときにいい感じにコミュニケーションを取っていた部分 © 2025 Techtouch, Inc. 18
42. ユーザーの誤り・曖昧さ • 特定の顧客のデータが欲しい時に基盤が持つ値と一致しない ◦ 例えば ▪ 基盤の値：XXX株式会社 ▪ ユーザー指定：XXX/XXX社 ◦ 一致しないので当然データは引けない ▪ 顧客名が間違っているとはユーザーは思っていない • 指標名についても ◦ XXX社の利用数を知りたい ▪ 利用数とは？ • PV数？セッション数？UU数？ © 2025 Techtouch, Inc. 18
43. 既存のデータ資産の軽視 • 恥ずかしい話だが、すべてAIでデータ活用を完結させようとしてしまった ◦ ユーザーからするとどっちでも良い話 ▪ 既存のもので解決できるのであれば、そちらで高速に解決 • 既存の資産は品質も担保されている ▪ できないものはAIと一緒に解決する © 2025 Techtouch, Inc. 18
44. AI Agentの構築
45. 方向性 • 当たり前の話だが、ユーザーの真に求めるデータをしっかり聞き出し、要件を確定させるプロセスが 必要だった • データにメタデータがあるように、ユーザーの問い合わせにもメタデータ（背景・目的）があり、その双 方が必要 • 依頼を受ける中で自然と行っていた「要件の言語化」をAI Agentに組み込むことにした ・かつ、既存のデータ資産や・ナレッジについても併用する © 2025 Techtouch, Inc. 18
46. AI Agentの全体像 © 2025 Techtouch, Inc. 19 - マルチエージェントな構成 - ナレッジエージェント - 過去の問い合わせに応じてQAする - データ資産で答えられる場合は そのレポート・ダッシュボードを共有 - データ抽出エージェント - ユーザーの任意のデータを最終的に SQLを作成し、抽出する
47. 全体の構成図 © 2025 Techtouch, Inc. 19 やり取りのI/FはSlack SlackからEvent Subscription でLambdaに Session管理にDynamoDB AI AgentはAgent Engineで hosting MCP Serverを通じて、 Snowflakeにアクセス SQL生成はCortex Analystに任せる
48. ナレッジエージェントの構成 © 2025 Techtouch, Inc. 19 confidential - シンプルなエージェント構成 - 1つのエージェントが、 QA集やレポートのカタログに問い合わせを 行い、ユーザーとやり取りする - データベースとは書いているが、 実態はテキストファイルです - 将来的にはRAGっぽくなるかも？ - いまはこれで十分
49. ナレッジエージェントの構成 © 2025 Techtouch, Inc. 19 confidential このように過去あった問い合わせからの回答をテキ ストファイルに固めているだけ github管理で、都度都度更新していく
50. ナレッジエージェントの構成 © 2025 Techtouch, Inc. 19 confidential - レポートの管理・運用・開発を行いやすいよう に、メタデータの管理を「たまたま」していた - この情報をそのまま流用 - dbt exposureとして管理
51. ナレッジエージェントの構成 © 2025 Techtouch, Inc. 19 confidential 上記のような概要に加えて、 可視化しているカラムをカタログとしてもつ
52. 実際の応答
53. データ抽出エージェントの構成 © 2025 Techtouch, Inc. 19 - 基本的には1つのエージェントには 1つの仕事だけ行わせる(ツール化） - 各エージェントツールには、 個別にツールを連携 - オーケストレーションエージェントに 直接各種ツールを連携すると安定しなかった ため、この構成に落ち着いた
54. データ抽出エージェントの構成 © 2025 Techtouch, Inc. 19 - ユーザーの最初の要望はSQLに落とすには 不十分なことが多い - 例えば - 期間の指定がない - 必要な条件がわかっていない - 通常適用する条件はどうす る？とか聞く - ここらへんをやり取りで深ぼっていく
55. データ抽出エージェントの構成 © 2025 Techtouch, Inc. 19 - ユーザーの指定した条件などは 不正確なことが多い - 様々な名前 - 略されていたり 通称がはいっていたり - データベースの値と一致していな かったり これらをデータベースとやりとりし、正しい値に
56. データ抽出エージェントの構成 © 2025 Techtouch, Inc. 19 - どのマートでどのデータが取れるのか - 1つの問い合わせで、複数のマートを組 み合わせる必要があることがおおい - 粒度があっていないとか - どのデータがどのモデルを使えばいいの かを特定する - 取れない項目、項目の認識齟齬が ないかを確認
57. データ抽出エージェントの構成 © 2025 Techtouch, Inc. 19 - Cortex Analystを利用し、クエリを生成 - ここで利用するSemantic Modelは 前述したメタデータより自動生成する
58. データ抽出エージェントの構成 © 2025 Techtouch, Inc. 19 - Cortex Analystは意外とクエリを間違える - 期間フィルタを忘れたり (めちゃくちゃ多いです） - データの粒度を間違えたり - レビューを行い、ユーザーの意図と違う箇所が ないかを検出 - もしあれば、ユーザーに確認
59. 実際の応答
60. まとめ
61. まとめ ・メタデータはデータの利活用という側面に焦点が当たりがちだが、開発者体験の向上にも寄与する • 一度付与するだけではなく、アップデートをし続ける必要があり、それを踏まえた仕組み化の重要性 • ただし、メタデータがあるだけでは活用できるとまではいえず、そこからさらに踏み込む必要があった © 2025 Techtouch, Inc. 21
62. 今後の課題 ・AIエージェントの課題 - ユーザーからの声として - AIが出力した結果が正しいかわからない（漠然とした不安） - 一次ソースの併記など - AIが提示した情報をすべて読まず、エイヤで進めてしまう - その結果、誤ったデータとなる - やりとりが一回一回長い - 「正しいデータを出す」ことに重きをおいているため仕方ない - 一方でラフに雰囲気でやり取りをするというニーズもあることはわかった - 開発側として思うこと - エージェントの改善を常にし続ける必要性 - ユーザーとのやり取りをどのように改善に組み込むか - また、どのように精度などをモニタリングし続けるのか © 2025 Techtouch, Inc. 22