BIツールの構築は、HTMLの設計書から始める

BIのダッシュボード作りをAIに任せるとき、いちばん効いたのは、BIツールを触る前にHTMLで設計書を作ることでした。

弊社は、SnowflakeやAmazon RDS for PostgreSQLなどのデータベースを自社で運用しています。そのデータを使い、MotionBoard、Tableau、Streamlitの3つでAIによる自動構築を検証してきました。AIの動かし方はツールごとに違います。それでも、効いた順番は同じでした。データを見て、人と話して、HTMLで画面を決め、承認を取ってから作る。そのあとはAIが検証を繰り返して完成に近づけます。

1つのお題（1〜2画面）あたり、人の時間は1時間半ほど、AIの時間は約2時間です。AIの時間はMotionBoardの実測で、人の時間は実際に回している感覚の値です。ただし、ダッシュボード構築を理解している人の時間です。理由は後で書きます。

検証に使っている環境

ここに書く話は、自社のデータ基盤とBIツールで実際に試した記録です。

案件ではPower BIの再構築も支援しています。データの置き場もBIツールも複数あるので、1つの製品に閉じない進め方を探してきました。

先に結論：6つの手順と受け持ち

人が判断するのは①〜④と、⑥の最後です。⑤の間は、画面に手を出しません。

なぜHTMLを先に作るのか

BIツールの上で直すと、1か所の変更でも時間がかかります。AIが画面を操作する場合は、なおさらです。HTMLなら、色や並びを数分で直して見比べられます。

設計書を飛ばすとどうなるかも、記録に残っています。

• 依頼文だけで作らせた検証（13回）：原価が1個あたりの金額だと気づかず、粗利率が81%（正しくは約73%）と出た回が、13回中7回ありました
• 手本と違う割り付けのまま磨いた回：3回、約4時間半かけても手本に近づきませんでした
• 一から作った飲食店のレポート：手本に寄せるまで10回、約12時間かかりました。仕上がった画面を複製して差し替える方法に変えると、2回、約2.3時間で92点に届きました

点数は弊社独自の採点表（100点満点）によるものです。

HTMLには、もう1つ利点があります。使う人に、触れる形で見せられることです。BIツールのアカウントが無い相手にも渡せます。弊社の案件でも、確認用のモックをHTML版で渡すことにしました。

手順1〜2：データを見てから、人と話す

AIに最初にさせるのは、画面づくりではなくデータの確認です。読み取り専用で接続し、明細は外に出さず、集計だけを書き出します。

架空の小売データ（約82万行）では、AIが依頼文のままでは誤る点を5つ見つけました。金額に見えて実は件数の列、日付と合わない月の列、半月分しかない最終月などです。

人が決めるのは、誰が、いつ、何を知りたいかです。さらに、どの順番で何を確認し、どんな判断をするかまで決めます。これを利用ストーリーと呼びます。AIは所見をもとに「この数字はこう置き換える」と提案し、人が選びます。定義は渡す側が決めて、画面にも書きます。同じ「保存率」でも、時点と期間の切り方で数字が変わるからです。

手順3〜4：設計書を作り、承認をもらう

HTML設計書には、画面の手本に加えて次の5つを書きます。

1. 部品ごとの位置、大きさ、色
2. 計算の決まり（率は合計どうしで割る、など）
3. データの癖
4. 崩してはいけない値（手本の月の主な数字）
5. 利用ストーリー（配置の根拠。最初に見てほしい情報を左上に大きく置く）

4つ目と5つ目が、あとの検証の答えになります。

承認は、ここで取ります。 BIツールで作った後に「思っていたのと違う」と言われると、作り直しになるからです。配色はデジタル庁の「ダッシュボードデザインの実践ガイドブック」から始めます。色を使いすぎて差し戻された初版の反省です。検証でも、このガイドブックを渡した回がいちばん高い点でした。

手順5：開発は、ツールに合う方法で

設計書が決まれば、AIは迷う所がほとんどなくなります。動かし方だけが違います。

