Lightdash（ライトダッシュ）とは？dbtで指標を定義するOSS BIの仕組み・料金・導入手順

Lightdashは、dbtプロジェクトのYAMLに書いたディメンションとメトリクスを読み込み、データウェアハウスへ投げるSQLを組み立てるBIツールです。Telescope Technology Limitedが開発しており、公式ブログによると2021年5月にオープンソースのプロジェクトとして開発が始まりました。ソースコードはGitHubの lightdash/lightdash リポジトリで公開されています。

この記事では、dbtの定義がLightdashの画面にどう対応するかを先に押さえ、2026年9月時点のライセンスと料金、指標の書き方、CLIとDocker Composeでの導入、APIの認証、LookerやMetabaseとの選び分けを、公式ドキュメントとリポジトリで確認した内容で整理します。

まとめ：Lightdashの採用条件と無料の自己ホストで使える範囲

Lightdashを選ぶ価値が大きいのは、dbtで変換処理を管理していて、売上や継続率といった指標の定義をレポートごとのSQLに散らさず、Gitで一元管理したい場合です。指標は schema.yml の meta に書き、lightdash deploy で反映します。dbtを使っていなくても、Lightdash YAMLでウェアハウスの既存テーブルを直接定義できます。

費用の判断では2点を確認してください。リポジトリの大半はMITライセンスですが、packages/backend/src/ee 配下（AIエージェント、MCP、SCIM、埋め込みなど）は別ライセンスで、本番利用にはEnterprise契約が要ります。マネージド版のCloud Proは月額3,000ドルの定額で、ユーザー数による課金はありません。

自己ホストについて、公式はほとんどの企業にLightdash Cloudを勧めており、Docker Composeの手順も検証用の最小構成という位置づけです。LTS版が無く、少なくとも月1回の更新が推奨されている点まで含めて、運用を引き受けられるかで決めます。

Lightdashの仕組み：dbtのYAMLからSQLを組み立てるセマンティックレイヤー

Lightdashはデータを取り込んで加工する製品ではありません。dbtがデータウェアハウス（DWH）上に作ったテーブルに対し、YAMLで定義した「どの列で分けるか（ディメンション）」と「どう集計するか（メトリクス）」を組み合わせてSQLを生成し、結果をグラフや表にします。対応するウェアハウスはBigQuery、Snowflake、Redshift、Databricks、PostgreSQL、Trino、ClickHouse、Athena、DuckDBです。

dbtの定義とLightdashの画面の対応関係

設計で最初に効いてくる制約は、ディメンションのSQLにウィンドウ関数を書けないことです。ディメンションは生成されるクエリの GROUP BY と同じ SELECT に入るためで、累積値や構成比が必要なら、dbtモデルで事前に計算するか、テーブル計算か、percent_of_total・running_total などのpost calculationメトリクス（実験的機能）を使います。既存のSQLレポートをそのまま移そうとすると、ここで書き直しが発生します。

Lightdashから探索するモデルをどの層に置くかは、dbtの三層構造においてmarts層が最終データ整備を担う原則で整理した考え方がそのまま使えます。

dbtを使わないLightdash YAMLとMetricFlow指標の取り込み

dbtを導入していない場合は、Lightdash YAMLを使います。プロジェクト直下の lightdash.config.yml にウェアハウスの種類を書き、models/ 配下のファイルで sql_from に既存テーブルを指定する形式です。公式ドキュメントは、Lightdash YAMLはテーブルを記述するだけで、作成や変換はしないと明記しています。変換処理は別の手段で用意する必要があります。GitHubかBitbucket Cloudと接続すれば、UIで作った項目をプルリクエストとしてリポジトリに書き戻せます。

dbt MetricFlowで定義済みの指標は、Lightdashが対応する種類なら二重に書く必要はありません。lightdash deploy がコンパイル済みの manifest.json からMetricFlowの指標を読み取り、Lightdashのメトリクスに変換します。条件はdbt Core 1.6以降で、同じ名前の指標が meta.metrics にもある場合は meta.metrics 側が優先されます。変換されるのは simple メトリクスなど対応済みの種類に限られるため、複雑な指標は変換結果を確認してください。

