はじめに
「また同じようなSQLを書いている……」
WEBコンサルタントとしてEC系クライアントのデータ分析を請け負っていると、レポート作成のたびにBigQueryでSQLを書く作業が発生します。GA4のBigQueryエクスポートデータはevent_paramsのUNNESTが必要だったり、セッションの定義が独特だったりと、毎回それなりの時間がかかる。しかもSQLのちょっとしたミスで数字がズレると、クライアントへの報告前に検証のやり直しが発生して、さらに時間を食います。
正直なところ、コンサルタントの本来の価値は「データから何を読み取り、どう改善するか」の戦略部分にあるはずなのに、実務時間の多くをSQL作成に費やしている現実がありました。
この記事では、Claude Code × BigQuery MCPを導入して、その状況がどう変わったかを体験ベースで書いてみます。
自己紹介
フリーランスのWEBコンサルタントとして、主にEC事業者のデータ分析・改善提案を行っています。GA4のデータをBigQueryに連携し、Looker Studioでダッシュボードを作り、数字に基づいた施策を提案するのが主な仕事です。
クライアントからの依頼は「広告チャネルごとのROASを出してほしい」「先月と今月でどこが変わったか調べてほしい」といったものが多く、そのたびにBigQueryでSQLを書いて集計するという流れでした。
Before:SQL作成に追われる日々
導入前の典型的なワークフローはこんな感じでした。
- クライアントから分析依頼を受ける
- BigQueryコンソールを開いてSQLを書き始める
- GA4のネスト構造に苦戦しながらUNNESTを組む
- 実行してみるとエラー → 修正 → 再実行を繰り返す
- 数字が出てもロジックが正しいか検証する
- ようやくレポートにまとめてクライアントに報告
特にGA4のBigQueryデータは、event_paramsやuser_propertiesがネストされた構造になっているため、単純なSELECT文では済みません。慣れていても1つのクエリに30分〜1時間かかることがあり、複雑な分析になると半日以上費やすこともありました。
💡 補足
GA4のBigQueryエクスポートデータは、イベントパラメータがRECORD型でネストされているため、
UNNEST(event_params)でフラット化する必要があります。この構造に慣れるまでが一つの壁です。
転機:Claude Code × BigQuery MCPとの出会い
Claude Codeには**MCP(Model Context Protocol)**という仕組みがあり、BigQueryに直接接続して、自然言語でSQLを生成・実行できます。
これを知ったとき「本当にそんなうまくいくのか?」と半信半疑でしたが、試してみたら想像以上でした。
After:自然言語で依頼するだけのワークフロー
導入後のワークフローはこう変わりました。
- クライアントから分析依頼を受ける
- Claude Codeにそのまま自然言語で伝える
- 生成されたSQLと結果を確認する
- レポートにまとめてクライアントに報告
ステップ2と3が劇的に短縮されました。以前は1〜2時間かかっていた部分が、数分で完了することもあります。
具体例①:広告チャネル別ROASの算出
あるクライアントから「先月の広告チャネル別のROASが知りたい」という依頼がありました。
以前なら、BigQueryコンソールを開いてsourceとmediumのチャネル分類ロジックを書くだけでも相当な時間がかかりました。購入イベントの売上集計から広告コストとの突合まで含めると、30分以上の作業でした。
Claude Codeには以下のように伝えるだけです。
BigQueryのGA4データから、先月の広告チャネル別(google/cpc, yahoo/cpc, meta/cpcなど)の
セッション数、コンバージョン数、売上合計を集計してください。
テーブルはbeeracle.beeracle_mart.mart_channel_performanceを使ってください。
約30秒でSQLが生成され、実行結果まで返ってきました。あとはこの数字に広告費データを合わせてROASを計算するだけです。
具体例②:コホート分析
別の案件で「初回購入月ごとのリピート状況を可視化したい」という依頼がありました。
コホート分析のSQLは正直かなり複雑です。ユーザーごとの初回購入月を特定し、その後の各月の購入有無をピボットテーブルのように展開する必要があります。手書きなら2時間は覚悟していた内容です。
Claude Codeに依頼すると、CTEを使った段階的なクエリを組み立ててくれました。初回購入月の特定 → 月ごとの再購入フラグ付与 → コホートテーブルへの整形、という流れを一度で生成してくれたのは驚きました。
⚠️ 注意
生成されたSQLをそのまま信用するのは危険です。特にコホート分析のような複雑なクエリは、少数のテストデータで結果を検証してから本番に使うことをおすすめします。
Claude Codeが得意なこと・苦手なこと
半年ほど使ってみた正直な感想です。
得意なこと
- GA4のネスト構造の処理:
UNNESTやevent_paramsからの値抽出はほぼ間違えない - 定型的な集計クエリ: チャネル別・デバイス別・期間比較などはスムーズ
- CTEを使った段階的なクエリ構築: 複雑なロジックも読みやすいSQLに整理してくれる
- 既存テーブルのスキーマ理解: MCPでスキーマを読み取り、カラム名を正確に使ってくれる
苦手なこと
- ビジネス固有のロジック: クライアント独自のKPI定義や特殊な計算ロジックは、事前に説明が必要
- データの異常値への気づき: 数字が明らかにおかしいときに自発的に指摘してくれるわけではない
- パフォーマンス最適化: 動くSQLは書いてくれるが、コスト効率の良いクエリかは自分で判断する必要がある
万能ではないですが、「80%の作業を自動化して、残り20%の重要な部分に集中する」という使い方が現実的です。
コンサルティング業務への影響
SQL作成にかかる時間が大幅に減ったことで、一番変わったのはクライアントとの対話に使える時間が増えたことです。
以前は「データを出すだけで精一杯」になりがちだったのが、今は数字の背景にある仮説を考えたり、改善施策を深掘りしたりする余裕ができました。結果として、クライアントから「分析だけじゃなくて戦略の相談もしたい」と言ってもらえることが増えた実感があります。
また、対応できる案件数にも余裕が出ました。以前は月3〜4件が限界だったクライアント数も、少し増やせるようになっています。
AIツール導入を検討しているコンサルタントへ
もし同じようにSQL作成やデータ集計に時間を取られているなら、Claude Code × BigQuery MCPは試す価値があると思います。
いくつかアドバイスを挙げるなら:
- 最初は簡単なクエリから始める — いきなり複雑な分析を任せるのではなく、日常的なチャネル別集計や期間比較から試してみる
- 結果は毎回検証する — AIが生成したSQLを盲目的に信頼しない。特に初回は手動の結果と突合する
- プロンプトにテーブル名とカラム名を含める — 曖昧な指示より、具体的なテーブル情報を渡した方が精度が高い
- ビジネスロジックは明文化しておく — クライアント固有のKPI定義やセグメント条件は、CLAUDE.mdなどにまとめておくと再利用しやすい
ツールはあくまで手段です。大切なのは、浮いた時間をクライアントへの価値提供に再投資することだと思います。
まとめ
Claude Code × BigQuery MCPを導入したことで、SQL作成にかかる時間を大幅に削減できました。コンサルタントとしての本来の仕事――データを読み解き、戦略を提案すること――に集中できるようになりました。
技術的なハードルは思ったより低く、BigQueryのMCPセットアップさえ済めばすぐに使い始められます。データ分析に時間を取られているフリーランスの方には、一度試してみることをおすすめします。