Power BI Embedded

解決する課題

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

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

主要概念と用語

• 埋め込み（Embedding）: 自社アプリの画面内に Power BI のレポート/ダッシュボード/タイルを iframe 的に表示すること
• キャパシティ（Aシリーズ SKU）: 埋め込み専用に確保する計算リソース。A1、A2 のように容量で段階があり、これを基準に課金される
• ワークスペース（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 ほど同時レンダリング数や扱えるモデルサイズの余裕が増える
• キャパシティは開始・一時停止ができる。停止中は計算課金が止まるため、稼働時間で費用を制御できる
• 埋め込みトークンは短命で、有効期限内のみ有効。失効時はバックエンドで再発行する
• RLS による出し分け に対応し、マルチテナント SaaS で顧客ごとにデータを分離できる
• 同時利用数・レンダリング負荷・モデルサイズなどの上限は SKU により異なる。具体的な数値は SKU や時期で変動し得るため、最新のドキュメントで確認する

内部の仕組み

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

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

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

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

運用・監視

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

コスト

課金は主に 割り当てた Aシリーズ キャパシティの SKU と稼働時間 に基づきます。閲覧者の人数では課金されないため、外部公開のように閲覧者が多いシナリオでは、ユーザー単位ライセンスより費用を予測しやすいのが特徴です。一時停止中は計算課金が止まる点を活かすと、さらに最適化できます。

セキュリティ

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

関連サービス・比較

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

ハンズオン / 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

# 使わない時間帯はキャパシティを一時停止して課金を止める
az powerbi embedded-capacity update \
  --resource-group demo-rg \
  --name demopbicapacity \
  --state Paused