はじめに こんにちは！ KINTOテクノロジーズのデジタル戦略部DataOpsグループ所属の三浦です。 普段は、社内のデータ分析基盤の開発・保守・運用に加え、Google Analytics 4（以下、GA4）やGoogleタグマネージャー（以下、GTM）を利用した、Webサイトのアクセス解析や計測環境の整備を担当しています。 WebサイトでGA4やGoogle広告を計測する場合、一般的にはGoogleドメインからGoogleタグを読み込み、Googleドメインへ計測リクエストを送信します。 一方、ブラウザのプライバシー保護機能や広告ブロッカーなどの影響により、Googleタグの読み込みや計測リクエストがブロックされ、イベントが欠損することがあります。 今回、この課題への対応として、既存のAmazon CloudFrontを利用し、Googleタグゲートウェイを導入しました。 本記事では、Googleタグゲートウェイを導入した背景や構成、社内での役割分担、検証時に確認したポイント、導入後に確認できた効果について紹介します。 本記事の対象者 本記事は、以下のような方を対象としています。 GTMやGA4を利用したWebサイトの計測を担当している方 Googleタグゲートウェイの導入を検討している方 Amazon CloudFrontをCDNとして利用している方 本記事では、CloudFrontの細かな設定手順ではなく、導入時の考え方や進め方、検証内容を中心に紹介します。 Googleタグゲートウェイ導入の背景と概要 背景 当グループでは、Webサイトの利用状況や広告施策の成果を把握するため、GTMを利用してGA4やGoogle広告などの計測タグを配信しています。 通常の構成では、WebサイトからGoogleドメイン上のGoogleタグを読み込み、計測したイベントをGoogleドメインへ送信します。 通常のGoogleタグ配信の構成 しかし、Googleドメインへの通信は、ブラウザのプライバシー保護機能や広告ブロッカーなどによって、制限されることがあります。 計測タグや計測リクエストがブロックされると、ユーザーが実際にページを閲覧したり、コンバージョンしたりしていても、GA4やGoogle広告へイベントが送信されません。 その結果、以下のような課題が発生する可能性があります。 GA4で確認できるイベント数が、実際の発生件数より少なくなる コンバージョン数が正しく計測されない Webサイトの施策評価に使用するデータが不完全になる 広告経由の成果を正しく評価できない 広告配信の最適化に使用するコンバージョンデータが不足する 特に広告配信では、計測したコンバージョンデータが、自動入札や配信対象の最適化に利用されます。 そのため、イベントの欠損は、レポート上の数値が少なくなるだけでなく、広告配信の学習や最適化にも影響する可能性があります。 実際に対象サイトでは、GA4で計測しているコンバージョンページのイベント数と、バックエンドのデータベースに保存されているコンバージョン件数に差がありました。 もちろん、GA4とバックエンドのデータベースでは、計測の仕組みや集計条件が異なります。 そのため、数値が完全に一致するものではありません。 一方で、差が大きい状態では、実際に発生したコンバージョンの一部をGA4で取得できていない可能性があり、広告施策やサイト改善を評価するうえで課題となっていました。 そこで、Googleタグへの通信を自社ドメイン経由に変更し、タグやイベントがブロックされる影響を軽減することを目的として、Googleタグゲートウェイを導入しました。 概要 対象のWebサイトでは、CDNとしてすでにAmazon CloudFrontを利用していました。 そのため、新たにサーバーを構築するのではなく、既存のCloudFrontを利用してGoogleタグゲートウェイへの通信を中継する構成を採用しました。 導入後の構成は以下のとおりです。 flowchart TB Browser[Webブラウザ] --> Domain[Webサイトと同じ自社ドメイン] Domain --> CF[Amazon CloudFront] CF -->|通常のWebコンテンツ| Origin[既存の配信先] CF -->|Googleタグゲートウェイ用のパス| GTG[Googleタグゲートウェイ] GTG --> GA4[GA4・Google広告など] Webサイト上にGoogleタグゲートウェイ用のパスを用意し、そのパスへの通信をCloudFrontからGoogle側へ転送します。 ブラウザから見ると、Googleタグの読み込み先や対象となる計測リクエストの送信先が、Googleドメインではなく、Webサイトと同じ自社ドメインになります。 Googleタグゲートウェイ導入前後の構成図 要素技術・アーキテクチャの紹介 ここからは、今回の導入で利用したGoogleタグゲートウェイとAmazon CloudFrontについて紹介します。 Googleタグゲートウェイとは？ Googleタグゲートウェイ（ Google tag gateway for advertisers ）は、自社が管理するCDNやロードバランサーなどのインフラを利用して、Googleタグを自社ドメイン経由で配信する仕組みです。 通常はGoogleドメインから読み込まれるGoogleタグを、自社ドメイン上の特定のパスから読み込めるようにします。導入前後の経路の違いは、前述の「 概要 」節の構成図のとおりです。 Googleタグゲートウェイでは、GA4のイベント設計や、GTMコンテナ内のタグの処理内容を大きく変更するのではなく、Googleタグへアクセスする経路を変更します。 そのため、既存のGTMコンテナ内のタグ、トリガー、変数などを維持したまま導入できます。 Amazon CloudFrontとは？ Amazon CloudFront は、AWSが提供するCDNサービスです。 Webサイトのコンテンツを利用者に近い拠点から配信することで、表示速度や可用性の向上に利用されます。 CloudFrontでは、アクセスされたURLのパスに応じて、異なる配信先へリクエストを振り分けられます。 今回はこの仕組みを利用し、Googleタグゲートウェイ用のパスへの通信のみを、Google側へ転送するようにしました。 サーバーサイドGTMとの違い Googleタグゲートウェイと混同しやすい仕組みに、サーバーサイドGTMがあります。 サーバーサイドGTMでは、サーバー用のGTMコンテナを構築し、サーバー側で計測リクエストを処理し、送信先を制御します。 一方、Googleタグゲートウェイは、Googleタグの読み込みや対象となる計測リクエストを、自社ドメイン経由に変更する仕組みです。 観点 Googleタグゲートウェイ サーバーサイドGTM 変更するもの Googleタグへの通信経路 計測リクエストの処理・送信先 追加で必要なもの CDN / ロードバランサーの設定 サーバー用GTMコンテナと実行環境 既存のWeb用GTMコンテナ そのまま利用 サーバー用コンテナ向けの設定追加が必要 今回の目的は、既存のGTM構成を維持しながら、Googleタグへの通信経路を変更することでした。 そのため、新たなサーバー用GTMコンテナは構築せず、既存のCloudFrontとWeb用のGTMコンテナを利用する構成を採用しました。 導入の進め方 各担当者の役割分担 今回の導入では、計測担当だけでなく、インフラ担当、プロダクトチームのサイト管理者と連携して進めました。 大きな役割分担は以下のとおりです。 DataOpsグループ・計測担当 Googleタグゲートウェイの導入目的と要件の整理 対象ドメインや対象環境の整理 Googleタグゲートウェイ用パスの検討 ブラウザやGA4を利用した動作確認 既存の計測への影響確認 導入前後のイベント数の比較 インフラ担当 CloudFrontへのGoogleタグゲートウェイ用設定の追加 Googleタグゲートウェイへの転送設定 検証環境と本番環境への設定反映 必要に応じたCloudFrontやWAFの調査 プロダクトチーム・サイト管理者 Webサイトに設置しているGTMコードスニペットの差し替え 検証環境と本番環境へのリリース Googleタグゲートウェイは、GTMやGA4だけで完結する機能ではありません。 CDNなどの配信基盤と、Webサイトへ設置しているGTMコードスニペットの両方に対応が必要です。 そのため、導入前に各担当者の作業範囲と、検証時の確認項目を整理しました。 GTMコンテナ側の設定は変更しない Amazon CloudFrontを利用した今回の構成では、GTMコンテナ側でGoogleタグゲートウェイ用の設定変更は行っていません。 既存の本番用GTMコンテナを、そのまま利用しました。 変更したのは、Webサイトに設置されているGTMコードスニペットの読み込み先です。 変更前 GoogleドメインからGTMコンテナを読み込む 変更後 自社ドメイン上のGoogleタグゲートウェイ用パスから 同じGTMコンテナを読み込む GTMコンテナ内のGA4タグ、Google広告タグ、トリガー、変数などは変更していません。 GTMコードスニペットの差し替えについては、Webサイトを管理しているプロダクトチームへ依頼し、検証環境と本番環境へ反映してもらいました。 通信経路のみを変更する構成だったため、既存の計測設計への変更を抑えて導入を進められました。 検証用GTMコンテナは作成しない 今回の導入では、Googleタグゲートウェイの検証用に、新しいGTMコンテナは作成しませんでした。 実際に本番環境で利用しているGTMコンテナを、検証環境でもそのまま利用しました。 導入の流れは以下のとおりです。 検証環境のCloudFrontへ設定 検証環境のGTMコードスニペットを差し替え 検証環境で動作確認 本番環境のCloudFrontへ設定 本番環境のGTMコードスニペットを差し替え 本番環境で動作確認 先に検証環境のCDNへGoogleタグゲートウェイの設定を追加し、プロダクトチームに検証環境のGTMコードスニペットを差し替えてもらいました。 そこで問題がないことを確認した後、本番環境のCloudFront設定とGTMコードスニペットを変更しました。 本番用のGTMコンテナをそのまま使用したことで、検証用コンテナと本番用コンテナの間に設定差分が発生しません。 実際に本番で使用するタグ構成のまま、通信経路の変更による影響を確認できました。 検証時のポイント Googleタグが自社ドメインから読み込まれているか 最初に、ブラウザの開発者ツールにあるNetworkタブを利用し、GTMコンテナの読み込み先を確認しました。 導入前はGoogleドメインから読み込まれていたGTMコンテナが、導入後は自社ドメイン上のGoogleタグゲートウェイ用パスから読み込まれていることを確認します。 導入前 https://www.googletagmanager.com/... 導入後 https://www.example.com/<Googleタグゲートウェイ用パス>/... 読み込み先だけでなく、HTTPステータスコードが正常であることや、ページ表示時にGTMコンテナが問題なく実行されていることも確認しました。 既存のタグがこれまでどおり発火するか Googleタグの読み込み先を変更しても、GTMコンテナ内のタグやトリガーが、これまでどおり動作する必要があります。 GTMのプレビューモードを利用し、以下を確認しました。 ページ表示時に必要なタグが発火すること クリックなどのイベントタグが発火すること GA4へ必要なイベントが送信されること イベントパラメータの値が導入前と変わっていないこと 同一イベントが重複して送信されていないこと 今回、GTMコンテナ内の設定自体は変更していません。 そのため、通信経路を変更したことで、既存のタグ発火やイベント送信に影響が出ていないかを中心に確認しました。 GA4でイベントを確認できるか ブラウザ上でタグが発火していても、最終的にGA4へイベントが到達していなければ、計測は成立しません。 GA4のDebugViewやリアルタイムレポートを利用し、以下を確認しました。 ページビューが送信されていること 主要なイベントが送信されていること イベントパラメータが欠損していないこと page_location などの値が正しいこと コンバージョンページのイベントが送信されていること 導入前と比較して、想定外の重複や減少がないこと Googleタグゲートウェイを経由した場合でも、GA4上では、これまでと同じイベント名やパラメータとして確認できます。 SPAの画面遷移も確認する 対象サイトには、ページ全体を再読み込みせずに画面を切り替えるSPA形式のページもありました。 SPAでは、初回表示時にGTMコンテナが正常に読み込まれていても、その後の画面遷移でページビューやイベントが正しく送信されるとは限りません。 そのため、以下を分けて確認しました。 ページを最初に表示したときの計測 ページ内で画面遷移したときの計測 画面遷移後の page_location 仮想ページビューの発火 前画面の値が dataLayer に残っていないか 同じイベントが重複して送信されていないか Googleタグゲートウェイ自体は通信経路を変更する仕組みですが、導入を機に、既存のSPA計測が正常に動作していることも合わせて確認しました。 プレビューモードだけで判断しない GTMのプレビューモードでは正常に見えていても、プレビューモードを利用しない通常アクセスでは、想定した通信が発生していない場合があります。 そのため、以下の両方で確認しました。 GTMのプレビューモードを利用した状態 プレビューモードを利用しない通常アクセス 問題が発生した場合は、以下の順番で確認すると、原因を切り分けやすくなります。 Webサイト上でGTMコードスニペットが実行されているか GTMコンテナが読み込まれているか 対象のタグが発火しているか ブラウザから計測リクエストが送信されているか CloudFrontへリクエストが到達しているか Google側へ転送されているか GA4でイベントを確認できるか ブラウザのNetworkタブにリクエスト自体が表示されていない場合は、CloudFrontより前のWebサイトやGTMの処理を確認します。 一方、ブラウザからリクエストが送信されているものの、エラーになっている場合は、インフラ担当と連携して、CloudFrontやWAFなどを確認します。 すべての通信が自社ドメイン経由になるわけではない 検証時には、ブラウザのNetworkタブからGoogle関連の通信を確認しました。 その結果、GA4の計測では自社ドメイン経由になっている通信を確認できましたが、一部の通信は、引き続きGoogleドメインへ送信されていました。 :::message Googleタグゲートウェイを導入したからといって、Googleに関係するすべての通信が自社ドメイン経由になるわけではありません。 ::: そのため、Googleドメインへの通信が完全になくなるかどうかではなく、対象となるGoogleタグや計測リクエストが、想定どおり自社ドメインを経由しているかを確認しました。 導入後の効果 Googleタグゲートウェイの導入後、タグの発火状況と、コンバージョンページのイベント数を確認しました。 タグの発火状況が改善した 導入前は、Googleタグの読み込みや計測リクエストをGoogleドメインへ直接送信していました。 導入後は、対象通信が自社ドメインを経由する構成へと変更されました。 これにより、広告ブロッカー等に起因するタグの未発火が抑制され、GA4へ送信されるイベント数が前月比・前週比で約10〜15%増加しました。 :::message 旧環境との完全な並行稼働による厳密な差分比較はできないため、前後期間の傾向に基づく推定値です。 ::: Googleタグゲートウェイを導入しても、すべてのユーザー環境で必ずタグが発火するようになるわけではありません。 例えば、以下のような要因によって、引き続きイベントが送信されない可能性があります。 JavaScriptが無効化されている ユーザーの同意状況によって計測が制限されている ページ表示が完了する前にユーザーが離脱した ブラウザやネットワークの状態によって通信に失敗した 一方で、Googleドメインへの直接通信がブロックされることによるイベント欠損については、一定の改善効果を確認できました。 GA4とバックエンドデータベースの数値差が縮小した 今回、導入効果を確認するため、GA4で計測したコンバージョンページのイベント数と、バックエンドのデータベースに保存されているコンバージョン件数を比較しました。 導入前は、バックエンドのデータベース上ではコンバージョンが記録されているものの、GA4では対応するイベントを確認できないケースがあり、両者の数値に大きな差がありました。 導入前 バックエンドDBのコンバージョン件数 ＞ GA4のコンバージョンページイベント数 Googleタグゲートウェイの導入後は、GA4で確認できるコンバージョンページのイベント数が増加し、バックエンドのデータベースに記録されている件数へ大きく近づきました。 導入後 バックエンドDBのコンバージョン件数 ≒ GA4のコンバージョンページイベント数 バックエンドのデータベースとGA4では、計測の仕組みや集計条件が異なるため、両者の数値が完全に一致するとは限りません。 例えば、コンバージョン処理がバックエンドで完了していても、ユーザーが完了ページを表示する前に離脱した場合は、GA4のページイベントが発生しない可能性があります。 また、同意設定やブラウザ環境などによって、GA4への送信が制限される場合もあります。 それでも、導入後に両者の数値差が大きく縮小したことから、これまで欠損していた一部のイベントを取得できるようになったと考えています。 広告施策の評価に利用するデータが改善した コンバージョンイベントの取得数が増えたことで、GA4やGoogle広告で確認できるデータが、実際のコンバージョン状況により近づきました。 これにより、広告施策ごとの成果を、導入前より正確に評価できるようになりました。 また、Google広告へ連携されるコンバージョンデータの欠損が減ることで、自動入札や広告配信の最適化に利用できるデータ量の改善も期待できます。 ただし、広告の成果や配信精度は、以下のような複数の要因に左右されます。 広告予算 入札戦略 ターゲティング 広告クリエイティブ ランディングページ 市場環境 コンバージョン設定 そのため、Googleタグゲートウェイの導入だけで広告成果や広告精度が向上したとは断定していません。 今回の主な成果は、広告施策の評価や配信最適化に利用する、コンバージョンデータの欠損を減らせたことだと考えています。 振り返り GTMコンテナ内の変更を抑えて導入できた 今回の構成では、GTMコンテナ内のGA4タグ、Google広告タグ、トリガー、変数などを変更していません。 CloudFront側の通信経路と、Webサイトに設置しているGTMコードスニペットの読み込み先を変更することで導入できました。 既存の計測設計への影響を抑えながら導入できた点は、大きなメリットでした。 検証環境から段階的に導入することが重要 いきなり本番環境へ反映するのではなく、先に検証環境のCloudFront設定とGTMコードスニペットを変更しました。 検証環境では、GTMコンテナの読み込み、GA4イベント、SPA遷移、コンバージョンページなどを確認しました。 問題がないことを確認した後に本番環境へ展開することで、既存計測への影響を抑えながら導入できました。 複数チームの連携が必要 Googleタグゲートウェイは、GTMやGA4だけでなく、CloudFrontなどの配信基盤と、Webサイトに設置されるコードにも関係します。 今回の導入では、DataOpsグループ、インフラ担当、プロダクトチームがそれぞれ以下を担当しました。 DataOpsグループ：要件整理、計測確認、効果検証 インフラ担当：CloudFrontの設定 プロダクトチーム：GTMコードスニペットの差し替え 事前に担当範囲を整理したことで、検証環境から本番環境への展開をスムーズに進められました。 レイヤーごとに切り分けることが重要 Googleタグゲートウェイ導入後の通信には、複数の要素が関係します。 Webサイト ↓ GTMコードスニペット ↓ GTMコンテナ ↓ ブラウザ ↓ Amazon CloudFront ↓ Googleタグゲートウェイ ↓ GA4・Google広告など 問題が発生した場合は、最初からすべてを調査するのではなく、どこまで正常に処理されているかを順番に確認することが重要です。 ブラウザのNetworkタブ、GTMのプレビューモード、GA4のDebugViewなどを組み合わせることで、問題がWebサイト側にあるのか、GTMにあるのか、インフラ側にあるのかを切り分けやすくなりました。 おわりに 今回は、Amazon CloudFrontを利用して、Googleタグゲートウェイを導入した事例を紹介しました。 Googleタグゲートウェイの導入だけで、すべてのイベント欠損を防げるわけではありません。 一方で、Googleドメインへの直接通信がブロックされることによる欠損を軽減し、サイト改善や広告施策の判断に利用するデータを、実態に近づける効果を確認できました。 Amazon CloudFrontを利用してGoogleタグゲートウェイの導入を検討されている方にとって、本記事が少しでも参考になれば幸いです。

