Google Cloud で学ぶデータエンジニアリング入門 2025年版 #GoogleCloudNext / 20250805

Google Cloud で学ぶデータエンジニアリング入門 2025年版（スライド公開用） 2025-08-05 Google Cloud Next Tokyo ‘25
株式会社風音屋 Google Developer Experts @yuzutas0

アジェンダアジェンダアジェンダ ① はじめに ⑨ データ品質 ② データ活用の事例 ⑩
データセキュリティ・権限管理 ③ データエンジニアリングの位置付け ⑪ コスト管理 ④ データテクノロジー（主な技術要素） ⑫ 継続的開発を支える技術 ⑤ データ収集 ⑬ データ利活用の促進 ⑥ データ加工 ⑭ DXからAIエージェントへの変遷、データエンジニアリングの未来 ⑦ データ提供 ⑧ メタデータ管理 ⑮ おわりに 2

1. はじめに

本日の内容初学者向けにデータエンジニアリング＆データアナリティクスの全体像を解説します。 • Cloud Storage、BigQuery、Dataform、Looker Studioによるデータの収集・連携・監視・加工・可視化の流れを紹介します。 • また、Dataplex Universal
Catalog によるメタデータの管理・活用や、BigQuery Canvasによるデータフローの設計・実装・動作確認にも言及します。ビジネスユーザーでも直感的に利用できること、Geminiによるさらなる補助が期待できることから、改めてこのタイミングで全体像を抑えておきましょう。 4

想定する対象 • データ基盤の構築に関心がある人。 ◦ 「風音屋にデータ基盤構築の発注を検討しているIT部門長やマーケティング部門長」、「風音屋に入社したデータエンジニア」といった方々に配るつもりで資料を作っています。 • [必須] ITパスポート相当の知識がある人。 ◦
Python、RDBMS、SQL、CSV、WebAPI等の初歩的な説明ができる水準を想定します。 ◦ それ未満だと、IT関連の仕事を担当したり、発注管理するのはちょっと難しいかもしれません󰢛 ▪ 最初は少し大変ですけど、ぜひ学習を頑張りましょう💪 • [推奨] Google Cloudや各サービスの基礎知識がある人。 ◦ 文量の都合上、個々のサービス説明は淡泊になるため、別教材で補強いただくと助かります。 ◦ Google Cloudの担当営業に60分のデモをお願いするだけでも十分理解は深まると思います。 ◦ Google Cloudのハンズオンチュートリアル経験者や、認定資格の保有者だとBetterです。 • 職種は特に限定なし。ITエンジニア以外でも歓迎です。 ◦ データ基盤という題材の特性上、どうしてもITエンジニア向けになっている箇所があります。 ◦ Google系ツールという題材の特性上、Webマーケティング系の用語を扱う箇所があります。 ◦ 細かいところは飛ばしながら読んで、雰囲気だけでも掴んでいただければと！ 5

注意事項 1. 本資料は許諾した範囲内でのみご利用ください。無断転載ならびに複写を禁じます。 2. 本資料に記載されている会社名・製品名などは、一般に各社の登録商標または商標、商品名です。資料内では ©, ®, ™ マーク等は省略させていただいております。
3. 本資料は特定企業の情報公開や称賛・批判を意図するものではありません。社名が提示されていないケーススタディやシステム構成は、原則的に複数企業の事例を踏まえたダミー情報となります。 4. 説明を簡略化するために、用語やツールの紹介は厳密な定義に則っていない場合があります。ご自身や所属チームでの理解・解釈が紹介内容と異なる場合は、適宜読み替えていただけると幸いです。 5. 本資料はGoogle Cloudならびにその関連企業の見解を代表するものではありません。風音屋は Google Cloudの認定パートナー企業であり、発表者はGoogle Developer Expertsに所属していますが、あくまで独立した立場にもとづいて情報発信を行っています。 6

登壇者（カジュアル版）ゆずたそ（@yuzutas0）リクルートやメルカリでデータ活用を推進後、AWSを経て、風音屋（かざねや）を創業。データ基盤やダッシュボードの構築について積極的に情報発信しており、主な著書・訳書に『実践的データ基盤への処方箋』『データマネジメントが30分でわかる本』『アジャイルデータモデリング』がある。 1,800人が参加するSlackコミュニティ datatech-jp、延べ参加者15,000人の勉強会 Data Engineering Study
の立ち上げに関わるなど、日本のデータエンジニアリング業界の発展をリードしてきた。 7 Now Writing…

登壇者（エンタープライズ版）横山翔（@yuzutas0）株式会社風音屋代表取締役。Conservation International、リクルート、メルカリ、AWSを経て、風音屋（かざねや）を創業。広告配信の最適化、店舗営業のインセンティブ改善など、データ分析によって数億円規模のインパクトを創出。データ基盤やダッシュボードの構築について積極的に情報を発信。主な登壇・発表 •
Pythonのカンファレンス「PyCon JP 2017」にてベストトークアワード優秀賞 • 翔泳社主催「Developers Summit 2018 Summer」にてベストスピーカー賞 • Google主催「Google Cloud Day」（‘21, ‘23）,「Google Cloud Next Tokyo」（‘23） • 日本統計学会第16回春季集会主な執筆・翻訳 • 講談社サイエンティフィク『アジャイルデータモデリング』 • 技術評論社『実践的データ基盤への処方箋』 • 技術評論社『Software Design』（’20年7月号 - ログ分析特集、’25年7月号 - SQL特集） • 風音屋『データマネジメントが30分でわかる本』 • 内閣府「経済分析第208号 - 景気動向分析の新たな潮流」主なコミュニティ活動 • 1,800人以上のデータ人材が参加するSlackコミュニティ「datatech-jp」の立ち上げ・運営 • 延べ参加者15,640人以上の勉強会「Data Engineering Study」の立ち上げ・モデレーター（2020〜2025） • 国内最大規模の技術カンファレンス「Developers Summit」コンテンツ委員会（2022〜2025） • 東京大学経済学研究科金融教育研究センター特任研究員（2023〜2025） • Googleが認定する技術エキスパート「Google Cloud Champion Innovator / Google Developer Experts」に選出（2023〜） 8

大手からスタートアップまで幅広いクライアント企業のデータ活用を支援するITコンサルティング企業。 100社のデータ経営を実現し、諸産業の活性化に貢献することをミッションとして掲げています。データエンジニアたちが技術相談やノウハウ共有しあう副業ギルドとして始まり、日本全国から多数のご相談・ご要望を受けて法人化。ステークホルダーの皆様にご協力いただきながら、会社組織としてアジャイルに成長してきました。スタートアップCEOからの推薦コメント風音屋（かざねや） 9 ご支援先（一部抜粋）　　　　 •
ランサーズ株式会社 • エイベックス株式会社 • 株式会社クラシコム • 株式会社商船三井 • 株式会社ビズリーチ • NE株式会社 • 株式会社リクルート • 福岡地所株式会社 • 住友化学株式会社

風音屋が提供するサービス 10 データ基盤構築データ分析

データエンジニアリングの書籍が読み放題です！風音屋オフィス（Library） 11

話題の新刊を次々とご恵贈いただいております！Google Cloudの書籍もご恵贈いただきました！風音屋オフィス（Library） 12

採用活動の文脈でMENTA講座を提供 13

MENTA講座では「Google Cloudによるデータ基盤構築」のハンズオンを行います！ Google Cloudによるデータ基盤構築 14

2. データ活用の事例

@yuzutas0や風音屋が過去に発信したアウトプット（一部抜粋）だけでも多岐にわたるデータ活用によって恩恵を得られる領域 17 組織経営 B/S P/L 3C 4P 製品価格
流通集客顧客事業投資社会貢献ビジョン政策・学術アセット管理リスト抽出結果指標活動領域オペレーションテーマ

組織経営のためのデータ分析 • 営利企業の経営会議で「利益 = 売上 - 費用」の予算・実績を確認し、差があれば深堀りを行う。 • 非営利団体（例：学校）の活動状況を可視化し、運営方針のブラッシュアップを行う。株式会社風音屋（監訳）『アジャイルデータモデリング』より「株式会社クラシコム」「学校法人
北陸大学」の事例 18

指標モニタリング販売数、登録数、コンテンツ閲覧数、広告費、商談数、問い合わせ数、問い合わせ対応時間など。毎朝の売上データ通知予算管理シートグラフ・ダッシュボード事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 19

顧客セグメント、商品セグメントなど。 ①全体の数値→②切り口によるドリルダウン→③N1（具体的な1人）と深堀り、課題を特定する。セグメント分析 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 全体 >
セグメント別セグメント > n1 ▪A1層(ロイヤル顧客) xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx xxxxxxxx 要因ロイヤル増加ロイヤル離脱既知パターン・xxxだった・xxxだった・xxxだった・xxxだった新規パターン・おそらく xxx・おそらく xxx ・おそらく xxx・おそらく xxx 20

傾向分析例：問い合わせ内容の偏り。売れ行きの良いジャンルと悪いジャンルの確認。問い合わせの詳細問い合わせの傾向事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 21

ユーザーの利用状況主要導線における遷移、離脱を計測して、改善インパクトの大きい箇所を特定する。事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 行動ファネル(遷移率) ジャーニーマップ+各遷移の遷移率 23

顧客データベース整備による部署連携（後工程への引き継ぎ） • セールス部門のツールと、カスタマーサポート部門のツールで見える情報に差があるとお客様とのコミュニケーションに齟齬が生じたり、データの受け渡し作業が何度も発生する。 • 各自で使いやすいツールを使いつつ、顧客データを統合・参照することで、サービス向上を実現。「スピード」と「品質」のスイッチング～事業成長を支える生存戦略～　https://speakerdeck.com/yuzutas0/20210218c1 例：Salesforce BigQuery
セールスサポートオペレーション例：Kintone 例：Zendesk 加盟店契約審査・キット配送問い合わせ対応 24

人材データベース整備による履歴管理（将来への引き継ぎ）人材斡旋事業の履歴チェック自動化 • 過去のコミュニケーションを確認することで、候補者打診前にアンマッチを防ぐ • 社内に散在している人材データを統合し、ボタン1つで人検索できるようにシステム化 • 担当者の自助努力に依存していた→システム化によって安定品質を実現可能にする Data Management
Guide - 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 25

