MetabaseからSupersetに移行して1年、正直に振り返る選定の後悔と収穫

去年の春、うちのチームでMetabaseからSupersetへの移行を決めた。その判断が正解だったかどうか、正直1年経った今もまだ100%確信は持てていない。ただ、移行を経験したことで「BIツール選定って本当は何で判断すべきか」というのがかなりクリアに見えてきた。

同じような選定に悩んでいるチームは多いと思う。「Metabaseは簡単だけどスケールしない」「SupersetはOSSで無料だけど運用が重い」みたいな雑な言説もよく見るけど、実際に両方を本番で動かした経験からすると、それだけじゃ全然足りない。今日はそのあたりを正直に書いていく。

移行前の状況と、なぜMetabaseじゃ足りなくなったか

移行前はMetabase 0.50系（2025年末時点）を使っていた。小規模スタートだったこともあり、最初は本当に良かった。非エンジニアのビジネスメンバーでもダッシュボードを作れるし、SQLが書けなくてもグラフを出せる。セットアップもDocker Composeで30分あれば動く。

ただ、チームのデータ活用が進むにつれてきつくなってきたポイントが3つあった。

まずカスタムビジュアライゼーションの限界。Metabaseはデフォルトで用意されているグラフタイプ以外を使おうとすると途端に辛くなる。ビジネスサイドから「ファネルチャートを出してほしい」「Sankey Diagramで遷移を見たい」みたいなリクエストが増えてきたとき、Metabaseでは対応できないか、できても複雑なワークアラウンドが必要だった。

次に権限管理の粒度。Metabaseの権限はグループベースで割と大雑把で、「このダッシュボードはこの部門だけ見せたい、でもデータソースは共通」みたいな細かい制御がしにくかった。RLSもあるにはあるが、設定が直感的じゃない。

そしてAI機能の差。2026年時点でBIツールのAIアシスト機能はかなり差がついてきた。Metabaseもv0.52以降でAI SQL生成機能を追加してきたが、Supersetのコミュニティが開発している自然言語クエリの完成度とは差がある。ここはまだ正直どちらも発展途上なんだけど。

データ基盤の設計についてはデータ品質管理2026年版やデータカタログ完全ガイド2026 でも触れているので、合わせて読んでみてほしい。

MetabaseとSupersetの2026年時点の機能比較

実際に使い込んで感じた差を表にまとめた。スペック表だけじゃなく「実際の運用感」も含めて評価している。

項目	Metabase 0.52	Apache Superset 4.1
セットアップ難易度	★★★★★（非常に簡単）	★★★（Docker必須、設定多め）
非エンジニア向け操作性	★★★★★	★★★
ビジュアライゼーション種類	20種類程度	50種類以上
カスタムViz（ECharts等）	制限あり	Plugin対応、自由度高
SQL Lab	基本的なもの	フル機能エディタ
AI SQLアシスト	v0.52で追加（Beta）	NL2SQL Plugin（2026年GA）
Row-Level Security	グループベース	細粒度のRLS対応
ダッシュボードフィルター	シンプル	クロスフィルター対応
アラート・レポート機能	Email/Slack対応	Email/Slack/Webhook対応
マルチテナント	限定的	対応
キャッシュ機構	内蔵	Redis連携
組み込みダッシュボード（Embedding）	有料プラン	OSS対応
月間アクティブコントリビュータ数	社内チーム主導	500人以上（2026年）
エンタープライズサポート	Metabase Pro/Enterprise	Preset.io等

数字だけ見るとSupersetが強そうに見えるけど、「非エンジニアが日常的にダッシュボードを触るチーム」においてはMetabaseの使いやすさは本当に圧倒的だった。うちのチームでは移行後、ビジネスメンバーが自分でダッシュボードを作る頻度がしばらく減ってしまった。これは想定外のコストだったし、個人的に一番後悔したポイントでもある。

実際の移行作業と、ハマったポイント

移行は3ヶ月かけてフェーズを分けてやった。アーキテクチャはこんな感じになっている。

