Lightdashはdbtを指標の唯一の正とし、BIをコードレビューの対象に変えた

Lightdashは、dbtプロジェクトの定義をそのまま分析の土台として使うオープンソースのBIプラットフォームである。

メトリクス・チャート・ダッシュボードをGit上のコードとして管理し、変更をプルリクエストとCIで検証してから本番に反映する「BI as code」を掲げる。

セルフホストの無料版と、ユーザー数無制限のマネージド版Lightdash Cloudで提供される。出典

英国ロンドンを拠点とするLightdashは、dbtの定義をそのまま指標の唯一の正に据えるという一点で、既存のBIツールと立ち位置を分けてきた。

共同創業者のHamzah Chaudharyは、創業間もない資金調達の告知で「私たちはデータアナリストのワークフローを直し、自分たちがずっと欲しかったBIツールを作るために資金を調達した」と述べている。出典

創業（2021年）

Chaudharyと共同創業者のOliver Laslettは、2021年4月にLightdashの最初のコミットをGitHubへ置き、dbtプロジェクトを可視化するオープンソースツールとして開発を始めた。

同年6月にHacker Newsで公開し、12月にはdbt metricsへネイティブ対応した最初のBIツールになったと公式の沿革は記録している。出典

当時、データチームは変換処理をdbtに寄せ始めていたが、その上流のBI層では指標の定義が別管理になり、同じ数字が部署ごとに食い違うという問題が残っていた。出典

転機（2022年）

2022年10月、Lightdashは総額$8.4Mの調達を発表した。

内訳はAccelがリードした$6Mと、公表していなかったMoonfire Venturesリードの$2.4Mで、同時にマネージド版Lightdash Cloudのパブリックベータを始めている。出典

当時、30秒に1回のクエリがLightdash上で実行されていたと公式ブログは説明する。

AccelのAndrei Brasoveanuは、既存のBIツールがデータスタックの進化に追随できず、アナリストとデータ消費者の双方の要求を満たせなくなっていると指摘し、Lightdashのオープンソースと効率を評価した。出典

成長（2024年）

2024年1月にLightdash Cloudが一般提供へ移り、同年10月にはAccelがリードし、Shopify VenturesやOperator Partnersが参加する$11MのSeries Aを発表した。出典

公式ブログは、2年間で利用量が50倍以上になり、1秒に2件のクエリが回答され、日次アクティブユーザーの8割以上がデータチーム以外の社員だと説明する。

データチームが作った定義を、非技術者がそのまま使える状態にしたことが成長の軸になった。出典

現在

2025年にはDashboards as codeやReact SDK、AIエージェントを相次いで投入し、ロンドンに本社を開いた。出典

現在はセマンティックレイヤーとダッシュボードをAIが自ら整える「self-improving analytics」を掲げ、メトリクス定義の陳腐化や使われないチャートの整理までを製品の役割に含めている。出典

UbieがMetabase、Looker、Presetを比較したうえでLightdashを選んだのは、BI側でビジネスロジックを再実装せずに済む構造が決め手だった。出典

dbtを使うデータチームは、変換処理を一度コードで定義しても、BI層では指標を作り直す必要があり、同じ「売上」や「解約」が部署ごとに違う数字になりやすい。

Lightdashはdbtプロジェクトをそのまま指標の正として読み込むため、定義の二重管理をなくせる。出典

Ubieでは、数千モデルに及ぶdbtコードと数百のダッシュボードを抱えるなかで、指標のばらつきと重複ロジックが日常的な障害になっていた。出典

「指標の定義を1か所に戻したい」という痛みは、データチームが一定規模を超えた企業ほど強くなる。だからこそ、小規模チームから数百人規模の組織まで同じ構造で刺さると考えられる。

参入障壁の中心は、指標をdbtとセマンティックレイヤーのコードに固定し、BI層での再実装を前提にしない製品構造にある。

ツールを乗り換えるには、定義・ダッシュボード・アクセス制御をまとめて移す必要があり、移行コストがそのままスイッチングコストになる。出典

加えて、Ubieが自作したTerraformプロバイダーのような外部の生態系が蓄積されるほど、置き換えは難しくなる。出典

ネットワーク効果は弱い。

利用者が増えても指標定義が自動的に共有されるわけではなく、単一組織内の内部効果にとどまる。出典

ただし、Slackコミュニティ、テンプレート、外部のTerraformプロバイダーといった補助資産は、利用者が増えるほど厚くなる。

製品本体の効果というより、エコシステム側の緩やかな効果である。出典

小規模なデータチームで成長企業を支える企業が主な対象である。

Ubieは従業員201〜500名で、全従業員の8割がLightdashを使う。出典

dbtを既に使い、ウェアハウスとGitの運用が定着している組織に向く。

逆に、変換処理をdbtに寄せておらず、専任のデータエンジニアも置かない組織では、セマンティックレイヤーを維持する前提が薄いため向きにくい。

第一に、dbtとBIを一体化し、指標の定義をコードで一元管理できるようにした点である。

Ubieはメダリオンアーキテクチャをdbtで組み、その上のメトリクス層をLightdashに置くことで、変換・ロジック・提示層の不一致を解消した。出典

第二に、オープンソースを入口にマネージド版で収益化するopen-coreモデルである。

セルフホストの無料版とユーザー数無制限のCloud Proを分け、導入の摩擦を下げた。出典

第三に、チャートやダッシュボードをコードとして扱い、PRとCIで検証する開発体験をBIに持ち込んだことだ。出典

ARRや売上高は公表されておらず、成長率は利用量や顧客数といった間接的な指標でしか確認できない。出典

競合は強力である。

BIの既存契約を持つLookerやTableau、Power BIと、ウェアハウスに直接LLMを当てる安価な選択肢の両方から価格圧力を受ける。出典

またBI as codeはデータチーム側にGitとCIの運用を前提とするため、その成熟度が低い組織では導入ハードルが残る。出典

初期はオープンソースをHacker Newsで公開し、Slackコミュニティとブログで利用者を増やすコミュニティ主導の獲得だった。出典

現在はdbtユーザーとデータチームに向けたコンテンツ、AIエージェントやMCPによる開発者体験、埋め込みによる顧客向け分析の3方向で拡張している。

OSSで認知を取り、Cloud ProとEnterpriseで収益化する構造だが、セルフホスト利用者が課金に移らないリスクとは隣り合わせである。出典

主要チャネル: community, content, open-source, product-led

分析基盤の差別化は、ダッシュボードの見た目ではなく「指標の定義をどこに置くか」で決まる。

Lightdashは、データ変換の事実上の標準だったdbtにBIを寄生させず一体化することで、独自の指標管理を作らずに差別化した。出典

また、買われないための障壁は機能数ではなく移行コストである。

定義と履歴をコードに置くと、乗り換えのたびに資産を移す必要が生まれ、結果として顧客が定着する。出典

日本のSaaSやヘルステックでは、事業部門ごとに数字の定義がずれ、データチームが問い合わせ対応に追われる状態が起きやすい。

Ubieは、dbtのリポジトリに月600件を超えるプルリクエストが届く運用と、Terraformでアクセス変更を監査可能にする仕組みを組み合わせ、従業員の8割がセルフサービスでデータを使う状態を作った。出典

日本企業が導入を検討する際は、ツール選定より先に「指標の定義を誰がコードで管理するか」を決めることが成否を分ける。

ガバナンスを後付けの制約ではなく、スケールの前提条件として設計できるかが問われる。出典