工場における製造プロセス改善や故障検知 • MI（マテリアルズ・インフォマティクス）によって新しい材料の開発・探索を効率化。 • PI（プロセス・インフォマティクス）によって材料を量産できるように製造プロセスを最適化。 ◦ 例：粉体製品の製造プロセスについて分析を行って、収率低下原因を解明し、改善を実現。 • プラント（大型工場）の操業ダッシュボードによるタイムリーな操業判断。 ◦
例：ポリマー製品の押出機の不調を早期発見し、設備トラブルを未然に防止。株式会社風音屋（監訳）『アジャイルデータモデリング』より「住友化学株式会社」の事例 27

エンタテイメント領域におけるコンテンツ制作の促進 • ラジオ局の番組をポッドキャストに配信 • インターネットを通して世界中へと対象リスナーを拡大 + 音声広告による収益化 • 地域別/時間帯別の再生状況をモニタリングし、データ駆動の番組企画を実現 https://pitpa.jp/studio
Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 28

レコメンド、マッチング類似商品の推薦、プッシュ通知やメールでのコンテンツ案内、CTRを最大化する検索結果の表示順、マッチングの期待値が高い人材やお相手の紹介など。事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 29

施策によって主要指標が変動し、期待するビジネス効果を得られたかを確認する。施策の効果測定 ABテスト結果新機能の利用率 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops https://speakerdeck.com/yuzutas0/20211210
株式会社風音屋（監訳）『アジャイルデータモデリング』より「ランサーズ株式会社」の事例 30

あああセールススタッフが使う顧客管理ツール（プロダクトの前の世界を扱うデータ）従量課金による粗利益の最大化　　ソフトウェアエンジニアが見るデータベース（プロダクトの中の世界を扱うデータ）データを横断活用 • 従量課金やレベニューシェア、ダイナミックプライシングによる、粗利益・ARPPUの最大化。
• 契約件数ではなく利用状況に応じて営業代理店にインセンティブを付与することで、利用に繋がらない契約を無理に取るのではなく、アフターサポートまで見据えた商談を促す。メルカリ社が運用する trocco & BigQuery のデータ分析基盤と経済性 #GoogleCloudDay https://speakerdeck.com/yuzutas0/20210526 32

相場が不透明な商品のプライシング（値付け）支援 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 • クラシックカーの購入希望者に過去取引データを提示。動産（アート）や不動産（物件）など、個人間の交渉で価格が決まる「1点モノ」は相場感が見えると意思決定の後押しになりうる。 •
フリーランス依頼時に発注価格が低すぎないかをAIがチェック。取引プラットフォームにおけるトラブル防止や健全性担保に寄与する。 33

モビリティや物流、宇宙領域における交通ルートや移動スピードの最適化 • 月面探査機における「資源ポイント」へのルート最適化。 • 配車手配サービスにおける「送り迎え地点」へのルート最適化。 • 走行スピードや路面画像から「事故が起きやすい地点」を特定し、ドライバーに減速を促す。「宇宙を人類の生活圏にする」民間発の月面探査チーム・HAKUTOが描く、近未来のビジョン　https://logmi.jp/brandtopics/194965 月面探査プロジェクトの最終ゴールとは？ HAKUTOとリクルートテクノロジーズの挑戦　https://logmi.jp/brandtopics/195185
35

デジタル広告配信の業務効率化 • ROAS（売上÷費用）を最大化できるように、「配信媒体」「クリエイティブ」「予算配分」を調整。 • 広告効果の集計作業を自動化して、効率的にレポート。事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 37

広報コンテンツ化による市場メッセージ • IRで利用状況を開示したり、プレスリリースやインフォグラフィックで市場にメッセージ。 • 時節に適したデータ開示を行うことでメディアが取り上げやすくなる。 • ファクトブック作成のデータ抽出を仕組み化すると、即座にアップデートできるようになる。 Data Management Guide
- 事業成長を支えるデータ基盤のDev&Ops　https://speakerdeck.com/yuzutas0/20211210 38

ユーザーの熱狂や ”バズり” の検知 (1) SNSやYouTubeで話題になり始めているコンテンツ（楽曲）を自動検知 (2) それらの楽曲を含むプレイリストを即日公開 (3) 音楽ストリーミングサービスのプレイリストランキングにランクイン株式会社風音屋（監訳）『アジャイルデータモデリング』より「エイベックス株式会社」の事例
39

対象者リスト抽出の効率化クーポン配布の対象顧客、障害発生時の影響調査など。わざわざ本番インフラ環境にアクセスしたり、 CSVダウンロードプログラムを作らなくても、BigQueryのWEBコンソール画面でデータを確認できる。データベースサーバログアクセス解析ツール BigQuery SQLを書くデータを見る実行する
事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 対象抽出のロジック検討イメージ 41

迷惑行為やスパム行為の異常検知 (1) 過剰アクセスや迷惑投稿を各フェーズで検知 (2) 違反候補者のリストを作成 (3) オペレーターが目視チェック登録情報サイト回遊（商品検索）
投稿内容（口コミ）リクエスト（日時や頻度）アクション（ブクマ）ルールベース or 機械学習検知：早い精度：低いチェックデータデータチェックデータチェックチェックチェックデータデータ検知：遅い精度：高い事業のグロースを支えるDataOpsの現場　https://speakerdeck.com/yuzutas0/20180727 42

資産ポートフォリオの最適化物件や船舶などの資産（アセット）をベースとしたビジネスの場合、「購入・開発などのアセットを増やす活動」「売却・廃棄などのアセットを減らす活動」を行い、アセットごとの収益率や変動（ボラティリティ）をモニタリングしながら、バランスシートを拡大する。株式会社風音屋（監訳）『アジャイルデータモデリング』より「株式会社商船三井」の事例 44

M&Aのシナジー効果や事業間ポートフォリオの計測株式会社風音屋（監訳）『アジャイルデータモデリング』より「ランサーズ株式会社」の事例 46 • 既存事業とM&A（予定の）事業とで、利用ユーザーの重なりや送客効果を推定・測定する。 • 事業A（エントリー向け）から事業B（ベテラン向け）へのユーザー移動を正確に把握することで、事業Aのユーザー離脱が「自社ポートフォリオ内の移動」か「対処すべき離脱」なのかを特定する。

新規事業のモックアップ加速ランサーズのデータ活用を手伝っている話 - 下町柚子黄昏記　https://yuzutas0.hatenablog.com/entry/2020/12/24/153000 47 オープンデータや社内データをモックアップに当てはめることで、開発工程の一部を省略し、短期間でのコンセプト検証を可能とする。

ビジョン達成状況の可視化株式会社風音屋（監訳）『アジャイルデータモデリング』より「ランサーズ株式会社」の事例 49 • 売上や顧客数だけではなく「こうなってほしい」というビジョンの達成状況を計測する。 • 例：「自分たちのプラットフォームが◯人の生活を支えている」を社長室のモニターに投影。

データに基づく政策立案や社会活動 • EBPM：エビデンス・ベースト・ポリシー・メイキング＝証拠に基づく政策立案。 • 生物や森林などの環境資源を計測し、データにもとづいて政策提言や環境保護活動を行う。 • 例：ジンベイザメに識別タグを付けて、リアルタイムで追跡。 Whale Shark Tracker
- Conversation International　https://www.conservation.org/projects/whale-shark-tracker 51

研究論文・学術調査 • 民間企業のリアルなデータを用いて、社会課題に関する学術調査を行い、研究論文として発表。 • 例：クレジットカードの決済データから、COVID-19による飲食店への購買行動の変化を調査し、「どのような属性の消費者」「どのような属性の店舗」の組み合わせで「自粛効果」が生じたのか（あるいは生じなかったのか）を特定する。 52 https://kazaneya.com/news |
https://note.com/kazaneya

教育・授業 • 民間企業のリアルなデータを用いて、学生向けにデータ分析の授業を実施。 • データ分析の結果をレポートにまとめて、企業の執行役員にプレゼンテーションを行い、マーケティング活動を推進する立場から実践的なフィードバックを受け取り、学びを深める。 • データリテラシーを身につけ、社会に出てからリーダーシップを発揮するための土壌を養う。 53 株式会社風音屋（監訳）『アジャイルデータモデリング』より「国立大学法人
東京大学」の事例

3. データエンジニアリングの位置付け

データ活用の流れ（カフェのビジネス） ◯◯さんカフェラテを注文 (消費) リラックス (効用) 統合注文履歴会員登録データ基盤
・購買データ・顧客データ生成新商品の開発リピーター割引券活用価値 ☕ 56 サービス提供に伴い、データが生成される。そのデータを統合し、活用することで、さらなるサービス提供を実現できるようになる。データにまつわる（青い背景の）箇所がデータエンジニアリングの対象領域。

データ活用の流れ（一般化）製品・商品プロダクト顧客・消費者ユーザー統合業務データ、行動ログデータ基盤生成開発、施策、業務
活用価値 57 サービス提供に伴い、データが生成される。そのデータを統合し、活用することで、さらなるサービス提供を実現できるようになる。データにまつわる（青い背景の）箇所がデータエンジニアリングの対象領域。

構造化データ • 行（横）と列（縦）のテーブル（表）で表現できるデータ。 • 従来のデータベースが前提としている形式であり、最も安定してデータを管理・利用できる。非構造化データ • 表形式で表せないデータ。画像、動画、音声、PDFなど。 • AI技術の発展に伴い、非構造化データを扱うツールが急進化しているが、どれもまだ発展途上。
• プログラムでのテキスト処理が簡単なJSONやXMLを「半構造化データ」と区別することもある。構造化データと非構造化データ 58 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円レコード (行) カラム (列)

複数のデータソース（入力／資源）と複数のユースケース（出力／活用）をリボンのように繋ぐ装置。データ基盤とは何か（概要） 59 データ活用基盤

複数のデータソース（入力／資源）と複数のユースケース（出力／活用）をリボンのように繋ぐ装置。データ基盤とは何か（詳細） 60

