更新履歴

  • 2026-03-30: 新規公開。BIの歴史的転換点と、現代における主要ツールの選定指針について詳解。

出来損ないのBI記事 をぶった切ったので、それに続ける感じで。まず、先の記事でもふれたように、Before/After TableauでBIには大きな次元断層があります。

timeline title History of BI Platform 1969 : Cognos 2003 : Tableau 2010 : Power Pivot 2015 : Power BI Desktop

  • Tableau以前（Before Tableau） ダッシュボード（あるいは「経営ボード」）は、あくまで経営層が閲覧するためのものでした。その構築や変更は、外部のベンダーや社内の情報システム部門（情シス）が独占的に行い、現場は「与えられた数字を見るだけ」の存在でした。この記事が語る「モジュール」や「開発費用」といったERP的な発想は、まさにこの時代の遺物です。

  • Tableau以後（After Tableau） ダッシュボードは「現場の武器」へと変貌しました。閲覧するだけでなく、現場の担当者自身が深く関わり、自らデータを探索し、ダッシュボードを更新・改善していく セルフサービスBI が当たり前となりました。

結果として、Tableauの前と後ではBIを誰が見て、誰が作るのかは決定的に変わりました。単純に言えば、Tableauより前のBIは死亡診断書でした、もう、起きたことをどう処理するか。その意味では管理会計に近い。しかし、Tableau以降では現場自身が次の打ち手を模索するためのツールになった。

Before Tableauの世界観

  • Viewer：役員・ボード
  • Creator：情シス or 外部ベンダー
  • Explorer：存在しない

データは“報告”のためのもの ダッシュボードは“提出物”

After Tableau

  • Viewer：現場
  • Explorer：現場
  • Creator：現場＋情シス

データは“意思決定のためのもの” ダッシュボードは“現場の道具”

この部分は重要です。まず、がらっと変わったからです。

結果として、美しさも問われるようになりました。なぜならば、打ち手を模索する思考をアクセラレートするための道具になったからです。

結果として、従来からの棒グラフや折れ線グラフなどに加えて、

  • ファネルチャート
  • ヒートマップ
  • サンキーダイアグラム

などが必要になりました。

これら「高度なViz」が必要になったのは、現場が「何が起きたか」だけでなく、 「なぜ起きたか（原因の究明）」 という外科手術を自ら行うようになったからです。

ここで、SIerによる「数ヶ月待ちのカスタマイズ」などという概念は1オングストロームの価値もなくなります。現場は、今この瞬間にメスを振るいたいのです。

ツール選定の3つの軸

BI ツールを選ぶ際、機能比較以上に重要なのが以下の 3 点です。

  1. ユーザーの技術スタック : SQL を書くのか、 GUI で操作するのか。
  2. データの性質 : 秒単位の監視か、じっくり見る月次レポートか。
  3. 運用・接続方式 : 「On the fly (直結型) 」 か、 「Decoupled (絶縁型) 」 か。

「何ができるか」ではなく、 「誰がどう使うか」 から逆算する必要があります。

OSS BI の二大思想：オートマか、マニュアルか

主要ツールの特性を一言で表すと、車の運転に例えられます。

  • Metabase は「オートマ車」 :

    • 「X-Rays」 などの自動化機能により、誰でもすぐに走り出せる。
    • 内部構造を知らなくても「よさげな結果」にたどり着ける快適さ。

  • Redash は「マニュアル車」 :

    • 「SQL」 を自ら操り、意図した通りの挙動を 100% 制御する。
    • ブラックボックスを排除し、プロの要求（細かな制御）に応えきる。

Evidence : 「Web と基幹 DB を直結させない」究極の安全策

