生成AI時代のダッシュボード制作譚
Udemyで、EvidenceとClaude Codeを使ってダッシュボードを作成する講座を作りました。
テーマとしては、いわゆる BI as Code （Business Intelligence as Code）です。
BI as Codeという言葉は、まだ日本ではそれほど一般的ではないかもしれません。ただ、今回Evidenceを実際に使いながら講座を作ってみて、私はかなり強くこう感じました。
これは、生成AI時代のBIのひとつの方向性なのではないか。
もちろん、現時点でEvidenceがTableau、Power BI、データポータル（Looker Studio）などの一般的なBIツールをすぐに置き換えるとは思っていません。むしろ、ダッシュボード作成の主役は、当面まだ従来型のBIツールだと思います。
一方で、Evidenceには、従来のBIツールとはかなり違う思想があります。
そして、その思想が生成AIと非常に相性が良い。
そこでこの記事では、講座には入れきれなかった、Evidenceを学びながら感じた魅力や開発途上な点、BI as Codeについて考えたことを、作者目線で振り返ってみたいと思います。
もちろん、講座を受講してもらえたら嬉しいな、という気持ち満載でお届けします。笑
Evidenceは、まだ発展途上。でも、とても魅力的なBIプラットフォーム
まず、Evidenceというツールについて、私自身がどう感じたかを一言でいうと、
まだ発展途上の部分はある。けれど、生成AIとともに進化する可能性を強く感じる、とても魅力的なBIプラットフォーム
です。この記事では、私が魅力的に感じた点を3点、発展途上だと思った点を3点にまとめてお届けします。
魅力的な点1：生成AIと一緒に作りやすい
Evidenceの一番大きな魅力は、生成AIと一緒にダッシュボードを作りやすいことだと思います。
Evidenceは、MarkdownとSQLを組み合わせてダッシュボードを作ります。そのため、Claude Codeのような生成AIコーディング支援ツールに、
「日別の表示回数を折れ線グラフにしてください」
「KPIカードを作ってください」
「期間フィルタをすべてのグラフに効かせてください」
といった依頼がしやすい。
従来のBIツールでは、画面にグラフやフィルタを配置するには人間が画面上で操作する必要があります。一方、Evidenceでは生成AIが直接コードを書き換えられます。
この感覚が、Evidenceならではの面白さだと思いました。
魅力的な点2：SQLで柔軟にグラフ用データを作れる
Evidenceを使っていて新鮮だったのは、グラフ作成の考え方です。
従来のBIツールでは、データソースにあるディメンションや指標を選びながらグラフを作ることが多いと思います。不足しているディメンションや指標は計算式で作ります。左カラムや右カラムにはデータソース上の項目、計算式で作った項目をあわせた項目一覧が並びます。
一方、Evidenceでは、グラフごとに必要なデータをSQLで作ります。
日別の表示回数を見たいなら、日付ごとに集計するSQLを書く。
クエリ別ランキングを作りたいなら、クエリ別に集計するSQLを書く。
KPIを出したいなら、クリック数、表示回数、CTRなどを集計するSQLを書く。
つまり、「グラフに必要な形のデータを、SQLで作ってから可視化する」という考え方です。
これには最初は少し戸惑いますが、慣れると非常に柔軟です。SQLで表現できる指標や切り口であれば、自由にグラフにできます。特に、指標定義を明確に残したい場合や、複数のグラフで同じ条件を使い回したい場合には、Evidenceの思想はかなりしっくり来ます。
魅力的な点3：ダッシュボードをコードとして管理できる
Evidenceのもうひとつの魅力は、ダッシュボードをコードとして管理できることです。
ダッシュボードがコードで作られているということは、Gitで変更履歴を管理できます。
- 誰が、いつ、どのSQLを変更したのか。
- どのグラフの定義が変わったのか。
- なぜ指標の数値が変わったのか。
こうしたことを追いやすくなります。
社内でダッシュボードが増えてくると、「どれが正しいのか」「この指標の定義は何か」「いつの間に数値が変わったのか」といった問題が起きがちです。
Evidenceのように、SQLやMarkdownとしてダッシュボードを管理できると、こうした問題に対処しやすくなります。
また、スタイルの調整もコードで行えます。グラフタイトルのフォントサイズ変更、KPIカードの余白調整、全体レイアウトの統一なども、生成AIに相談しながら進めやすい。このあたりに、BI as Codeらしさを強く感じました。
発展途上な点1：見た目の美しさは従来型BIツールに分がある
一方で、Evidenceはまだ万能ではありません。まず感じたのは、見た目の美しさです。
正直に言うと、グラフの見た目やダッシュボード全体の美しさという点では、Tableau、Power BI、データポータル（Looker Studio）の方が上だと思いました。従来型のBIツールは、色、凡例、軸、ラベル、ツールチップ、配置などがよく考えられており、短時間で見栄えのするダッシュボードを作りやすいです。
Evidenceでも見た目を整えることはできます。ただ、そのためにはWebやCSSに近い感覚が必要になることがあります。自由度が高いぶん、整えるには少し技術が必要になる。
この点は、Evidenceの発展途上な部分だと感じました。
発展途上な点2：横型レイアウトや複雑な画面構成は工夫が必要
Evidenceは、縦型のレイアウトと相性が良いです。そのため、KPI、グラフ、表、説明文を上から順番に並べ、スクロールしながら読んでいく構成は作りやすいです。
むしろ、数値やグラフだけでなく、文章で補足しながら見せる「データ記事」のような構成は、Evidenceの得意分野だと思います。一方で、横型レイアウトや複雑な画面構成には工夫が必要です。たとえば、経営会議用のダッシュボードのように、1画面に多数のKPIやグラフをきっちり並べたい場合は、TableauやPower BIの方が向いているかもしれません。
EvidenceでもGridやCSSを使えば調整できますが、無理に従来型BIツールと同じ画面を作るより、縦に読み進める構成を活かした方が良いと感じました。
発展途上な点3：企業利用ではアクセス制御に工夫が必要
企業利用を考えるうえで重要なのが、アクセス制御です。
企業で使うダッシュボードでは、誰がどのデータを見られるのかを制御する必要があります。
- Tableau CloudであればTableau側のユーザー管理があります。
- Looker StudioであればGoogleアカウントを使った共有管理があります。
- Power BIであればMicrosoft 365と組み合わせた管理ができます。
一方、Evidenceの場合は、デプロイ先の仕組みを使ってアクセス制御を設計する必要があります。
- どこにデプロイするのか。
- 誰がURLにアクセスできるのか。
- 認証をどうするのか。
- 社内限定にするのか。
こうした点を、Webアプリケーションの公開設計として考える必要があります。
個人学習では非常に面白い一方で、組織やチーム向けの本番ダッシュボードとして使う場合は、デプロイ、認証、権限管理、データ更新まで含めて検討する必要があると思います。
BIツールの来し方行く先
今回、EvidenceでBI as Codeの講座を作りながら、BIツールの進化についても考えました。
私なりに整理すると、BIツールは大きく次の図のように進化してきたのではないかと思います。
まず、中央集権型BIの時代がありました。CognosのようなBIツールを使い、情報システム部門や専門部署が中心となって、企業内のデータを可視化する時代です。この時代、ダッシュボードは誰でも作れるものではありませんでした。
専門部署がデータを集め、加工し、レポートやダッシュボードとして提供する。現場の担当者は、それを見る側に回ることが多かったと思います。この中央集権型BIには、「統制は効きやすいが、各部署で必要なダッシュボードを迅速に作れない」という課題があったと思います。
その課題に対して登場したのが、セルフサービスBIです。TableauをはじめとするBIツールによって、ダッシュボード作成は大きく民主化されました。これは、非常に大きな進歩だったと思います。私自身も、Tableau、データポータル（Looker Studio）、SQL、BigQueryなどを使ったデータ活用には大きな可能性を感じてきましたし、多くの方に教えてきました。ただ、民主化には副作用もあります。
誰でもダッシュボードを作れるようになると、今度はダッシュボードが乱立します。そこでは、
- 似たようなダッシュボードが複数ある。
- どれが正しいのかわからない。
- 同じ「売上」でも、定義が微妙に違う。
などの問題が出てきました。こうなると、せっかくデータ活用を進めたはずなのに、かえって混乱が生まれます。これは、セルフサービスBIが普及した組織ほど起きやすい問題ではないかと思います。
では、次に必要なのは何か。
私は、
民主化と統制の両立
なのではないかと思います。
ここで、EvidenceのようなBI as Code型のプラットフォームが面白くなってきます。
Evidenceでは、ダッシュボードをコードとして管理できます。SQLも、Markdownも、ファイルとして残ります。Gitを使えば、変更履歴も追えます。
- 誰が、いつ、何を変えたのか。
- どのSQLで指標を計算しているのか。
- どのクエリが複数のグラフで使われているのか。
- どこを修正すれば、どのグラフに影響するのか。
こうしたことが、従来型BIツールよりも見えやすくなります。これは、単に「エンジニア向けのBIツール」という話ではありません。むしろ、ダッシュボード作成の民主化を保ちながら、統制を取り戻すための考え方なのではないかと思います。
- 1人の担当者でも、生成AIと一緒にダッシュボードを作れる。
- 一方で、そのダッシュボードはコードとして管理され、変更履歴も追える。
- SQLのロジックも確認できる。
- 共通クエリを使えば、指標定義のブレも減らせる。
これが、Evidenceに私が感じた可能性です。
Evidenceが今すぐ、従来のBIツールを代替するとは思いませんが、生成AI時代において、BI as Codeという考え方は確実に存在感を増していくと思います。これからのデータ人材には、従来型BIツールを使いこなす力に加えて、コードでダッシュボードを管理する感覚も求められるかもしれません。
だとすると、得意なBIツールを最低一つは持ちつつ、EvidenceのようなBI as Code型のアプローチにも触れておく。というのが、かなり良いポートフォリオになるのではないでしょうか。
Evidenceは、これからのBIの可能性を感じさせてくれるツールです。まだ発展途上です。でも、だからこそ面白い。
今回のUdemy講座は、その可能性を体験するための入口として作りました。
生成AI時代のダッシュボード作成に興味がある方。
BI as Codeという考え方に触れてみたい方。
SQLを使って、もう少し自由にダッシュボードを作ってみたい方。
そうした方に、ぜひEvidenceを試していただけたら嬉しいです。
Udemy講座はこちら
という背景で作成した、Udemy講座『BI as Code入門 – EvidenceとClaude Codeで作るAI時代のダッシュボード』はこちらからアクセスできます。（画像をクリックしてください。）
