老舗BIツール「Looker」はAI時代をどう生き抜くか - 10年超の歴史と進化の軌跡
はじめに
LookerはGoogle Cloudが提供するエンタープライズ向けのBIツールです。初出は2012年とすでに10年以上の歴史を持つプロダクトなため、Modern Data Stackの中ではかなり古参の部類に入ります。どれくらい古参かと言うと、BigQueryやRedshiftのようなクラウドDWHとほぼ同世代に生まれています[1]。
プロダクト名がややこしいので整理すると、現在Lookerと呼ばれるGoogleのBIツールとしては以下の3種類が提供されています：
- Looker：エンタープライズ向けの高機能BIプラットフォーム（本記事の主題）
- Looker Studio Pro：有料版のLooker Studio
- Looker Studio：無料で利用できるシンプルなBIツール
このうちLooker Studioは、元々はGoogle Data Studioという名前でしたが、2019年にGoogleが買収したLookerに合わせて2022年にリブランディングにより名称が変更されました。ブランド名が重複しているため、Lookerのドキュメントを探しているのに、Looker Studioのドキュメントばかりヒットしてしまうという弊害もあるのが地味に困る点でもあります。
Looker Studioは無料で気軽に触れるBIツールとして優秀ですが、反面APIがほとんどなく、統合的な管理が難しいという課題があります。一方でLookerは10年以上もエンタープライズ向けのSaaSとして提供されているため当然多機能になっており、今では管理者としてLookerインスタンスをメンテナンスしているエンジニアでもすべての機能を把握するのは困難なレベルになっています。
この多機能さは両刃の剣で、さまざまな用途に利用することはできるのですが、社内外に広く提供する場合は、管理者は単にライセンスを管理するだけではなく、Lookerの機能を理解した上でどの機能を開放するか、権限設計をどうするかなど、適切にガバナンスを効かせるためにプラットフォームチームのような役割も求められます。特にLookerはAPIが充実しているため、無秩序な状態だとどこからでもLookerのリソースを参照・操作できるようになってしまうため、注意が必要です。
さて、そんなLookerですが、ここ数年はAIとの統合が急速に進められています。セマンティックレイヤー用の独自言語であるLookMLを起点としたプロダクトの設計が、現在のAI時代において親和性が高いことも大きな要因です。
本記事では、Lookerがこれまでどのような変化を遂げてきたのか、そして現在のAI時代にどう適応しているのかを見ていきたいと思います。
先見の明があった機能
ここ数年でよく、ダッシュボードもコード管理できるように、という「BI as Code」という言葉を耳にするようになりましたが、なんとLookerでは既に10年以上前からその概念が実装されていました。
Lookerでは他のBIツール同様に、ブラウザからドラッグアンドドロップでダッシュボードを作成することもできますが、LookMLを使ったコードベースでのダッシュボード定義もサポートしています。
LookMLダッシュボードはほかのLookMLと同様にGitリポジトリでバージョン管理できるため、レビュープロセスを経た安全なデプロイが可能です。
Looker自体が経営層やクライアントへのダッシュボードの提供といった品質が求められる用途を強みとしているため、このような本番環境に影響を与えることなく開発できるプロセスは非常に重要です。
ダッシュボード用のファイルはLookMLではなくYAMLフォーマットになっており、GUIで定義したダッシュボードをコード化して流用するなど、一から人間がコーディングすることは想定されていない仕様ですが、今では生成AIに書いてもらうことも可能になっているため、より効率的にLookMLダッシュボードを作成できるようになっています。
過去の遺産
もちろんすべてが時代に即した最先端の機能という訳ではありません。現在のModern Data Stack観点で見ると「この機能要る？」というものもあります。
その代表例が PDT(Persistent Derived Table) です。
PDTとは
PDTは簡潔に言うと、Looker内蔵のテーブル作成のためのスケジューラー機能です。Looker上で定義されたSQLを定期実行し、結果をテーブルとして物理的に作成することができます。
事前にグラフ描画のためにテーブルを作成しておくことで、描画までの時間短縮やクエリコストの最適化などが期待できます。
このPDTについても2014年にリリースされています。BigQueryのScheduled QueryがGAになったのは2019年なので、PDTの方が約5年も早く存在していたことになります。
当時の合理性と現在の課題
2010年代当時は、データアナリストなど非エンジニアが利用できるスケジューラーは非常に限られていました。そのため、LookerのPDTにニーズがあり、利用することは当時としては合理的な選択肢だったと考えられます。
代替手段として以下のような選択肢も考えられましたが、いずれもハードルが高いものでした。
- cronで動作するSQL実行用のスケジューラーを内製する
- エンジニアにSQLを渡して、Airflowなどのワークフローツール上で実行してもらう
しかし現在では状況が大きく変わっており、dbtやsqlmeshなどのSQLベースのデータ変換ツールが普及し、非エンジニアでも管理可能なマネージドサービスも多数登場しています。
データ品質テスト、依存関係の管理・可視化などモダンな機能も次々と開発されており、継続的な運用を考えると、Scheduled Queryなどgit管理外で実行されるSQLは今では野良クエリとして撲滅対象になっていることも多い時代です。
一方でLookerのPDTには、前述したようなSQLを管理するためのリッチな機能は十分に追加されていません。また、すでにdbtなどのSQLワークフローツールを導入している場合は、Looker側のリポジトリに独自のSQLを配置することになるため、運用コストや複雑さが増すことになります。
そのため現在では、Looker運用の熟練者がチームに在籍しており、クエリ実行の最適化が明確に見込めるといった特別な事情がない限り、PDTの新規利用は避けた方が良いでしょう。
データ変換はdbtなど特化したモダンなツールで行い、Lookerは純粋にBIツールとして利用する方法が現時点ではベターだと考えています。
AIの波に飲まれた？ 幻のプロジェクト
Lookerの歴史を語る上で興味深いエピソードが、「Looker Modeler」という幻のプロジェクトです。
Looker Modelerとは
2023年前半に、GoogleはLooker Modelerという新たな構想を発表しました。
これは、Looker上に定義したLookMLセマンティックレイヤーを他のツールから利用するための専用インターフェースを提供するという構想でした。つまり、LookMLで定義されたビジネスロジックをLookerに閉じずに他のツールでも活用できるようにするというプロジェクトでした。
しかしこのアナウンス以降、Looker Modelerについては音沙汰がない状態が続きました。時期的に組織改編も含めてGoogleがAIへのリソースシフトを進めていた時期と重なるため、何があったのかはお察しください状態になっていました。
MCP ServerとBI Connector
とはいえ、このアイデア自体が完全消滅してしまった訳ではありません。
先日、Looker MCP Serverがリリースされました。これは当初のLooker Modelerとは異なるアプローチですが、AIエージェントがAPI経由でグラフやダッシュボードの作成などを行えるようになったため、結果的に類似の価値を提供しています。
また、この機能とは別にBI Connectorと呼ばれる機能も並行で開発されており、現在ではスプレッドシートやPowerBIなど主要なBIツール側で分析することも可能になっています。
この2つの機能を組み合わせて考えると、Looker Modelerで当初想定されていた「LookMLを他のツールから利用する」という構想は、一定程度実現されていると言えるでしょう。
AIとの統合
前述のMCP Serverも含めて、ここ数年Lookerが最も注力しているのが急速に発展するAI分野との統合です。
特に注目すべきはConversational Analyticsという機能です。
機能面ではMCPと似ていますが、データソースごとにデータエージェントという、追加のコンテキスト情報を考慮しながら分析できるため、より高度な分析が（十分なデータ整備を行えば）可能になります。
また、この機能はLooker自体に統合されているので、マネージドサービスとしても利用することができます。
LookMLの資産価値
Conversational Analyticsのデータソースとしては、APIが提供されているため、LookerだけでなくBigQueryのテーブルを利用することも可能です。そのため、一からAI向けのデータソースを構築するのであれば、必ずしもLookerにこだわる必要はありません。
しかし、長年Lookerを利用しており、既にexploreとしてユーザーが様々な指標を利用できるようにLookMLを整備できている場合は話が別です。
Looker上に蓄積されている既存資産を活用したい場合は、LookMLをさらにAI活用に向けて拡充していくことが合理的な選択肢になります。
以下のリンクのように、LookML自体もAIを意識したプロパティが追加されており、LookMLを人間だけでなくAIにとっても使いやすい状態にしていくことが可能になっています。
Open Semantic Interchange (OSI) の登場
Lookerにはまだ直接の関連はありませんが、先日、Open Semantic Interchange (OSI) という新しいセマンティックレイヤーの標準化に関するプロジェクトについて発表があり、大きな話題になっています。
標準化というと、AIエージェント向けインターフェースとしては、MCP (Model Context Protocol) が広く普及していますが、これまでセマンティックレイヤーについては類似のものが存在していませんでした。
個々のプロダクトが独自のセマンティックレイヤーとそのインターフェースを定義しているため、相互運用性が低く、異なるツール間でのデータ共有にはLookerのBI Connectorのようにプロダクト側がマネージドなコネクタを開発するか、高い学習コストを払って仕様を理解する必要がありました。
しかし、このプログラムに名前を連ねている企業の中にはGoogleもといLookerの名前がありません。
Lookerとしては、既存顧客が長い年月をかけて構築してきたLookML資産を保護できることが競争力の源泉であり、セマンティックレイヤーを外部に簡単に持ち出し可能になってしまうことは、ビジネスモデル上のメリットが少ないため無理もありません。
とはいえセマンティックレイヤーの標準化は利用者が待ち望んでいた機能であり、この取り組みがスタンダードになっていけば、いずれLookerも対応せざるを得ないことになるでしょう。
これからのLookerに期待すること
Lookerは既に多機能ですが、今も定期的にアップデートが入っており、さまざまな新機能が追加されています。
AIとの統合については、プロダクト側も明らかに最優先で進めており、AIの進化に伴ってLookerも発展していくはずなので、ここでは敢えて触れず、それ以外の「こうなったら嬉しいな」という点を挙げてみます。
より現代的なコード開発環境
Lookerではブラウザ上で動くIDEが提供されていますが、正直なところかなりレガシーなUI/UXになっています。
動作がもっさりしているだけでなく、かつてのInternet Explorerを彷彿とさせるようなシングルタブUIで、複数のファイルを同時に開けないため、かなり不便に感じることが多いです。
とはいえブラウザ上でコードを書くという行為自体も、様々なAIプロダクトがVScodeのようなIDEを中心として統合されていることを考えると、あまり現代的な選択肢とは言えません。
この領域についても徐々にではありますがアップデートが入っており、CI機能がマネージドサービスとしての提供が開始されています。
この機能は元々Spectaclesと呼ばれるサードパーティのツールとして提供されていましたが、SpectaclesがLookerに買収されたことで、Lookerの一機能として提供されるようになりました。
ブラウザ上で行うことが主流だったCIバリデーションについても、この機能と組み合わせることでプルリクエスト作成時にバリデーションが走るので、ローカルIDEでも少しだけ開発しやすくなりました。
加えて、vscodeの拡張機能などが公式から提供され、シンタックスハイライトやスニペット、構文チェックなどが利用できるようになると、より快適なローカル開発環境が整っていくでしょう。[2]
公式Terraform Providerの提供
Lookerに限らず、インフラの設定値をコードやtfstateで管理できると、再利用性の向上や、万が一のトラブルの際にも迅速に復旧できるため、インフラのIaC化は非常に重要です。
特にLookerのようなエンタープライズ向けSaaSでは、利用者が数百人～数千人のような規模になったり、社外向けに提供したりするケースも多く高いサービスレベルを求められるため、GUIでの操作には大きなリスクが伴います。
ただ残念ながら、現在Looker APIを利用したTerraform Providerはサードパーティ製のものしかありません。
現在も定期的にアップデートが入っているのは、エムスリーの方がオーナーの後者のProviderのみです。また、このProvider自体も歴史があるため、LegacyなSDKv2で構築されています。
そのため、LookerやTerraformに何らかの大型アップデートが入った場合、追従が遅れるリスクがあります。
公式がメンテナンスや機能追加を行うProviderがあれば、そうしたリスクを軽減できるため、オフィシャルなProviderの提供を期待しています。
気軽にAPIを試せるサンドボックス環境
LookerはAPIも非常に充実しており、API explorerと呼ばれるGUIからAPIにリクエストを送信できる拡張機能が提供されています。
一方で、API explorerから操作できるリソースはそのインスタンスの実際のデータとなっており、UpdateやDelete系の処理を気軽に実験するには心理的ハードルが高い状態になっています。
実際のインスタンスとは隔離されたサンドボックス環境のようなものがセットで提供されるのが理想的ですが、現時点では完全な開発環境が必要な場合、「非本番環境インスタンス」と呼ばれる開発環境用のインスタンスを別途契約する必要があります。
とはいえ、社外クライアントへの提供など厳密さが求められる場合を例外として、「ちょっとAPIを試したいから」という理由で開発インスタンス用の稟議を通すのはなかなか現実的ではありません。
豊富なAPIを活用した拡張機能のニーズをLookerのプロダクトチームだけで満たすのは現実的ではありません。前述のterraform providerのように、Lookerのエコシステムを活性化するためにも、開発者が気軽にAPIを試せるような環境が提供されることを期待しています。
90日トライアルインスタンス
このサンドボックス環境問題にも少し関連しますが、90日トライアルインスタンスという新しいオプションがリリースされました。
以前から、30日トライアルインスタンスと呼ばれるオプションもありましたが、こちらはトライアル完了後に自動的に有償版に切り替わってしまうトラップ付きでした。
新たに追加された90日版は、トライアル期間終了後には削除か新しい有償版インスタンスの作成が求められるため、より安全な仕様になっています。定期的にリフレッシュする必要はありますが、APIの動作確認などの目的には使用できる可能性が高いでしょう。
ただし、個人所有のGCPプロジェクトで試してみたところ、セールスへの連絡が要求される状態でグレーアウトしており、インスタンスを作成できませんでした。残念ながら引き続き個人レベルで気軽に試せる環境は提供されていないようです。
まとめ
BIツールの分野は競争が激しい戦国時代であり、Lookerも例外ではありません。さらに、前述のOSIのようなセマンティックレイヤーの標準化、さらなるAIの進化などを踏まえると、BIツールという存在そのものが別の何かに置き換わってしまう可能性もあります。
BIツールを組織のために新しく選定する場合も、現状ではどのツールも一長一短があり、BIツール以外の技術スタック、組織規模、利用者のデータリテラシーなど無数の要素によって最適解は変化します。
例えば2025年現在であれば、データ変換ツールとして広くdbtを採用しているのであれば、Lightdashなどが有力な選択肢として挙がってくるでしょう。
ちなみに私がビジネスサイドにいた頃は自分たちでデータパイプラインを組んで、プロジェクトで変化を期待するKPIをモニタリングするためのダッシュボードも自作するという一風変わったチームにいました。
自分たちがデータのオーナーでもありコンシューマーでもあるようなこうしたチームでは、LookMLで都度指標を定義していくより、Looker StudioなどシンプルなGUIベースのBIツールを使って、見たいデータに合わせてダッシュボードをスクラップアンドビルドした方が生産性が高い場合もあります。
しかし世間一般には、ダッシュボードを作る人と見る人が組織や会社を横断して分かれているケースが多いでしょう。その場合、Lookerのようなガバナンス機能が充実したBIツールを利用する価値は依然として高いと言えます。
LookerはBIツールの中でもAI統合が非常に進んでおり、今後もGeminiと連携した高機能なBIツールとして進化することが期待できます。少なくともすぐ近い将来にLookerがKilled By Googleの仲間入りをする未来はなさそうです。
-
非公式の拡張機能であれば存在するようです。https://marketplace.visualstudio.com/items?itemName=Cobry.looker-vscode ↩︎
Discussion