顧客提供型 BI に Looker を採用した感想
株式会社Hacobu / i-dach
データエンジニア
| 利用プラン | ツールの利用規模 | ツールの利用開始時期 | 事業形態 |
|---|---|---|---|
Looker(オリジナル) | 301名〜500名 | 2024年10月 | B to B |
| 利用プラン | Looker(オリジナル) |
|---|---|
| ツールの利用規模 | 301名〜500名 |
| ツールの利用開始時期 | 2024年10月 |
| 事業形態 | B to B |
アーキテクチャ

アーキテクチャの意図・工夫
署名付き埋め込みのアーキテクチャです。 プロダクト側のリクエストに応じて、API側で企業・ユーザー情報からダッシュボードを選定し、署名付きURLを動的に発行します。プロダクト側にLooker固有の情報を持たせない設計にしており、責務の分離を実現しています。原則1ページに対し1つのダッシュボードが埋込される形式です。
詳細: https://speakerdeck.com/hacobu/deng-tan-zi-liao-fan-zhong-da-di-gao-qiao-gui?slide=29
導入の背景・解決したかった問題
導入背景
ツール導入前の課題
弊社では複数のSaaSプロダクトを提供しており、蓄積された業務データを用いて社内で活用する土壌が存在しておりました。この社内で培った分析および業務改善のノウハウを顧客にも提供させていだたくことで、弊社の掲げる「Data Driven Logistics」をより推進したい、という思いがありました。
どのような状態を目指していたか
- プロダクト内でダッシュボードを埋め込み表示すること
- 顧客が埋込ダッシュボードを直接操作でき、プロダクト内でシームレスな編集が可能であること
- 顧客自身で、ダッシュボードを作成することができ、フィルタや分析軸を変えてデータ探索ができること
- テナントごとのデータ分離を宣言的に実装し、システム停止なしにスケールできるアーキテクチャとなること
- 月に数百社の新規追加にもシームレスに対応できるスケーラビリティを確保すること
比較検討したサービス
- Tableau
- Apache Superset
- Metabase
比較した軸
以下の4軸で評価を行いました。
- 品質: ガバナンス(データ定義の一元管理)、安定稼働、要件の実現性
- 体験: 直感的な操作性、高速表示、顧客が自らデータ探索できるUX
- 運用: カスタマーサクセス学習コスト、システム保守性、少人数(2名)で回せること
- コスト: 必要なアカウント数・種類、開発運用にかかる精緻なコスト
加えて、以下の機能要件を重要視していました。
- 柔軟な権限管理が可能であること: 顧客間でのデータ漏洩を起こさないアーキテクチャであること。また、データのアクセス範囲制御だけでなく、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 モデルのフルリプレースを実施する必要がありました。
導入に向けた社内への説明
上長・チームへの説明
ー
活用方法
当社ではプロダクトの機能の一部として Looker を活用しています。
- 埋込ダッシュボード機能(全顧客向け): LookML テンプレートで共通化したダッシュボードを顧客へ提供します
- 埋込ダッシュボード機能(個社向け): 個社専用ダッシュボードおよびフォルダを顧客に付与し、提供します
よく使う機能
- Signed Embedding(署名付き埋め込み)
- Looker API
ツールの良い点
- LookML自体がセマンティックレイヤーの構築手法: Viewでデータ項目を定義し、Modelで結合条件を定義し、Exploreで分析の起点を提供する。Lookerのプラクティスに従うだけで自然とセマンティックレイヤーが構築されます
- コードベースのBI管理: ダッシュボードをテンプレート化することができ、また、Git によるバージョン管理・PRベースのレビュー・ADRによる設計判断の記録が自然に回り、トレーサビリティが確保できます。
- 少人数・短期間での運用可能: 3名の PJ メンバー(内、エンジニアは1名)で約3ヶ月で顧客向けダッシュボードをリリース。PoC時の資産をベースに本番化へスムーズに移行できました
- 柔軟な権限管理実装:
always_joinなど、マルチテナント提供を実現するための機能が揃っています - 署名付き埋め込み: 顧客は自社プロダクトにログインするだけでダッシュボードを閲覧でき、プロダクトの一機能として自然に統合できます
- dbtとの構造的な対応が可能: データ変換(dbt)とデータ表現(Looker)の責務がきれいに分離されます
ツールの課題点
- LookML固有の学習コスト: dbt 経験者でも習得に時間がかかります。
- デバッグの難しさ: 複数のリファインメントが適用されたViewでは、最終的にどの定義が有効かの把握に時間がかかります
- Liquid構文による環境管理の複雑化: 環境が増えるほど条件分岐が膨らみ、LookMLファイルの可読性が下がります
ツールを検討されている方へ
- データ定義を先に固める: 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フィールドを活用したデータカタログとしての役割も強化していきます
株式会社Hacobu / i-dach
データエンジニア
よく見られているレビュー
株式会社Hacobu / i-dach
データエンジニア
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法


