GASでダッシュボードを作るニーズを考えてみた
とある案件でポートフォリオ提出を求められ、Google Apps Script（GAS）でダッシュボードのサンプルを作りました。見た目はこんな感じ。
気になる方は下記リンクから実際の挙動を確認できます。
GAS_Dashboard_SAMPLE
Gitのサンプルコード: DashboardSample_using_GAS
私自身、BIツールや Python + Flask での簡易Webアプリによるダッシュボード開発経験はありますが、GASでのダッシュボード作成は今回が初めてです。
また、需要としてはややニッチだと思いますので、知見を共有したいと思います。
そもそもGASでダッシュボードを作るシーンってどんな時？
Googleスプレッドシートにも描画機能はありますし、BIツールを使えばダッシュボードは比較的簡単に作れます。
それでもあえてGASでダッシュボードを作る必要があるのは、例えばこんな条件のときでしょう。
- 標準機能ではできない処理を組み込みたい
- インタラクティブなUIを実装したい
- 他のGoogleサービスと連携させたい
- コードベースでダッシュボードを管理したい
- コストを抑えたい
- 外部サービスとの連携でデータ取得を行いたい
つまり「データが自動更新され、集計ロジックやUIも自由にカスタマイズできて、それでいてBIツールの利用コストが不要」という、かなりわがままな仕様です。
そもそもスプレッドシートやBIツールは汎用性と専門性をトレードオフしていますし、構築・運用コストについても「カスタマイズ性」と「手軽さ」のトレードオフです。
以下は「ダッシュボードを作りたい」場合の選択肢を星取り表でまとめたものです（あくまで私の主観です）。
| 項目 | スプレッドシート | BIツール | GAS | スクラッチ開発 |
|---|---|---|---|---|
| 開発ハードル | Excellent | Good | Fair | Poor |
| カスタマイズ性 | Poor | Fair | Good | Excellent |
| 描画可能なデータ量 | Fair | Good | Poor | Excellent |
| 開発スピード | Excellent | Good | Fair | Poor |
| 追加金銭コスト | Excellent | Fair | Excellent | Poor |
| メンテナンス負荷 | Poor | Fair | Good | Good |
ベンチャー/中小企業のような小さな組織でデータ量はそこまで多くない、だけど、BIツールを入れたり独自のダッシュボードアプリを一から作るほどの金銭的な余裕もない、とはいえスプレッドシートベースで管理するマンパワーもない、というケースだとGASでダッシュボード作るニーズはあるのかなと思います。
ダッシュボードの設計について
今回のダッシュボードはWebアプリとして構築し、描画にはPlotlyを使いました。
理由は、データ分析の文脈で私が使い慣れていたことと、サンプルなので動きや操作性も見せたいと思ったからです。
ただし、GASでPlotlyを使うのは一般的ではないようです。
Webアプリ型のダッシュボードなら、通常はGoogle Charts Service（Charts API）を使う方が主流です。 これはGAS標準のチャートサービスで、サーバーサイドでレンダリングするため追加ライブラリは不要。Charts.newAreaChart()やCharts.newLineChart()などのメソッドで簡単に作れます。ブラウザ負荷を軽減できるのもメリットです。
一方、PlotlyはCDN経由でHTML Serviceから読み込み、ブラウザ側で描画します。
ホバーでの詳細表示、アニメーション、レスポンシブ対応などが標準で備わっていますが、HTML/CSS/JavaScriptの知識が必要で、設定も複雑。データ量が多いとブラウザ側でフリーズすることもあります。
さらに、GASでは実行時間が最大6分、メモリも限られます。
10万件クラスのデータは厳しいため、BigQueryで前処理するか、BIツールを使うのが現実的です。
サンプルのダッシュボードを触ってもらえば分かりますが、私の環境では2000行程度のデータでも集計で数秒程度のラグが発生しています。ギリギリ許容範囲ですが、UXとしてはいただけないですね。でもサンプルなのでそこは割り切っています。
サンプルデータについて
当初は政府系機関のデータを探しましたが、サンプル用途なのでそこまで大容量でなく、グラフ化しやすいものってなると探し当てるのが難しいんですね。あまりにも単純すぎるデータだとサンプル作る上でデータ不足になりますし、調査する時間ももったいない。
最終的にKaggleの「Retail Fashion Boutique Data Sales Analytics 2025」を利用しました。Kaggleのデータセットはタグで分類され、データ定義書もあり、簡易的な可視化も確認できるので便利です。ただし、コンペ用データは偏りがある場合も多く、今回のデータも特定年月に集中していました。事前に簡易集計して確認しておくのがおすすめです。
Retail Fashion Boutique Data Sales Analytics 2025
そもそもダッシュボードは必要？
身も蓋もないですが、「ダッシュボードを作りたい」という話が出たときは、本当に必要なのかをまず確認すべきです。
- 誰が使うのか
- どんな情報があればアクションにつながるのか
- なぜダッシュボードという解決策に至ったのか
これを明確にしないと、「誰も見ないが更新だけは発生する」状態になりがちです。
多くの場合、ダッシュボードは既存の集計値を一カ所にまとめただけです。
もし目的が「レポート作成の負担を減らす」なら、ビジュアル化せずテキストの集約だけで十分かもしれません。
また、指標を集約すると抽象度が上がり、詳細確認のために元データを結局見に行くことになります。
その意味では、ダッシュボードは「データへのポータルサイト」として位置付けるのが現実的だと思います。
と言いながらも、ユーザー目線に立つと、目新しさはあるのでキャッチーな感じがしますし、既存レポートに対する定型処理の自動化という側面ではダッシュボード作りもメリットが生まれるのかなと思います。
言われたものだけを作ると結構不幸になるパターンが多いダッシュボード作りなので、製作者の方は本当に必要なのかという視点をもちながら案件を進めていく必要がありますね。
Discussion