Tableau や Redash は、ユーザー操作に応じて 「On the fly (動的) 」 にクエリを発行します。これは本質的に 「Web と基幹 DB を直結するパイプ」 を抱えるリスクを意味します。

  • 直結型の脆弱性 : 動的レイヤーが外部から攻略された際、そのパイプを通じて業務 DB にまで直接の危険が及ぶ可能性があります。
  • 絶縁の SSG アーキテクチャ : Evidence は 「ビルド時にのみデータを引っこ抜く」 仕組み。公開サーバーと DB を物理的に絶縁し、攻撃パスを完全に遮断します。
  • 情シスの最終判断 : 「リアルタイム性」よりも「基幹データの絶対的保護」を優先する場合、 Evidence は唯一無二の選択肢となります。

Kibana : 検索エンジンの「窓」

「全文検索ができる Elasticsearch がある」という状況が前提です。

  • 使うべき状況 : ログ、テキストデータ、あるいは膨大な非構造化データの中から 「特定のキーワード」 や 「特定のパターン」 を掘り起こし、その傾向を時系列で追いたい時。
  • 迷わない理由 : Elasticsearch を使っているなら Kibana 以外を選ぶ理由がほぼないし、逆に Elasticsearch がないのに BI 目的だけで Kibana を導入するのは、順序が逆だからです。

Grafana : 時系列の「鼓動」

「時系列データベース (Prometheus, InfluxDB 等) 」や「インフラ監視」が前提です。

  • 使うべき状況 : 「今、この瞬間」 のサーバー負荷、温度、株価、パケット量など、刻一刻と変化する数値 (メトリクス) を監視し、閾値を超えたらアラートを飛ばしたい時。
  • 迷わない理由 : 「モニタリング」 が必要なら Grafana がデファクトスタンダードであり、そこにビジネスレポート (昨対比の売上集計など) を期待するのはお門違いだからです。

Streamlit : 「BI ツール」として使うべきか

強力なのは間違いないですが、多くの企業が求めている 「データの可視化」 という要件に対しては、コストが見合わないケースが多々あります。

特に、 Pythonista がいない環境での 「オーバーキル」 がもたらす弊害は深刻です。

  • 学習・運用・保守コスト : 開発環境の維持だけで工数が溶ける。
  • UI 自由度の高さ : 「あるべき姿」をイチから設計する迷いが生じる。

「ただのグラフ」を作るための工程が多すぎる

  • Redash / Metabase : SQL (または GUI) を書いてボタンを押せばグラフが出る。
  • Streamlit :
    1. Python 仮想環境を作成・管理する。
    2. Pandas 等でデータフレームを整形するコードを書く。
    3. st.sidebar や st.columns でレイアウトを組む。
    4. デプロイ環境 (サーバー、コンテナ) を永続的に維持する。

この 「4つのステップ」 のどこかで躓くだけで、現場は 「もう Excel でいいや」 となってしまいます。

「エンジニアがPythonで『最強の自由』を謳歌している横で、現場は『1週間後に届くグラフ』のために死んでいる。そのギャップを埋めるのは、コードの自由度ではなく、ツールの制約である。」

「汎用性」が逆に「迷い」を生む

Streamlit は 「何でもできる」 (AI チャット UI も、画像認識の結果表示も可能) からこそ、ダッシュボードとしての 「型」 を自分で設計しなければなりません。

Redash 等のツールには最初から 「BI としての制約」 があるため、迷う余地がありません。多くの中小企業に必要なのは 「無限の可能性」 ではなく、 「正解が用意された最短ルート」 です。

Metabase : 驚異的な「使い勝手」と自動化（オートマ）

Metabase の真髄は、作り手が作り込まなくても 「最初から備わっている」 圧倒的なユーザー体験にあります。

  • ドリルダウンの民主化 : グラフの要素をクリックするだけで、データの深掘りやフィルタリングが特別な設定なしで可能。
  • X-Rays (おまかせ生成) : テーブルを指定するだけで、 Metabase が勝手に「よさげなダッシュボード」を自動生成。
  • 「とりあえず入れる」の正解 : 専門家がいなくても、データを入れた瞬間から「インサイトが得られる状態」まで持っていける。

Metabase : 普及の「丸」と負債の「罠」

