Data Engineering Guide 2025 #data_summit_findy by @Kazaneya_PR / 20251106

技術カンファレンス「Data Engineering Summit」の資料です。
https://kazaneya.com/26570d0c5ac8803f8f78f25e0b1907ca

Transcript

1. Data Engineering Guide 2025 2025-11-06 Data Engineering Summit 特別講演 Opening ＆ Keynote 株式会社風音屋 横山 翔（Sho Yokoyama） @yuzutas0
2. っ で 、 でCMで 。
7. データエンジニア・ データコンサルタント 採用中 Speakerdeck公開版
8. 1. は めに
9. 注意事項 1. 本資料は許諾 範囲内でのみ 利用 い。無断転載ならびに複写を禁 ま 。 2. 本資料に記載 れている会社名・製品名などは、一般に各社の登録商標ま は商標、商品名で 。資 料内では ©, ®, ™ マーク等は省略 てい いて りま 。 3. 本資料は特定企業の情報公開や称賛・批判を意図 るものではありま ん。社名 提示 れていない ケーススタディやシステム構成は、原則的に複数企業の事例を踏まえ ダミー情報となりま 。 4. 説明を簡略化 る めに、用語やツールの紹介は厳密な定義に則っていない場合 ありま 。 自身 や所属チームでの理解・解釈 紹介内容と異なる場合は、適宜読み替えてい ると幸いで 。 9
10. 本講演の概要 近年では生成AIやデータ活用 注目 れて り、いっ うデータ整備の重要性 高まっていま 。 で本発表ではデータエンジニアリング分野の全体感を振り返りつつ、 各テクノロジーの進化や普及を踏まえて、実践的なアクションに向 道筋を 紹介 ま 。 https://data-engineering-summit.findy-tools.io/2025?m=2025/tt/YzmXmIaR 10
11. データ基盤人材への注目（需要） 平均年収の高い職種は…(中略)… 「Data Warehouse Architect」で 15万4800ドル（1702万8000円） IT業界で平均年収の高い職種はソフトウェアエンジニアリング マネージャ、データウェアハウスアーキテクト、ソフトウェア 開発マネージャなど。米Glassdoor https://www.publickey1.jp/blog/18/itglassdoor.html 11
12. データ基盤人材への注目（供給） http://b.hatena.ne.jp/entry/yuzutas0.hatenablog.com/entry/2018/10/25/183000 12
13. 生成AIの活用効果 「期待以上」となる要因の2位は日米ともに「データ品質」 13 PwCコンサルティング「生成AIに関 る実態調査2024 春 米国との比較」 https://www.pwc.com/jp/ja/knowledge/thoughtleadership/generative-ai-survey2024-us-comparison.html
14. ニーズの高まりにより、データマネジメント 国家資格へ 14 https://www.nikkei.com/article/DGXZQOUA219D40R20C25A5000000/ https://xtech.nikkei.com/atcl/nxt/column/18/00001/10716/
15. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 15 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
16. 2. 自己紹介
17. 登壇者（カジュアル版） ゆ （@yuzutas0） リクルートやメルカリでデータ活用を推進後、AWSを経て、風音屋（ ねや）を創業。 独立行政法人情報処理推進機構（IPA）にて情報処理技術者試験委員を兼任。 データ基盤やダッシュボードの構築について積極的に情報発信 て り、主な著書・訳書に『実践的データ 基盤への処方箋』『データマネジメント 30分でわ る本』『アジャイルデータモデリング』 ある。 1,800人 参加 るSlackコミュニティ datatech-jp、延べ参加者15,640人の勉強会 Data Engineering Study の立 上 に関わるなど、日本のデータエンジニアリング業界の発展をリード て 。 17 Now Writing…
18. 登壇者（詳細版） 横山 翔（@yuzutas0） • リクルートやメルカリにてデータ活用を推進 後、AWSを経て独立 、株式会社風音屋を創業 • 広告配信の最適化、店舗営業のインセンティブ改善など、データ分析によって数億円規模のインパクトを創出 • 独立行政法人情報処理推進機構（IPA）にて情報処理技術者試験委員を兼任（2025〜） • 東京大学 経済学研究科 金融教育研究センター 特任研究員を兼任（2023〜2025） 主な登壇・発表 • Pythonのカンファレンス「PyCon JP 2017」にてベストトークアワード優秀賞 • 翔泳社主催「Developers Summit 2018 Summer」にてベストスピーカー賞 • Google主催「Google Cloud Day」（‘21, ‘23）,「Google Cloud Next Tokyo」（‘23, ‘25） • 日本統計学会 第16回春季集会 主な執筆・翻訳・出版 • 講談社サイエンティフィク『アジャイルデータモデリング』 • 技術評論社『実践的データ基盤への処方箋』 • 技術評論社『Software Design 2020年7月号 - ログ分析特集』『同 2025年7月号 - SQL特集』 • 風音屋『データマネジメント 30分でわ る本』 • 内閣府「経済分析 第208号 - 景気動向分析の新 な潮流」 主なコミュニティ活動 • Google 認定 る技術エキスパート「Google Cloud Champion Innovator / Google Developer Experts」に選出（2023〜） • 1,800人以上 参加 るSlackコミュニティ「datatech-jp」の立 上 ・運営 • 延べ参加者15,640人以上の勉強会「Data Engineering Study」の立 上 ・モデレーター（2020〜2025） • 国内最大規模の技術カンファレンス「Developers Summit」コンテンツ委員会（2022〜2026） 18
19. リクルートやメルカリのSlackで貼られてい クソコラ 19
20. 日本にデータ基盤の3分類を広め 人 「データレイク層」「データウェアハウス層」「データマート層」 20 ※ の三層構造は Bill Inmon 氏のCIFと 青木峰郎氏 『10年戦えるデータ分析入門』で 提唱 概念を参考に ていま 。
21. 日本に るDataOpsの第一人者 21
22. （ ぶん）日本で最も読まれているデータマネジメント本の著者 22
23. 日経産業新聞いわ 「引 手あま の逸材」 23
24. あまりに存在感 大 て、Google社 2人分の席を用意 るを得な っ 男 24
25. SNS / @yuzutas0 フォローよろ ね い ま ！ 25
26. 大手 らスタートアップまで幅広いクライアント企業のデータ活用を支援 るITコンサルティング企業。 100社のデータ経営を実現 、諸産業の活性化に貢献 る とをミッションと て掲 ていま 。 データエンジニア 技術相談やノウハウ共有 あう副業ギルドと て始まり、 日本全国 ら多数の 相談・ 要望を受 て法人化。 ステークホルダーの皆様に 協力い な ら、会社組織と てアジャイルに成長 て ま 。 スタートアップCEO らの推薦コメント 風音屋（ ねや） 26 支援先（一部抜粋）　　　　 • ランサーズ株式会社 • エイベックス株式会社 • 株式会社クラシコム • 株式会社商船三井 • 株式会社ビズリーチ • NE株式会社 • 株式会社リクルート • 福岡地所株式会社 • 住友化学株式会社
27. データエンジニアを募集中！ 27
28. データエンジニアリングの書籍 読み放題で ！ 風音屋オフィス（Library） 28
29. 風音屋 提供 るサービス 29 データ基盤構築 データ分析
30. 「Excelで学ぶデータマネジメント入門」研修 ＆ 風音屋データマネジメント検定 30 【研修実績】 • 全社研修：500名の社員にデータマネジメントの全体像と勘所をインプット • 新入社員研修：ゼミのレポートを題材と て、データ管理の Do’s & Don’ts を学習 • IT部門研修：データ基盤の実践的なシステム構成例、開発・運用プロセスまで踏み込んで 紹介 【ポイント①】Excelファイルに例えな らデータマネジメントの作法を解説 • 「Excelファイルで◯◯を工夫 るのと同 ように、本格的なITシステムでは〜」フォーマットで説明 • 業務部門とIT部門 スムーズに連携で るように知識の橋渡 を行う 【ポイント②】理解度チェックテスト（風音屋データマネジメント検定）を活用 柔軟な研修デザイン • 講義の前と後にテスト → 研修による学習効果を計測・評価 • 分割講義で都度テスト → 講義内容の理解をサポート • 満点獲得まで繰り返 → 講義内容の理解を徹底強制 、セキュリティテストと同 位置付 に • 講義の後に単発テスト → 組織アセスメントや人事評価、配属検討に利用可能
31. 採用文脈でオンライン講座を提供 31
32. 累計260ページ・18万文字の超豪華な研修教材を読み、データ基盤構築のハンズオンを行いま 。 データ基盤構築のインプット＆ハンズオン 32
33. データエンジニアへの転職は無理なの ！？ 33
34. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 34 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
35. 3. データ活用の事例
36. 横山や風音屋 過去に発信 事例 • テーブル数50程度の小規模WEBサービスで、ダッシュボードを含むデータ基盤を2時間で構築。 • 6人日 ってい 「売上の変動箇所の特定」を10分に短縮 、ビジネスの変化を迅速に察知。 ビジネスに るデータ活用の事例（1/6） 36
37. 横山や風音屋 過去に発信 事例 • 集客（マーケ）→営業（セールス）→CS（サクセス）を横断 データ基盤を構築 る とで 個別最適化 ら全体最適化に切り替えて利益を最大化 、いわゆるRevOpsを実現。2020年の記事。 ビジネスに るデータ活用の事例（2/6） 37 https://yuzutas0.hatenablog.com/entry/2020/12/02/173000
38. 横山や風音屋 過去に紹介 事例 • ビジョン達成の計測。「 の事業 ◯人の生活を支えている」を上場企業の社長室モニターに投影。 • 各指標のモニタリング。売上、会員数、販売数、コンテンツ閲覧数、広告費、顧客対応時間など。 • 投資家向 報告書やプレスリリースの めのファクトブック。集計データを再現可能な形で管理 る。 • M&A（買収）に るシナジー効果の推定・測定。 ビジネスに るデータ活用の事例（3/6） 株式会社風音屋（監訳）『アジャイルデータモデリング』より「株式会社クラシコム」「ランサーズ株式会社」の事例 38
39. 横山や風音屋 過去に紹介 事例 • 顧客セグメントや商品ジャンル別の傾向分析。ロイヤル顧客の特徴やリピート商品を特定 る。 • キャンペーン施策の効果測定。 の後のリピートに繋 っ 、需要の先食いは起 ていない 。 • エンタテイメント領域に るコンテンツ企画。視聴数 多い曜日・時間帯 ら分析。 • 工場に る製造プロセス改善や機械の故障検知。 ビジネスに るデータ活用の事例（4/6） 株式会社風音屋（監訳）『アジャイルデータモデリング』より「住友化学株式会社」の事例 39
40. 横山や風音屋 過去に紹介 事例 • 顧客データベース管理によって、部署横断での連携や引 継 を2日→10分に短縮。 • 異常検知：SNSの”バズり”を検知 て関連コンテンツを即日提供。過剰アクセスや迷惑投稿のBAN。 • デジタル広告によるROAS（売上÷広告費）を最大化 る めの入札の最適化。 • 物件や船舶などの資産（アセット）の売り買いによるポートフォリオ最適化。 ビジネスに るデータ活用の事例（5/6） 株式会社風音屋（監訳）『アジャイルデータモデリング』より「エイベックス株式会社」「株式会社商船三井」の事例 40
41. 横山や風音屋 過去に紹介 事例 • レコメンド：類似商品の推薦、クリック率を最大化 る表示順、マッチング期待値 高い人材の紹介。 • 経路探索：自動車ドライバーや月面探査機のルート最適化。 • 動産（アート）や不動産（物件）など交渉で価格 決まる「1点モノ」のプライシング（値付 ）。 • 従量課金やレベニューシェア、ダイナミックプライシングによる、取引単価の最大化。 ビジネスに るデータ活用の事例（6/6） 事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 41
42. 横山や風音屋 過去に紹介 事例 • 民間企業のリアルなデータを用いて、社会課題に関 る学術調査を実施。 • クレジットカードの決済データ らCOVID-19の自粛効果を分析。 ◦ 顧客-店舗の2部グラフで「高田馬場」「若い男性」「低予算」「居酒屋」などの特徴を抽出。 非営利活動：研究論文・学術調査 https://kazaneya.com/news | https://note.com/kazaneya 42
43. 横山や風音屋 過去に紹介 事例 • 生物や森林などの環境資源を計測 、データにもとづいて政策提言や環境保護活動を行う。 • ジンベイザメに識別タグを付 て、リアルタイムで追跡。 • 「スター・ウォーズ」「インディー・ジョーンズ」のハリソン・フォード氏 CIの副理事。 非営利活動：EBPM（エビデンスに基づ 政策立案） Whale Shark Tracker - Conservation International　https://www.conservation.org/projects/whale-shark-tracker 43
44. 横山や風音屋 過去に紹介 事例 • （広義の）古文書の撮影画像を集約、AIで解読 、資料の中身を検索可能な形でデータベース化。 • 資料間の関連や矛盾をナレッジグラフに変換 て、AIで歴史空間にマッピング る。 • 「資料A 正 い場合」「仮説B 正 い場合」の歴史年表や家系図をAIで生成 、妥当性を評価。 ◦ 例：特定資料群 正 いと仮定 、天照大御神 ら横山翔まで無理やり結びつ る。 非営利活動：古文書データ基盤 『富岡村誌』「神奈川県立歴史博物館ホームページ」『千福 横山家文書』『裾野市史』 44
45. • 読書データ基盤（本2,000冊分の読書ノート＆図解メモをAIで解読 てデータベース化） • 婚活データ基盤（縦軸で採用候補者、横軸で工程を管理 て、ファネル改善のサイクルを回 ） • 家計簿データ基盤（10年ほどコツコツと月次でFinOps、AIで半自動化で ない 検討中） • 確定申告の半自動化（2020年：6週間 る→2025年：2日で完了！） • 株式投資に る銘柄選定の半自動化（2024年に人生初のテンバガー達成！） • 家庭菜園データ基盤（定点記録・写真をデータベース化、次は農場経営の話 寄 られて り…？） 私生活に るデータ活用の事例 45
46. 構造化データ • 行（横）と列（縦）のテーブル（表）で表現で るデータ。 • 従来のデータベース 前提と ている形式であり、最も安定 てデータを管理・利用で る。 非構造化データ • 表形式で表 ないデータ。画像、動画、音声、PDFなど。 • AI技術の発展に伴い、非構造化データを扱うツール 急進化 ている 、どれもま 発展途上。 • プログラムでのテキスト処理 簡単なJSONやXMLを「半構造化データ」と区別 る ともある。 補足：構造化データと非構造化データ 46 id 決済日付 決済利用者 加盟店 金額 100 2022-03-01 Aさん いろは商店 900円 101 2022-03-02 Bさん いろは商店 700円 102 2022-03-03 Cさん にほへ屋 1,100円 103 2022-03-04 Dさん にほへ屋 800円 レコード (行) カラム (列)
47. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 47 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
48. 4. データ基盤の意義
49. 企業で起 ている課題 データ活用やDX（デジタルトランスフォーメーション）、生成AIといっ 分野 注目 れている 実際にプロジェクトを進めるとデータ整備の課題 次々と浮上 る。 用途を 実現で るほど データ品質 高 ない 具体的に どのようにデータを 連携 るの 分 らない 必要なデータ 入力 れていない 49
50. データ整備は活用の前工程 データ整備 OK データ活用 ビジネス価値 OK OK データ整備 データ活用 ビジネス価値 NG NG 50
51. データの質・量 不十分 日本国内686社の調査で、データ活用の課題2位と て「質・量を備え データの取得」 挙 られている。 NEDO（2019）「産業分野に る人工知能及び の内の機械学習の活用状況及び人工知能技術の安全性に関 る調査」 ならびに https://ainow.ai/2020/07/05/224999/ 51
52. データのサイロ化（分断） アジア太平洋 よび欧州中近東の企業調査にて、テクノロジー部門の上級意思決定者670人中73% 、 データのサイロ化によって「必要と るデータを提供で ていない」「目標を達成で ていない」と回答。 Oracle Corporation (2020) “Moving the Needle: Data Management for the Multi-Hybrid Age of IT” ならびに https://prtimes.jp/main/html/rd/p/000000003.000057729.html 52
53. SSoTの担保 • SSoT（Single Source of Trust ＝ 信頼で る単一の情報源）の担保 鍵となる。 • データ分析者 「 を見れば必要なデータ 揃う」と信頼で る「寄る辺」 必要と れている。 https://techcrunch.com/2017/06/23/five-building-blocks-of-a-data-driven-culture/ ならびに https://jp.techcrunch.com/2017/06/25/20170623five-building-blocks-of-a-data-driven-culture/ ※閉鎖済 事実の単一情報源を持っている場合には、 アナリストや他の意思決定者といっ エンドユーザー に、 優れ 価値を提供 る と で る。 彼らは組織内でデータを探 時間 少な て済むようになり、 データの利用により多 の時間を割 と で るようになる ら 。 When you have a single source of truth,you provide superior value to the end user: the analysts and other decision makers. They’ll spend less time hunting for data across the organization and more time using it. Additionally, the data sources are more likely to be organized, documented and joined. Thus, by providing a richer context about the entities of interest, the users are better positioned to leverage the data and find actionable insights. 53
54. 社内外のデータを一ヶ所に集約 る • 事前にデータを一元管理 て ば、分析者 都度データを取り寄 る必要 な なる。 • 以下は登壇者 メルカリ社で構築 データ基盤の構成図を一部抜粋 もの。 ◦ 営業管理ツール、 問い合わ 対応の記録、人事マスタといっ データをBigQueryに集約。 ◦ BigQueryはデータウェアハウス（DWH）と呼ばれる分析用データベース製品の1つ。後述。 54 Salesforce：加盟店営業 社内外のデータ DWH kintone：加盟店管理 Zendesk：顧客サポート JIRA：チケット管理 Workday：人事マスタ BigQuery
55. 一連の処理をパイプラインと て管理 る • データの統合や加工を実現 る めのテクノロジー 存在 る。 • れらのテクノロジーを組み合わ てシステムを構築 る。詳細は後述。 55 データ 取得元C データ 取得元B データ収集プログラム （ETL） データウェアハウス （分析環境） 元データ 加工 データ データ加工・変換 （ELT） ワークフロー （処理の流れを横断管理） データ 取得元A https://learn.microsoft.com/en-us/azure/data-factory/iterative-development-debugging
56. SSoTの画面イメージ • 画面上で組み合わ を指定 て、欲 いデータを集計で ている状態。 • 以下は『アジャイルデータモデリング』に掲載 れているクラシコム様の事例。2022年上場。 56 株式会社風音屋（監訳）『アジャイルデータモデリング』よりクラシコム社の事例
57. • ステークホルダー全員 共通のキューブ（立方体）を多様な軸でスライス（切断）で る状態。 • 売上高◯◯円という事実（Fact）を3つの次元（Dimension）で分解 る。 SSoTの概念イメージ 57 株式会社風音屋（監訳）『アジャイルデータモデリング』より（網掛 は本資料での追記） の期間での売上 2億円 の製品での売上 5,000万円 の店舗での売上 800万円 売上累計 30億円
58. れまでの観点と違う新 い観点でデータを見る 「営業組織別のExcelシート」ではな 「切り口を柔軟に変更で る基盤」 58 繊維 工業 卸小売 飲食業 宿泊業 チームA 京都府 80 40 60 60 チームB 大阪府 60 60 80 80 チームC 兵庫県 20 80 80 60 チームD 滋賀県 40 20 20 20 市場環境の変化 れまでと違う観点での データ分析 社内外のデータ 根拠のある 意思決定 変化に適応 失敗を検知 マーケット変化への適応 「 れまでは営業組織に合わ てエリア別で数字を見てい 」 「新型コロナの影響 あるは なので業種別で数字を見 い」 「飲食業など店頭サービス業での利用は減少 」 「 れらの店舗に対 て何 支援を提供で ない 」 「逆に の状況で伸びている業種はあるの ろう 」 「 れまでと違っ 利用の急な増加に備えるべ 」
59. 集計対象（Fact：出来事>指標>計算方法）の洗い出 モデル化 図（例：業務フロー図） らビジネスイベントを洗い出 ビジネスイベント ら指標を洗い出 指標 ら計算方法を洗い出 （※BIツールに任 るケースもある） 59 来店 注文 発送 返品 注文 件数 人数 商品数 金額 注文件数 総計 1人あ り 1商品あ り YoY増加率
60. 【分 て】5W1Hで分析の切り口を定める 【比べる】分析軸による差異を比較 る • 「都心の店舗」は「郊外の店舗」より（客数 多い｜少ない） • 「今年」は「去年」より（注文総額 多い｜少ない） • 「バッグ」は「衣類」より（平均単価 高い｜低い） • 「高単価の商品」は「低単価の商品」より（レビュー評価 高い｜低い） • 「リピーター」は「新規顧客」より（1度の注文点数 多い｜少ない） 分析軸（5W1H）の洗い出 、分析軸での比較検討 60 今月 When 切り口 （dim） Who 新規顧客 今月 When 切り口 （dim） Where 渋谷店 What バッグ Where 店舗（≠EC） Who 誰 What 何を When いつ Where ど で Why な How どのように
61. データ活用の流れ（カフェのビジネス） ◯◯ ん カフェラテを注文 (消費) リラックス (効用) 統合 注文履歴 会員登録 データ基盤 ・購買データ ・顧客データ 生成 新商品の開発 リピーター割引券 活用 価値 ☕ 61 サービス提供に伴い、データ 生成 れる。 のデータを統合 、活用 る とで、 らなるサービス提供を実現で るようになる。 データにまつわる（青い背景の）箇所 データエンジニアリングの対象領域。
62. データ活用の流れ（一般化） 製品・商品 プロダクト 顧客・消費者 ユーザー 統合 業務データ、行動ログ データ基盤 生成 開発、施策、業務 活用 価値 62 サービス提供に伴い、データ 生成 れる。 のデータを統合 、活用 る とで、 らなるサービス提供を実現で るようになる。 データにまつわる（青い背景の）箇所 データエンジニアリングの対象領域。
63. 複数のデータソース（入力／資源）と複数のユースケース（出力／活用）をリボンのように繋 装置。 データ基盤とは何 （概要） 63 データ活用基盤
64. 複数のデータソース（入力／資源）と複数のユースケース（出力／活用）をリボンのように繋 装置。 データ基盤とは何 （詳細） 64
65. データ基盤を構成 る要素 「データ」や「システム」 ではな 「ヒト」まで含めて「一連の仕組み」（基盤）と言える。 65 ゆ （共著）『実践的データ基盤への処方箋』より
66. な データ基盤 必要 （BI） 人間の意思決定を加速 、PDCAサイクルを回 め。 66 顧客価値 担当業務（オペレーション）の目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution） 例：販売目標を達成で ている ？ 採用目標を達成で ている ？ クレーム件数は減ら ている ？ 業務横断（オペレーション）での目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution） 例：キャンペーンや商談は継続利用に繋 っている ？ 押 売りで後工程のトラブルを招いていない ？ 事業（ビジネス）視点での目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution） 例：会員や商材のストックは増えている ？ 顧客ニーズのトレンドは変わっていない ？ 資源（リソース）視点での目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution） 例：対象領域の（予算｜人員）を（増や｜減ら） て（組織変更｜新規事業化｜買収｜売却｜撤退） る ？ ソフトウェア 開発 デザイン 販促 マーケ カスタマー サポート 法務 経理・財務 広報 セールス 在庫管理 配送 店舗接客 セキュリティ 人事・労務 製造管理 事業開発 IR 商談 販売促進 受注・契約 初回利用 継続利用
67. な データ基盤 必要 （AI） 機械の自動判断を加速 、業務の効率化 よび顧客体験の変革を進める め。 67 Before After 注文書作成 オペレーション ビジネス 在庫発注 タスク 店頭スタッフ販売 Gemini 自動作成 ワークフロー型のAIエージェントで 自動発注 無人店舗 （AIスタッフ販売） 人間の 脳内 社内外の データ
68. どういっ 手順で作る • 「データソース」と「ユースケース」の絵を描 、両者を繋 る めの流れを描 。 • Return（どのような恩恵を得られる ）とInvestment（どのような開発を行う ）を明確に て ステークホルダーに提示 、ROIの高い順番でシステム開発やダッシュボード構築を進める。 • キーワードや製品あり で「◯◯◯を導入 ま ょう！」 ら始めるのはアンチパターン。 68 例：ヘラルボニーに るデータ基盤の初期構築。設計・実装は風音屋 担当。
69. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 69 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
70. 5. システム構成要素
71. のパート以降で話 内容 • データテクノロジーに る主要な構成要素を紹介 ま 。 • スライド資料「Google Cloud で学ぶデータエンジニアリング入門 2025年版」 らの抜粋で 。 • 風音屋ではAWSやSnowflakeの案件も多数扱っていま 、「無料のgmailメールアドレス えあれば 個人でも気軽に試 る」「DWHやBIツールの無料枠で体験で る幅 圧倒的に広い」という理由 ら カンファレンス参加者の自己学習やNextActionに繋 や いGoogle Cloudを題材と ま 。 71
72. データ基盤を支える代表的なテクノロジーと構成例は以下のようになる。 主な技術要素（概要版） 72 元データA 元データB DWH 蓄積・集計 BI 分析・可視化 ワークフローエンジン 処理の流れを管理 ETL 収集・連携 データカタログ 仕様の入力・検索
73. 主な技術要素（詳細版） 73 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
74. 主な技術要素（詳細版） 74 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
75. BI（Business Intelligence）ツール • グラフ可視化やダッシュボード構築に特化 ツール。「分析ツール」と て分 りや い。 • Googleアカウント あれば Looker Studio をWEBブラウザで利用で る。基本料金は無料。 • 日本で有名な利用事例と ては、クリスプ・サラダワークス ん Looker StudioでKPIを全公開。 ◦ デジタル庁 PowerBIで作っ 政策ダッシュボードも有名。 • https://lookerstudio.google.com/gallery • https://metrics.crisp.co.jp/ 75
76. BIツールの選定例 76 観点 選択肢の例 エンタープライズ用途で 予算を確保 ている (多 はオンプレ・クラウド両対応) Tableau, Looker, Qlik, ThoughtSpot, DOMO, Microsoft Power BI (PRO/Premium) Redash, Metabase, Kibana, Grafana, lightdash 無料で使い い (無料の場合) 自社構築 必要 構築不要 Microsoft Power BI (Free), Looker Studio (Free) 使い慣れ ツールで済ま い （BI専用ツールを使わ に分析や可視化を行う） Microsoft Excel, Google Sheets
77. BIツール：適切なツールは部署や役割 とに異なる • 自分にとってのベスト≠他人にとってのベスト • 過去に某案件でヒアリング と は部署によって回答 異なってい 77 マーケター データアナリスト WEBプロデューサー (≒プロダクトマネージャー) ソフトウェア開発者 (機械学習を含む) Excel Tableau Redash Jupyter Notebook 気軽に数字を変えて シミュレーション 高価格・高機能 分析要求に対応 SQL 書 るひと 手軽利用 Gitでコード管理 プログラムの恩恵
78. 主な技術要素（詳細版） 78 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
79. DWH（データウェアハウス）製品 • 大規模データの保存や集計に適 データベース。データエンジニアリングの中核となる存在。 • Googleアカウント あれば、BigQuery WEBブラウザで利用で る。月1TBまでの集計 無料。 • SQLと呼ばれるデータベース言語を使ってデータの抽出・集計を行う。 ◦ 例えば「SELECT name FROM customers WHERE prefecture = “東京都”」 と 「氏名を取得 よ」「顧客テーブル ら」「東京都で絞り込んで」という指示になる。 79 SQLを書く データを見る 実行する
80. DWH製品の選定例 80 観点 選択肢の例 処理規模 〜◯◯PB 〜◯◯TB クラウド ベンダー Snowflake, Databricks, Google BigQuery, Amazon Redshift, Amazon Athena, Azure Synapse Analytics, Treasure Data オンプレ 構築可能 Teradata, Vertica OSS Hadoop, ClickHouse 〜数百GB *not DWH RDBMSを分析用に構築（MySQL, PostgreSQL） ELKスタック（Elasticsearch + Logstash + Kibana） ファイルストレージで完結（Iceberg + Spark） 〜数十MB　*not DWH ExcelやGoogle Sheetsなどの表計算ソフト DuckDBやSQLiteなどの軽量DB KintoneやSalesforceなどのSaaSをDB代わりに使う
81. 主な技術要素（詳細版） 81 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
82. クラウドストレージ • 安全・安価なファイルの置 場。 • Google Cloudを使う場合は、GCS（Google Cloud Storage） 該当 る。 ◦ Googleドライブ 人間用のファイル置 場なら、GCSはシステム処理用のファイル置 場。 • データエンジニアリングの分野 と以下の用途で使われる と 多い。 ◦ ①バックアップの置 場。DWHの更新ミス あっ と に備えて、ストレージにバックアッ プを保存 、データを復旧で るように て と 望ま い。 ◦ ②データの中継地点。DWHは事前に定義 仕様（列名や型）と異なるデータを追加 ると エラーになる。ストレージにデータ あれば、外部システム らデータを再連携 に済む。 82 風音屋のMENTA講座の資料より
83. 主な技術要素（詳細版） 83 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
84. プログラム実行環境 • Pythonなどのプログラムで「外部 らのデータ取得」や「外部へのデータ連携」を実現 るには、 プログラムを実行 る めのインフラ環境（＝サーバ） 必要になる。 ◦ 個人 PC端末（＝ローカルサーバ）でGoogle Chrome（＝プログラム）を起動 り、 スマートフォン（＝ローカルサーバ）でYouTubeアプリ（＝プログラム）を動 のと同 。 • Google Cloudを使う場合、Cloud Run functionsというソリューション 、特に軽量 つ安価で、 使い勝手 良いのでオススメ。 ◦ PythonのソースコードをGCSに置 、Cloud Schedulerで定期スケジュールを設定 ると、 Cloud Run functionsで処理を実行で る。 風音屋のMENTA講座の資料より 84
85. 補足：ETL（Extract / Transform / Load）ツール データの抽出・変換・格納を行うツール • 例：設定ファイルとプラグインで様々なデータベース間のデータ転送を実現で るEmbulk • 転送元（Source） ら転送先（Target）へのマッピングを定義 てフォーマットの差異を吸収 る in: type: mysql host: HOST_NAME user: USER_NAME password: PASSWORD database: DATABASE_NAME table: purchase select: id, user_id, title, contents, created_at, updated_at out: type: bigquery auth_method: json_key json_keyfile: *****.json path_prefix: /tmp file_ext: .csv.gz source_format: CSV project: BQ_PROJECT dataset: postapp__datalake__mysql auto_create_table: true schema_file: article.json formatter: {type: csv, charset: UTF-8, delimiter: ',', header_line: false} Out (target) In (source) 85
86. 用語解説：ETL、ELT、ReverseETL ①狭義のETL（処理／ツール）：外部 らDWH製品へデータを連携・統合。 　外部 らデータをE（抽出）→DWH製品 読み取れる形式にT（変換）→DWH製品にL（格納） る。 ②ELT（処理／ツール）：DWH製品の中でデータを加工。 　DWHにL（格納） れ データをT（変換） るので①のE→T→Lと対比 る意図でE→L→Tと呼ぶ。 ③ReverseETL（処理／ツール）：DWH製品 ら他システムへデータを連携・転送。 　他システム らデータを取り込む①の逆（Reverse）なのでReverseETLと呼ぶ。 ④広義のETL（処理／ツール）：上記3つを含ん 一般的なデータの加工・転送の総称。 　元は④想定で数々のETLツール 誕生 、多 のPJで①に関心 偏り、①の機能強化 優先 れ 。 　 の後、②や③のニーズ 顕在化 とで、専用ツール 登場 、①に対 て②③を名乗る。 データソース DWH製品 社内システムや 外部ツール 元データのコピー 加工済みデータ Reverse ETL処理 Reverse ETLツール ELT処理 ELTツール 広義のETL処理 広義のETLツール 狭義のETL処理 狭義のETLツール ① ② ③ ④ 86
87. ETLツールの選定例 87 観点 選択肢の例 定期バッチ (1分毎実行可能を含む) (いわゆるEAIを含む) オンプレ 構築可能 コード Embulk 画面 HULFT, DataSpider, Alteryx, CDataSync, ASTERIA WARP, Talend, Airbyte クラウド ベンダー コード AWS Glue, Databricks Job 画面 HULFT SQUARE, Informatica, Boomi, Fivetran, Stitch, TROCCO, Reckoner, Azure Data Factory ストリーミング (メッセージキュー含む) クラウドベンダー Amazon Kinesis, AWS SNS + SQS + Lambda, Cloud Pub/Sub, Azure Stream Analytics オンプレ構築可能 Fluentd, Apache Kafka, Logstash, Apache Storm 両対応 クラウドベンダー Cloud Dataflow オンプレ構築可能 （分散処理FW） Apache Spark, Apache beam
88. 主な技術要素（詳細版） 88 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
89. SQL管理ワークフロー / ELTツール • SQLでのデータ変換・集計処理について、依存関係をパイプライン管理 るツール。 • BigQueryを使う場合は、付随機能と て Dataform というツールを無料で使う と で る。 • 以下のような複数のSQLを段階的に実行で る。 1. POSレジのデータと通販DBのデータを統合 る 2. 顧客一覧を作成 る 3. 顧客 との年間売上を集計 る 4. 年間売上を元に顧客ランクを付与 る 5. メルマガ配信リストを作成 る。 89 風音屋のMENTA講座の資料より
90. ワークフローエンジン • 一連の処理の流れを管理 るツール。 • Google Cloudを使う場合は、Cloud Workflowsというソリューション 汎用的で使いや い。 • 複数のシステムを横断 て、以下のような一連の処理を管理・実行で る。 1. Cloud Run functionsでPythonプログラムを実行 てデータをBigQueryに反映 る。 2. DataformでBigQueryのデータを加工・集計 、メルマガ配信リストを作成 る。 3. Cloud Run functionsでPythonプログラムを実行 てメルマガ配信ツールにリストを送る。 風音屋のMENTA講座の資料より 90
91. ワークフローエンジンの選定例 91 観点 選択肢の例 コード管理 Apache Airflow（AWS、GCP、Azure等でマネージドサービスを提供）, Argo, Prefect, Dagstar, Luigi, Digdag, Azkaban GUI管理 Jenkins (最近はコード管理機能も追加), Rundeck SQLベースの変換管理 ※ELTツール 拡張 ればワークフローになる dbt（OSS版／SaaS版）, Dataform の他の汎用的な ジョブスケジューラ make, cron, JP1(有料), AWS Step Functions, Cloud Workflow, ETLツール（例：TROCCO）やBIツール（例：Looker） ワークフロー機能を提供 る例も増えて 。
92. 主な技術要素（詳細版） 92 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
93. データカタログ • 社内データを検索 り、データの特徴や注意点を調べる と で るツール。 ◦ 例えば、「user」で検索 るとユーザーに関連 る社内データを見つ られる。 ◦ データの最終更新日や他にどのような項目 含まれている といっ 情報も確認で る。 • Google Cloudを使う場合は、Dataplex Universal Catalog というソリューション 該当 る。 • 「個人情報を含む」といっ タグ付 （PIIタギング）を行い、特定の部署以外 アクセス ると、 該当データの中身をマスキング るといっ 設定も可能（現時点では旧Catalogのみ対応）。 93 風音屋のMENTA講座の資料より
94. データカタログ（OSSの例） • Open Metadata や dbt docs などのOSSで機能強化 活発 • ワークフローエンジンの実行ログを自動で取り込むといっ 機能を有 ているケースもある 94 https://open-metadata.org/ Open Metadata で記載内容の承認 https://docs.getdbt.com/docs/collaborate/documentation dbt docs でテーブルや列の説明を表示
95. データカタログの選定例 95 観点 選択肢の例 ベンダー 日本語に対応 Informatica Data Catalog, HULFT DataCatalog, Quollio Data Catalog, Insight Catalog, COMETA 主に英語で表示 Atlan, Metaphor, Microsoft Purview, Cloud Dataplex（Data Catalog） OSS （SaaS版も提供あり） OpenMetadata, DataHub, dbt docs 使い慣れ ツールで済ま い （専用ツールよりも手軽に社内普及 る） SharePoint等での社内ポータルサイト、 Confluence等での社内Wiki
96. 主な技術要素（詳細版） 96 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
97. • 「誰 」「どのデータに」（どのシステムに）アクセスで るの 、を管理 る めの機能。 • Google Cloud と、Cloud IAM（Identity and Access Management） 該当 る。 • Google Driveのフォルダ権限管理と同 で、Google Groups（メーリングリスト機能）のグループに 対 て、データ参照の権限を付与 る と で る。 ◦ 入退社や部署異動の手続 でGoogle Groupsを使っている場合は、同 要領で管理で る。 IAM（アクセス管理） 97 A ん@kazaneya.com B ん@kazaneya.com C ん@kazaneya.com D部署@kazaneya.com E案件@kazaneya.com F職種@kazaneya.com E案件の受領データ D部署 管理 るデータ 研修用のデータ データ利用者 Google Groups BigQueryのデータ IAM 編集権限 閲覧権限 編集権限
98. 監査ログ • データへのアクセス記録を残 、後 ら監査を行う と で るログ。 • Google Cloud と、主に Cloud Logging というログ出力ソリューションを用いる。 ◦ クラウドサービスの標準機能であり、利用者 他の候補を検討 るといっ 類のものではない。 • あらゆるログ 出力 れるので、調査のノイズを減ら り、保存コストを節約 る めに、 「特定データへのアクセス」といっ 条件で絞り込んで、保存ストレージを指定 る ともで る。 98
99. 主な技術要素（詳細版） 99 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
100. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 100 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
101. 6. データ収集
102. 主な技術要素（詳細版） 102 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
103. Python等のプログラムを実行 て、SaaS（例：Kintone、Shopify、Moneyforward、Salesforce）、 広告媒体（例：Meta広告）、メールやLINEの配信ツール（例：Klaviyo、CRM Plus on LINE）、 アプリデータ（例：Apple Store）、自社Webサービス等 提供 るWeb API らデータを取得 る。 データ基盤システム（Google Cloud） コンソール利用時 Web API によるデータ取得 103 SaaS等のWebシステム データベース Web画面 （ユーザー用） Web API （システム連携用） 取得プログラム 例：Python Cloud Run functions ファイル 例：CSV, JSON GCS BigQuery Webブラウザ インターネット 人間 HTTP リクエスト 外部 テーブル 保存 HTTP リクエスト PC端末 表示 提供 アクセス 💡SalesforceやServiceNowなど、一部のSaaSは BigQuery Data Transfer Serviceのプレビュー版 登場 ので、ゆ ゆ は置 換えられる も？
104. クラウドサービス（例：AWS）のエクスポート機能でストレージ（例：S3）を経由 てデータを渡 、 ま はDatastreamでDBの更新ログを取得 てGCS経由でBigQueryに連携 る。 な 、Datastream らBigQueryに直接出力 ると履歴 消えるので、強いリアルタイム要望 な れば （＝10分間隔のマイクロバッチで要件を満 るなら）GCSを経由 る と 望ま い。 データ基盤システム（Google Cloud） 業務DB らのデータ取得（例：AWS→BigQuery） 104 Data stream ファイル GCS BigQuery Webシステム（例：AWS） データベース 例：Amazon RDS 更新ログ WEBアプリ ケーション データ 更新 保存 外部 テーブル 取得 ⚠セキュリティ要件によっては アクセスNGの場合もあるよ！ 💡差分エクスポートなどで ファイルの数や容量を減ら う！ ストレージ 例：Amazon S3 エクスポート Storage Transfer Service 取得 ファイル GCS 外部 テーブル 保存 AWS Fargate等 ユーザー インターネットや VPN等 HTTP リクエスト プライベート接続、 VPCピアリング、VPN等 💡MySQLやPostgreSQL、Oracle等、 一部のRDBMSは、BigQuery Data Transfer Serviceのプレビュー版 登場 ので、N/Wアクセス 許可 れるのであれば、 ゆ ゆ は置 換えられる も？
105. アクセスログやアプリケーションログと呼ばれるWebシステムのログは、 • Google Cloud内ならCloud Logging らGCS経由でBigQueryに連携 る。 • Google Cloud外（例：AWS）ならエクスポート機能でストレージ（例：S3）を経由 て受 渡 。 データ基盤システム（Google Cloud） サーバログ らのデータ取得 105 ファイル GCS BigQuery Webシステム（Google Cloud） Cloud Logging WEBアプリ ケーション ユーザー HTTP リクエスト ログ 出力 保存 外部 テーブル ファイル GCS Webシステム（例：AWS） ログサービス 例：Cloud Watch Logs WEBアプリ ケーション ユーザー HTTP リクエスト ログ 出力 ファイル GCS エクスポート Cloud Run等 AWS Fargate等 💡ECS + Fargateの構成なら FireLens→S3に直接連携も！ 💡ファイルの数や容量 多い場合は Lambda等で事前に加工・削減！ Storage Transfer Service 取得 外部 テーブル エクスポート インターネットや VPN等 プライベート接続、 VPCピアリング、VPN等
106. • 政府統計や各社オープンデータはBigQuery Sharing機能で提供事業者 らデータ取得 可能。 • WEBコンテンツは、Python等のプログラム + Geminiでスクレイピングを行い、BigQueryに連携。 データ基盤システム （Google Cloud） 各提供者 各省庁等 オープンデータによるデータ取得 106 WEB公開 コンテンツ 提供事業者A 政府統計 収集・加工 システム BigQuery 提供事業者B 各社 データベース BigQuery BigQuery BigQuery Sharing BigQuery Sharing インターネット 取得プログラム 例：Python Cloud Run functions ファイル 例：CSV, JSON GCS 保存 外部 テーブル HTTPリクエスト スクレイピング （Google検索） Gemini 取得 更新 更新 連携 HTTPリクエスト スクレイピング （ページ指定） 💡Webサービスの画面レイアウト変更時は、 エラーログとHTML文字列をもとに GitHub Issueを自動起票 てコーディングAIに パース処理を修正 てもら う！
107. • 各ツール ら文章、画像、動画、PDFファイルなどの非構造化データを集約 る。 • システム 管理 る場合はGCSに置 、必要に応 てBigQueryにデータをロード る。 • 人間 管理 る場合はGoogle Driveに置 、必要に応 てGCSを経由 てBigQueryにロード る。 • BigQueryのObject Table機能でGCSの非構造化データを参照 、バイナリ形式で機械学習に利用。 データ基盤システム（Google Cloud） 社内フォルダ等のデータ取得（ストレージに集約 る場合） 107 インターネット Google Workspace BigQuery ユーザー HTTP リクエスト ファイルを アップロード 各ファイル Google Drive 取得プログラム 例：Python Cloud Run functions 各ファイル GCS 保存 WebAPIコールやスクレイピング 各ツール 外部 テーブル HTTPリクエスト Web API コール HTTP リクエスト
108. • 各ツール ら文章、画像、動画、PDFファイルなどの非構造化データを連携 る。 • Gemini Enterpriseに直接データを連携 、BigQueryに集約 構造化データと組み合わ る。 • データ分析のレポートやSQLを自動生成 り、カレンダーやメールの作成 可能。 • 例：キャンペーン企画や契約書を連携 ⇒ 売上の変動要因を解釈 ⇒ 重点顧客にアポ依頼のメール。 社内フォルダ等のデータ取得（Gemini Enterpriseで直接利用 る場合） 108 Microsoft Teams Microsoft Outlook Microsoft OneDrive SharePoint Slack Box Gmail Google Drive Confluence JIRA GitHub Salesforce Google Group Google Calendar 文章 | 画像 | 動画 | PDF 非構造化データ HubSpot Zendesk Service Now Workday etc… Trello BigQuery 構造化 データ データ基盤システム （Google Cloud） Gemini Enterprise Vertex AI Agent Engine Python + ADK Assistants Gemini Google Workspace Google Calendar Gmail 人間 連携 連携 利用 利用 スケジュール設定や メールの送信 分析レポートや SQLの作成 Web画面で チャット指示 ⚠Gemini Enterprise等のAI Agent系 サービスはEarly AccessやPreview相当の もの 多い。機能強化は今後に期待。 ⚠Claude Desktop等を使い、 各サービスをMCP経由で参照 て 分析レポートを作る方法もあり。
109. データの仮想化について • データ本体を持 に「外部テーブル」や「federated query」で別のシステムにアクセス つつ、 利用者にはデータ にある のように振る舞う とを「データの仮想化」と呼ぶ。 • データの仮想化あり で整え システム構成を「レイクハウスアーキテクチャ」と呼ぶ。 ネイティブテーブルへの変換 • 上記機能 と、接続設定 容易な一方で、データアクセスの挙動 安定 ない と ある。 ◦ 例：Google Sheetsへのアクセス エラーになる。再実行 ると問題な データを取得で る。 • 頻繁に参照 れるデータは、BigQueryに実体をコピー る（ネイティブテーブルを作る） とで、 エラーに煩わ れ に済む。 • Dataformで “SELECT * FROM 仮想化テーブル WHERE 対象日” を実行 、別テーブルに保存 る。 他システム データ基盤システム （Google Cloud） BigQuery 補足：仮想化テーブルの一部はネイティブテーブルへと変換 109 仮想化テーブル ネイティブテーブル Dataform 取得 保存 元データ本体 都度参照 取得経路と解釈 rawデータと解釈
110. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 110 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
111. 7. データ加工
112. 主な技術要素（詳細版） 112 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
113. データ加工の概要 Excelシートで経理データを集計・活用 ると には、以下のような工夫を行う。 • データ 更新 れて、シート 上書 れて まわないように、履歴（スナップショット）を残 • Excel関数で処理で るようにフォーマットを調整（前処理） る • 1つのセルに含まれるExcel関数 膨大・複雑になっ ら、途中集計のセルを分 る • 汎用的な会員リストを作って ら、複数のシートで のリストを参照 、フィルタリングを行う のような「データの加工」の流れを設計 て、SQLで実現 てい 。 113
114. 風音屋式の簡易DFD（データフロー図）でデータ加工処理を設計 る 114 最終的な活用イメージ（モックアップ）と テーブル 紐づ と ろまで確認 る 加工前のデータ 出口まで繋 る とを確認 る 結合条件や加工結果を明記 る →1つ1つ SQLのCTEやDataformのファイルになる 最終形となるテーブルの具体例を書 、 ステークホルダーと擦り合わ る 参考：BEAM✲テーブル テスト観点を明記 る → Dataformのテストコードに反映 る 1.『Software Design 2025年7月号』 特集「データ分析の めのSQL講座」 2. データ分析で用いるSQLクエリの設計方法 - 風音屋TechBlog 　 https://techblog.kazaneya.com/20241208-design-of-analytical-sql-queries/ インプット アウトプット プロセス（途中処理）
115. BigQuery CanvasでSQLを書 、簡易DFDを再現 る クエリの実行結果をプレビュー表示 て、 の結果に対 て次のクエリを実行 る と 可能。 簡易DFDの設計をベースに てSQLを実装＆テスト てい 。 115 風音屋のMENTA講座の資料より
116. 作成 SQLをDataformに移植 る Dataformのデータ集計機能 • 集計処理の定期実行、エラー時のリトライ • バリデーション（NotNullやUnique）や自動テスト • データの依存関係の管理 116 Git/GitHubでのコード管理 • Gitでのバージョン管理 • GitHubでのCI管理（Linterなど） • AIエージェントによる開発の半自動化 風音屋のMENTA講座の資料より
117. データの取得（左） ら活用（右）に向 って層（レイヤー） とに役割＆名前を分 る。 • 元データのコピー（ローデータ）を格納 る「raw__xxx」テーブル • 顧客属性や商品カテゴリといっ 分析の切り口は「dim__xxx」テーブル • 商品購入の金額・数量といっ 集計対象は「fact__xxx」テーブル • dimとfactを結合 て、簡単にデータを使えるように 「wide_xxx」テーブル 責務に応 てレイヤーを分 、命名規則で管理 る 117 株式会社風音屋（監訳）『アジャイルデータモデリング』より
118. 構造化データに るレイヤリングの過去議論 118 “ゆ ”の3層構造（概要） Bill Inmon “CIF” 画像は『データマネジメント知識体系ガイド』より Kimball “DW Chess Pieces” 画像は『データマネジメント知識体系ガイド』より 青木峰郎 “SQL中心アーキテクチャ” 画像は『10年戦えるデータ分析システム』より Databricks “Medallion Architecture” https://www.databricks.com/jp/glossary/medallion-architecture dbt labs “dbt best practice” https://docs.getdbt.com/best-practices/how-we-structure/1-guide-overview
119. 風音屋のデータモデリング標準 / “ゆ ”の3層構造（詳細） データの「入口」「中間」「出口」で、重視 べ ステークホルダーや担うべ 役割 異なるという思想。 世に出ている様々なテーブル設計のテクニックを、 れ れに適 箇所で使うように位置付 ている。 119 raw 元データの コピー データ ソース ユース ケース 前処理 提供形式調整 用途別I/F ディメンショナルモデル 主にデータ保有者 データ品質を担保 る （データレイク層） 主にデータ利用者 データ品質を担保 る （データマート層） 主にデータ整備者 データ品質を担保 る （データウェアハウス層） snapshot 変更履歴の 保持 adapter 標準化や クレンジング hub 名寄 ・統合 bridge fact/dimの 生成ロジック dim 分析の切り口 （5W1H） fact 集計対象 出来事＞指標 dim 分析の切り口 （5W1H） dim 分析の切り口 （5W1H） dim 分析の切り口 （5W1H） wide factとdimの 組み合わ summary 粒度を集約 metric 主要・共通の 指標を管理 bi BIツールに データ提供 team 各チームに データ提供 sys 各システムに データ提供 z 各ユーザーに データ提供 raw 元データの コピー データ ソース raw 元データの コピー データ ソース raw 元データの コピー データ ソース ユース ケース ユース ケース ユース ケース
120. 補足：イベントマトリクス ファクトとディメンションの組み合わ を表形式（イベントマトリクス）と て書 出 。 データチームの定例ミーティングで表を更新 り、データ整備やデータ分析のTODOリストに反映 る。 • 縦軸：ファクトとなる「出来事」（ビジネスイベント） • 横軸：ディメンションとなる「切り口」（5W1H） 120 株式会社風音屋（監訳）『アジャイルデータモデリング』より引用
121. 非構造化データ ⇔ 構造化データ の変換 生成AIによる「非構造化データ」 ら「構造化データ」への変換（以下は例） • 商品名のテキスト → 商品カテゴリーの分類 → カテゴリー別の売上集計 可能になる • 自動車 撮影 路面写真 → リスク要因のラベリング → 走行データと合わ て事故予測の精度向上 • 代理店との会議メモやメール → キャンペーンの情報を抽出 → MMMに組み込んで広告効果推定の改善 生成AIによる「構造化データ」 ら「非構造化データ」への変換（以下は例） • 法人顧客の行動データ → 営業担当向 に追加提案メールのドラフトを生成 • 商品の在庫や注文のデータ → 今日推 べ 商品で「 んな人 買ってま 」訴求文面を生成 • 企業の募集要項と求職者の履歴書 → 条件ミスマッチを緩和 る めの修正提案メッセージを作成 121 風音屋TechTalk #4 発表資料より
122. 非構造化データ in データパイプライン パイプラインに組み込む どう で2つのアプローチ 考えられる。 1. データパイプラインに組み込む場合。BigQuery ML GeminiでSQL らGeminiを実行 る。 2. 従来のパイプラインに組み込ま 、Gemini Enterpriseに各データを集約 てAI側で完結 る。 122 非構造化データ データパイプライン 構造化データ 非構造化データ ①生成AIで前処理 ②生成AIで出力作成
123. 非構造化データの3層構造 Garbage In, Garbage Out（ゴミを入れ らゴミ 出て る） • 社内文書や動画ファイルはボリューム 多い割に、品質 低 っ り、ノイズ情報も混 る。 • 生成AI 一度に記録・利用で るデータ量には上限 ある。 • ルンバ（ 掃除ロボット）を動 めに、床の物を片付 るのと同 。事前に整える。 構造化データと同 ようにデータの整理 必要 • 元のファイル（入口）→整理 情報（中間）→用途に必要な情報（出口）を整備 る。 • “ゆ ”の3層構造の「データレイク層」「データウェアハウス層」「データマート層」に該当。 の領域は生成AIの台頭に伴って急進化 始まっ フェーズ • 現時点で れ というリファレンスアーキテクチャ 定まっていない。 • データの持 方も定まっていない。テキストを書 直 もの、文書ベクトル、グラフ構造 etc…？ • 対応 るソリューションも違う。BigQuery、Vertex AI Feature Store、Spanner Graph etc…？ ◦ グラフDBの構築はToo MuchなのでGIS機能と似 位置付 のBigQuery Graph 欲 い。 123 ソース 水源 レイク 湖 = 蓄積 る ウェアハウス 倉庫 = 管理 る マート 市場 = 売る ユーザー 利用者
124. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 124 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
125. 8. データ提供
126. 主な技術要素（詳細版） 126 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
127. Google Sheets（Googleスプレッドシート）でのデータ抽出・集計 シートでの柔軟なデータ分析 • N1分析：BigQuery らデータを抽出 て、顧客や商品、取引など1件1件のデータを確認 る。 ◦ Connected Sheet機能でBigQueryのWideテーブルやSummaryテーブルに接続 る。 • ピボット集計：カテゴリ別ｘ月次の注文総額といっ 簡易的な集計ならピボットシートで完結。 • アドホック分析：顧客や商品のセグメント分類、ファネルｘコホートで離脱ポイント特定など。 • モニタリング：主要指標を計測シートにまとめて、日次＜週次＜月次で計測で るように る。 ◦ 取締役会や投資家向 Google Slidesにシートを貼り付 て1クリックでデータを更新。 利用者本人 シートを編集 る世界観（セルフサーブ型） • 素早 、柔軟に、欲 いデータ 手に入る。 ◦ 10分で30点のアウトプット。 れで十分なケースも。 ◦ 試行錯誤を通 て「筋の良い計測」に辿り着 。 • データ分析職に依頼 るストレス ら解放 れる。 ◦ 「要件を決めて い」ばっ 言って る 。プロの提案 欲 いのに。 ◦ なん 期待 のと違うもの で る 。ビジネス理解 浅 ない？ ◦ ぶっ ゃ 依頼者 自分でやっ ほう 早い 。ダラダラやるの勘弁 て。 127 https://cloud.google.com/bigquery/docs/connected-sheets
128. Looker Studio（旧Googleデータポータル、Google Data Studio）でのモニタリング ダッシュボードを直感的に作成 • Google Sheetsの集計 ら「ダッシュボードで定点観測 べ 指標」を特定 、反映 る。 • BigQueryのBI連携テーブルに接続 て、LookerStudioでグラフ とにフィルタリングを行う。 • ソースコード管理はで 、開発AIエージェントとの相性は悪いので注意。 128 https://codelabs.developers.google.com/codelabs/community-connectors#0 https://cloud.google.com/billing/docs/how-to/visualize-data
129. 生成AIによるアドホック分析 ジュニア分析者より正確で、シニア分析者より早い＆安いアウトプット • GeminiチャットやNotebookLMによるデータ分析レポートの作成。 • Claude Desktop等のサードパーティツール らBigQueryを参照 る事例も散見 れる。 MCP経由で加工済みテーブルにアクセス • 本資料作成時点で主流なのはBigQueryのMCPを経由 てデータを参照 る方法。 • 将来的にはGeminiやNotebookLM、Looker Studio Pro（対話エージェント機能）を社内提供 る アプローチ Google Cloudユーザーの主流になりうる。ま 高水準とは言えない 今後に期待。 • BigQueryでFact＆Dimension（ま は れらを結合 Wide or Summary）テーブルに接続 る。 129
130. チャットツールへの自動配信 毎朝の始業時間に、前日の経営状況をSlackで通知 • 実現方法と ては以下い れ 簡単。 ◦ Cloud Run functionsでPythonスクリプトを実行 る。 ◦ Google App Script（GAS）でGoogle Sheetsの内容を送信 る。GASのソースコードは、 clasp / GitHubでソースコードを管理 るとメンテナンスや挙動 安定 る。 • BigQuery側で計測対象となるデータを整備 る。 ◦ BigQuery側でビジネス指標を固定 る（日次で締める） めのmetricテーブルを用意 る。 ◦ BigQuery ML による異常検知（Anomaly Detection）にて、急激な数値の変動 あれば、 レポート対象と て含めるように設定 る。 130 https://speakerdeck.com/yuzutas0/20211210?slide=27 https://cloud.google.com/blog/products/data-analytics/bigquery-ml-unsupervised-anomaly-detection
131. CRMツールや広告媒体などの外部連携 各ツールの機能を120%活 、一度は夢見 「データ活用構想」を実現 • SalesforceやKintoneへのデータ入力。営業やCS向 に法人情報や利用状況を受 渡 。 • メルマガやLINE、プッシュ通知など、顧客へのパーソナライズ or セグメンテーション配信。 • Google広告やInstagram広告などのリターゲティング配信。 外部システムへの連携処理をステップバイステップで構築 • ま はExcelでのリスト作成を自動化。担当者 BigQueryコンソール画面 らリストをCSV形式で ダウンロード 後、対象システムのコンソール画面に手動アップロード。 • の後に連携作業を自動化。Cloud Run functionsでPythonスクリプトを実行 、対象システムの WebAPIへと受 渡 。Reverse ETLと呼ばれる仕組み。 連携先システムのアップロード項目に合わ データで作成 • 各チーム BigQueryのteamテーブル（ビュー）でSQLを書いて試行錯誤。 • 要件 固まっ らsysテーブルに移管 、品質チェックの対象と る。 131 https://www.salesforce.com/jp/campaign/lightning/
132. NotebookやFeature Storeによるデータサイエンス BigQuery Notebook（Jupyter Notebook / Google Colab Enterprise相当）での統計解析 • 四則演算ベースの集計はSQLで済ま 、ノートブックでは定量的な予測や解釈を行う。 • 例：値上 の影響、購買促進のハブとなるコンテンツの特定、自然成長や季節変動や景気連動や需要 の先食いを除去 マーケティングキャンペーン効果の推定。 BigQuery内のデータで機械学習を行い、Vertex AI Feature Store 経由でプロダクトに組み込み • プロダクト内に る商品、コンテンツ、物件、人材のレコメンド機能など。 • Notebookでアドホック分析 後、機械学習のモデルやパイプラインに組み込む。 ※必要に応 てBigQueryの（加工前）rawテーブルや（前処理済み）adapterテーブルを参照 る。 132
133. Gemini Enterprise等のAIエージェントによる業務効率化・自動化 業務フローを整理 て、作業・判断を「システムで完結 る」「AI 担う」ように置 換えてい • AIエージェントの設計プロセスについては後述。 • システム構成はGemini Enterpriseのデータ連携スライドを参照。他システムでも似 構成となる。 • 本資料作成時 とGemini Enterpriseはま 理想とギャップ ある。 ◦ Google Workspaceとネイティブ連携で る強み ら、将来的な進化に期待 い。 ◦ 直近はDifyやn8nのほう 期待像に近い。コード管理もほ い。Opal 主流になる 。 例：法人顧客の離反検知とフォローアップの（半）自動化 1. BigQueryで法人顧客の利用状況を収集 2. 日次集計で離反の可能性を検知（＝事前定義 セグメントに分類） 3. Googleカレンダーで営業担当者の空 日程を確認 4. Gメールで対象顧客に打 合わ のアポイントメントを送信 5. Google Slidesで提案スライドの草案を作成 6. Google Docsで打 合わ 台本の叩 台を生成 7. Salesforceにフォローアップ状況を入力・更新 133 https://cloud.google.com/blog/products/ai-machine-learning/bringing-ai-agents-to-enterprises-with-google-agentspace
134. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 134 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
135. 9. メタデータ管理
136. 主な技術要素（詳細版） 136 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
137. メタデータ • データを説明 るデータの とをメタデータと呼ぶ。 • 図書館に対 る図書目録のように、利用者 様々な着眼点 らデータを見つ られるように る。 ◦ 例：「価格」（price）データの「100」 「100円」なの 「100ドル」なの 分 らない。 • 様々な分類 ある。 ◦ 「データソースに紐づ 情報」「データ加工に紐づ 情報」「データ利用に紐づ 情報」など。 ◦ 「システム 自動で付与 る情報」「人間 工数を費や て付与 る情報」など。 137 『実践的データ基盤への処方箋』より
138. データ活用で必要になるメタデータ（1/4） • テーブルの用途や作成経緯。 • カラム名、型、制約（ユニーク、NotNull）、値の範囲などのスキーマ情報。 • 問い合わ 先。 • 類似データとの使い分 。 • 一緒に使う と 多いテーブル。 138
139. • よ ある質問と回答例（FAQ）。 • 既知のエラーケース。 ◦ 例：◯◯日〜◯◯日はシステムトラブルでデータ 0件になっている。 • 機密情報に該当 る 。 • データの更新頻度やタイミング。 • データの依存関係。 データ活用で必要になるメタデータ（2/4） 139
140. • 代表的なクエリ例。 • 複雑なデータ仕様、状態遷移、ドメイン用語の解説。 データ活用で必要になるメタデータ（3/4） 140
141. データ活用で必要になるメタデータ（4/4） • データ利用状況 ◦ 誰 、いつ、ど で、どのデータを参照・利用 るの 。 ◦ 後述 る監査ログを用いる。 • データ生成過程（DGP：Data Generation Process） ◦ データ 生成 れると の業務フロー。 ◦ 誰 、いつ、ど で、どのデータを記入・更新 るの 。 ◦ GoogleDriveや社内Wikiにあるマニュアルを転用 る。 141
142. Google Cloudに るデータカタログ機能 • Google Cloudのコンソール画面 らデータカタログ機能を利用で る。 ◦ Data Catalog → Dataplex Universal Catalog とリブランディング。 • Googleアカウントでログイン て、データを探 り、メタデータを入力で る。 ◦ データセット（スキーマ）、テーブル、カラム れ れに説明文を記載で る。 ◦ 個人情報などのタグをつ る ともで る。 • BigQueryの利用補助AIはデータカタログの情報を主に参照 る め、充実 て と良い。 • 集計ロジックの図解やデータ横断のルールなどは扱えない め、社内Wikiの整備 別で必要となる。 142
143. 「データの説明文」には「横断のルール」と「個別の説明」 ある 143 ＜例＞ 横断のルール 固別の説明 データセット （スキーマ） productA_xxxは製品Aの teamB_xxxはチームBのデータを扱う 同 GA4のエクスポートデータでも、 ◯◯はサイトA、△△はサイトBを扱う テーブル raw_xxx、dim_xxx、fact_xxx、 wide_xxxの使い分 paymentsテーブルは◯◯で、 salesテーブルは△△を扱う カラム dwh_xxxはDWH側で加工 データ、 _maskedはマスキング済みのデータ customer_name_maskedカラムは 顧客名（マスキング済み）を扱い、 退会 後はNullで上書 れる 横断ルールの 設定ファイル 個別説明の 設定ファイル 両者を統合 データ説明文 データカタログの 説明欄 統合 統合 反映 • データセット、テーブル、カラム れ れに「横断のルール」と「個別の説明」 ある。 • の両方 揃って初めてデータ利用者やAIはデータを正確に使えるようになる。 • データカタログでは「横断のルール」を分 て管理で ない め、全てのデータの説明文の中に、 同 「横断のルール」を書いて な ればならない。 • 「横断のルール」と「個別の説明」は別の設定ファイルで管理 て 、メタデータ統合システムで 両者を統合 て らデータカタログに連携 る。
144. 非構造化 データ 構造化 データ メタデータ管理の3層構造（1/2） メタデータも、収集（入口）→統合（中間）→提供（出口）の3層構造でパイプライン化 れる。 144 RDBMSのスキーマ情報 ＠DDL SFDCで入力 る データ項目 ＠管理シート Dataform 加工 る BigQueryテーブル仕様 ＠設定ファイル BigQuery コンソール画面の クエリ作成補助AI （Gemini） 各AIチャットへの データ分析依頼や 問い合わ データ利用ガイド 社内ポータル Dataplex Universal Catalog 一連のデータ仕様と クエリ生成のコツを 組み込ん 社内MCPサーバ 一連のデータ仕様を SphinxやJekyllなどの サイトジェネレーターに 反映 基幹システム 顧客管理システム （CRM） BigQuery 加工テーブル BigQuery 利用記録 Cloud Logging 出力 る監査ログ ＠監査ログ 顧客対応システム Zendeskの入力手順 社内マニュアル ＠GoogleDocs 取得元 メタデータの入口 メタデータの出口 利用先 メタデータの中間 GitHubの 専用リポジトリ メタデータ管理プログラム
145. メタデータ管理の3層構造（2/2） 前提：システムで自動化で るものは自動化 、人間は人間に 扱えない情報に専念 る。 • システムで自動生成 れ メタデータは うと分 るように自動生成のラベルをつ る。 • 人間 チェック ら認証済みのラベルを、管理部門 承認 ら「公式」ラベルをつ る。 入口：データを生成 る人 、データを生成 る箇所で、メタデータを管理 る。 • 例：SFDCの設定は管理者 シートで管理。RDBMSのスキーマはSREチーム DDLで管理。 • 理由1：データ基盤以外の通常業務でも使う め。何ら の形でメタデータは必要。 • 理由2：データ利用者 事後調査 ると1日 る。担当者本人 事前記入 ると10分で済む。 中間： れ れのメタデータを集約管理 る。 • 現状、 を満 るツール 世にない め、各社 GitHub管理の仕組みを作っている。 出口：メタデータの利用箇所に合わ 場所・形式でメタデータを連携 る。 • 例：GeminiでBigQueryを使う場合はDataplex Universal Caralogにメタデータ 必要。 145
146. Google Cloudに るメタデータ管理の補助機能 • グロッサリー（辞書）：「売上」等のキーワードを設定 、関連データを紐づ る。 • データプロファイリング：nullの割合、一意となる値の割合、平均、標準偏差、最大、最小、四分位数 といっ 統計情報を確認 る。 • データリネージ（依存関係）：どのテーブル どのテーブル ら作成 れている 、を管理 る。 146 https://cloud.google.com/data-catalog/docs/concepts/about-data-lineage https://cloud.google.com/blog/products/data-analytics/dataplex-business-glossary-now-ga
147. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 147 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
148. 10. データ品質
149. 主な技術要素（詳細版） 149 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
150. 風音屋 定義 るデータ品質の5分類 数十種類の「データ品質」を大ま にまとめると以下の5種類になる。①〜⑤の順に依存関係 ある。 例：① 不十分 と②〜⑤を正確に計測で ない。② 不十分 と③で見るべ データ 存在 ない。 150 ②データ 適切な場所に置 れている （可用性・即時性・最新性・回復性・移植性） ③データの中身 現実を正確に表現 ている （正確性⊇完全性、一意性、一貫性、有効性、精度） ④適切な人 適切なデータにアクセスで る （アクセシビリティ・機密性） ⑤データ 使いや い状態になっている （ユーザビリティ⊇理解性、効率性、標準適合性） ①活動を追跡で る（追跡可能性・信憑性）
151. SLO（サービスレベル目標）をステークホルダーと合意 る • 誰も望んでいないのに過剰な目標を追って まうと、徒労で終わる。 • 部署や用途 とに暗黙的に期待 れている品質目標を洗い出 、明文化 て、関係者と合意 る。 151 例 用途 約束相手 連絡先 利用データ 期待品質 未達時の影響範囲 1 日次 レポート マーケター Slack #daily_kpi BigQueryの 売上テーブル 毎営業日の8時までに 欠損な 前日売上 レポート れる と （即時性） 売上状況に応 施策 打てな なる （機会損失） 2 … … … … … … 3 … … … … … … … … … … … … …
152. テスト・監視 Dataformによる定期データ集計時に、チェックを行う。 • Dataformの集計処理の成否。 • 各テーブルの更新日時、レコード件数、nullや空白の有無、値の範囲など。 • 処理エラーとなる場合はシステム管理者に通知を送る。 152 https://cloud.google.com/dataform/docs/assertions
153. データ利用者への案内 • ダッシュボードのトップ画面に「🚨現在判明 ている問題🚨」欄を設 て、検知可能に る。 • システム管理者への通知とは別に、データ利用者にチャットBotで速報を送る。 153
154. システムチューニング • 品質の目標と現状のギャップ 大 い箇所（ボトルネック）を特定 、原因を特定 る。 • 例えば、「朝8時までに売上集計を終わら る」（即時性） 担保 れていない場合、集計処理のう どの部分に時間 っているの を確認 る。 • の上で、以下のようなチューニング施策を実施 る。 ◦ 「全件更新」 ら「差分更新」に切り替える。前日分 を集計 る。 ◦ 「クラスタリング」や「パーティション」でデータの参照範囲を区切る。 ◦ 処理Aの後に処理Bを行う「直列実行」 ら、A・Bを同時に行う「並列実行」に切り替える。 154 処理時間 最も長い箇所（＝ボトルネック）をチューニング る
155. 週次ミーティングで改善サイクルを回 • 毎週の振り返りミーティングで現状（AsIs）と期待（ToBe）を比べる。 • の週のインシデント（トラブル）一覧を読み返 。 • サービスレベル目標（SLO）を満 ていな れば、改善アクションの めのTODOを起票 る。 ◦ 例：新規データ連携を後回 に てパフォーマンスチューニングを優先 る。 • サービスレベル目標（SLO）自体を見直 。 ◦ 過大目標であれば下方修正（e.g. 未使用ダッシュボードはメンテナンス に除却 る） ◦ 過小目標であれば上方修正（e.g. データ更新頻度を毎週 ら毎日に変更 る） 155 What 何を る スプリント レビュー どうやって る How スプリント プランニング レトロ スペクティブ デイリー スクラム
156. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 156 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
157. 11. データセキュリティ・権限管理
158. 主な技術要素（詳細版） 158 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
159. データセキュリティで実現 い と 159 よ ある相談例 BigQueryで個人情報を扱うのは、カスタマーサポート（CS）部門の「問い合わ 対応」業務のみと い 要件（Requirements）を言語化 ると？ ①ルール違反を ない。 • 個人情報保護法に準拠 い。 • カスタマーに提示 ている利用規約やプライバシーポリシーに準拠 い。 • 個人情報取扱に関 る社内規程に準拠 い。 ②「顧客ID」は使い い。 • 厳密な「個人情報」の定義 と「顧客ID」も含まれて まう ……。 ◦ 規約や用途によっては顧客IDの利用もNGになる と あるので注意！ • 顧客IDなどの仮名加工情報（ れ単体では個人を特定で ない情報）はOKと い。 • 氏名やメールアドレスなど、特定個人を直接的に表 情報のみNGと い。 　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　etc…
160. データセキュリティの設定（全体像） 160 BigQueryのセキュリティ対策手順 - 風音屋TechBlog　https://techblog.kazaneya.com/20220830-bigquery-secure-guide/ 与件となるルール・規程（文書で管理） 例 位置付 項目 法令 個人情報保護法 顧客合意 利用規約・プラポリ or 契約書 社内ルール 個人情報取扱に関 る社内規程 取り扱うデータの種別（シートで管理） 例 対象データ 種別 氏名 特定個人を 直接的に表 情報 メールアドレス 顧客ID 仮名加工情報 メールアドレスのハッシュ値 機密性レベル（シートで管理） 例 レベル データ種別 提供範囲 2 特定個人を 直接的に表 情報 特定部署のみ 1 仮名加工情報 社内限 アクセス制御（Terraformで管理） 例 PJ レベル 通信要件 認証・認可 gcp-pii-pj 2 CS部門用の VDI経由のみ CS部門社員に 閲覧権限を付与 gcp-bi-pj 1 社内VPNで アクセス可能 複数部門社員に 閲覧権限を付与 監視・監査（GCS等で管理） 例 データ混入や権限付与ミス、 意図 ないデータアクセスなどの ガイドライン違反を自動検知＆都度チェック データセキュリティを担保 るにあ って 「規程」と「データ種別」 ら「機密性レベル」を定め、 通信要件（N/W）と認証・認可（IAM）を設定 る。 ま 、要件に沿って運用 ている とを監視・監査 る。
161. データセキュリティの設定（1/3） 与件となるルール・規程（文書で管理） • 法令：個人情報保護法、金融商品取引法（インサイダー規制）、電気通信事業法（通信の秘密） • 認証基準：PCI DSS、Pマーク • 契約事項：利用規約、各取引先との契約書 • 社内規則：情報管理規定、セキュリティ細則 取り扱うデータの種別（シートで管理） • PII（個人識別情報） • PHI（個人健康情報） • インサイダー情報（財務データなど） • 契約上の制限に抵触 る情報 • 競争上の優位性に関わる情報 • 企業秘密に関わる情報 • 公開 ている情報 161 BigQueryのセキュリティ対策手順 - 風音屋TechBlog　https://techblog.kazaneya.com/20220830-bigquery-secure-guide/ 与件となるルール・規程（文書で管理） 例 位置付 項目 法令 個人情報保護法 顧客合意 利用規約 or 契約書 社内ルール 個人情報取扱に関 る社内規程 取り扱うデータの種別（シートで管理） 例 対象データ 種別 氏名 特定個人を 直接的に表 情報 メールアドレス 顧客ID 仮名加工情報 メールアドレスのハッシュ値
162. データセキュリティの設定（2/3） 機密性レベル（シートで管理） • 社外公開 • NDAの範囲内で共有 • 社外秘 • 限定共有：特定の役職、部署、プロジェクトメンバー アクセス制御（Terraformで管理） • 通信要件 ◦ システム構成図 ら通信経路を網羅 る ◦ アクセス元ｘアクセス先Bｘ権限（許可｜禁止） ◦ VPC Service Controls • 認証・認可 ◦ シート らデータ操作の組み合わ を網羅 る ◦ 対象者グループｘ対象データｘCRUD権限 ◦ Cloud IAM 162 BigQueryのセキュリティ対策手順 - 風音屋TechBlog　https://techblog.kazaneya.com/20220830-bigquery-secure-guide/ 機密性レベル（シートで管理） 例 レベル データ種別 提供範囲 2 特定個人を 直接的に表 情報 特定部署のみ 1 仮名加工情報 社内限 アクセス制御（Terraformで管理） 例 PJ レベル 通信要件 認証・認可 gcp-pii-pj 2 CS部門用の VDI経由のみ CS部門社員に 閲覧権限を付与 gcp-bi-pj 1 社内VPNで アクセス可能 複数部門社員に 閲覧権限を付与
163. データセキュリティの設定（3/3） 監査・監視（GCS等で管理） • 監査ログの取得・保存 ◦ 各サービス とに取得可能なログ 異なる め、仕様詳細を確認・調査 る ▪ 例：本資料作成時点でBigQueryの「Save results」の監査ログは誤検知 うる ◦ Cloud LoggingやGoogle Workspace管理機能で監査ログを取得 る ◦ 他環境 ら独立 監査用Google CloudプロジェクトのGCSに保存 る • 監査ログの参照 ◦ アラート条件で不審な変更・作業を早期検知 ◦ トラブル発生後に事後調査 ◦ 定期・不定期の監査でログを確認 • Google Cloudの自動チェックサービスで補完 ◦ Security Command CenterでCISベンチマークによる自動チェック ◦ Cloud DLPによる機密情報の混入チェック 163 BigQueryのセキュリティ対策手順 - 風音屋TechBlog https://techblog.kazaneya.com/20220830-bigquery-secure-guide/ BigQuery の「Save results」をモニタリング る めの現実的なアプローチ - 風音屋TechBlog　 https://techblog.kazaneya.com/20250714-bigquery-save-results-audit-log/ 監視・監査（GCS等で管理） 例 データ混入や権限付与ミス、 意図 ないデータアクセスなどの ガイドライン違反を自動検知＆都度チェック
164. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 164 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
165. 12. コスト管理
166. 主な技術要素（詳細版） 166 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
167. Cloud Billingによるコストモニタリング • 毎月のコストや内訳は Cloud Billing のコンソールで確認可能。 • 個人やスタートアップ 無料サービスを中心に活用 れば、コスト 問題になる とは少ない。 ◦ 嘉悦大学では月2万円でデータ基盤を運営。書籍『アジャイルデータモデリング』事例集より。 ◦ 数百円/月で業務利用 ているケースもある。 167 https://cloud.google.com/billing/docs/how-to/cost-breakdown https://cloud.google.com/billing/docs/reports
168. 監査ログによるBigQuery利用金額のモニタリング • Cloud Logging→GCS→BigQuery→LookerStudioに連携 て、BigQueryの利用金額を可視化 る。 ◦ 利用金額 高い or 増えている「チーム > ユーザー」x「テーブル」 チェック る。 • Cloud Logging→Cloud Monitoringでアラート設定を行って、高額クエリ検知時にSlack送信 る。 • パフォーマンス・チューニングと同様に、余分なスキャンや集計処理を削ってい 。 ◦ システム 毎日データを集計 ているのにユーザー 使っていない場合はクリーニング る。 168 BigQueryのコスト可視化ダッシュボードを10分で作る - 下町柚子黄昏記 https://yuzutas0.hatenablog.com/entry/2018/12/18/160000 データレイク構築後の四方山話 #DPM / 20190905 https://speakerdeck.com/yuzutas0/20190905?slide=27
169. Snowflake の Cost Management ダッシュボード • 標準機能で高コストのウェアハウス（インスタンスのようなもの）やクエリを探 る。 • プラットフォームにバンドル れるDBではな 、DB自体 メインのサービスならではの機能。 169 https://www.snowflake.com/en/blog/cost-management-interface-generally-available/
170. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 170 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
171. 13. 継続的開発を支える技術
172. 主な技術要素（詳細版） 172 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
173. 開発標準・開発環境（1/2） 173 ▪ リポジトリ：コードの置 場。 • Git：コードの差分や履歴を管理 るツール。AIエージェント ミスを ても復旧で る。 • GitHub：Git管理のコードをチームで共有 、開発を進めてい めのツール。 • GitHub Actions：GitHubの機能。Linterや自動テスト、Terraform等の処理を実行で る。 ▪ CI（継続的インテグレーション）：継続的にコードを開発 、安全 つ効率的に統合 る。 • Linter：コード 社内ルールに沿っ 書 方になっている とを自動チェック る仕組み。 ◦ 例：PythonならRuff、SQLならSQLFluff、TerraformならTFLint、。 • 自動テスト：コード 期待通りに挙動 る とを自動でチェック る めの仕組み。 • Code Rabbit：GitHubで人間の代わりにコードレビュー て れるAI。 ◦ 「シニアデータエンジニアと て振る舞って」「若手に助言 るようにレビュー て」 「若手の反論 甘 っ ら徹底的にツッコミ て」と設定 ると、丁寧に教えて れる。 ▪ CD（継続的デリバリー）：継続的にコードを本番環境へとリリース る活動。 • Terraform：クラウドインフラをコードで管理 て、自動構築 る めのツール。 ◦ IaC（Infrastructure as Code）なる概念。画面操作と異なり、作業ミス防止や横展開 容易。 ◦ 例：BigQueryの設定をコードで管理 て、GitHubでレビュー 通っ ら自動反映。
174. 開発標準・開発環境（2/2） 174 ▪ 開発標準：自社のルールを決め り、仕組みを自動化 る とで開発効率を上 る。 • テンプレート：要件定義フォーマット、セキュリティ設計シート、コスト計測シート etc…。 • 規約／ガイドライン：Pythonコーディング規約、SQL規約、データモデリング標準 etc…。 ▪ 開発AIエージェント：Terraformを含めて一連のプログラムを自動実装 るツール。 • Cursor：ローカル環境のIDEでユーザーに編集提案 て れる。 • Claude Code：ローカル環境のターミナルで自律開発 て れる。Gemini CLIも の立 位置（？） • Claude Code Actions：GitHubでのユーザーコメントをもとに自律開発 て れる。 • Devin：Slackでのユーザーコメントをもとに自律開発 て れる。 ◦ データ分析者 Gemini支援の元でSQLを作り、SlackでDevin君にパイプライン追加を依頼。 ⇒風音屋では一連のデータ基盤システムを クライアント 最短工数で利用開始で る仕組みを構築中。 本資料のように「データ基盤の構築や運用」といっ 業務を 1つ1つ言語化 、手順化 、システムに反映 る とで 徐々に「AI Ready」な開発環境へ進化 てい （は ）！
175. 特にコードレビューの自動化は期待以上 っ 175 • 新規構築 dbtプロジェクトのPull Requestに対 て、メタデータ入力を促 コメント。 ◦ RAGのように参考資料を追加 とも、データエンジニアリングの要素も加味 て れる。 ◦ 今のと ろCode Rabbitのほう GitHub Copilotより期待に近い。 • AIやジュニア人材 作っ Pull Requestをレビュー ると に「最低限 は抑えてほ いなあ」 「 んなケアレスミスを指摘 て ら仕事 進まないよ」というラインをある程度指摘 て れる。 ◦ ブラッシュアップ れ 状態で手元にレビュー依頼 届 ので、従来比でストレス 9割減。
176. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 176 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
177. 14. データ利活用の促進
178. 主な技術要素（詳細版） 178 データ 取得元C データ 取得元B データ収集プログラム Python ファイル ストレージ （保存） GCS データウェアハウス （分析環境） BigQuery ダッシュボード BIツール アドホック集計 Google Sheets メルマガ配信 CRMツール 元データ 加工 データ プログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workflows データカタログ（データの説明） Dataplex Universal Catalog データ 取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質 権限管理 コスト
179. データ利用促進＝社内マーケティング • 毎月のデータ利用の人数（MAU） 増えている 、安定 ている 、をモニタリング る。 • どのチームで、どの水準までデータを利用で ている 、をモニタリング る。 • 次の注力支援先を決めて、ニーズを調査 、仕組みを整え、社内営業とサポートを行い、伴走 る。 179 株式会社風音屋（監訳）『アジャイルデータモデリング』より引用 チームA チームB チームC チームD チームE チームF 生ログ 独自利用 データT支援 業務依頼 データT支援 データ出力 自主的 データ出力 担当者 依存 自主的 データ生成 他チーム 依頼 基盤貢献！ 担当者 依存 担当者 依存 局所化 自走 改善 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops https://speakerdeck.com/yuzutas0/20211210
180. 監査ログによるBigQuery利用状況のモニタリング • Cloud Logging→GCS→BigQuery→LookerStudioに連携 て、BigQueryの利用状況を可視化 る。 • クエリ実行数 多い or 増えている「チーム > ユーザー」x「テーブル」 チェック る。 • 「既に活用 ているチーム」「ま 活用 ていないチーム」を把握 、社内営業やサポートを行う。 • 「活用ニーズ あるデータ」を優先 て充実 り、メンテナンス り、社内に宣伝 る。 180 BigQueryのコスト可視化ダッシュボードを10分で作る - 下町柚子黄昏記 https://yuzutas0.hatenablog.com/entry/2018/12/18/160000 データレイク構築後の四方山話 #DPM / 20190905 https://speakerdeck.com/yuzutas0/20190905?slide=27
181. データ利用ガイドを社内提供 • 「 で全体像 分 る」という社内Wikiを整備 る。 • ダッシュボードのトップに、利用案内のURLを掲載 る。 181
182. 社内勉強会やハンズオン • データ利用の流れを解説 り、実際に体験 てもらう場を設 る。 • 毎月の「相談会」で伴走 な ら分析レポートを作り、 のまま上司や経営陣、投資家に報告 る 流れになるとスムーズ。上司 ら「A案件はデータ相談会に持 もう」と声 掛 るようになる。 182
183. • チャットツールで相談場所を設 る。 ◦ データチームで運用当番を設 てユーザーサポートに当 る。 • よ ある問い合わ （FAQ）はWikiやデータカタログツールに反映 る。 ◦ 次 らはURLの案内 で済むように る。 ◦ ナレッジを充実 る とでAIの回答精度を高める。 • 自動対応 るチャットBotを構築 る。 ◦ Slackを窓口に るならGoogle CloudのConversational Analytics APIを用いて実装 る。 ◦ 今後はGemini EnterpriseやLooker (Studio Pro) のConversational Analyticsに期待。 ◦ データ項目追加や権限付与依頼はGitHub管理と 、Devin等の開発AIエージェントに任 る。 問い合わ 対応や作業依頼 183 分析相談 レビュー依頼 FAQ 充実化 再利用
184. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 184 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
185. 15. 生成AIによる5つの変化
186. 1. データ収集：オープンデータ取得やWEBスクレイピングでデータのバリエーション 増える。 2. データ加工：カジュアルに構造化データと非構造化データを相互変換で る。 3. メタデータ整備：入力・編集を自動化で る。生成AIにコンテキストを渡 めに関連機能 充実。 4. DataDevOps改善：データエンジニアリングに る一連の業務プロセスを自動化で る。 5. BizDevOps改善：「データ基盤」と「業務フロー」と「経営」 一体化 つつある？ 生成AI データプラットフォームにも ら 5つの変化 186
187. オープンデータ取得やWEBスクレイピングの難易度 下 り、扱えるデータのバリエーション 増える。 • 生成AI自身 持つWEB検索機能（例：Gemini CLI） • 生成AI らの操作に適 ブラウザの台頭（例：ChatGPT Atlas） • WEB画面（HTML）やシート構成（Excel） らの対象要素の抽出（※後述の非構造化データ） • WEB画面やシート構成の変更差分の特定 → 要素抽出スクリプトの修正（※後述の開発プロセス） 従来はWebAPIやDB らのデータ取得 主流で、以下のような場面・組織でないと持続不可能 っ 。 • アドホック分析で都度データを取得 る（例：マーケティング担当や研究者） • スクレイピング選任の開発チームを運営 る（例：法人データ提供会社） ①生成AIによる「データ収集」の変化 187 ゆ 編『個人開発をは めよう！- クリエイター25人の実践エピソード』の 第8章「格安スクレイピングを支える技術」（morizyun ん）では、 岡崎市立中央図書館事件を例に挙 てスクレイピングの注意点を紹介 ていま 。 AI開発を始める前に ひ読んで ま ょう！ ⚠スクレイピングや外部データ利用時は、規約やマナーを守りま ょう！
188. • PCを持 運ぶ めのバッグ検索サイト「HileSearch」（入るサーチ） ◦ 自分のノートPC ょうど っぽり入るサイズのカバン・バッグ・リュックを約1万の候補 ら探 出 「HileSearch」 - GIGAZINE • MacBookPro を持っている人には、MacBookPro より大 いサイズのバッグ を、一覧で表示 る • 検索機能を実現 る めには、PCとバッグ、 れ れのサイズに関 るデータ 必要 10年前は開発に数カ月 っ データ収集システム 188 ゆ （編）『個人開発をは めよう！』、ゆ （共著）『データマネジメント 30分でわ る本』より引用
189. • 政府統計や各社オープンデータはBigQuery Sharing機能で提供事業者 らデータ取得 可能。 • WEBコンテンツは、Python等のプログラム + Geminiでスクレイピングを行い、BigQueryに連携。 データ基盤システム （Google Cloud） 各提供者 各省庁等 【再掲】オープンデータによるデータ取得 189 WEB公開 コンテンツ 提供事業者A 政府統計 収集・加工 システム BigQuery 提供事業者B 各社 データベース BigQuery BigQuery BigQuery Sharing BigQuery Sharing インターネット 取得プログラム 例：Python Cloud Run functions ファイル 例：CSV, JSON GCS 保存 外部 テーブル HTTPリクエスト スクレイピング （Google検索） Gemini 取得 更新 更新 連携 HTTPリクエスト スクレイピング （ページ指定） 💡Webサービスの画面レイアウト変更時は、 エラーログとHTML文字列をもとに GitHub Issueを自動起票 てコーディングAIに パース処理を修正 てもら う！
190. データ収集SaaS 不要になる or データ収集SaaS AI対応 る データ収集用のETL SaaS（ETLツール）を使うメリット 減っている。 • もともと社内業務システム らのデータ抽出には向 ない。 ◦ 「通信量でコスト る料金体系」 つ「VPC外通信でのセキュリティ懸念」 重なる。 • 多様なSaaSや広告データを取得 るユースケースに向いてい （去年までは）。 ◦ 各WebAPIへのリクエスト処理をメンテナンス るよりも、ETL SaaSに頼るほう ROI 高い。 ◦ 、 の1年でAIエージェントやAIコーディングに任 られるようになっ 。 ▪ 現状 とデータ収集SaaSは不要になる。 オープンデータ取得やスクレイピングなど「データ収集」の業務自体は広 っている。 • む ろ生成AIのHuman in the loop管理など、仕組みを自前でメンテナンス る難易度は向上。 • データ収集SaaS 進化 て う 用途に対応で ると、引 続 使われる とになるは 。 ◦ 既存ベンダーはゆ に相談 て れ ら技術顧問＆宣伝協力 ま 。 • 既存ベンダー 後手に回れば、新興のデータ収集SaaS 台頭 るは （予言）。 ◦ ゆ にプロトタイプを持参 ら出資＆宣伝協力 ま 。PLAID んあ りも興味持つ 。 ◦ という 風音屋の内製ツールを外販 るの 最速？ 190
191. 機械学習システム構築の難易度 下 り、カジュアルに構造化データと非構造化データを相互変換で る。 • 従来は「選任の機械学習チーム」や「AutoMLツール」による専用システムの構築 必要 っ • 現在は「SQLのSELECT句を1行書 」（10秒） で変換処理を実行で るようになっ ②生成AIによる「データ加工」の変化 191 画像を準備する AIの回答を取得 SQLでAIを呼ぶ https://docs.cloud.google.com/bigquery/docs/reference/standard-sql/bigqueryml-syntax-ai-generate
192. 主要クラウドベンダー各位のトレンドと て、非構造化データの取り扱いを強化 ている。 • ストレージやデータウェアハウス製品に、画像やPDFなどの非構造化データを扱う機能 増え 。 • 生成AIのユースケースと て、 れらのデータを参照 るニーズ 増えている と 主な背景。 • 従来はテーブル形式の処理 メイン っ 、対象データのバリエーション 増え 。 Analytics製品の非構造化データ対応 進む 192
193. • 各ツール ら文章、画像、動画、PDFファイルなどの非構造化データを集約 る。 • システム 管理 る場合はGCSに置 、必要に応 てBigQueryにデータをロード る。 • 人間 管理 る場合はGoogle Driveに置 、必要に応 てGCSを経由 てBigQueryにロード る。 • BigQueryのObject Table機能でGCSの非構造化データを参照 、バイナリ形式で機械学習に利用。 データ基盤システム（Google Cloud） 【再掲】社内フォルダ等のデータ取得（ストレージに集約 る場合） 193 インターネット Google Workspace BigQuery ユーザー HTTP リクエスト ファイルを アップロード 各ファイル Google Drive 取得プログラム 例：Python Cloud Run functions 各ファイル GCS 保存 WebAPIコールやスクレイピング 各ツール 外部 テーブル HTTPリクエスト Web API コール HTTP リクエスト
194. 【再掲】非構造化データ ⇔ 構造化データ の変換 生成AIによる「非構造化データ」 ら「構造化データ」への変換（以下は例） • 商品名のテキスト → 商品カテゴリーの分類 → カテゴリー別の売上集計 可能になる • 自動車 撮影 路面写真 → リスク要因のラベリング → 走行データと合わ て事故予測の精度向上 • 代理店との会議メモやメール → キャンペーンの情報を抽出 → MMMに組み込んで広告効果推定の改善 生成AIによる「構造化データ」 ら「非構造化データ」への変換（以下は例） • 法人顧客の行動データ → 営業担当向 に追加提案メールのドラフトを生成 • 商品の在庫や注文のデータ → 今日推 べ 商品で「 んな人 買ってま 」訴求文面を生成 • 企業の募集要項と求職者の履歴書 → 条件ミスマッチを緩和 る めの修正提案メッセージを作成 194 風音屋TechTalk #4 発表資料より
195. 【再掲】非構造化データ in データパイプライン パイプラインに組み込む どう で2つのアプローチ 考えられる。 1. データパイプラインに組み込む場合。BigQuery ML GeminiでSQL らGeminiを実行 る。 2. 従来のパイプラインに組み込ま 、Gemini Enterpriseに各データを集約 てAI側で完結 る。 195 非構造化データ データパイプライン 構造化データ 非構造化データ ①生成AIで前処理 ②生成AIで出力作成
196. 【再掲】非構造化データの3層構造 Garbage In, Garbage Out（ゴミを入れ らゴミ 出て る） • 社内文書や動画ファイルはボリューム 多い割に、品質 低 っ り、ノイズ情報も混 る。 • 生成AI 一度に記録・利用で るデータ量には上限 ある。 • ルンバ（ 掃除ロボット）を動 めに、床の物を片付 るのと同 。事前に整える。 構造化データと同 ようにデータの整理 必要 • 元のファイル（入口）→整理 情報（中間）→用途に必要な情報（出口）を整備 る。 • “ゆ ”の3層構造の「データレイク層」「データウェアハウス層」「データマート層」に該当。 の領域は生成AIの台頭に伴って急進化 始まっ フェーズ • 現時点で れ というリファレンスアーキテクチャ 定まっていない。 • データの持 方も定まっていない。テキストを書 直 もの、文書ベクトル、グラフ構造 etc…？ • 対応 るソリューションも違う。BigQuery、Vertex AI Feature Store、Spanner Graph etc…？ ◦ グラフDBの構築はToo MuchなのでGIS機能と似 位置付 のBigQuery Graph 欲 い。 196 ソース 水源 レイク 湖 = 蓄積 る ウェアハウス 倉庫 = 管理 る マート 市場 = 売る ユーザー 利用者
197. 「データウェアハウス製品」 ら（AWS 言う）「データレイク」への揺れ戻 ？ • 非構造化データの中間加工のパターンやベストプラクティスはま 決まっていない。 ◦ ベクトル化やグラフ構造など、非構造化データを扱う めの作法 複数あり、解 定まらない。 ◦ 非構造化データモデリング分野の体系化とソリューション実装 必要なフェーズ。 • 必要なツールや機能もま 出揃っていない。 ◦ 次の3年間は状況 日々変わってい ように思える。 ◦ 現時点では既存のリファレンスアーキテクチャを踏襲 、3年後に式年遷宮でも良い も。 • クラウドストレージに元データを置いて いて、後 ら修正で るように て の 大事。 ◦ AWS 言う「データレイク」本来のコンセプトに（一周回って）立 戻る。 ◦ 一方で、2010年代はAWS + Snowflake構成 人気 っ ように、DWH製品に寄 る世界観 グローバルで受 入れられて 。 ◦ 両者の擦り合わ な れて、次の進化 起 るタイミング。ま に技術の螺旋。 197 https://speakerdeck.com/twada/understanding-the-spiral-of-technologies-2025-edition
198. 補足：AWSに る（主にS3を中心と ）データレイク データウェアハウス、データレイク、 よびデータマートは、異なるクラウドストレージソリューション で 。（中略） データウェアハウスは、構造化 れ 形式でデータを格納 ま 。 れは、分析 よびビジネスインテリ ジェンス用に前処理 れ データの中心的なリポジトリで 。（中略） データマートは、企業の財務部門、マーケティング部門、営業部門など、特定のビジネスユニットのニー ズに対応 るデータウェアハウスで 。（中略） 一方、データレイクは、生データと非構造化データの中心的なリポジトリで 。最初にデータを保存 、 後で処理で ま 。 https://aws.amazon.com/jp/compare/the-difference-between-a-data-warehouse-data-lake-and-data-mart/ https://aws.amazon.com/jp/big-data/datalakes-and-analytics/datalakes/ 198
199. １）生成AI⇒メタデータ：生成AIによってメタデータ拡充 容易になる。 • メタデータの一部は「非構造化データ」であり、従来は人間 入力・編集 る必要 あっ 。 • 生成AIによって非構造化データを自動処理で るようになり、メタデータ拡充 容易となっ 。 ２）メタデータ⇒生成AI：生成AIを使う めにメタデータ拡充 必要になる。 • もともとデータカタログ機能強化のトレンド あっ 。生成AIへの需要で らに加速。 ◦ 2020年前後に大手各社でもデータウェアハウス製品 普及 、カタログ管理の課題 顕在化。 • 生成AIにコンテキストを与えて処理精度を改善 るにはメタデータの整備 必要となる。 ◦ 主要クラウドベンダー各位のトレンドと て、AIエージェント関連の機能提供とセットで メタデータ整備に関 る機能を強化・充実 ている。 ③生成AIによる「メタデータ整備」の変化 199
200. 非構造化 データ 構造化 データ 【再掲】メタデータ管理の3層構造（1/2） メタデータも、収集（入口）→統合（中間）→提供（出口）の3層構造でパイプライン化 れる。 200 RDBMSのスキーマ情報 ＠DDL SFDCで入力 る データ項目 ＠管理シート Dataform 加工 る BigQueryテーブル仕様 ＠設定ファイル BigQuery コンソール画面の クエリ作成補助AI （Gemini） 各AIチャットへの データ分析依頼や 問い合わ データ利用ガイド 社内ポータル Dataplex Universal Catalog 一連のデータ仕様と クエリ生成のコツを 組み込ん 社内MCPサーバ 一連のデータ仕様を SphinxやJekyllなどの サイトジェネレーターに 反映 基幹システム 顧客管理システム （CRM） BigQuery 加工テーブル BigQuery 利用記録 Cloud Logging 出力 る監査ログ ＠監査ログ 顧客対応システム Zendeskの入力手順 社内マニュアル ＠GoogleDocs 取得元 メタデータの入口 メタデータの出口 利用先 メタデータの中間 GitHubの 専用リポジトリ メタデータ管理プログラム
201. 【再掲】メタデータ管理の3層構造（2/2） 前提：システムで自動化で るものは自動化 、人間は人間に 扱えない情報に専念 る。 • システムで自動生成 れ メタデータは うと分 るように自動生成のラベルをつ る。 • 人間 チェック ら認証済みのラベルを、管理部門 承認 ら「公式」ラベルをつ る。 入口：データを生成 る人 、データを生成 る箇所で、メタデータを管理 る。 • 例：SFDCの設定は管理者 シートで管理。RDBMSのスキーマはSREチーム DDLで管理。 • 理由1：データ基盤以外の通常業務でも使う め。何ら の形でメタデータは必要。 • 理由2：データ利用者 事後調査 ると1日 る。担当者本人 事前記入 ると10分で済む。 中間： れ れのメタデータを集約管理 る。 • 現状、 を満 るツール 世にない め、各社 GitHub管理の仕組みを作っている。 出口：メタデータの利用箇所に合わ 場所・形式でメタデータを連携 る。 • 例：GeminiでBigQueryを使う場合はDataplex Universal Caralogにメタデータ 必要。 201
202. データエンジニアリングに る一連の業務プロセスを効率化 、サイクルタイムを短縮で る。 • システム開発：コーディング、テスト、レビューの自動化 • システム運用：リリース、監視、アラート対応の自動化 • サービス運用：問い合わ 対応、権限管理、コスト管理の自動化 • データ分析：数値変動調査、探索（EDA）、レポートの自動化 ④生成AIによる「DataDevOps」の変化 202
203. 【再掲】開発標準・開発環境（1/2） 203 ▪ リポジトリ：コードの置 場。 • Git：コードの差分や履歴を管理 るツール。AIエージェント ミスを ても復旧で る。 • GitHub：Git管理のコードをチームで共有 、開発を進めてい めのツール。 • GitHub Actions：GitHubの機能。Linterや自動テスト、Terraform等の処理を実行で る。 ▪ CI（継続的インテグレーション）：継続的にコードを開発 、安全 つ効率的に統合 る。 • Linter：コード 社内ルールに沿っ 書 方になっている とを自動チェック る仕組み。 ◦ 例：PythonならRuff、SQLならSQLFluff、TerraformならTFLint、。 • 自動テスト：コード 期待通りに挙動 る とを自動でチェック る めの仕組み。 • Code Rabbit：GitHubで人間の代わりにコードレビュー て れるAI。 ◦ 「シニアデータエンジニアと て振る舞って」「若手に助言 るようにレビュー て」 「若手の反論 甘 っ ら徹底的にツッコミ て」と設定 ると、丁寧に教えて れる。 ▪ CD（継続的デリバリー）：継続的にコードを本番環境へとリリース る活動。 • Terraform：クラウドインフラをコードで管理 て、自動構築 る めのツール。 ◦ IaC（Infrastructure as Code）なる概念。画面操作と異なり、作業ミス防止や横展開 容易。 ◦ 例：BigQueryの設定をコードで管理 て、GitHubでレビュー 通っ ら自動反映。
204. 【再掲】開発標準・開発環境（2/2） 204 ▪ 開発標準：自社のルールを決め り、仕組みを自動化 る とで開発効率を上 る。 • テンプレート：要件定義フォーマット、セキュリティ設計シート、コスト計測シート etc…。 • 規約／ガイドライン：Pythonコーディング規約、SQL規約、データモデリング標準 etc…。 ▪ 開発AIエージェント：Terraformを含めて一連のプログラムを自動実装 るツール。 • Cursor：ローカル環境のIDEでユーザーに編集提案 て れる。 • Claude Code：ローカル環境のターミナルで自律開発 て れる。Gemini CLIも の立 位置（？） • Claude Code Actions：GitHubでのユーザーコメントをもとに自律開発 て れる。 • Devin：Slackでのユーザーコメントをもとに自律開発 て れる。 ◦ データ分析者 Gemini支援の元でSQLを作り、SlackでDevin君にパイプライン追加を依頼。 ⇒風音屋では一連のデータ基盤システムを クライアント 最短工数で利用開始で る仕組みを構築中。 本資料のように「データ基盤の構築や運用」といっ 業務を 1つ1つ言語化 、手順化 、システムに反映 る とで 徐々に「AI Ready」な開発環境へ進化 てい （は ）！
205. • チャットツールで相談場所を設 る。 ◦ データチームで運用当番を設 てユーザーサポートに当 る。 • よ ある問い合わ （FAQ）はWikiやデータカタログツールに反映 る。 ◦ 次 らはURLの案内 で済むように る。 ◦ ナレッジを充実 る とでAIの回答精度を高める。 • 自動対応 るチャットBotを構築 る。 ◦ Slackを窓口に るならGoogle CloudのConversational Analytics APIを用いて実装 る。 ◦ 今後はGemini EnterpriseやLooker (Studio Pro) のConversational Analyticsに期待。 ◦ データ項目追加や権限付与依頼はGitHub管理と 、Devin等の開発AIエージェントに任 る。 【再掲】問い合わ 対応や作業依頼 205 分析相談 レビュー依頼 FAQ 充実化 再利用
206. 【再掲】生成AIによるアドホック分析 ジュニア分析者より正確で、シニア分析者より早い＆安いアウトプット • GeminiチャットやNotebookLMによるデータ分析レポートの作成。 • Claude Desktop等のサードパーティツール らBigQueryを参照 る事例も散見 れる。 MCP経由で加工済みテーブルにアクセス • 本資料作成時点で主流なのはBigQueryのMCPを経由 てデータを参照 る方法。 • 将来的にはGeminiやNotebookLM、Looker Studio Pro（対話エージェント機能）を社内提供 る アプローチ Google Cloudユーザーの主流になりうる。ま 高水準とは言えない 今後に期待。 • BigQueryでFact＆Dimension（ま は れらを結合 Wide or Summary）テーブルに接続 る。 206
207. 生成AI データを正 使う めには、データの整備 必要 50個の「売上テーブル」 存在 てい ら、生成AIはどの「売上」で分析 れば良い 判断で ない。 も も考え方や用途によって「売上」の定義は変わる。 • 消費税を含む？ • 途中解約はど に計上 る？ • 年間契約は月次で按分 る？ • 割引はど で差 引 ？ • 返金は後で差 引 ？ 購入時に遡って差 引 ？ • 通販サイトやアプリ決済の決済手数料を含む？ 年間契約を行っ 場合、ある分析では「今月の売上」 大幅に向上 と報告 ても、 別の分析 と月次で按分 ているので1/12の数字になる。 AI 生成 2つのレポートを見比べると「今月の売上」 10倍近 ズレる とになる。 207
208. 「fct_xxx」と「dim_xxx」のテーブル 用意 れている。 つまり れはディメンショナルモデリングで作られ テーブル 。 • 集計対象 fctで、切り口 dim ろう。 • れらのテーブルは「xxx_id」列で結合 れば良いの ろう。 • 1 らAI 集計 るのではな 、既に整備 れている 「按分売上」や「消費税抜」列を使えば良いの ろう。 • AI 事業年度を「4月 〜 翌3月」と推測 るのではな 、 整備 れている「事業年度」列を使えば良いの ろう。 生成AIによるデータ分析の品質 安定 、 従業員 カジュアルに生成AIに頼る と で るようになる。 テーブルの形式 明確 と生成AI 推論 や い 208
209. 他の有識者 の資料 Microsoft PowerBI はディメンショナルモデリング 前提となる。Copilot 機能を使う場合もま 然り。 https://www.docswell.com/s/yugoes1021/KRXVY2-2024-05-08-213110 メルカリ社のSocrates（分析AIエージェント）はBasic Tables（信頼で るテーブル）に依拠 ている。 https://note.com/mercari_data/n/n247a65af9bf5 209
210. 1. データ収集：オープンデータ取得やWEBスクレイピングでデータのバリエーション 増える。 2. データ加工：カジュアルに構造化データと非構造化データを相互変換で る。 3. メタデータ整備：入力・編集を自動化で る。生成AIにコンテキストを渡 めに関連機能 充実。 4. DataDevOps改善：データエンジニアリングに る一連の業務プロセスを自動化で る。 5. BizDevOps改善：「データ基盤」と「業務フロー」と「経営」 一体化 つつある？ 【再掲】生成AI データプラットフォームにも ら 5つの変化 210
211. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 211 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
212. 16. DX らAIエージェントへの変遷、データエンジニアリングの未来
213. 【再掲】Gemini Enterprise等のAIエージェントによる業務効率化・自動化 業務フローを整理 て、作業・判断を「システムで完結 る」「AI 担う」ように置 換えてい • AIエージェントの設計プロセスについては後述。 • システム構成はGemini Enterpriseのデータ連携スライドを参照。他システムでも似 構成となる。 • 本資料作成時 とGemini Enterpriseはま 理想とギャップ ある。 ◦ Google Workspaceとネイティブ連携で る強み ら、将来的な進化に期待 い。 ◦ 直近はDifyやn8nのほう 期待像に近い。コード管理もほ い。Opal 主流になる 。 例：法人顧客の離反検知とフォローアップの（半）自動化 1. BigQueryで法人顧客の利用状況を収集 2. 日次集計で離反の可能性を検知（＝事前定義 セグメントに分類） 3. Googleカレンダーで営業担当者の空 日程を確認 4. Gメールで対象顧客に打 合わ のアポイントメントを送信 5. Google Slidesで提案スライドの草案を作成 6. Google Docsで打 合わ 台本の叩 台を生成 7. Salesforceにフォローアップ状況を入力・更新 213 https://cloud.google.com/blog/products/ai-machine-learning/bringing-ai-agents-to-enterprises-with-google-agentspace
214. ITエンジニアやWEBマーケター ではな 、人事や経理などのバックオフィス職（事務職）にも 「AIエージェント」や「データエンジニアリング」の考え方 必要になる バックオフィス職にもAI＆データ 必須の時代 214
215. DXの議論を踏襲 つつ、DXとの差分に注目 る 215
216. DXの進め方①：現状のリソースの流れを書 出 「アナログ志向の業務」は「ヒト・モノ」（リソース）の流れに依存 ている。 216 自社法務 郵便局員 相手法務 契約書を印刷 署名・押印 受付 配達 受付 配達 受 取り 受 取り 署名・押印 ヒト ヒト ヒト モノ モノ
217. DXの進め方②：理想のデータの流れを書 出 「デジタル志向の業務」は「情報」（データ）の流れを最適化 る。データ基盤の本来のコンセプト。 217 Input 入力 Processing 加工 Output 出力 契約書PDF 自社署名 相手署名 内容確認 締結 署名済みPDF 取引記録
218. DXの進め方③：システムで自動化で る箇所を特定 る ツール導入やシステム化によって「人間」の作業を減ら 、ムダ・ムラ・ムリを解消 る。 218 Input 入力 Processing 加工 Output 出力 契約書PDF 自社署名 相手署名 内容確認 締結 署名済みPDF 取引記録 ▪ヒト やるべ と （入力と確認） ▪DXで実現で る と （加工と出力）
219. DXの進め方④：システムで置 換え 後のリソースの流れを書 出 「デジタル志向の業務」になっ 後のフローを書 出 、業務マニュアル作成やスタッフ研修を行う。 システム構築やツール導入で終わりではな 、現場業務の落と 込みとカルチャー装着まで「変革」 る。 219 自社法務 GMOサイン 相手法務 PDFアップロード 入力・送信 受 取り 入力・送信 ヒト ヒト 情報 受 取り 転送 転送 DX
220. Before ら「増や べ もの」を追加 、「減ら べ もの」を取り除 。 の めの予算確保、体制整備、社内営業＆サポートの徹底、ロードマップ策定・推進を行う。 DXの進め方⑤：BeforeとAfterの差分を埋めるの DXプロジェクト 220 After Before 減ら もの 増や もの 契約書PDF、電子契約ツール、 PDFアップロード、電子署名 紙の契約書(原本) 署名、捺印、郵送依頼、 郵便局員、配達、受 取り
221. AIエージェント導入の勘所①：AIで半自動化で る箇所を特定 る AI導入によって「人間」の作業＆判断を らに減ら 、ムダ・ムラ・ムリを解消 る。 221 Input 入力 Processing 加工 Output 出力 契約書PDF 自社署名 相手署名 内容確認 締結 署名済みPDF 取引記録 ▪ヒト やるべ と （入力と確認） ▪DXで実現で る と （加工と出力） ▪AI 一部担える と （草案作成＆懸念指摘） NEW!
222. AIエージェント導入の勘所②：AI導入後のリソースの流れを書 出 業務手順の中にAIエージェントを組み込む。あるいはAIエージェントの中に人間の介在箇所を組み込む。 業務マニュアル作成やスタッフ研修を行い、現場業務の落と 込みとカルチャー装着まで「変革」 る。 222 自社法務担当 GMOサイン 相手法務担当 PDFアップロード 承認・送信 受 取り 入力・送信 ヒト ヒト 受 取り 転送 転送 法務’sサポートAI　　. （ワトソン君） 契約書の作成 自社記入欄の入力 情報 DX AI
223. 業務システムやAIシステムを高速開発で るデータテクノロジー 台頭 223
224. AIネイティブな時代の「ビジネス」や「オペレーション」の行 着 先 あらゆる事業（ビジネス）や業務（オペレーション）は以下の一連の活動と言える。 • 何ら のリソースを投入（Input） て • 何ら の価値を付加（Processing） て • 何ら の財・サービスを提供（Output） る AIエージェントによって「情報」（データ）の担う部分 拡大 る。 結果、あらゆるビジネスやオペレーション 「データエンジニアリング」化 る。 • 「情報」（データ）の流れを制御 る中核システム 「データ基盤」 • 「情報」（データ）の流れを制御 る活動 「データエンジニアリング」 ⇒Development（仕組みの構築） 　「データエンジニアリング」と「AIエージェント導入」と「業務定義」と「経営」と 一体化 る。 ⇒Operations（仕組みの運営） 　「データ基盤」と「AIエージェント」と「業務フロー」と「事業運営」と 一体化 る。 224
225. 本日のタイムスケジュール 開始目安 所要時間 アジェンダ ① 11:05 2分 は めに ② 11:07 3分 自己紹介 ③ 11:10 3分 データ活用の事例 ④ 11:13 3分 データ基盤の意義 ⑤ 11:17 3分 システム構成要素 ⑥ 11:20 3分 データ収集 ⑦ 11:23 3分 データ加工 ⑧ 11:26 3分 データ提供 ⑨ 11:29 3分 メタデータ管理 225 開始目安 所要時間 アジェンダ ⑩ 11:31 3分 データ品質 ⑪ (略) 0分 データセキュリティ・権限管理 ⑫ (略) 0分 コスト管理 ⑬ 11:34 3分 継続的開発を支える技術 ⑭ 11:37 3分 データ利活用の促進 ⑮ 11:40 9分 生成AIによる5つの変化 ⑯ 11:49 3分 DX らAIエージェントへの変遷、 データエンジニアリングの未来 ⑰ 11:52 3分 わりに - 5,000年前のデータ基盤、 5,000年後のデータ基盤
226. 17. わりに - 5,000年前のデータ基盤、5,000年後のデータ基盤
227. 世界最古のデータ基盤 5,000年前 ら本質は変わっていない。扱える幅 当時より少 広 なっ 。 • メソポタミアの都市ウルクでシュメール人 牛の数を記録 「粘土板」説（紀元前3,000年） • 「船乗りの樽」説（同時代にシュメール人 船で飲み物を運ん と れる 詳細は不明） 227 飲み物の残量・推移 乗組員の命に直結 るKPI 「一」の線 即座に読める直感的なUI 節約 or 消費 アロケーションの意思決定 具体的な行動に直結
228. 228 228
 穀物の収穫高をどう増や ？ 工場の生産量をどう増や ？ 通販サイトの販売高をどう増や ？ データを収集・整備・管理・活用 る めの 「仕組み」（データ基盤）や「取り組み」（データエンジニアリング） 必要 病気の治療効果をどう増や ？ 飲み水をどう増や ？ 安全な土地をどう増や ？ 配達速度をどう増や ？ 人類はデータと対峙 て 移動距離をどう増や ？ 歴史や産業を超え 普遍性
