AIとペアプロでLooker Studioダッシュボードを3時間で構築した記録
SEGO の月次レビューに毎回30分以上かかっていました。GA4 で訪問者数を確認し、GSC で検索クエリを見て、Supabase で診断件数を集計し、Google Sheets でコンサル契約状況を確認する。4つのツールを行き来する作業を、Looker Studio による一画面集約で月次レビュー時間を10分に短縮できました。
本記事は、AI とペアプロしながら、4データソース(GA4・GSC・Supabase・Google Sheets)を統合した KPI ダッシュボードを3時間で構築した実装記録です。構築途中で遭遇した3つの大きな壁とその解決プロセスも、すべて公開します。同じような計測課題を抱える個人開発者・SaaS運営者・SEO担当者の方の参考になれば幸いです。
本記事の対象読者は、SEO/Webマーケ担当者で開発スキルが浅い方、個人開発者・SaaS運営者で自社プロダクトの計測基盤を作りたい方、スタートアップで KPI ダッシュボードを設計したい方です。実装手順だけでなく、設計判断のプロセスも記録しているため、自社サイトに応用しやすい構成になっています。
なお、本記事で頻出する「ペアプロ」はペアプログラミングの略称で、もともとは2人のエンジニアが1つの画面を見ながら一緒にコードを書く開発手法を指します。
本記事では、これをAI(Claude)と人間で行うスタイルを「AIとペアプロ」と表現しています。人間が何をしたいかを伝え、AIが実装案や問題解決の仮説を提示し、最終判断は人間が行う、という協働の進め方です。
Contents
なぜ Looker Studio で一元化したのか
SEGO のローンチから1ヶ月、月次レビューを行うたびに同じ非効率を繰り返していました。GA4 を開いてユニークユーザー数を確認し、GSC(Google Search Console) を開いてクリック数を確認し、Supabase の SQL Editor を開いて診断件数を集計し、Google Sheets を開いてコンサル契約状況を確認する。4つのツールを行き来するだけで、レビュー前の準備に30分かかっていました。
これは個人開発者・SaaS 運営者あるあるかもしれません。データはバラバラに存在しているのに、それを一画面で見る仕組みがない。結果として「データを見る」より「データを集める」ことに時間を使ってしまう、本末転倒な状態に陥ります。
Looker Studio による一元化を決めた理由は3つあります。
まず、レビュー時間を3分の1に短縮できると確信したこと。次に、同じ画面で複数指標を比較することで、データ間の関連性が見えやすくなること。そして、クライアントサイトの計測支援でも同じ実装を提案できる、自社の実例として活用できることです。
SEGO 自身が SEO/AI検索診断ツールであり、計測の透明性を価値としている以上、自社サイトの計測基盤も整えておかなければ説得力がありません。自社AI診断ツールの実装監査記録でも触れた「数値を出力するツールは、数値の正確性に責任を負う」という哲学の延長線上に、本記事の取り組みがあります。
全体設計(4視点での意思決定プロセス)
実装に入る前に、設計レベルで4つの意思決定を行いました。これを後回しにすると、実装の途中で何度も手戻りが発生します。
4つの意思決定の中で、特に重要なのは 「データソース選定」 でした。Webマーケティングで使う計測ツールは多数ありますが、SEGO の事業特性から「訪問者・検索パフォーマンス・プロダクト利用・営業状況」の4軸が必要と判断しました。それぞれを別ツールで管理しているため、4データソースの統合が必須でした。
KPI 項目は最終的に5つに絞りました。多すぎるとダッシュボードが見にくくなり、少なすぎると意思決定に必要な情報が欠けます。「30秒見ただけで事業状況が分かる」をゴールにすると、5つ前後がバランス良いという結論に至りました。
公開範囲については「完全プライベート」を選択しました。事業運営の数字をすべて含むため、外部公開は不適切です。ただし、本記事のように特定の数字を抜粋して公開することは、build-in-public の文脈で意義があると考えています。
事前準備(30分)
実装に入る前に、以下の準備を行いました。これらを先に整えることで、実装フェーズがスムーズに進みます。
1つ目は コンサル契約管理シートの設計 です。Google Sheets で「契約日」「初回接触日」「お問い合わせ件数」「ステータス」のカラムを準備しました。Looker Studio 側で集計しやすいように、シンプルなテーブル構造にしておくのがコツです。
2つ目は Supabase の読み取り専用ユーザー作成 です。Looker Studio から Supabase に接続する際、本番ユーザーの認証情報を使うのはセキュリティ上避けるべきです。読み取り権限のみを持つ専用ユーザーを SQL で作成し、Looker Studio 接続時にはこのユーザーを使うようにしました。
SQL の実行は Supabase の SQL Editor で行いました。CREATE USER 文と GRANT SELECT 文で必要な権限を付与し、生成したパスワードは安全な場所に保管。Looker Studio 側の接続フォームには、このパスワードを入力する形になります。
データソース接続(1時間)
4つのデータソースを接続していきます。難易度は接続するサービスによって大きく異なります。
GA4 と GSC は Google アカウントでの認証で完結するため、5分程度で接続できます。Looker Studio の「データを追加」から該当のコネクタを選び、自分のアカウントに紐づくプロパティを選ぶだけです。
Google Sheets も同様に、対象のスプレッドシートを選択するだけで接続できます。事前にコンサル契約管理シートを準備しておけば、ここはスムーズに進みます。
問題は Supabase(PostgreSQL)接続 です。Looker Studio 標準の「PostgreSQL コネクタ」を使いますが、ホスト名・ポート・データベース名・ユーザー名・パスワードを正確に入力する必要があります。Supabase の管理画面から接続情報を取得して、Looker Studio に貼り付けます。
ここまでは順調に進みました。しかし、接続が完了して実際にデータを表示しようとした時に、最大の壁にぶつかりました。
AIペアプロで効いた点・詰まった点
本記事で最も価値があるのは、ここから先の「実装途中で遭遇した3つの大きな壁とその解決プロセス」です。AI(Claude)とペアプログラミングしながら、それぞれの壁を乗り越えていきました。
壁1:RLS による「月間診断件数 0」問題
Supabase 接続後、Looker Studio で月間診断件数のスコアカードを作成したところ、表示が「0」のまま。Supabase の SQL Editor で同じクエリを実行すると正しい数値(664件)が返るのに、Looker Studio からは「0」になる。
AI とのペアプロで原因を仮説立てしていきました。「Looker Studio 側のクエリミス?」「接続情報の誤り?」「期間フィルタ?」と次々に検証していき、最終的に Supabase の Row Level Security(RLS) が原因と特定しました。RLS は行レベルでアクセス制御する仕組みで、未認証ユーザーには行が見えない設定になっていたのです。
解決策として、Looker Studio 接続用の専用ユーザーに BYPASSRLS 権限を付与しました。本番運用のセキュリティを維持しつつ、読み取り専用ユーザーだけは RLS をバイパスできる構成にしました。原因特定までに25分、解決自体は5分でした。
この経験から学んだのは、外部ツールから DB に接続する際は、認証・認可の仕組みを最初に確認するべき ということです。Supabase 特有の RLS は、PostgreSQL に慣れている人でも盲点になりやすい仕組みです。
壁2:Metric/Dimension の誤解で「お問い合わせ件数 7」
次の壁は GA4 接続後に発生しました。お問い合わせ件数のスコアカードに「7」と表示される。実際のお問い合わせは1件のはずなのに、何の数字なのか分からない。
AI に聞きながら確認したところ、Event name を Metric に設定していた のが原因でした。GA4 では「Event name」は Dimension(次元)であり、Metric(指標)として扱うと意味不明な集計が行われます。
正しくは、Filter で「Event name = contact_submit」を指定し、Metric には「Event count」を設定する。AI ペアプロでこの設計概念を整理してもらい、修正したところ正しい数値が表示されるようになりました。所要時間は15分です。
Looker Studio の Metric/Dimension の概念は、データ分析の基礎を理解していないと混乱しやすい部分です。AI時代のSEOライティングでも触れた「AIに任せる領域と人間が判断する領域」の話と同じく、仕組みの本質を人間が理解した上で AI に質問する ことが重要だと改めて感じました。
壁3:contact_submit イベントの未発火問題
3つ目の壁はやや構造的です。お問い合わせ件数を計測しようとして、GTM で contact_submit イベントを設定していました。しかし Tag Assistant で確認すると、イベントが発火していない。
原因を調べると、お問い合わせフォームに Googleフォームを使っており、送信完了後に Google 側のサンクスページへ遷移する設計でした。自社サイト内のサンクスページが存在しないため、サンクスページ到達をトリガーにしたイベント発火が機能しない。
選択肢は2つありました。1つ目は、Googleフォーム送信後に自社サイトのサンクスページに戻すよう設計を変更する。2つ目は、お問い合わせ件数の計測を Google Sheets(フォーム回答が記録される)からの直接集計に切り替える。
結論として後者を選びました。理由は「測れないものを測ろうとするコスト」と「設計変更のリスク」を避けるためです。Google Sheets で確実にカウントできる仕組みがあるなら、無理に GA4 イベントで取る必要はない。実装監査記録でも触れた「データがない」と「データが悪い」の区別と同じく、計測設計でも何を測り、何を測らないかの判断が重要です。
サマリーページ構築(1時間)
3つの壁を乗り越えた後は、ダッシュボードのサマリーページ構築です。Looker Studio のスコアカードを5枚配置し、それぞれに対応するデータソースとMetricを設定していきます。
効率化のコツとして、1枚目のスコアカードを丁寧に作り込んでから、Cmd+D(複製)で4枚に増やす 方法を採用しました。サイズ・色・フォントの統一感が保てて、結果として見やすいダッシュボードになります。
期間フィルタは 「Last 30 Days」 をデフォルトに設定。月次レビューに最適化された設計です。年間トレンドを見たい場合は、ダッシュボード上で期間を切り替えられるようにしました。
注意点として、Looker Studio の期間フィルタは データソースごとに別々に設定する必要がある ものと、ダッシュボード全体に一括で適用できる ものがあります。GA4 と GSC は前者、Supabase と Sheets は後者になりやすい傾向があります。混在するダッシュボードでは、どの期間が適用されているかを意識して設計することが大切です。
構築直後のダッシュボード
3時間の構築を経て、SEGO の現在の事業状況が一画面で見える状態になりました。記事公開時点(2026年5月時点)の実数値を、本記事用に公開します。
これらの数値から、いくつかの示唆が見えてきます。686ユニークユーザーのうち、664件が診断を実行しているということは、サイト訪問者の大多数が SEGO の中心機能を使ってくれている証拠です。一方で、お問い合わせは1件、コンサル契約は0件であり、診断完了後のコンバージョンには大きな改善余地があります。
GSC の月間31クリックは、SEO 流入としてはまだ小さい数字です。しかし、SEGO 独自の診断データを継続的に公開していくことで、徐々に検索流入を増やしていける可能性があります。実際、本ブログを通じた SEO 流入は、過去1ヶ月で着実に伸びている実感があります。
これらの数字を一画面で見られるようになったことで、月次レビューの時間は30分から10分に短縮。短縮された20分は、データを「集める」時間ではなく「考える」時間に充てられるようになりました。これがダッシュボード一元化の本質的な価値です。
同じ実装をクライアントサイトでもしたい方へ
本記事で紹介した実装は、SEGO 独自の事情に最適化されていますが、基本構造は中小企業の SEO/Web マーケティング担当者の方にもそのまま応用可能です。
クライアントサイトの計測支援において、4データソース(GA4・GSC・Supabase 等の DB・Google Sheets による契約管理)を統合した KPI ダッシュボードを構築する案件は、計測基盤の重要性が認識されるにつれて増えてきています。「データはあるが、まとめて見られない」状態を解消するだけで、月次レビューの効率と意思決定の質が大きく変わります。
SEO/AI検索対応の戦略策定だけでなく、計測基盤の構築から KPI ダッシュボード設計、月次レビュー運用設計まで含めて支援できる体制が、SEGO のコンサルティングの強みです。SEGO の診断ロジックを理解した上で、自社サイトの計測基盤に応用したい方は、ぜひ無料相談をご利用ください。
AIとペアプロで構築するときのポイントまとめ
AI とペアプロしながら計測基盤を構築する際のポイントを整理します。本記事の経験から導き出した実践的な指針です。
- 事前設計を AI と一緒にやる:データソース選定・KPI項目選定・公開範囲・更新頻度の4視点を明文化してから実装に入る
- エラー時は症状を AI に正確に伝える:「0と表示される」より「Looker Studio で 0、SQL Editor で 664」のように具体的に
- 原因仮説を複数出してから検証する:AI に1つの仮説だけでなく、考えられる複数の仮説を提示してもらう
- セキュリティのトレードオフを意識する:BYPASSRLS のような権限変更は、影響範囲を AI と確認してから実施
- 「測れないものを測ろうとしない」判断:技術的に可能でも、運用コストが高ければ別の方法に切り替える勇気が必要
- 機密情報のマスキング判断:本番DBのパスワード等を AI に共有する際は、マスキングしてから渡す習慣をつける
AI ペアプロの本質は「AI に判断を委ねる」のではなく「AI と一緒に判断する」ことです。最終意思決定は必ず人間が行うことで、効率と品質を両立できます。
AIペアプロでのダッシュボード構築に関するよくある質問
ペアプロとは何ですか
ペアプロはペアプログラミングの略称で、もともとは2人のエンジニアが1つの画面を見ながら一緒にコードを書く開発手法を指します。1人がコードを書き、もう1人が設計や論理を確認することで、品質と速度を両立する手法として広まりました。
本記事の「AIとペアプロ」は、この片方をAI(Claude等)に置き換えた協働スタイルを指します。人間が「何をしたいか」を伝え、AIが実装案や問題解決の仮説を提示し、最終判断は人間が行うという進め方です。AIは膨大な情報を瞬時に提案できる一方、業務の文脈やセキュリティ判断は人間にしかできないため、両者の役割分担が重要になります。
Looker Studio は無料で使えますか
Looker Studio は基本機能を無料で使用できます。本記事で紹介した4データソース統合・5KPIダッシュボード構築も、すべて無料で実装可能です。
エンタープライズ向けの「Looker」とは別製品である点に注意してください。データソースの接続数や更新頻度に制限がある有料プランも存在しますが、個人開発者・中小企業のサイト計測用途であれば無料プランで十分です。
Supabase 以外のデータベースでも同じ実装はできますか
はい、できます。Looker Studio は PostgreSQL・MySQL・BigQuery など主要なデータベースとの接続コネクタを提供しています。
Supabase(PostgreSQL)以外でも、本記事と同様のダッシュボード構築が可能です。ただしデータベースごとに認証・権限設定の仕組みが異なるため、本記事のようにアクセス制御の仕組みを最初に確認することを推奨します。
本記事のダッシュボード構築に必要なスキルレベルは
SQL の基本(SELECT 文・WHERE 句・GROUP BY 句)の理解と、GA4・GSC の基本操作経験があれば、3〜5時間で同様のダッシュボードを構築できます。プログラミングの専門知識は不要です。
本記事で遭遇した3つの壁(RLS・Metric/Dimension・イベント未発火)は、いずれも事前に知識があれば回避可能なものです。AIペアプロを活用すれば、知識ギャップは埋められます。
AIペアプロで詰まったときはどうすれば良いですか
詰まったときの対処として有効なのは、症状を具体的に伝えること、AIから複数の原因仮説を引き出すこと、1つずつ検証して切り分けることの3点です。「動かない」だけでは AI も適切な仮説を提示できません。
「Looker Studio で 0、SQL Editor で 664」のように、どこで何が起きているかを正確に伝えると、AI ペアプロの精度が大きく上がります。
記事で公開されている数値は本物ですか
はい、記事で公開している数値(月間診断件数664・GSC月間クリック数31・月間ユニークユーザー数686等)は、SEGO の2026年5月時点の実数値です。
SEGO は計測の透明性を価値としているため、自社サイトの数値も適切な範囲で公開しています。本記事のように具体的な数字を含む build-in-public 形式の発信は、ブランディング・信頼性向上の観点でも効果があります。詳細な独自データはSEGO 診断データ大公開記事を参照してください。
この記事を書いた人
