Metabaseとは？構成・エディション差と本番構成への移行を実装視点で解説【2026年版】

Metabaseは、SQLを書かない利用者にもデータベースへの問い合わせを開放するOSSのBIツールです。GitHubのリリース一覧では2026年8月4日時点の最新が63系で、OSS版がv0.63.2、Enterprise版がv1.63.2として2026年7月29日に公開されています。導入そのものはJARを起動するだけで終わりますが、そのまま本番へ持ち込むと既定のH2データベースが足かせになります。この記事は、Javaアプリ本体とアプリケーションデータベースという構成の分かれ方、H2からPostgreSQLへ移す手順と前提、AGPLと商用ライセンスの境界、埋め込み機能で有償プランが必要になる線、そしてApache SupersetやLightdashと並べたときにMetabaseを選ぶ条件までを実装者の目線で整理したものです。

まとめ：Metabase採用の可否を分ける3つの実装条件

採用可否を分けるのは、画面の使いやすさではなく次の3点です。第一に、既定のH2アプリケーションデータベースをPostgreSQL 14以上へ移す作業を、公開前に計画へ組み込めるかどうか。第二に、SSO・行や列単位の権限・アプリ全体の埋め込みといった有償プランの線を越えるのかを、要件定義の段階で確定できるか。第三に、JAR実行ならJava 25の実行環境を、Dockerなら常駐コンテナを、誰が保守し続けるかを決められるか、です。

逆に、接続先が1系統でダッシュボードも数本に収まる規模なら、自前で立てる価値は薄い。この判断の根拠を、構成・本番移行・ライセンス・選定の順に分解しました。

MetabaseがOSS BIとして担う守備範囲と製品の成り立ち

SQLを書かない利用者にまでデータ参照を開放する製品の設計思想

Metabaseが引き受けているのは、データベースへの問い合わせを非エンジニアの手元まで降ろす部分です。画面から表と列を選び、絞り込み条件を足していくと、内部でSQLへ変換されて実行されます。SQLエディタも併存するため、分析担当が書いたクエリを保存し、営業部門はその結果をダッシュボードで眺めるという分業が成立します。

この守備範囲は、データ変換やパイプライン構築までは含みません。取り込み済みのデータをどう見せるかに絞られており、前段のETLや基盤側は別の道具が受け持ちます。BIツール全般の選定軸から整理したい場合はBIツールとは？できること・ダッシュボードでの可視化・選定軸を先に読むと、Metabaseがどの層の製品なのかを掴みやすくなります。

63系まで進んだ版数体系とOSS版・Enterprise版の番号の対応

版数の読み方には癖があります。GitHubのリリースは「Metabase 63.2」という表記でまとめられ、その中にOSS版のv0.63.2とEnterprise版のv1.63.2が並びます。先頭の0と1がエディションの区別で、63.2という後半が実際の版数です。ドキュメントやDockerタグでどちらの番号を指しているのか、取り違えると別ビルドを引くことになります。

リリース間隔は短く、2026年7月28日から29日にかけてだけでも63.2・62.7・62.6・61.9が並んで公開されました。63系が出た後も62系や61系に修正が入る形です。運用側は最新へ追随するか、特定の系に留まって修正だけ拾うかを先に決めておくと、更新のたびに判断を迫られずに済みます。

Metabaseの構成要素とクエリ実行が通るデータ経路の全体像

Javaアプリ本体とアプリケーションデータベースが担う役割の分担

Metabaseは大きく2つの入れ物でできています。ひとつはJavaで書かれたアプリ本体で、画面の配信・SQLへの変換・接続先への問い合わせを担当します。もうひとつがアプリケーションデータベースで、ここには利用者アカウント、保存した質問、ダッシュボードの配置、権限設定、接続情報といったMetabase自身の状態が入る仕組みです。

分析対象のデータは、このアプリケーションデータベースには入りません。問い合わせのたびに接続先のPostgreSQLやBigQueryへSQLが飛び、結果だけが返ってきて画面に描かれる。つまりMetabaseは保管庫ではなく通り道です。この分離を理解しておくと、次に述べる本番移行の話がなぜ設定変更ではなくデータ移行なのかが腑に落ちます。

モデルとメトリクスによる指標定義の共有とセマンティック層の限界

保存した質問をそのまま使い回すと、部署ごとに少しずつ違う集計が増えていきます。これを抑える仕組みがモデルで、公式ドキュメントでは「新しい質問の出発点として使うことを意図した、特別な保存済み質問」という位置づけです。列の説明やメタデータを整えたモデルを土台にすれば、分析の起点が揃います。メトリクスは指標そのものの定義を共有する仕組みで、売上や継続率といった数式を一箇所に置けます。

