looker-studio-bigquery

Looker Studio + BigQuery

実際の成果物が BigQuery を基盤とする、信頼できるステークホルダー向けレポート一式 である場合は、このスキルを使用してください。

looker-studio-bigquery は、次のレポートレイヤーを担当します。

• PM／運用チーム向け KPI レビューボード
• BigQuery ですでにモデリングされている、プロダクトファネル、継続率、ロールアウトのダッシュボード
• マーケティング／GTM のチャネルおよび収益レポート
• ゲーム／ライブオペレーション／ビジネステレメトリーのレビューボード
• キュレートされたデータに対する Looker Studio の更新、コスト、対象者、エクスポート引き継ぎの判断

必要に応じて、まず次のサポートドキュメントを確認してください。

• references/intake-packets-and-route-outs.md
• references/modeling-refresh-and-cost.md
• references/dashboard-delivery-checklist.md
• references/modes-and-routing.md

このスキルを使用する場合

• ユーザーが明示的に Looker Studio／Data Studio + BigQuery の支援を求めている場合。
• データがすでに BigQuery に存在する場合、またはダッシュボードがキュレートされた BigQuery のテーブル／ビューを明らかに基盤としている場合。
• 主な作業が、ダッシュボードの構成、更新／コストの設計、対象者に応じた提供、またはエクスポート可能なレポートである場合。
• KPI ボード、PM／運用レビュー、マーケティング／GTM レポート、プロダクト概要ダッシュボード、またはゲーム／ビジネステレメトリーのダッシュボードに関する依頼の場合。
• 主なリスクが、SQL の解釈だけではなく、ダッシュボードへの信頼、更新設計、または複数の対象者が混在することによる肥大化である場合。

このスキルを使用しない場合

• 主な作業が、KPI が変動した理由やデータセットの意味の説明である場合 → data-analysis を使用してください
• 主な作業が、メトリクス／イベント全体にわたる異常の反復的な探索や、再利用可能なルールによるスキャンである場合 → pattern-detection を使用してください
• 主な作業が、テレメトリーの信頼性、アラート、または計測範囲である場合 → monitoring-observability を使用してください
• 主な作業が、BI／セマンティックプラットフォーム全体の選定である場合 → survey を使用してください
• 主な作業が、広範な GCP のブートストラップ／デプロイ作業である場合 → まず該当するインフラスキルに引き継いでください

手順

Step 1: チャートについて話す前に、主要なパケットを 1 つ選ぶ

依頼の内容を 1 つのパケットに整理します。

looker_studio_bigquery_packet:
  primary_packet: dashboard-spec | slow-dashboard | refresh-shape | audience-split | exec-handoff
  audience: executive | pm-ops | product-analytics | marketing-gtm | game-liveops | mixed | unknown
  source_shape: curated-table | view | scheduled-query-output | materialized-view | mixed | unknown
  freshness_need: near-real-time | hourly | daily | weekly | unknown
  trust_risk: low | medium | high

primary_packet を 1 つだけ選びます。

• dashboard-spec — ステークホルダー向けダッシュボードを作成または再設計する
• slow-dashboard — 遅い、高コスト、または不安定なダッシュボードを改善する
• refresh-shape — ライブ、スケジュール実行、スナップショット、BI Engine のいずれにするか決める
• audience-split — 1 つの過負荷なレポートを、対象者ごとの成果物に分割する
• exec-handoff — コメントや承認のためのエクスポート／シート／スライドへの引き継ぎを含む、シンプルなダッシュボードを作成する

2 つのパケットが候補に挙がる場合は、まず提供上の最大のリスクを取り除く方を選びます。

Step 2: 意図的にダッシュボードをシンプルに保つ

セクションを設計する前に、次の点に答えます。

1. このダッシュボードが支援するレビューの習慣や意思決定は何ですか？
2. 信頼できる情報源となるテーブル／ビューは何ですか？
3. レポートレベルの数式ではなく、BigQuery に置くべきメトリクスはどれですか？
4. データの鮮度、信頼性チェック、注意事項の担当者は誰ですか？

依頼が依然として未加工のファクトテーブル、不安定な結合、または曖昧なメトリクス定義に依存している場合は、その旨を伝え、ダッシュボードを仕上げる前に上流のモデリング作業を進めてもらいます。

Step 3: 一般論の BI 解説ではなく、パケットを具体化する

references/intake-packets-and-route-outs.md のパケットのガイダンスを使用します。

パケットに最低限必要な内容：

