Google広告（特にShoppingやP-MAX）の週次レポート、毎週どれくらい時間をかけていますか？
広告アカウントの数値をスプレッドシートにコピペし、Shopifyの売上を別シートで突き合わせ、商品単位の効率を眺めて気づきをまとめるところまでで２〜３時間。「毎週これをやるのは正直しんどい」という方は多いと思います。
Google広告のデータをBigQueryに集約してClaudeからつなぐと、この週次作業がだいぶ楽になります。今回はその環境構築の手順と、ECならではの分析シナリオをまとめておきます。
佐藤 恒
株式会社INVOX 代表取締役CEO
マーケティング領域でデータ分析基盤の設計・構築を担当。広告や顧客接点のデータをAIが扱える形に整え、現場のマーケターが自分で分析できる環境づくりに取り組む。スタートアップから大手まで、データはあるけれど活かしきれていない事業会社に伴走し、"判断のスピード"を変えることをミッションとしている。
株式会社INVOX
https://in-vox.com
この記事の目次
ECの広告分析が抱える３つの構造的課題
ECのGoogle広告分析は、ほかの業種と比べて構造的にひと手間多いです。具体的には３つの厄介ごとがあります。
週次レポート作成に２〜３時間かかっている
Google広告の管理画面でキャンペーン別の数値を確認し、Shopifyの売上データを別タブで開いて突き合わせ、Excelで商品別ROASを計算し、最後にスライドにまとめる。しかも、この作業は毎週発生します。仮に週２〜３時間かかっているとすると、年間では100時間を超えます。これは、ほぼ１人月に近い工数です。
「分析できる人がもう一人いれば」と思いながらも、結局は自分で集計し、整形し、報告資料まで作っている。そういうEC担当者や広告運用者は少なくないはずです。
Shopping広告・P-MAXの中身が見えにくい
Standard Shoppingキャンペーンでは、商品単位でクリック、費用、CV、CV値などを確認しやすく、どの商品を伸ばすか/抑えるかを判断しやすいです。
一方、P-MAX（Performance Max）は、検索、YouTube、Discover、Gmail、Displayなどを横断して、Googleの機械学習が自動で配信を最適化するキャンペーン形式です。そのため、Standard Shoppingに比べると、配信面別・検索語句別・商品単位で細かく分析したり、意図的に配信を調整したりしにくい面があります。
P-MAXは成果拡大を狙いやすい一方で、「どこを止めて、どこに寄せるか」の判断材料が少なくなりやすく、移行後に分析しづらくなったと感じる運用者が多いのも事実です。
商品×顧客×広告をつないだ分析が難しい
ECでは、Shopifyに商品・顧客・注文データ、Google広告に広告配信・費用・CVデータ、GA4にセッションや流入データが分かれて存在します。
「Google広告経由で初回購入した顧客のリピート率」「商品カテゴリ別の広告効率」「クーポン利用顧客と非利用顧客のLTV比較」などを分析するには、商品マスタ、顧客マスタ、注文データ、広告データを横断して見る必要があります。これを毎週スプレッドシートで手作業集計するのは、データ量が増えるほど現実的ではありません。
そこで重要になるのが、これらのデータをBigQueryなどのデータ基盤に集約し、Claudeのような生成AIに自然言語で質問できる環境を作ることです。SQLを書かなくても上記のような問いに答えが出せるようになります。
ECで実際にできる分析――架空のD2Cブランドで実演
どんな分析ができるのか、３つ具体例を紹介します。ここで紹介する分析は、Google広告のデータをBigQueryに集約し、Claudeから自然言語で問える環境を前提にしています。
題材は架空のスキンケアD2Cブランド「Daily Leaf」（年商約7,000万円、AOV約10,000円、12SKU）で、データはすべて架空のデータです。
キャンペーン別CPA / ROASを比較する
まず一番ベーシックな分析。Claudeにこう聞きます。
直近３か月のGoogle広告キャンペーン別に、コスト・CV数・CV金額・CPA・ROASを出して。campaign_typeごとに分けて、特にSHOPPINGとPMAXの違いがわかるように
リマーケ系ディスプレイ（display-remarketing）と指名検索（brand-kw）がROAS２倍超で頭ひとつ抜け、Shoppingは1.4前後、P-MAXは1.2前後で新規開拓系としては成立、一方ジェネリック検索（generic-skincare、generic-serumなど）は0.7前後で赤字、という構図が見えます。
ROASだけ見るとリマーケと指名を増やしたくなりますが、これらは新規開拓に貢献しないので流入の蛇口を閉めれば数か月後に枯渇します。Claudeに「この構造を踏まえた打ち手は？」と聞くと、「赤字のジェネリック検索はキーワード/入札を見直し、新規開拓を担うShoppingとP-MAXの予算は維持」のような方針が出てきます。
広告で押しているカテゴリと売れているカテゴリの整合性を見る
「広告で寄せているカテゴリ」と「実際に売れているカテゴリ」がズレている、というのはECあるあるです。
Daily Leafの広告キャンペーンはgeneric-serum、generic-uv、generic-skincare、shopping-feed-allのように商品カテゴリと対応する命名なので、Shopifyの商品カテゴリ別売上とGoogle広告のキャンペーン別コストを並べるだけで、押している先と売れている先の対応関係が見えます。
直近３か月で、商品カテゴリ別の売上ランキングをShopifyから出して。あわせて同期間のGoogle広告のキャンペーン別コストも並べて、特にgeneric-serum / generic-uv / generic-skincare / shopping-feed-allの４本について見たい
直近３か月（2026-02〜2026-04）を見ると、売上はserum（¥4.73M、シェア28.7%）が圧倒的１位でskincare_set、cream、toner、milkと続き、広告投下はgeneric-skincare ¥633K > generic-serum ¥584K > shopping-feed-all ¥452K > generic-uv ¥201Kの順でした。
ここから２つのミスマッチが見えます。１つは、最大投下のgeneric-skincare（¥633K）がROAS 0.65で４本中最低、CPAも¥9,046で最高。「スキンケア」というビッグワードで汎用クエリを拾いすぎてコンバージョン効率が悪い構図で、キーワード絞り込みか予算再配分が検討対象。
もう１つは、generic-uvが投下¥201Kと控えめなのにROAS 1.07で２番目に良く、これから本格シーズン（５〜８月）に入るUV製品としては予算拡張の余地があります。shopping-feed-all（ROAS 1.41）は最も効率が良く、伸ばす方向。
商品単位の真のROASまで踏み込まなくても、カテゴリ別売上 vs 広告投下の並列比較だけで「どこを止め、どこに寄せるか」の判断材料はかなり集まります。
季節性×配信比率を可視化する
ECは季節性が強い業種です。Daily Leafの場合、11月のブラックフライデーと12月の年末、そして４月の新生活シーズンに山が立ちます。
過去12か月の月次GMVと、Google広告の月次コストを並べて。GMVに対するコストの比率（広告費率）も出して
過去12か月を見ると、平均広告費率は15.47%で月次もそれぞれ14〜16%台に安定。GMVの山は11月（¥6.80M、ブラックフライデー）、12月（¥6.44M、年末セット）、４月（¥6.52M、新生活）の３つ。
広告費率も11月が16.27%で最高、GMV増以上に予算を寄せて攻めている月と読めます。逆に８月は14.35%で最低で、夏枯れ期にコストを抑えている様子。
目を引くのは、３月（16.16%）→４月（15.01%）の改善。GMVは伸びているのに広告費率は下がっているので、「何が効いて効率が改善したか」をClaudeに深掘りさせれば、来月の予算配分の根拠が掴めます。
なお、ここで言う「広告費率」はGoogle広告費 / 全GMVなので、厳密にはGoogle広告のROAS（広告費：広告経由売上）とは別物です。GMVの分母にオーガニック流入やMeta経由の売上も含まれるため、分けて考える必要があります。
ClaudeでGoogle広告を分析する環境の全体像
ここからは、上の分析を実現する環境の作り方を説明します。
アーキテクチャ
構成はシンプルです。
Google広告 → Fivetran → BigQuery → MCP → Claude
Google広告がデータの源。FivetranがGoogle広告のデータを引っ張ってきて、BigQueryに整形して入れます。BigQueryにデータが入ったら、MCP（Model Context Protocol）という規格でClaudeから接続します。あとはClaudeに自然言語で問えば、内部でSQLが生成されてBigQueryから結果が返ってくる、という流れです。
各構成要素の役割
- Fivetran：データパイプラインのSaaS。Google広告のAPIに繋ぐコネクタが用意されているので、自分でAPI連携を書かずに済みます。無料枠あり。
- BigQuery：Google Cloudのデータウェアハウス。EC事業者の規模なら無料枠で足りるケースが大半。
- MCP：ClaudeなどのAIツールと外部データソースを繋ぐ規格。最近Googleが公式のリモートMCPサーバーを提供開始。
- Claude：分析の窓口。Desktop版でもブラウザ版でも、リモートMCPサーバー経由でもBigQueryにつながります。
構築手順①：必要なサービスの登録
３つのサービスに登録します。所要時間は合わせて15〜30分です。
Fivetran
Fivetran公式サイトの「Start free」から登録できます。クレジットカード登録なしで14日間の無料トライアルがあり、その後もFreeプラン（月50万行まで）が使えるので、EC事業者の規模なら無料で始められます。
BigQuery
Google Cloudのアカウントで利用できます。プロジェクトを新規作成してください。
注意点が１つ。BigQueryの「サンドボックス環境」（クレカ登録なしで使える無料環境）ではFivetranが動作しません。サンドボックスから「アップグレード」してください。アップグレードといってもクレカ登録するだけで、無料枠（クエリ１TB/月）はそのまま使えます。
ロケーションは「US（マルチリージョン）」が無難です。日本のリージョンを選ぶことも可能ですが、エンタープライズ企業のデータ保管要件がない限り、デフォルトのUSで問題ありません。
Claude
Desktop版またはブラウザ版（claude.ai）のどちらでも構いません。今回はリモートMCPサーバー経由で接続するので、両方とも対応しています。
構築手順②：FivetranでGoogle広告データをBigQueryに転送
Fivetranで２つの設定をします。Destination（転送先）の作成と、Connection（転送元）の追加です。
Destinationの作成（BigQuery）
Fivetranのダッシュボードで「Destinations」→「Add destination」をクリック、「BigQuery」を選択します。
Setup Guideに沿ってBigQueryプロジェクトIDやサービスアカウント認証情報を入力し、「Save & Test」で接続確認。これで完了です。
ConnectionでGoogle Adsを追加
次に「Connections」→「Add connection」で「Google Ads」を選択。OAuth認証でGoogle広告アカウントに接続します。複数のMCC（管理アカウント）配下を持っている場合は、対象アカウントを指定してください。
データ同期の頻度はプランに応じて選べます。Freeプランは最短６時間ごと、Standard以上で１時間ごとも選べます。週次レポート用途ならFreeプランの６時間ごとで十分です。
dbt Packageで分析用テーブルを整形
Fivetranが提供している「dbt Package」を使うと、Google広告の生データから、分析しやすい形のテーブル（キャンペーン日次集計、広告グループ日次集計、キーワード日次集計など）を自動で作ってくれます。
Connection設定の最後に表示される画面でTransformationsを有効にしてください。これを使わないと、生データのテーブルが大量に並んで何が何だかわからなくなります。
構築手順③：BigQueryをClaudeに接続する
ここが最後のステップです。リモートMCPサーバーを使うので、ローカルに何かインストールする必要はありません。
リモートMCPサーバーでBigQueryと繋ぐ
Google Cloud公式のBigQuery MCPサーバーが用意されています。
Claudeの設定で「カスタマイズ」→「コネクタ」を開き、BigQueryのコネクタを追加します。Googleアカウント認証を求められるので、BigQueryのプロジェクトを使えるアカウントでログインしてください。
Google Cloud側でOAuthクライアントを作成し、Claudeのコネクタ設定に入力すると接続ができます。Desktop版・ブラウザ版どちらでもこの手順で繋がります。
Claudeから接続を確認する
接続できたら、Claudeに「BigQueryのGoogle広告データセットにあるテーブルを一覧で見せて」と聞いてみてください。テーブル名がずらっと返ってきたらセットアップ成功です。
構築・運用で詰まりやすいポイント
ここまでで分析環境は整いますが、運用に乗せると必ずぶつかる構造的な制約があります。先に知っておくと心の準備ができます。
Google広告上の購入数とECカート上の真値が乖離する
Google広告管理画面の「コンバージョン数」とShopifyの実際の注文数は一致しないことがあります。
主な要因は、SafariなどのITPやサードパーティCookie制限による追跡漏れ、複数デバイスを跨いだ購入のcross-device attribution不完全性、ビュースルーコンバージョン（広告を見ただけで購入した扱い）の加算など。「真の売上」はShopify側を正として捉え、Google広告管理画面のROASは参考値として見るぐらいがちょうどいいです。
P-MAXは可視性が改善されたが、自由な明細分析にはまだ限界がある
P-MAXは以前に比べて可視性が改善されており、現在はチャネル別レポートや検索語句インサイトも利用できます。
ただし、商品・配信面・検索語句・ユーザー単位を自由に掛け合わせた完全な明細分析ができるわけではありません。Google広告単体では見えない部分が残るため、Shopifyの商品・注文データやGA4の行動データとBigQuery上で突き合わせて補完するのが現実的です。
ROASは売上ベースであって粗利ではない
ROAS（広告売上÷広告費）だけを見て粗利率の低い商品に広告を寄せると、売上は伸びても利益は減るという事態が起こる可能性があります。
複数商材を扱うECや原価率の幅が広いカテゴリでは、Shopify商品マスタに原価カラムを足してBigQueryに同期し、「粗利ROAS」を別途計算する仕組みを用意しておくと安心です。
GA4とShopifyを厳密に繋ぐにはGA4側のuser_id実装が必要
「P-MAX起点のこのセッションでこの商品が売れた」レベルまで追いたい場合、標準データだけでは組めません。
GA4 BigQuery Exportはemailが入らず（GoogleのPII送信ポリシー）、Shopify側にもGA4のuser_pseudo_idがないため、共有キーが存在しないからです。
解決策は、GA4側でuser_idとしてShopifyのcustomer_idを送る実装（gtagやGTMでチェックアウト時に設定）。深掘りが必要になったタイミングで足すのが現実的です。
まとめ：環境を整えると意思決定のスピードが変わる
構築自体はプロに任せればスムーズに終わります。
その先に何が変わるかというと、週次レポートに２〜３時間かかっていた作業が10分台に短縮されます。意思決定のサイクルが、月次から週次に、週次から日次に近づきます。
そしてこの流れは、いったん環境ができると、Meta広告・GA4・Search Consoleと範囲を広げていけます。最初の１ステップとして、Google広告 + BigQuery + Claudeから始めてみてください。
株式会社INVOXのご紹介
株式会社INVOXでは、EC事業者を対象に、Google広告・GA4・Shopifyなどのデータをワンストップで集約し、Claudeから自然言語で分析できる環境の構築・運用を支援しています。
「自社でも試したいが、どこから手を付けていいかわからない」「本格的なデータ基盤を整えたい」という方は、公式サイトよりお気軽にご相談ください。
あわせて読みたい
