組み込み分析とは？実装方式4種の比較と内製・外注の判断基準【2026年版】

自社のSaaSや業務システムの画面に、顧客ごとのグラフやレポートを表示したい。この要望に応える手段が組み込み分析（Embedded Analytics）です。ただし「BIツールを買えば済む」という話ではなく、公開リンクを貼るだけの構成から、Reactコンポーネントとして自社UIに溶かし込む構成まで、実装方式によって工数もライセンス費も一桁変わります。この記事で扱うのは、定義と実装方式4種の違い、権限分離の設計、主要製品の価格帯、内製と外注の判断基準。採用を見送るべき条件も具体的に示します。

まとめ｜組み込み分析を自社SaaSに採用すべき条件と実装方式選定の判断軸

結論から示します。組み込み分析を採用する価値があるのは、顧客ごとにデータが分かれていて、かつ見たい集計軸が今後も増え続けるプロダクトです。集計軸が3つか4つに固定でこの先も増えないなら、BI製品を挟まず自前のグラフライブラリで描いたほうが安く速く終わります。

実装方式は、顧客に見せるデータの機密度で決まります。社外に出しても構わないデータなら公開リンク埋め込みで数時間、顧客ごとに隔離するなら署名付き埋め込みで1〜2週間、自社UIと見分けがつかない体験ならSDK埋め込みで1〜3か月が目安です。

費用は、ライセンス費より実装と運用の人件費のほうが大きくなります。Metabaseの高度な埋め込み機能はPro以上（月額575ドルから）、Power BI Embeddedは本番運用にA SKUなどの容量購入が必須。内製か外注かは、専任エンジニアを1名以上・半年以上張り付けられるかで分かれます。

組み込み分析の定義とBIツール単体・自社実装ダッシュボードとの境界

ベンダー資料の「アプリケーション内に分析機能を統合する手法」という説明では、自社で作ったグラフ画面との違いが見えません。境界を実装の観点で引き直します。

組み込み分析の定義｜別ツールへ遷移せずアプリ内で完結する分析体験

組み込み分析とは、BI製品が持つ集計・可視化のエンジンを、自社アプリケーションの画面内から呼び出して結果を表示する構成を指します。判定基準はひとつ、利用者が別のURLやアプリに遷移しないことです。

従来のBI利用では、業務システムで数字を入力した担当者が、集計を見るためにBIツールへログインし直していました。別ツールへの遷移が挟まると、月次で数回しか開かれない画面になりがちです。もうひとつの特徴が提供者と利用者が分かれる点。ライセンスを持つのは自社だけで、画面を見る顧客はBI製品の存在を意識しません。ホワイトラベルと呼ばれる形態です。

BIツール導入との違い｜利用者が社内か顧客かで変わる設計要件

社内向けにBIを導入する場合と、顧客向けに分析画面を提供する場合とでは、必要な設計がまるで異なります。社内向けなら「部署ごとに見える範囲を分ける」程度の権限設計で足りるのに対し、顧客向けではA社の担当者がB社のデータを1行たりとも見られない保証が要ります。

社内BIはデータソースを接続してダッシュボードを組めば動き出しますが、顧客向けでは認証連携・テナント境界・トークン発行・監査ログの4点セットが追加されます。BI製品の機能や選定軸はBIツールでできることと選定軸を整理した解説記事で扱うため、本記事は顧客向け提供に固有の論点に絞ります。

自前グラフ実装との分岐点｜集計軸の変更頻度で決まる採用ライン

Chart.jsやApache EChartsで自前描画する選択肢も残ります。分岐点は集計軸の変更頻度です。表示するグラフが「月次売上の推移」のように固定で、変更要望が年に1度あるかどうかなら、SQLを1本書いてAPIを生やすだけの自前実装が安く済みます。

逆に、顧客から「この軸で切りたい」という要望が四半期ごとに複数届くなら、その都度エンジニアが実装する構成は破綻します。BI製品を挟めば顧客自身がドリルダウンやフィルタを操作でき、開発チームは対応から解放されます。年間で6件以上のグラフ追加要望が見込まれるあたりが、切り替えの現実的なラインです。

組み込み分析の実装方式4種｜公開リンクから署名付き・SDK・フルアプリまで