Streamlitでは、裏のSQLは必ず人が見ると決めました。Pythonのコードまでは見ません。

手順6：AIが検証を繰り返す

ここがAI任せの本体です。1回作って終わりにせず、比べて直す輪をAIに回させます。

数字の検証

• 画面の数字を、別に書いたSQLや元の表から出した値と突き合わせる
• 最後は国の公表値など、まったく別の出どころと合わせる。自分のSQLを2通り書いて一致しても、元の表がずれていれば両方ずれます
• KPIと明細の合計、地図の合計とKPIのように、部品どうしも合わせる
• わざと壊して、検査が落ちることを確かめる。落ちない検査は検査になっていません

見た目の検証

• 手本と同じ大きさで撮って並べ、差が大きい順に「直す点の一覧」を作る。順番は、割り付け、大きな数字、表、グラフ、文言、余白と色
• 表示倍率や画面の幅を変えて撮る。75%でだけ崩れる画面がありました
• 別のAIにも写真を見せる。作った本人の点検は甘くなります

止めどき

• 手本との差が縮まらなくなったら、磨くのをやめて設計書に戻ります
• AIの「済みました」は信じません。薄すぎて見えない塗りや、押せないボタンが「済」で報告された回がありました。必ず実物で確かめます

伝わるかの検証

「手本どおりか」だけで採点すると、表だらけの手本を忠実に写した画面が高得点になります。物差しは「見る人に伝わるか」に置き、次の3つを確かめます。

• 説明がなくても、何の画面か分かるか
• 迷わず操作できるか
• 問題に気づけるか

この確かめは、AIにも任せられます。画面の写真だけを別のAIに見せて「ここから何を判断しますか」と答えさせ、利用ストーリーと比べます。

1つの画面で試しました。同じ質問を3回ずつ行い、5点満点で採点した結果です。

分かったことは3つです。

• 伝わらない画面は、この検査で落ちます。見出しを消すと、何の業務の画面かを答えられませんでした
• 写真は鮮明に撮ります。粗い写真では、問題を読み取れない回が続きました。ただ、この2つは画面も違うので、差のすべてが粗さのせいとは言い切れません
• 点より、回答の中身に価値があります。改善版では、判断を3回とも「落ちた仕入先への対応」と行動で答えました。元の手本では「売上が大きい仕入先」という説明にとどまっています

検査で新しい指摘も出ました。6回中4回が「対象月は2月なのに、推移が3月まであるのはなぜか」と迷っていました。数字が合っていても、見る人は迷います。この種の指摘は、数字の検証では出てきません。

これは画面1つの小さな試行で、採点も作った側が行っています。改善版は検査用のHTMLで、BIツールの画面ではありません。

利用ストーリーと伝わるかの考え方は、ウイングアーク1stのMotionBoardデザインコンテンツを参考にしました。

人が必要な時間

1つのお題（1〜2画面）あたりです。ストップウォッチで測った値ではなく、実際に回している感覚の時間です。

いちばん長いのは、HTMLを見ている時間です。人の判断は、ここに集めます。BIツールの操作に人の時間は使いません。使う人が別にいる場合は、承認の打ち合わせの時間が別に要ります。

AIの時間は、MotionBoardの実測で1つのお題あたり約1.5〜2.1時間でした。手本がない状態から作ったOura Ringの2画面は、14回、約10時間かかっています。テンプレートがまだ無かった時期の記録です。

人の時間は、データの分かりにくさで増えます。項目の意味を書いたメモがあると、①と②が短くなります。

この時間は、構築を理解している人の数字です

人の時間がとても短く見えると思います。ただ、これは誰でもこの時間で済むという話ではありません。この数十分は、次の3つの知識があって初めて成り立ちます。

• データベースの知識：この列は1個あたりの金額だから数量を掛ける、この結合だと件数が増える、と読める
• 業務の知識：その数字が現場で何の判断に使われ、どの定義なら会議で通るかが分かる
• ダッシュボードの構成論：誰の問いに答える画面か、何を左上に置き、何を載せないかを決められる