Lightdashのライセンスと料金：MITの範囲とEnterprise契約が要る機能

リポジトリ直下のLICENSEは、packages/backend/src/ee ディレクトリを除く部分をMITライセンスとしています。ee 配下は「Lightdash Source Available License」で、本番環境での利用には有効なEnterprise Subscriptionが必要です。開発やテスト目的でのコピーと改変は、契約なしで認められています（出典：LICENSE、ee配下のLICENSE）。

2026年9月時点で、ee 配下には AiAgentService、McpService、ScimService、EmbedService などのサービスが置かれています。OSS版を無料で自己ホストするつもりで評価を始めると、AIエージェントやMCPサーバー、SCIMによるユーザー同期を本番で動かす段階で契約が必要になります。評価の前に、使いたい機能がどちらのライセンスにあるかを確認しておくと手戻りを防げます。

Open Source・Cloud Pro・Enterpriseの価格と機能の差

iframeやReact SDKによる埋め込みは別料金のアドオンです。従量課金は最初の1,000ロードが無料で、以降は1ロード0.05ドル、定額はEmbed Workerあたり10万ロードで月790ドルです。Cloud Proには21日間の無料トライアルがあり、期間はdbtプロジェクトを最初に接続してコンパイルした時点から始まります（出典：Lightdash公式の料金ページ、2026年9月15日確認）。

ユーザー数で課金しない料金体系は、導入企業の選定理由にもなっています。CARTA HOLDINGSのfluctは2025年12月の技術ブログで、Amazon QuickSightやRedashと比較したうえで、基本固定の月額料金であることをLightdashを選んだ理由に挙げています。閲覧者が数百人規模の組織ほど定額が有利になる一方、閲覧者が10人程度なら1人あたり月300ドルとなり、ユーザー単位で課金するBIより割高になりえます。

DimensionとMetricの定義：schema.ymlの書き方とdbtバージョンによる違い

メトリクスの書き方はdbtのバージョンで変わります。dbt v1.10以降は meta を config の下に置き、v1.9以前は列やモデルの直下に meta を書きます。公式ドキュメントも両方の書式を併記しているので、プロジェクトのdbtバージョンを確認してから書き始めてください。次はdbt v1.10以降の書式です。

models:
  - name: orders_model
    config:
      meta:
        metrics:
          revenue_per_user:
            type: number
            sql: 1.0 * ${sum_revenue} / NULLIF(${distinct_user_ids}, 0)
    columns:
      - name: user_id
        config:
          meta:
            metrics:
              distinct_user_ids:
                type: count_distinct
      - name: revenue
        config:
          meta:
            metrics:
              sum_revenue:
                type: sum

列に付けた distinct_user_ids と sum_revenue は、その列を集計するメトリクスです。複数のメトリクスを組み合わせる revenue_per_user は、モデル単位の meta に type: number で書き、${メトリクス名} で参照します。type には sum・count・count_distinct・average・median・percentile・min・max などの集計型があり、sum_distinct と average_distinct はベータ版です。

列ごとの定義を手で書く量を減らすなら、lightdash generate でdbtモデルの全列ぶんのディメンション定義を生成できます。

Lightdashの導入手順：CLIのdeploy・previewとDocker Composeでの自己ホスト

Lightdash CLIのインストールと本番を壊さないdeployの使い方

CLIはmacOSならHomebrew、それ以外のOSではNPMで入れます。Windowsでは、CLI・Node.js・dbtの挙動をmacOSやLinuxと揃えられるWSL内での利用が推奨されています。

brew tap lightdash/lightdash
brew install lightdash

# 利用するLightdashのURLに置き換えて認証
lightdash login https://<LightdashのURL>

# 操作対象のプロジェクトを選択
lightdash config set-project