実装方式は、セキュリティ要件と見た目の要求水準で4種類に整理できます。Metabaseのドキュメントでは Public embeds、Guest embedding、Modular embedding SDK、Full app embedding という呼称が使われており（2026年8月時点）、他製品でも構造はおおむね共通します。

公開リンク埋め込み｜社外秘データを扱えない前提と適用できる範囲

ダッシュボードに公開URLを発行し、iframeで自社画面に貼る方式です。実装は最短で数十分。認証もトークン発行も不要です。

制約は明確で、URLを知っている人は誰でも中身を見られます。適用できるのは、サービスの稼働状況を示すステータスページや公開統計を加工したレポートなど、全ユーザーに同じ内容を見せる用途に限られます。URLにテナントIDを付けて出し分ける実装を見かけますが、IDを書き換えれば他社のデータが見えるため採用してはいけません。

署名付き埋め込み｜サーバ側でトークンを発行する最小構成の手順

実務でもっとも採用されるのがこの方式です。自社バックエンドがログイン中のユーザーに対応するトークンを署名付きで発行し、そのトークンを含むURLをiframeに渡す。BI製品側はトークンを検証し、埋め込まれたパラメータでデータを絞り込みます。Apache Supersetを例に取った手順が次のとおりです。

1. 設定で EMBEDDED_SUPERSET フィーチャーフラグを有効にする
2. GUEST_TOKEN_JWT_SECRET に本番用のシークレットを設定する（既定値のままの本番運用は不可）
3. 自社バックエンドからサービスアカウントで guest_token エンドポイントを呼び、ゲストトークンを取得する
4. 取得したトークンをフロントへ渡し、npmパッケージ @superset-ui/embedded-sdk の fetchGuestToken から返す

ゲストトークンには行レベルセキュリティ（RLS）のルールを載せられ、これがテナント境界の実体になります。Superset 5.0系では、ゲストトークンのRLSが適用されるのは EMBEDDED_SUPERSET が有効な場合に限られ、4.1.3系までの常時適用から挙動が変わりました。バージョンを上げる際は差分の確認が要ります。なお、トークン取得のエンドポイントをブラウザ側から直接叩いてはいけません。

SDK埋め込み｜ReactコンポーネントとしてUIに溶かす方式の条件

iframeではなく、BI製品が提供するReactコンポーネントを自社アプリのコンポーネントツリーに直接置く方式です。フォントも配色も自社のデザインシステムに合わせられるため、iframeにありがちな「枠の中だけ別サービス」という見え方が消えます。

採用条件はふたつ。フロントエンドがReactで構築されていること、そして有償プランを前提にできることです。Metabaseの高度な埋め込み機能はProおよびEnterpriseで提供され、Open SourceとStarterではSSOを伴わない構成に限られます。工数は署名付き埋め込みの2〜3倍。Metabaseの構成とエディション差を実装視点でまとめた記事に、本番構成へ移行する際の設定差を記載しています。

フルアプリ埋め込みとAPI自前描画｜4方式の比較表と選定順序

フルアプリ埋め込みは、BI製品のアプリケーション全体をiframeで表示し、顧客に探索操作まで開放する方式です。顧客側にデータ分析の担当者がいる法人向けSaaSでは有効な一方、BI製品のUIがそのまま露出するためコンシューマ向けには向きません。クエリAPIだけを使って自前のグラフライブラリで描く構成もありますが、フィルタもドリルダウンも自作になり、BI製品を挟む意味が薄れます。

選定順序は、まず公開リンクで足りるかを確認し、足りなければ署名付き埋め込みを既定とします。SDK埋め込みへ進むのは、署名付きで作ったプロトタイプを見て「製品体験として浮いている」と判断できたとき。最初からSDKを選ぶと、要件が固まらないまま工数だけが膨らみます。

マルチテナントSaaSにおける権限分離・データ隔離とトークン設計の論点

組み込み分析のプロジェクトで工数が読み違えられるのは、可視化ではなく権限まわりです。詰まる箇所を先に潰しておきます。

テナント境界の担保｜行レベルセキュリティとトークン埋め込み値

