LayerX エンジニアブログ

LayerX の エンジニアブログです。

バクラク事業部のデータ基盤 2025: 今年一年の変化を振り返るの巻

Snowflake AI Agent データ基盤 dbt debezium
See More

この記事は、LayerX Tech Advent Calendar 2025 の 23 日目の記事です。

tech.layerx.co.jp

こんにちは。バクラク事業部 BizOps部 データグループの@civitaspoです。今年は子どもたちが入手困難なものをサンタさんにお願いしなかったので、心穏やかな気持ちでサンタさんを家に迎え入れることができそうです。

はじめに

今年も本日を入れて残り9日となりました。本記事では、データ基盤の2025年を締めくくるために、この1年でデータ基盤に起こった変化を振り返ります。 2023年の振り返りは以下の記事でまとめました。 tech.layerx.co.jp 一方で、2024年のまとめはなぜか書き忘れていました…😢

そのため本記事では、2024年後半から2025年にかけて起きたイベントやシステムの変化を軸に、データ基盤がどのような前提のもとで使われるようになってきたかを整理します。

なお、本記事は Snowflake Industry Days 2025 で登壇した以下の資料の内容に多く触れます。すでに Snowflake Industry Days 2025 で私の登壇をご覧になった方にとっては、重複する内容もありますがご容赦ください。

speakerdeck.com

2025年に起きた大きなイベント

まずは、2025年にデータ基盤に起きたイベントについてまとめていきます。

BigQuery → Snowflake 移行は「ほぼ完了」フェーズへ

2024年10月から進めてきた BigQuery から Snowflake への移行は、2025年末時点で「ほぼ完了」と呼べるフェーズに入りました。一部、パフォーマンスチューニングやコスト効率の改善が必要なワークロードは残っていますが、主要なデータ活用は Snowflake 上で行われています1。

BigQuery から Snowflake への移管を進めるにあたってのモチベーションや期待については、以下の記事で詳しくまとめていました。

findy-tools.io

ざっくりまとめると以下のスライド1枚で表現できます。

https://speakerdeck.com/civitaspo/one-year-into-snowflake-how-layerx-uses-data-today?slide=12

2025年は、その期待を胸に実際の移管作業を進めた一年でした。2025年7月にBizOps部へチームごと異動して以降、部署を横断したプロジェクトメンバーとともに移管を加速させました2。そして、移管が進むにつれて Snowflake を前提としたデータ活用が徐々に広がっていきました。

現在のBizOps部 部長である @takumi_zamami はデータ組織・データ基盤に対する強い理解者であり、以下の記事の中でも、データ基盤の移行を行う案件が発生したとき、「ビジネスのバリューチェーンを再構築する絶好の機会」と捉えていると発言しています。

note.com

実際、移管を進める中で、当初想定していた以上に Snowflake の利用方法は拡大し、ビジネスプロセスの最適化余地や事業価値に直接的にデータ基盤を繋げる機会が広がりました。特筆すべき変化は以下のスライドにまとめたように4つに大別されます。

https://speakerdeck.com/civitaspo/one-year-into-snowflake-how-layerx-uses-data-today?slide=14

次の節から上記4点の変化について深掘りして説明しています。

Snowflake を使ったセルフサービス化の定着

バクラク事業のデータ基盤では、エンジニア・ビジネスメンバー問わず、Streamlit in SnowflakeやSnowflakeアラート、Google Sheetsを使って自らデータ施策を実行できるようになっています。驚きだったのは、Coding Agentの発達により、SQLだけではなくPythonといったプログラミング言語を使った施策をビジネスメンバーだけで実施できる状態になったことです。たとえば以下のブログは、人事の方がStreamlit in Snowflakeでアプリケーションを作った事例です。

note.com

利用が加速し、社内で問題解決するミニアプリがSnowflake上に増えてきたため、以下のように、どういう用途で使うものなのかをカタログとして管理している社内ドキュメントも生まれています。

社内のNotionでカタログ管理されているものを抜粋

また、Snowflakeアラートを使って、データ異常検知やSaaSビジネスプロセスにおけるネクストアクション推薦を自動化する仕組みも定着しました。データチームが介在せずとも、各部署でデータ施策を実施できるようになったので、2026年は信頼性の担保や最適化など管理者レベルで、利用者のデータ施策が安全に安定して実施できる仕組みを作る必要があると感じています。

Snowflake Cortex Agents や n8n を利用したビジネスプロセスへのデータ基盤組み込み

次に、ビジネスプロセスへの組み込みに関する変化についてです。先に述べた通り、2025年にかけてデータ基盤が分析用途にとどまらず、日々の業務フローの一部として使われるケースが徐々に増えてきました。

