Lightdash（ライトダッシュ）とは？dbtで指標を定義するOSS BIの料金・AI機能・導入手順【2026年版】

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

この記事では、2026年10月時点のライセンスと料金、AI機能の提供条件、指標の書き方、導入手順、チャートのコード管理、API、他のBIとの選び分けを、公式ドキュメントとリポジトリで確認した内容で整理します。

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

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

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

自己ホストについて、公式はほとんどの企業にLightdash Cloudを勧めています。LTS版が無く、GitHubのリリースは2026年10月に1日10件を超える日もあるため、少なくとも月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層とは？3層の分け方とMetricFlowで指標を定義する手順【dbt 1.12対応】で整理した考え方がそのまま使えます。

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

dbtを導入していない場合は、Lightdash YAMLを使います。プロジェクト直下の lightdash.config.yml にウェアハウスの種類を書き、models/ 配下のファイルで sql_from に既存テーブルを指定する形式です。Lightdash YAMLはテーブルを記述するだけで、作成や変換はしません。

dbt MetricFlowで定義済みの指標は、Lightdashが対応する種類なら二重に書く必要はありません。lightdash deploy がコンパイル済みの manifest.json からMetricFlowの指標を読み取り、Lightdashのメトリクスに変換します。条件はdbt Core 1.6以降で、同じ名前の指標が meta.metrics にもある場合は meta.metrics 側が優先されます。この連携はベータ版で、simpleのほか、入力が同一モデル内にあるratio・derivedなどに対応します。一方、cumulative・conversionやモデルをまたぐratio・derivedなどは変換されず、警告が出ます。

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

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

2026年10月19日時点で、ee 配下の services には AiAgentService、McpService、AppGenerateService（Data Apps）、AiWritebackService、ScimService、EmbedService などが並びます。OSS版を無料で自己ホストするつもりで評価を始めると、これらを本番で動かす段階で契約が必要になります。

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

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

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

AIエージェント・MCPサーバー・Data Apps：AI機能の提供条件

2026年のLightdashは、料金ページのCloud Proの説明で「AI-native BI platform」を名乗り、AI機能を3つの形で提供しています。どれもdbtで定義したセマンティックレイヤーを通してクエリを組むため、指標の定義と権限設定がAIからの問い合わせにもそのまま適用されます。逆に言えば、メトリクスの説明文や結合の定義が薄いプロジェクトでは、AIの回答精度も上がりません。

AIエージェントとMCPサーバーの違いと接続方法

AIエージェントは、Lightdashの画面やSlackで自然言語の質問を受け、チャート・表・要約・Data Appのいずれかで答える機能です。MCPサーバーは向きが逆で、Claude・ChatGPT・Codex・Cursor・VS CodeといったLightdashの外のAIアシスタントから、Lightdashの指標を検索してクエリを実行させます。公式のMCPドキュメントでは、接続先は https://<インスタンス名>.lightdash.cloud/api/v1/mcp で、対話型のクライアントはOAuthで認証し、ヘッドレスな連携では個人アクセストークンも使えます。MCPサーバーの仕組み自体はMCP（Model Context Protocol）とは？AIと外部ツールをつなぐ標準規格の仕組みをわかりやすく解説で説明しています。

# Claude Codeから接続する例（公式ドキュメント記載のコマンド）
claude mcp add --transport http lightdash 'https://<インスタンス名>.lightdash.cloud/api/v1/mcp'

提供条件は資料によって書き方が違うため、契約前に確認が必要です。MCPは「Lightdash Cloudの全ユーザーが利用可能、自己ホストはEnterpriseライセンスが必要」とドキュメントに明記されています。AIエージェントは、料金ページのCloud Proの項目に「AI agents and MCP」と並ぶ一方、AIエージェントのドキュメントは「全プランで利用できるアドオン」と書き、料金比較表のAI agents行ではCloud Proが利用可能の表示、Enterpriseが「Custom pricing」となっています。追加料金の有無と上限は見積もり時に確かめてください。

Data Apps（ベータ）とカスタムチャートの提供範囲

