はじめに
私は今、ちょっと面白い立ち位置にいます。
7月に『いちばんやさしいGoogleデータポータルの教本』というBIツールの書籍を出した一方で、5月には『BI as Code入門 – EvidenceとClaude Codeで作るAI時代のダッシュボード』というUdemy講座をリリースしました。
つまり、「既存のBIツール」と「生成AI活用型のBI as Code」の両方を、教材として世に出している状態です。
すると当然、こう聞かれます。
「で、結局どっちを使えばいいんですか？」
この問いに対する、現時点での私なりの答えを整理してみたいと思います。先に結論を言ってしまうと、今後、BI as Codeは進化するとは思いますが、現状では、必ずどちらかを使うべきということではなくて、「どう使い分けるか」の問題だと思っています。
2つのアプローチをおさらい
まず、それぞれのアプローチを簡単に整理します。
既存ツール型は、データポータル（旧Looker Studio）、Tableau、Power BIなどのBIツールを使う方法です。画面上でデータソースに接続し、ディメンションや指標をドラッグ＆ドロップしながらグラフを配置していきます。ダッシュボード作成の「主流」は、今も間違いなくこちらです。
BI as Code型は、EvidenceのようなツールでSQLとMarkdownを書いてダッシュボードを作る方法です。ダッシュボードが「コード」なので、Claude Codeのような生成AIに「日別の表示回数を折れ線グラフにして」と依頼すれば、AIが直接コードを書き換えてくれます。GUIをポチポチ操作するのは人間にしかできませんが、コードなら生成AIが書けるわけです。
メリット・デメリットの対比
両方を実際に使い、教材まで作ってみて感じた対比を表にまとめます。
| 観点 | 既存ツール型（データポータル等） | BI as Code型（Evidence等） |
|---|---|---|
| 作成のしやすさ | GUI操作で直感的。学習コストが低い | SQLとMarkdownの知識が前提 |
| 生成AIとの相性 | AIは画面操作を代行できない | AIがコードを直接書ける。相性抜群 |
| 見た目の美しさ | 短時間で見栄えよく作れる | 整えるにはCSS的な素養が必要 |
| レイアウト | 1画面に自由配置できる | 縦スクロール型が基本。横型は工夫が要る |
| 変更履歴・統制 | 「いつの間にか数値が変わった」が起きがち | Gitで誰が・いつ・何を変えたか追える |
| 指標定義 | 計算フィールドがブラックボックス化しがち | SQLとして明示的に残る |
| 共有・権限管理 | ツールに組み込み済み（Googleアカウント共有等） | デプロイ・認証を自分で設計する必要がある |
| コスト | データポータルは無料 | ツール自体は無料（OSS）だが、公開先や生成AIの費用は別途 |
こうして並べると、それぞれの得意・不得意がきれいに裏返しになっているのが分かると思います。
既存ツールの強みは「誰でも・早く・きれいに・安全に共有できる」こと。弱みは、ダッシュボードが増えたときに「どれが正しいのか分からない」「同じ売上でも定義が微妙に違う」という統制の問題が起きやすいことです。
BI as Codeの強みは「生成AIと一緒に作れる」「コードとして統制できる」こと。弱みは、見た目・レイアウト・アクセス制御のそれぞれで、Web開発に近い工夫が必要になることです。
適材適所：どちらを選ぶべきか
では、具体的にどう使い分けるか。私は次のように考えています。
既存ツール型が向いているケース
- 組織の「共通の景色」となる定常ダッシュボードを作る場合。経営会議や部署の定例で全員が見る画面は、権限管理と見た目の完成度が重要です
- 作る人・見る人に非エンジニアが多い場合。SQLを書ける人がいなくても、作成も引き継ぎも成立します
- 1画面に多数のKPIやグラフをきっちり並べたい場合。横型レイアウトは既存ツールの得意分野です
- とにかく早く、無料で始めたい場合。データポータルなら今日から作れます
BI as Code型が向いているケース
- SQLを書ける人が、生成AIと組んで高速に作りたい場合。プロンプトでグラフが増えていく体験は、一度味わうと戻れません
- 指標定義のブレをなくしたい場合。「この数字はどのSQLで計算しているのか」が常に確認でき、共通クエリで定義を使い回せます
- 変更履歴やレビューが必要な場合。Gitで管理できるので、「誰がいつ何を変えたか」が追えます
- 数値やグラフを文章で補足しながら見せる「データ記事」型のレポートを作る場合。縦に読み進める構成はEvidenceの得意分野です
判断の軸をひとことで言うと
「見る人の多様さ」と「統制の必要度」の2軸で考えると分かりやすい気がします。
見る人が多様（非エンジニア含む）で、今すぐ共通の景色が欲しいなら既存ツール。作り手がSQLを書けて、指標定義や変更履歴の統制を効かせたいならBI as Code。そんな整理です。
代替ではなく、役割分担
以前の記事（Evidence講座を作りながら考えたBI as Codeの未来）でも書きましたが、BIツールは「中央集権型BI → セルフサービスBI」と進化してきました。セルフサービスBIはダッシュボード作成を民主化しましたが、副作用としてダッシュボードの乱立と指標定義のブレを生みました。
次に必要なのは「民主化と統制の両立」で、BI as Codeはその答えのひとつだと思っています。ただし、今すぐ既存ツールを置き換えるものではありません。当面の主役は既存ツールのままでしょう。
だからこそ、これからのデータ人材のポートフォリオとしては、
得意なBIツールを最低ひとつ持ちつつ、BI as Codeにも触れておく
というのが、かなり良い組み合わせなのではないかと思います。
おわりに
というわけで、両方の入口を用意しています。笑
- 既存ツール型を学ぶなら：『いちばんやさしいGoogleデータポータルの教本』（インプレス）
- 既存ツール型をさらに深く学ぶなら：『Looker Studio大全』（技術評論社）
- BI as Code型を学ぶなら：Udemy講座『BI as Code入門 – EvidenceとClaude Codeで作るAI時代のダッシュボード』
ご自身の状況に合わせて、どちらか（あるいは両方）を手に取っていただけたら嬉しいです。