で、結局 Snowflake や Databricks でアプリ用のデータって作っていいの？

はじめに

「Snowflake や Databricks でアプリが使うデータを作るって、アリなんだっけ？」── 設計レビューでこれを言われたとき、自分は一瞬うまく答えられませんでした。分析のための基盤なのに、アプリ用のデータを作る。なんか変じゃないか、と。

結論から言うと、その違和感は正しいです。そして違和感が指している場所こそが「やってはいけない一線」で、そこを言語化すると設計の迷いがきれいに消えます。この記事はその一線を、できるだけ素朴な言葉で引き直す試みです。
※なるべく一般化して書きましたが、もしかしたら私の意見も入っている部分があるかもしれません。

対象読者：Webアプリも触るし、データ基盤も触る。両方をまたいで設計する立場のエンジニア。「分析基盤をアプリのデータソースにしていいのか？」でモヤッとしたことがある人。

違和感の正体は「計算する」と「配信する」の混同

まず、データには役割が2つあります。ここを混ぜると話がこんがらがります。

ひとつは 計算・加工する 役割。全履歴を舐めてレコメンドを作る、何億行を集計してランキングを出す、といった「重い処理で成果物を生み出す」仕事です。

もうひとつは 配信する 役割。アプリがリクエストのたびに「このユーザーへのおすすめは？」と引きにくる、その問い合わせに即答する仕事です。

Snowflake や Databricks が得意なのは前者だけ、というのがこの記事の出発点になります。

Snowflake / Databricks は「工場」であって「店頭」ではない

たとえるなら、Snowflake や Databricks は工場です。原料（全履歴）を持ち込んで、重い機械でガッと加工して、製品（レコメンドや集計結果）を作る場所。これはめちゃくちゃ得意です。

一方で工場は「店頭」ではありません。お客さん（アプリ）が一人ずつレジに来て「これください」と言うのを毎回さばく場所ではない。役割を表で並べるとこうなります。

役割	Snowflake / Databricks	やってよいか
計算・加工する（全履歴を舐めてレコメンドを生成）	◎ 得意	OK
アプリのリクエスト毎に直接引かれる配信	✕ 不向き	NG（これが違和感の正体）

「分析基盤なのにアプリ用？」というモヤモヤは、工場に店頭の仕事をさせようとしている匂いを嗅ぎ取っているわけです。鼻はかなり正確です。

アプリが毎リクエストSnowflakeにSELECTを投げると何が壊れるか

ではなぜ「店頭」に向かないのか。アプリが毎リクエストで Snowflake に SELECT を投げる構成を、具体的に分解してみます。壊れる理由は3つあります。

ひとつ目はレイテンシです。OLAPエンジンは大量データのスキャンに最適化されていて、1クエリが秒単位になることも珍しくありません。ユーザーがボタンを押すたびに数秒待たされるアプリは、それだけで終わります。

ふたつ目は同時実行数の限界です。工場のラインは「一度に大量の原料を流す」前提で設計されていて、「小さな注文が同時に何千件も飛んでくる」状況には向きません。秒間リクエストが増えた瞬間に詰まります。

みっつ目はコストです。クエリ単位・コンピュート稼働時間で課金される世界では、毎リクエストでスキャンを走らせると請求が青天井になります。配信用途の「軽い問い合わせを大量に」とは、課金モデルからしてかみ合っていません。

つまり、レイテンシも・同時実行も・課金体系も、全部が配信に向いていない。あなたの違和感は、この3つを直感的に束ねて「変だ」と言っているんです。

正しい形：工場で作って、配信ストアに置く

じゃあアプリは何を引くのか。工場で作った成果物を、別の「配信ストア」に置いておいて、アプリはそこだけを読みます。

配信ストアに使うのは、Postgres・Redis・DynamoDB・小さめの Mongo といった「軽い問い合わせを大量にさばける」データベースです。工場（Snowflake / Databricks）が重い計算で小さな成果物を作り、それを配信ストアにプッシュして書き出す。アプリは配信ストアだけを低レイテンシで読む。図の右側、点線で示した「アプリ → 工場へ毎リクエスト直引き」がアンチパターンで、ここを絶対に通さないのがポイントです。

これは"裏技"ではなく定番パターン ── Reverse ETL と Feature Store

「分析基盤でアプリ用データを作って、運用側に戻す」という流れには、ちゃんと名前がついています。

ひとつは Reverse ETL です。これは、データウェアハウスで作った結果を、業務システムやアプリ側に書き戻すこと¹。通常のETL（業務システム → DWH）とは逆向きにデータを流すので Reverse、という素直なネーミングです。

もうひとつ、機械学習の文脈では Feature Store と呼ばれます。特徴量をバッチで計算しておいて、オンラインストアから低レイテンシで配信する仕組みです。「重い計算はバッチで・配信は別レイヤーで」という発想は、ML界隈ではむしろ標準装備になっています。

どちらも「工場で作って配信ストアに渡す」を、別の角度から名付けただけ。あなたが手探りでたどり着いた構成は、すでに踏み固められた道だったというわけです。

ベンダー自身が「OLAPをそのまま店頭にするな」と答えを出している

おもしろいのは、Snowflake も Databricks も「ウェアハウス単体は配信に向かない」と分かっていて、配信レイヤーを別途用意していることです。これが存在すること自体が、業界の答えだと思っています。

Snowflake には Hybrid Tables（Unistore）があります。トランザクション的なポイント操作を二桁ミリ秒でさばけるテーブルで、AWSでは2024年10月、Azureでは2025年10月にGAになりました（執筆時点でGCPは未提供）²。