Salesforce、Slack、Googleカレンダーといった業務ツールとデータ基盤の連携が進み、ダッシュボードで状況を確認するだけでなく、次のアクションを促すアラートやレコメンドが業務の中で常時使われるようになっています。各部門が自らダッシュボードやアラートを設定し、業務改善を回す状態が広がってきました。

SaaSのビジネスプロセスにおいては、顧客の状況変化に対してどれだけ早く適切な行動を起こせるかが、事業KPIに直結します。そのため、状態の変化を検知し、判断し、次の行動につなげるまでを、Snowflakeを中心に組み立てる取り組みが増えています。

具体的な事例のひとつが、n8n を用いた商談アサインの自動化です。顧客の業界や事業規模、従業員数といった属性、商談を担当する営業側の得意分野や担当プロダクトといった情報はSalesforceに格納されています。これに加えて、Googleカレンダーの予定情報も含めてSnowflakeに集約し、そのデータをもとに、誰をどの商談にアサインするかをワークフローとして自動化しています。 この仕組みがエンジニアではなく、セールスのサポートメンバーによって構築された点は特徴的で、データ基盤が現場主導で業務を改善するための土台として使われ始めていることが分かります。

note.com

もうひとつの事例が、Snowflake Cortex Agents を用いたお問い合わせ調査のAIエージェントです。お問い合わせが発生した際の顧客の状態や、プロダクトのデータベースの状態、アプリケーションログなどはすべてSnowflakeに格納されています。Cortex Agentがそれらを横断的に参照し、調査結果を整理した上で、対応にあたるエンジニアへ情報を提供する仕組みです。これにより、調査に要する時間を短縮し、より迅速な対応につなげることができるようになる見込みです。3 tech.layerx.co.jp

また、Datadog Logs の検索体験を Snowflake に持ち込む取り組みも、この流れの中にあります。この事例が示しているのは、単なるツール置き換えではなく、エンジニア自身が Snowflake を前提に業務効率化を設計し始めている点です。 ログ探索という日常的で手間のかかる作業を、データ基盤と近い場所で完結させることで、状況把握や判断までの時間を短縮しています。こうした取り組みは、アーリーアダプターとして新しい使い方を試し、手間を減らすために自ら仕組みを作る、いわば Builder としての動きが現場から生まれてきている良い例だと感じています。

tech.layerx.co.jp

これらの事例に共通しているのは、データ基盤が「誰かに依頼して使うもの」ではなく、「自分たちの業務を変えるために使うもの」へと認識が変わってきた点です。ビジネスメンバー・エンジニア、それぞれの立場で Snowflake を前提に業務を再設計する動きが見られるようになりました。データ基盤が業務改善の起点として自然に使われ始めていること自体が、BigQuery から Snowflake への移行を経て生まれた、ひとつの重要な変化だと捉えています。

AI Agent開発基盤としてのデータ基盤

また別の変化として、AI Agent の開発基盤としてデータ基盤が使われるようになってきた点が挙げられます。2025年は、Snowflake を用いて AI Agent の PoC や評価、バックテストといった検証プロセスを回す事例が徐々に増えてきました。

AI Agent を業務やプロダクトに組み込むにあたっては、本番環境に近いデータを使って挙動を検証することが重要になります。一方で、本番データを外部環境へ持ち出すことには、セキュリティや運用上の制約が伴います。Snowflake 上で開発と検証を完結させることで、本番データを外部に出すことなく、比較的自由度の高い PoC や検証を進められるようになりました。

Snowpark Container Services の導入も、この取り組みを支えています。コンテナとして AI Agent をデプロイし、特定のメンバーのみがアクセスできるエンドポイントや、複数人で検証するためのエンドポイントを用途に応じて用意できるようになりました。PoC の段階から、ある程度実運用を意識した形で AI Agent を動かせる点は、開発を進める上で大きな助けになっています。

tech.layerx.co.jp

また、AI Agent の評価においては、バックテストの仕組みが重要な役割を果たしています。プロンプトやモデルを変更した際に、過去のデータを用いてどのような挙動の変化が起きるのかを検証することで、導入前にリスクや効果を確認できます。このバックテストの基盤は、AI を用いた申請レビューの評価などにも活用されており、導入によってどの程度差し戻しを防げるのか、といった観点での検証にもつながっています。

speakerdeck.com

このようなバックテストを可能にしている背景には、CDC（Change Data Capture） によるデータ取得があります。過去の任意の時点におけるプロダクトのデータベース状態を Snowflake 上に再現できることで、特定時点の状態を前提とした検証が可能になっています。CDC を用いたデータ連携の仕組み自体については、後述する「プロダクトデータベースのニアリアルタイム連携」の節で詳しく触れます。