注意したいのが lightdash deploy の挙動です。公式ドキュメントは、dbtプロジェクトではローカルの profiles.yml を使うため、既定のターゲットが開発環境を指したまま実行すると本番のセマンティックレイヤーを上書きし、全ユーザーのダッシュボードを壊すと警告しています。コミットしていない変更も送られます。手元での確認には一時的な別プロジェクトを作る lightdash preview を使い、本番への反映はCIから行う運用が勧められています。

# 変更の確認（キーを押すとプレビュープロジェクトを削除）
lightdash preview

# 本番への反映（本番ブランチで、本番用のprofileを明示）
git checkout main
git pull
# profiles.yml内のプロファイル名・本番ターゲット名に置換
lightdash deploy --profile <プロファイル名> --target <本番ターゲット名> --no-partial-compilation

既定の部分コンパイルでは、切り分けられるフィールドや結合のエラーは警告に留まり、デプロイは通ります。壊れた定義をCIで止めたい場合は --no-partial-compilation を付けます。プレビュープロジェクトを作れるのは、そのプロジェクトでdeveloper以上の権限を持つユーザーです。

Docker Composeで起動する4つのコンテナと必須の環境変数

公式のDocker Compose手順は、インターネットからはアクセスできない最小構成をローカルで動かす概念実証用です。リポジトリをcloneし、.env を編集してから起動します。

git clone https://github.com/lightdash/lightdash
cd lightdash
export LIGHTDASH_SECRET="not very secret"
export PGPASSWORD="password"
docker compose -f docker-compose.yml --env-file .env up --detach --remove-orphans

LIGHTDASH_SECRET はデータベース内のデータを暗号化する値で、公式はこれを失うとLightdash内のデータにアクセスできなくなると明記しています。検証環境でも値を控えてから起動してください。

本番の自己ホストで運用側が負う更新作業

本番向けには、公式Helmチャートを使ったKubernetes構成が案内されています。公式の比較ページは、ほとんどの企業とチームにはLightdash Cloudを勧め、安全に自己ホストするにはDockerとKubernetesの運用、セキュリティ面の十分な理解が必要だとしています。

見積もりに入れておきたいのが更新の頻度です。バージョンは major.minor.patch のセマンティックバージョニングで、マイナー版にも後方互換性のない変更が入りうるとされ、LTSや安定版のタグはありません。公式は image.tag を特定のバージョンに固定し、少なくとも月1回は検証環境を経て更新するよう勧めています。GitHubのリリースは2026年9月14日（UTC）の約4時間で2.211.0から2.211.4まで5件が出ており、更新を後回しにすると差分がすぐに積み上がります。

Lightdash APIの認証方式とクエリを実行するエンドポイント

Lightdash APIは、個人アクセストークン（Personal access token）で認証します。トークンは設定画面の personal access tokens から発行し、CLIの認証にも同じものを使えます。公式のOpenAPI定義（swagger.json）では、Authorization ヘッダーに「ApiKey」の接頭辞を付けて渡す形式です。Bearerではないので、他のSaaSのAPIクライアントを流用するときは書き換えてください。

curl -H "Authorization: ApiKey <発行したトークン>" \
  https://<LightdashのURL>/api/v1/org/projects

APIの仕様は、利用中のバージョンに対応するswagger.jsonで確認してください。v2のクエリ系は応答の型名が ApiExecuteAsyncMetricQueryResults のとおり非同期実行で、実行と結果取得（query/{queryUuid}）が別のパスに分かれています。スクリプトでは実行後にqueryUuidを使って結果を取得します。未完了なら間隔を空けて再取得し、完了後は必要なページを取得する設計にします。Claude・ChatGPT・Codexから指標を直接問い合わせたい場合は、APIではなくLightdashのMCPサーバーも選べます（ee配下の機能です）。

LookerやMetabaseとの違いと選び分け

Looker（LookML）との違い：指標定義の管理場所

LookerはLookMLという独自の言語でビューとモデルを定義し、指標の定義はLookerのプロジェクトの中に置かれます。Lightdashは同じ役割をdbtのYAML（またはLightdash YAML）で担うため、変換処理と指標の定義が1つのリポジトリにまとまります。Ubieは導入から2年の振り返り記事で、BIのロジックをdbtのリポジトリに集約したことで、バックエンド改修時に影響を受けるダッシュボードを機械的に洗い出せるようになった点を1つ目の効果に挙げています。

