SaaSへのMetabaseダッシュボード埋め込み：3つのモードとマルチテナント分離

あなたはSaaS製品を構築し、顧客は自分の数値を製品の中で見たいと考えています——別のツールで、別のログインの向こう側ではなく。Metabaseはこれを埋め込み（embedding）で解決しますが、「ダッシュボードを埋め込む」という言葉は、まったく異なる3つのモードと、すべてを左右する1つの問い——各顧客が厳密に自分のデータだけを見られるようにするにはどうするか——を覆い隠しています。

顧客を別のツールへ誘導することは、文脈・ログイン・定着を犠牲にします。埋め込み型アナリティクス——自社のインターフェース内に、自社ブランドで表示するダッシュボード——は製品の一部となり、データは意思決定が行われる場所に現れます。問題はやるかどうかではなく、常にどうやるかです——そしてMetabaseにおける「どうやるか」には3つの形があります。

• Static embedding（署名付き） — サーバー側で署名したJWTを用いたiframeです。パラメータ（例：顧客の識別子）はトークン内に固定され、ユーザーは操作も変更もできません。顧客ごとの固定パネルに最適です。オープンソースで利用可能です。
• Interactive embedding — SSO（JWT）でログインし、顧客が自分で問い（クエリ）を探索・作成できる、Metabase全体を埋め込む方式です。Pro/Enterpriseが必要で、data sandboxingと組み合わせます。
• 埋め込み型アナリティクスSDK（React） — Metabaseのコンポーネントを自社アプリケーション内に配置し、レイアウトやテーマをきめ細かく制御できます。Enterpriseの機能です。

マルチテナント製品において、起こりうる最悪の誤りは、ある顧客が他の顧客のデータを見てしまうことです。安全な分離はモードに依存します：

• Static embedding — テナントは、自社バックエンドで署名したJWT内の固定パラメータ（locked）として渡されます。トークンはサーバーの秘密鍵で署名されているため、顧客が別の識別子を偽造する術はありません。オープンソースにおける分離の道です。
• Interactive embedding + data sandboxing — 顧客が自由に探索しても、JWTのユーザーに応じて行レベルのフィルタが自動的に適用されます。自由な探索に対する最も強力な分離であり、Enterpriseです。
• sandboxingなしのOSS — オープンソースで探索が必要な場合、進むべき道はテナントごとに接続/スキーマでデータを分離することです（当社のMetabase OSSにおけるガバナンスの記事と同じアーキテクチャです）。

• tenant_idを編集可能なURLパラメータで渡すこと——顧客が数値を書き換えて隣の顧客のデータを見てしまいます。
• 「URLを誰も当てられないだろう」と考えて、署名なし（公開埋め込み）で埋め込むこと。
• フロントエンドでフィルタリングを行うと信頼すること——フィルタは署名付きトークンかデータベースの中に存在しなければならず、決してJavaScriptの中にあってはなりません。

実践的なルール：顧客がテナントごとのパネルを見るだけでよいなら、署名付きstatic embeddingで解決します——しかもオープンソースで動きます。行レベルの分離を保ちつつ探索して問いを作る必要があるなら、interactive embedding + data sandboxing（Enterprise）です。探索は必要だが予算がOSSなら、アーキテクチャ上でテナントごとにデータを分離してください。誤りは、実際の分離要件ではなく、デモの華やかさで選んでしまうことです。