なぜデータ基盤が必要か（BI）人間の意思決定を加速し、PDCAサイクルを回すため。 61 顧客価値担当業務（オペレーション）の目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution）例：販売目標を達成できているか？採用目標を達成できているか？クレーム件数は減らせているか？業務横断（オペレーション）での目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution）例：キャンペーンや商談は継続利用に繋がっているか？
押し売りで後工程のトラブルを招いていないか？事業（ビジネス）視点での目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution）例：会員や商材のストックは増えているか？顧客ニーズのトレンドは変わっていないか？資源（リソース）視点での目標設定（ToBe）→現状把握（AsIs）→課題特定（Problem）→施策立案（Solution）例：対象領域の（予算｜人員）を（増や｜減ら）して（組織変更｜新規事業化｜買収｜売却｜撤退）するか？ソフトウェア開発デザイン販促マーケカスタマーサポート法務経理・財務広報セールス在庫管理配送店舗接客セキュリティ人事・労務製造管理事業開発 IR 商談販売促進受注・契約初回利用継続利用

なぜデータ基盤が必要か（AI）機械の自動判断を加速し、業務の効率化および顧客体験の変革を進めるため。 62 Before After 注文書作成オペレーションビジネス在庫発注タスク
店頭スタッフ販売 Geminiが自動作成 Agentspaceで自動発注無人店舗（AIスタッフ販売）人間の脳内社内外のデータ

どういった手順で作るか • 「データソース」と「ユースケース」の絵を描き、両者を繋げるための流れを描く。 • Return（どのような恩恵を得られるか）とInvestment（どのような開発を行うか）を明確にしてステークホルダーに提示し、ROIの高い順番でシステム開発やダッシュボード構築を進める。 • キーワードや製品ありきで「XXXを導入しましょう！」から始めるのはアンチパターン。 63 例：ヘラルボニーにおけるデータ基盤の初期構築。設計・実装は風音屋が担当。

4. データテクノロジー（主な技術要素）

• データ基盤を支える代表的なテクノロジーと構成例は以下のようになる。 • Google Cloudでデータ基盤を構築する場合は、主にBigQuery（＝DWH：データウェアハウス）が中心的な役割を果たすことになる。主な技術要素（概要版） 66 元データA 元データB
DWH 蓄積・集計 BI 分析・可視化ワークフローエンジン処理の流れを管理 ETL 収集・連携データカタログ仕様の入力・検索

主な技術要素（詳細版） 67 データ取得元C データ取得元B データ収集プログラム Python ファイルストレージ
（保存） GCS データウェアハウス（分析環境） BigQuery ダッシュボード BIツールアドホック集計 Google Sheets メルマガ配信 CRMツール元データ加工データプログラム実行環境 Cloud Run functions データ加工・変換 SQL ワークフロー（処理の流れを横断管理） Cloud Workﬂows データカタログ（データの説明） Dataplex Universal Catalog データ取得元A SQL管理ワークフロー Dataform データ連携プログラム Python プログラム実行環境 Cloud Run functions コード管理 GitHub インフラ構築 Terraform 品質権限管理コスト

BI（Business Intelligence）ツール • グラフ可視化やダッシュボード構築に特化したツール。「分析ツール」として分かりやすい。 • Googleアカウントがあれば Looker Studio をWEBブラウザで利用できる。基本料金は無料。 •
日本で有名な利用事例としては、クリスプ・サラダワークスさんがLooker StudioでKPIを全公開。 • https://lookerstudio.google.com/gallery • https://lookerstudio.google.com/u/0/reporting/01c05c49-dbc4-464b-aa9a-0a9ﬀ0b97e7b/page/pcEJC 69

DWH（データウェアハウス）製品 • 大規模データの保存や集計に適したデータベース。データエンジニアリングの中核となる存在。 • Googleアカウントがあれば、BigQueryがWEBブラウザで利用できる。月1TBまでの集計が無料。 • SQLと呼ばれるデータベース言語を使ってデータの抽出・集計を行う。 ◦ 例えば「SELECT name
FROM customers WHERE prefecture = “東京都”」だと「顧客を取得せよ」「顧客テーブルから」「東京都で絞り込んで」という指示になる。 71 SQLを書くデータを見る実行する

クラウドストレージ • 安全・安価なファイルの置き場。 • Google Cloudを使う場合は、GCS（Google Cloud Storage）が該当する。 ◦ Googleドライブが人間用のファイル置き場なら、GCSはシステム処理用のファイル置き場。
• データエンジニアリングの分野だと以下の用途で使われることが多い。 ◦ ①バックアップの置き場。DWHの更新ミスがあったときに備えて、ストレージにバックアップを保存し、データを復旧できるようにしておくことが望ましい。 ◦ ②データの中継地点。DWHは事前に定義した仕様（列名や型）と異なるデータを追加するとエラーになる。ストレージにデータがあれば、外部システムからデータを再連携せずに済む。 73 風音屋のMENTA講座の資料より

プログラム実行環境 • Pythonなどのプログラムで「外部からのデータ取得」や「外部へのデータ連携」を実現するには、プログラムを実行するためのインフラ環境（＝サーバ）が必要になる。 ◦ 個人がPC端末（＝ローカルサーバ）でGoogle Chrome（＝プログラム）を起動したり、スマートフォン（＝ローカルサーバ）でYouTubeアプリ（＝プログラム）を動かすのと同じ。 • Google
Cloudを使う場合、Cloud Run functionsというソリューションが、特に軽量かつ安価で、使い勝手が良いのでオススメ。 ◦ PythonのソースコードをGCSに置き、Cloud Schedulerで定期スケジュールを設定すると、 Cloud Run functionsで処理を実行できる。風音屋のMENTA講座の資料より 75

補足：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) 76

用語解説：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ツール ① ② ③ ④ 77

SQL管理ワークフロー / ELTツール • SQLでのデータ変換・集計処理について、依存関係をパイプライン管理するツール。 • BigQueryを使う場合は、付随機能として Dataform というツールを無料で使うことができる。 •
以下のような複数のSQLを段階的に実行できる。 1. POSレジのデータと通販DBのデータを統合する 2. 顧客一覧を作成する 3. 顧客ごとの年間売上を集計する 4. 年間売上を元に顧客ランクを付与する 5. メルマガ配信リストを作成する。 79 風音屋のMENTA講座の資料より

ワークフローエンジン • 一連の処理の流れを管理するツール。 • Google Cloudを使う場合は、Cloud Workﬂowsというソリューションが汎用的で使いやすい。 • 複数のシステムを横断して、以下のような一連の処理を管理・実行できる。 1.
Cloud Run functionsでPythonプログラムを実行してデータをBigQueryに反映する。 2. DataformでBigQueryのデータを加工・集計し、メルマガ配信リストを作成する。 3. Cloud Run functionsでPythonプログラムを実行してメルマガ配信ツールにリストを送る。風音屋のMENTA講座の資料より 80

データカタログ • 社内データを検索したり、データの特徴や注意点を調べることができるツール。 • Google Cloudを使う場合は、Dataplex Universal Catalog というソリューションが該当する。 82
風音屋のMENTA講座の資料より

• 「誰が」「どのデータに」（どのシステムに）アクセスできるのか、を管理するための機能。 • Google Cloudだと、Cloud IAM（Identity and Access Management）が該当する。 •
Google Driveのフォルダ権限管理と同じで、Google Groups（メーリングリスト機能）のグループに対して、データ参照の権限を付与することができる。 ◦ 入退社や部署異動の手続きでGoogle Groupsを使っている場合は、同じ要領で管理できる。 IAM（アクセス管理） 84 Aさん@kazaneya.com Bさん@kazaneya.com Cさん@kazaneya.com D部署@kazaneya.com E案件@kazaneya.com F職種@kazaneya.com E案件の受領データ D部署が管理するデータ研修用のデータデータ利用者 Google Groups BigQueryのデータ IAM 編集権限閲覧権限編集権限

監査ログ • データへのアクセス記録を残し、後から監査を行うことができるログ。 • Google Cloudだと、主に Cloud Logging というログ出力ソリューションを用いる。 ◦
クラウドサービスの標準機能であり、利用者が他の候補を検討するといった類のものではない。 • あらゆるログが出力されるので、調査のノイズを減らしたり、保存コストを節約するために、「特定データへのアクセス」といった条件で絞り込んで、保存ストレージを指定することもできる。 85

なぜ他のツールではなく、ストレージやデータウェアハウスを中心にするのか「個別ツールのコンソール画面やCSVダウンロード」だとダメ？ • 複数ツールを横断してデータを利用する場合は、どこかしら別の管理場所が必要になる。 • ツールごとにCSVダウンロードして、Excelでデータを統合＆集計することになる。 ◦ 人材不足の時代に、労力を投下して単純作業を繰り返すことは好ましくない。 ◦ 作業ミスが混入すると、集計した値が誤ってしまうといった品質面の課題が生じる。
◦ 担当者のローカルPC端末でデータを処理する場合、セキュリティやガバナンス観点でリスク。 • メルマガ配信リストを手動作成してMAツールに手動アップロードするような場合、上記の一連のデメリットが重なり、メールの誤配信といった顧客トラブルにも繋がる。「Excel / Google Sheets」だとダメ？ • 扱えるレコード件数に上限がある。 • 操作内容やデータ形式によっては、システムによる自動化と相性が悪い。「MAツール / CRMツール」だとダメ？ • 顧客単価を上げるために「機能豊富で高価」路線の製品が多く、用途によってはToo Muchとなる。 • 離脱防止のためにバックアップやエクスポートの制限が多く、ロックインのリスクが高い。 87

データ基盤にGoogle Cloudを使う理由（1/3） - 少額で始められるサーバの運用保守が不要なシステム構成 • 例：BigQuery（蓄積）+ Dataform（集計）＋ Looker Studio
か Google Sheets（可視化） • スタートアップや初期構築フェーズならデータ基盤はこれだけで十分。 • コストや人員を抑えることができる。毎月のインフラ費用が数百円で済むケースもある。スモールデータだと破壊的な安さ • BigQueryは毎月1TBまで無料。Dataform、LookerStudioは無料。 ◦ LookerStudioの有料機能（Pro）は代表者1名ｘ1,000円/月だけで恩恵を受けられる。 • 類似のクラウドサービスを契約すると最低でも数万円/月は必要になる。 • 類似のOSSをサーバで管理すると、メンテナンス対象が増えて人員が必要になる。 88

