BigQueryなしでGA4・GSCデータを蓄積する方法｜SQLiteで擬似BigQueryを作る

2026年7月8日

BigQueryを導入していないサイトでも、GA4とサーチコンソール（GSC）のデータを日次で蓄積して、SQLで何度でも好きな断面を切り出せます。この記事では、Claude Codeに相談しながらローカルのSQLiteにデータを溜める仕組みを作った過程と、そのまま真似できる手順をまとめます。

対象は「BigQueryは重いけどGSC/GA4データは蓄積したい」サイト運営者・SEO担当者です。読み終えると、GCPもクエリ課金もなしで擬似BigQueryを作る全体像がわかります。所要時間は初回のバックフィルで数分、以降は日次数十秒です。

結論を先に書くと、BigQueryが使えるならそちらが上位互換です。

ただしBigQueryが使えない・調整コストが重い環境では、SQLite蓄積が現実的な次善策になります。

ご覧いただきありがとうございます。

採用する前に。外注する前に。

AI時代に試せる第三の選択肢をまとめました。

サービス資料DL(無料)

＜資料サンプル＞

セミナー共催やコラボプロジェクトなど、パートナー提携についてはこちらをクリック
シンクムーブのインハウスマーケティング共創支援はこちらをクリック
シンクムーブ代表豊藏のプロフィールはこちらをクリック

📘 あなたの記事、AIにどう評価される？ → ThinkMove Academy（無料）

読みたい場所にジャンプ

BigQueryの代替は41MBのファイル1個で足りる

構成はシンプルです。GoogleのAPIからGSCとGA4のデータを毎日取得し、SQLiteのデータベースファイルに追記していく。それだけです。

自社サイトとクライアント2社分、16ヶ月分を入れて容量は41MB。行数は数百万行です。GCPプロジェクトもクエリ課金も接続設定も存在しません。ファイルが1個あるだけです。

「擬似BigQuery」と呼ぶのは、溜めておいてSQLで何度でも好きな断面を切れるという使い方がBigQueryと同じだからです。違うのはインフラがゼロになっている点だけです。

なぜSQLiteがクライアントワークで効くのか

BigQueryが使えるならそれに越したことはありません。ただしクライアントワークだと、この導入が意外と重いです。

BigQueryのエクスポートは先方のGCP側にデータセットを作ってもらう必要があります。こちらのアカウントに権限を付与し、それを先方が管理し続ける体制になります。この調整だけで数週間かかることもあります。

SQLiteならAPIの閲覧権限さえあれば、その日から溜め始められます。先方の環境に何も作りません。ここがクライアントワークで最大の差になります。

GA4・GSCデータをSQLiteに取り込む手順

技術的な話をすると、この日コードは1行も書いていません。Claude Codeへの発言だけで完成しました。実際の指示を時系列でそのまま載せます。

1. テーブル設計と取り込みスクリプトを作る

最初の指示はこれだけです。

データベースの中に入れちゃったら、BigQueryみたいに擬似的に使うことができたりするのかな。一回やってみて

これでSQLiteのテーブル設計と取り込みスクリプトができ、数分後には自社サイトの90日分が入りました。Google認証が切れていた箇所だけ「このコマンドを実行してください」と指示され、ターミナルに1行貼りました。人間の作業はそれだけです。

2. 集計の締め仕様を口頭で指定する

次に、レポートの締め仕様を言葉で直しました。

毎月5月末締めで。全体レポートは3ヶ月に対して前年の3ヶ月と比較するっていうのを基本フォーマットにしてほしい

この一言で、レポートが「月末締め・直近3ヶ月×前年同期」に組み変わりました。仕様書は書いていません。しゃべった要件がそのまま仕様になります。

3. 表示の見た目を調整する

見た目も同じ流れで直しました。

各行をウィンドウ形式にしてさ、スクロールすると下に行けるみたいな。LookerStudioみたいなイメージがいいんだよね

これで表が固定ヘッダー付きのスクロールウィンドウになり、列見出しクリックでのソートまで付きました。

要件定義書とコードの間の距離がほぼゼロになる感覚があります。思いついた不満を口にすると、次のレポートから直っています。

溜めるテーブルは9枚｜GSC5枚・GA4の4枚

蓄積しているテーブルは全部で9枚です。GSC側が5枚、GA4側が4枚。用途込みで一覧にします。

テーブル名	粒度	主な用途
gsc_daily	サイト×日	全体指標（クリック・表示・CTR・順位）の俯瞰
gsc_query_daily	日×クエリ	クエリ単位の推移
gsc_page_daily	日×ページ	ページ単位の推移
gsc_device_daily	日×デバイス	デバイス別の傾向
gsc_query_page	期間×クエリ×ページ	カニバリゼーション検出
ga4_channel_daily	日×チャネル	チャネル別セッション
ga4_landing_daily	日×ランディングページ	オーガニックの着地ページ分析
ga4_source_daily	日×参照元/メディア	流入元の実態把握
ga4_conversion_daily	日×キーイベント名	コンバージョン推移

全ディメンションを溜めないのがポイント

設計の肝は、全ディメンションを溜めないことです。俯瞰に使う切り口だけ溜め、深掘りしたくなったらその時だけAPIを直接叩きます。この分担にしないとデータベースが際限なく太ります。

Search Console MCPを使っているなら、これで基盤を作っておき、必要なデータは追加でMCPから取る運用もありだと思います。

ga4_source_dailyがAI流入の過小評価を防いだ

ga4_source_daily は途中から足したテーブルですが、これが当たりでした。

あるクライアントで、チャネルレポート上は「AI Assistant」が123セッションだったのが、参照元ベースで見ると chatgpt.com や openai 経由が870セッションを超えていました。AIからの流入は、チャネル分類だと過小に出るケースがあります。参照元の生の値を持っておく価値はここにあります。

集計は速い。重いのはAPIからの運搬だけ

当初は「毎回SQLで集計するのは重いのでは」と思っていました。実測すると逆でした。

重いのはGoogleのAPIからデータを運んでくる瞬間だけです。16ヶ月分のバックフィルは数分かかります。ただしこれは初回のみ。日々の差分取り込みは数十秒で、バックグラウンドで走らせておけば済みます。

一度溜めてしまえば、集計はローカルのSQLで完結します。数百万行あっても一瞬で、月次レポートのフル再生成が2.3秒でした。

だからHTMLレポートは保存していません。欲しくなったら都度作り直します。正本はSQLiteと、月次の数字を書き出したMarkdownだけです。

GSCデータは16ヶ月で消える｜溜める最大の理由

これが蓄積する一番の理由かもしれません。

サーチコンソールは16ヶ月より前のデータを保持しません。つまり今日から溜め始めた分だけが、来年の前年同月比になります。

レポートの型は後からいくらでも変えられます。ですがデータは後から取れません。だから「分析するかどうか決めてから」ではなく、決める前に溜め始めた方がいいです。

SQLite蓄積とBigQueryエクスポートの違い

BigQueryのエクスポートと同じものが手に入るわけではありません。持っているデータの行の粒度が別物です。ここは正直に書いておきます。

項目	SQLite蓄積（本記事）	BigQueryエクスポート
1行の意味	その日の合計	1人の1回の行動
データ例	2026-06-15｜google / organic｜セッション312｜CV 2	ユーザーX｜6/15 21:03:12｜page_view｜/blog/記事A
ユーザー単位の追跡	できない	できる
SQLの難易度	簡単	複雑
軽さ	軽い（41MB）	重い
導入の調整コスト	ほぼゼロ	数週間かかることも