こうした取り組みによって、AI Agent に関する開発や検証を、検討段階で終わらせず、実データに基づいて評価するための環境が整いつつあります。正直なところ、日本国内で、データ基盤を前提にしたAI Agentの開発・検証の取り組みはまだ発展途上だと感じています。その中で、データ基盤を前提に設計し、試行錯誤を重ねてくれる AI Agent 開発者に恵まれていることは、とても心強く感じています。データ基盤を預かる立場としても、そうした期待に応えられるような基盤を提供し続けたいと考えています。

データプロダクトのリリース

この章の最後に、データプロダクトのリリースに関する変化について触れます。これまで Snowflake は、主に社内向けのデータ基盤として利用されてきましたが、2025年はその位置づけが少しずつ広がり、バクラクのプロダクトとしてお客様に提供する取り組みが進み始めました。

背景には、プロダクトをホスティングしている AWS と Snowflake の親和性が高まってきたことがあります。これにより、データ基盤を単なる社内基盤としてではなく、プロダクトの一部として設計・運用する選択肢が現実的になってきました。社内利用を前提とした延長ではなく、最初からプロダクトとしてデータ基盤を提供する、という発想に切り替わった点が特徴です。

バクラクは、企業経営において重要なデータをお預かりするプロダクトです。そのため、データを蓄積するだけでなく、分析や可視化を通じて付加価値を提供し、意思決定や改善アクションにつなげることが求められます。現在開発しているデータプロダクトでは、コスト分析などの観点からデータを整理・可視化し、経営視点での改善を支援することを目指しています。

この取り組みは、現在一部のお客様にのみ提供している段階ですが、順次内容を拡充していく予定です。正式なプロダクト名称は「バクラクインテリジェンス」で、前任のデータ基盤マネージャーである @shun_tak が開発をリードしています。

note.com bakuraku.jp

社内向けのデータ活用をそのまま外に出すのではなく、顧客に提供するプロダクトとして改めて設計し直す必要がありました。安定性や再現性、説明可能性といった要件がこれまで以上に重要になり、データ基盤の責務も、「社内の意思決定を支える」から「顧客価値を継続的に提供する」ものへと広がっています。

このように、データ基盤が事業の内側を支える存在から、プロダクトとして外に価値を届ける役割を担い始めたことは、2025年に起きた大きなイベントのひとつだと捉えています。

2025年に起きたシステム的な変化

ここまでが、バクラクのデータ基盤を取り巻く周辺環境や、利用のされ方に関する変化でした。ここからは、それらの変化を支えるために、データ基盤そのものに加えたシステム的な変更について整理します。

プロダクトデータベースのニアリアルタイム連携

まず、プロダクトデータベースのニアリアルタイム連携についてです。2025年にかけて、データ基盤に求められる要件が「定期的に集計できること」から、「できるだけ現在に近い状態を扱えること」へと徐々に変化してきました。

業務プロセスへのデータ基盤の組み込みや、AI Agent の検証・評価を進める中で、過去の集計結果だけでなく、「その時点でのプロダクトの状態」を前提にした分析や検証が必要になる場面が増えてきました。特に、問い合わせ対応や AI を用いたレビュー、バックテストといったユースケースでは、データの鮮度や時点の再現性が重要になります。

こうした要件に対応するため、プロダクトデータベースから Snowflake へ、CDC（Change Data Capture）を用いたデータ連携を行い、ニアリアルタイムに近い形でデータを取り込む仕組みを整備しました。

具体的には、データベースの変更イベントを Debezium で取得し、Managed Streaming for Apache Kafka（MSK）を経由して、Snowflake Kafka Connector（Snowpipe Streaming v2）で Snowflake に書き込む構成を採用しています。この構成により、データベースへの書き込みから数分以内に Snowflake 側へ反映される状態を実現しています。

この仕組みによって、単に最新状態を参照できるようになっただけでなく、過去の任意の時点におけるデータベースの状態を Snowflake 上に再現できるようになりました。その結果、「当時この AI Agent を動かしていたらどうなっていたか」といった検証や、問い合わせ発生時点の状況を前提とした調査が可能になっています。前章で触れた AI Agent のバックテストや、お問い合わせ調査の自動化は、こうしたデータ連携を前提として成立しています。

CDC を用いたデータ連携の全体像は、以下の図のような構成になっています。

https://speakerdeck.com/civitaspo/one-year-into-snowflake-how-layerx-uses-data-today?slide=23

