顧客提供型 BI に Looker を採用した感想

ツール導入前の課題

弊社では複数のSaaSプロダクトを提供しており、蓄積された業務データを用いて社内で活用する土壌が存在しておりました。この社内で培った分析および業務改善のノウハウを顧客にも提供させていだたくことで、弊社の掲げる「Data Driven Logistics」をより推進したい、という思いがありました。

どのような状態を目指していたか

• プロダクト内でダッシュボードを埋め込み表示すること
• 顧客が埋込ダッシュボードを直接操作でき、プロダクト内でシームレスな編集が可能であること
• 顧客自身で、ダッシュボードを作成することができ、フィルタや分析軸を変えてデータ探索ができること
• テナントごとのデータ分離を宣言的に実装し、システム停止なしにスケールできるアーキテクチャとなること
• 月に数百社の新規追加にもシームレスに対応できるスケーラビリティを確保すること

• Tableau
• Apache Superset
• Metabase

以下の4軸で評価を行いました。

1. 品質: ガバナンス（データ定義の一元管理）、安定稼働、要件の実現性
2. 体験: 直感的な操作性、高速表示、顧客が自らデータ探索できるUX
3. 運用: カスタマーサクセス学習コスト、システム保守性、少人数（2名）で回せること
4. コスト: 必要なアカウント数・種類、開発運用にかかる精緻なコスト

加えて、以下の機能要件を重要視していました。

• 柔軟な権限管理が可能であること: 顧客間でのデータ漏洩を起こさないアーキテクチャであること。また、データのアクセス範囲制御だけでなく、BI 自体のダッシュボードや機能に関しても制御可能であることが重要
• セマンティックレイヤー: ビジネス用語とデータ定義を一箇所で管理し、ダッシュボード間で一貫した指標を提供する仕組み
• コードベースの管理: メトリクスのコード管理が可能で、UIがテンプレート化できること
• プロダクトへの埋め込み: 自社プロダクトのログインのみで利用でき、プロダクト画面に埋め込み表示が可能なこと
• 拡張性: データ探索・ドリルダウン、AI等の新機能が高頻度で追加されること

Lookerを選んだ決め手は、以下の点でした。

柔軟なデータ制御・細かな権限管理が可能

always_joinとユーザー属性の組み合わせで、テナント単位のアクセス制御をLookMLコードとして宣言的に記述できます。また Liquid 構文が使用可能であるため、アクセス制御の粒度や制御粒度を柔軟に対応することが可能です。さらに、Looker 自体の権限管理機能やコンテンツ管理機能によって、ユーザーごとの細やかな権限制御を行える点が、今回の要件に合致しました。

署名付き埋め込み（Signed Embedding）

自社プロダクトにログインするだけでダッシュボードを閲覧でき、外部のBIツールに別途ログインする必要がありません。URLを外部に共有してもアクセスできない設計のため、セキュリティ面でも安心でした。

コードベースのBI管理

LookML によってセマンティックレイヤーの構築・管理が可能なので、Gitによるバージョン管理・プルリクエストベースのレビュー・ADR（Architecture Decision Records）による設計判断の記録が自然に回ります。また、Looker 上での LookML の検証によるチェックや、 Contents Validator といった検査機構によって、意図せぬ破壊を未然に防ぐことも可能な点は、運用面で大変魅力的でした。

改善したかった課題はどれくらい解決されたか

Looker導入により、当初の課題はほぼ全て解決できました。

• セマンティックレイヤーの確立: LookMLのView定義でDimension（分析軸）とMeasure（集計値）を一元管理。「稼働時間とは何を含むのか」「商品数はどの業務イベントに紐づくのか」といったデータ項目の定義を、コード上で明確化できるようになりました
• 埋め込みダッシュボードの実現: 署名付き埋め込み（Signed Embed URL）により、自社プロダクト内で顧客がシームレスにデータを閲覧できる体験を提供。プロダクト側にLooker固有の情報を持たせず、API経由で署名付きURLを発行する設計にすることで、責務の分離も実現しました
• スケーラブルな権限管理: 企業単位の契約フラグと、ユーザー属性によるデータアクセス制御、および Looker 上の Role 制御を組み合わせることで、顧客が増えてもシステム停止なしに最小限に必要な権限を付与することが可能になりました

