[みん強]AIの価値を最大化するデータ基盤戦略：Self-Service型Data Meshへの転換とAgentic AI Meshに向けた取り組み with Snowflake他

https://datatech-jp.connpass.com/event/386874/
で利用させていただいた資料（公開用版）です

Transcript

1. AIの価値を最⼤化するデータ基盤戦略： Self-Service型Data Meshへの転換と Agentic AI Meshに向けた取り組み with Snowflake他
2. Business Profile 松原 侑哉 Matsubara Yuya 株式会社NTTドコモ R&Dイノベーション本部 サービスイノベーション部ビッグデータ基盤 兼 ネットワーク本部 ネットワーク部技術企画部⾨ Principal Data Engineer 2 社外：OSS・SaaSコミュニティの運営 他
3. Executive Summary • ネットワーク領域を中⼼とするデータ基盤 を従来の中央集権的なData Warehouseから ⾮中央集権的なData Mesh構成へと変⾰ 中央集権型から⾃律分散型への変⾰ Data Mesh＆Data Product Agentic AI時代を⾒据えた準備 Agentic AI Mesh • 既存のData Managementの課題を踏まえた AI AgentをData Productとして管理 中央集権では 流通していなかったデータの流通 • ツール/成果物の分析結果データ • ビジネスメタデータが揃った⾼品質な データ etc. データ活⽤意識の向上/意識改⾰ • データへの責任感 • ⼀⼈⼀⼈のデータの価値の再確認 etc. 次世代/AIによるデータ活⽤への ⼟台構築 3
4. On-premises Public Cloud Multi Cloud SaaS • Netezza ・ Greenplumを社 屋内に構築 • 保守運⽤を社員 が実施 • Amazon Web Serviceを採⽤ • AWS Redshiftを Data Warehouse として導⼊ コンシューマ通信関連 • Google Cloudを 追加で採⽤ • Google Cloud BigQueryを Redshiftと並⾏し て利⽤する形で 導⼊ スマートライフ・法⼈関連 データ流通・分析基盤 各種規制・法律に対応するため、社内には代表的なデータ基盤が２つ存在 双⽅ともSnowflake ⼗数PBクラスのデータと計数万弱のテーブル/ビューを提供 共有 • Snowflakeを 採⽤ • AWS RedshiftとGC BigQueryの利⽤を 停⽌ • Databricksをデー タ処理領域に採⽤ 2014 2020 2024 データ SaaSの活⽤ Snowflakeを中⼼とし 数千のテーブル/ビューを提供 ※規制・法律により流通 データを制限 4
5. Data Catalog Data Marketplace Governance 中央集権型 Data Warehouse SaaS導⼊当初は引き続き 中央集権型のData Warehouse及び中央運⽤チームによる データ処理・提供を実施 データの増加・データ活⽤の増加が続く 5
6. 中央集権型の基盤ではデータを⽣成する事業部⾨とデータを処理する中央チーム、 そしてデータを利⽤する部⾨が分断されており データを⽣成する側はデータ品質に対する責任感（オーナーシップ）が⽋如しがちである 中央チームは全社からの依頼を抱えるためバックログが膨れ上がり、 中央チームそのものが組織のボトルネックとなる 往々にしてデータ品質やデータ活⽤速度低下の責任を負うのは中央チームである 中央集権の限界 データを⽣成する側は 「基盤にデータを流し込めば終わり」と考え、 そのデータの使い勝⼿（データ形式 / メタデータ整 備他 ）を疎かになり、中央チームはそのデータの クレンジングに時間を浪費 データのオーナーシップの不在と データ品質の低下 ビジネスコンテキストの喪失 組織的なボトルネックと アジリティの低下 新しいデータ分析の要件や AIモデルの構築が必要になった際、 すべてのリクエストが中央チームに集中し、 データチームそのものが組織のボトルネック化 中央チームはデータのドメイン知識を保有してお らず、ドメインに適したデータ処理が困難であり、 結果提供されるデータは どの部⾨にとっても使い勝⼿の悪いデータに 6 AI活⽤において 死活問題
7. ⾃律分散型 Data Mesh Open Table Format ・ Signed URL 形式に制限なく流通 • 構造化データ • 半構造化データ • ⾮構造化データ • セマンティックモデル • ベクトル • AI/MLモデル etc. アクセス権の流通 データのコピーによるストレージ コストの増加や Unload/Loadによるデータ鮮度の 低下を防⽌ Domain Data Catalog Data Marketplace Governance 7
8. 8 Domain Project Team Data Product Listing Listing Access External Iceberg Table from Snowflake Domain Domain External Env, Service ⾃律分散型 Data Mesh
9. 中央集権型 ⾃律分散型 Domain Data Catalog Data Marketplace Governance Data Catalog Data Marketplace Governance Ownership 1 2 3 Data Product Self-Service 責任の明確化：データを⽣み出したDomainが データの品質・管理・監督に責任を持つ 品質の担保とパッケージ化：カタログと保証・問 い合わせの窓⼝がセットとした製品としてデータ を取り扱う 相互流通：データオーナー⾃らがデータを Marketplaceに出品する データのオーナーシップの不在と データ品質の低下 組織的なボトルネックとアジリ ティの低下 ビジネスコンテキストの喪失 9
10. Marketplace流通: カタログ経由で「アクセス権」を流通。 非移動共有: データの物理コピーを最小化し、鮮度を維持。 ⾃律分散型 Domain Data Catalog Data Marketplace Governance Ownership 1 2 3 Data Product Self-Service 責任の明確化：データを⽣み出したDomainが データの品質・管理・監督に責任を持つ 品質の担保とパッケージ化：カタログと保証・問 い合わせの窓⼝がセットとした製品としてデータ を取り扱う 相互流通：データオーナー⾃らがデータを Marketplaceに出品する データの移動がないデータ活⽤ アクセス権の流通 データのコピーによるストレージコストの増加や Unload/Loadによるデータ鮮度の低下を防⽌ 結果の再出品による知⾒の統合 分析結果の再流通 分析結果が再びData ProductとしてMesh上に再 出品されることで、 組織を跨いだ知⾒の統合を実現 10
11. 11 ドキュメント 他データ情報 function 各種情報をテーブル化 カタログ情報 生成AIによるメタデータの出力 結果の確認・修正 + 評価 データ利用者 メタデータの確認・評価 カタログ評価 生成AI評価 生成結果の評価を取り入れることにより • 不足ドキュメントの追加 など継続的にアップデート可能 データ利用者目線で理解しづらい メタデータの判別が可能 Data Owner メタデータの強化 データ利⽤者が、流通するデータに関しては利⽤者ならではの知⾒を保有している それらの情報も共有・流通するため、利⽤者がメタデータを提案できる仕組みも整備
12. Center Of Excellence データが「組織全体で繋がる（相互運⽤性）」こと「安全である（信頼性）」ことを保証するための「共 通ルール（規約）」を策定し、その規約にデータオーナーが準拠しているか監督を実施 • 相互運⽤性と標準化 • ルールの統⼀： ⽇付、単位、命名規則など書式の統⼀ • 共通IDの設計： ドメイン横断でデータを結合するための共通IDの設 計 • ⾔葉の定義の統⼀： 部署間での⽤語定義の統⼀と解釈不⼀致の防⽌ • データプロダクトの品質と信頼性 • 品質の監視（SLO）： 更新頻度や⽋損率など、データ品質の継続的 な監視 • 窓⼝とマニュアル： 問合わせ窓⼝の明確化と最新ドキュメントの維 持 • 背景情報の付与： データの⽤途や背景（ビジネスメタデータ）の適切な 付与 • セキュリティとコンプライアンス • ルール策定と監査： 匿名化/最⼩アクセス権限のルール策定および 監査 • セキュリティの⾃動化： ⾃動マスキングなど、セキュリティポリ シー適⽤の⾃動化 • 評価とエコシステムの活性化 • 利⽤状況の分析： データプロダクトの利⽤率や⼈気度の可視化 • 貢献度の評価： データ提供者の貢献度可視化とインセンティブ設計 • 効果測定（ROI）： データ活⽤によるビジネスインパクトの計測 中央集権的な検閲官ではなく⾃動化・⾃律を⽀援するイネーブラー 12 • 現場の変⾰ 実践的なサポート： ⽀社に対するFDEスタイル のハンズオン⽀援 イノベーションの促進： ハッカソンやワーク ショップを通じた変⾰の推進 基盤アセットの提供： 過去の分析記録に基づい て、便利な「SKILL.md」や「セマンティックレ イヤー」の作成と提供 ＋α データ・AI活⽤の推進 最近社内の Forward Deployed Engineer化
13. Center Of Excellence データが「組織全体で繋がる（相互運⽤性）」こと「安全である（信頼性）」ことを保証するための「共 通ルール（規約）」を策定し、その規約にデータオーナーが準拠しているか監督を実施 • 相互運⽤性と標準化 • ルールの統⼀： ⽇付、単位、命名規則など書式の統⼀ • 共通IDの設計： ドメイン横断でデータを結合するための共通IDの設 計 • ⾔葉の定義の統⼀： 部署間での⽤語定義の統⼀と解釈不⼀致の防⽌ • データプロダクトの品質と信頼性 • 品質の監視（SLO）： 更新頻度や⽋損率など、データ品質の継続的 な監視 • 窓⼝とマニュアル： 問合わせ窓⼝の明確化と最新ドキュメントの維 持 • 背景情報の付与： データの⽤途や背景（ビジネスメタデータ）の適切な 付与 • セキュリティとコンプライアンス • ルール策定と監査： 匿名化/最⼩アクセス権限のルール策定および 監査 • セキュリティの⾃動化： ⾃動マスキングなど、セキュリティポリ シー適⽤の⾃動化 • 評価とエコシステムの活性化 • 利⽤状況の分析： データプロダクトの利⽤率や⼈気度の可視化 • 貢献度の評価： データ提供者の貢献度可視化とインセンティブ設計 • 効果測定（ROI）： データ活⽤によるビジネスインパクトの計測 中央集権的な検閲官ではなく⾃動化・⾃律を⽀援するイネーブラー 13 • 現場の変⾰ 実践的なサポート： ⽀社に対するFDEスタイル の⽀援 イノベーションの促進： ハッカソンやワーク ショップを通じた変⾰の推進 基盤アセットの提供： 過去の分析記録に基づい て、便利な「SKILL.md」や「セマンティックレ イヤー」の作成と提供 ＋α データ・AI活⽤の推進 最近社内の Forward Deployed Engineer化 今までのように 「活⽤の仕⽅を教える」・「ハンズオンをする」 だけでは世の中の変化についていけない ※今までもついて⾏っているかは疑問ではあるが 現場の泥臭い課題をリアルタイムに解決する 「動くもの」を早く⾒せる ことで現場の業務削減に直接コミット
14. 『 AIに “作業の指⽰書” ではなく、 “達成すべき⽬標“ だけを伝えるだけで ⽬的が達成される世界にむけて 』 14
15. AI AgentもData Productと定義 • 責任の明確化： Data Productには必ず「オーナー（責任者）」が存在するため、エージェ ント（含むskillsなどのAI Assets) も同様に、誰がその精度と運⽤を管理す るのかを明確化 • ガバナンスの適⽤： データの利⽤規約やセキュリティ、プライバシー保護のルールを そのままエージェントの⾏動規範に反映することが可能 • 再利⽤性： 特定の⽤途（例：発注管理エージェント）をプロダクトとして管理するこ とで、社内の他の部署でも「部品」として再利⽤することが可能 Data Productの定義を拡張 ダッシュボードやデータセットのように、 ⼈が中⾝を⾒て判断を下すための「受動的なものData Product」から、 データをもとに⾃ら思考し次のアクションを提案・実⾏する「能動的なData Product」へ 15
16. AI-Native・Human-on-the-loopに向けて 「⼈間を補助するツール」から、⾃律的に意思決定と実⾏を⾏う真の「Agentic AI」へと変わり、 従来の「⼈間が事前に掃除する」から「AIが⽂脈を読み解きながらその場で解釈する」に進化する Ontology・knowledge Graphの整備 AIが「汚いデータ」から必要な情報を抽出するためには？ AIに「世界の解釈」を授ける 「概念と概念の関係性」を定義することで、 AIはデータの「表⾯上の汚れ」に惑わされず 推論が可能 • 多義性の解消 • 未知のデータの解釈 • 推論のガイド • 点ではなく⾯による推論 • 汚いデータの⾃動クレンジング ドメインを絞る： まずは「顧客対応」や「製造プロセス」など、特定の業務範囲に限定して その中の重要な概念と関係性を定義する ボトムアップでAIに作らせる： 既存の仕様書やマニュアルをAIに読み込ませ、「この業務における主要な 概念図を抽出して」と指⽰し、⼈間はそれを修正する側に回る 「世界の解釈」を授けることで AIは「共通⾔語」と「常識」を学び、 「⽂脈」を頼りに正解にたどり着けるようになる How to 16
17. Agentic AI Mesh と Agentic AI Workflowに向けて • 複数エージェントの協調： 「データ検索が得意なAgent」「コードを書くAgent」「コンプ ライアンスをチェックするAgent」など、特化型の専⾨Agent同 ⼠がチームとして連携し複雑なタスクを実⾏ • ガバナンスとゼロトラスト・セキュリティ： 「このエージェントは⼈事データへのアクセス権限（RBAC）を 持っているか」「実⾏前に⼈間の承認（Human-in-the-loop）が 必要か」といったルールを定義し、全エージェントの⾏動履歴を 監査ログとして記録・監視（オブザーバビリティ） • エージェントのレジストリと発⾒可能性： 組織内のどこにどんな能⼒を持ったAI Agentが存在するのかを Catalog化し、⼈間や他のAI Agentが発⾒・再利⽤ 複数の専⾨特化した「AI Agent」が網⽬（Mesh）のように繋がり互いに連携・協⼒して複雑なタスクを 解決する（=Agentic AI） Agentic AI Mesh上のAI Agentは⾃律的にAgent/Data Catalogを検索し、 ユーザーからの曖昧な指⽰のみでも必要なAI Agent・Dataを各ドメインから集め処理を完遂する Agentic AI Mesh AI Agent Multi Agent Routing Domain-specific Orchestrators AIガバナンス Agent to Agent(A2A)通信 17
18. Data Mesh：供給の⾃律 中央集約的なデータウェアハウス（DWH）の限界 を突破し、データの「鮮度」と「専⾨性」を担保 AIが中央のIT部⾨を介さず、必要なデータを直接、 リアルタイムに取得できる Ontology：意味の地図定義 表記ゆれやデータの不整合があっても、AIがこの 「地図」を参照することで、データの真の意味を 読み解き、論理的な推論を可能とする Agentic AI Mesh：⾃動探索・実⾏ ⼈間が「どのデータをどう処理するか」を指⽰す るのではなく、AIが⾃律的に「どのドメインの データ/Agentが必要か」を判断し、⾃⼒で正解を 探索・⽣成する Domain Domain Domain Data Product Marketplace Data Mesh Agentic AI Mesh AI Agent Multi Agent Routing Domain-specific Orchestrators データガバナンス AIガバナンス Agent to Agent(A2A)通信 MCP Server Ontology 特定の⼩さな課題に対して⼩規模に連携して動かし 徐々に拡張拡⼤していく 1 2 3 組織的知性の循環・確⽴ 18
19. 19 ⾃律分散型 Data Mesh とはいったところで、変化が早く すぐ陳腐化するため四苦⼋苦している 「変化」に対応するには 今まで以上の「Agility」が必要 であり、⾝軽になる上でもSelf-Serviceを推進するのは 現時点では悪くない選択であったと考えている
20. AIの価値を最⼤化するために AIに「質の⾼い情報」を届けられるよう、 データの品質管理とカタログ化による 知識の供給ラインを整備することが必要である その上で、データの鮮度や安全性を保証するガバナンスを敷き、 AIが迷わず、かつ責任を持って動ける 「信頼の⼟台」をアジャイルに築くことが不可⽋である p AIが⾃律的に動作する世界のためには、オントロジー他必要なデータが 存在し、それらのデータもマネジメントする必要がある p 良質なAI Agentを育てるためには、良質なData Productを⽤意する必要 がある p Agentを「Data Product」とみなせば、「野良AI」を卒業し 「資産」として正しく運⽤・スケールができると考えている 20