ただし、これを本格的なセマンティックレイヤーと同列に見ると期待が外れます。モデルは同一データベース内の表から派生させる作りで、指標定義をコードとして版管理し、レビューを通して配布するといった運用は前提にされていません。指標の定義を巡って部署間の調整が頻発する組織では、Metabaseの手前にモデリング層を別途置く構えになります。

モデル永続化とキャッシュ設定で問い合わせ負荷を抑える運用の打ち手

都度実行が基本である以上、接続先のデータベースには利用者の数だけ負荷がかかります。緩和策の一段目がモデル永続化で、モデルの結果を接続先に実体テーブルとして書き出し、決めた間隔で更新します。二段目がキャッシュで、同じ問い合わせの結果を一定時間再利用する仕組みです。

永続化には副作用があります。書き出し先のスキーマに実体が増えるため、接続用アカウントに書き込み権限を渡す必要が出てきます。読み取り専用で通していた運用方針とぶつかる箇所なので、権限設計の段階で扱いを決めておくべきです。ダッシュボードの表示が遅いという相談は、多くの場合ここと接続先側のインデックス設計の両面から見ることになります。

アプリケーションデータベースをH2からPostgreSQLへ移す判断

既定のH2が検証用にとどまる理由と本番運用で生じる破損のリスク

初回起動時、Metabaseはアプリケーションデータベースとして組み込みのH2をファイルとして作ります。公式ドキュメントはこれを「ローカルマシンでMetabaseを手軽に試せるようにするため」と説明したうえで、本番導入ではPostgreSQLへ置き換えることを推奨しています。

H2のまま運用を続けた場合の困りごとは具体的です。ファイル1個に全設定が入るため、プロセスの異常終了やコンテナの入れ替えでファイルが壊れると、ダッシュボードも権限設定もまとめて失われます。バックアップもファイルコピーに依存し、稼働中の整合性を保証しにくい。なお接続先としてのH2はバージョン46.6.4以降サポート対象から外れており、アプリケーションデータベースとしての組み込みだけが残っている点も押さえておきましょう。

load-from-h2コマンドで移行する手順と版を揃える前提条件

移行はコマンド一発ではなく、停止を伴う手順です。公式ドキュメントが示す流れは次のとおりです。

1. 移行先データベースへの疎通を確認する
2. Metabaseインスタンスを停止する
3. H2のアプリケーションデータベースファイルを退避する
4. 空の移行先に対して load-from-h2 コマンドを実行する
5. 接続情報を渡した通常起動に切り替えて動作を確認する

前提条件として公式が強く警告しているのが版の一致です。H2ファイルを作った版、移行作業に使う版、本番で動かす版が同一である必要があり、移行と版上げを同時に行わないよう明記されています。作業当日に最新版へ上げたくなる場面はありますが、移行完了を確認してから別作業として上げる。この順序を崩すと、失敗時にどちらが原因か切り分けられなくなります。

PostgreSQL 14以上とMySQL 8.4以上という接続先の版要件

移行先に選べるのはPostgreSQL、MySQL、MariaDBの3種です。公式ドキュメントが示す最低版はPostgreSQLが14、MySQLが8.4.0、MariaDBが10.6.0で、MySQL系では文字セットに utf8mb4 が必須と指定されています。日本語のダッシュボード名や質問名を扱う以上、この指定を外すと保存時に落ちます。

接続先の指定は環境変数で行い、種別を MB_DB_TYPE に、接続文字列を MB_DB_CONNECTION_URI に渡します。推奨はPostgreSQLで、公式は「サポートされている最も古い版から最新の安定版まで」という書き方をしているため、PostgreSQL側の提供終了時期に合わせて更新計画を引く形になります。既存の社内データベースに相乗りさせるか、Metabase専用に1つ立てるかは、停止許容時間とバックアップ運用をどちらに寄せるかで決めてください。

OSS版と有償プランを分けるライセンスの境界と埋め込み機能の可否

AGPLが及ぶ範囲とenterpriseディレクトリの商用ライセンス

ライセンスは1本ではありません。リポジトリのLICENSE.txtは、最上位のenterpriseディレクトリの外にあるソースコードをAGPLとし、非enterpriseのバイナリもAGPLで配布すると定めています。裏を返すと、enterpriseディレクトリ配下は別建ての商用ライセンスです。無償で自己ホストする場合に手にしているのは前者だと理解しておく必要があります。

社内で自社データを見るためにOSS版を立てる分には、AGPLの条件が問題になる場面はほぼありません。判断が要るのは、Metabaseを改変して社外の利用者にネットワーク越しに提供する構成です。AGPLは改変版をネットワーク経由で提供する場合にソース開示を求める条項を持つため、SaaSへ組み込んで顧客に見せる設計を採るなら、法務を交えた確認を設計段階で済ませておきましょう。ライセンス条項と商用利用の可否をもう少し噛み砕いた説明はMetabaseの使い方｜料金・商用利用・無料OSS版でできることで扱っています。