flowchart TB
    subgraph DataSources["Data Sources"]
        PG[(PostgreSQL)]
        BQ[(BigQuery)]
        RD[(Redshift)]
    end

    subgraph Superset["Apache Superset 4.1 (Kubernetes)"]
        WEB["Superset Web\n(Gunicorn)"]
        WORKER["Celery Worker\n(非同期クエリ)"]
        BEAT["Celery Beat\n(スケジュール)"]
        CACHE[("Redis Cache")]
        META[("PostgreSQL Meta DB")]
    end

    subgraph Auth["認証・認可"]
        OIDC["Keycloak OIDC"]
    end

    BROWSER["ブラウザ"] --> WEB
    WEB --> META
    WEB --> CACHE
    WEB --> WORKER
    BEAT --> WORKER
    WEB --> OIDC
    WORKER --> DataSources
    WEB --> DataSources

Kubernetes上でのセットアップ

Helmチャートを使うのが一番楽だった。ただ、2026年時点のHelmチャート（superset/superset 0.14.x）は値の設定が微妙にわかりにくい部分がある。

# values.yaml 抜粋
supersetNode:
  connections:
    redis_host: redis-master
    redis_port: 6379
    redis_password: ""

  env:
    - name: SUPERSET_SECRET_KEY
      valueFrom:
        secretKeyRef:
          name: superset-secret
          key: secret-key

# カスタム設定はconfigOverridesに書く
configOverrides:
  my_override: |
    from flask_appbuilder.security.manager import AUTH_OAUTH
    AUTH_TYPE = AUTH_OAUTH
    OAUTH_PROVIDERS = [
      {
        'name': 'keycloak',
        'token_key': 'access_token',
        'icon': 'fa-key',
        'remote_app': {
          'client_id': 'superset',
          'client_secret': '${KEYCLOAK_SECRET}',
          'server_metadata_url': 'https://keycloak.example.com/realms/internal/.well-known/openid-configuration',
          'client_kwargs': {'scope': 'openid email profile'},
        },
      }
    ]
    FEATURE_FLAGS = {
      'ENABLE_TEMPLATE_PROCESSING': True,
      'DASHBOARD_CROSS_FILTERS': True,
      'DRILL_BY': True,
    }

ここで最初にハマったのがFEATURE_FLAGSだ。Supersetは機能の多くがFeature Flag経由で有効化する必要があって、デフォルトでOFFのものが意外と多い。DASHBOARD_CROSS_FILTERS（クロスフィルタリング）とDRILL_BY（ドリルダウン分析）は明示的に有効化しないと使えない。ドキュメントを読み込むまでこれに気づかず、「あれ、クロスフィルター動かないな……」って30分くらい無駄にした。

Row-Level Security の設定

Metabaseからの移行でいちばん工数がかかったのがここだった。SupersetのRLSはSQLAlchemyベースのフィルターで設定するんだけど、設定UIがまだちょっとわかりにくい。

# RLS ルール設定例（API経由での設定）
import requests

rls_rule = {
    "name": "department_filter",
    "description": "部門別アクセス制御",
    "filter_type": "Regular",
    "tables": [42],  # テーブルID
    "roles": [3],    # ロールID
    "clause": "department_id = '{{current_user_attribute('department_id')}}'",
    "group_key": "department",
}

response = requests.post(
    "http://superset:8088/api/v1/rowlevelsecurity/",
    json=rls_rule,
    headers={"Authorization": f"Bearer {access_token}"},
)

current_user_attribute() でJinja2テンプレート経由のユーザー属性を参照できる。Keycloakからのユーザー属性マッピングと組み合わせるとかなり柔軟な権限制御ができる。ただしJinja2テンプレート処理を有効化していないと動かないので、ENABLE_TEMPLATE_PROCESSING: True は必須——というのを最初に知らくて詰まった。

キャッシュ戦略

# superset_config.py のキャッシュ設定
from cachelib.redis import RedisCache

DATA_CACHE_CONFIG = {
    'CACHE_TYPE': 'RedisCache',
    'CACHE_DEFAULT_TIMEOUT': 3600,  # 1時間
    'CACHE_KEY_PREFIX': 'superset_data_',
    'CACHE_REDIS_HOST': 'redis-master',
    'CACHE_REDIS_PORT': 6379,
    'CACHE_REDIS_DB': 1,
}

# ダッシュボードごとのキャッシュタイムアウトも設定可能
WARM_CACHE_TIMEOUT = 300  # 5分

