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

みなさんこんにちは！ワンキャリアでエンジニアをしている佐藤（GitHub： seiya2130 ）です。 今回は、AIによるコーディング支援（Claude Code）をチームで本格的に活用していくにあたり、 AIにプロジェクト固有のルールを教え込む（育てる）プロセスを自動化した取り組み についてご紹介します。

はじめに Google BigQuery は、Google Cloud のサーバーレスなデータウェアハウスです。 大量データの集計や分析を SQL で実行でき、インフラ管理をほとんど意識せずに使えます。 その BigQuery 上で、機械学習を SQL を用いて操作できる機能が BigQuery ML です。 AI関数が増えたことで、SQLだけで予測や異常検知を試せる範囲が広がりました。 2025年以降の主な BigQuery の AI 機能アップデートは以下です（2026-04 時点）。 ※ 一部に Preview の機能を含みます。最新の提供状況は各関数の公式ドキュメントを確認し