データ基盤にGoogle Cloudを使う理由（2/3） - 連携先が多い Googleのマーケティング製品とのデータ連携 • 広告媒体（Google広告）、動画サイト（YouTube）、Androidアプリのストア（Google Play）、 WEBサイト運営（Google
Analytics 4）、モバイルアプリ運営（Firebase）、SEO（Googleサーチコンソール）、検索ボリューム（Googleトレンド）等のデータに対応。 • これらのデータをエクスポートする先は原則的にBigQueryのみ。他のデータウェアハウスを使うと BigQueryとの二重管理になってしまう。 Googleの業務支援製品とのデータ連携 • Google Sheets（Googleスプレッドシート）で管理しているリストをBigQueryに取り込んだり、 Google Sheets で BigQueryのデータを抽出・集計・可視化できる。 • GeminiチャットやNotebookLMによる分析レポートの生成、Agentspaceによる業務自動化など、今後のAI系サービスへの連携強化も期待できる。 ◦ Google社はAIサービス提供の土台が充実している。開発者・研究者（世界のトップ人材）、計算資源（世界中にGoogle Cloudのデータセンター）、社外データ（Google検索に世界中の WEBコンテンツ、YouTubeに世界中の動画、Google Photoに世界中の画像、Google Mapに世界中の地図）、社内データ（Google Cloudに基幹データ、GA4やFirebaseにWEBデータ、 Google Workspaceに文書データ）など。「とりあえずGoogleで良いか」に説得力がある。 89

データ基盤にGoogle Cloudを使う理由（3/3） - ビジネスユーザーが使いやすいビジネスユーザーが手軽に試せる • 無料Gmailのユーザーを含めて、Googleアカウントさえあれば、数クリックで利用開始できる。 • 他のクラウドサービスでデータ基盤を作ろうとすると、早くても1-2週間（普通は1ヶ月以上）、安くても数万円/月は必要になってしまう。どうしても「会社が本格導入するもの」になってしまう。
ビジネスユーザー向けの学習教材が豊富である • 例1：中小企業の経営者がLooker Studioを使うための書籍　⇒『データを使って利益を最大化する超効率経営』 • 例2：WebマーケターがBigQueryを使うための書籍　⇒『BigQueryではじめるSQLデータ分析 GA4 & Search Console & Googleフォーム対応』データ専門職以外にも普及している • 特にBigQueryやLookerStudioは「よくわからないけど◯◯さんの真似をして使っている」状態。 • 例：WEBサイト運営者（Google Analytics 4）、動画配信者（YouTube）、SEOライター（Google サーチコンソール）、個人アプリ開発者（Firebase）、WEBマーケター（Google Ads） • 「会社による契約やシステム導入」が必要な類似サービスとは利用者数の桁が違う。当社調べ。 • エコシステムを含めて「よくわからないけど使える」「初心者に選ばれる」土台が整っている。 90

本資料における設計ポリシー • 個人がカジュアルに試せる規模のスモールスタートに対応できる内容とする。数万円〜/月のコストがかかる Cloud DataﬂowやCloud Composer、数十万円〜/月のコストがかかるLookerには言及しない。 • Snowﬂakeやdbt
Cloudなどの他クラウドサービスを追加契約するとリードタイムがかかる上、ガバナンス対応が複雑化するため、なるべくGoogle Cloudで完結することを想定する。 ◦ データ収集用のETL SaaSについても、従来は自前でメンテナンスするよりもROIが高かったが、この1年でAIエージェントやAIコーディングに任せられるようになったので対象外とする。 • dbt Core / dbt FusionやLightdashなどのOSSをGCEやCloud Runで動かすと、メンテナンス対象が増えるため、なるべくマネージドサービスを使うことを想定する。 91

5. データ収集

データ収集のざっくり実装方針 1. BigQueryに直接保存できるデータはなるべくその通りにする。*1 2. そうでないデータはGCSを経由して保存する。 3. Pythonのプログラムを書かないといけないときは、Cloud Run functionsでPythonを動かす。 95
*1：一部例外あり。後述。

社内管理シートからのデータ取得 • 担当者がGoogle Sheetsを直接編集するか、またはGoogleDriveにExcelファイルをアップロード。 • BigQueryの外部テーブル機能でそれらのファイルを読み込むことで、データを取得する。 96 インターネットユーザー Google
Workspace Google Sheets データ基盤システム（Google Cloud） BigQuery 外部テーブル HTTPリクエストシートに入力ユーザー HTTPリクエストファイルをアップロード Excelファイル Google Drive ファイルサーバやストレージ等 Excelファイル取得外部テーブル

Python等のプログラムを実行して、SaaS（例：Kintone、Shopify、Moneyforward、Salesforce）、広告媒体（例：Meta広告）、メールやLINEの配信ツール（例：Klaviyo、CRM Plus on LINE）、アプリデータ（例：Apple Store）、自社Webサービス等が提供するWeb APIからデータを取得する。データ基盤システム（Google Cloud）
コンソール利用時 Web API によるデータ取得 97 SaaS等のWebシステムデータベース Web画面（ユーザー用） Web API （システム連携用）取得プログラム例：Python Cloud Run functions ファイル例：CSV, JSON GCS BigQuery Webブラウザインターネット人間 HTTP リクエスト外部テーブル保存 HTTP リクエスト PC端末表示提供アクセス 💡SalesforceやServiceNowなど、一部のSaaSは BigQuery Data Transfer Serviceのプレビュー版が登場したので、ゆくゆくは置き換えられるかも？

Web APIをユーザーに対して提供していないSaaS等のWebサービスからデータを取得する場合、 • コンソール画面からダウンロードしたCSVファイルをGoogleDrive経由でBigQueryに連携する。 • またはPython等のプログラムを実行してスクレイピングを行う。データ基盤システム（Google Cloud）コンソール画面からのデータ取得 98
インターネット Google Workspace BigQuery ユーザー HTTP リクエストファイルをアップロード CSVファイル Google Drive 外部テーブル SaaS等のWebサービスコンソール画面 HTTPリクエストファイルをダウンロード取得プログラム例：Python Cloud Run functions ファイル例：CSV, JSON GCS 保存スクレイピング SaaS等の Webサービスコンソール画面外部テーブル HTTPリクエスト 💡Webサービスの画面レイアウト変更時は、エラーログとHTML文字列をもとに GitHub Issueを自動起票してコーディングAIにパース処理を修正してもらおう！

BigQueryのfederated queryで定期的にDBからデータを取得するか、またはDatastreamでDBの更新ログを取得してGCS経由でBigQueryに連携する。データ基盤システム（Google Cloud）業務DBからのデータ取得（Google Cloud内のDB） 99 Datastream ファイル
GCS BigQuery Webシステム（Google Cloud）データベース例：Cloud SQL 更新ログ WEBアプリケーションユーザーデータ更新保存外部テーブルフェデレーションクエリ（その時点の最新データを取得）取得 💡ユーザー影響を防ぐために DBのレプリカ（コピー）を経由することもあるよ！ Cloud Run等インターネットや VPN等 HTTP リクエスト

クラウドサービス（例：AWS）のエクスポート機能でストレージ（例：S3）を経由してデータを渡すか、またはDatastreamでDBの更新ログを取得してGCS経由でBigQueryに連携する。なお、DatastreamからBigQueryに直接出力すると履歴が消えるので、強いリアルタイム要望がなければ（＝10分間隔のマイクロバッチで要件を満たせるなら）GCSを経由することが望ましい。データ基盤システム（Google Cloud）業務DBからのデータ取得（Google Cloud以外のDB） 100 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アクセスが許可されるのであれば、ゆくゆくは置き換えられるかも？

アクセスログやアプリケーションログと呼ばれるWebシステムのログは、 • Google Cloud内ならCloud LoggingからGCS経由でBigQueryに連携する。 • Google Cloud外（例：AWS）ならエクスポート機能でストレージ（例：S3）を経由して受け渡す。データ基盤システム（Google Cloud）
サーバログからのデータ取得 101 ファイル 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等

Google Analytics 4（FirebaseやGoogle Tag Managerを含む）は、標準機能でBigQueryに連携が可能。 • データが1日100万件以上だと、有償プランに切り替えるか、一部項目の取得を妥協する必要がある。 • コンソールの集計方法は非公開であり、データ反映ラグやバグ混入もあるため、BigQueryの集計とは数値が一致しないケースがある。
データ基盤システム（Google Cloud）アクセス解析ツールからのデータ取得 102 BigQuery Webシステム WEBアプリケーション Cloud Run等インターネット HTTP リクエストユーザー WEB画面 PCやスマホログ出力 Google Analytics 4 GA4内のデータベースコンソール画面表示エクスポートコンソール利用時人間 WEBブラウザで HTTPリクエストインターネット

Google検索サービスからのデータ取得 103 • Googleサーチコンソール（自社サイトの検索パフォーマンス）はエクスポート機能で連携。 • Googleトレンド（キーワードの検索ボリューム）はBigQuery Sharing機能でデータを取得。 Google検索クローラー検索
ログデータベースインデックスを保存検索機能検索ユーザー HTTP リクエストインターネット Googleサーチコンソール Googleトレンド Googleサーチコンソールのデータベース Google トレンドのデータベース WEB画面 WEB画面コンソール利用時人間 WEBブラウザで HTTPリクエストインターネットコンソール利用時人間 WEBブラウザで HTTPリクエストインターネットデータ基盤システム（Google Cloud） BigQuery 表示表示エクスポートエクスポートログ出力

Google運営サービス（検索以外）からのデータ取得 104 広告媒体（Google広告）、動画サイト（Youtube）、Androidアプリのストア（Google Play）など、 Googleが運営する各プラットフォームのデータは、BigQuery Data Transfer Serviceで取得が可能。 Google広告
Google広告のデータベース WEB画面コンソール利用時人間 WEBブラウザで HTTPリクエスト表示 Youtube Youtubeのデータベース WEB画面表示コンソール利用時人間 Google Play Google Playのデータベース WEB画面表示コンソール利用時人間インターネット WEBブラウザで HTTPリクエストインターネット WEBブラウザで HTTPリクエストインターネットデータ基盤システム（Google Cloud） Data Transfer Service 取得 Data Transfer Service Data Transfer Service BigQuery 取得取得保存保存保存

• 政府統計や各社オープンデータはBigQuery Sharing機能で提供事業者からデータ取得が可能。 • WEBコンテンツは、Python等のプログラム + Geminiでスクレイピングを行い、BigQueryに連携。データ基盤システム（Google Cloud）
各提供者各省庁等オープンデータによるデータ取得 105 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にパース処理を修正してもらおう！