HTMLを見ている30〜50分は、眺めている時間ではありません。頭の中でデータの持ち方を確かめ、業務に照らし、画面の構成を組み立て直しています。何年も手で作ってきた経験を、数十分に圧縮して使っている状態です。

AIが短くしたのは、手を動かす時間です。判断に要る知識まで短くしたわけではありません。

粗利率が81%と出た画面も、見た目はきれいでした。正しくは約73%だと気づけるのは、原価の持ち方を知っている人だけです。知識がないまま同じ手順を回すと、時間が短くなる代わりに、誤った画面が速く完成します。

だから、この手順の価値は「誰でも作れる」ことにはありません。分かっている人が、判断だけに時間を使えるようになることにあります。

トークン量を抑える工夫

AIは1手ごとに、それまでの作業記録を読み直します。つまり、長い1回がいちばん高くつきます。検証では、平均28分の回で約4,900万トークン、74分の回で約1億3,000万トークンを読み込みました。

効いた工夫は次のとおりです。

1. 渡す資料を絞る：資料を全部渡した回は、ガイドブックだけの回より準備に約6倍の時間がかかり、点数も下回りました
2. 直すのはHTMLの段階で：BIツールの画面操作は、1回で道具を数百回使います。手戻りはHTMLのうちに済ませます
3. テンプレートを持つ：色や書式を設定済みの見本を使うと、AIが作る量そのものが減ります
4. 回を区切り、メモで引き継ぐ：1回の上限を90〜120分にして、終わりに実装メモを書かせます。次の回はそのメモから始めます
5. 仕上げは軽いモデルに渡す：1回目はOpus 5.5で90分、直す点の一覧を渡した仕上げはSonnet 5.5で13分でした
6. 直す点は一覧にして渡す：1行1項目で、色の値まで書きます。AIが探す手間が減ります
7. 計算はプログラムで済ませる：差の列、合計、単位の換算まで済ませてから渡します。AIに引き算や単位換算をさせると間違えます
8. 作業の切れ目で会話を空にする：終わった作業の記録を抱えたまま次へ進まないためです

うまくいかないこと

• ツールにない表示は、AIでも作れません。手本にあっても追わないと先に決めると、同じ所で時間を使わずに済みます
• 公開後に開き直して確かめます。作った直後は動いても、開き直すと壊れていたことがありました
• ツールごとの比較は、同じお題で行ったものではありません。ここに書いた数字は、それぞれの検証の記録です

まとめ

• BIツールを触る前に、データを見て、話して、HTMLで設計書を作る
• 人がするのは、目的を決めることと、手本を確かめること、承認、最後の判断。時間は1時間半ほど
• 開発と検証の繰り返しはAIに任せ、数字は別の道で突き合わせる
• その1時間半は、データベース、業務、構成論を理解している人にしか出せない
• トークン量を抑える一番の工夫は、長い1回を作らないこと

同じお題でも、回し方を変えると約12時間が約2.3時間になりました。ツールの選び方より先に、順番を決めるのが近道です。

残る課題：その知識をどう身につけるか

これからの時代、ダッシュボードの細かな構築技術は要らなくなっていきます。チャートの設定や画面の操作は、AIが引き受けるからです。

ただ、全体の構成の理論は、その細かな構築を経験する中で身についてきたものです。そして今必要なのは、その理論の上位2割ほどだと感じています。

細かな構築をAIが担う時代に、その2割をどう身につけるか。答えはまだ出ていません。これが、弊社の今後の課題です。

石井 亮介（りょうさん）

データパレード 代表取締役

XContact

㈱データパレードの代表取締役で、高田馬場の町中華「一番飯店」のChief Data Officerも務めています。BIツールのセールスエンジニア・システムエンジニア・カスタマーサクセス歴15年。大学のデータサイエンス教育で講師も担当してきました。現在は自社業務のほとんどをAIに移管し、AI10部署と50を超える自動処理が24時間動く「AI経営」を実践中。その実践知をこのブログで発信しています。