SnowflakeからBigQueryへ。アソビューがDWHを統合した意思決定の背景と展望

アソビュー Advent Calendar 2025の24日目(裏面)です。

はじめに

2025年11月、Google Cloud 主催『Data & AI Summit '25 Fall』に登壇させていただきました。本記事では、登壇資料をベースに、口頭で話した内容や話しきれなかった内容を補足しながら、アソビューがデータ基盤のアーキテクチャを再設計するに至った意思決定の裏側を共有します。

cloudonair.withgoogle.com

speakerdeck.com

前提として、データ基盤とそのアーキテクチャに関してはスクラップアンドビルドが重要だと考えています。その時々で重視するものや大事なものが変わっていく中で、非常にコストがかかり長期的な運用が必要になるデータ基盤は、最初から完璧を目指すことは難しくコストも高いです。

モダンデータスタックに代表されるように、データ基盤ではパズルのようにアーキテクチャを選択していくことが可能です。その時々の最善の選択やアップデートが重要であり、課題や負債を受け入れる一見不合理に見える選択も中長期で考えれば十分に価値を見出だせます。

今回はアソビューがフェーズの変化に伴って、どうアーキテクチャを選択してきたのか。その技術的決断のプロセスを解説します。

アソビューのデータ活用の現在地と課題

2022年から構築してきたデータ基盤の変遷

アソビューでは2022年からデータ基盤の構築を開始しました。最初期は下記の構成でした。

初期構成図

whatweuse.dev

構築のポイントとして重視していたのは「構築スピード」です。TROCCOは日本企業向けの豊富なコネクターと日本語サポートがあり、ETLサービスとして素早くデータ投入を実現できました。また、GA4のデータが既にBigQueryに存在していたため、そのまま採用できた点もスピード重視の判断でした。

初期構築時点では構築スピードを重視した構成を取っていたものの、運用をしていく中でBigQueryのコスト・パフォーマンスに課題が生じて、SnowflakeのPoCを行っていました。

構成図2

当然ですが、2つのDWHを運用していくのは難しく、どちらかのDWH製品にデータを寄せていく必要が出てきました。

アーキテクチャの意思決定の指針: データ基盤のROI

アソビューがこれまでの意思決定、そしてこれからの意思決定に一番重要だと考えている要素はROIです。データ基盤は非常にコストがかかります。これはデータ量が多いから仕方ないという側面もありますが、構造的な課題があります。

データ基盤は「移動・保存・可視化」すべてにお金がかかる

データ基盤の価値の一つは、様々なデータを一緒に分析できることです。例えば、ECサイトであれば購買データと顧客の行動データを組み合わせることで、いわゆるN1分析が行えたり、施策の効果を確認できたりします。

しかし、データを一緒に見るためには、データを移動させる必要があります。この移動にもお金がかかります。データが多くなればなるほど、このコストも増えていきます。

さらに、データを貯めているだけでは意味がありません。見られて初めて価値が出ます。クエリを投げること自体にもお金がかかりますし、それを見るためのBIにもお金がかかります。データ基盤は作って終わりではなく、長期的に運用していく必要があります。運用が続けばデータが増え、よりお金もかかっていきます。

事業価値(アクション)が出るまでのリードタイムが長く、コスト対効果が見えづらい

データから価値を出すには、多くのステップが必要です。企業がお金を生む行動(広告を打つ、マーケティング、営業、アプリケーション開発など)を生むための要素を、データ基盤から作ることにはリードタイムがかかります。

まずデータ基盤を構築して、そのデータを見るためのダッシュボードを作って、そこからインサイトを得て、やっとアクションにつながります。そのアクションが生まれて初めて価値につながるのです。

データ活用は価値を生む反面、こうしたROIを意識できていないと、ただただお金を垂れ流すだけになってしまいます。

目指す姿:「早く・安く・うまい」基盤への転換

だからこそ、事業価値のあるデータを、可能な限り低コストかつ高速に提供する「早く・安く・うまい」基盤がアソビューのデータ基盤のアーキテクチャ選定において重要な指針でした。

  • 早く: データ基盤の構築をできるだけ早くすることで、リードタイムを短縮する
  • 安く: 費用を削減することでROIを上げる
  • うまい: 事業価値のあるデータ、お金を生む行動に近いデータを優先的に扱う(ECサイトであれば購買データからまずやっていくのが良いなど)

この思想から、初期段階では構築スピードを重視してアーキテクチャを選定してきました。できるだけ早くデータを見られる状態で提供することで、事業価値を最大化することを意識してきました。

そして、これからの時代はここに加えてAIの活用が肝になってきます。データ基盤のROIを最大化するためには、価値を生むアクションの数を増やす必要がありますが、データ分析は非常に難しいものです。ダッシュボードを作る行為、そこからインサイトを得る行為、これらは専門的な知識を求められ、ボトルネックになりやすい。生成AIがSQL生成やインサイト抽出をサポートすることで、非エンジニアでも直接データからアクションを生み出せるようになり、アクションの最大化を目指せます。

つまり「コストの最適化」とそこから生み出される「アクションの最大化」が次の意思決定において重要なポイントになると考えました。