顧客別にデータを隔離する実装は、行レベルセキュリティ（RLS）で行います。トークンにテナントIDを埋め込み、BI製品側で「WHERE tenant_id = トークンの値」に相当するフィルタを強制する構造です。

落とし穴は、テナントIDをフロントエンドから渡してしまう実装にあります。開発者ツールでリクエストを書き換えれば、他社のデータが取得できてしまう。テナントIDは必ずサーバ側のセッションから取得し、トークンに封入してから署名する。この順序を崩さないことが唯一の防御になります。同じ顧客企業でも管理者は全店舗、店長は自店舗だけといった役割分離が要件に入りがちなので、RLSは2階層で設計しておくと後の改修が減ります。

トークンの有効期限と再発行｜セッション設計で詰まりやすい箇所

埋め込み用トークンの有効期限は、製品にもよりますが数分から数十分に設定します。短すぎると席を外した利用者の画面が固まり、長すぎると漏洩時の影響範囲が広がるためです。実装漏れが起きるのは再発行の経路。期限切れでiframeが無言のエラー表示になり、利用者からは「グラフが消えた」という問い合わせになります。フロント側で残り時間を監視し、期限前に再取得して差し替える処理を最初から入れておきます。

Power BI Embeddedでは、認証の型そのものが分岐します。Microsoft Learnの記載では、外部顧客に見せる「顧客向けに埋め込む」（アプリ所有データ）はサービスプリンシパルまたはマスターユーザーによる非対話型認証で、アプリ利用者にPower BIライセンスは不要です。一方「組織向けに埋め込む」（ユーザー所有データ）はMicrosoft Entra IDでの対話型認証となり、利用者ごとにライセンスが必要です。SaaSの顧客向けなら前者を選びます。

描画性能の担保｜集計テーブルの事前生成とクエリキャッシュの使い分け

顧客画面に載せる以上、表示は数秒以内に収めたいところです。ところがBI製品は裏で素直に集計SQLを流すため、数千万行のテーブルを毎回スキャンすれば当然待たされます。

対処は2段構え。日次や時次で集計済みテーブルを生成してダッシュボードはそこだけを参照させ、あわせてBI製品側のクエリキャッシュで同一条件の再表示を返します。この集計テーブルをどこに置くかは分析基盤側の設計判断になるため、構成要素や費用感はデータ分析基盤の構成要素と内製・外注の判断基準を整理した記事にまとめています。

組み込み分析のコスト構造｜ライセンス費・実装工数・運用負荷の内訳

ライセンス費だけを見積もって稟議を通し、あとから実装工数で膨らむケースが多く見られます。3つの費目に分けて目安を示します。

ライセンス費の実額｜Metabase・Power BI Embeddedの価格帯

Metabaseの公開価格ページ（2026年8月時点）では、Open Source版が無料・ユーザー数無制限、Starterが月額100ドル（初回5ユーザーを含む）、Proが月額575ドル（初回10ユーザーを含む）、Enterpriseは年額20,000ドルからのカスタム価格です。高度な埋め込み機能はProとEnterpriseで提供されるため、顧客向けの本番運用ではPro以上が実質的な下限になります。

Power BI Embeddedは容量単位の課金です。Microsoft Learnには、開発テストでは無料試用版トークンが使えるものの、本番運用には容量の購入が必要で、購入するまで埋め込みレポートの上部に試用版バナーが表示され続けると明記されています。SKUは、Power BI EmbeddedがA SKU、Power BI PremiumがPまたはEM SKU、Microsoft FabricがF SKUという整理。Supersetを自前ホストするならライセンス費はゼロで、代わりにインフラ費と運用工数を負担します。

実装工数の目安｜最小構成と権限分離込みの本番構成で変わる見積り幅

署名付き埋め込みでダッシュボード1枚をテナント分離ありで出すところまでなら、経験のあるエンジニアで10〜15人日が実感に近い数字です。内訳は、セットアップとデータソース接続に3人日、トークン発行と検証の実装に3人日、RLS設計とテストに4人日、ダッシュボード作成に2人日。

ここに複数の役割階層・監査ログ・多言語表示・PDFエクスポートが加わると、40〜60人日の規模へ跳ね上がります。要件定義の段階でこの4項目の要否を確定させておくと、見積りのぶれが小さくなります。

