なぜShopify→BigQuery連携は選択肢が分かれるのか
同じ「Shopify → BigQuery」の要望でも、案件ごとに採用される方式が違うのは、要件が3つの軸で大きくばらつくためです。
1つ目は 対象データの範囲と鮮度 です。注文・商品・顧客の3本だけ日次で載せれば足りるのか、在庫スナップショット・放棄カート（Checkouts）・返金・メタフィールドまで含めて時間単位で追いたいのか。単一ストアで注文月1,000件規模なら、どのツールでも日次同期が動きます。一方、注文月10万件・多店舗・在庫時間単位の要件が入ると、GraphQLの calculated cost と Bulk Operations の設計が必須になります。
2つ目は 多店舗・多通貨の有無 です。日本のShopifyストアだけならシンプルですが、jp.myshopify.comとus.myshopify.comを1つのBigQueryに寄せる場合、shop_domain列の付与、注文ID・顧客IDのストア別独立性、presentment_currencyとshop_currencyの使い分けを設計時に決めておかないと、後段の売上集計がずれます。SaaS ELTでも各社の対応差が大きいポイントです。
3つ目は 社内の技術資産と稟議事情 です。すでにデータエンジニアが1人以上いてPythonとBigQueryを触れる会社なら、Cloud Run内製で月額を数千円台に圧縮できます。エンジニア工数がなく、稟議も国内SaaSしか通りにくい会社ならtrocco一択。複数SaaSを英語系ツールで一元管理したい大手はFivetran、既存のAirbyte資産があるならAirbyte、と切り分けが変わります。
この3軸で要件を整理すれば、5つの選択肢のうちどれが自社に合うかは概ね絞れます。以降のセクションでは、それぞれの方式の中身と、費用相場、選び方の判断軸を順に見ていきます。
5つの連携方式：概要と得意領域
Shopify → BigQuery の連携方式は、大きく次の5つに整理できます。
| 方式 | 提供元 | 実装難易度 | 得意な要件 |
|---|
| Fivetran | Fivetran（米） | 低 | 複数SaaS横断、スキーマ自動追従、多店舗の並列取り込み |
| trocco | primeNumber（日） | 低 | 日本語サポート、稟議通しやすさ、対象絞り込みの柔軟性 |
| Airbyte Cloud / OSS | Airbyte（米/OSS） | 中 | GraphQL/Bulk対応、コネクタ多数、自ホスト運用の余地あり |
| Cloud Run 内製 | Google Cloud＋自作 | 高 | 費用最小化、多店舗の柔軟な統合、既存GCP基盤への統合 |
| Stitch／Hevo など海外ELT | Talend/Hevo（米） | 低 | 既存のStitch/Hevo資産あり、低スペック要件 |
Fivetran は、Shopifyコネクタを標準搭載する米国発のSaaS ELTで、注文・商品・顧客・在庫・返金・放棄カート・メタフィールドなど主要オブジェクトを自動同期し、スキーマ変更にも追従します。多店舗は「1ストア＝1コネクタ」の単位で登録し、BigQuery側でスキーマを分けてくれるため、店舗横断はdbtで束ねるのが定石です。料金は MAR（Monthly Active Rows：月間の追加・更新・削除された行数）ベースで、Standard $500/百万MAR〜、Enterprise $667〜、Business Critical $1,067〜。2025年3月以降はコネクタ単位でMARを計算する方式に変わり、コネクタあたり $5 の最低課金 も追加されているため、多店舗運用では店舗数だけベース料金が積み上がる点に注意が必要です。詳細はFivetranのコスト最適化｜MARの削減と契約プランの見直しを参照してください。
trocco は、日本のprimeNumber社が提供するETL/ELT SaaSで、Shopifyコネクタを転送元として持ちます。GUIからノーコードで転送設定を組め、対象オブジェクト・カラムを転送設定単位で絞り込めるため、Fivetranより MAR相当の転送量をコントロールしやすい のが実務上の強みです。料金はFree（月2時間、0円）、Starter（月75,000円、30時間枠、5ユーザー）、Essential（月150,000円、250時間枠）、Advanced（月300,000円、600時間枠、コネクタ200種類以上）の4段階で、単一ストア＋日次同期ならStarterで十分収まります。円建て請求書払いで国内稟議が通りやすい点も選ばれる理由です（trocco料金体系の詳細と競合比較参照）。
Airbyte Cloud / OSS は、OSSで公開されているAirbyteのShopifyソースコネクタを、マネージド版（Airbyte Cloud）または自社構築（OSS）で使う構成です。コネクタ内部でShopify REST・GraphQL・GraphQL Bulk APIを併用し、Shopify Plusでは>100 redeem codes per discountのような特殊仕様にも対応する更新が2026年に入っています。認証はOAuth2.0が推奨（API Passwordは廃止予定）。Airbyte CloudはSaaS課金、OSS自ホストはGCE/GKE上の実費（月5,000〜15,000円）だけで済みます。ただし、OSSは本体のバージョンアップ追従・障害復旧・コネクタ更新時の互換性検証などの運用工数が発生します。
Cloud Run 内製 は、Shopify GraphQL Admin APIをPythonから叩き、Cloud RunとCloud Schedulerで日次バッチを回してBigQueryに書き込む構成です。GCP側の実費は月3,000〜15,000円で、月商10億円規模でも十分収まります。ただし、認証（Custom AppのAccess Token管理）、GraphQLのcalculated cost制御、Bulk Operationsの起動とJSONLダウンロード、多店舗のshop_domain付与、返金・返品の再取得ウィンドウ、在庫スナップショット、メタフィールドの選択取得をすべて自作する必要があり、初期開発費は50万〜120万円、保守工数も上乗せされます。PythonとGCPが触れるエンジニアが1人でもいる会社向けの選択肢です。
Stitch／Hevo など海外ELT は、Talend系のStitchやHevo Dataといった海外ELTでShopifyコネクタを使う選択肢です。国内での採用は少ないものの、既存のStitch/Hevo資産がある会社では、そのままShopifyコネクタを追加して数日で回せます。料金はStitchが月$100〜$1,250、Hevoが月$249〜のレンジ。多店舗・メタフィールド・Bulk Operationsのカバレッジは方式ごとに差があり、日本語サポートも薄いので、稟議の通しやすさで見るとFivetran・troccoに劣る傾向があります。
Shopify Admin APIの制限と特有仕様：設計時に必ず押さえるポイント
方式選定と並行して、Shopify Admin APIの制限と特有仕様を先に押さえておかないと、稼働後に「大量注文の日次同期がタイムアウトする」「複数ストアで並列にBulk Jobを起動したら5件上限で詰まった」といった障害を招きます。設計時に必ず確認したいのは、次の3点です。
GraphQL Admin APIのcalculated query cost
- 標準Shopifyプラン：1,000ポイントのバケット、50ポイント/秒でリストア
- Shopify Plus：2,000ポイントのバケット、100ポイント/秒でリストア
- 1クエリあたりの最大コスト：1,000ポイント（プラン共通）
- カウント単位：アプリ × ストア の組合せごと（別アプリを別トークンで動かせば実質的な並列度は上げられる）
- 超過時：GraphQLレスポンスに
THROTTLEDエラー、extensions.costにrestore待ち時間
大量注文を1クエリで取ろうとするとバケットが枯渇するため、通常GraphQLはページング（first: 100＋cursor）で100件ずつ、それでも足りないなら次のBulk Operationsを使います。REST版のAdmin APIは2024年10月以降legacy扱いなので、新規実装は原則GraphQLに寄せます。
Bulk Operations APIの使いどころ
- 概ね 1,000レコード以上 の一括取得、または深くネストしたクエリで使う
- 非同期ジョブとして実行され、結果は JSONL形式 の署名付きURLで返る
- API 2026-01以降、1アプリ×1ストアあたり最大5件のbulk query＋5件のbulk mutation を同時実行可能
- 1ジョブの最大実行時間：10日（超過で自動失敗）
- ファイルサイズ上限：50MB程度（詳細はAPIバージョンで変動）
差分同期には向かず、月次のフルリロードや初回移行の全件ロードで真価を発揮します。日次の増分は通常GraphQL、月次はBulk Operationsの併用が定番設計です。
多通貨（presentment currency）と多店舗
- 注文の金額は
shop_money（ストア基準通貨）とpresentment_money（購入者が支払った通貨）の2種類が存在 - 分析マートでは ストア基準通貨に寄せた列と、実際に受領した通貨の列 の両方を持たせる
- 多店舗運用では、注文ID・顧客ID・商品IDが ストアごとに独立した名前空間 で採番される
- BigQuery側は必ず
shop_domainまたはstore_idを全テーブルに持たせ、shop_domain × idの複合キーで名寄せする
このあたりの設計を後回しにすると、店舗を横断したLTVや売上集計を出す段階でやり直しになります。
費用相場：初期構築費と月額の目安
「結局いくらかかるのか」を先に押さえたい方向けに、方式別の初期・月額の目安を並べます。対象は「Shopifyストア1〜3店舗＋月商1,000万〜10億円＋注文数月1,000〜10万件＋日次または時間単位同期」の中堅D2C／EC事業者ケースを想定しています。
| 方式 | 初期構築費 | 月額運用費（連携部分） | BigQuery費用（別途） |
|---|
| trocco Free | 0円 | 0円（月2時間まで） | 数千〜1万円 |
| trocco Starter | 0円 | 月75,000円（30時間枠） | 数千〜1万円 |
| Fivetran | 30万〜100万円 | 月$500〜$2,000（MAR依存） | 数千〜1万円 |
| Airbyte Cloud | 20万〜50万円 | 月$300〜$1,000 | 数千〜1万円 |
| Airbyte OSS 自ホスト | 30万〜80万円 | 月5,000〜15,000円（GCE実費） | 数千〜1万円 |
| Cloud Run 内製 | 50万〜120万円 | 月3,000〜15,000円 | 数千〜1万円 |
| Stitch／Hevo | 30万〜80万円 | 月$100〜$1,250 | 数千〜1万円 |
初期構築費には、要件整理・対象オブジェクト設計・スキーマ設計・変換ロジック（dbt等）・多店舗設計・品質検証・ドキュメント整備までを含みます。troccoは設定作業そのものは軽いですが、その周辺の設計工数は他方式と大差ありません。
BigQuery側の実費は、注文月10万件規模で月数千〜1万円が中央値です。ストレージは論理 $0.02/GB/月、物理 $0.05/GB/月（東京リージョン、2026年目安）で、Shopifyの注文・顧客データは1本あたり数百MB〜数GBに収まることが多く、費用の主役はクエリスキャン量です。在庫スナップショットを日次で累積すると1テーブルで数十GB〜になるため、日別パーティションでスキャン量を絞る設計が必須になります。BigQueryのコスト削減の全体像はBigQueryの料金体系とコスト削減｜課金トラップと対策にまとめています。
トータルの費用感の中央値は、単一ストア＋標準的な中堅D2Cで 月8万円前後（trocco Starter＋BQ）、内製で圧縮するなら 月1万〜2万円（Cloud Run＋BQ、初期開発費除く）、多店舗＋複数SaaS横断で運用するなら月15万〜25万円（Fivetran または trocco Essential）のレンジです。3年運用で総額100万〜1,000万円のオーダーになります。
選び方の判断軸：ユースケース・鮮度・技術資産・稟議
方式選定を先に決め打ちで進めると、後から「安く済ませようとしたら要件を満たせなかった」「高機能を選んだが持て余した」というミスマッチが起きます。次の4軸で自社の要件をチェックし、消去法で絞るのが実務的です。
軸1：ユースケースの広さ
- 注文・商品・顧客の3本だけ、単一ストア、日次同期：trocco Free か Cloud Run 内製 が最安
- 在庫・返金・放棄カート・メタフィールドまで含めたい：Fivetran、trocco Starter、内製
- 多店舗（3店舗以上）＋広告×在庫×注文の横断分析：Fivetran か trocco Essential
軸2：鮮度要件
- 日次で足りる：どの方式でもOK。trocco Free と 内製 が最安
- 時間単位（1時間ごとにダッシュボード更新）：trocco Starter、Fivetran、Airbyte、内製
- 分単位・準リアルタイム：Shopify Webhook を Cloud Run で受けて Pub/Sub → BigQuery Streaming Inserts に流す 内製構成 が必要（在庫更新の
inventory_levels/updateを優先受信）
軸3：社内の技術資産
- エンジニア工数なし、日本語サポート必須：trocco（Starter以上）
- GCPとPythonが触れるエンジニア1人以上：Cloud Run 内製 が最安・最柔軟
- OSS運用実績あり、DevOpsチームあり：Airbyte OSS 自ホスト
- 複数SaaSを英語系ツールで一元管理したい：Fivetran
軸4：稟議と契約事情
- 円建て請求書払い必須、稟議が厳しい：trocco 一択
- クラウド勘定科目で処理できる、$建てOK：Fivetran や Airbyte Cloud も選択肢
- 保守工数を自社で持てる、稟議は柔軟：Cloud Run 内製 か Airbyte OSS
- 既存のStitch/Hevo資産あり：そのまま追加
この4軸で並べると、多くの中堅D2Cは「trocco Starter または Cloud Run 内製」の2択に絞れ、多店舗＋複数SaaSを横断する大手はFivetran、既存OSS運用ができる会社はAirbyte、という切り分けになります。ツール全体の比較観点はデータ連携ツールの選び方：コスト・サポート・コネクタ数で比較にまとめています。
実装の落とし穴：多店舗・在庫スナップショット・返品遅延・メタフィールド・多通貨
方式を決めたあとに詰まりやすい実装上の落とし穴を5つ挙げます。要件定義の時点で潰しておくと、稼働後の障害対応が大きく減ります。
多店舗（multi-store）の統合
Shopifyの注文ID・顧客ID・商品IDは、ストアごとに独立した名前空間で採番されます。jp.myshopify.comのOrder ID 5001とus.myshopify.comのOrder ID 5001は別注文です。BigQuery側の対策は必ずshop_domain（またはstore_id）を全テーブルに持たせ、複合キー（shop_domain × id）で名寄せすることです。Fivetran・troccoは既定で1ストア＝1スキーマ（shopify_jp.orders／shopify_us.orders）に分けるため、店舗横断のクエリはdbtのstg_shopify__orders層で全ストアをshop_domain付きでUNION ALLしてマート層に流すのが定番です。内製ではBigQuery書き込み時点でshop_domainを挿入して単一テーブルに寄せると、後段のSQLがシンプルになります。
在庫スナップショットの累積
Shopifyの在庫API（InventoryLevel）は現在値しか返さないため、時系列で追いたい場合は日次スナップショットをBigQuery側で累積する設計が必要です。日次バッチで拠点×商品バリアントの全在庫を取得し、snapshot_date列を付けてパーティションテーブルに追記します。バリアント数×拠点数×日数で行数が急増するため、snapshot_dateでの日別パーティションと、skuまたはvariant_idでのクラスタリングを必ず設定してください。90日分保持でも数千万行になるケースが普通です。リアルタイム性が必要ならinventory_levels/updateWebhookを Cloud Runで受けてPub/SubからBigQuery Streaming Insertsに流す構成もありますが、分析用途では日次スナップショット＋週次断面比較で足りるケースがほとんどです。
返品・返金の遅延反映
Shopifyの注文は返金・返品・タグ変更でupdated_atが更新されるため、増分同期をupdated_at >= 前回同期時刻で組めば、過去注文の変更も拾えます。落とし穴は、分析マート側で「注文月」でGROUP BYした売上テーブルを固定化してしまうケースです。返金が翌月以降に発生すると、過去月のマートが更新されずズレます。対策は2つで、①マート層をrefunded_atまたはupdated_atベースで再集計する、②直近90日は毎日再集計するウィンドウを日次バッチに入れる、が実務的です。過去N日ウィンドウでの再取得はdbtのincremental modelでlookbackパラメータを設けると管理が楽になります。
メタフィールド（metafields）の選択取得
Shopifyのメタフィールド（Product・Variant・Customer・Orderに付くカスタム属性）は、namespaceとkeyで識別されます。GraphQL Admin APIはnamespaceとkey（またはownerId）で絞れる一方、値そのものでのフィルタはできないため、必要な絞り込みは取得後にBigQuery側で行います。全メタフィールドを無制限に取得するとcalculated costが跳ねるので、分析で使うnamespace/keyだけを明示的に指定する設計が必須です。Fivetranはメタフィールドを標準取得しますがMARが跳ねやすく、troccoは転送設定でnamespaceを絞れるため転送量を抑えやすい設計になっています。内製ではGraphQLクエリでmetafields(first: 20, namespace: "custom")のように明示指定します。
多通貨（presentment currency）の使い分け
Shopify Paymentsで多通貨対応にしていると、注文の金額はshop_money（ストア基準通貨）とpresentment_money（購入者が支払った通貨）の2種類がレスポンスに含まれます。BigQuery側の設計は、分析マートで total_price_shop_currency（ストア基準）とtotal_price_presentment_currency（実受領通貨）の両方を保持 し、経営会議はストア基準、決済照合は実受領通貨、と使い分けるのが定石です。日本のストアで海外顧客がUSDで支払ったケースを、シンプルにtotal_priceだけで集計すると通貨換算誤差が生じるので、要件定義で必ず切り分けます。
標準構成例：スモール／中規模／複数ストア横断
具体的な構成イメージがつかめるよう、規模別に3パターン挙げます。
スモール：単一ストアの売上ダッシュボード（月1万円以下）
対象はShopify Standard、単一ストア、月商1,000万〜3,000万円、注文数月1,000〜3,000件規模。注文・商品・顧客の3本を日次でBigQueryに載せ、Looker Studioで週次の売上ダッシュボードを自動化する構成。
- 連携：trocco Free（月0円、2時間枠）または Cloud Run 内製（月3,000〜5,000円）
- 変換：BigQueryのスケジュールドクエリでシンプルな集計マート
- BI：Looker Studio（無料）
- 想定費用：初期30万〜80万円、月0〜数千円
Shopifyを導入して1〜2年目のD2Cで、まずは経営会議の週次で「今月の売上・新規顧客数・リピート率」を見たい段階の構成です。
中規模：単一ストア＋広告データ横断（月8万〜10万円）
対象はShopify Advanced、単一ストア、月商5,000万〜3億円、注文数月5,000〜3万件規模。注文・商品・顧客・在庫スナップショット・返金・放棄カート＋Google/Meta/TikTok広告データをBigQueryに統合し、dbtで共通の売上×広告×LTVマートを整備、Looker Studioで全社ダッシュボードを提供する構成。
- 連携：trocco Starter（月75,000円、30時間枠）＋広告データはSupermetrics等
- 変換：dbt Core（自前運用）または dbt Cloud（月$100〜$500）
- BI：Looker Studio Pro または Looker
- 想定費用：初期150万〜400万円、月8万〜15万円
Shopifyを「売上・顧客・広告の共通データベース」として使い倒しているD2C事業者がこのゾーンに入ります。trocco Starterの30時間枠は、単一ストア日次＋主要オブジェクト時間単位でも余裕を持って収まります。
複数ストア横断：日本×海外3〜5店舗＋HubSpot／Salesforce 統合（月15万〜25万円）
日本本店に加えて海外向けストア（US／EU／APACなど）を複数運営し、Shopify＋HubSpot／Salesforce（CRM）＋広告データをBigQueryに統合、部門横断のKPIダッシュボードをLookerで提供する構成。マーケ×EC×CSの3部門が同じ数字を見ながら意思決定する体制向けです。
- 連携：trocco Essential（月150,000円、250時間枠、ユーザー無制限）または Fivetran（月$1,000〜$3,000）
- 変換：dbt Cloud（月$500〜$1,500）
- BI：Looker（月$3,000〜）または Looker Studio Pro
- 想定費用：初期300万〜600万円、月20万〜40万円
このゾーンでは、稟議と円建て・複数コネクタ数のバランスでtrocco EssentialとFivetranのどちらを選ぶかが分かれます。国内SaaS中心なら trocco、海外SaaS比率が高いなら Fivetran が有力です。他SaaSの取り込み方はHubSpotのデータをBigQueryに連携する方法5つと費用相場やkintoneのデータをBigQueryで分析する方法5つと費用相場も参考にしてください。
Shopify→BigQueryを最短で立ち上げる4ステップ
方式を決めたあとの立ち上げは、次の4ステップで進めるとつまずきにくくなります。
ステップ1：対象オブジェクトとストアの絞り込み（1〜2週）
Shopifyにある全オブジェクト・全メタフィールドを載せようとせず、経営会議・部門会議で実際に使われている数字を作るのに必要な範囲に絞ります。まずは注文・商品・顧客・在庫の4本、返金と放棄カートは分析要件があれば追加、メタフィールドは分析で使うnamespaceだけを明示指定、というのが立ち上げ時の鉄則です。多店舗運用の場合はストアごとに認証情報（Custom App のAccess Token）を発行し、shop_domainの一覧を先に確定させます。
ステップ2：連携ツールの選定と契約（1〜3週）
前節の4軸で方式を絞り、troccoの場合はFreeプランで実データを1オブジェクト通してみます。無料でShopify→BigQueryが動くか、多店舗のスキーマ分離が期待通りかを確認してからStarterに切り替えます。Cloud Run内製の場合は、まず注文オブジェクトだけをPythonスクリプトでCloud Runで動かし、GraphQLの通常クエリ（orders(first: 100, query: "updated_at:>...")）とBulk Operationsの併用、cursor管理、429/THROTTLED時のバックオフを検証します。この段階でcalculated costの消費量を計測し、複数ストア並列時のバケット枯渇リスクを確認します。
ステップ3：BigQuery側の設計とdbt構築（2〜5週）
BigQueryにraw_shopify（連携そのままのテーブル）、stg_shopify（型変換・命名統一・多店舗のUNION ALL・多通貨列の整備）、mart_ec（EC KPIマート）の3層を作り、dbtでモデルを整備します。この段階で、返金遅延の再取得ウィンドウ（直近90日リプレイス）、在庫スナップショットのパーティション設計（snapshot_date＋variant_idクラスタリング）、メタフィールドの選択取得ポリシー、多通貨列の使い分けを確定します。EC横断の粗利・LTV分析まで組むなら、広告データやWMSデータとの結合キー設計もこの段階で決めます。
ステップ4：ダッシュボード構築と業務移行（1〜3週）
Looker StudioまたはLookerでEC事業部・経営会議・広告運用チーム向けダッシュボードを構築し、既存のShopify管理画面レポートやExcelレポートと1〜2週間並行運用して数字が一致することを確認します。並行期間を短くしすぎると「数字が合わない」という指摘で信頼を失うため、最低1週間は取ります。売上がShopify管理画面とズレるケースの多くは、返金・キャンセル・テスト注文・多通貨換算の扱いに起因するので、切替前に必ず突合しておきます。切替後、既存のShopify管理画面レポートやExcelレポート運用は段階的に廃止します。
Shopify×BigQuery連携を検討したくなったら
ShopifyのデータをBigQueryに載せると、単一ストアの売上ダッシュボードから、多店舗×広告×在庫の横断分析、CRM（HubSpot/Salesforce）と統合した全社ダッシュボードまで、EC/D2Cの意思決定サイクルが一気に組み替わります。ただし、方式選定・GraphQL calculated costの設計・Bulk Operationsの使いどころ・多店舗の名寄せ・在庫スナップショット・返品遅延・メタフィールドの選択取得・多通貨の扱いと、要件定義の段階で決めておくべき論点は多く、選定を誤ると月額が予算の2〜3倍に跳ねたり、必要な分析要件（SKU別粗利・チャネル別LTV）に届かなかったりします。
Evastでは、Shopifyを含む複数SaaSのBigQuery統合基盤構築を、月次のスモールスタートから対応しています。「まず現状のオブジェクト棚卸しと方式選定だけ相談したい」「troccoと内製の見積比較を稟議に使いたい」「多店舗運用でShopifyストアが増えて集計が破綻しつつある」といった段階からご相談いただけますので、お気軽にお問い合わせください。データ基盤全体の考え方はデータ基盤構築｜Evastのデータ基盤構築サービスにまとめています。