なお、CDC パイプラインの詳細なアーキテクチャや、Snowflake 上で任意時点のスナップショットを扱う仕組みについては、以下の記事で詳しく解説しています。

tech.layerx.co.jp

このニアリアルタイム連携は、データ基盤を業務や AI の中に深く組み込んでいく上では、前提条件を大きく書き換えるものでした。

Glue × S3 Tables を利用した Iceberg Table 活用

次に、Glue と S3 Tables を利用した Iceberg Table の活用についてです。この取り組みは、機械学習のワークロードにおけるデータ取り扱いの課題をきっかけに検討を始めました。

背景にあったのは、機械学習の推論結果がS3上に細かい単位で大量にオブジェクト生成されるワークロードです。これらのデータを Snowflake に直接取り込む場合、Snowpipe を用いた取り込みではコストパフォーマンスが非常に悪くなるという課題がありました。一方で、推論結果そのものは Snowflake から参照できる状態にしておきたい、という要件もありました。そのため、Snowflake からの参照性を保ちつつ、よりコストパフォーマンスの良い手段でテーブルを構築する必要がありました。

そこで、AWS 側で Iceberg Table を構築し、それを Snowflake から参照する構成を採用しました。Iceberg Table を構築するストレージとしては S3 Tables を利用し、Glue を中心とした構成でデータを管理しています。この構成により、Snowflake に直接ロードすることなく、コスト効率の良い形で Snowflake から推論結果を参照できるようになりました。

また、副次的な目的として、Snowflake だけに閉じない構成を一部に取り入れることで、データ組織としてデータエンジニアリング上の選択肢を増やす、という狙いもありました。Iceberg Table という技術に実際に触れ、運用まで含めて経験することで、理論上の比較だけでは分からない特性を把握したいと考えていました。

実際に運用してみると、「コストパフォーマンスの良い手法で Snowflake からデータを参照する」という当初の目的自体は達成できました。一方で、開発生産性の観点では dbt を中心とした既存のワークフローに寄せたほうが良いケースが多いことや、Iceberg Table 特有の運用難易度の高さが見えてきました。加えて、2025年12月に Snowpipe の料金改定が行われたこともあり、当初想定していたほどのコスト優位性が得られなくなった面もあります。

docs.snowflake.com

こうした点を踏まえ、現時点では、現在バクラクのデータ基盤で見えているワークロードにおいて、AWS Glue を用いた Iceberg Table の構成を積極的に採用していく判断はしていません。一方で、相互運用性が強く求められるケースなど、前提条件が異なれば有効な選択肢になり得る技術である、と考えています。

Iceberg Table の運用特性や難しさを実体験として把握できたことにより、今後のデータ基盤設計において取れる手段が確実に増えたと感じています。どのような条件で使うべきか、どこに注意が必要かを具体的に理解した上で選択できるようになったこと自体が、この取り組みの大きな価値でした。

動画の書き起こしやサポートチケットのコメントなど非構造化データの拡充

3つ目に、非構造化データの拡充についてです。2025年は、AI Agent が飛躍的に進化した年だったと感じています。それに伴い、AI Agent が扱うデータの前提も大きく変わりつつあります。

これまでのデータ基盤では、数値やカテゴリといった構造化データを中心に扱い、分析や意思決定に活用してきました。一方で、AI Agent を業務やプロダクトに組み込んでいく中では、人が普段扱っている情報、つまりテキストや音声といった非構造化データを含めて扱えることが重要になってきています。そこで、分析用途でよく使われるデータだけでなく、AI Agent が扱うことを前提としたデータもデータ基盤に集約し始めました。

具体的には、商談動画の書き起こしデータや、サポートチケットにおけるコメントといった情報がその一例です。これらは従来、データ基盤の外に置かれることが多かったデータですが、業務の文脈を理解する上では重要な情報でもあります。こうした非構造化データを Snowflake に集約することで、構造化データと組み合わせた分析や、AI Agent による処理を前提とした活用が可能になります。

現時点では、これらの取り組みが直接的な成果に結びついているわけではありません。ただし、Snowflake 上で非構造化データを扱えるようになることで、AISQL を用いた分析や、ビジネスメンバー自身による高度な分析、さらには業務フローへの組み込みといった活用につながる可能性があると考えています。まずはデータを集め、使える状態にしておくことが、次の一手を打つための前提になると捉えています。

Snowpark Container Services の運用開始

4つ目に、Snowpark Container Service（SPCS）の運用開始についてです。先ほど AI Agent の開発基盤として触れたとおり、Snowflake 上でコードを実行する環境を整備するために、SPCS を本格的に使い始めました。

tech.layerx.co.jp