Data Appsは、作りたい画面を文章で指示すると、コーディングエージェントが隔離されたサンドボックスでReactアプリを生成し、セマンティックレイヤーのデータでそのまま動かす機能です。2026年10月19日時点ではベータ版で、「当面は無料、一般提供後の料金は未定」とされています。ベータ期間中は仕様変更への対応や一般提供後の追加費用が生じる可能性があるため、変更対応の余地がない定型業務への採用は避け、まず検証用途で評価することを勧めます。

グラフの種類を増やす手段も同じ線引きです。チャートライブラリやChart Studioで作るカスタムチャートはEnterprise機能で、Data Appsの実行環境が必要です。Enterpriseライセンスが無くても使えるのは、Vega-Liteで記述する基本的なカスタマイズです。

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

メトリクスの書き方はdbtのバージョンで変わります。dbt v1.10以降は meta を config の下に置き、v1.9以前は列やモデルの直下に meta を書きます。v1.10へ上げると旧書式に非推奨の警告が出るため、公式は書き換えを自動化する「MetaMove」を案内しています。Lightdashのドキュメントには「Lightdash works with dbt Core v2」とあり、Fusionでビルドするプロジェクトも従来と同じ手順でコンパイルされます。次は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モデルの全列ぶんのディメンション定義を生成できます。

画面上で作るカスタムメトリクスは、そのチャートの中にだけ保存され、同じテーブルから新しいチャートを作るときの一覧には出てきません。複数のレポートで使う指標は、画面で試して確定したらYAMLに書き戻すと、定義の二重管理を避けられます。

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

Lightdash CLIのインストールとpreview・deployの使い分け

公式はmacOS・Linux x86_64・Windows（WSL）でHomebrewを推奨しています。npmの @lightdash/cli は代替手段で、利用にはNode.js 24以降が必要です。

brew tap lightdash/lightdash
brew trust lightdash/lightdash
brew install lightdash
lightdash --version

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

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

注意したいのが lightdash deploy の挙動です。CLIリファレンスは、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手順は、ローカルでの概念実証用です。ただし、Composeファイルの公開ポートはlocalhost限定ではないため、外部からの到達可否はホストのネットワーク設定やファイアウォールに依存します。リポジトリを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内のデータにアクセスできなくなると明記しています。検証環境でも値を控えてから起動してください。また、接続に使うLightdash CLIは、起動したサーバーと同じバージョンに揃えてください。

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

本番向けには公式Helmチャートを使ったKubernetes構成が案内されていますが、公式の比較ページはほとんどの企業にLightdash Cloudを勧めています。

見積もりに入れておきたいのが更新の頻度です。バージョンは major.minor.patch のセマンティックバージョニングで、マイナー版にも後方互換性のない変更が入りうるとされ、LTSや安定版のタグはありません。公式の更新ガイドは image.tag を特定のバージョンに固定し、少なくとも月1回は検証環境を経て更新するよう勧めています。GitHubのリリースは2026年9月14日の2.211.4から10月19日の2.605.0まで、約1か月でマイナー番号が394進みました。2026年10月16日（UTC）には19件のリリースが公開されています。検証の手間はリリース件数そのものより、利用中の版から移行先までの変更内容で決まります。更新を数か月止めるほど確認する変更が増えるため、月1回の更新を前提に担当者の工数を見積もってください。

チャートとダッシュボードをコードで管理する：lightdash download・upload

指標だけでなく、画面で作ったチャートやダッシュボードもYAMLとして取り出して編集できます。lightdash download がプロジェクトのチャートとダッシュボードを作業ディレクトリの lightdash/ 配下へ書き出し、lightdash upload が変更をLightdashへ戻します。新規のチャートを作るときは --force が必要です。

# 特定のダッシュボードだけを書き出す
lightdash download -d https://<LightdashのURL>/<ダッシュボードのURL>

# 編集したYAMLを戻す（新規作成を含むなら --force、反映後に検証するなら --validate）
lightdash upload --force --validate

# dbt側の変更で壊れたチャートを一覧する
lightdash validate

運用で事故が起きやすいのは同時編集です。公式のガイドは、YAMLを使い捨ての作業ファイルとして扱う方式では同時編集に対応せず、最後のアップロードが先の変更を上書きすると明記しています。uploadはアプリ側で加えられた変更も上書きします。同じダッシュボードを複数人が触る組織では、Gitを正本にして画面からの編集を閲覧のみに絞り、mainへのマージ時にCIで lightdash deploy と lightdash upload --force を続けて実行する方式を選びます。