• dashboard-spec → ページ構成、KPI セット、チャートと質問の対応関係、BigQuery の契約
• slow-dashboard → ボトルネックの優先順位、上流での事前計算の選択肢、最短で実施できる修正 1 つ
• refresh-shape → 実際のレビュー頻度に合わせた、ライブ、スケジュール実行、スナップショットの選択
• audience-split → ステークホルダーのレビュー習慣、信頼性の要件、詳細度に基づく成果物の分割
• exec-handoff → シンプルなダッシュボードと、Connected Sheets／エクスポート／スライドへの引き継ぎ計画

一般的なチャートの寄せ集めで回答しないでください。

Step 4: 提供用の概要を返す

次の構成を使用します。

# Looker Studio Delivery Brief

## Primary packet
- Packet: ...
- Audience: ...
- Confidence: high | medium | low

## Review ritual and question
- Ritual: ...
- Decisions supported: ...

## BigQuery contract
- Source table/view: ...
- Grain: ...
- Core dimensions: ...
- Core metrics: ...
- Freshness / owner / caveats: ...

## Recommended dashboard shape
- Pages or sections: ...
- KPI and chart-to-question mapping: ...
- Filters / drilldowns / export needs: ...

## Refresh, cost, and trust plan
- Preferred refresh shape: ...
- Heavy logic to move upstream: ...
- Trust or caveat notes: ...

## Recommended next artifact
- Choose one: dashboard spec | SQL handoff list | refresh decision memo | audience split brief | export / Connected Sheets handoff

## Route-outs
- Upstream modeling / KPI interpretation / anomaly hunting / observability / platform comparison as needed

Step 5: 適切に振り分ける

• データセットの分析や KPI の説明が必要な場合は、data-analysis に振り分けます。
• 繰り返し発生する異常の検出や再利用可能なメトリクスルールが必要な場合は、pattern-detection に振り分けます。
• テレメトリーのカバレッジ、アラート、計装への信頼性が必要な場合は、monitoring-observability に振り分けます。
• より大規模な BI やセマンティックプラットフォームの選定が必要な場合は、survey に振り分けます。

例

例 1：PM／オペレーション向けダッシュボードの構築

入力

BigQuery の週次 KPI を使って、経営陣向けの PM レビューダッシュボードを Looker Studio で作成してください。

出力の概要

• パケット：dashboard-spec
• ダッシュボードの構成：KPI スコアカード＋メイントレンド＋ドリルダウン 1 つ＋担当者／データ鮮度に関する注記
• 次の成果物：dashboard spec

例 2：表示が遅いマーケティングダッシュボード

入力

マーケティングファネルのダッシュボードは、フィルターを操作するたびに遅く、コストもかかりすぎます。

出力の概要

• パケット：slow-dashboard または refresh-shape
• 主な推奨事項：スタイルを変更する前に、繰り返し使うファネルのロジックを BigQuery で事前計算します
• 次の成果物：refresh decision memo または SQL handoff list

例 3：対象者が混在するダッシュボード

入力

1 つのダッシュボードで経営陣、PM、グロース、ライブ運用のすべてに対応しようとしています。継ぎはぎを続けるべきでしょうか？

出力の概要

• パケット：audience-split
• 推奨事項：意思決定の習慣と信頼性の要件に応じて成果物を分けます
• 次の成果物：audience split brief

例 4：コメントを付けやすい引き継ぎ

入力

経営陣は週次ダッシュボードを求めていますが、レビューの前に Sheets で数値に注釈を付けています。

出力の概要

• パケット：exec-handoff
• 推奨事項：ダッシュボードはシンプルに保ち、エクスポート／Connected Sheets の引き継ぎを明確に定義します
• 次の成果物：export / Connected Sheets handoff

ベストプラクティス

1. グラフの種類ではなく、現在のパケットから始めます。
2. 可能な限り、複雑なロジックは BigQuery に置きます。
3. すべてをリアルタイムにするのではなく、実際のレビューの習慣に合わせてデータ鮮度を設定します。
4. 1 つの成果物に相容れないニーズが集まり続ける場合は、対象者ごとにダッシュボードを分けます。
5. 重要なダッシュボードの引き継ぎには、担当者、注意事項、信頼性に関する取り決めを明記します。
6. このスキルに分析、異常の調査、可観測性を詰め込むのではなく、適切な振り分けを優先します。

参考資料

• BigQuery：Looker Studio でデータを可視化する
• BigQuery のスケジュールされたクエリ
• BigQuery のマテリアライズドビュー
• BigQuery BI Engine
• BigQuery 用 Connected Sheets