なぜ Shopify を BigQuery に入れたくなるのか（Shopify to BigQuery）
Shopify の管理画面には、レポート機能がついています。注文・売上・セッションなど、ある程度の数字は標準で見られます。 ただ、運用を続けると必ずぶつかる壁があります。
- 「先月の 新規顧客の LTVを、獲得チャネル別に出したい」
- 「Klaviyo のメールと Shopify の購入履歴を横串で分析したい」
- 「GA4 の流入データを、注文単位で結合して見たい」
- 「広告費（Meta / Google / TikTok）と売上を、日別 MER で並べたい」
- 「2 年前のコホート LTVを見たいが、Shopify ではデータ保持が短すぎる」
Shopify 標準のレポートは「Shopify 内のデータだけ」で完結します。 複数のソースを横串で結合したい瞬間に、別の場所にデータを集めて分析する必要が出てきます。 その「別の場所」として最も普及しているのが BigQuery（Google Cloud のデータの倉庫）です。
入れると、何ができるようになるか
- 横串の分析：Shopify × Klaviyo × GA4 × 広告チャネル を結合して、コホート LTV や MER を計算
- 長期保存：BigQuery に入れれば、5 年でも 10 年でも保管。コホート LTV の長期分析が可能
- SQL での自由分析：標準レポートでは表現できない切り口を、自分で書ける
- AI 分析エージェントの接続：BigQuery に乗っていれば、Slack 常駐 AI に業務質問を投げて答えさせられる
- BI ツールとの連携：Looker Studio、Tableau、Power BI などから直接ダッシュボード化できる
これが、EC/D2C のデータ分析で「Shopify to BigQuery」のデータパイプラインが標準パターンとして定着している理由です。
選択肢は 3 系統 — SaaS で買う / Shopify 公式機能 / 自作
① SaaS で買う（最もよくあるパターン）
Fivetran、Airbyte、Hevo、Stitch などのデータ取込 SaaS を使うやり方。 Shopify と BigQuery の両方を選択して接続情報を入れるだけで、定期的にデータが流れます。
- メリット：エンジニアの工数がほぼゼロで動く。コネクタが対応している API 変更にもベンダー側で追従
- デメリット：処理量に応じて月額が伸びる。料金モデル次第で、年商連動で爆発することも
② Shopify 公式機能（BigQuery 連携アドオン）
Shopify Plus（上位プラン、月額約 2,000 ドル〜）には、 BigQuery への直接連携機能（Shopify Data Pro）があります。 すでに Shopify Plus を使っている会社なら、追加コスト少なく導入可能。
- メリット：Shopify が公式で出しているので、API 変更追従の心配がない
- デメリット：機能の柔軟性は SaaS 系より制約あり。Plus プランそのものが必要
③ 自作（GraphQL Admin API + Webhook）
Shopify の API を直接呼び出して、自分で BigQuery に書き込むパイプラインを組むやり方。 最も柔軟で、月額コストはほぼゼロにできますが、開発と運用の責任を全部自分で持つ必要があります。
- メリット：完全に自由、月額コストが BigQuery のクエリ実行と保管のみ（数千〜数万円）
- デメリット：開発と運用工数が高い。専任エンジニアが必要
SaaS で買う場合の選び方（Fivetran / Airbyte / Hevo / Stitch）
SaaS 系の選び方は、シンプルに次の 3 軸で決まります。
軸 1：料金モデル（最重要）
Fivetran：MAR（Monthly Active Rows）課金
月にデータを動かしたユニーク行数 × 単価。 EC が売れて顧客数が増えるほど、線形に費用が伸びる。 年商 1 億 → 5 億に成長すると、月額が 5 倍になる可能性あり。D2C 成長フェーズには注意。
Hevo：処理レコード数課金
扱うレコード数で課金。レコード量が予測できれば計算しやすい。 顧客が増えても、購入頻度が変わらなければ料金は変わりにくい。
Stitch：行数課金（簡素）
シンプルでレガシー価格帯。中小規模で安定運用したい場合の選択。 機能は基本的なものに絞られる。
Airbyte Self-hosted：固定費（インフラ代のみ）
OSS なのでライセンスはゼロ。サーバー代のみ（月数千円〜数万円）。 運用工数は自分持ち。
軸 2：必要なコネクタの対応状況
Shopify 単体ではなく、複数のデータソースをまとめて接続したい場合が多い。 以下のコネクタが揃っているかを必ず確認します：
- Shopify（注文 / 顧客 / 商品 / 売上）
- Klaviyo（メール送信履歴 / Flow 統計）
- GA4（イベント / セッション）
- Meta Ads / Google Ads / TikTok Ads（広告費 / インプレッション / クリック）
- Stripe（決済）
- 業務 DB（自社のカスタムテーブル）
軸 3：データの出力先（BigQuery への書き込み形式）
Fivetran / Airbyte などは、テーブル構造が標準化されています。 ただし、Klaviyo の Flow 統計、Shopify のキャンセル・返品、注文編集（order_edits）などは、テーブル形式が SaaS によって違うので、整形（dbt 側）の手間が変わります。
Shopify Plus 公式機能を使う場合
Shopify Plus 上位プランには、Shopify Data Proという BigQuery 直接連携機能があります。
- 追加費用：Plus プラン内で利用可能（追加月額がかかる場合あり、ストア規模次第）
- 連携データ：注文、顧客、商品、売上、セッションなど主要データ
- 更新頻度：Daily が標準
メリットは「公式が用意しているのでメンテが安定」。 ただし、Plus プラン以外では使えない、また、Klaviyo / GA4 / 広告データなどは 別途 SaaS や自作で取り込む必要がある点に注意。
自作で組む場合の現実的なつまずき所
自作（Shopify GraphQL Admin API + 自前パイプライン）を選ぶ場合、 技術的には可能ですが、運用で必ず引っかかる地雷があります。経験ベースで列挙します。
① Bulk Operations の使いこなし
Shopify は大量データを取るときは Bulk Operations（一括クエリ）を使う必要があります。 通常の API 呼び出しではレート制限ですぐ詰まる。 5 万件超えると、Bulk が必須。
Bulk Operations の流れ：
- GraphQL で Bulk クエリを投げる
- Shopify 側でクエリが完了するまで待つ（数分〜数十分）
- JSON Lines 形式の結果ファイル URL を取得
- そのファイルをダウンロードして BigQuery に書き込む
このフローを安定運用するには、ポーリング機構、リトライ、エラーハンドリングが必要。
② 注文のキャンセル・返品・編集
注文は作成された後も状態が変わります。
- キャンセル（cancelled_at の追加）
- 返品（refunds の発生）
- 注文編集（order_edits、商品の追加削除や金額変更）
「いつの状態か」をスナップショットで持たないと、集計ロジックが日々ズレます。 通常は MERGE を使った Upsert で、「最新状態」と「履歴」の両方を保持するのが標準。
③ タイムゾーン問題
Shopify は内部 UTC、店舗設定はローカル（例：JST）、BigQuery テーブルは別。 日次集計で「1 日ズレる」事故が頻発します。
解決策は、整形時に必ず店舗のタイムゾーンに変換してから日付化すること。 dbt のマクロで一律変換する仕組みを最初に作っておく。
④ Webhook の取りこぼし
イベント駆動で取り込む場合、Webhook が落ちることがあります。 Shopify 側のリトライにも限度があるので、バッチでの差分補正（毎日深夜に「過去 7 日分の不足を埋める」）を必ず実装します。
⑤ API バージョンの追従
Shopify は API バージョンが定期的に更新される（年 4 回）。 古いバージョンは 1 年で deprecate される。 半年〜 1 年ごとに自分で追従が必要です。
どの方式でも刺さる、Shopify 固有の地雷 5 つ
- テスト注文の混入：開発時に作ったテスト注文が、生データに混じる。 email がテスト用ドメインかどうか、または specific tag で除外するロジックを必ず入れる
- 無料注文（金額 0 の注文）：プレゼントやインフルエンサー無償提供で発生。 LTV / 売上集計から除外するか、別カウントするかを決める
- サブスクと単発購入の混在：定期注文と単発注文が同じ orders テーブルに入る。 recurring フラグでの判別ロジックを最初に決める
- マルチカレンシー：複数通貨で販売している場合、為替レートの統一が必要。 注文時点のレートで JPY 換算するか、最新レートで再計算するかを決める
- マルチストア：複数店舗を 1 つの BigQuery に統合する場合、店舗 ID の付与忘れに注意。 integration の最初に store_id カラムを必ず追加
入れた後にやること — 取り込みは半分、整形が残る
重要な前提：データを BigQuery に入れただけでは、まだ業務には使えません。
理由は、SaaS や API から流れてくるデータは「Shopify 側のテーブル構造そのまま」だからです。 注文の生レコード、顧客の生レコード、商品の生レコードが並ぶだけ。 ユーザー単位の累積購入額、月次売上、コホート LTV のような業務粒度にはなっていない。
そこで、生データを「業務で使えるテーブル」に整形する手順を、dbt のようなツールでコード化します。 ここまで作って、初めて経営会議や Slack AI 分析エージェントから業務質問を投げて、答えが返ってくる状態になります。
dbt 整形の典型パターン
dbt の標準的な階層構造：
staging（生データの軽い正規化）
- stg_shopify__orders
- stg_shopify__customers
- stg_shopify__products
- stg_klaviyo__email_events
- stg_ga4__sessions
ここでカラム名を統一、型を変換、タイムゾーン処理、テスト注文除外などを行う。
intermediate（複数の staging を結合した中間テーブル）
- int_orders_with_customer（注文に顧客属性を付与）
- int_orders_with_session（注文と GA4 セッションを結合）
- int_orders_with_email（注文と Klaviyo メールを紐付け）
marts（業務で直接使うテーブル）
- fct_orders（注文単位のファクトテーブル）
- dim_customers（顧客のディメンション、累積購入 / LTV / 最終接触）
- monthly_metrics（月次の売上 / 新規 / リピート）
- cohort_ltv（獲得月 × 経過月のヒートマップ用）
- channel_attribution（チャネル別の獲得 / 売上）
marts レイヤーが整っていれば、AI 分析エージェントは「使い回せるテーブル」をベースに SQL を組み立てます。 精度・速度・コスト全部が安定する。
全体像はデータ基盤を組むときに考えることに書きました。
月額コストの目安
規模別レンジ（年商 1〜30 億の D2C 想定）
- SaaS（Hevo / Stitch）：月 2〜 5 万円 + BigQuery 数千〜数万円
- SaaS（Fivetran 標準）：月 5〜 30 万円（年商連動）+ BigQuery 数千〜数万円
- Shopify Plus 公式機能：Plus プラン内（既に使ってれば追加負担小）
- OSS（Airbyte Self-hosted）：サーバー代 月数千〜数万円
- 自作：BigQuery のクエリ実行 + Cloud Functions 等のインフラで 月数千〜数万円
dbt 整形と BI 表示を含めると、フル構成でだいたい 月 10〜 50 万円のレンジに収まる組織が多い。
よくある落とし穴 5 つ
- SaaS の料金モデルを軽く見る — 1 年後にアクティブ顧客が増えて、月額が当初想定の 5 倍になる。 年商連動で爆発しない選択を最初にする
- 「とりあえず BigQuery に入れた」で止まる — 整形しないと、業務質問には答えられない。意思決定に乗らない
- 注文のキャンセル・返品・編集を考慮していない — 売上集計が日々変わって、誰も信用しなくなる
- タイムゾーンを揃えていない — 日次レポートで 1 日ズレる事故が頻発
- BigQuery のクエリコストを監視していない — ダッシュボードのフルスキャンで、月の請求が突然跳ねる。 INFORMATION_SCHEMA から日次でコスト集計を Slack に流す
まとめ
- Shopify to BigQuery は、複数ソース横串の分析、長期保存、AI 分析エージェント接続のために、 EC/D2C で標準パターン化しているデータ移行
- 選択肢は 3 系統：SaaS で買う / Shopify Plus 公式機能 / 自作。 年商 1〜30 億の D2C なら、SaaS（料金モデルに注意）か Plus 機能から始めるのが現実的
- BigQuery に入れただけでは終わらない。dbt で業務粒度に整形してこそ、データが動く
- Shopify 固有の地雷（テスト注文 / 無料注文 / サブスク混在 / マルチカレンシー / マルチストア）に最初から備える
- 自作は柔軟だが運用コストが重い。専任エンジニアが必要、と前提を置く