229. 150年前の明治維新を超える「革命」の渦中に私 は立っている、 700万年の「人類の歴史」の最前線に私 は立っている（と考えるとワクワク ま ん ？） • 5年後：全企業 AIを活用 る めの AI Ready なデータ基盤 • 15年後：全企業 ロボットを活用 る めの Robot Ready なデータ基盤 • 500年後：（気候変動で）全人類 エネルギー資源を活用 る めの Energy Ready なデータ基盤 • 5,000年後：（地球の滅亡を見据えて）全人類 宇宙進出 る めの Space Ready なデータ基盤 5,000年後の「当 り前」に向 ベストプラクティスを開拓で る時代 229
230. 覚悟とは、やら れ仕事に甘ん る犠牲の心ではないッ！ テクノロジーの進化を全身で楽 んで！ ベストプラクティスやデファクトスタンダード 見えない 暗闇の荒野に、進むべ 道を切り開 と ッ！ 「データ活用」にコミットメント ると誓いを立て 日 ら！ 俺は1日も作業の手を止め とはない！ 俺は今までよ やって ！俺はで る奴 ！ て今日も！ れ らも！テクノロジー 変わっても！ 俺 歩みを止める とは絶対にない！ 諸君はどう ？ 颯爽 る未来圏 ら吹いて来る透明な風の音 聞 えない ？ 100年後には（最善ルートでも）灰になって墓の下 ？ 2-3年後のキャリアに悩むヒマなん ないよなぁ〜？？？ データエンジニアリングを楽 む覚悟はで ている ？ 5,000年後まで自分の爪痕を残 てやろうという気概はある ？ の激動の時代で命と人生を賭 てテクノロジーで遊び尽 勇気はある ？ 覚悟はいい ？ 俺はで てる 230
231. データエンジニアリングを楽 もう！ 231 データエンジニアリングは、いわば総合格闘技で 。 データの重要性 日々増 てい 時代、世界中で誰も 困っている課題に立 向 ってい 仕事で 。 エンジニアリングの面白 （ て難 ） 詰まっ 、やり いのある分野で 。 の発表 皆様の業務に少 でも 役に立て ら嬉 思いま 。
232. 【再掲】データエンジニアリングへのモチベーション 上 っ ！というアナタには…… 232
233. 累計260ページ・18万文字の超豪華な研修教材を読み、データ基盤構築のハンズオンを行いま 。 【再掲】データ基盤構築のハンズオン 233
234. データエンジニアへの転職は無理なの ！？ 234
235. 清聴あり とう いま 235 改善サイクルを回 、今日よりも良い明日を。 https://kazaneya.com/contact