• 各ツールから文章、画像、動画、PDFファイルなどの非構造化データを集約する。 • システムが管理する場合はGCSに置き、必要に応じてBigQueryにデータをロードする。 • 人間が管理する場合はGoogle Driveに置き、必要に応じてGCSを経由してBigQueryにロードする。 • BigQueryのObject Table機能でGCSの非構造化データを参照し、バイナリ形式で機械学習に利用。
データ基盤システム（Google Cloud）社内フォルダ等のデータ取得（ストレージに集約する場合） 106 インターネット Google Workspace BigQuery ユーザー HTTP リクエストファイルをアップロード各ファイル Google Drive 取得プログラム例：Python Cloud Run functions 各ファイル GCS 保存 WebAPIコールやスクレイピング各ツール外部テーブル HTTPリクエスト Web API コール HTTP リクエスト

• 各ツールから文章、画像、動画、PDFファイルなどの非構造化データを連携する。 • Agentspaceに直接データを連携し、BigQueryに集約した構造化データと組み合わせる。 • データ分析のレポートやSQLを自動生成したり、カレンダーやメールの作成が可能。 • 例：キャンペーン企画や契約書を連携 ⇒ 売上の変動要因を解釈
⇒ 重点顧客にアポ依頼のメール。社内フォルダ等のデータ取得（Agentspaceで直接利用する場合） 107 Microsoft Teams Microsoft Outlook Microsoft OneDrive SharePoint Slack Box Gmail Google Drive Conﬂuence JIRA GitHub Salesforce Google Group Google Calendar 文章 | 画像 | 動画 | PDF 非構造化データ HubSpot Zendesk Service Now Workday etc… Trello BigQuery 構造化データデータ基盤システム（Google Cloud） Agentspace Vertex AI Agent Engine Python + ADK Assistants Gemini Google Workspace Google Calendar Gmail 人間連携連携利用利用スケジュール設定やメールの送信分析レポートや SQLの作成 Web画面でチャット指示 ⚠Agentspace等のAI Agent系サービスは Early AccessやPreview段階のものが多い。機能強化は今後に期待。 ⚠Claude Desktop等を使い、各サービスをMCP経由で参照して分析レポートを作る方法もあり。

データの仮想化について • データ本体を持たずに「外部テーブル」や「federated query」で別のシステムにアクセスしつつ、利用者にはデータがそこにあるかのように振る舞うことを「データの仮想化」と呼ぶ。 • データの仮想化ありきで整えたシステム構成を「レイクハウスアーキテクチャ」と呼ぶ。ネイティブテーブルへの変換 • 上記機能だと、接続設定が容易な一方で、データアクセスの挙動が安定しないことがある。
◦ 例：Google Sheetsへのアクセスがエラーになる。再実行すると問題なくデータを取得できる。 • 頻繁に参照されるデータは、BigQueryに実体をコピーする（ネイティブテーブルを作る）ことで、エラーに煩わされずに済む。 • Dataformで “SELECT * FROM 仮想化テーブル WHERE 対象日” を実行し、別テーブルに保存する。他システムデータ基盤システム（Google Cloud） BigQuery 補足：仮想化テーブルの一部はネイティブテーブルへと変換 108 仮想化テーブルネイティブテーブル Dataform 取得保存元データ本体都度参照取得経路と解釈 rawデータと解釈

6. データ加工

データ加工の概要 Excelシートで経理データを集計・活用するときには、以下のような工夫を行う。 • データが更新されて、シートが上書きされてしまわないように、履歴（スナップショット）を残す • Excel関数で処理できるようにフォーマットを調整（前処理）する • 1つのセルに含まれるExcel関数が膨大・複雑になったら、途中集計のセルを分ける • 汎用的な会員リストを作ってから、複数のシートでそのリストを参照し、フィルタリングを行う
このような「データの加工」の流れを設計して、SQLで実現していく。 112

風音屋式の簡易DFD（データフロー図）でデータ加工処理を設計する 113 最終的な活用イメージ（モックアップ）とテーブルが紐づくところまで確認する加工前のデータが出口まで繋がることを確認する結合条件や加工結果を明記する →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/ インプットアウトプットプロセス（途中処理）

BigQuery CanvasでSQLを書き、簡易DFDを再現するクエリの実行結果をプレビュー表示して、その結果に対して次のクエリを実行することが可能。簡易DFDの設計をベースにしてSQLを実装＆テストしていく。 114 風音屋のMENTA講座の資料より

作成したSQLをDataformに移植する Dataformのデータ集計機能 • 集計処理の定期実行、エラー時のリトライ • バリデーション（NotNullやUnique）や自動テスト • データの依存関係の管理 115 Git/GitHubでのコード管理
• Gitでのバージョン管理 • GitHubでのCI管理（Linterなど） • AIエージェントによる開発の半自動化風音屋のMENTA講座の資料より

データの取得（左）から活用（右）に向かって層（レイヤー）ごとに役割＆名前を分ける。 • 元データのコピー（ローデータ）を格納する「raw__xxx」テーブル • 顧客属性や商品カテゴリといった分析の切り口は「dim__xxx」テーブル • 商品購入の金額・数量といった集計対象は「fact__xxx」テーブル • dimとfactを結合して、簡単にデータを使えるようにした「wide_xxx」テーブル責務に応じてレイヤーを分け、命名規則で管理する
116 株式会社風音屋（監訳）『アジャイルデータモデリング』より

構造化データにおけるレイヤリングの過去議論 117 “ゆずたそ”の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

風音屋のデータモデリング標準 / “ゆずたそ”の3層構造（詳細）データの「入口」「中間」「出口」で、重視すべきステークホルダーや担うべき役割が異なるという思想。世に出ている様々なテーブル設計のテクニックを、それぞれに適した箇所で使うように位置付けている。 118 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 元データのコピーデータソースユースケースユースケースユースケース

• データの分析や活用に特化したテーブル設計手法。 • Fact（ファクト：集計対象）とDimension（ディメンション：分析軸）でテーブルを管理する。 • データを整備すると、売上高◯◯円という事実（Fact）を3つの次元（Dimension）で分解できる。補足：ディメンショナルモデリング 119 fact_order id
user_id item_id item_count amount 1 100 10 1 300 2 101 20 3 2400 3 102 500 15 15000 dim_user id name age 101 ◯◯ 18 102 △△ 22 103 □□ 25 dim_item id name category 10 トマト野菜 11 ナス野菜 12 じゃがいも野菜株式会社風音屋（監訳）『アジャイルデータモデリング』より（網掛けは本資料での追記）この期間での売上 2億円この製品での売上 5,000万円この店舗での売上 800万円売上累計 30億円

補足：イベントマトリクスファクトとディメンションの組み合わせを表形式（イベントマトリクス）として書き出す。データチームの定例ミーティングで表を更新したり、データ整備やデータ分析のTODOリストに反映する。 • 縦軸：ファクトとなる「出来事」（ビジネスイベント） • 横軸：ディメンションとなる「切り口」（5W1H） 120 株式会社風音屋（監訳）『アジャイルデータモデリング』より引用

非構造化データ ⇔ 構造化データの変換生成AIによる「非構造化データ」から「構造化データ」への変換（以下は例） • 商品名のテキスト → 商品カテゴリーの分類 →
カテゴリー別の売上集計が可能になる • 自動車が撮影した路面写真 → リスク要因のラベリング → 走行データと合わせて事故予測の精度向上 • 代理店との会議メモやメール → キャンペーンの情報を抽出 → MMMに組み込んで広告効果推定の改善生成AIによる「構造化データ」から「非構造化データ」への変換（以下は例） • 法人顧客の行動データ → 営業担当向けに追加提案メールのドラフトを生成 • 商品の在庫や注文のデータ → 今日推すべき商品で「こんな人が買ってます」訴求文面を生成 • 企業の募集要項と求職者の履歴書 → 条件ミスマッチを緩和するための修正提案メッセージを作成 121 風音屋TechTalk #4 発表資料より

非構造化データ in データパイプラインパイプラインに組み込むかどうかで2つのアプローチが考えられる。 1. データパイプラインに組み込む場合。BigQuery ML GeminiでSQLからGeminiを実行する。 2. 従来のデータパイプラインには組み込まず、Agentspaceで各データを集約してAI側で完結させる。
122 非構造化データデータパイプライン構造化データ非構造化データ ①生成AIで前処理 ②生成AIで出力作成

非構造化データの3層構造 Garbage In, Garbage Out（ゴミを入れたらゴミが出てくる） • 社内文書や動画ファイルはボリュームが多い割に、品質が低かったり、ノイズ情報も混ざる。 • 生成AIが一度に記録・利用できるデータ量には上限がある。 •
ルンバ（お掃除ロボット）を動かすために、床の物を片付けるのと同じ。事前に整える。構造化データと同じようにデータの整理が必要 • 元のファイル（入口）→整理した情報（中間）→用途に必要な情報（出口）を整備する。 • “ゆずたそ”の3層構造の「データレイク層」「データウェアハウス層」「データマート層」に該当。この領域は生成AIの台頭に伴って急進化が始まったフェーズ • 現時点でこれぞというリファレンスアーキテクチャが定まっていない。 • データの持ち方も定まっていない。テキストを書き直したもの、文書ベクトル、グラフ構造 etc…？ • 対応するソリューションも違う。BigQuery、Vertex AI Feature Store、Spanner Graph etc…？ ◦ グラフDBの構築はToo MuchなのでGIS機能と似た位置付けのBigQuery Graphが欲しい。 123 ソース水源レイク湖 = 蓄積するウェアハウス倉庫 = 管理するマート市場 = 売るユーザー利用者

7. データ提供

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

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

生成AIによるアドホック分析ジュニア分析者より正確で、シニア分析者より早い＆安いアウトプット • GeminiチャットやNotebookLMによるデータ分析レポートの作成。 • Claude Desktop等のサードパーティツールからBigQueryを参照する事例も散見される。 MCP経由で加工済みテーブルにアクセス • 本資料作成時点で主流なのはBigQueryのMCPを経由してデータを参照する方法。
• 将来的にはGeminiやNotebookLM、Looker Studio Pro（対話エージェント機能）を社内提供するアプローチがGoogle Cloudユーザーの主流になりうる。まだ高水準とは言えないが今後に期待。 • BigQueryでFact＆Dimension（またはそれらを結合したWide or Summary）テーブルに接続する。 129

チャットツールへの自動配信毎朝の始業時間に、前日の経営状況を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

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/