Snowpark Container Service を利用することで、AI Agent の PoC や検証、バックテスト用の処理をコンテナとしてデプロイし、用途に応じてエンドポイントを分けて運用できるようになっています。これにより、Snowflake 上でデータと処理を近い場所に置いたまま、複数人で検証や改善を進めやすくなりました。

また、Streamlit in Snowflake の利用が社内で広がるにつれて、実行コストが課題になってきたこともあり、SPCS 上で Streamlit アプリケーションを動かす運用も始めています。Snowpark Container Runtime を利用することで、従来の Streamlit in Snowflake に比べて、コスト効率を意識した運用が可能になりつつあります。

docs.snowflake.com

データ基盤上にコンテナをデプロイできる基盤を持ったことで、本番データを外部に出すことなく、セキュアな形でデータアプリケーションの構築や AI Agent の PoC を行えるようになりました。Snowflake を中心としたデータ基盤の上で、開発・検証・評価までを完結できる手段が増えたことが、この一年での大きな変化です。

select.dev の導入

最後に、select.dev の導入についてです。Snowflake を幅広い用途で使うようになってきた結果、単純に Warehouse 単位や月次の合計だけでは見えないコスト構造が課題になっていました。たとえば、同じ Warehouse の中でも、どのクエリや dbt モデルが大きくコストを使っているのかは従来の指標からは分かりづらく、勘や経験に頼る部分もありました。こうした状況を解消するために、コストコントロールを主な目的として select.dev を導入しました。

select.dev

select.dev を使うと、クエリ単位・dbt モデル単位・チーム単位といった、より細かい粒度でコスト構造を把握できるようになります。どの処理がどれだけ Snowflake クレジットを消費しているのかが一覧として見えるようになり、曖昧だったコストの使われ方が具体的な数値として捉えられるようになりました。

こうした細かい可視化ができるようになったことで、データ基盤を実際に使っているメンバーと同じ数値・同じ可視化を見ながら会話できるようになったことが、導入の大きな価値だと感じています。

これにより、「どこがボトルネックなのか」「どのモデルや処理にコストがかかっているのか」という議論を、定性的な推測ではなく数値に基づいた形で進められるようになりました。

また、select.dev では Usage Group を使ったコスト按分や、アラート機能なども提供されており、チームや用途ごとのコスト管理や予算の割り振りまで見通しやすくなっています。これにより、将来的にはコスト管理の責務をデータ基盤チームだけでなく、利用側のチームにも委譲しやすくなる体制が整いつつあると考えています。

tech.layerx.co.jp

おわりに

ここまで、2024年後半から2025年にかけて、バクラク事業のデータ基盤を取り巻く変化を振り返ってきました。

この一年で、データ基盤は用途・責務・扱うデータの幅という点で大きく成長したと感じています。一方で、これらの変化の多くは、各チームや個人がそれぞれの課題に向き合いながら実装してきた結果でもあります。セルフサービス化や業務プロセスへの組み込み、AI Agent 開発基盤としての活用といった取り組みは、いずれも個別には非常に良い形で機能していますが、組織全体で高効率に使い続けるためには、個別最適の積み重ねを全体最適へと昇華させていく進化が必要なフェーズに入ったと考えています。

また、こうしたデータ基盤の進化は、バクラク事業に閉じたものではありません。今後は、全社のデータ基盤として Snowflake を採用し、スコープを拡大していく方針となっています。バクラクで得られた知見や経験を土台に、LayerX 全体としてのデータ活用を支える基盤へと広げていく予定です。

2026年以降は、これまで個別に積み上げてきた取り組みを、組織として全体最適になるよう整理し直しながら、継続的に事業成長に寄与するデータ基盤へと進化させていきたいと考えています。

絶賛採用中🔥

LayerXでは、Snowflakeを活用したデータ基盤の構築と、その上でのAI/MLシステムの開発を進めています。Production-ReadyなAI開発をサポートするためのデータ基盤開発、時系列データ処理、リアルタイムデータパイプラインの構築などに興味がある方、そして、データ基盤を事業成長に繋がる成長ドライバーだと信じて止まない方は、ぜひ一緒にチャレンジしましょう!

open.talentio.com open.talentio.com open.talentio.com

  1. Google Analytics ã‚„ Google Ads、および KARTE DataHub との連携など Google BigQuery のエコシステムに強く依存するサービスのデータ移管も 2025-12-23時点では残っていますが、今年の残り営業日で完了させる気持ちでいます。↩
  2. 移管にあたって協力してくれたプロジェクトメンバーには感謝しても感謝しきれません。ありがとうございました。↩
  3. PoC を終了して本格的に実装している最中↩