StarterとProの月額と含まれるユーザー数で見る費用の分岐

2026年8月4日時点の公式Pricingでは、プランは4段構成です。

年払いにするとStarterが月90ドル、Proが月517.50ドルまで下がり、Enterpriseは年2万ドルからと明示されています。ここで効くのは基本料の差ではなく人数の伸び方です。Proは10人を超えると1人あたり月12ドルが積み上がり、社内利用者と埋め込み先の利用者が両方カウント対象になります。数百人規模の閲覧者を抱える見込みなら、有償プランの総額と自己ホスト＋保守工数を並べて比べる段階に入ります。プラン別の機能差を逐条で追いたい場合は、前掲の使い方記事側が詳しい参照先です。

ゲスト埋め込みとSSO埋め込みで分かれる必要プランと実装の方式

自社サービスの画面にダッシュボードを埋める場合、必要なプランは方式で変わります。パラメータを固定したゲスト埋め込みは、OSS版とStarterを含む全プランで使えます。認証なしの公開リンクも同様です。一方、SSOで利用者を識別し、権限に応じて見せる範囲を変えるモジュラー埋め込みと、アプリ全体をiframeに収めるフルアプリ埋め込みは、ProまたはEnterpriseが前提になります。

実装手段はフレームワークを問わないWebコンポーネントと、細かい制御ができるReact SDKの2系統です。テナントごとにデータを出し分けるマルチテナント型の分析機能を製品に組み込む要件なら、無償のまま進む道はありません。要件定義で「顧客ごとに見える行を変えたい」という一文が出た時点で、費用は有償プラン側で見積もっておくのが安全です。

Metabaseの導入形態とデータソース接続で詰まりやすい要件

Metabase CloudとDockerとJARで変わる保守範囲の線引き

自己ホストの手段はDocker、JAR、Podman、Azure Web Apps、systemdサービス、ソースからのビルドと幅があり、隔離環境向けのエアギャップ版も用意されています。公式が推奨として挙げているのはMetabase Cloudと、自己ホストならDockerです。JARは手軽な半面、ドキュメント自身が「本番へ移す際に難しくなる可能性がある」と注意書きを添えています。

JARで動かす場合の実行環境は明確に指定されています。Eclipse Temurin配布のJRE 25が推奨で、それ以前のJavaはサポート対象外です。待ち受けポートは既定で3000、変更は MB_JETTY_PORT で行います。社内の標準JavaがまだLTSの旧版で固定されている組織では、この一点だけでDocker採用に倒れることも珍しくありません。

公式ドライバ18種とコミュニティ製ドライバで異なるサポート範囲

同梱される公式ドライバは18種で、内訳は次のとおりです。

• 汎用RDB：PostgreSQL、MySQL、MariaDB、SQL Server、Oracle、SQLite、Vertica
• クラウドDWH：BigQuery、Snowflake、Redshift、Databricks、Athena
• 分散・列指向：ClickHouse、Druid、Presto、Starburst、SparkSQL
• ドキュメント指向：MongoDB

この一覧に無い接続先はコミュニティ製ドライバを探すことになりますが、公式ドキュメントはMetabaseチームが保守する上記ドライバについて、ProとEnterpriseの契約者が公式サポートを受けられると書いています。裏返せば、コミュニティ製ドライバで組んだ接続は不具合時に自力で追う前提です。接続先が一覧外の製品なら、Metabaseの手前にPostgreSQLやDWHを1枚挟んで公式ドライバの範囲に収める構成のほうが、運用は確実に軽くなります。

他のBIツールと比べたときにMetabaseを選ぶ条件と見送る場面

SupersetやLightdashと並べたときに残るMetabaseの利点

OSSのBIで比較対象に挙がるのは、Apache SupersetとLightdashです。3者は思想が違います。

Metabaseが残す利点は、立ち上げから利用者への配布までの距離が最も短いことに尽きます。常駐させる要素がアプリ本体とアプリケーションデータベースの2つで済み、指標定義のために別の言語やツールを覚える必要もありません。構成要素の多さと引き換えに細かい制御を取るならApache Supersetとは？構成・Docker導入手順とMetabase比較を、dbtで指標をすでに管理しているならLightdashとは？オープンソースBIツールの基本概要を並べて検討してください。

ダッシュボードが数本で終わる規模でMetabaseを見送る判断の根拠

