AIに「このデータを分析して」と頼むと、SQLやグラフの案が返ってくる。
この流れは、かなり現実的になっています。
以前は、社内データを見える化するには、BIツールの画面を操作し、項目を選び、グラフを作り、細かな表示を調整する必要がありました。今は、Markdown、SQL、可視化コンポーネントを組み合わせたファイルをAIに書かせ、レポートやダッシュボードを作る選択肢も出ています。
Evidenceの公式ドキュメントでは、EvidenceはSQLでレポート、意思決定支援ツール、埋め込みダッシュボードなどのデータプロダクトを作るためのオープンソースフレームワークと説明されています。公式サイトでも、ドラッグ&ドロップ型BIの代替となるコードベースの選択肢として紹介されています。
これは便利です。
ただし、中小企業がここで見るべき論点は「どのBIツールが新しいか」だけではありません。
本当に大事なのは、ダッシュボードを画面として作る前に、指標の定義を会社の資産として残せるかです。
この記事では、AI時代にダッシュボードを作るとき、なぜ指標定義をコードやテキストとして残すことが重要になるのかを整理します。
ダッシュボード作成は、画面づくりだけではない
社内でダッシュボードを作ろうとすると、最初に見た目へ意識が向きます。
売上の折れ線グラフ、問い合わせ件数の棒グラフ、案件数のカード、月次推移、店舗別の比較。きれいな画面ができると、データ活用が進んだように見えます。
でも、実務でつまずくのは見た目より前です。
この売上は税込か税抜か
キャンセル分は引いているか
問い合わせ件数に迷惑メールは入るか
今月の数字は速報値か確定値か
同じ指標を別部署も同じ意味で使っているかここが曖昧なままグラフを作ると、画面はできても会議で止まります。
「この数字はどこから来たのか」「先月の資料と違うのはなぜか」「担当者が変わったら直せるのか」という確認が毎回発生します。
AIがSQLを書けるようになるほど、この問題は見えにくくなります。なぜなら、画面を作る速度が上がる一方で、指標の意味が曖昧なままでも、それらしいグラフができてしまうからです。
ダッシュボード作成は、画面づくりではなく、会社として見る数字の定義をそろえる作業です。
BI as Codeは、指標の履歴を残しやすい
BI as Codeの発想は、ダッシュボードをクリック操作だけで作るのではなく、テキストファイルとして定義することです。
EvidenceのGitHubでは、MarkdownファイルからWebサイトを生成し、Markdown内のSQLがデータソースに対してクエリを実行し、その結果をチャートやコンポーネントで描画すると説明されています。公式ドキュメントでも、EvidenceのレポートはSQLクエリ、データ可視化コンポーネント、プログラム的な機能を含むMarkdownで書くとされています。
この形の良さは、かっこよさではありません。
定義が残ることです。
たとえば、月次売上のグラフを作る場合、次の要素が1つのファイルや関連ファイルに残ります。
何を集計しているか
どの条件で除外しているか
どの列を日付として使っているか
どの粒度でグループ化しているか
画面上でどう説明しているかこれがテキストとして残っていれば、あとからレビューできます。変更履歴も追えます。AIに修正を頼むときも、「この指標の計算条件を変えたい」と具体的に依頼できます。
反対に、画面操作だけで作ったダッシュボードは、どこをどう触ったのかが属人化しやすいです。作った人が退職したり、担当が変わったりすると、数字の意味を追うのが難しくなります。
中小企業では、専任のデータ担当者が常にいるとは限りません。だからこそ、指標定義がテキストで残ることには実務上の意味があります。
AIに任せる前に決める4つの定義
AIにダッシュボードを作らせる前に、最低限4つの定義を決めます。
1. 指標名
まず、何を見るのかを言葉で決めます。
「売上」だけでは広すぎます。受注額、請求額、入金額、粗利、継続売上、初回売上では意味が違います。
問い合わせも同じです。フォーム送信数、営業対象になる問い合わせ、既存顧客からの問い合わせ、採用応募、迷惑メールを除いた件数では、判断が変わります。
AIに頼む前に、人間が指標名を決めます。
2. 計算式
次に、どう計算するかを決めます。
売上 = 請求済み金額の合計
有効問い合わせ = 問い合わせ全体 - 迷惑メール - 採用応募
対応遅れ = 初回返信まで24時間を超えた問い合わせこのレベルでよいので、先に言葉にします。
SQLはAIが下書きできます。しかし、計算式そのものを決めるのは会社側です。ここをAIに丸投げすると、一般的には正しそうでも、自社の会議では使えない数字になります。
3. 粒度
同じ指標でも、日次、週次、月次、店舗別、担当者別、顧客区分別で見え方が変わります。
粒度を決めないままグラフを作ると、あとから「見たいものと違う」となります。
最初は多く作りすぎない方がよいです。
毎週の会議で見るなら週次。月次経営会議で見るなら月次。現場改善なら担当者別や店舗別。目的に合わせて粒度を絞ります。
4. 確認者
最後に、人間の確認者を決めます。
AIが書いたSQLが動いても、指標として正しいとは限りません。データの欠損、除外条件、例外処理、古いデータの扱いは、人間が確認する必要があります。
少なくとも、次の2人の役割を分けます。
業務を知っている人: 指標の意味が現場と合っているかを見る
データを触れる人: SQLやデータ元の条件が合っているかを見る人数が少ない会社では同じ人が兼ねても構いません。ただし、役割としては分けて考えます。
最初の一枚は、経営会議ではなく反復業務から作る
ダッシュボードというと、経営会議用の立派な画面を想像しがちです。
でも、最初から全社KPIを作ろうとすると重くなります。
中小企業がAIとBI as Codeを試すなら、最初の一枚は反復業務から作る方が安全です。
たとえば次のようなものです。
問い合わせ対応:
- 週ごとの問い合わせ件数
- 初回返信までの平均時間
- 未対応の件数
- よくある問い合わせカテゴリ
営業活動:
- 新規商談数
- 提案済み件数
- 失注理由の分類
- 次回アクション未設定の案件数
社内作業:
- 未完了タスク数
- 期限超過タスク数
- 手戻りが発生した件数
- AIで下書きしたが人間修正が多かった作業これらは、会社の大きな戦略を語るためというより、毎週の改善に使う指標です。
小さな反復業務であれば、データ元も限られます。計算式も確認しやすいです。AIが書いたSQLの間違いにも気づきやすくなります。
最初の目的は、完璧な経営ダッシュボードを作ることではありません。
指標を決め、AIに下書きさせ、人間が確認し、次週も同じ定義で見られる状態を作ることです。
コード管理すると、AIへの依頼も具体的になる
指標定義がファイルとして残ると、AIへの依頼も変わります。
曖昧な依頼は、こうなります。
売上のダッシュボードを作ってください。
いい感じに分析してください。
見やすいグラフにしてください。一方で、定義が残っていると、次のように頼めます。
既存の週次問い合わせダッシュボードに、
初回返信が24時間を超えた件数を追加してください。
有効問い合わせの定義は既存ファイルに合わせてください。
グラフ下に、先週比が増えた場合の確認観点を3つ書いてください。この差は大きいです。
AIは、何もないところから「いい感じ」を作るより、既存の定義に合わせて追加・修正する方が実務に馴染みます。
また、コード管理されていれば、AIが変更した箇所を差分で確認できます。SQLの条件が変わったのか、文章だけが変わったのか、グラフの種類だけが変わったのかを見分けられます。
これは、AI時代のダッシュボード運用でかなり重要です。
AIに速く作らせるほど、あとから人間が確認できる形にしておく必要があります。
注意点は、SQLを書ける人がいなくなることではない
BI as Codeという言葉を聞くと、「結局コードが書ける人向けではないか」と感じるかもしれません。
その懸念は半分正しいです。
SQLやデータ元の理解は必要です。AIが下書きしたとしても、数字が経営判断に使えるかどうかは確認しなければいけません。
ただし、注意点は「全員がSQLを書けないと使えない」ことではありません。
本当に危ないのは、SQLを書ける人だけが指標の意味を握ってしまうことです。
ダッシュボードは、データ担当者だけのものではありません。現場が見て、管理者が判断し、経営者が次の打ち手を決めるためのものです。
だから、コードで残す場合でも、次のように分けます。
SQL: データの取得条件
Markdown: 指標の説明、使い方、注意点
グラフ: 判断しやすくする表示
レビュー記録: いつ、誰が、何を確認したかEvidenceの公式ドキュメントでは、Markdown内のSQLクエリはDuckDB方言で実行されると説明されています。こうした技術仕様を理解する担当者は必要です。
一方で、経営者や現場責任者が見るべきなのは、SQLそのものだけではありません。指標の説明、除外条件、見た後の判断です。
AIでコードが書きやすくなるほど、技術担当者と業務担当者の会話を分けないことが大事になります。
Optiensの見方
Optiensでは、AI活用を「AIに作らせること」ではなく、「業務の判断材料を再現できる形にすること」として見ています。
ダッシュボードも同じです。
AIにグラフを作らせるだけなら、最初の画面は早くできます。しかし、指標名、計算式、粒度、確認者、更新履歴が残っていなければ、社内の判断材料として育ちません。
BI as Codeの価値は、コードを書くこと自体ではありません。
数字の意味を残し、レビューできる形にし、AIにも人間にも引き継げることです。
AI活用をどこから始めるべきか迷っている場合は、まず AI活用診断簡易版（無料） で、既存業務のどこがAIパッケージ化しやすいかをご確認ください。実装まで進めたい候補が見えた場合は、導入前スコープ整理 で対象業務、含む範囲、費用感、5営業日で初期版にできるかを整理します。