Lookerは指標定義をLookMLにコード化し、$2.6BでGoogle Cloudに買われた

Lookerは、指標の定義をLookMLというモデリング言語で一度だけ書き、そのsemantic layerを通じてBIダッシュボード・埋め込みアプリ・AIエージェントへ同じ数値を届けるデータ分析プラットフォームだ。

部署ごとに集計がずれる状態を、定義の一元化で解くことを狙う。

Google CloudのLookerは、指標の定義を一度書けば、ダッシュボードでも埋め込みアプリでもAIエージェントでも同じ数値が返る。

そのsemantic layerという考え方を業界に広めた製品だ。

共同創業者のLloyd Tabbは、この設計の原点を現場の痛みに置き、必要なら自分の役割まで手放すことを選んだ人物として知られる。

Tabbは後のインタビューで「Great software is an act of empathy（優れたソフトウェアは共感の行為だ）」と語っている。出典

出発点 — 「また同じ集計ツールを作っている」

TabbはNetscapeやLiveOps、ReadyForceで、特定のデータを見るための専用ツールを何度も作り直していた。

同じものを繰り返し作っているという感覚が、事業の種になった。

Tabbは「何年もかけてLookerのような製品の必要性を感じ、何度もこのアイデアに戻ってきた」と述べている。出典

2012年1月、TabbとBen Porterfieldはカリフォルニア州Santa CruzでLookerを創業した。

PorterfieldはReadyForce時代にTabbが社内部署向けに作っていたツールを見ており、エンジニアが価値を感じることをすでに知っていた。出典

)

転機 — CEOの座を手放す決断

初期のLookerは製品こそ刺さっていたが、販売の仕組みを持っていなかった。

Tabbは取締役会から営業チームの構築を求められた際、自分では担えないと判断し、Frank Bienを招いた。

Tabbは「真実を言えば、CEOの帽子を手放すのは難しかった。だから最初はPresidentとして迎えた」と振り返っている。出典

その後Lookerは資金調達を重ねて規模を広げた。

2013年8月のシリーズAで$18M超、2015年3月のシリーズBで$30M、2016年1月のシリーズCで$48M、2017年3月のシリーズDで$81.5M、2018年12月のシリーズEで$103Mを調達している。出典

)

到達点 — 買収という新章

2019年6月6日、GoogleはLookerを$2.6Bの全額現金で買収すると発表した。

Google CloudのThomas Kurian CEOは「Lookerはビジネス指標を一貫した形で定義する能力を加える」と述べ、両社で350社超の共同顧客がすでにいることを挙げた。出典

買収は2020年2月に完了し、LookerはGoogle Cloudの分析ポートフォリオに加わった。出典

現在地 — 指標をAIの土台にする

現在のLookerは、Geminiを組み込んだConversational AnalyticsとMCP連携を掲げ、人間とAIエージェントが同じ定義を参照するagentic BI基盤として位置づけられている。出典

Tabbが置いた「指標の定義をコードにする」という設計は、AIがデータを読む時代になって、むしろ価値が増していると言える。

Lookerが刺さるのは、部署ごとに指標の定義がずれ、集計のたびに数字が食い違う組織だ。

Google Cloudは買収時点で、Lookerが「ビジネス指標をデータソースをまたいで一貫した形で定義する」能力を持つと説明している。出典

定義をLookMLに一度書けば、BIダッシュボードでも埋め込みアプリでも同じ数値が返る。

分析者ごとのSQLの書き方に依存しない点が、意思決定の速度と信頼を同時に上げる。出典

参入障壁はsemantic layerそのものだ。

顧客がLookMLで定義した指標は、組織の業務知識がコードとして蓄積された資産になる。

定義を書き換えるほど移行コストが上がり、乗り換えが難しくなる。出典

ネットワーク効果は弱めだ。

指標定義は顧客ごとに閉じており、利用者が増えても他の顧客のモデル精度は上がらない。

強みはエコシステム、すなわちLookML資産とAPI/SDKの広がりにある。出典

主な利用者は、データウェアハウスにデータを集約し、指標の定義を統制したい中堅〜大企業だ。

BI担当のアナリスト、事業部門の分析者、そして自社プロダクトに分析を組み込む開発チームが重なる。

埋め込み分析では、分析を収益源にしたいSaaS企業も対象になる。出典

第一に、指標定義をsemantic layerへ集約したことだ。

LookMLでモデルを一元管理し、表示層の違いを吸収した。出典

第二に、初期から経営を専門家に委ねたことだ。

創業者自らCEOを譲り、営業と組織の構築を任せた。出典

第三に、買収後もsemantic layerを軸に据え続けたことだ。

GeminiやMCP連携も、定義の一貫性を前提に組み込まれている。出典

Lookerは公開情報の範囲で大きな失敗を記録していないが、構造的なリスクは残る。

価格が要見積もりの年間契約中心で、小規模チームには導入の壁が高い。出典

またGoogle Cloudへの統合は、マルチクラウドを前提に選んだ顧客にとって将来の不確実性になり得る。

買収発表時点でも両社はマルチクラウドの継続を明言しており、そこは注視点だ。出典

初期はプロダクト主導と顧客コミュニティが成長の入口だった。

創業者は顧客イベントを早期から重ね、communityの構築に手応えを感じていたという。出典

規模拡大の局面では、専門経営者による営業組織の構築が伸びを決めた。出典

)

現在はGoogle Cloudの販売網とBigQuery連携が、データウェアハウスの導入と一緒にBIを売る導線を作っている。出典

主要チャネル: sales, content, community, events, cloud_marketing

指標の定義をどこに置くかは、後から効いてくる設計判断だ。

表示層をいくら磨いても、定義が散っていれば数字は信用されない。

早い段階でモデルを一カ所に集めるほど、分析の規模を広げても一貫性を保ちやすい。出典

日本企業でも、事業部ごとにKPIの定義がずれて集計が合わない問題は根深い。

Lookerの考え方は、全社の指標をLookMLで定義し、BIと社内アプリ、そしてAIエージェントに同じ数値を配る設計として参考になる。

導入の重さより、定義の統制をどこまで経営課題として扱えるかが成否を分けると考える。出典