Databricks 側は Feature Serving がGA済みで、特徴量や関数の結果を低レイテンシで配信するエンドポイントを提供しています³。

ここは情報の鮮度に注意してください。Databricks の配信レイヤーは動きが速く、かつて「Online Tables」と呼ばれていた仕組みは現在 legacy 扱いになり、後継の Online Feature Stores（Lakebase ベース）へ移行しています⁴。2026年には Lakebase Autoscaling や、Delta/Iceberg に直接ミリ秒で引ける Lakehouse//RT のような技術も出てきていて、「専用の配信ティアを別に持つ」という前提自体を畳みにきています⁵。

注目したいのは、これらが「OLAPエンジンをそのまま店頭にするのはまずい」という共通認識の上に作られている点です。むしろ各社が境界を埋めにきているという事実が、「工場と店頭は本来別物だ」という前提を裏側から証明しています。境界がなくなる日が来るとしても、それまでは役割を分けて設計するのが安全です。

判断の物差し（レッドライン）

「じゃあ何でもSnowflakeで作って配信ストアに置けばいいのか」というと、そうではありません。ここに2本目のレッドラインがあります。データの性質で置き場が自然に決まります。

データ	性質	置き場
レコメンド・集計（read中心・多少古くても許容・派生物）	工場で作って配信箱に置く	Snowflakeで計算 → 配信ストア。OK
ポイント残高・入出金（write・整合性・お金）	そもそも計算物ではない	PostgreSQLで直接トランザクション。Snowflakeは関与させない

レコメンドは「多少古くてもいい・読み中心・全履歴から導く派生物」なので工場生産に向きます。一方でポイント残高は「1円もズレてはいけない・書き込み・即時反映」が要る。これは派生物ですらない、台帳そのものです。工場に持ち込んではいけません。

この性質の違いさえ握っておけば、「何でもSnowflakeで作る」という極端には倒れません。

実例で考える ── ECサイトに当てはめると

具体に落とすと分かりやすいので、あるECサイトの設計を一般化して考えてみます。「おすすめ商品」と「集計結果」を毎回リアルタイムに計算していて、全履歴スキャンを高価なドキュメントDB上でやってしまっていた、というよくある状況を想定します。

この場合、おすすめや集計の生成を Snowflake / Databricks に移すこと自体は正しい判断です。むしろ全履歴スキャンのような重い処理は、本来こちらの仕事。高価な配信用DBで力技をやるのをやめて、工場に移すのが狙いになります。

ただし、アプリに Snowflake を直接引かせてはいけません。生成した結果は今まで通り軽量な配信ストア（小さい Mongo でも Postgres でも Redis でもいい）に置いて、アプリはそこだけ読む。そしてポイント残高のようなお金のデータは、最初から最後まで PostgreSQL のトランザクションで扱い、Snowflake には一切触らせない。

「重い派生物は工場へ、お金の台帳はRDBへ、配信は軽量ストアから」── この3点を守るだけで、設計の8割は片付きます。

ハマりどころ ── 鮮度とパイプラインの責任分界点

実際にやると、ここでひとつ詰まります。配信ストアの中身は「工場が最後にプッシュした時点」のものなので、必ず少し古い。レコメンドなら数時間〜1日古くても許容できますが、「在庫数」みたいに鮮度がシビアなものを安易に工場経由にすると、表示と実態がズレて事故ります。自分も「これくらいバッチでいいだろう」と判断を一度ミスって、肝を冷やしたことがあります。配信ストアに置くデータは「どれくらい古くて許されるか」を必ず先に決めておくのが安全です。

もうひとつは、工場から配信ストアへ書き出すパイプラインが新しい責任分界点になることです。ここが落ちると配信ストアの中身が腐っていく。監視とリトライ、そして「最後にいつ更新されたか」を持っておくと、後で自分が助かります。

まとめ ── Snowflakeは「作る人」、配信ストアは「渡す人」

最初の違和感に戻ります。「分析基盤をアプリの直接のデータソースにするのは変だ」という直感は、ガードレールとして100点でした。

正しい設計は、その直感を否定することではなく、役割を分けることです。Snowflake / Databricks は重い計算で成果物を作る人。配信ストアはそれをアプリに渡す人。アプリは「渡す人」からだけ受け取る。そしてお金の台帳は、そもそも工場に持ち込まない。

この線引きさえ握っておけば、「分析基盤でアプリ用データを作るの？」という問いに、もう詰まらずに答えられるはずです。みなさんの現場では、この境界、どこで引いていますか？ もし「うちはこう分けてる」という流儀があれば、ぜひ教えてください。

1. Reverse ETL の定義については以下が分かりやすい。 https://hightouch.com/blog/reverse-etl ↩

2. Snowflake Hybrid Tables（Unistore）GAの公式アナウンス。 https://www.snowflake.com/en/blog/unistore-general-availability/ / Azureリージョン対応（2025年10月）: https://docs.snowflake.com/en/release-notes/2025/other/2025-10-06-hybrid-tables-azure-ga ↩

3. Databricks Feature Serving GAの公式ブログ。 https://www.databricks.com/blog/announcing-general-availability-databricks-feature-serving ↩

4. Databricks Online Feature Stores のドキュメント。 https://docs.databricks.com/aws/en/machine-learning/feature-store/online-feature-store ↩

5. Lakehouse//RT に関する解説記事。 https://venturebeat.com/data/databricks-says-it-solved-the-decades-old-data-pipeline-problem-thats-been-slowing-ai-agents ↩