Claude in Chromeレビュー第3弾！BigQueryでのGA4データ分析をClaude Opus 4.6に丸投げしてみた
こんにちは！Rimo合同会社で海外展開/PLGを中心に担当している吉澤です。
Claude in Chromeレビューシリーズ第3弾です。今回は、BigQuery上のGA4イベントデータを使ったユーザーリテンション分析をClaudeにお願いしてみました。
結構うまくいったので、指示の仕方やアウトプットイメージを本記事で紹介します。
また、この実験をした当日、ちょうどClaude Opus 4.6のリリースがあったので、Opus 4.6で実行をしています。本記事を読んでいただくと、Opus 4.6の実力もイメージが湧くと思います。
疑問：「Rimoを登録したユーザーに、最初にどの機能を触ってもらうのがいいのか？」
きっかけは、海外事業の進捗について全社のDemoDayで報告していたときのこと。とあるメンバーから、こんな質問をもらいました。
「signupした後に録音機能を使ったユーザーと、ファイルアップロードを使ったユーザーで、定着率に差はあるんですか？」
…良い質問です。PLGを進める上で、どの機能が最初のアハ体験につながっているかは非常に重要な問いです。それによって、signup後にどの機能をまずおすすめするのがいいのか、体験設計が変わってきます。
過去の実験からファイルアップロードをメインでおすすめしていたのですが、直近のデータは持っておらず、その場では正確な回答ができませんでした。
GA4のデータはBigQueryにエクスポートされているので、やろうと思えば分析できます。ただ、SQLを書いて、テーブル構造を確認して、イベント名を調べて…とやっていると、それだけで数時間コースです。
そこで、Claude in Chromeに丸ごとお任せしてみることにしました。
実験：Claudeにリテンション分析をやってもらう
以前の反省から、Claude自身に適切なテーブル・カラム名を探してもらうことはできるが、それだと時間がかかったり、最終的に的外れな結果になることもあることを学んでいました。
そのため、今回はできるだけ調べてほしい対象を具体的に指示してみました。
BigQuery上の analytics_243845147 データセットを使って、signup後に mic_recording（録音）を実行したユーザーが再度イベントを発生させる率を調べる
同様に、signup後に upload_ga4（ファイルアップロード）を実行したユーザーについても調べる
ステップ1：テーブル構造の把握とイベント確認
Claudeはまず BigQueryコンソール上でデータセットを開き、GA4の events_* テーブルのスキーマを確認。続いて、指定したイベント名が実際にデータに存在するかを確認するクエリを自ら書いて実行しました。signup や mic_recording、upload_ga4 のイベント件数を一覧で出してくれて、データの全体感をまず掴んでくれます。
ステップ2：リテンション分析の実行…と、Claudeの自主判断
Claudeは CTEを使った分析クエリを自力で設計し、実行しました。ロジックはこうです。
signupしたユーザーを特定
その後に対象アクションを実行したユーザーを抽出
そのアクション以降にイベントを発生させたかどうかで「再訪」を判定
様子を確認したところ、最初の出力では、どちらのイベントのretention_rateも非常に高い結果になっていました（97.85%と100%）。
これは正しいのだろうか、、？と疑問に思っていたところ、claudeはその場では最終の回答を返さず、別のSQLを実行し始めたので、放置をしていました。
数分後に出た回答が以下です。
なんと、Claudeは最初の定義でのリテンション率が高すぎることに自ら疑問を持ち、
「この定義だと意味のある分析にならない」と判断し、「別の日に再度イベントを発生させた」という、より厳密な定義を追加提案してくれたのです。
これは正直驚きました。単にSQLを書くだけでなく、結果の妥当性を自分で評価して、分析の定義そのものを改善してくれる。データアナリストと壁打ちしているような体験です。
ステップ3：「ユーザー数少なくないですか？」からの深掘り
改善された定義で結果が出たものの、今度は別の問題に気づきました。upload_ga4 の対象ユーザーがわずか数百人しかいません。全期間のデータなのに少なすぎる。
Claudeに「対象期間を調べてほしい」と伝えたところ、すぐにイベントの月別分布を調査するクエリを実行。すると、upload_ga4 イベントは特定の日時を最後に記録が途切れていたことが判明しました。
ステップ4：イベント名リネームの発見
Claudeはさらに自発的に、upload を含む全イベント名を洗い出すクエリを実行。その結果、特定の日から upload_with_file_data という新しいイベント名が登場していることを発見しました。
つまり、途中でイベント名のリネームが行われていたのです。こういった「現場の事情」はドキュメントにも書かれていないので、データを見なければわからない類のものです。Claudeがデータドリブンに発見してくれたのは助かりました。
ステップ5：正しいイベント名で再分析
upload_with_file_data を使って改めてリテンション分析を実行したところ、対象ユーザーが現場感覚と遜色のない数に増え、信頼性のある分析になりました。
結果
最終的に、signup後に録音機能を使ったユーザーと、ファイルアップロードを使ったユーザーのリテンション率はほぼ同等という結果が得られました。
どちらの入口から入っても定着率に大きな差がないことがわかったのは、プロダクト戦略を考える上で重要なインサイトです。
また、今回は最初の指示のスコープを絞ったことが功を奏し、最初の出力はわずか11分ほどで得ることができ、その後の修正等もスピーディにやりとりできました。
うまくいったこと → 評価：★★★★☆（かなり良い）
分析の「思考プロセス」を一緒に進めてくれたことが最大の価値でした。 単にSQLを生成するだけなら他のツールでもできますが、今回Claudeがやってくれたのはそれ以上のことです。
結果の妥当性を自ら評価し、「この定義だとリテンション率が高すぎる」と自主的に軌道修正してくれた
「別の日に再訪」というより意味のある定義を自ら提案・実装してくれた
イベント名のリネームという隠れた問題を、データから自発的に発見してくれた
★5ではなく★4にした理由は、BigQueryのUIナビゲーションで少しもたつく場面があったことです。メニューが意図せず開いてしまったり、クエリ実行ボタンを押すのに手間取る場面がありました。ただ、最終的にはすべて完了しているので実用上の問題はありません。
結論：Claude in Chromeはデータ分析の「壁打ち相手」として優秀
今回の実験で強く感じたのは、Claude in ChromeはSQLを書いてくれるツールではなく、データ分析の思考プロセスそのものを一緒に進めてくれるパートナーだということです。
DemoDayでもらった質問から、ものの数十分でインサイトが得られたのは、正直かなり衝撃的でした。SQLが書けない人でも、「こういうことを調べたい」と日本語で伝えるだけで分析が完了する。しかも結果がおかしければ自分で気づいて修正してくれる。
次回は、この分析結果を元にした施策の検討もClaudeに手伝ってもらおうと思います。
それでは、次の実験でお会いしましょう！