運用フェーズの費用｜バージョン追従とダッシュボード追加の負荷

公開後に効いてくるのがバージョン追従です。前述のとおりSuperset 5.0系ではRLSの適用条件が変わりました。OSS製品を自前ホストするなら、メジャーバージョンの更新ごとに埋め込み部分の回帰テストが必要になるため、年2回・各3〜5人日を運用予算に見込みます。

ダッシュボード追加の負荷は、誰が作るかで変わります。BI製品の画面から非エンジニアが作れる体制を整えれば1枚あたり半日程度、SQLの改修を伴うなら2〜3人日です。BIツール導入支援では体制づくりまで含めて設計と実装を請け負っており、初回の権限分離設計だけを依頼して以降を自社運用に切り替える進め方にも対応しています。

内製と外注の判断基準｜組み込み分析を自社開発すべき条件と見送る場面

ここは判断を言い切ります。玉虫色にすると、稟議も設計も止まるためです。

自社開発が成立する条件｜専任エンジニアと更新頻度の下限ライン

内製を選んでよいのは、次の3条件をすべて満たす場合に限ります。ひとつでも欠けるなら内製は選ばないでください。

• BI製品のセットアップと運用を担当する専任エンジニアを1名以上、6か月以上確保できる
• SQLとデータモデリングの経験者が社内にいる（集計テーブルの設計を外に出さずに済む）
• ダッシュボードの追加・改修が月1件以上発生し、外注では回転が追いつかない

3つ目が満たされない、つまり改修が年数回しかないプロダクトで内製を選ぶと、担当者が異動した瞬間に誰も触れない仕組みが残ります。

外注が有利になる場面｜初回リリースまでの期間を短縮したい局面

外注が明確に有利なのは、リリース期日が先に決まっている場合です。組み込み分析は、認証連携とRLS設計という「初めて触ると必ず時間を取られる」領域を含みます。経験のないチームが自力で進めると、トークンの検証エラーやCORSの設定だけで1〜2週間を消費します。既存の業務システムへ後付けする改修も外注向き。現行の認証基盤とトークン発行の接続は既存コードの読解が前提になるため、設計ごと委ねたほうが早く終わります。

併用パターン｜初期は外注で立ち上げ運用は内製へ移す分担の条件

現実に多いのがこの分担です。初回リリース（製品の選定、テナント分離の設計と実装、ダッシュボード3〜5枚）までを外注し、以降の追加を社内で回します。

機能する条件は2つ。引き渡し時にRLSの設計意図がドキュメント化されていることと、社内にSQLを書ける担当者がいることです。設計意図が口頭で終わると、半年後に「なぜこのフィルタが入っているか分からない」という理由でRLSを外す改修が入り、テナント境界が壊れます。引き渡し資料には、ルールごとに「どのテナント属性を、どのカラムで絞っているか」を必ず残してください。

組み込み分析で失敗する4パターンと着手前に潰しておく前提条件

実装そのものより、進め方で行き詰まる例のほうが多く見られます。頻度の高い順に4つ挙げます。

全顧客共通ダッシュボードを個社要望で分岐させ続ける設計の破綻

最初は全顧客に同じダッシュボードを見せる設計で始めます。そこへ「A社だけこの指標を追加してほしい」という要望が入り、条件分岐でしのぐ。これを繰り返すと、半年後には顧客数と同じだけのダッシュボードが並びます。着手時点で「個社カスタマイズは受けない。共通ダッシュボードにフィルタとして実装できるものだけ追加する」という線を引き、営業側と合意しておいてください。

BIツールのUIがそのまま露出し製品体験から浮く見た目の問題

フルアプリ埋め込みや素のiframeで組むと、BI製品のツールバーやロゴが顧客の目に触れます。法人向けの管理画面なら許容される場合もありますが、製品のブランド体験が競争力になっているコンシューマ向けサービスに、フルアプリ埋め込みを選ぶべきではありません。この場合はSDK埋め込みを選ぶか、そもそも自前描画に戻す判断が正解です。

本番DBを直接参照して顧客画面が重くなる構成と切り離しの判断時期