採用を見送るべき条件を先に言い切ります。接続先が1系統で、見たいダッシュボードが5本前後に収まり、閲覧者も10人以下。この規模ならMetabaseを自己ホストする理由はありません。得られるものに対して、アプリケーションデータベースの移行・Java実行環境の維持・版上げ追随という3つの負債が明らかに重すぎます。

もうひとつ見送る場面があります。指標の定義が部署ごとに割れていて、まずその統一から始めなければならない状態のときです。Metabaseを入れると各部署が自由に質問を保存できるため、定義の揺れがダッシュボードの本数だけ増えて固定されます。この順序で失敗した現場では、後から数字が合わない原因を追う工数のほうが大きくなります。定義を先に揃え、道具はその後です。

受託開発でMetabaseを採用するときに設計者が固める運用要件

採用する場合、設計段階で決め切っておく項目は4つです。アプリケーションデータベースをどのPostgreSQLに置きどうバックアップするか、接続用アカウントの権限をモデル永続化まで見越して読み取り専用にするか否か、埋め込み要件が有償プランの線を越えるか、そして版上げの追随方針をどの系に置くか。ここを曖昧にしたまま公開すると、運用開始後の変更コストが跳ね上がります。

社内にJavaとPostgreSQLの保守要員を置けない場合は、Metabase Cloudへ寄せるか、基盤ごと外部に任せる判断が現実的です。一創ではBIツール導入支援として、接続先の設計から権限モデル、埋め込み要件の切り分けまでを含めた構築を請け負っています。要件がProプランの線を越えるかどうかの見極めだけでも、先に済ませておくと予算の組み直しを避けられます。

よくある質問

Metabaseの検討時に問い合わせの多い論点を、公式ドキュメントとPricingの記載に沿って整理します。

Metabaseは商用利用できますか？

OSS版を自社の業務で使うこと自体に費用は発生しません。リポジトリのLICENSE.txtは、enterpriseディレクトリの外にあるコードと非enterpriseバイナリをAGPLで配布すると定めており、社内でデータを見る用途はこの範囲に収まります。判断が必要になるのは、Metabaseを改変して社外の利用者にネットワーク越しに提供する構成です。AGPLの開示条項が関わるため、自社サービスへ組み込んで顧客に見せる設計なら法務確認を設計段階で挟んでください。

Metabaseの無料版と有料プランは何が違いますか？

2026年8月4日時点の公式Pricingでは、Open Sourceは自己ホストかつ利用者数無制限で無料、Starterは月100ドルからのクラウド提供です。有償側で増えるのは主に、行や列単位の権限、SSO、キャッシュ制御、利用状況分析、マルチテナント向けの埋め込みで、これらはPro以上に含まれます。無償のまま進めるかどうかは、機能一覧よりも「利用者ごとに見える行を変える要件があるか」で切り分けると判断が早くなります。

Metabaseは日本語に対応していますか？

対応しています。ロケールコードはjaで、管理画面のAdmin配下にあるLocalization設定からインスタンス全体の言語を指定でき、利用者が個人設定で上書きすることも可能です。ただし公式ドキュメントは、翻訳の一部がコミュニティによる貢献であり完全ではない場合があると断っています。言語がリリースに含まれ続けるには翻訳率100%の維持が条件とされているため、版によって未訳の項目が現れる余地は残ります。

Metabaseのインストールにはどんな環境が必要ですか？

JARで動かす場合はEclipse Temurin配布のJRE 25が推奨で、それ以前のJavaはサポート対象外です。待ち受けポートは既定で3000、変更はMB_JETTY_PORTで行います。Dockerを使えばJavaの版を意識せずに済むため、自己ホストではDockerが公式の推奨です。いずれの方法でも初回起動時のアプリケーションデータベースはH2になるので、本番で使うならPostgreSQL 14以上への移行を公開前の作業として組み込んでおきましょう。

MetabaseとLooker Studioはどう使い分けますか？

接続先とデータの置き場所が、両者を分ける判断軸です。Looker StudioはGoogleのサービス群、とりわけBigQueryやGoogle広告との組み合わせで手数が少なく、無料で始められます。Metabaseは社内のPostgreSQLやMySQLに直接つなぎ、権限を細かく設計して社内向けに配る用途で強みが出ます。データがGoogle側に集まっているならLooker Studio、オンプレミスや自社クラウドのデータベースが主役ならMetabase、という切り分けが実務では扱いやすい線引きです。

関連記事

• BIツール比較｜主要製品の違い・料金と失敗しない選び方：商用BIも含めた製品全体の比較軸を確認できます
• 無料BIツール比較｜無償版・OSSの範囲と有償化ライン：どこから費用が発生するかを製品横断で整理しています
• Looker Studioとは｜無料BIツールの機能・料金・BigQuery連携：Google系データが主役の場合の比較対象です
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順：BIの手前にあるデータ基盤側の設計を扱っています