移行について公式は「Migrating from another BI tool」ガイドを用意しています。Lookerの場合はLookMLプロジェクト（.lkml ファイルなど）を書き出し、AIコーディングエージェントにLightdash YAMLやdbtの定義へ変換させる手順です。このガイドの手順では、ダッシュボードは移行したセマンティックレイヤーの上でLightdashの画面から作り直します。料金表には自動移行ツール（Automated migration tools）の項目もあるため、ダッシュボードの数が多い場合は、プランごとの移行支援の範囲を見積もり時に確認してください。

Metabaseとの比較事例と指標管理体制による採用判断

Safieは2025年6月の技術ブログでMetabaseと比較し、dbt連携でymlによる定義管理ができることと、UIで作った指標をdbt writeback機能でymlへ反映できることを理由にLightdashを選んでいます。同じ記事で差が大きかった点に挙げられた「スペースを階層化できない」（2025年5月時点）は、2026年9月時点の公式ドキュメントではネストしたスペースとして解消されており、親スペースの権限を継承するか、個別に制限するかを選べます。

一方で、dbtのモデルが整っておらず、レポートごとに独自のSQLで作られている組織では、定義を一元化するLightdashの利点が効きません。Ubieも同じ記事で、多忙な経営メンバーがセルフサービスでBIを使うにはまだ壁が多いと書いています。指標をコードで管理する体制がまだ無い段階なら、dbtを前提にしない製品から比べるほうが現実的です。無償で使えるBIの範囲と有償化の目安は無料BIツール比較｜無償版・OSSの範囲と有償化ライン・導入の判断まで解説で一覧にしています。Metabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】とApache Supersetとは？構成・Docker導入手順とMetabase比較で採用判断を解説【2026年版】で、それぞれの構成と導入手順を解説しています。

よくある質問

Lightdashは無料で使えますか？

OSS版を自社環境で自己ホストすれば無料で使えます。ただし packages/backend/src/ee 配下のAIエージェント、MCP、SCIMなどは別ライセンスで、本番利用にはEnterprise契約が必要です。マネージド版のCloud Proは月額3,000ドルで、21日間の無料トライアルがあります。

dbtを使っていなくてもLightdashを導入できますか？

導入できます。Lightdash YAMLで、ウェアハウスにある既存のテーブルを sql_from で指定し、ディメンションとメトリクスを定義します。Lightdash YAMLはテーブルの作成や変換をしないため、集計しやすい形のテーブルは別の手段で用意しておく必要があります。

LightdashのSSOはどのプロバイダーに対応していますか？

料金表では、Open SourceとCloud ProのSSOはGoogleのみで、OktaやAzureなどのプロバイダーはEnterpriseプランの対象です。社内のIDプロバイダーがGoogle以外なら、Enterpriseの見積もりを前提に比較してください。

Lightdash CloudとSelf-hostedはどちらを選ぶべきですか？

公式はほとんどの企業にCloudを勧めています。自己ホストが向くのは、情報セキュリティ部門がCloudを承認するまで自社インフラで概念実証をしたい場合や、独自の改修をしたい場合です。自己ホストではイメージのバージョン固定と月1回以上の更新を自社で回すことになります。

Lightdashはカタカナで何と書きますか？

公式の日本語ページ（lightdash.com/jp）も製品名は英字の「Lightdash」のみで、カタカナ表記はありません。日本語の記事や検索では「ライトダッシュ」と書かれることがありますが、資料や稟議書には英字表記を使うと公式情報と照合しやすくなります。

関連記事

• dbtとは？ELTのTを担う仕組みとdbt Core・Cloudの選び方【2026年版】
• Metabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】
• Apache Supersetとは？構成・Docker導入手順とMetabase比較で採用判断を解説【2026年版】
• dbtの三層構造においてmarts層が最終データ整備を担う原則
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説