クラウドサービス

Power BI Embedded

自社アプリやポータルに Power BI のレポートやダッシュボードを埋め込んで提供できる。専用キャパシティで課金され、AWS の Amazon Quick Sight 埋め込みに相当する位置づけのサービス。

中級コスト最適化運用上の優秀性パフォーマンス効率
最終更新: 2026-07-29公式ドキュメント
3つの要点
TL;DR
  1. Power BI のレポート/ダッシュボードを自社アプリへ埋め込んで配信する PaaS。
  2. 外部向けは閲覧者ライセンスなしで、A SKU または Fabric F SKU の容量から配信する。
  3. AWS の Amazon Quick Sight の埋め込み分析に相当する位置づけのサービス。

解決する課題

SaaS や社内ポータルに高品質な BI を組み込みたいとき、BI 機能を自前で開発するのは大きな負担です。一方で閲覧者全員に BI 製品のユーザーライセンスを配るのは、外部顧客向けアプリでは現実的ではありません。Power BI Embedded は、Power BI で作ったレポートやダッシュボードを API とキャパシティ課金で自社アプリに埋め込むことで、この溝を埋めます。

  • 自社の Web アプリや SaaS に 対話的なレポート・ダッシュボードを組み込んで 提供したい
  • 外部顧客や匿名ユーザーに見せたいが、閲覧者ごとに BI ライセンスを配りたくない
  • 可視化機能を一から作らず、Power BI の作図・分析機能をそのまま流用 したい
  • 利用量に応じて キャパシティを増減させ、コストを利用規模に合わせたい

主要概念と用語

  • 埋め込み(Embedding): 自社アプリの画面内に Power BI のレポート/ダッシュボード/タイルを iframe 的に表示すること
  • キャパシティ(A / F SKU): Power BI Embedded の A SKU、または Microsoft Fabric の F SKU で確保する計算リソース。用途と必要な Fabric 機能に応じて選ぶ
  • ワークスペース(Workspace): レポートやデータセットを束ねる入れ物。埋め込み対象はワークスペース内のコンテンツとして管理する
  • 埋め込みトークン(Embed Token): アプリのバックエンドが発行する短命のトークン。フロントエンドはこれを使ってコンテンツを表示する
  • App owns data(アプリがデータを所有): 閲覧者は Power BI のアカウントを持たず、アプリ側のサービス プリンシパルで認証する主要シナリオ
  • User owns data(ユーザーがデータを所有): 組織内ユーザーが自分の Power BI ライセンスでサインインして見る、社内向けのシナリオ
  • Row-Level Security(RLS): 行レベルでデータ表示を絞る仕組み。埋め込みトークン発行時にロールやユーザー情報を渡して、テナントごとの出し分けを実現する
  • Power BI REST API / Embedded Analytics SDK: トークン発行やコンテンツ取得を行う API と、フロントエンドで描画する JavaScript ライブラリ

仕様・制限・クォータ

  • 埋め込みのシナリオは大きく2つ。外部公開向けの「App owns data(サービス プリンシパルで認証)」と、社内向けの「User owns data(組織ユーザーがサインイン)」がある
  • キャパシティ SKU で性能と上限が決まる。上位 SKU ほど同時レンダリング数や扱えるモデルサイズの余裕が増える
  • キャパシティは開始・一時停止ができる。停止中は計算課金が止まるため、稼働時間で費用を制御できる
  • Power BI Premium の P1〜P5 は新規販売を終了し、各契約期間の終了時に廃止される。Power BI Embedded の A SKU、Power BI Pro、Premium Per User はこの P SKU 廃止とは別であり、新規の容量は Fabric F SKU も比較する
  • 組織内向けの User owns data では、F64 以上なら Fabric 無料ライセンスの閲覧者へ配信できる。F64 未満では閲覧者ごとに Pro または Premium Per User が必要で、外部向け App owns data のライセンス設計と混同しない
  • 埋め込みトークンは短命で、有効期限内のみ有効。失効時はバックエンドで再発行する
  • RLS による出し分け に対応し、マルチテナント SaaS で顧客ごとにデータを分離できる
  • 同時利用数・レンダリング負荷・モデルサイズなどの上限は SKU により異なる。具体的な数値は SKU や時期で変動し得るため、最新のドキュメントで確認する