Agentspace等のAIエージェントによる業務効率化・自動化業務フローを整理して、作業・判断を「システムで完結する」「AIが担う」ように置き換えていく • AIエージェントの設計プロセスについては後述。 • システム構成はAgentspaceのデータ連携スライドを参照。他システムでも似た構成となる。 • 本資料作成時だとAgentspace（7月31日に一般公開）はまだ理想とギャップがある。 ◦ Google
Workspaceとネイティブ連携できる強みから、将来的な進化に期待したい。 ◦ 直近はDifyやn8nのほうが期待像に近い。あの方向性に進化してほしい。コード管理もほしい。例：法人顧客の離反検知とフォローアップの（半）自動化 1. BigQueryで法人顧客の利用状況を収集 2. 日次集計で離反の可能性を検知（＝事前定義したセグメントに分類） 3. Googleカレンダーで営業担当者の空き日程を確認 4. Gメールで対象顧客に打ち合わせのアポイントメントを送信 5. Google Slidesで提案スライドの草案を作成 6. Google Docsで打ち合わせ台本の叩き台を生成 7. Salesforceにフォローアップ状況を入力・更新 132 https://cloud.google.com/blog/products/ai-machine-learning/bringing-ai-agents-to-enterprises-with-google-agentspace

NotebookやFeature Storeによるデータサイエンス BigQuery Notebook（Jupyter Notebook / Google Colab Enterprise相当）での統計解析 •
四則演算ベースの集計はSQLで済ませ、ノートブックでは定量的な予測や解釈を行う。 • 例：値上げの影響、購買促進のハブとなるコンテンツの特定、自然成長や季節変動や景気連動や需要の先食いを除去したマーケティングキャンペーン効果の推定。 BigQuery内のデータで機械学習を行い、Vertex AI Feature Store 経由でプロダクトに組み込み • プロダクト内における商品、コンテンツ、物件、人材のレコメンド機能など。 • Notebookでアドホック分析した後、機械学習のモデルやパイプラインに組み込む。 ※必要に応じてBigQueryの（加工前）rawテーブルや（前処理済み）adapterテーブルを参照する。 133

BigQuery Sharingによるデータの外部提供統計データを法人顧客、取引先、研究機関に提供 • BtoBサービスのオプション商品として組み込むケースも散見される。 • データ提供用の加工テーブルを用意し、BigQuery Sharing（旧：Analytics Hub）で受け渡す。 •
例：@yuzutas0が東京大学で実施した授業。Pythonの使い方を学んだ後、NE株式会社が保有する年1兆円以上の取引データ（日本のEC市場の1割弱に相当、統計加工済み）を用いて、マーケティング課題の発見・解決提案をレポートにまとめ、授業最終日には執行役員に対して成果発表を行った。 134 株式会社風音屋（監訳）『アジャイルデータモデリング』より「国立大学法人東京大学」の事例

8. メタデータ管理

メタデータ • データを説明するデータのことをメタデータと呼ぶ。 • 図書館に対する図書目録のように、利用者が様々な着眼点からデータを見つけられるようにする。 ◦ 例：「価格」（price）データの「100」が「100円」なのか「100ドル」なのか分からない。 • 様々な分類がある。 ◦
「データソースに紐づく情報」「データ加工に紐づく情報」「データ利用に紐づく情報」など。 ◦ 「システムが自動で付与する情報」「人間が工数を費やして付与する情報」など。 138 『実践的データ基盤への処方箋』より

データ活用で必要になるメタデータ（1/4） • テーブルの用途や作成経緯。 • カラム名、型、制約（ユニーク、NotNull）、値の範囲などのスキーマ情報。 • 問い合わせ先。 • 類似データとの使い分け。 •
一緒に使うことが多いテーブル。 139

• よくある質問と回答例（FAQ）。 • 既知のエラーケース。 ◦ 例：◯◯日〜◯◯日はシステムトラブルでデータが0件になっている。 • 機密情報に該当するか。 • データの更新頻度やタイミング。
• データの依存関係。データ活用で必要になるメタデータ（2/4） 140

• 代表的なクエリ例。 • 複雑なデータ仕様、状態遷移、ドメイン用語の解説。データ活用で必要になるメタデータ（3/4） 141

データ活用で必要になるメタデータ（4/4） • データ利用状況 ◦ 誰が、いつ、どこで、どのデータを参照・利用するのか。 ◦ 後述する監査ログを用いる。 • データ生成過程（DGP：Data Generation
Process） ◦ データが生成されるときの業務フロー。 ◦ 誰が、いつ、どこで、どのデータを記入・更新するのか。 ◦ GoogleDriveや社内Wikiにあるマニュアルを転用する。 142

Google Cloudにおけるデータカタログ機能 • Google Cloudのコンソール画面からデータカタログ機能を利用できる。 ◦ Data Catalog → Dataplex
Universal Catalog とリブランディング。 • Googleアカウントでログインして、データを探したり、メタデータを入力できる。 ◦ データセット（スキーマ）、テーブル、カラムそれぞれに説明文を記載できる。 ◦ 個人情報などのタグをつけることもできる。 • BigQueryの利用補助AIはデータカタログの情報を主に参照するため、充実させておくと良い。 • 集計ロジックの図解やデータ横断のルールなどは扱えないため、社内Wikiの整備が別で必要となる。 143

「データの説明文」には「横断のルール」と「個別の説明」がある 144 ＜例＞横断のルール固別の説明データセット（スキーマ） 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はデータを正確に使えるようになる。 • データカタログでは「横断のルール」を分けて管理できないため、全てのデータの説明文の中に、同じ「横断のルール」を書いておかなければならない。 • 「横断のルール」と「個別の説明」は別の設定ファイルで管理しておき、メタデータ統合システムで両者を統合してからデータカタログに連携する。

非構造化データ構造化データメタデータ管理の3層構造（1/2）メタデータも、収集（入口）→統合（中間）→提供（出口）の3層構造でパイプライン化される。 145 RDBMSのスキーマ情報＠DDL SFDCで入力する
データ項目＠管理シート Dataformが加工する BigQueryテーブル仕様＠設定ファイル BigQuery コンソール画面のクエリ作成補助AI （Gemini）各AIチャットへのデータ分析依頼や問い合わせデータ利用ガイド社内ポータル Dataplex Universal Catalog 一連のデータ仕様とクエリ生成のコツを組み込んだ社内MCPサーバ一連のデータ仕様を SphinxやJekyllなどのサイトジェネレーターに反映基幹システム顧客管理システム（CRM） BigQuery 加工テーブル BigQuery 利用記録 Cloud Loggingが出力する監査ログ＠監査ログ顧客対応システム Zendeskの入力手順社内マニュアル＠GoogleDocs 取得元メタデータの入口メタデータの出口利用先メタデータの中間 GitHubの専用リポジトリメタデータ管理プログラム

メタデータ管理の3層構造（2/2）前提：システムで自動化できるものは自動化し、人間は人間にしか扱えない情報に専念する。 • システムで自動生成されたメタデータはそうと分かるように自動生成のラベルをつける。 • 人間がチェックしたら認証済みのラベルを、管理部門が承認したら「公式」ラベルをつける。入口：データを生成する人が、データを生成する箇所で、メタデータを管理する。 • 例：SFDCの設定は管理者がシートで管理。RDBMSのスキーマはSREチームがDDLで管理。 •
理由1：データ基盤以外の通常業務でも使うため。何らかの形でメタデータは必要。 • 理由2：データ利用者が事後調査すると1日かかる。担当者本人が事前記入すると10分で済む。中間：それぞれのメタデータを集約管理する。 • 現状、ここを満たせるツールが世にないため、各社がGitHub管理の仕組みを作っている。出口：メタデータの利用箇所に合わせた場所・形式でメタデータを連携する。 • 例：GeminiでBigQueryを使う場合はDataplex Universal Caralogにメタデータが必要。 146

Google Cloudにおけるメタデータ管理の補助機能 • グロッサリー（辞書）：「売上」等のキーワードを設定し、関連データを紐づける。 • データプロファイリング：nullの割合、一意となる値の割合、平均、標準偏差、最大、最小、四分位数といった統計情報を確認する。 • データリネージ（依存関係）：どのテーブルがどのテーブルから作成されているか、を管理する。 147
https://cloud.google.com/data-catalog/docs/concepts/about-data-lineage https://cloud.google.com/blog/products/data-analytics/dataplex-business-glossary-now-ga

9. データ品質

風音屋が定義するデータ品質の5分類数十種類の「データ品質」を大まかにまとめると以下の5種類になる。①〜⑤の順に依存関係がある。例：①が不十分だと②〜⑤を正確に計測できない。②が不十分だと③で見るべきデータが存在しない。 151 ②データが適切な場所に置かれている（可用性・即時性・最新性・回復性・移植性） ③データの中身が現実を正確に表現している（正確性⊇完全性、一意性、一貫性、有効性、精度） ④適切な人が適切なデータにアクセスできる（アクセシビリティ・機密性）
⑤データが使いやすい状態になっている（ユーザビリティ⊇理解性、効率性、標準適合性） ①活動を追跡できる（追跡可能性・信憑性）

SLO（サービスレベル目標）をステークホルダーと合意する • 誰も望んでいないのに過剰な目標を追ってしまうと、徒労で終わる。 • 部署や用途ごとに暗黙的に期待されている品質目標を洗い出し、明文化して、関係者と合意する。 152 例用途約束相手連絡先
利用データ期待品質未達時の影響範囲 1 日次レポートマーケター Slack #daily_kpi BigQueryの売上テーブル毎営業日の8時までに欠損なく前日売上がレポートされること（即時性）売上状況に応じた施策が打てなくなる（機会損失） 2 … … … … … … 3 … … … … … … … … … … … … …

テスト・監視 Dataformによる定期データ集計時に、チェックを行う。 • Dataformの集計処理の成否。 • 各テーブルの更新日時、レコード件数、nullや空白の有無、値の範囲など。 • 処理エラーとなる場合はシステム管理者に通知を送る。 153 https://cloud.google.com/dataform/docs/assertions

データ利用者への案内 • ダッシュボードのトップ画面に「🚨現在判明している問題🚨」欄を設けて、検知可能にする。 • システム管理者への通知とは別に、データ利用者にチャットBotで速報を送る。 154

