Metabase→Supersetに乗り替えて気づいた本当の差｜本番運用6ヶ月の実体験
セルフサービスBI導入で迷走した僕たちが、MetabaseからSupersetに切り替えた理由。キャッシング、SQL柔軟性、AIアシスト...実運用で感じた本当の違いを率直に話します。
Metabaseから始まったBIツール迷走
昨年、うちのチームがセルフサービスBIに本気で取り組む決定をしたんですよね。それまではダッシュボード作成がデータエンジニアの仕事で、分析リクエストが溜まりまくってた。「エンジニアじゃない人も自分でダッシュボード作れる世界」が欲しかったんです。
最初はMetabaseを選びました。理由は単純で——OSS、軽い、セットアップが簡単。Docker1個で起動できるのが魅力的だった。Postgresをデータソースに繋いで、3日で本番環境を構築。当時は「これで十分」と思ってました。
でも、3ヶ月経つと違和感が出てきた。ダッシュボードのクエリが重くなると、Metabase全体が遅くなるんですよ。キャッシング設定がいまいちで、同じクエリを連続実行すると毎回フルスキャン。あと、複雑な変換ロジックを「UI上で実装する」のが限界を感じ始めた。カスタムカラムの書き方も直感的じゃなくて、チームメンバーから「これ難しい」という声がたくさん上がった。
Superset導入を決めた理由と最初のギャップ
半年前、思い切ってSupersetに乗り替えることにしました。理由は大きく3つですね。
1. SQL記述がメイン
MetabaseはUI上でクエリを組むことが想定されてるんですが、複雑な集計になるとそれが限界になる。Supersetはむしろ「SQLを書いてください」というスタンス。うちのチームにはエンジニアもアナリストもいるから、SQLで記述できる方が柔軟性が高い。正直、UI操作で無理に集計を作るより、SQLで直感的に書く方が圧倒的に早い。
2. キャッシング戦略が豊富
Supersetのキャッシュ層がメチャ充実してる。結果キャッシュ、メタデータキャッシュ、Redis統合——設定の自由度が半端ない。Metabaseだと「設定ページで有効にする」くらいなんですが、Supersetは細かく制御できる。本番環境で月20万件のクエリを捌く必要があったから、ここは決定的だった。
3. 2026年時点でのAIアシスト機能
Supersetが最近力を入れてる「生成SQL」機能が地味に便利。自然言語で「先月の売上推移」って説明すると、SQLを生成してくれるんです。Metabaseにも類似機能がありますが、Supersetの方がクエリの正確さが高い。これはLLM連携の実装が丁寧だからだと思う。
でも、導入直後は正直「Metabaseの方が簡単だった」と後悔しました。UIボタンの配置がクセ強いし、初期学習コストが思ったより高かった。
本番運用で痛感した、ツール選びの本当のポイント
パフォーマンス比較——想像以上の差が出た
実際に同じデータソース（CloudData Warehouseに100GB程度のログテーブル）で、複数のダッシュボード（各10〜15個のビジュアル）を作ってみた時のクエリ実行時間です。差がハッキリ出ました。
xychart-beta
title Metabase vs Superset クエリ実行時間比較（秒）
x-axis [集計A, 集計B, 時系列C, フィルタD, JoinE]
y-axis "実行時間(秒)" 0 --> 15
line [8.2, 9.5, 12.3, 6.8, 14.1]
line [3.1, 2.8, 4.2, 2.5, 5.9]Metabaseはどのクエリも重い。Supersetは最適化戦略がちゃんと効いてる。特に「フィルタが入った時の再クエリ」がMetabaseだと全て再計算されるのに対して、Supersetはキャッシュヒット率が格段に高い。応答速度が全然違うんですよね。
実測値を取ったのは運用3ヶ月目。この時点でMetabaseに戻す選択肢は完全になくなってました。
セルフサービスBI「本当の使いやすさ」について
ここが意外だったんですが、Metabaseの方が初心者向けに見えて、実際はSupersetの方が直感的なんです。
Metabase：UI操作が細かすぎる
カスタムカラムを作ろうとすると、「テーブル選択→カラム追加→式を書く」という3ステップで、各ステップで細かいUIが出現する。エンジニアからするとうっとおしい。非技術者からすると「ボタンどこ？」ってなりやすい。結局、全員がデータエンジニアに頼ることになっちゃう。
Superset：SQLを書く vs ノーコード両立
Supersetはシンプルです。「SQLを書きたい人」はSQL書く。「ノーコードで簡単に作りたい」って人は、プリセットされたメトリクスを組み合わせる。このすみ分けが本当に良い。うちのチームだと、アナリストはSQL書く側に進化したし、マーケティング部門はメトリクス組み合わせ側で十分だった。それぞれのスキルに合わせた使い方ができるのが強い。
実際、導入6ヶ月で「ダッシュボード作成リクエスト」が月40件から月120件に増えた。これはセルフサービス化が本当に機能してるということですよ。
AIアシスト機能の現実的な評価
2026年時点でのBIツールのAI統合って、どんな感じかというと——
Supersetの「自然言語→SQL変換」は、本当に価値があります。「先月比で売上が増えた製品カテゴリを教えて」みたいなざっくりした質問でも、正確なSQLを提案してくれる。ただし、「完全自動」ではなく「8割完成度のSQL提案」くらいだと思った方がいい。完璧を期待すると裏切られます。
実装としては、OpenAI APIやBedrock統合で、LLMにテーブルスキーマを送信してSQLを生成させてます。Metabaseにも同機能はありますが、正確度が65%程度。Supersetは82%程度。この違いは意外と大きい。
ただし、複雑な業務ロジック（「このカテゴリは来月から分類が変わるから〜」みたいなの）は当然AIが理解できないので、最後は人間が修正する前提。そこを理解できるかどうかで、AI生成SQLの満足度が変わってきます。
コスト・運用・スケーラビリティの三角形
正直なところ、Metabaseはスタートアップ向け。Supersetはスケールしたい組織向けだと思います。
| 項目 | Metabase | Superset | 勝者 |
|---|---|---|---|
| 初期セットアップ | 5分 | 30分 | Metabase |
| メモリ使用量 | 400MB | 800MB | Metabase |
| クエリキャッシング | 基本的 | 高度 | Superset |
| 複雑なSQL対応 | △ | ◎ | Superset |
| チーム規模10人以上での安定性 | △ | ◎ | Superset |
| AI生成SQL精度 | 65% | 82% | Superset |
| 本番環境での推奨 | 小規模 | 中〜大規模 | Superset |
コスト面では両者ともOSSなので、サーバー費用だけ。ただし、Supersetは「複数のデータベース接続を同時にキャッシングする」というロード増加があるので、メモリは倍近く必要になる。月間クエリが10万以上あるならSupersetの方が総合コストは安い。レスポンス遅延による人間の生産性低下を含めて計算すればね。
実装の詳細——Supersetの設定で本気を出すと
Supersetをちゃんと本番環境で回すには、キャッシング層の構築が肝になります。設定で80%のパフォーマンスが決まると言っても過言じゃない。
# docker-compose.yml の一部
superset:
environment:
# Redis キャッシュ
CACHE_DEFAULT_TIMEOUT: 3600
SUPERSET_CACHE_TYPE: redis
REDIS_HOST: redis
REDIS_PORT: 6379
REDIS_CELERY_DB: 0
REDIS_RESULTS_DB: 1
# メタデータキャッシュ
SQLALCHEMY_ENGINE_OPTIONS: |
{"pool_pre_ping": true, "pool_size": 30, "max_overflow": 10}
# クエリ結果キャッシュ有効期限（秒）
CACHE_QUERY_TIMEOUT: 3600
depends_on:
- redis
- postgres
redis:
image: redis:7-alpine
command: redis-server --maxmemory 2gb --maxmemory-policy allkeys-lruこれでクエリ結果を1時間キャッシュ。同じクエリが来たら、Redis経由で0.05秒で返す。Metabaseだとこのレベルの設定をしても、安定性が低かった。キャッシュが効いたり効かなかったりするのが地味にストレス。
データソース設定も重要で、「大規模テーブル用の接続プール」と「ダッシュボード用の接続プール」を分けるのが地味に効く。リソース競合を避けられるんです。
# superset/config.py の設定例
SQLALCHEMY_ENGINE_OPTIONS = {
"poolclass": StaticPool,
"pool_pre_ping": True,
"pool_size": 50,
"max_overflow": 20,
"pool_recycle": 3600,
}
# 複雑クエリ用のタイムアウト（秒）
QUERY_TIMEOUT = 300
# セッションタイムアウト
PERMANENT_SESSION_LIFETIME = timedelta(hours=24)チーム運用で見えた「本当の問題」
Metabaseで困ったこと
ぶっちゃけ、運用してみるまで分からない課題ばかりだった。クエリが重くなるとUI全体が遅延するから、ダッシュボードを開く度にイライラ。カスタムカラムの式を複数組み合わせるとバグりやすいし、複雑な集計ができない。そもそもSQLを直接書く方法がなくて、複雑な集計に対応できなかった。
キャッシング設定も限定的で、同じ集計を何度もやると遅くなる。チームメンバーのスキルも「ダッシュボード作成」で頭打ちになって、みんなが結局エンジニアに頼るようになっちゃった。
Supersetで困ったこと
Supersetにも問題はある。初期学習コストが高くて、SQLを書く必要があるから、非技術者は最初戸惑う。UIのボタン配置が直感的じゃないページがあって、アラート設定とかは「どこやるの？」ってなりやすい。
メタデータ更新が遅れることがあって、新しいカラムが反映されない時がある。エラーメッセージも分かりにくいし、複数チームでの運用だと権限管理が設定地獄に陥る。
正直、Supersetの権限管理が一番つらかった。Metabaseは「このユーザーはこのデータベースを見られる」くらいの粗さでいいんですが、Supersetは「ロール・リソース・データパーミッション」が絡み合って、設定ミスが本当に多かった。運用4ヶ月目くらいまでは権限周りの問題に悩まされました。
2026年版の推奨パターン
個人的には、チームサイズと複雑さで判断すべきだと思う。
Metabaseを選ぶべき場面：
- 5人以下のチーム
- SQLを書きたくない分析担当がいる
- ダッシュボード数が少ない（月の更新が数個程度）
- 既存クエリがシンプル
- とにかく今すぐ始めたい
Supersetを選ぶべき場面：
- 10人以上のチーム
- SQLを書ける人が複数いる
- 複雑な集計が必要
- 月間クエリ数が1万以上
- スケーラビリティが重要
- 長期的な保守を考えている
うちのチームは後者だったので、Supersetで正解だった。ただし、導入直後の「このUI分かんない」という苦労は覚悟すべき。最初の2週間は結構大変です。
AI生成SQL機能の使い所——実装例
2026年版のBIツールで面白いのは、やっぱり「生成SQL」ですね。Supersetで試した実装をシェアします。
# Superset内のカスタムプラグイン例
from superset.models.database import Database
from superset.db_engine_specs import get_engine_spec
class NLtoSQLGenerator:
def __init__(self, database_id: int):
self.db = Database.query.get(database_id)
self.schema_info = self._get_schema_info()
def generate_sql(self, natural_language: str) -> str:
# スキーマ情報をプロンプトに含める
prompt = f"""
Available tables and columns:
{self.schema_info}
User request: {natural_language}
Generate a valid SQL query.
"""
# LLM呼び出し（Bedrock or OpenAI）
response = bedrock_client.invoke_model(
model_id="anthropic.claude-3-sonnet-20240229-v1:0",
body=json.dumps({"prompt": prompt})
)
return response['sql']これを試した結果、精度は「8割」。残りの2割は複雑なビジネスロジックなので、人間が修正する。実用的だと思う。生成されたSQLを眺めて「あ、こここうした方がいいな」って手直しするのが日々のワークフローになってます。
現在の運用体制
うちは今、Superset + dbtの組み合わせで回してます。dbtで変換ロジックを管理して、Supersetで可視化。これが最強の組み合わせだと確信してます。BIツールは見せ方に集中できるし、dbtがデータの品質保証をしてくれるから。
データパイプラインとBIツールを分離した方が保守性が圧倒的に高い。だから、「Metabase vs Superset」という比較は、実はBIツール選びの氷山の一角で、本当の問題は「データパイプラインの品質」だったりします。ツール選びより先に、データの信頼性を確保する方が100倍重要。
まとめ
- Metabaseはシンプルだけど、スケールに弱い。初心者向けのプロトタイプには最適だが、月10万クエリ超の本番環境では心許ない。UI操作だけでは複雑な集計に対応できない。
- Supersetは複雑だけど、スケールに強い。SQLを書ける人がいるなら、長期的には絶対こっち。キャッシング設定とRedis統合で、パフォーマンスが全然違う。
- 2026年のAI生成SQL機能は、どちらでも8割程度の精度。完全自動ではなく、人間が修正前提で使うべき。信頼しすぎは禁物です。
- 権限管理の複雑さはSuperset > Metabase。複数チームでの運用を考えるなら、初期設計を丁寧に。後から修正するのは本当に大変。
- 結局、チームのSQLスキルがボトルネック。BIツール選びより「SQLが書ける人を育成する」ことの方が重要だと痛感した。
次のアクション：
- 月間クエリ数を測定する
- チーム内のSQLスキル分布を把握する
- 6ヶ月単位でTools Sprintを設定して、実際に両方試す
- キャッシング戦略を事前に設計する（これがパフォーマンスの50%を決める）
繰り返しになりますが、BIツール選びは「データ品質管理」とセットで考えるべき。ツール選びだけに時間をかけるより、データの信頼性確保に時間をかけた方が、長期的には絶対に効きますよ。