Looker 入門 ── LookML がデータ活用の「自由と統制の二択」を超える仕組み

「Looker = BI ツール」という理解は半分しか合っていません。残り半分は「セマンティックレイヤー基盤」としての顔があり、ここを掴まないと「なぜダッシュボードツールにこの値段がつくのか」が腹落ちしません。

本記事では、LookML の仕組みと Explore による自由探索の設計を軸に、データポータル (旧 Looker Studio、2026 年 4 月にリブランド) / Tableau との位置づけの違いと組織導入の現実的な条件を整理します。Looker の設計思想を掴むことで、「ダッシュボードを作るツール」か「セマンティックレイヤーへの投資」かを自分の組織の文脈で判断しましょう。

データ活用が組織に広まらない理由 ── 自由か統制かという二択の限界

データ活用を組織全体に広げようとすると、ほぼ必ずぶつかる構造的な二択があります。

業務部門に自由を渡す方向を選ぶと、部署ごとに独自のダッシュボードが乱立し始めます。「先月の売上」という同じ言葉が、部署によって「受注ベース」「請求ベース」「入金ベース」のいずれかを指す状態になります。レポートを横並びにしたとき数字が合わず、どの数値を信じればよいか誰も分からなくなります。

逆に IT 部門やデータ部門が指標定義を厳密に管理する方向を選ぶと、今度は業務部門からの依頼が集中します。「この切り口で見たい」という要望のたびにチケットを起票し、待ち時間が発生します。業務スピードが落ち、最終的に「やっぱり自分たちで Excel を作る」という逆戻りが起きます。

これは ツール選びの問題ではなく、設計レベルの問題 だと位置付けるのが正確です。どのダッシュボードツールを使っても、指標の定義を「どこで誰が管理するか」という問いに答えを持たない限り、同じ二択に戻り続けます。

Looker のこの二択への答えは、LookML というレイヤーの設計に集約されています。

LookML ── 指標を一度書いて全員で使い回すコード

LookML (Looker Modeling Language) は、SQL データベースの上に構築するセマンティックデータモデルを記述するための DSL (ドメイン固有言語) です。SQL そのものではなく、Looker が SQL を生成するための設計図を書く専用言語だと捉えると位置づけが掴みやすくなります。公式ドキュメントは LookML の役割を次のように説明しています。

you can use LookML to describe dimensions, aggregates, calculations, and data relationships in your SQL database. Looker uses a model that is written in LookML to construct SQL queries against a particular database.

出典: Google Cloud (Looker) — What is LookML?

この DRY (Do not Repeat Yourself) 原則が、二択問題への直接的な回答になっています。指標の定義は LookML ファイルに書きます。そのファイルは Git でバージョン管理され、変更履歴が残り、レビューも通せます。

LookML には 3 つの中心概念があります。

• model: データベースへの接続と、クエリ起点となる Explore の集合を定義する
• view: テーブル構造とフィールド定義 (dimension / measure) を記述する
• explore: ユーザーがクエリを組み立てる起点となるエントリポイント

以下は model ファイルの最小骨格です (公式ドキュメントのサンプルを参考にした構成です。実環境での動作は connection 名やファイルパスに依存するため、そのまま流用する際はご確認ください)。

# model ファイル (.model.lkml)
connection: order_database
include: "*.view.lkml"  # 例: 全 view ファイルを取り込む

explore: orders {
  join: customers {
    sql_on: ${orders.customer_id} = ${customers.id} ;;
  }
}

次に view ファイルを見ていきます。dimension はテーブルの列や計算値を、measure は集計値 (COUNT / SUM など) を定義します。

# view ファイル (.view.lkml)
view: orders {
  dimension: id {
    primary_key: yes
    type: number
    sql: ${TABLE}.id ;;
  }

  dimension: customer_id {
    sql: ${TABLE}.customer_id ;;
  }

  dimension: amount {
    type: number
    sql: ${TABLE}.amount ;;
  }

  measure: count {
    type: count
    sql: ${id} ;;
  }

  measure: total_amount {
    type: sum
    sql: ${amount} ;;
  }
}

出典: Google Cloud (Looker) — LookML terms and concepts

この 2 ファイルで「注文数」と「合計金額」という指標が組織の共有定義になります。SQL を書ける担当者が一度定義すれば、SQL を書けない全員がその指標を Explore から参照できます。これが LookML の非対称な分業の仕組みです。

Explore ── 業務部門が SQL なしで自分で答えを出せる画面

Explore は Looker の UI 上でユーザーがクエリを組み立てる画面です。LookML で定義した dimension と measure が「フィールドピッカー」として左側に一覧表示されます。

ユーザーはフィールドを選択し、絞り込み条件を設定し、グラフ種別を切り替えます。SQL を書く必要はありません。Looker が LookML の定義を読み取り、SQL クエリを自動生成してデータベースに送信します。

重要なのは 「自由に探索できるが、数字の定義はセマンティックレイヤーが固定している」 という構造です。業務部門は自分のペースで切り口を変えながらデータを見られます。一方で「売上」の定義を勝手に変えることはできません。LookML に定義された measure を使う限り、全員が同じ計算式の結果を見ることになります。