システムチューニング • 品質の目標と現状のギャップが大きい箇所（ボトルネック）を特定し、原因を特定する。 • 例えば、「朝8時までに売上集計を終わらせる」（即時性）が担保されていない場合、集計処理のうちどの部分に時間がかかっているのかを確認する。 • その上で、以下のようなチューニング施策を実施する。 ◦ 「全件更新」から「差分更新」に切り替える。前日分だけを集計する。
◦ 「クラスタリング」や「パーティション」でデータの参照範囲を区切る。 ◦ 処理Aの後に処理Bを行う「直列実行」から、A・Bを同時に行う「並列実行」に切り替える。 155 処理時間が最も長い箇所（＝ボトルネック）をチューニングする

週次ミーティングで改善サイクルを回す • 毎週の振り返りミーティングで現状（AsIs）と期待（ToBe）を比べる。 • その週のインシデント（トラブル）一覧を読み返す。 • サービスレベル目標（SLO）を満たせていなければ、改善アクションのためのTODOを起票する。 ◦ 例：新規データ連携を後回しにしてパフォーマンスチューニングを優先する。 •
サービスレベル目標（SLO）自体を見直す。 ◦ 過大目標であれば下方修正（e.g. 未使用ダッシュボードはメンテナンスせずに除却する） ◦ 過小目標であれば上方修正（e.g. データ更新頻度を毎週から毎日に変更する） 156 What 何をするかスプリントレビューどうやってするか How スプリントプランニングレトロスペクティブデイリースクラム

10. データセキュリティ・権限管理

データセキュリティで実現したいこと 160 よくある相談例 BigQueryで個人情報を扱うのは、カスタマーサポート（CS）部門の「問い合わせ対応」業務のみとしたい要件（Requirements）を言語化すると？ ①ルール違反をしたくない。 • 個人情報保護法に準拠したい。 • カスタマーに提示している利用規約やプライバシーポリシーに準拠したい。
• 個人情報取扱に関する社内規程に準拠したい。 ②「顧客ID」は使いたい。 • 厳密な「個人情報」の定義だと「顧客ID」も含まれてしまうが……。 ◦ 規約や用途によっては顧客IDの利用もNGになることがあるので注意！ • 顧客IDなどの仮名加工情報（それ単体では個人を特定できない情報）はOKとしたい。 • 氏名やメールアドレスなど、特定個人を直接的に表す情報のみNGとしたい。　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　etc…

データセキュリティの設定（全体像） 161 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）を設定する。また、要件に沿って運用していることを監視・監査する。

データセキュリティの設定（1/3）与件となるルール・規程（文書で管理） • 法令：個人情報保護法、金融商品取引法（インサイダー規制）、電気通信事業法（通信の秘密） • 認証基準：PCI DSS、Pマーク • 契約事項：利用規約、各取引先との契約書 •
社内規則：情報管理規定、セキュリティ細則取り扱うデータの種別（シートで管理） • PII（個人識別情報） • PHI（個人健康情報） • インサイダー情報（財務データなど） • 契約上の制限に抵触する情報 • 競争上の優位性に関わる情報 • 企業秘密に関わる情報 • 公開している情報 162 BigQueryのセキュリティ対策手順 - 風音屋TechBlog　https://techblog.kazaneya.com/20220830-bigquery-secure-guide/ 与件となるルール・規程（文書で管理）例位置付け項目法令個人情報保護法顧客合意利用規約 or 契約書社内ルール個人情報取扱に関する社内規程取り扱うデータの種別（シートで管理）例対象データ種別氏名特定個人を直接的に表す情報メールアドレス顧客ID 仮名加工情報メールアドレスのハッシュ値

データセキュリティの設定（2/3）機密性レベル（シートで管理） • 社外公開 • NDAの範囲内で共有 • 社外秘 • 限定共有：特定の役職、部署、プロジェクトメンバー
アクセス制御（Terraformで管理） • 通信要件 ◦ システム構成図から通信経路を網羅する ◦ アクセス元ｘアクセス先Bｘ権限（許可｜禁止） ◦ VPC Service Controls • 認証・認可 ◦ シートからデータ操作の組み合わせを網羅する ◦ 対象者グループｘ対象データｘCRUD権限 ◦ Cloud IAM 163 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でアクセス可能複数部門社員に閲覧権限を付与

データセキュリティの設定（3/3）監査・監視（GCS等で管理） • 監査ログの取得・保存 ◦ 各サービスごとに取得可能なログが異なるため、仕様詳細を確認・調査する ▪ 例：本資料作成時点でBigQueryの「Save results」の監査ログは誤検知しうる ◦
Cloud LoggingやGoogle Workspace管理機能で監査ログを取得する ◦ 他環境から独立した監査用Google CloudプロジェクトのGCSに保存する • 監査ログの参照 ◦ アラート条件で不審な変更・作業を早期検知 ◦ トラブル発生後に事後調査 ◦ 定期・不定期の監査でログを確認 • Google Cloudの自動チェックサービスで補完 ◦ Security Command CenterでCISベンチマークによる自動チェック ◦ Cloud DLPによる機密情報の混入チェック 164 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等で管理）例データ混入や権限付与ミス、意図しないデータアクセスなどのガイドライン違反を自動検知＆都度チェック

11. コスト管理

Cloud Billingによるコストモニタリング • 毎月のコストや内訳は Cloud Billing のコンソールで確認可能。 • 個人やスタートアップが無料サービスを中心に活用すれば、コストが問題になることは少ない。 ◦
嘉悦大学では月2万円でデータ基盤を運営。書籍『アジャイルデータモデリング』事例集より。 ◦ 数百円/月で業務利用しているケースもある。 168 https://cloud.google.com/billing/docs/how-to/cost-breakdown https://cloud.google.com/billing/docs/reports

監査ログによるBigQuery利用金額のモニタリング • Cloud Logging→GCS→BigQuery→LookerStudioに連携して、BigQueryの利用金額を可視化する。 ◦ 利用金額が高い or 増えている「チーム > ユーザー」x「テーブル」
チェックする。 • Cloud Logging→Cloud Monitoringでアラート設定を行って、高額クエリ検知時にSlack送信する。 • パフォーマンス・チューニングと同様に、余分なスキャンや集計処理を削っていく。 ◦ システムが毎日データを集計しているのにユーザーが使っていない場合はクリーニングする。 169 BigQueryのコスト可視化ダッシュボードを10分で作る - 下町柚子黄昏記 https://yuzutas0.hatenablog.com/entry/2018/12/18/160000 データレイク構築後の四方山話 #DPM / 20190905 https://speakerdeck.com/yuzutas0/20190905?slide=27

Cloud Run functionsの料金（東京リージョンの場合）簡易的なデータ収集だけならばそこまで大きな金額にはならない。毎日数万人のアクセスが来るような本格的なWebサービスを構築する場合にコストかかる。どうしても節約したいなら、オフィスや自宅で Mac Miniを常時起動してスクリプトを定期実行する手もあるが、端末代と電気代とエラー対応で多分赤字。 • リクエスト ◦
料金：$0.40/100万リクエスト ◦ 月額の無料枠：200万リクエスト ◦ シミュレーション：1日10万リクエストの場合、$0.40 = 60円 • コンピューティング（CPU） ◦ 料金：$0.000024/vCPU秒 ◦ 月額の無料枠：180,000 vCPU秒 ◦ シミュレーション：1日10万リクエスト * 1秒の場合、282万vCPU秒 → $67.7 = 10,155円 • コンピューティング（メモリ） ◦ 料金：$0.0000025/GB秒 ◦ 月額の無料枠：360,000 GB秒 ◦ シミュレーション：1日10万リクエスト * 1秒かつメモリ512 MiBの場合、114万GiB秒 → $2.85 = 428円 170 労力節約のために、Gemini DeepResearch、ChatGPT Deep Research、Claude Web Searchで並列調査させて同じ結果になったものを転記しています。詳細なファクトチェックを経ていないため、誤りがあったら申し訳ありません。なお、1ドル＝150円で計算しています。

Google Cloud Storageの料金（東京リージョンの場合）簡易的なデータ蓄積だけならばそこまで大きな金額にはならない。数千万人が毎日開くアプリだとさすがにそれなりの金額になるが、デフォルト設定が最安値と言って良いので、あまりチューニング余地もない。どうしても節約したいならGoogle DriveやBOXなどの導入済みクラウドストレージに置く手もあるが、ストレージ単位あたりの効率だけだとGCSのほうが安いはず。 • ストレージ（Standard
storage） ◦ 料金：$0.023/GB/月 ◦ シミュレーション：1日10GBのデータを保存 * 30日 * $0.023/GB = $6.9 = 1,035円 • オペレーション（Class A：書き込み） ◦ 料金：$0.005/1,000オペレーション • オペレーション（Class B：読み取り） ◦ 料金：$0.0004/1,000オペレーション 171 労力節約のために、Gemini DeepResearch、ChatGPT Deep Research、Claude Web Searchで並列調査させて同じ結果になったものを転記しています。詳細なファクトチェックを経ていないため、誤りがあったら申し訳ありません。なお、1ドル＝150円で計算しています。

BigQueryの料金（東京リージョンの場合）簡易的なデータ分析だけならばそこまで大きな金額にはならない。「毎月1TBまで無料のデータウェアハウス」は業界としても価格破壊の水準で、代替サービスも限られる。 • ストレージ ◦ 料金：$0.023/GB/月 ▪ 90日以上未変更のデータは半額になる ◦
月額の無料枠：10GB ◦ シミュレーション：毎月100GBのデータを保管すると90GB * $0.023/GB = $1.98 = 310円 • クエリ処理 ◦ 料金：$7.5/TB ◦ 月額の無料枠：1TB/月 ◦ シミュレーション：毎月30TBのクエリを実行すると29TB * $7.5/TB = $145 = 32,625円 • ストリーミング処理 ◦ 料金：$0.03/GB ◦ 備考：GA4からのデータ連携など一部が該当 172 労力節約のために、Gemini DeepResearch、ChatGPT Deep Research、Claude Web Searchで並列調査させて同じ結果になったものを転記しています。詳細なファクトチェックを経ていないため、誤りがあったら申し訳ありません。なお、1ドル＝150円で計算しています。