内部の仕組み

横にスクロール

Power BI Embeddedでバックエンドが埋め込みトークンを発行し、RLSを適用してブラウザーにレポートを描画する信頼境界
特権資格情報はバックエンドに閉じ、ブラウザーには短命な埋め込みトークンだけを渡します。外部向け配信ではRLSとA/F容量の負荷を併せて監視します。

Power BI Embedded は、Power BI サービス本体(作図・データモデル・レンダリング)に、埋め込み専用のキャパシティトークンベースの認証フローを組み合わせたものとして動きます。レポートの作成や更新は通常の Power BI と同じ仕組みを使い、表示だけを自社アプリ側に持ち込む形です。

  • レポートやデータセットは ワークスペース に置き、埋め込み対象として参照する
  • アプリのバックエンドが サービス プリンシパル(または専用ユーザー)でサービスに認証 し、REST API を呼んで対象コンテンツの 埋め込みトークン を発行する
  • フロントエンドは JavaScript SDK にトークンと埋め込み URL を渡し、ユーザーのブラウザー内に レポートを描画 する
  • 実際の計算(クエリ実行・集計・レンダリング)は割り当てた A SKU または Fabric F SKU の容量で行われ、SKU の大きさが同時処理能力の上限を決める
  • マルチテナントでは、トークン発行時に RLS のロールやユーザー情報を埋め込み、同じレポートでも閲覧者ごとに見えるデータを絞る
トークンはバックエンドで発行する

埋め込みトークンの発行には特権が伴うため、必ずアプリのバックエンドで行い、フロントエンドには短命トークンだけを渡します。サービス プリンシパルの資格情報をブラウザー側に置かないことが、安全な埋め込みの基本です。

設計パターン / ベストプラクティス

  • 外部顧客向けには App owns data + サービス プリンシパル を基本とし、閲覧者に Power BI ライセンスを要求しない構成にする
  • マルチテナント SaaS では RLS を使い、テナントごとのデータ分離をトークン発行ロジックに集約する
  • キャパシティは 利用時間帯に合わせて開始・一時停止 し、夜間や週末に使わない検証環境のコストを抑える
  • トークンは 短い有効期限 にし、バックエンドで失効時の再発行を実装して、長命な資格情報を持ち回らない
  • レポートの作成・編集は通常の Power BI(Pro 等)で行い、埋め込みは配信専用 と役割を分けて運用する

運用・監視

  • キャパシティのメトリクス(CPU / メモリ使用率) を監視し、上限に張り付くようなら SKU の見直しやクエリ最適化を検討する
  • 専用の キャパシティ メトリクス アプリ で、レンダリングや更新の負荷、過負荷時の挙動(スロットリング)を把握する
  • キャパシティの 開始・一時停止のスケジュール を組み、稼働時間を業務時間に合わせてコストと性能のバランスを取る
  • データセットの スケジュール更新 が時間内に終わっているかを確認し、遅延が続くならモデルや更新方式を見直す
  • 監視ログを Azure Monitor / Log Analytics に集約し、トークン発行エラーや表示失敗を追えるようにする

コスト

外部向けの App owns data では、課金は主に 割り当てた A SKU または Fabric F SKU の容量に基づきます。閲覧者ごとの Power BI ライセンスを要求しないため、利用者が多いシナリオでは容量負荷から費用を見積もります。停止可否や課金の細部は選んだ容量で確認します。

コスト要因増減の方向最適化の勘所
キャパシティ SKU上位 SKU ほど性能も時間あたり費用も上がる負荷メトリクスを見て必要十分な SKU に収める
稼働時間開始している間だけ課金される使わない時間帯は一時停止しスケジュールで制御する
閲覧者数閲覧者が増えてもライセンス課金は増えない外部公開ではユーザー単位より予測しやすい