強力な自動化機能で組織に浸透しやすい一方で、エンジニア視点ではいくつかの 「限界」 と 「罠」 が見えてきます。

  1. 可視化の「強行」ができないもどかしさ : Redash や Streamlit を使っているエンジニアが Metabase を触ると、一番ストレスが溜まるのが 「表現力の柔軟性」 です。
  • Redash : SQL で HTML タグを吐き出したり、Python エディタ機能を駆使した強引な表示が可能。
  • Metabase : 基本的に「用意されたパーツ」を組み合わせる世界です。 JS の直接注入などの「強行突破」は不可能です。
  1. コネクタの「ほどほど」感 :

メジャーな DB (PostgreSQL, BigQuery 等) は完璧ですが、 Redash のように「マニアックな DB や API まで繋ぎにいく」という執念は感じられません。 「独自 API の結果を可視化する」といったエンジニア的なハックには向いていません。

  1. 「Query を書かなくていい」の罠 :

これが最大の魅力であり、同時に 「負債」 の入り口です。

非エンジニアが GUI (クエリビルダー) で作った質問が乱立すると、 「同じ指標なのに、裏側のロジックが微妙に違うダッシュボード」 が量産されます。 整合性を保つには、結局エンジニアが「SQL (Native Query) 」や「モデル」を定義して管理しなければならず、そうなると 「Redash でよくない？」 という話に回帰してしまいます。

Redash : プロの要求に応える「制御可能性」（マニュアル）

Redash の最大の強みは、魔法のような自動生成（ブラックボックス）を排除し、作り手に 「完全な制御」 を委ねている点にあります。

  • 脱・ブラックボックス : 「勝手に何かをやってくれる」のではなく、投げた SQL の結果を 100% 意図通りにハンドリングできる安心感。
  • プロのための道具 : 魔法のような X-Rays はありません。しかし、集計ロジックの透明性とデバッグの容易さは、プロの現場において何物にも代えがたい武器になります。
  • エンジニアへの信頼 : 「ツールに縛られる」のではなく、ツールを自らのスキルで 「使い倒す」 ことを好むチームに最適。

Redash で「強行突破」ができる理由

「データさえあればいい」という割り切りが、圧倒的な柔軟性を生んでいます。

  • Custom Chart (Plotly.js) : 生の JavaScript を直接書いてグラフを構築可能。「複雑な軸設定」や「動的な色変更」も自由自在。
  • 取得と描画の完全分離 : 「データの取得 (SQL) 」と「描画 (JS) 」が独立しているため、 SQL の結果セットを eCharts 等の外部ライブラリへ最短距離で流し込めます。
  • v25 以降の拡張性 : ビジュアライゼーション・エンジンの刷新により、さらに高度な 3D 表現や特殊チャートへの対応が進んでいます。

結論 : 誰が使い、誰がメンテするのか

  • Metabase（オートマ） : 「組織への普及」と「現場の初動」を最優先する。
  • Redash（マニュアル） : 「脱・ブラックボックス」と「自由な制御」でプロの要求に応えきる。
  • Evidence（SSG） : 「Web と DB の絶縁」で基幹データの安全を絶対防衛する。
  • Streamlit（アプリ） : 「BI の枠」を超えたデータアプリ開発へ。

ツールごとの 「運転感覚」 と 「セキュリティ境界」 を理解し、チームのコンテキストに最適な一台を選び抜くことが重要です。

番外 : Pentaho の「安らかな眠り」

2000年代の「重量級エンタープライズ」の象徴だった Pentaho に、 2026 年のモダンなデータ環境は荷が重すぎます。先にも述べた通り、BIの次元断層は深く巨大なのです。

  • Java ベースの重厚長大さ : セットアップに一苦労し、リソースを大量消費。
  • XML 地獄 : 設定が巨大な XML で管理され、 Git での差分管理が困難。
  • UI/UX の「化石化」 : モダンな操作感とは対極の、 2000 年代初頭の操作性。
  • メンテナンスコスト : 「動かすための運用」に工数を取られ、分析に集中できない。