dac validate や dac serve など、開発・確認用のCLIが用意されているGitHubで公開されている bruin-data/dac は、ひとことで言うと ダッシュボードをコードとして定義するためのツールです。
名前のとおり DaC = Dashboard-as-Code。Infrastructure-as-Code（Terraformみたいな「インフラをコードで管理する」考え方）の、ダッシュボード版だと思うとイメージしやすいです。
普通、ダッシュボードはBIツールの画面上でポチポチ作ることが多いですよね。あれは直感的で便利なんですが、規模が大きくなると途端にしんどくなります。
このあたりの「あるある」に、DaCはかなり真正面から向き合っている印象です。
個人的には、**“レビューしやすいダッシュボード”** という発想がかなり重要だと思います。見た目がきれいでも、定義が雑だと分析の信用が落ちるので、そこをコードで固めるのは筋がいいです。
READMEには、DaCが YAML and TSX でダッシュボードを定義できるとあります。
要するに、用途によって書き方を選べるのがポイントです。
YAML
人間が読みやすい設定ファイル。
「このダッシュボードには、こういうwidgetを置く」といった構造を素直に書きやすいです。
TSX / JSX
React系の文法で、コンポーネントや条件分岐、繰り返し処理が書ける方式。
つまり、ただの設定ではなく、ロジック込みでUIを組めるのが強みです。
READMEには、TSXで dynamic charts, tabs, loops and conditionals に対応するとあります。
これは地味に大きいです。ダッシュボードって、現実には「表示条件がある」「同じ形式のカードを複数並べたい」「タブで切り替えたい」みたいな要件が多いので、YAMLだけだと限界が来やすいんですよね。そこにJSX系の表現力を持ち込むのは、かなり自然な進化だと思います。
このプロジェクトの一番おもしろいところは、READMEが強く押している built-in semantic layer です。
semantic layer をざっくり言うと、
「売上」「顧客数」「利益率」みたいな指標の定義を、SQLのあちこちに散らさず、一か所で管理する仕組み」です。
たとえば、同じ「売上」でも人によって
SUM(amount)SUM(revenue)SUM(price * quantity)みたいに定義がズレると、会議で話が噛み合わなくなります。
semantic layer があると、メトリクスやdimensionsを一度定義して、それを各widgetから参照できるようになります。READMEでも「DAC generates the SQL」と書かれていて、SQLを毎回手書きする代わりに、裏側で生成してくれる設計のようです。
これはかなり実務向きです。
特にチームでダッシュボードを作るとき、**“指標の定義が統一されている”** ことは、見た目以上に価値があります。派手さはないけれど、運用がラクになるタイプの機能ですね。
READMEには、DaCは “AI agents to build dashboards in a reliable and reviewable way” のために作られているとあります。
つまり、単に人間向けの便利ツールというより、AIにダッシュボードを作らせる前提がかなり強いです。
ここは今っぽいし、正直かなり攻めているなと思いました。
AIにUIを作らせると、見た目はそれっぽくても、
という問題が出がちです。
DaCはそこに対して、YAML/TSXの明示的な定義、semantic layer、validateコマンド で「作ったあとに確認しやすい形」に寄せているわけです。
個人的には、AI時代の開発で本当に大事なのは「AIが作れること」より「人間があとから理解・監査・修正できること」だと思っています。DaCはその方向にかなり寄っていて、思想として好感が持てます。
READMEには、スタータープロジェクトを作る流れが載っています。
dac init my-dashboards
cd my-dashboards
dac validate --dir .
dac serve --dir . --open
ざっくりいうと、
init でひな形を作るvalidate で設定や定義をチェックするserve でローカル表示するという流れです。
これは開発体験としてかなり重要です。
ダッシュボード系のツールは、作成画面はあっても、壊れていないかを機械的に確認する仕組みが弱いことがあります。そこを validate で押さえているのは素直に良いですね。
また、READMEには Bruin connections を使うとあり、実行時には bruin query に頼る形だと書かれています。
つまり、DaC単体というより、Bruinエコシステムの上に乗っている感じです。既存の接続設定を活かせるのは、導入のハードルを下げそうです。
READMEでは、以下のような主要データベースに対応するとされています。
この広さはありがたいです。
分析基盤って、会社によって本当にバラバラですからね。BigQuery派もいれば、Snowflake派もいるし、伝統的にPostgresで頑張っている現場もあります。
そういう意味で、特定のDBに閉じていないのは導入しやすさにつながると思います。
リポジトリには、4つのサンプルプロジェクトがあると書かれています。
examples/basic-yamlexamples/basic-tsxexamples/semantic-yamlexamples/semantic-tsxここがちゃんとしているツールは、だいたい使いやすいです。
なぜなら、抽象的な説明だけでなく、実際にどう書くかを見せてくれるからです。
ダッシュボード系の新しい仕組みは「概念はいいけど、結局どう書くの？」で詰まりがちなので、サンプルが複数あるのはかなり好印象です。
READMEには構成も載っています。
cmd/ : CLI entrypointspkg/ : dashboard loading, semantic engine, server, query backendsfrontend/ : React frontenddocs/ : VitePress documentationexamples/ : 実行可能なサンプルresources/ : READMEや資料testdata/ : テスト用のフィクスチャぱっと見、小さな玩具ツールではなく、きちんとした製品として育てる前提の構成です。
GoでCLIとバックエンドをまとめつつ、frontend に React を埋め込んでいるのも今どきです。
私はこういう「裏は堅く、表は柔らかい」構成、けっこう好きです。
READMEには telemetry についての説明もあります。
匿名の利用状況イベントを送るとのことですが、収集内容はかなり限定されています。
収集するものとして挙げられているのは、
一方で、収集しないものも明記されています。
これはかなり誠実です。
telemetry という言葉だけ聞くと身構える人も多いですが、「何を取らないか」をはっきり書いているのは信頼につながります。
もちろん、telemetry 自体を好まない人もいるので、TELEMETRY_OPTOUT=1 や DO_NOT_TRACK=1 で止められるのも大事です。
DaCは、単なる「ダッシュボード作成ツール」ではなく、
“AI時代に、壊れにくくレビューしやすい形でダッシュボードを管理する” という思想がかなり前面に出ています。
ここが面白いところです。
世の中には「作れる」ツールはたくさんあります。でも、実運用では「作れて終わり」ではなく、
このあたりが効いてきます。DaCはそこを真面目に狙っていて、単なる流行りものではなさそうだと感じました。
もちろん、こういうコードベースのダッシュボードは、非エンジニアにとっては少し敷居が上がる可能性があります。
なので、「誰でもすぐ触れる」というよりは、データチームや開発チームが運用するダッシュボード基盤として強いのではないか、と思います。
DaCは、次のような人・チームに向いていそうです。
逆に、とにかく画面上でサクッと作りたいだけなら、従来型のBIツールのほうが合う場面もあるでしょう。
DaCは思想がはっきりしているぶん、合う人には刺さるけれど、万人向けの軽いツールではない、という印象です。
DaCは、ダッシュボードをコードとして管理する Dashboard-as-Code の実装です。
YAMLでわかりやすく、TSX/JSXで柔軟に、さらに semantic layer で指標の定義を統一できる。しかもAI agentとの相性まで考えられている。
この組み合わせ、かなり今の時代に合っていると思います。
「見た目のダッシュボード」ではなく、再利用できて、レビューできて、AIでも扱いやすいダッシュボードを目指しているのがDaCの本質でしょう。
地味だけど重要な問題にちゃんと答えようとしているところが、個人的にはかなり好印象でした。