Redisキャッシュを入れてからクエリ応答が劇的に改善した。ビジネスメンバーがよく使うダッシュボードは定期的にキャッシュを温めるジョブ（superset cache-warmup）を回すようにした。地味に便利で、「なんかSuperset遅い」という不満がほぼ消えたのはこれのおかげだと思っている。

1年運用してわかったBIツール選定の本音

移行から1年経った今の感想を正直に書く。チーム内でアンケートを取ったので、その結果がこれだ（n=18）。

xychart-beta
    title "BIツール評価スコア（チーム内アンケート, n=18）"
    x-axis ["操作性", "機能性", "AI支援", "権限管理", "パフォーマンス", "運用負荷"]
    y-axis "スコア（10点満点）" 0 --> 10
    bar [8.5, 6.2, 6.8, 8.0, 7.5, 5.5]
    line [6.0, 8.8, 7.5, 8.5, 8.2, 7.0]

※棒グラフがMetabase、折れ線がSuperset

この結果を見ると、操作性ではMetabaseが圧勝、機能性と権限管理ではSupersetが勝るのがよくわかる。そして一番下の「運用負荷」——Supersetの7.0に対してMetabaseが5.5なのは、Metabaseの方が運用は楽ということだ（スコアが低いほど負荷が高い逆スケールで集計している）。

正直しんどかったのは、Supersetの運用エンジニアリングコストだ。Celery WorkerとBeatの死活監視、Redisのメモリ管理、定期的なDB vacuum、Helmチャートのアップグレード対応……Metabaseなら考えなくていいことが山ほどある。「OSSだから無料」という話をよく聞くけど、エンジニアの工数というコストはしっかりかかる。ここは過小評価しがちなので注意したほうがいい。

じゃあ移行は失敗だったかというと、そうは思っていない。うちのチームで実現したかった「部門をまたいだ細粒度のアクセス制御」と「カスタムVisualization」はSupersetでしかできなかった。目的と手段が合っていれば、コストは払う価値がある——そういう話だと思っている。

2026年のAI機能の実態

Supersetの自然言語クエリ（NL2SQL）機能を実際に試した結果がこれだ。

# Superset 4.1 NL2SQL API（実験的機能）
import requests

response = requests.post(
    "http://superset:8088/api/v1/database/1/nl2query",
    json={
        "user_question": "先月の日次売上を商品カテゴリ別に集計して",
        "schema": "public",
    },
    headers={"Authorization": f"Bearer {token}"},
)

result = response.json()
print(result["sql"])
# -> SELECT
#      DATE(created_at) AS date,
#      product_category,
#      SUM(amount) AS total_sales
#    FROM orders
#    WHERE created_at >= DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
#      AND created_at < DATE_TRUNC('month', CURRENT_DATE)
#    GROUP BY 1, 2
#    ORDER BY 1, 2

精度は……正直「まあ使えるかも」というレベルだ。シンプルな集計クエリは8割くらいの精度で出てくる。ただしJOINが絡んだり複雑な条件が入ると途端に怪しくなる。Metabaseも似たような状況なので、2026年時点ではどちらも「おまけ機能」として見ておいたほうがいい。AI機能を移行の主な理由にするのは早計だと思う。

データパイプラインの上流についてはデータパイプラインで2年間ハマり続けた話が参考になる。BIツールの問題の多くは実はパイプライン側に原因があったりするので、合わせて読んでほしい。

どのチームがどちらを選ぶべきか

1年の経験から言えることを整理すると、こんな感じになる。

Metabaseを選ぶべきチーム:

データアナリストやビジネスメンバーが自分でダッシュボードを作ることが前提
エンジニアリングリソースが限られている（SREやインフラが専任でいない）
スタートアップや小〜中規模のデータチーム
素早く立ち上げて価値を出したい（PoC、MVP段階）

Supersetを選ぶべきチーム:

細粒度の権限管理が必要（マルチテナント、部門分離）
カスタムVisualizationや高度なダッシュボードが必要
データエンジニアが専任でSuperset運用を担当できる
OSSのエコシステムに乗っかりたい（カスタマイズの自由度を重視）
EmbeddingでBIを自社サービスに組み込みたい

「どちらがいいか」じゃなくて「自分たちのチームに何が必要か」で決める話なんですよね。当たり前に聞こえるかもしれないけど、これを整理せずに移行すると後で相当痛い目を見る。うちはかかったので。