列名を変えたときは lightdash rename で、保存済みのチャートに残る古いフィールド名を一括で置き換えられます。マージ前のCIでは、lightdash validate で変更後の定義と保存済みコンテンツを照合し、renameは --dry-run で変更対象だけを確認します。実際のrenameはプレビュープロジェクトで検証し、本番への適用はマージ後のデプロイと合わせて行います。

定期配信・Google Sheets同期・SQL Runner：dbtの定義の外で使う機能

定期配信は保存済みのチャートやダッシュボードをメールかSlackへ送る機能で、頻度は毎時・毎日・毎週・毎月かCron式、形式は画像・CSV・.xlsx・PDFから選びます。配信されたファイルは既定で3日後に失効し、古いメールやSlackの画像は表示されなくなります。残したいデータはファイル添付で送るか、Google Sheetsへの定期同期を使います。

SQL Runnerは、セマンティックレイヤーを通さずに任意のSQLを書いてチャートを作る画面です。書いたクエリは保存済みチャートにでき、Virtual Viewとして再利用できるテーブルにするか、dbtのモデルとして書き戻すこともできます。使えるのはdeveloperかadminの権限を持つユーザーだけです。2024年3月のSuperset・Metabaseとの比較記事では「カスタムSQLは実行できるが保存できない」と評価されていましたが、現在の仕様では当てはまりません。

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

Lightdash APIは、個人アクセストークン（Personal access token）で認証します。トークンは設定画面の personal access tokens から発行し、CLIの認証にも同じものを使えます。公式のOpenAPI定義（swagger.json）では、Authorization ヘッダーに「ApiKey」の接頭辞を付けて渡す形式です。Bearerではないので、他のSaaSのAPIクライアントを流用するときは書き換えてください。2026年10月19日時点のswagger.json（info.version 2.605.0）には662のパスが定義されており、仕様は利用中のバージョンに対応する定義で確認してください。

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

v2のクエリ系は応答の型名が ApiExecuteAsyncMetricQueryResults のとおり非同期実行で、実行と結果取得（query/{queryUuid}）が別のパスに分かれています。スクリプトでは実行後にqueryUuidで結果を取得し、未完了なら間隔を空けて再取得します。AIアシスタントから指標を問い合わせたいだけなら、APIを自前で包むより前章のMCPサーバーのほうが手数が少なく済みます。

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の定義へ変換させる手順です。ダッシュボードは移行後のモデルに合わせて再構築します。公式ガイドには画面での再作成に加え、AIエージェントによるcontent as codeの生成も案内されているため、数が多い場合は自動化と移行支援の範囲を見積もり時に確認してください。

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

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

一方で、dbtのモデルが整っておらず、レポートごとに独自のSQLで作られている組織では、定義を一元化するLightdashの利点が効きません。指標をコードで管理する体制がまだ無い段階なら、dbtを前提にしない製品から比べるほうが現実的です。オープンソースのBIを横並びで比べるなら無料BIツール比較｜無償版・OSSの範囲と有償化ライン・導入の判断まで解説、個別の構成はMetabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】とApache Supersetとは？構成・Docker導入手順とMetabase比較で採用判断を解説【2026年版】で解説しています。dbtのモデル設計からダッシュボードの運用設計までまとめて検討する場合は、BIツール導入支援で要件整理から相談できます。

よくある質問

Lightdashは無料で使えますか？

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

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

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

Lightdash Enterpriseでないと使えない機能は何ですか？

料金表では、OktaやAzureなどGoogle以外のSSO、SCIM 2.0、カスタムロール、デプロイ先の個別指定がEnterpriseの対象です。自己ホストでは、これに加えてAIエージェント・MCP・Data Appsの本番利用にもEnterpriseライセンスが要ります。社内のIDプロバイダーがGoogle以外なら、Enterpriseの見積もりを前提に比較してください。

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

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

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

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

関連記事

• dbtとは？ELTのTを担う仕組みとdbt Core・Cloudの選び方【2026年版】
• dbtのmarts層とは？3層の分け方とMetricFlowで指標を定義する手順【dbt 1.12対応】
• Metabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】
• Apache Supersetとは？構成・Docker導入手順とMetabase比較で採用判断を解説【2026年版】
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説