Looker Studio

解決する課題

• BigQuery やスプレッドシートのデータを、専用ツールの導入や費用をかけずに可視化したい
• 作成したレポートを、メール添付ではなくURL や閲覧権限で共有し、常に最新の数字を見せたい
• SQL を書けない担当者でも、ドラッグ操作だけでグラフや表を組み立てられる環境がほしい
• 複数のデータソース（広告・分析・データベースなど）を1 枚のダッシュボードに集約して全体像を把握したい

主要概念と用語

• レポート: グラフ・表・スコアカードなどを並べた可視化の画面。共有や定期配信の単位になる
• データソース: レポートが参照するデータへの接続定義。BigQuery、Google スプレッドシート、Google アナリティクス、各種 SQL データベースなどへつなぐ
• コネクタ: データソースへ接続するための部品。Google 純正のコネクタに加え、サードパーティ製のパートナーコネクタもある
• ディメンション / 指標: ディメンションは「いつ・どこで」のような切り口、指標は「合計・件数・平均」のような集計値。レポート上でドラッグして組み合わせる
• 計算フィールド: 既存の列から数式で新しい列を作る機能。データソース側にもチャート側にも定義できる
• ライブ接続とエクストラクト: 既定では接続先へ都度クエリを発行するライブ接続。一方、データの一部を抜き出して高速化するエクストラクト（抽出）も選べる
• Looker Studio Pro: チーム管理やサポート、コンテンツ管理機能を強化した有償エディション。無償版に対し組織利用向けの管理性を加える

仕様・制限・クォータ

• 基本機能は無償で利用でき、組織向けの管理機能を求める場合に有償の Looker Studio Pro を選ぶ、という二段構えが基本
• Looker Studio 自身は大量のデータを自前で保持しない。クエリは接続先（BigQuery など）で実行され、結果が一定時間キャッシュされる。そのため性能とコストの多くは接続先側に依存する
• レポートあたりのデータソース数や、1 ページに置けるグラフ数、抽出（エクストラクト）データのサイズなどには上限がある。具体的な数値は変動しうるため、断定せず公式ドキュメントで都度確認する
• 接続先が BigQuery の場合、レポートを開くたびにクエリが走るため、スキャン量がそのまま費用に直結しうる点に注意する

内部の仕組み

Looker Studio の中核は、レポートでの操作を接続先データソースへのクエリに変換して描画する点にあります。データを Looker Studio 側へ大量に複製するのではなく、表示のたびに接続先へ問い合わせるライブ接続が既定です。これにより、利用者は常に接続先の最新状態に近いデータを見られます。

接続先への負荷とコストを抑えるため、Looker Studio はクエリ結果をキャッシュします。同じ条件のグラフを短時間に何度も開いても、キャッシュが有効な間は接続先へ再問い合わせしません。キャッシュの鮮度と接続先への負荷はトレードオフの関係にあり、データの更新頻度に合わせて考えます。

さらに高速化が必要な場合は、データの一部を抜き出して保持する**エクストラクト（抽出）**を使えます。これは接続先への都度クエリを避け、抽出済みデータに対して描画するため応答が速くなりますが、抽出時点のスナップショットになる点に注意が必要です。

設計パターン / ベストプラクティス

• BigQuery を直接参照するレポートでは、事前に集計したテーブルやビューを接続先に用意し、レポートからは軽い結果を読むだけにする。生のファクトテーブルを毎回スキャンさせない
• フィルタや日付範囲の既定値を絞り、1 枚に大量のグラフを詰め込まない。グラフの数だけ接続先へのクエリが増える
• 計算ロジックはデータソース側の計算フィールドに寄せ、同じ計算を複数のグラフで重複定義しない
• 複数レポートで使う接続は埋め込みデータソースではなく再利用可能なデータソースとして共有し、定義の重複を避ける
• 全社で数値の一貫性が重要な指標は、Looker Studio だけで作り込むのではなく、接続先（BigQuery など）や上位のセマンティックレイヤーで定義することを検討する

運用・監視

• レポートの表示が遅いときは、Looker Studio ではなく接続先データソースのクエリ性能を疑うのが基本。集計済みテーブルの用意やキャッシュ活用、グラフの粒度見直しで対処する
• BigQuery 接続では、どのレポートがどれだけスキャンしているかを BigQuery 側のジョブ履歴やコスト管理機能で把握し、想定外のスキャンを早期に検知する
• 共有設定を定期的に棚卸しし、「リンクを知っている全員」など広すぎる公開範囲が残っていないかを確認する
• 定期配信（スケジュール送信）の失敗や、コネクタ側の仕様変更による表示崩れを監視する

コスト

セキュリティ

• レポートやデータソースの共有は、Google アカウントの閲覧・編集権限で制御する。組織外への共有可否は管理ポリシーで制限できる
• BigQuery などへの接続では、接続に使う認証情報の扱いが重要。レポート閲覧者の権限で実行するか、所有者の権限で実行するかの設定を理解し、意図しないデータ露出を避ける
• 「リンクを知っている全員が閲覧可」のような公開共有は便利だが、機密データでは行レベルの分離ができないため慎重に扱う
• 組織での統制を強めたい場合は Looker Studio Pro のチーム・コンテンツ管理機能を使い、アクセス範囲とガバナンスを一元管理する

関連サービス・比較

ハンズオン / CLI例

# Looker Studio のレポート作成はブラウザの GUI が中心で、
# 日常操作に gcloud は使いません。ここでは前提となる
# 接続先（BigQuery）側の準備を bq / gcloud の例で示します。

# 1) レポートが参照する集計済みデータセットを BigQuery に用意する
bq --location=asia-northeast1 mk --dataset MY_PROJECT:reporting

# 2) 重いファクトテーブルを毎回スキャンさせないため、
#    集計済みビューを作っておき、レポートからはこれを参照する
bq mk --use_legacy_sql=false \
  --view='SELECT DATE(created_at) AS day, COUNT(*) AS orders
          FROM `MY_PROJECT.sales.orders`
          GROUP BY day' \
  MY_PROJECT:reporting.daily_orders

# 3) レポートで使う閲覧用サービスアカウントに最小権限を付与する
gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:looker-studio@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/bigquery.dataViewer"

gcloud projects add-iam-policy-binding MY_PROJECT \
  --member="serviceAccount:looker-studio@MY_PROJECT.iam.gserviceaccount.com" \
  --role="roles/bigquery.jobUser"

# 4) Looker Studio で BigQuery コネクタから reporting.daily_orders を選び、
#    集計済みデータを参照する軽いレポートを作成する。