Supersetのパフォーマンス実測と最適化

Kubernetes上でのSupersetで実測したクエリ応答時間の改善記録がこれだ。

xychart-beta
    title "クエリ応答時間の改善推移（中央値, ms）"
    x-axis ["初期構成", "Redis追加", "非同期クエリ", "クエリキャッシュ", "コネクションプール"]
    y-axis "応答時間 (ms)" 0 --> 8000
    bar [7200, 4800, 3100, 1200, 850]

最終的に初期構成の約12%まで応答時間を改善できた。効いた施策の順番はこの通り。

Redisキャッシュ追加: 同じクエリの2回目以降が劇的に速くなる
非同期クエリ有効化: 重いクエリがUIをブロックしなくなる
SQLAlchemyコネクションプール最適化: DBへの接続待ちを削減

# コネクションプール設定（superset_config.py）
SQLALCHEMY_POOL_SIZE = 10
SQLALCHEMY_MAX_OVERFLOW = 20
SQLALCHEMY_POOL_TIMEOUT = 30
SQLALCHEMY_POOL_RECYCLE = 3600  # 接続を1時間ごとにリサイクル

# 非同期クエリ設定
RESULTS_BACKEND = RedisCache(
    host='redis-master',
    port=6379,
    db=2,
    default_timeout=86400,  # 結果を24時間保持
)

個人的には最初から全部やっておけば良かったと思っている。特にコネクションプールの最適化は「後でやればいいか」と後回しにしがちだけど、トラフィックが増えてから詰まると対処が大変だった。

BigQueryとの連携については BigQuery vs Athena vs Redshift 2026 を読んでもらうとデータウェアハウス選定の文脈が分かる。Supersetはどのデータソースを背後に使うかによってパフォーマンス特性がかなり変わるので、DWH選定とBI選定はセットで考えた方がいい。

まとめ

1年運用して言えること、正直にまとめる。

Metabaseの「簡単さ」は本物: 非エンジニアが自走できるかどうかに一番差が出る。これを軽視して移行すると後悔する（うちがそうだった）
Supersetの「自由度」は運用コストとトレードオフ: 細粒度の権限管理・カスタムViz・Embeddingが必要なら選ぶ価値は高い。ただし専任の運用担当者がいること前提
AI機能は2026年時点ではまだおまけ: NL2SQLはどちらもベータ品質。意思決定の主軸に置かない方がいい
キャッシュとコネクションプールは最初から設計する: 後付けでも改善できるが、最初からやっておけば良かったと後悔した
移行は3ヶ月以上かかると見積もる: ダッシュボードの移植だけじゃなく、ユーザー教育と権限設計の見直しに時間がかかる

次のアクション: もし今Metabaseを使っていて「スケールしてきた」と感じているなら、まず権限管理の要件とカスタムVisualizationの需要を整理してみてほしい。そこに明確なニーズがなければ、Metabaseのままv0.52の機能強化を待つのも全然ありだと思う。移行はコストが高い。「なんとなく移行したい」ではなく「これができないから移行する」という明確な理由を持ってから動いた方がいい——というのが1年かけて学んだ一番大事な教訓だった。

皆さんのチームではBIツールどう選んでいますか？MetabaseでもSupersetでも、選定の背景や移行経験があればぜひ聞かせてほしい。

移行前の状況と、なぜMetabaseじゃ足りなくなったか

MetabaseとSupersetの2026年時点の機能比較

実際の移行作業と、ハマったポイント

Kubernetes上でのセットアップ

Row-Level Security の設定

キャッシュ戦略

1年運用してわかったBIツール選定の本音

2026年のAI機能の実態

どのチームがどちらを選ぶべきか

Supersetのパフォーマンス実測と最適化

まとめ

関連記事

Metabase→Supersetに乗り替えて気づいた本当の差｜本番運用6ヶ月の実体験

MetabaseとSuperset徹底比較2026｜AIアシスト・セルフサービスBI選定ガイド

データカタログ3回失敗して分かった、ようやく「使われる」ようになった話

dbt Core 2.0移行後1年、本番運用で積み上がった設計の知見

データパイプラインで2年間ハマり続けた話｜Airflow・dbt・Kafka本番運用の現実

Kafkaで本番止めた話｜ストリーム処理2年運用の失敗記録