BI as Code ツール調査メモ
Claude先生に最近の”BI as Code”ツールについて調べてもらったまとめ。以下書いてもらったまま。
BI as Code に関するツールを調べた。BI as Code とは、ダッシュボードや指標定義などの BI 成果物をコードとして管理するアプローチで、Git によるバージョン管理・レビュー・CI/CD といったソフトウェア開発のプラクティスをデータ可視化の領域に持ち込むものだ。
ツール一覧
A. コードファースト BI
ダッシュボードそのものをコードで定義するツール群。
| ツール | 記述形式 | 出力 |
|---|---|---|
| Evidence.dev | Markdown + SQL | 静的サイト |
| Rill | YAML + SQL | ダッシュボード UI（DuckDB 内蔵） |
| Visivo | YAML + Jinja2 | ダッシュボード（Plotly.js、Python CLI） |
B. dbt 連携型 BI
dbt のセマンティック定義を BI に流用するツール群。
| ツール | 特徴 |
|---|---|
| Lightdash | dbt の YAML をそのまま BI のメトリクス定義に使う |
| Holistics | 独自の AML/AQL コードで指標定義・dbt 連携あり |
C. セマンティックレイヤー as Code
BI の下の指標定義レイヤーをコードで管理するツール群。BI ツールそのものではなく、複数の BI ツールや AI エージェントに対して一貫した指標を提供するミドルウェアとして機能する。
| ツール | 記述形式 | 特徴 |
|---|---|---|
| Cube | JS/TS スキーマ | REST / GraphQL / SQL API を提供 |
| dbt Semantic Layer（MetricFlow） | YAML | dbt 上でメトリクスを定義・Apache 2.0 OSS |
D. コードベースのデータアプリフレームワーク
BI 隣接領域のコードベースフレームワーク。ダッシュボードというよりデータアプリや分析ドキュメントの構築に使われる。
| ツール | 言語 | 特徴 |
|---|---|---|
| Observable Framework | JS/TS + SQL | 静的データアプリ・D3/Plot と統合 |
| Streamlit | Python | 高速プロトタイプ向け Web アプリ |
| Quarto | R / Python / Julia | ドキュメント・レポート・出版向け |
| Shiny | R / Python | インタラクティブ Web アプリ |
E. BI as Code 的な機能を持つ商用 BI
コード管理機能を備えた商用 BI ツール。
| ツール | コード形式 | 備考 |
|---|---|---|
| Looker（LookML） | LookML | Google 傘下・独自 DSL |
| Omni | YAML 的モデル + Git | Looker の思想を継承・改良 |
| ThoughtSpot（TML） | YAML ベース TML | 検索ファーストと組み合わせ |
| GoodData | MAQL + LDM | MCP サーバー対応済み（2025） |
各ツール詳細（A・B カテゴリ）
Evidence.dev
- 記述形式: Markdown + SQL（
.mdファイルにクエリを埋め込む） - 出力: 静的サイト（Vercel / Netlify / セルフホスト）
- ライセンス: MIT（完全 OSS）
- データソース: BigQuery / Snowflake / Redshift / PostgreSQL / DuckDB / MotherDuck / Databricks / Google Sheets / CSV 等
.md ファイルの中に SQL クエリを記述し、<LineChart> や <DataTable> などのコンポーネントに渡すだけでビルドが走り、純粋な静的サイトとして出力される。バックエンドが不要なため運用コストが低く、Vercel などに簡単にデプロイできる。テキストとデータを組み合わせたナラティブ型のレポートが得意で、「分析ドキュメント」に近い用途で力を発揮する。
強み: 構成がシンプルで摩擦が少ない。Git 管理が自然に行える。SQL が書ければすぐ始められる。
弱み: 静的生成のためリアルタイム更新なし。エンドユーザーによるアドホックな絞り込み・探索は不可。Markdown と SQL が書けることが前提のため非エンジニアには向かない。
Rill
- 記述形式: YAML + SQL
- 出力: インタラクティブなダッシュボード UI（ローカル起動 or クラウドデプロイ）
- ライセンス: OSS コアあり
- バックエンド: DuckDB（中小規模）/ ClickHouse（大規模・数十億行）/ MotherDuck / Druid / Pinot 等の外部 OLAP エンジンにも接続可
YAML でソース・モデル・ダッシュボードを定義し、ローカルで rill start するとブラウザ上でインタラクティブなダッシュボードが即座に立ち上がる。DuckDB を内蔵しているため小〜中規模データなら追加インフラなしで高速に動く。大規模データには ClickHouse を外部接続できる。MCP サーバー対応により AI エージェントがセマンティックレイヤーに直接クエリを投げる構成も実現できる。
強み: ローカル開発の即時フィードバック、OLAP ベースの高速クエリ、AI エージェント連携（MCP）、インクリメンタル取り込みや行レベルアクセスポリシーなどの運用機能。
弱み: データを Rill 側に取り込む必要があり既存 DWH をそのまま参照しにくい。ビジュアライゼーションの種類は多くない。機能がまだ成熟途上。
Visivo
- 記述形式: YAML + Jinja2（Python CLI）
- 出力: ダッシュボード（Plotly.js ベース、50 種以上のチャート）
- ライセンス: OSS
- データソース: PostgreSQL / Snowflake / BigQuery / MySQL / SQLite / DuckDB / CSV / Excel
YAML でチャートやダッシュボードを定義し、Jinja2 テンプレートで環境変数や条件分岐を使った動的生成が可能。dbt プロジェクトの DAG と接続して lineage ベースの BI 管理ができる点が特徴的で、visivo test による Python テストフレームワークも内蔵している。VS Code 向けのリンター・オートコンプリート拡張もある。
強み: Python テストフレームワーク内蔵、dbt との DAG 連携と lineage 管理、Jinja2 による動的ダッシュボード生成、Plotly.js による豊富なチャート種類。
弱み: コミュニティが小さくドキュメントが少ない。知名度が低く日本語情報はほぼない。
Lightdash
- 記述形式: dbt の
schema.ymlに追記するだけ - 出力: Explore UI + ダッシュボード
- ライセンス: OSS（セルフホスト無料、クラウド $600/月〜）
- 必須条件: dbt プロジェクトが必要
dbt のモデルが持つカラム定義に数行追記するだけでメトリクスや次元が Lightdash の探索 UI に反映される。変換ロジックと指標定義が同じ YAML に同居するため、dbt 側の変更が BI 側に自動で反映され「指標の計算がツールによってずれる問題」を構造的に解消できる。2025 年以降は AI エージェントによる自然言語クエリ・ダッシュボード自動生成（アジェンティック BI）の機能拡充が進んでいる。
強み: dbt と完全に統合されており追加のメンテコストが低い。バージョン管理が標準で備わっている。プレビュー環境でダッシュボード変更を事前検証できる。
弱み: dbt なしでは使えない（強依存）。ビジュアライゼーションの種類が限られる。埋め込み分析の機能は弱い。
Holistics
- 記述形式: AML（Analytics Modeling Language）+ AQL（独自クエリ言語）、Git 連携あり
- 出力: BI プラットフォーム（ダッシュボード + 非エンジニア向け self-serve）
- ライセンス: クラウド専用（セルフホスト不可）、$960/月〜（100 レポート・10 ユーザー）
Looker の LookML に近いコードベース設計の BI ツールで、独自の AML でデータモデルや指標を定義し Git 管理できる。dbt との連携も深く、dbt モデルの変更を自動で BI レイヤーに反映し、同一リポジトリで dbt と AML コードを共存できる。非エンジニアのビジネスユーザーでも SQL なしで探索できる self-serve 機能が充実している点が他の BI as Code ツールとの大きな違い。
強み: 非エンジニアも使える self-serve、Looker に近い指標ガバナンスをより安価に実現、Git 連携の成熟度が高い、dbt との自動連携。
弱み: 高価格（最低 $960/月〜）でスタートアップや小規模チームには重い。クラウド専用でセルフホスト不可。独自言語（AML/AQL）の学習コストがある。
A・B カテゴリ 比較
技術特性
| Evidence | Rill | Visivo | Lightdash | Holistics | |
|---|---|---|---|---|---|
| 記述形式 | Markdown + SQL | YAML + SQL | YAML + Jinja2 | dbt YAML 追記 | AML / AQL |
| データ取得方式 | ビルド時にクエリ | Rill に取り込み | クエリ直接発行 | DWH に直接クエリ | DWH に直接クエリ |
| リアルタイム更新 | なし（静的） | OLAP による高速応答 | DWH 依存 | DWH 依存 | DWH 依存 |
| dbt 連携 | 任意（独立） | 任意（独立） | DAG 連携あり | 必須・完全統合 | 自動同期あり |
| セルフホスト | ◯ | ◯ | ◯ | ◯ | 不可 |
| OSS | MIT | コアのみ OSS | ◯ | ◯ | クローズド |
| 費用 | 無料 | 無料〜有料 | 無料 | 無料〜$600/月 | $960/月〜 |
ユーザー・組織特性
| Evidence | Rill | Visivo | Lightdash | Holistics | |
|---|---|---|---|---|---|
| 主な利用者 | データエンジニア・アナリスト | データエンジニア | データエンジニア | アナリティクスエンジニア | アナリスト〜ビジネスユーザー |
| 非エンジニアの自己解決 | 不可 | 限定的 | 不可 | 限定的 | 可（SQL 不要） |
| 学習コスト | 低（SQL + Markdown） | 低〜中（YAML + SQL） | 中（YAML + Jinja2 + Python） | 低（dbt を知っていれば） | 中〜高（AML/AQL 習得が必要） |
| チーム規模感 | 個人〜小チーム | 小〜中チーム | 小〜中チーム | 中〜大チーム | 中〜大チーム（企業向け） |
ユースケース適合度
| ユースケース | Evidence | Rill | Visivo | Lightdash | Holistics |
|---|---|---|---|---|---|
| 定期レポート・分析ドキュメント | 最適 | △ | △ | △ | △ |
| インタラクティブな探索・絞り込み | 不可 | ◯ | ◯ | ◯ | ◯ |
| dbt 既存プロジェクトへの追加 | 任意で可能 | 任意で可能 | 自然に統合 | 最適 | ◯ |
| 大規模データ（数十億行） | △（DWH 依存） | ◯（ClickHouse） | △（DWH 依存） | △（DWH 依存） | △（DWH 依存） |
| AI エージェント連携 | △ | ◯（MCP 対応） | △ | ◯ | △ |
| 非エンジニアへのセルフサービス提供 | 不向き | 不向き | 不向き | 限定的 | 最適 |
| 埋め込み分析（外部サービスへの組み込み） | 静的サイトとして可 | ◯ | △ | 弱い | ◯ |
| コスト重視・スモールスタート | 最適 | ◯ | ◯ | ◯ | 不向き |
まとめ：こういうチームに向いている
Evidence: dbt などのデータパイプラインの成果を「読む人向けに届ける」定期レポートや分析ドキュメントが主な用途。エンジニアが自分のチームや社内向けに書くレポートとして非常に低コストで始められる。探索機能は不要で、伝えたいことが決まっている場合に向く。
Rill: 大量データを高速に集計してインタラクティブに探索したいチーム向け。DuckDB / ClickHouse の OLAP 性能を活かした運用 BI や、AI エージェントが分析基盤に直接クエリを投げる構成（MCP）を検討しているチームにも向く。データを Rill に取り込む前処理が必要な点は考慮が必要。
Visivo: Python や dbt に慣れたデータエンジニアが、BI をコードとしてフルに管理し、テストも書きたい場合に向く。コミュニティが小さいため、自力で問題を解決できる前提が必要。
Lightdash: すでに dbt を本番稼働させているチームにとって最も自然な選択肢。dbt の YAML に数行追記するだけで BI に展開でき、指標定義が一元化される。dbt を使っていないなら採用する理由はほとんどない。
Holistics: ビジネスユーザーへの self-serve 提供が必要で、かつ Looker のような指標ガバナンスを求めるチーム向け。価格が最も高く OSS でもないため、費用対効果の検討が重要。すでに Looker を使っていてコストを下げたい場合の移行先候補にもなりうる。