Looker（Google Cloud）

どんなサービスか

Looker は、Google Cloud が提供する BI（ビジネスインテリジェンス） プラットフォームです。データウェアハウス上のデータを、コードで記述した定義済みのモデルを通じて可視化・分析し、組織で共有できます。

「結局なに？」を一言でいえば、指標の定義を集約してから可視化する タイプの BI で、データの意味づけ（モデリング）を中心に据える点が特徴です。

元はスタートアップ Looker Data Sciences の製品で、2020 年に Google が買収して Google Cloud のサービス群に組み込まれました。Tableau や Power BI が「手元にデータを取り込んで描く」発想なのに対し、Looker は データをウェアハウスに置いたまま、その場で SQL を生成して問い合わせる（インデータベース）設計を貫いているのが出発点の違いです。

横にスクロール

主な特徴

• LookML と呼ばれる独自のモデリング言語で、テーブルの関係（join）や指標（measure）・項目（dimension）の計算方法を 一元的に定義 できる。
• 利用者はモデルを土台に、SQL を書かずに「探索（Explore）」画面で項目を選ぶだけで分析でき、Looker が裏側で SQL を自動生成する。
• 指標の定義を共通化することで、部署ごとに数字がズレる「単一の真実（single source of truth）」問題を抑えやすい。
• LookML はテキストファイルなので Git でバージョン管理 でき、変更レビューやブランチ運用といったソフトウェア開発の作法を BI に持ち込める。
• ダッシュボードやレポートの共有に加え、定期配信・しきい値アラート・他システムへのデータ埋め込みに対応する。
• API と埋め込み機能（Embedded Analytics）が充実しており、自社プロダクトに分析画面を組み込む用途にも使える。

仕組み・アーキテクチャ

Looker の心臓部は LookML によるセマンティックレイヤー（意味づけの層） です。アナリストが LookML で「この指標はどのテーブルのどの列をどう集計するか」を一度書いておくと、エンドユーザーが探索画面で操作するたびに、Looker がその定義に従って クエリ時に SQL を組み立て、接続先のデータウェアハウスへ直接発行 します。

この「インデータベース」方式により、Looker 自体は大量データを保持せず、計算は BigQuery・Snowflake・Redshift などウェアハウス側の性能をそのまま活かします。一方で、実行するたびにウェアハウスへ課金されるクエリが走る ため、コスト管理とキャッシュ設計が運用の要になります。Looker はクエリ結果のキャッシュや、PDT（Persistent Derived Table、永続化した中間テーブル）でこれを緩和します。

LookML はおおまかに次の構成要素で組み立てます。

• view … 1 つのテーブルに対応し、dimension（項目）と measure（集計）を定義する。
• explore … 複数の view を join でつなぎ、ユーザーが分析を始める入口にする。
• model … どのデータベース接続を使い、どの explore を公開するかをまとめる。

ユーザー操作（Explore）
   └→ LookML 定義を解釈
        └→ SQL を自動生成
             └→ データウェアハウスで実行（BigQuery 等）
                  └→ 結果をキャッシュして可視化

主なユースケース・向き不向き

組織横断で 指標の定義を統制し、全社で同じ数字を見たい 場面に最も向きます。営業・マーケ・経営など部署ごとに「売上」の定義がぶれる問題を、LookML の中央定義で解消できるのが典型的な価値です。すでに BigQuery や Snowflake などのクラウドデータウェアハウスを基盤に持つ組織と特に相性が良いといえます。自社 SaaS に顧客向けの分析画面を埋め込む（組み込み分析）用途でも採用されます。

一方で、少人数で手早く対話的にグラフを作りたい、あるいは きれいなウェアハウスがまだ無い 段階では、モデリングの初期コストが重く感じられます。LookML を書ける担当者の確保も前提になります。アドホックに表計算感覚で探索したいだけなら、可視化先行の BI のほうが立ち上がりは速いでしょう。

競合・代替との比較

同じ BI でも、可視化先行の Tableau とは設計思想が対照的です。

数字の整合性を組織横断で担保したいなら Looker、手早く対話的にビジュアルを作りたいなら Tableau、Microsoft 365 との親和性なら Power BI が向きます。Looker は Google Cloud のデータ基盤と組み合わせ、定義の統制を重視する場面で選ぶのが実務的です。

料金・エコシステム

Looker は商用の SaaS で、OSS ではありません。料金は一般にプラットフォーム利用料と、閲覧・開発などの ユーザー区分ごとのライセンス を組み合わせる形が中心で、規模や用途で大きく変わるため個別見積もりが基本です（変動するため最新の公式情報で確認してください）。

エコシステム面では、Google Cloud の一員として BigQuery との連携が密 なほか、Snowflake・Redshift・PostgreSQL など多数のデータベースに接続できます。近年は Looker Studio（旧 Google Data Studio）という無料寄りの軽量 BI も別系統で提供されており、本格的な LookML モデリングを伴う「Looker」とは別物として整理すると混乱しません。LookML のモデルを Looker Studio など他ツールから参照する連携も進んでいます。

導入・運用上の注意点

導入で最初に効いてくるのは LookML 設計の良し悪し です。view・explore の切り方や join の定義が雑だと、誤った指標が全社に広がるリスクがあるため、コードレビューやテスト（LookML には依存関係を検証する仕組みがある）を前提にした運用が望まれます。Git 連携を活かし、本番モデルへの反映をブランチ経由にしておくと安全です。

運用フェーズでは前述のクエリコストとパフォーマンスが論点です。重い集計は PDT や上流の集計テーブルへ寄せ、ダッシュボードのキャッシュ方針を決めておくと、ウェアハウス負荷と課金を抑えられます。権限設計（誰がどのデータ・どの行を見られるか）も LookML 側で表現できるため、アクセス制御を含めてモデルに織り込む設計が定着への近道です。総じて、Looker は「BI ツール」というより データ定義の共通基盤 として捉え、データエンジニアリングの体制とセットで導入すると価値を発揮します。