セキュリティ

  • 埋め込みトークンの発行は サービス プリンシパル(Microsoft Entra ID) で認証し、資格情報はバックエンドに閉じ込める
  • 閲覧者ごとのデータ分離は Row-Level Security(RLS) で行い、トークン発行時にロールやユーザー情報を渡す
  • トークンは 短命 にして、漏洩時の影響範囲を時間で限定する
  • 操作権限は Azure RBAC とワークスペースのロール で制御し、レポート編集と配信の権限を分離する
  • 保存・転送中のデータは暗号化され、データソース側のアクセス制御と組み合わせて多層で保護する
サービス プリンシパルの資格情報をフロントに出さない

サービス プリンシパルのシークレットや管理者トークンをブラウザー側に渡すと、誰でもコンテンツを取得できてしまいます。フロントには有効期限の短い埋め込みトークンだけを渡し、特権資格情報はバックエンドに限定してください。

関連サービス・比較

同じ Power BI でも、社内ユーザーが自分のアカウントで使う「Power BI サービス(Pro / Premium ユーザー)」と、自社アプリに埋め込んで外部にも配信する「Power BI Embedded」では位置づけが異なります。閲覧者にライセンスを求めるか、キャパシティで課金するかが主な分岐点です。

観点Power BI EmbeddedPower BI サービス(Pro)
主な用途自社アプリ/外部向けの埋め込み配信組織内ユーザーの BI 利用
閲覧者のライセンス閲覧者個別のライセンス不要閲覧者にもライセンスが必要
課金単位A または F 容量ユーザー単位の月額
主な認証サービス プリンシパル(App owns data)ユーザーのサインイン
想定読者外部顧客・匿名ユーザーも対象主に組織内ユーザー
相当するAWSAmazon Quick Sight の埋め込みAmazon Quick Sight の利用者

ハンズオン / CLI例

# リソースグループを作成
az group create --name demo-rg --location japaneast

# Power BI Embedded キャパシティ(Aシリーズ)を作成
az powerbi embedded-capacity create \
  --resource-group demo-rg \
  --name demopbicapacity \
  --location japaneast \
  --sku-name A1 \
  --sku-tier PBIE_Azure \
  --administration-members admin@contoso.com

# キャパシティの状態を確認
az powerbi embedded-capacity show \
  --resource-group demo-rg \
  --name demopbicapacity

# Azure CLI の専用コマンドには一時停止操作がないため、ARM REST API を呼ぶ
az rest --method post \
  --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/demo-rg/providers/Microsoft.PowerBIDedicated/capacities/demopbicapacity/suspend?api-version=2021-01-01"

# 利用を再開する
az rest --method post \
  --url "https://management.azure.com/subscriptions/<subscription-id>/resourceGroups/demo-rg/providers/Microsoft.PowerBIDedicated/capacities/demopbicapacity/resume?api-version=2021-01-01"

Azure Service

Power BI Embeddedを実務で読む

TL;DRは入口です。実際に選ぶ・使う段階では、何を解決するか、何と比較するか、導入後にどこで詰まるかまで見る必要があります。

解決すること

分析

比較で見る軸

クラウド: Azure / カテゴリ: 分析 / 難易度: intermediate

導入後に効く点

外部向けは閲覧者ライセンスなしで、A SKU または Fabric F SKU の容量から配信する。

先に潰すリスク

サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。

数字・仕様の読み方
クラウド
Azure
カテゴリ
分析
難易度
intermediate
関連資格
設計柱
cost / operational / performance

判断チェックリスト

  • 自社の用途が「分析 / cost」に近いか確認する。
  • 強みである「Power BI のレポート/ダッシュボードを自社アプリへ埋め込んで配信する PaaS。」が本当に評価軸になるか確認する。
  • 注意点の「サービス単体ではなく、権限、ネットワーク、監視、課金、バックアップを含めて設計する必要がある。」を運用で吸収できるか確認する。
  • 公開値や仕様値は、対象プラン・対象機種・対象リージョンまで確認する。
  • 既存システム、ID、ネットワーク、監視、バックアップとの接続方法を先に洗い出す。
  • 小さく試してから、本番移行、権限設計、障害時手順、コスト監視を決める。

次に確認する観点

分析costoperationalperformance