GA4のGeminiを活用した新機能「Ask Advisor」（旧 Analytics Advisor）について検証します。

1. はじめに こんにちは、スタンバイでデータエンジニアを担当している権藤です。 私が所属する Data Platform Group では、データ基盤の開発・運用・保守を担当しています。 今回はデータ基盤の移行について、計画〜実行までの過程を紹介していきます。 2. 移行の背景と計画 移行前のアーキテクチャの問題点 当時開発・運用していたデータ基盤について様々な課題が発生したため、リプレイスすべきだろうという話が挙がりました。 (以下、旧データ基盤と呼びます) 旧データ基盤の構成図は以下になります。 移行前のアーキテクチャ図 代表的な技術スタックは以下です。 スタンバイのサービスは AWS 上に構築されているため、技術スタックも AWS のものをメインで用いています。 ストレージ: S3 データカタログ: Glue Data Catalog ETL 処理: Glue Job (PySpark) 集計処理: Athena オーケストレーション: Amazon Managed Workflows for Apache Airflow (MWAA) BI ツールなど: Redash、Looker Studio 課題は山積みだったのですが、闇雲に「モダンデータスタックを使ってイケてるシステムに作り変えたい」とするのは危険と考え、まずデータ基盤が抱えている課題を1つ1つ洗い出していくことにしました。 課題の可視化・細分化を行うにあたり、実施したものが以下になります。 データマネジメント成熟度アセスメント データ基盤利用者へのアンケート データマネジメント成熟度アセスメントの実施 データマネジメント成熟度アセスメント (Data Management Maturity Assessment、以下 DMMA と呼びます) とは、 DMBOK2 で以下のように定義されています。 組織内で実施されているデータ関連業務に対してランク付けする方法。データマネジメントの現状とそれが組織に与える影響を明らかにする。 DMBOK2 で定義されているデータマネジメントの知識領域を大分類として合計 77 個の質問項目を用意し、それぞれ5段階評価を付けてその平均スコアをレーダーチャートにするという手法をとりました。 DMMAスコア これらの質問へはデータマネジメントに関わるメンバー、今回だとデータエンジニアが回答しました。 実務とデータマネジメントの知識領域との双方を把握していないと回答自体が難しく、また実行可能な改善計画を立てるため、データエンジニアを中心に実施しました。 DMMA 実施によって、以下の改善効果を得ることができました。 知識領域ごとの強み・弱みが明らかになる 定期的な DMMA の実施により、データマネジメントの成熟度を測ることができる データ基盤利用者へのアンケートの実施 先述の DMMA の実施は主に開発者 (データエンジニア) を対象としたものでしたが、こちらは利用者を対象としたものです。 開発者からは見えない視点での評価・意見を拾うことが目的です。 アンケートの質問項目は、回答者のハードルを下げるために極力選択式としました。(別途、自由記述の質問項目も設けています) 質問の一例は以下になります。 主な利用目的は？ よく利用する周辺ツールは？ よく利用するデータは？ 現在のデータ基盤に対する満足度は？ データ基盤について現在直面している問題は？ アンケートの実施によって、利用者の課題感・要望が明らかになりました。 具体例を以下に示します。 様々なデータを同じデータ基盤上で扱いたい (複数のデータを統一の SQL で参照したい) データの関係性がわかりにくい (データリネージュ・メタデータの不足) KPI の計算式を統一したい (分析者によって SQL の記述方法が異なるため統一したい) データの欠損が一部あり、分析がしづらい (データ品質の不足) 重点課題の設定 これら2つの調査結果を統合し、データマネジメントの観点で整理した結果、解決すべき「5つの重点課題」とその解決ソリューションを定義しました。 1. 非効率なデータ統合 GA4やSalesforceなど、事業上重要とみなされているデータが基盤に取り込まれておらず、社内にデータが散在（サイロ化）している。 現在の S3 + Athena 構成では新しいデータの追加に作り込みが必要で、気軽に追加できないため、データ利活用者が複数のシステムをまたいで手作業でデータを結合するなどの無用な工数が発生している。 2. ER 図の欠如 テーブル間の関係性（キーの結合やレコードの対応関係）を直感的に表現するER図が提供されていない。 そのため、データ基盤の利用者にとってテーブル同士の関係が分かりにくく、データ活用の障害となっている。 3. 不完全なデータリネージ テーブル間の派生関係（どのテーブルから何が作られたか）を示すリネージは提供されているが、完全なものではない。 S3 + Athena 構成ではデータ変換の自由度が高すぎてプロセスが統制されていないため、一部でリネージが取得できなくなっている。 4. 部署や担当者ごとの KPI 計算の不一致 事業上の主要なKPI（セッション数など）の計算式や条件が、部署や担当者ごとに異なってしまう問題が発生している。 これはデータのサイロ化を招くだけでなく、利用者が「正しいSQLの書き方が分からない」という悩みにもつながっている。 5. データ品質テストの不足 データ品質のテストがごく一部でしか行われておらず、不備があっても長い間気づけないリスクがある。 実際に過去、カラム内容の不備が数週間発見されず機械学習モデルに影響を与えた事例もあり、基盤に対する利用者の信頼を損なう要因となっている。 課題解決方針 アセスメントとアンケートによって特定された5つの重点課題に対し、私たちは単なる部分最適ではなく、データ基盤のアーキテクチャ全体を見直す形で以下のような解決方針を策定しました。 1. 効率的なデータ統合 外部データ連携に強みを持つモダンなDWH製品の導入と併せ、Fivetran や Airbyte などのデータ統合ツールを活用する。 これにより、GA4やSalesforceなどのサイロ化されたデータを、最小限の開発工数で一元管理できる仕組みの構築を目指す。 2. ER 図の自動提供 手動によるドキュメント運用の限界を打破するため、dbt などのデータモデリングツールを導入する。 コード（DDL）からER図を自動的に生成・更新し続ける仕組み（dbterdなど）をパイプラインに組み込み、データの認知コストを下げる。 3. 完全なデータリネージの確立 データ変換プロセスをすべて dbt 配下に集約してフローを統制し、データの変遷をトレース可能な環境を構築する。 4. ビジネスロジック （KPI） の共通化 データと利用者の間に dbt Semantic Layer などの「セマンティックレイヤー」を導入する。 部署ごとに散在していたKPIの計算ロジックを一箇所にコードとして集約し、全社で「信頼できる唯一のソース（SSOT）」を参照できる状態を確立する。 5. データ品質テストの自動化 サイレントなデータ不備による信頼低下や下流への悪影響を防ぐため、dbt のテスト機能をパイプラインの実行フローに組み込む。 重要なテーブルやカラムに対する「非nullチェック」や「一意性チェック」を自動化し、異常を早期発見できる体制を整える。 3. 技術選定 前章の課題解決策として「dbt」という単語が何度か登場しましたが、本章ではなぜ数あるツールの中から dbt を選んだのか、そしてその実行基盤（DWH）としてなぜ Databricks を選定したのか、その詳細なプロセスを記載します。 dbt の採用 dbt とは Data Build Tool の略で、DWH 上でのデータ変換（Transform）を SQL で管理するツールです。 https://www.getdbt.com/ SELECT 文を記述するだけで変換処理をモジュール化でき、テストによるデータ品質の自動検証、ドキュメントの自動生成、テーブル間のリネージ追跡といった機能を標準で備えています。 解決すべき5つの課題の多くが「データ変換とガバナンス」に集中していたため、以下の理由から dbt の採用を早期に決定しました。 ELT アーキテクチャへのシフトによる工数削減 従来の Glue Job (PySpark) を中心とした複雑な ETL から、SQL を中心とした ELT アーキテクチャへ転換した。これにより、複雑な Spark コードのメンテナンスから解放され、学習コストを抑えつつ開発スピードを最大化できる エコシステムの成熟度とポータビリティ 主要な DWH との Adapter が公式・コミュニティ双方で活発に開発されており、将来的なインフラの変化にも柔軟に対応できる信頼性を評価した。 「データ品質」と「リネージ」の標準装備 DMMA で特に低スコアだったデータ品質とリネージの課題に対し、dbt test による自動検証や、プロジェクト構造から自動生成されるデータリネージ機能が決定打となった。 ビジネスロジックの一元管理 dbt Semantic Layer 等の活用により、部署間で散在していた KPI 計算ロジックを統合し、「信頼できる唯一のソース（SSOT）」を構築できる点を重視した。 DWH 製品の選定：検証プロセスと結果 dbt を導入するためには、当時の構成（S3 + Athena）では公式な Adapter サポートが不十分でした。 （※ 現在は dbt Labs による公式サポートが提供されています。） dbt のポテンシャルをフルに引き出し、データマネジメントを Phase 2 以上へ進めるためには、実行基盤となる DWH 自体の刷新が不可避であるという結論に至りました。 dbt を導入する土台となる DWH の選定にあたっては、候補となる複数の主要な DWH 製品の中から最終候補を2製品に絞り込み、実際のワークロードを用いた PoC（概念実証）を実施しました。 検証の進め方 今回の PoC では、単なる機能比較に留まらず、エンジニアによる技術検証と利用者による UI 評価の両面からスコアリングを行いました。 主な検証項目と評価 以下の観点でスコアリングを行いました。 具体的には、以下の 6 項目を重点的に検証しました。 検証カテゴリ 検証内容（一例） 評価結果の要約 コスト クエリ実行、インスタンス起動の費用 Databricks が優位。同一シナリオにおいて、他の競合製品よりも低コストで実行可能であることを確認。 データロード S3 からのデータロード・外部テーブル参照 いずれの製品も容易だが、Databricks は S3 上のデータを直接参照・管理する親和性が高い。 開発体験 SQL / Python の記述、デバッグのしやすさ 競合製品は SQL 中心で洗練されている一方、Databricks はノートブックによる Python / SQL の混在開発に強みを持つ。 エコシステム dbt 連携の安定性、周辺ツールとの接続 いずれの製品も dbt との親和性は極めて高い。 ガバナンス カタログ、権限管理、リネージの自動化 Databricks の Unity Catalog による一元管理と、自動生成されるリネージを高く評価。 AI / 機械学習 生成 AI 連携、ノートブックの AI 補助 Databricks が充実。AI アシスタントや Genie 等の機能が豊富。 総合判断 PoC での定量・定性的な検証を経て、最終的に Databricks の採用を決定しました。 以下の3点を評価しました。 1. オープンなデータ管理とポータビリティ Databricks は S3 上に Delta Lake（オープンフォーマット） でデータを保持します。 特定ベンダーの独自ストレージにロックインされず、他の AWS サービスからも直接データを活用できるオープン性が、弊社の将来的なアーキテクチャの柔軟性に合致しました。 2. コストパフォーマンスの良さ 大規模なログデータを扱う弊社のワークロードにおいて、インフラコストの効率性は重要な検討材料の1つでした。 PoCにおける検証の結果、同一の集計処理シナリオにおいて、比較対象とした製品よりも Databricks の方が約 3 割ほどコンピューティング費用を抑えて実行できる見込みであることが分かりました。 中長期的なデータ量の増加を考慮した際、このコスト効率の良さは好ましい要素となりました。 3. AI 活用とデータ活用の民主化 検証項目の1つであった「AI 機能」において、Databricks の進化の速さを実感しました。 特に自然言語でデータ探索が可能な Databricks Genie 等の機能は、データエンジニアの工数を削減しつつ、非エンジニアが自律的に分析を行える「データの民主化」を加速させると感じました。 4. 移行後のアーキテクチャ Databricks 移行後の構成図は以下のようになりました。 (以下、新データ基盤と呼びます) 移行後のアーキテクチャ図 技術スタックも以下のようになり、ストレージ以外は全て変化しています。 ストレージ: S3 データカタログ: Unity Catalog ELT 処理: dbt × Databricks SQL オーケストレーション: Databricks Lakeflow Jobs BI ツールなど: Databricks Dashboard これにより、先に挙げた5つの重点課題に対する具体的なソリューションを用意できるようになりました。 課題解決方針 具体的なソリューション 1. 効率的なデータ統合 Databricks のマネージドコネクタの利用 2. ER 図の自動提供 dbterd や Databricks の Constraints による外部キーの設定 3. 完全なデータリネージの確立 dbt による高度なリネージ機能 4. ビジネスロジック （KPI） の共通化 dbt Semantic Layer や Databricks metric view 5. データ品質テストの自動化 dbt の Data Test や Databricks の Anomaly detection その他、データエンジニア視点での変化も挙げておきます。 メダリオンアーキテクチャ を採用。Bronze・Silver・Gold の各レイヤーでの責務境界を明確にした データフォーマットに Delta Lake を採用。Liquid クラスタリングによるクエリパフォーマンスの最適化や、スキーマエボリューションによりスキーマ変更の運用コストが大幅に削減された オーケストレーションに Lakeflow Jobs を採用。Airflow ほどの柔軟性はないがシンプルにまとまっており、Terraform での管理が可能になった 5. データ利用側の移行プロセスと工夫 結論から申し上げますと、開発よりもこちらの移行作業のほうが大変だったと感じています。 今回の移行対象は、利用シーンで大きく 2 つのパターンに分けられました。 他システムからのデータ基盤参照箇所の切り替え ダッシュボード内のデータソースの切り替え 前者はコード管理されているので特定は容易でしたが、後者は範囲が膨大であったため、社内の全部署へのヒアリングが必要となりました。 長期的なスケジュールを組むことが予想されたため、以下のような段取りで進めることにしました。 旧データ基盤の利用状況を全て一覧化する 利用状況から各部署にヒアリングを行い、移行完了に必要な作業工数を見積もる 新旧データ基盤の並行稼働期間を決める (= 旧データ基盤の停止時期を決める) 旧データ基盤の停止期限までに移行してもらう 旧データ基盤の処理を停止し、エラーが発生しないことを確認する 基本的には愚直に進めるしかなかったのですが、少しでも効率化を図るために 4.の工程を AI を用いて短縮化させる工夫をしました。 具体的には「Athena SQL -> Databricks SQL に変換するツール」を作成し、社内ホスティングの web アプリケーションとして公開しました。 実はこのツールは我々データエンジニアではなくアナリストが有志で作ってくれたもので、そのほか様々な協力があって移行をスムーズに進めることができています。 6. 改善効果 新データ基盤への移行はまだ途中段階で、より重要度の高いデータから順に進めています。 5つの重点課題の解決状況 全ての課題が解決済みというわけではありませんが、新データ基盤への移行により、それぞれの課題に対応するための土台・準備が整いました。 課題 状況 1. 非効率なデータ統合 🔧 導入基盤が整備済み 2. ER 図の欠如 🔧 導入基盤が整備済み 3. 不完全なデータリネージ ✅ 解決済み 4. KPI 計算の不一致 🔧 導入基盤が整備済み 5. データ品質テストの不足 🔧 導入基盤が整備済み 課題 1 と 3 については、現時点で改善が進んでいる部分があるため、以下に補足します。 1. 非効率なデータ統合 当初は Fivetran や Airbyte などのデータ統合ツールの活用を計画していましたが、移行期間中に Databricks の Lakeflow Connect が登場し、採用方針をマネージドコネクタへ切り替えました。 Lakeflow Connect 本体の機能活用に向けた基盤が整っています。 3. 不完全なデータリネージ dbt 導入により、テーブル間の依存関係がリネージとして自動的に可視化されるようになりました。 旧データ基盤では、「テーブル C の処理はテーブル A と B のデータが出来上がってからでないと実行できない」といった依存関係を Airflow の ExternalTaskSensor で個別に管理しており、テーブルの増加とともに運用が困難になっていました。 dbt のリネージ機能により、こうした依存関係の管理・把握が大幅に改善されました。 また、Databricks の Unity Catalog のリネージ機能 を活用することで、テーブル・カラム単位でのデータの流れを Databricks の UI 上で視覚的に確認することも可能になりました。 利用者・エンジニアの声 弊社での Databricks の採用は初めてであり、当初は利用者からの戸惑いの問い合わせも多かったですが、徐々にうれしいコメントをもらえるようになってきました。 データ基盤利用者からの声 生成 AI 機能 (Genie) が便利。クエリやダッシュボードを自分で作ってくれる Notebook を用いた調査・検証作業が楽になった。結果の共有もスムーズに行える データの問題調査がしやすくなった。Genie がテーブルの中身を自ら探索・分析してくれるため、原因の特定までの時間が大幅に短縮できる データエンジニアからの声 テーブル追加等の開発時の学習コストが下がった。より多くのエンジニアが開発可能になり、レビューアの負担も軽くなった dbt のリネージ機能が便利。データ異常発生時の影響範囲が明確になり、復旧オペレーションも楽になった ダッシュボードなどの機能が Databricks に集約され、管理の手間が減った 7. まとめ 今回の移行プロジェクトにおいて、筆者は初期の課題設定の工程がキーだったと考えています。 当初は「データ基盤を作り変える」という手段が先行していましたが、一度立ち止まって徹底的に背景を深堀りしていき、 開発者視点だけでなく利用者視点での意見も取り入れ、アンケート結果をスコアリングして優先順位を付けて取り組んでいくことの重要性を体感できました。 スタンバイのプロダクトや組織について詳しく知りたい方は、お気軽にご相談ください。 www.wantedly.com