なぜ Snowflake ではなく BigQuery だったのか

コスト最適化の観点は先のブログに譲りますが、多くの検証とこれまでの実績を通じて、すべてのユースケースに通じる訳ではありませんが、どちらも十分に最適化できる結果となりました。

tech.asoview.co.jp

tech.asoview.co.jp

そこで重要になってくるポイントがAIの活用によるアクションの最大化です。そのための要素がLookerの導入とGoogle Cloudのエコシステム全体の親和性でした。

AI Readyな基盤にするために

Lookerを選んだ理由は、単にグラフを描画するツールとしてではなく、「セマンティックレイヤー(意味定義層)」としてのLookerを評価したからです。

Lookerを構成するLookMLは、ビジネス指標やロジックをSQLの中に埋もれさせず、Git管理可能なコードとして定義できます。これによりビジネスロジックがコードとして管理され、属人化を防げます。 〇〇のデータはどこにあるのか、それはどのカラムをどう使えば見られるのか。こうしたノウハウはデータ基盤を使うプロセスの中では属人化し暗黙知で動いている場合があり、新規参入障壁が高いです。こうした問題のソリューションとしてカラムの意味を日本語で定義してあげることで、誰でも分かる状態を作れます。

この誰でも分かる状態を作ることはAIにとっても利用しやすい基盤であることを意味します。このセマンティックレイヤーを構築するという部分もAIの発展によりかなり効率化されていることで導入障壁が下がっていることも決め手のひとつになりました。

また、データ(BigQuery)とAI(Vertex AI/Gemini)が物理的に近い場所にあり、シームレスに連携できることが、AI活用のハードルを劇的に下げます。 セマンティックレイヤーを定義し、AIが利用しやすい状態を作ることができ、物理的に近い場所にデータとAIがあることで転送料金も抑えられ、提供される機能の恩恵を受けやすい。そんな環境がGoogle Cloud全体で作ることができ、一気にAI Readyなデータ基盤を作っていけることが、今回の選定において重要なポイントとなりました。

構成図3

利用用途による差別化:TableauとLookerの共存

Lookerを導入することでTableauをどうするのか、現時点ではTableauとLookerを利用用途で差別化していく方針です。データ探索の文脈ではTableauを使い、モニタリングやレポーティングはLookerを使っていく想定です。

Tableauは自由度が高く、アドホックな分析やデータ探索に適しています。一方、Lookerは「セマンティックレイヤー」としての機能を重視し、モニタリングやレポーティングに最適化させていきます。セマンティックレイヤーを通したクエリは予測が立てやすく改善しやすいことでBIからのクエリの不確実性が減るため、Lookerを通すことでクエリの料金を抑えられることも魅力です。

データ活用にAIを使っていくことで目指す先

これまでは専門知識を持つ人がダッシュボードを作る「人海戦術」でしたが、それでもリソースが追いつかずボトルネックになっていました。

アソビューでは、TableauのコミュニティであるDATA Saberを通じてプロダクトのエンジニアやCPO、アクションを起こすマーケター自身が自分で分析を行える環境になっています。またデータ基盤チームのエンジニアもこれに参加することで、データを作る人と使う人が同じ視点を持って議論ができるようになり、価値のあるデータを作ってきました。

しかし、それでも人数は限られています。最近は増えて20人近くいますが、それでもこの人たちがボトルネックになってしまい、全社に広げることはまだまだ難しい状況でした。

生成AIがSQL生成やインサイト抽出をサポートすることで、データ分析の専門的な知識がないメンバーでも直接データからアクションを生み出すためのインサイトを得やすい環境が手に入れられ、よりデータ分析の輪が広がっていくと考えています。

エンジニアの役割の変化

エンジニアの仕事は「依頼されてデータやダッシュボードを作る(1の価値)」ことから、「AIが自走できる環境(LookMLやパイプライン)を整備する(10〜100の価値)」へシフトします。

これにより、エンジニアがより本質的でレバレッジの効く事業貢献ができる体制になります。エンジニアがカラム1個追加した、dbtのモデルをちょっと改善した今までの仕事が、今までボトルネックになっていた人を経由して生んでいた価値が1だったとすると、AI活用によってそのアクションの数が10にも100にもなり得るのです。

社外への価値提供

これまで社内の話に焦点を当ててきましたが、AIを活用することでのアクションの最大化はアソビューのプラットフォームを通じて、遊び・体験を提供されている事業者様にも拡大したいと画策しています。

IT企業であるアソビューでもデータ分析は難しくデータ活用には課題がある中で、DXを積極的に推進している中である事業者様にとっても同様の課題があると考えています。 そこにしっかりとアソビューのデータでLookerと生成AIを活用して価値をお届けすることで、社内だけでなく事業者様へも直接インサイトを提供できるようになるのではないかと期待しています。

このデータ基盤の価値が本当に10にも100にもなっていくのではないかという未来を、私たちは考えています。

おわりに

アソビュー!が持つデータを武器に、業界全体の「アクション」を増やし、ミッションである「生きるに、遊びを。」を加速させていきます。そんなデータ基盤を作り、一緒に事業価値を最大化したいエンジニアを募集中です。

www.asoview.co.jp