検証段階では本番DBに直接つないで動かします。データ量が少ないうちは動く。問題は顧客数が増えた後で、ダッシュボードを開くたびに重い集計SQLが本番DBへ流れ、業務システム本体のレスポンスまで落ちます。切り離しの判断時期は本番公開の前。公開後に動くと、稼働中のサービスへパイプライン追加と参照先変更を同時に行うことになり、リスクも工数も倍増します。

無料プランで検証しPro相当の費用に着手後に気づく見積り漏れ

Metabase Open SourceやSupersetで試作し、うまく動いたのでそのまま本番へ、という流れでつまずく例があります。SSO連携やSDKによる埋め込みが有償プランでの提供だと分かるのが実装の終盤になるためです。Power BI Embeddedでも、試用版トークンで開発を進めた末に本番直前で容量購入の必要が判明します。検証前に「本番で使う機能がどのプランに含まれるか」を価格ページで確認しておいてください。

よくある質問｜組み込み分析の導入判断と実装期間に関する5つの疑問

導入相談で実際に受ける質問のうち、判断に直結する5つに回答します。

組み込み分析とダッシュボードの違いは何ですか？

ダッシュボードは画面の形式を指す言葉で、組み込み分析は提供の仕方を指す言葉です。BIツールにログインして見るダッシュボードも、自社アプリの中に表示されるダッシュボードも、画面としては同じものになりえます。違いは、利用者が別ツールへ遷移するかどうか、そしてBI製品のライセンスを利用者側が持つ必要があるかどうか。顧客に見せる用途では後者の差が効いてきます。

小規模なSaaSでも組み込み分析を導入する価値はありますか？

顧客数が少なくても、集計軸の追加要望が定期的に来るなら価値があります。逆に、表示するグラフが数枚で固定なら、BI製品を挟まず自前で描いたほうが安く済みます。判断の目安は、年間で6件以上のグラフ追加要望が見込まれるかどうか。この水準を下回るなら、導入を見送って構いません。

無料のOSS製品だけで顧客向けの組み込み分析は実現できますか？

Apache Supersetを自前ホストする構成なら、ライセンス費ゼロで署名付き埋め込みまで実現できます。ゲストトークンとRLSによるテナント分離も標準機能です。ただしバージョン更新への追従、稼働監視、バックアップといった運用をすべて自社で負担します。Metabase Open Source版の場合、SSOを伴わない構成に限られるため、顧客の認証基盤と連携させたいならPro以上が必要になります。

組み込み分析の導入にはどれくらいの期間がかかりますか？

署名付き埋め込みでダッシュボード1枚をテナント分離ありで公開するまでなら、経験のあるチームで10〜15人日、暦日では3〜4週間が目安です。役割階層・監査ログ・多言語・PDFエクスポートが加わると40〜60人日、3〜4か月規模になります。期間の差はほぼ権限まわりの要件で決まるため、着手前にこの4項目の要否を確定させると見通しが立ちます。

既存の業務システムに後から組み込むことはできますか？

できます。ただし、既存システムの認証情報からテナントIDを取り出してトークンに封入する経路を新設する必要があり、この部分は現行コードの構造に依存します。セッション管理がフレームワーク標準に沿っていれば数日、独自実装なら1〜2週間の追加を見込んでください。あわせて、集計処理を本番DBから切り離す設計も同時に検討します。

関連記事

• BIツール比較｜主要製品の違い・料金と失敗しない選び方【2026年版】：組み込み先に使うBI製品の料金体系と機能差を比較できます。
• データ分析基盤の導入手順と期間｜工程・体制・外注の契約形態まで解説：分析用データストアを新設する場合の工程と体制がわかります。
• データ分析基盤の構築とは？5層アーキテクチャとBigQuery実装手順を技術視点で解説：集計テーブルを置く基盤側の実装手順を扱っています。
• Apache Supersetとは？構成・Docker導入手順とMetabase比較で採用判断を解説【2026年版】：OSSで自前ホストする場合の構成と導入手順をまとめています。
• Looker Studioとは｜無料BIツールの機能・料金・BigQuery連携と企業導入の判断【2026年最新】：無料枠で検証を始める際の機能範囲と限界を把握できます。