Looker (Google Cloud) の設計思想 — LookML で BI を「コード化」する

Looker と、他の BI ツールの違い

Looker は Google Cloud が買収した BI (Business Intelligence) プラットフォーム。Tableau や Power BI、Metabase と比較したときの決定的な違いは以下です。

	Looker	Tableau / Metabase
集計定義	LookML (Git 管理されるコード)	GUI 操作、ダッシュボードごとに個別定義
データモデルの再利用	全ダッシュボード・レポートで共通	ダッシュボード毎に重複実装しがち
バージョン管理	Git	Workbook ファイル、差分が追えない
計算は DB 側で実行 (ELT)	SQL をリアルタイム生成、DB で集計	一部は BI 側でメモリ処理
ユーザー層	データアナリスト + エンジニア	ビジネスユーザー中心

要は「BI をコードで管理する」のが Looker の中核です。見た目のダッシュボードだけでなく、「売上 = SUM(amount) WHERE status = ‘paid’」といった指標定義そのものを LookML というコードで一元管理します。

LookML の最小例

LookML ファイル (.lkml / .lookml.yml) は Git で管理されます。

# model: sales.model.lkml
connection: "prod_bigquery"
include: "/views/**/*.view.lkml"

explore: orders {
  join: users {
    sql_on: ${orders.user_id} = ${users.id} ;;
    relationship: many_to_one
  }
}

# view: orders.view.lkml
view: orders {
  sql_table_name: analytics.orders ;;

  dimension: id { primary_key: yes; type: number; sql: ${TABLE}.id ;; }
  dimension: created_at { type: time; sql: ${TABLE}.created_at ;; }
  dimension: status { type: string; sql: ${TABLE}.status ;; }
  dimension: amount { type: number; sql: ${TABLE}.amount ;; }

  measure: total_amount {
    type: sum
    sql: ${amount} ;;
    filters: [status: "paid"]  # 「売上」の定義をここに集約
  }
  measure: order_count {
    type: count
  }
}

これで「売上 = status=paid の amount 合計」という定義が組織内の唯一の真実になります。ダッシュボードはこの measure: total_amount を参照するだけで良い。

いつ Looker を選ぶか / 選ばないか

選ぶべき

• 指標定義を Git 管理したい (監査・レビュー・テスト容易性)
• データアナリスト + エンジニア の組織 (LookML を書ける人がいる)
• BigQuery / Snowflake / Redshift 中心のモダン分析基盤
• 複数チームでダッシュボードが乱立しがち

選ばないほうがよい

• ビジネスユーザーだけで運用したい (LookML の学習コストが高い)
• データ量が小さく、BI 投資の ROI が見えない
• オンプレ DB 中心 (Looker はクラウド DB との相性最高)
• 無料でまずは使いたい → Looker Studio か Metabase

Looker Studio との棲み分け

同じ Google Cloud の BI に Looker Studio (旧 Data Studio) もあります。

	Looker	Looker Studio
価格	有料 (ユーザー課金)	無料 (Pro 版は有料)
指標定義	LookML (コード)	GUI
バージョン管理	Git	無し
対象ユーザー	エンジニア + アナリスト	ビジネスユーザー
用途	全社のデータ基盤 + 分析レポート	個別のダッシュボード、外部共有レポート

役割分担のパターン:

• Looker: 指標定義の正本、重要なダッシュボード、全社 KPI
• Looker Studio: 外部共有用のレポート、ちょっとした集計、無料で済む範囲

実運用の落とし穴

1. LookML の設計が属人化する

1 人のアナリストだけが LookML を書けると、その人が辞めると保守崩壊。複数人レビュー文化、Git PR での LookML 変更レビューが必須。

2. sql_always_where の濫用

特定グループだけに見せたい列・行の制御を sql_always_where に書き始めると LookML が複雑化し、クエリパフォーマンスも低下。Row-Level Security は DB 側 (BigQuery の Row Access Policy) で実現する方が健全。

3. ダッシュボードの重複増殖

「XXX チーム用ダッシュボード」が次々増えて、結局は誰も見なくなる。ダッシュボード棚卸しの定例運用 (四半期に一度、使われていないものを削除)。

4. BigQuery スロット消費

Looker は SQL を DB 側で実行するので、人気ダッシュボードは BigQuery スロットを食う。Persistent Derived Table (PDT) や BI Engine で結果キャッシュを活用。

まとめ

• Looker の価値は「BI をコードで管理」+ LookML による指標の一元化
• 規模の大きい組織・データアナリストがいるチームには強力
• 小規模・無料で始めたいなら Looker Studio か Metabase から
• 両方を適材適所で使い分けるのが現実解