この設計が、冒頭で整理した「自由か統制か」の二択を超えます。自由の範囲 (どの切り口で見るか) と、統制の対象 (指標の定義そのもの) を明確に分離しているからです。

Explore の挙動の詳細は公式ドキュメントに記載されています。

出典: Google Cloud (Looker) — Viewing and interacting with Explores

データポータル・Tableau と何が違うか ── 名称の混同と設計思想の差

まず名称の整理から始めます。データポータル は 2026 年 4 月のリブランドにより旧 Looker Studio から改称された Google Cloud のレポートツールです。

Looker (エンタープライズ BI) とデータポータルは別製品です。 どちらも Google Cloud のサービスですが、設計目的が異なります。Looker は LookML によるセマンティックレイヤーが中心にあります。データポータルはセマンティックレイヤーを持たず、レポートごとに個別にデータソース接続を設定します。

以下の比較表で主な違いを整理します。

出典: Google Cloud (Looker) — Looker と データポータル の比較

Tableau については、2025.2 以降に Tableau Semantics という指標レイヤー相当の機能が導入されています。また Tableau Pulse はメトリクスの自動モニタリングに近い仕組みです。指標をカタログ化して組織内で再利用できる点では LookML と共通しますが、これらは GUI ベースの設定が中心であり、LookML のようにコードとして記述・Git 管理する DSL ベースの DRY 強制の仕組みではありません。

出典: Tableau Help — Tableau Semantics / Tableau Help — Tableau Pulse

組織に Looker を入れる前に確認したい 3 つの条件 ── Developer User・データモデル・エディション

Looker を導入する際に現実的なハードルになる点を整理します。

1. Developer User の確保

LookML を書ける人材が最大のハードルになります。Looker のユーザー種別は大きく「Developer User (LookML 開発者)」と「Standard User (参照・探索のみ)」に分かれます。Developer User がいなければ LookML のモデルを整備・更新できず、セマンティックレイヤーを維持できません。

LookML は SQL の知識があれば習得できますが、学習コストと時間は確保しておく必要があります。

2. BigQuery 側のデータモデル整備

LookML は「すでに整理されたデータ」の上に乗る仕組みです。BigQuery のテーブル設計が未整理のまま LookML だけ書いても、正確な指標定義にはなりません。データウェアハウス側のモデリング (ディメンション・ファクトの分離など) と並行して進める必要があります。

3. エディション選定

Looker (Google Cloud core) には 3 つのエディションがあります。

出典: Google Cloud (Looker) — Looker Core エディション

料金はすべてのエディションで公式 USD 数値は公開されておらず、要営業相談となっています。

ただし Conversational Analytics (自然言語でデータを問い合わせる機能) は単価が一部公開されています。2026 年 9 月 30 日まで無料で利用でき、2026 年 10 月 1 日以降は入力トークン $3 / 出力トークン $20 (それぞれ 100 万トークンあたり) と公式に案内されています。1 USD = 155 円換算 (2026 年 5 月 4 日時点) で計算すると、入力 1M トークンあたり約 465 円、出力 1M トークンあたり約 3,100 円に相当します。

なお、データポータル Pro (旧 Looker Studio Pro) は Looker (Google Cloud core) のユーザーであれば無料で利用できます。

まとめ ── セマンティックレイヤーへの投資として Looker を測る

Looker は「誰でも触れる × 数字は揃う」という二律背反を、LookML というセマンティックレイヤーで両立させるための道具です。

「ダッシュボードを作るツール」ではなく、「組織が共有する指標定義をコードとして管理する基盤」として捉えると、エディション問わず要営業相談という料金体系の背景も見えてきます。

投資対効果の判断軸は一点に集約されます。Developer User 1 名が LookML でモデルを整備することで、SQL を書けない全員が Explore から正確な数字を自分のペースで引き出せるようになります。この非対称な分業が組織規模で効くかどうかが、導入判断の核心です。

導入を検討する際の出発点として、自組織で「自由 vs 統制の二択」がどのフェーズで問題化しているかを確認するのが実際的です。ダッシュボードが乱立して数字が合わなくなっている段階なのか、それとも IT 部門への依頼が滞留している段階なのか。どちらの段階にあるかで、Looker が効く領域と導入準備のボトルネックが変わってきます。

参考文献

• What is LookML? | Google Cloud (Looker)
• LookML terms and concepts | Google Cloud (Looker)
• Viewing and interacting with Explores | Google Cloud (Looker)
• Looker Core edition types | Google Cloud (Looker)
• Looker Studio is Data Studio | Google Cloud Blog
• Opening up the Looker semantic layer | Google Cloud Blog
• About Data Studio Pro | Google Cloud (Data Studio)
• Tableau Pulse | Tableau Help
• Tableau Semantics | Tableau Help

Author

tgeas

大阪の SIer 勤務。Google Cloud Partner Top Engineer 2026 / 2025 JAPAN All AWS Certification Engineers。インフラ・ネットワークからデータ活用と生成 AI 活用支援まで幅広く対応。

profile