Cloud Loggingの料金（東京リージョンの場合）主に監査ログなどでの利用を想定。簡易的なデータ利用だけならばそこまで大きな金額にはならない。基本的にはGCSにバックアップを取って、余計なコストも発生させないようにする。さすがにデータを扱うのに「監査ログを取らない」はよろしくないので、必要経費と割り切るのが吉。 • ログ取り込み ◦ 料金：$0.50/GB ◦
月額の無料枠：50GB ◦ シミュレーション：毎日10GBのログを収集すると、250 GB * $0.50/GB = $125 = 18,750円 • 長期保持（30日以降） ◦ 料金：$0.01/GB/月 ◦ 備考：GCSに退避すれば削除可能 173 労力節約のために、Gemini DeepResearch、ChatGPT Deep Research、Claude Web Searchで並列調査させて同じ結果になったものを転記しています。詳細なファクトチェックを経ていないため、誤りがあったら申し訳ありません。なお、1ドル＝150円で計算しています。

12. 継続的開発を支える技術

開発標準・開発環境（1/2） 177 ▪ リポジトリ：コードの置き場。 • Git：コードの差分や履歴を管理するツール。AIエージェントがミスをしても復旧できる。 • GitHub：Git管理のコードをチームで共有し、開発を進めていくためのツール。 • GitHub
Actions：GitHubの機能。Linterや自動テスト、Terraform等の処理を実行できる。 ▪ CI（継続的インテグレーション）：継続的にコードを開発し、安全かつ効率的に統合する。 • Linter：コードが社内ルールに沿った書き方になっていることを自動チェックする仕組み。 ◦ 例：PythonならRuﬀ、SQLならSQLFluﬀ、TerraformならTFLint、。 • 自動テスト：コードが期待通りに挙動することを自動でチェックするための仕組み。 • Code Rabbit：GitHubで人間の代わりにコードレビューしてくれるAI。 ◦ 「シニアデータエンジニアとして振る舞って」「若手に助言するようにレビューして」「若手の反論が甘かったら徹底的にツッコミして」と設定すると、丁寧に教えてくれる。 ▪ CD（継続的デリバリー）：継続的にコードを本番環境へとリリースする活動。 • Terraform：クラウドインフラをコードで管理して、自動構築するためのツール。 ◦ IaC（Infrastructure as Code）なる概念。画面操作と異なり、作業ミス防止や横展開が容易。 ◦ 例：BigQueryの設定をコードで管理して、GitHubでレビューが通ったら自動反映。

開発標準・開発環境（2/2） 178 ▪ 開発標準：自社のルールを決めたり、仕組みを自動化することで開発効率を上げる。 • テンプレート：要件定義フォーマット、セキュリティ設計シート、コスト計測シート 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」な開発環境へ進化していく（はず）！

13. データ利活用の促進

データ利用促進＝社内マーケティング • 毎月のデータ利用の人数（MAU）が増えているか、安定しているか、をモニタリングする。 • どのチームで、どの水準までデータを利用できているか、をモニタリングする。 • 次の注力支援先を決めて、ニーズを調査し、仕組みを整え、社内営業とサポートを行い、伴走する。 182 株式会社風音屋（監訳）『アジャイルデータモデリング』より引用チームA
チームB チームC チームD チームE チームF 生ログ独自利用データT支援業務依頼データT支援データ出力自主的データ出力担当者依存自主的データ生成他チーム依頼基盤貢献！担当者依存担当者依存局所化自走改善 Data Management Guide - 事業成長を支えるデータ基盤のDev&Ops https://speakerdeck.com/yuzutas0/20211210

監査ログによるBigQuery利用状況のモニタリング • Cloud Logging→GCS→BigQuery→LookerStudioに連携して、BigQueryの利用状況を可視化する。 • クエリ実行数が多い or 増えている「チーム > ユーザー」x「テーブル」
チェックする。 • 「既に活用しているチーム」「まだ活用していないチーム」を把握し、社内営業やサポートを行う。 • 「活用ニーズがあるデータ」を優先して充実させたり、メンテナンスしたり、社内に宣伝する。 183 BigQueryのコスト可視化ダッシュボードを10分で作る - 下町柚子黄昏記 https://yuzutas0.hatenablog.com/entry/2018/12/18/160000 データレイク構築後の四方山話 #DPM / 20190905 https://speakerdeck.com/yuzutas0/20190905?slide=27

データ利用ガイドを社内提供 • 「ここで全体像が分かる」という社内Wikiを整備する。 • ダッシュボードのトップに、利用案内のURLを掲載する。 184

社内勉強会やハンズオン • データ利用の流れを解説したり、実際に体験してもらう場を設ける。 • 毎月の「相談会」で伴走しながら分析レポートを作り、そのまま上司や経営陣、投資家に報告する流れになるとスムーズ。上司から「A案件はデータ相談会に持ちこもう」と声が掛かるようになる。 185

• チャットツールで相談場所を設ける。 ◦ データチームで運用当番を設けてユーザーサポートに当たる。 • よくある問い合わせ（FAQ）はWikiやデータカタログツールに反映する。 ◦ 次からはURLの案内だけで済むようにする。 ◦ ナレッジを充実させることでAIの回答精度を高める。
• 自動対応するチャットBotを構築する。 ◦ Slackを窓口にするならGoogle CloudのConversational Analytics APIを用いて実装する。 ◦ 今後はAgentspace + GeminiやLooker (Studio Pro) のConversational Analyticsに期待。 ◦ データ項目追加や権限付与依頼はGitHub管理とし、Devin等の開発AIエージェントに任せる。問い合わせ対応や作業依頼 186 分析相談レビュー依頼 FAQ 充実化再利用

14. DXからAIエージェントへの変遷、データエンジニアリングの未来

DXの進め方①：現状のリソースの流れを書き出す「アナログ志向の業務」は「ヒト・モノ」（リソース）の流れに依存している。 190 自社法務郵便局員相手法務契約書を印刷署名・押印受付配達
受付配達受け取り受け取り署名・押印ヒトヒトヒトモノモノ

DXの進め方②：理想のデータの流れを書き出す「デジタル志向の業務」は「情報」（データ）の流れを最適化する。データ基盤の本来のコンセプト。 191 Input 入力 Processing 加工 Output 出力契約書PDF
自社署名相手署名内容確認締結署名済みPDF 取引記録

DXの進め方③：システムで自動化できる箇所を特定するツール導入やシステム化によって「人間」の作業を減らし、ムダ・ムラ・ムリを解消する。 192 Input 入力 Processing 加工 Output 出力契約書PDF
自社署名相手署名内容確認締結署名済みPDF 取引記録 ▪ヒトがやるべきこと（入力と確認） ▪DXで実現できること（加工と出力）

DXの進め方④：システムで置き換えた後のリソースの流れを書き出す「デジタル志向の業務」になった後のフローを書き出し、業務マニュアル作成やスタッフ研修を行う。システム構築やツール導入で終わりではなく、現場業務の落とし込みとカルチャー装着まで「変革」する。 193 自社法務 GMOサイン相手法務 PDFアップロード入力・送信受け取り
入力・送信ヒトヒト情報受け取り転送転送 DX

Beforeから「増やすべきもの」を追加し、「減らすべきもの」を取り除く。そのための予算確保、体制整備、社内営業＆サポートの徹底、ロードマップ策定・推進を行う。 DXの進め方⑤：BeforeとAfterの差分を埋めるのがDXプロジェクト 194 After Before 減らすもの増やすもの契約書PDF、電子契約ツール、 PDFアップロード、電子署名
紙の契約書(原本) 署名、捺印、郵送依頼、郵便局員、配達、受け取り

AIエージェント導入の勘所①：AIで半自動化できる箇所を特定する AI導入によって「人間」の作業＆判断をさらに減らし、ムダ・ムラ・ムリを解消する。 195 Input 入力 Processing 加工 Output 出力契約書PDF
自社署名相手署名内容確認締結署名済みPDF 取引記録 ▪ヒトがやるべきこと（入力と確認） ▪DXで実現できること（加工と出力） ▪AIが一部担えること（草案作成＆懸念指摘） NEW!

AIエージェント導入の勘所②：AI導入後のリソースの流れを書き出す業務手順の中にAIエージェントを組み込む。あるいはAIエージェントの中に人間の介在箇所を組み込む。業務マニュアル作成やスタッフ研修を行い、現場業務の落とし込みとカルチャー装着まで「変革」する。 196 自社法務担当 GMOサイン相手法務担当 PDFアップロード承認・送信受け取り
入力・送信ヒトヒト受け取り転送転送法務’sサポートAI　　. （ワトソン君）契約書の作成自社記入欄の入力情報 DX AI

AIネイティブな時代の「ビジネス」や「オペレーション」の行き着く先あらゆる事業（ビジネス）や業務（オペレーション）は以下の一連の活動と言える。 • 何らかのリソースを投入（Input）して • 何らかの価値を付加（Processing）して • 何らかの財・サービスを提供（Output）する AIエージェントによって「情報」（データ）の担う部分が拡大する。結果、あらゆるビジネスやオペレーションが「データエンジニアリング」化する。
• 「情報」（データ）の流れを制御する中核システムが「データ基盤」 • 「情報」（データ）の流れを制御する活動が「データエンジニアリング」 ⇒Development（仕組みの構築）　「データエンジニアリング」と「AIエージェント導入」と「業務定義」と「経営」とが一体化する。 ⇒Operations（仕組みの運営）　「データ基盤」と「AIエージェント」と「業務フロー」と「事業運営」とが一体化する。 197

ITエンジニアやWEBマーケターだけではなく、人事や経理などのバックオフィス職（事務職）にも「AIエージェント」や「データエンジニアリング」の考え方が必要になるバックオフィス職にもAI＆データが必須の時代 198

15. おわりに

データエンジニアリングを楽しもう！ 201 データエンジニアリングは、いわば総合格闘技です。データの重要性が日々増していく時代、世界中で誰もが困っている課題に立ち向かっていく仕事です。データ活用やビジネス理解の面白さ（そして難しさ）が詰まった、やりがいのある分野です。 Google Cloudは、データエンジニアリングの最前線を開拓し、同時に、専門家以外にも裾野を広げる魅力的なソリューションだと思っています。ぜひフル活用していきましょう。この発表が皆様の業務に少しでもお役に立てたら嬉しく思います。

ご清聴ありがとうございました 202 改善サイクルを回し、今日よりも良い明日を。 https://kazaneya.com/contact

Google Cloud で学ぶデータエンジニアリング入門 2025年版 #GoogleClo...

Google Cloud で学ぶデータエンジニアリング入門 2025年版 #GoogleCloudNext / 20250805

Video

More Decks by 風音屋 (Kazaneya)

Other Decks in Technology

Featured

Transcript