どのような成果が得られたか

最大の成果は、2024年11月のキックオフから約3ヶ月で、3名のプロジェクトチーム（内、エンジニア1名）で顧客向けダッシュボードをローンチできたことです。競合他社との競争が激化する中、Deliveryを最優先とする方針でプロジェクトを推進し、2025年1月下旬に販売可能な状態を達成しました。LookMLでデータモデルを一度構築すれば、ダッシュボードの作成・変更がExplore上で素早く回せるため、少人数でもスピード感のある開発が可能でした。

LookML固有の学習コスト

LookML は dbt 経験者でも習得に時間がかかりました。Explore、View、リファインメント、Liquid 構文といったLooker 独自の概念を理解する必要があり、カスタムディメンション・メジャー、表計算といった動的に生成したデータ項目と組み合わせた場合での各種挙動や、sql_distinct_key を用いた集計でのエラーなどの復旧には、慣れるまで苦労しました。

• ※ 関連資料: https://speakerdeck.com/hacobu/deng-tan-zi-liao-fan-zhong-da-di-a54e47fb-1835-4020-9f44-6a51c73eeca2?slide=60
• ※ エラーの例: https://docs.cloud.google.com/looker/docs/best-practices/error-non-unique-primary-key-computing-sum?hl=ja

セマンティックレイヤー構築時のデータ定義の詰め

LookMLでDimension/Measureを定義する際には、データ項目の「単位」「定義」「命名」を事前に厳密に詰める必要があります。「稼働時間」のような一見シンプルな項目でも、定義が曖昧なままLookMLに落とし込むと、認識がブレやすく、結果としてダッシュボードの数値に対する信頼を損ないます。ドメインエキスパートとの認識合わせに想定以上の時間を要しました。

• ※ 関連資料1: https://speakerdeck.com/hacobu/deng-tan-zi-liao-fan-zhong-da-di?slide=23
• ※ 関連資料2: https://speakerdeck.com/hacobu/deng-tan-zi-liao-fan-zhong-da-di-a54e47fb-1835-4020-9f44-6a51c73eeca2?slide=53

既存データマートからの移行

社内BIで使っていたデータマートをそのまま流用できるという楽観は禁物でした。今回の初期要件では、ワイドテーブル構造からディメンショナルモデル（スタースキーマ）への再設計が必要になり、結果として dbt モデルのフルリプレースを実施する必要がありました。

• ※ ブログ: https://zenn.dev/hacobu/articles/3b963cab3a768d

• データ定義を先に固める: LookMLでDimension/Measureを定義する前に、データ項目の「単位」「定義」「命名」をドメインエキスパートと厳密に詰めてください。定義が曖昧なままLookMLに落とし込むと、ダッシュボードの数値に対する信頼を損ないます
• dbtとの連携を前提に設計する: LookMLのディレクトリ構成をdbtのレイヤー構造に対応させることで、保守性が大幅に向上します
• 既存データマートの「そのまま流用」に注意: 社内BI用のワイドテーブルをそのまま顧客向けに流用しようとすると、リネージの複雑さに苦しむことがあります。ディメンショナルモデルへの再設計を視野に入れてください
• PoCで資産を作っておく: LookMLはコードベースなので、PoCで作成したダッシュボードやモデル定義を本番化フェーズでそのまま再利用できます。PoCを「使い捨て」にしない設計が有効です

• AI連携の拡張: LookMLで定義したセマンティックデータモデルを、API連携やMCP（Model Context Protocol）を通じてAIツールからも参照可能にし、LLMによるデータ分析の基盤として活用していく予定です
• プロダクトラインの拡大: さらに多くのプロダクトラインへLookerダッシュボードの提供を拡大していきます
• セマンティックレイヤーの深化: Dimension/Measureの定義をさらに充実させ、label/descriptionフィールドを活用したデータカタログとしての役割も強化していきます