Power BI Embedded: アプリケーションへの分析の追加

すべての SaaS アプリケーションは最終的に分析を必要とします。ユーザーは、使用パターン、パフォーマンス指標、ビジネス成果を示すダッシュボードを望んでいます。カスタム分析レイヤーをゼロから構築するには (チャート ライブラリ、データ パイプライン、キャッシュ、エクスポート機能、ドリルダウン インタラクションなど)、エンジニアリング作業と継続的なメンテナンスに 6 ～ 12 か月かかります。 Power BI Embedded は、Microsoft のインフラストラクチャによってサポートされる、アプリケーションに直接組み込まれたエンタープライズ グレードの分析機能という代替手段を提供します。

Power BI Embedded は、単に「ページに iframe を配置する」だけではありません。これは、独自のアプリケーションの UI 内でインタラクティブで安全なマルチテナント分析エクスペリエンスを提供するための完全なプラットフォームです。顧客は、Power BI の成熟した視覚化エンジン、DAX 計算レイヤー、データ接続インフラストラクチャを活用しながら、製品にネイティブなルック アンド フィールの分析を操作します。

このガイドでは、アプリケーションに Power BI を埋め込むためのアーキテクチャ、認証モデル、マルチテナント セキュリティ、キャパシティ プランニング、SDK 統合、および価格に関する考慮事項について説明します。埋め込み分析の実装を計画している場合は、アーキテクチャ ガイダンスと開発サポートについて Power BI 埋め込み分析サービス を参照してください。

重要なポイント

• Power BI Embedded は、「顧客向けの埋め込み」 (アプリがデータを所有) と「組織向けの埋め込み」 (ユーザーがデータを所有) の 2 つのシナリオをサポートします。
• マルチテナント SaaS アプリケーションにはサービス プリンシパル認証が推奨されます。マスター ユーザー アカウントはシンプルですが、単一障害点が発生します。
• 行レベルのセキュリティ (RLS) は、共有データセット内のテナント データの分離を確保するための主要なメカニズムです
• Fabric F SKU は、開発用の F2 から始まる、組み込みシナリオに最もコスト効率の高い容量を提供します
• JavaScript SDK により、フィルターの適用、イベントのキャプチャ、ナビゲーションの制御、テーマのカスタマイズなど、プログラムによる詳細な制御が可能になります。
• 容量のサイジングは、合計ユーザー数だけではなく、同時ユーザー、クエリの複雑さ、データ量によって決まります。
• カスタム テーマと隠しクロムにより、埋め込みレポートがアプリケーションにネイティブに感じられるようになります

---

埋め込みシナリオ: 顧客 vs 組織

顧客のために埋め込む (アプリがデータを所有)

「アプリがデータを所有する」シナリオは、SaaS アプリケーションの主な使用例です。アプリケーションは、サービス プリンシパルまたはマスター ユーザー アカウントを使用して Power BI で認証し、埋め込みトークンを生成して、埋め込みレポートをエンド ユーザーに提供します。顧客が Power BI と直接対話することはなく、Power BI ライセンスは必要ありません。

アーキテクチャ フロー:

1. 顧客は認証システムを使用してアプリケーションにログインします。
2. アプリケーション バックエンドは Power BI REST API を呼び出して、その顧客の特定のレポート、データセット、および RLS ロールをスコープとする埋め込みトークンを生成します。
3. バックエンドは、埋め込みトークンと埋め込み URL をフロントエンドに返します。
4. フロントエンドは、埋め込みトークンを使用して Power BI JavaScript SDK を初期化し、指定されたコンテナー要素にレポートを表示します。
5. 埋め込みトークンは構成可能な期間 (デフォルトは 1 時間) が経過すると期限切れになり、アプリケーションは透過的にトークンを更新します。

主な特徴:

• お客様は Power BI Pro または Premium Per User ライセンスを必要としません
• すべての容量コストは、ファブリック/組み込み SKU を通じてお客様 (アプリケーション プロバイダー) が負担します。
• RLS とプログラムによるフィルタリングを通じてユーザーに表示されるものを完全に制御できます
• 認証は完全にアプリケーションの認証システム内で行われます
• 埋め込みトークンは、特定のアーティファクトへの範囲指定された時間制限付きアクセスを提供します

これは、ISV、SaaS プラットフォーム、および内部ポータルで使用されるモデルであり、分析利用者は Power BI が基盤となるテクノロジであることを認識したり気にしたりする必要はありません。

組織に埋め込む (ユーザーがデータを所有)

"ユーザーがデータを所有する" シナリオは、ユーザーが既に Power BI ライセンス (Pro または PPU) を持っている内部アプリケーション内に Power BI コンテンツを埋め込むためのものです。埋め込みエクスペリエンスでは、ユーザー自身の Power BI ID とアクセス許可が使用されます。

アーキテクチャ フロー:

1. ユーザーはアプリケーションを通じて Azure AD で認証します。
2. アプリケーションは、OAuth 2.0 の代理フローを使用して、ユーザーに代わってアクセス トークンを取得します。
3. アプリケーションは、ユーザーのトークンを使用して Power BI REST API を呼び出し、埋め込み構成を取得します。
4. レポートは、ユーザーの完全な Power BI アクセス許可を使用して表示されます。

主な特徴:

• 各ユーザーは Power BI Pro または Premium Per User ライセンスを持っている必要があります
• ユーザーは、自身の Power BI アクセス許可と RLS 割り当てに基づいてコンテンツを表示します。
• 追加のファブリック/組み込み容量は必要ありません (ユーザーの Pro/PPU ライセンス割り当てを使用します)
• アプリケーション開発者の制御が減り、ユーザーの自主性が高まる
• アーキテクチャはシンプルですが、ユーザーごとのライセンスコストは高くなります

このモデルは通常、ユーザーがすでに Power BI ライセンスを持っており、既存のアクセス許可を保持する必要があるイントラネット ポータル、SharePoint 統合、および内部アプリケーションに使用されます。

シナリオの選択

外部顧客を対象とするほとんどの SaaS アプリケーションでは、「アプリがデータを所有する」が正しい選択です。このガイドの残りの部分では、主にこのシナリオに焦点を当てます。

---

認証: サービス プリンシパルとマスター ユーザー

サービス プリンシパルの認証

サービス プリンシパルは、プログラムでリソースにアクセスするために Power BI が信頼する Azure AD アプリケーション ID です。これは、運用組み込みアプリケーションに推奨される認証方法です。

セットアップ要件:

1. Azure AD にアプリケーションを登録します。
2. アプリケーションのクライアント シークレットまたは証明書を作成します。
3. Azure AD セキュリティ グループを作成し、それにサービス プリンシパルを追加します。
4. Power BI 管理ポータルで、[テナント設定] > [開発者設定] でセキュリティ グループのサービス プリンシパル アクセスを有効にします。
5. サービス プリンシパルに、埋め込みコンテンツを含む特定の Power BI ワークスペースへのアクセスを許可します。

利点:

• 特定のユーザー アカウントに依存しない (単一障害点を排除)
• サービスを中断することなく、クライアント シークレットと証明書をローテーションできます。
• サービス プリンシパルのスコープを特定のワークスペースに設定できます (最小権限)
• Azure でホストされるアプリケーションで Azure AD マネージド ID と連携します。
• 証明書ベースの認証をサポートし、セキュリティを強化します

制限事項:

• 「マイ ワークスペース」（個人用ワークスペース）にアクセスできません
• 特定の管理 API を呼び出すことができません
• 一部の高度な機能を使用するには Azure AD Premium が必要です
• 初期設定はマスターユーザーよりも複雑です

マスターユーザー認証

マスター ユーザーは、アプリケーションが Power BI で認証するために使用する Power BI Pro または PPU ライセンスを持つ通常の Azure AD ユーザー アカウントです。アプリケーションはこのユーザーとしてログインし、埋め込みトークンを生成します。

利点:

• より簡単な初期セットアップ (ユーザーの作成、ライセンスの割り当て、ワークスペースへのアクセスの許可)
• 管理 API を含むすべての Power BI 機能にアクセスできます
• Azure AD アプリケーションの登録は必要ありません

短所:

• 単一障害点: ユーザー アカウントがロックされている場合、パスワードの有効期限が切れている場合、または MFA がトリガーされた場合、アプリケーションは分析にアクセスできなくなります。
• 対話型サインインを必要とする条件付きアクセス ポリシーは使用できません
• パスワードのローテーションにはアプリケーションの更新が必要です
• マシンプロセスに人間のアカウントを使用しないというセキュリティのベストプラクティスに違反します。
• ユーザーアカウントのライセンス費用

推奨事項: すべての実稼働環境でサービス プリンシパル認証を使用します。マスター ユーザー アカウントは、信頼性よりもシンプルさが重要な概念実証および開発環境で使用できます。

トークンの生成と管理

認証方法に関係なく、アプリケーションは Power BI REST API を通じて埋め込みトークンを生成します。トークンは、埋め込みセッションの権限をカプセル化します。

埋め込みトークンに関する考慮事項:

• トークンの有効期間: デフォルトは 1 時間ですが、最大 24 時間まで構成可能です。有効期間が短いほど安全性は高くなりますが、より頻繁な更新が必要になります。
• トークンのスコープ: 各トークンのスコープは、特定のレポート、データセット、およびワークスペースに限定されます。可能な限り狭い範囲を生成します。
• RLS ID: 行レベルのセキュリティを使用する場合、RLS ID (ユーザー名とロール) がトークンに埋め込まれます。これは、テナントの分離を確保する方法です。
• トークンの更新: フロントエンドはトークンの有効期限を監視し、有効期限が切れる前に新しいトークンを要求する必要があります。 JavaScript SDK はこのためのイベントを提供します。

トークン生成フローの例:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken
{
    "datasets": [{"id": "dataset-guid"}],
    "reports": [{"id": "report-guid"}],
    "identities": [{
        "username": "[email protected]",
        "roles": ["TenantRole"],
        "datasets": ["dataset-guid"]
    }]
}

応答には、埋め込みトークンと有効期限のタイムスタンプが含まれます。バックエンドはこのトークンを (有効期限を考慮して) キャッシュし、認証されたフロントエンド リクエストに提供します。

---

マルチテナントの行レベルのセキュリティ

RLS が組み込みにとって重要な理由

マルチテナント SaaS アプリケーションでは、複数の顧客のデータが同じ Power BI データセットに存在することがよくあります。行レベルのセキュリティがなければ、埋め込みトークンによりデータセット内のすべてのデータへのアクセスが許可されます。 RLS では、基になるデータセットが共有されている場合でも、各顧客が自分のデータのみを参照できるようにします。

RLS は、マルチテナントの組み込みシナリオではオプションではありません。テナントの分離に失敗するとデータ侵害となります。 RLS は後付けではなく、基本的なセキュリティ制御として設計します。

静的 RLS

静的 RLS は、Power BI Desktop の DAX 式を使用して固定フィルター ルールを定義します。各ロールには、表示される行を制限する一連のテーブル フィルターがあります。

例:

Customers テーブル上のこのフィルターを含む「TenantRole」:

[TenantId] = USERNAME()

埋め込みトークンを生成するとき、アプリケーションは USERNAME() 値を現在のテナントの識別子に設定します。 DAX フィルターは、すべてのクエリを TenantId が一致する行に制限します。

静的 RLS はシンプルで、直接的なテナント分離に効果的です。次の場合にうまく機能します。

• テナントの分離は、関係を通じて伝播する単一の列 (TenantId) に基づいています。
• すべてのテナントに、データにフィルタリングされた同じレポート構造が表示されます。
• RLS ロールの数は少なく、安定しています

動的 RLS

動的 RLS は、ユーザーの ID に基づいてクエリ時に評価される DAX 式を使用します。これにより、テナントごとに個別のロールを作成することなく、より複雑なセキュリティ シナリオが可能になります。

一般的な動的 RLS パターン:

USERPRINCIPALNAME() パターン:

[Email] = USERPRINCIPALNAME()

埋め込みトークンは、有効な ID のユーザー名をユーザーの電子メールに設定します。フィルタは、セキュリティ マッピング テーブルの電子メール列と照合します。

セキュリティ テーブル パターン: ユーザーをアクセスできるデータにマッピングする専用のセキュリティ テーブルを作成します。

リレーションシップを通じてこのセキュリティ テーブルをファクト テーブルに結合する RLS フィルターを適用します。このパターンは、テナント レベルの分離だけでなく、テナント内のユーザー レベルのアクセス許可をサポートします。

RLS のテストと検証

展開前テスト:

1. Power BI Desktop で、[表示形式] を使用して、サンプル ユーザー名を使用して各 RLS ロールをテストします。
2. テーブル間のクロスフィルタリングが RLS 境界を尊重していることを確認します。
3. エッジ ケースをテストします。一致する行がないユーザー (エラーではなく空のレポートが表示されるはずです)、複数のロールを持つユーザー、およびフィルター列の NULL 値。
4. ALL() または REMOVEFILTERS() を使用した DAX 測定が RLS をバイパスしていないことを確認します (バイパスすべきではありませんが、確認してください)。

製品検証:

• 導入パイプラインの一部として RLS テストを自動化します
• テナント ID をテストするための埋め込みトークンを生成し、クエリ結果が予想されるデータと一致することを確認します
• 容量メトリクスでの RLS バイパス試行を監視します (異常なクエリ パターン、予期しないデータ量)
• RLS 構成のセキュリティ レビューを四半期ごとに実施します。

---

容量サイジングとファブリック SKU

容量を理解する

Power BI Embedded には専用の容量、つまり埋め込みワークロード用に予約されたコンピューティング リソースが必要です。キャパシティはキャパシティ ユニット (CU) で測定され、レポートのレンダリング、クエリの実行、データセットの更新に使用できる処理能力を決定します。

容量はユーザーごとではありません。これは、すべての組み込みセッションが利用するコンピューティングの共有プールです。つまり、価格は総ユーザー数ではなく、同時実行性とクエリの複雑さに応じて決まります。

ファブリック F SKU オプション

Microsoft Fabric F SKU は、Power BI Embedded 容量の現在の価格モデルです。従来の A SKU を、より柔軟で一時停止可能なモデルに置き換えました。

重要な注意事項:

• 同時ユーザー数は合計ユーザー数を意味するものではありません。これは、ユーザーが同時にアクティブにクエリを実行していることを意味します。一般的な割合は、常に全ユーザーの 5 ～ 10% が同時接続です。
• これらはおおよその目安の数値です。実際の容量は、クエリの複雑さ、モデルのサイズ、レポートごとの視覚化数に大きく依存します。
• F SKU は、使用していないときは一時停止できます (従来の P SKU とは異なります)。これは、開発や季節的なワークロードにとって価値があります。
• F64 以降には、追加のライセンス費用なしで Power BI Premium 機能 (ページ分割されたレポート、AI、展開パイプライン) が含まれています。

容量サイジングの方法論

ステップ 1: 同時ユーザーを見積もります。

同時ユーザー = 合計ユーザー x ピーク同時実行率

営業時間中にアクセスされる SaaS 分析ダッシュボードの場合: 同時実行率は 5 ～ 10%。 1 日を通して頻繁にチェックされる運用ダッシュボードの場合: 同時実行率は 15 ～ 25%。 イベント駆動型ダッシュボード (リアルタイム監視、アラート) の場合: 30 ～ 50% の同時実行率。

ステップ 2: クエリの複雑さを評価します。

単純なレポート (5 ～ 10 個のビジュアル、基本的な集計、単一のファクト テーブル): 1x ベースライン。 中規模レポート (10 ～ 20 のビジュアル、タイム インテリジェンス、複数のファクト テーブル): ベースラインの 2 ～ 3 倍。 複雑なレポート (20 以上のビジュアル、複雑な DAX、大規模なデータセット、クロスソース クエリ): ベースラインの 4 ～ 6 倍。

ステップ 3: 必要な容量を計算します。

上の表からの同時ユーザーの見積もりと一致する SKU から始めます。複雑さの係数を掛けます。結果が SKU の同時クエリ容量を超える場合は、次の層に移動します。

ステップ 4: 負荷テストで検証します。

理論的なサイジングが出発点です。運用を開始する前に、現実的なデータ量、クエリ パターン、同時実行レベルで負荷テストを実施します。 Microsoft は、この目的のために Power BI Embedded 容量負荷テスト ツールを提供しています。

ステップ 5: 成長の計画を立てる。

今後 6 ～ 12 か月間の成長に対応できるよう、現在のピークより 30 ～ 50% の余裕を追加します。 F SKU はダウンタイムなしでアップグレードできるため、段階的に適切なサイズに調整できます。

コスト最適化戦略

• 業務時間外は開発能力を一時停止します。 F SKU はアクティブなときは秒単位で課金され、一時停止しているときは無料です。 Azure Automation または Logic Apps を使用して一時停止/再開を自動化すると、開発コストを 60 ～ 70% 削減できます。

• 容量を拡張する前に モデルを最適化します。 F8 で適切に最適化されたモデルは、F32 で適切に最適化されていないモデルよりもパフォーマンスが優れていることがよくあります。パフォーマンスの問題にコンピューティングを投入する前に、モデルの最適化に投資してください。

• 大規模なデータセットには集計テーブルを使用します。一般的な粒度 (日次、週次、月次) でデータを事前に集計すると、詳細のドリルダウン機能を維持しながら、概要レベルのビジュアルのクエリ処理が 80 ～ 90% 削減されます。

• Power BI REST API を介してレポート レベルのキャッシュを実装します。データ更新の頻度が低いダッシュボードの場合、キャッシュされた結果によってユーザー セッションごとの容量消費が削減されます。

• さまざまなワークロードに対して個別の容量を検討してください。更新操作を対話型クエリから分離することで、更新のスパイクによるユーザー エクスペリエンスの低下を防ぎます。これは、営業時間中に更新される大規模なデータセットがある場合に特に重要です。

---

JavaScript SDK の統合

基本的な埋め込み

Power BI JavaScript SDK (powerbi-client) は、Web アプリケーションに Power BI コンテンツを埋め込んで制御するためのプログラム インターフェイスを提供します。

インストール:

npm install powerbi-client

基本的な埋め込みフロー:

import * as pbi from 'powerbi-client';

const powerbi = new pbi.service.Service(
    pbi.factories.hpmFactory,
    pbi.factories.wpmpFactory,
    pbi.factories.routerFactory
);

const embedConfig = {
    type: 'report',
    id: reportId,
    embedUrl: embedUrl,
    accessToken: embedToken,
    tokenType: pbi.models.TokenType.Embed,
    settings: {
        panes: {
            filters: { visible: false },
            pageNavigation: { visible: true }
        },
        background: pbi.models.BackgroundType.Transparent,
        layoutType: pbi.models.LayoutType.Custom,
        customLayout: {
            displayOption: pbi.models.DisplayOption.FitToWidth
        }
    }
};

const reportContainer = document.getElementById('report-container');
const report = powerbi.embed(reportContainer, embedConfig);

プログラムによる制御

SDK は、埋め込みレポートに対する広範なプログラム制御を公開します。

フィルターの適用:

const filter = {
    $schema: "http://powerbi.com/product/schema#basic",
    target: {
        table: "Sales",
        column: "Region"
    },
    operator: "In",
    values: ["North", "South"],
    filterType: pbi.models.FilterType.BasicFilter
};

await report.setFilters([filter]);

イベントのキャプチャ:

report.on('loaded', function() {
    console.log('Report loaded successfully');
});

report.on('dataSelected', function(event) {
    const data = event.detail;
    // Handle user selection — navigate to detail page, update other UI, etc.
});

report.on('pageChanged', function(event) {
    const pageName = event.detail.newPage.displayName;
    // Track page navigation in your analytics
});

トークンの更新:

report.on('tokenExpired', async function() {
    const newToken = await fetchNewEmbedToken();
    await report.setAccessToken(newToken);
});

ナビゲーション制御:

// Navigate to a specific page
const pages = await report.getPages();
const targetPage = pages.find(p => p.displayName === 'Revenue Analysis');
await targetPage.setActive();

// Set a specific slicer value
const visuals = await targetPage.getVisuals();
const slicer = visuals.find(v => v.type === 'slicer');
await slicer.setSlicerState({
    filters: [{
        $schema: "http://powerbi.com/product/schema#basic",
        target: { table: "Date", column: "Year" },
        operator: "In",
        values: [2026],
        filterType: pbi.models.FilterType.BasicFilter
    }]
});

パフォーマンスのためのフェーズド レンダリング

多くのビジュアルを含む複雑なレポートの場合、段階的レンダリングにより、スクロールせずに見える範囲のコンテンツが最初にレンダリングされるため、知覚されるパフォーマンスが向上します。

const embedConfig = {
    // ... standard config
    settings: {
        // ... other settings
        commands: [{
            visualRendered: {
                phase: 1,
                visualNames: ['revenue-kpi', 'trend-chart', 'summary-table']
            }
        }]
    }
};

report.on('visualRendered', function(event) {
    if (event.detail.phase === 1) {
        // Hide loading spinner, show report
        document.getElementById('loading').style.display = 'none';
    }
});

---

カスタム テーマとブランディング

カスタムテーマが重要な理由

既定の Power BI ビジュアルでは、Microsoft のカラー パレットとスタイルが使用されます。埋め込みコンテキストでは、これによりアプリケーションとの視覚的な不一致が生じます。カスタム テーマは、埋め込まれた分析を製品の設計システムと連携させ、エクスペリエンスをボルトオンではなくネイティブに感じさせます。

テーマの JSON 構造

Power BI テーマは、色、フォント、視覚的な既定値、要素のスタイルを制御できる JSON ファイルとして定義されます。

{
    "name": "MyApp Theme",
    "dataColors": [
        "#2563EB", "#7C3AED", "#059669", "#D97706",
        "#DC2626", "#0891B2", "#4F46E5", "#65A30D"
    ],
    "background": "#FFFFFF",
    "foreground": "#1E293B",
    "tableAccent": "#2563EB",
    "textClasses": {
        "callout": {
            "fontSize": 28,
            "fontFace": "Inter, sans-serif",
            "color": "#0F172A"
        },
        "title": {
            "fontSize": 14,
            "fontFace": "Inter, sans-serif",
            "color": "#1E293B"
        },
        "header": {
            "fontSize": 12,
            "fontFace": "Inter, sans-serif",
            "color": "#475569"
        },
        "label": {
            "fontSize": 11,
            "fontFace": "Inter, sans-serif",
            "color": "#64748B"
        }
    },
    "visualStyles": {
        "*": {
            "*": {
                "border": [{
                    "color": {"solid": {"color": "#E2E8F0"}},
                    "radius": 8
                }],
                "background": [{
                    "color": {"solid": {"color": "#FFFFFF"}},
                    "transparency": 0
                }]
            }
        }
    }
}

プログラムによるテーマの適用

テーマは、埋め込み時に適用することも、動的に切り替えることもできます (ダーク モードのサポートに役立ちます)。

// Apply theme at embed time
const embedConfig = {
    // ... standard config
    theme: { themeJson: customThemeJson }
};

// Switch theme dynamically (e.g., light/dark mode toggle)
await report.applyTheme({ themeJson: darkThemeJson });

Power BI Chrome を非表示にする

完全にネイティブな外観にするには、Power BI の組み込み UI 要素を非表示にし、独自のアプリケーション コントロールに置き換えます。

const settings = {
    panes: {
        filters: { visible: false },      // Hide filter pane
        pageNavigation: { visible: false } // Hide page tabs
    },
    bars: {
        actionBar: { visible: false },     // Hide action bar
        statusBar: { visible: false }      // Hide status bar
    },
    background: pbi.models.BackgroundType.Transparent,
    visualRenderedEvents: true
};

次に、アプリケーションの UI フレームワークでカスタム ナビゲーション、フィルタリング、およびエクスポート コントロールを構築します。 JavaScript SDK を使用して、ユーザーがカスタム コントロールを操作するときにプログラムでフィルターを適用し、ページを変更し、エクスポートをトリガーします。

このアプローチでは、より多くの開発労力が必要になりますが、ユーザーがアプリケーションのネイティブ機能と埋め込まれた Power BI コンテンツを区別できないシームレスなエクスペリエンスが得られます。

---

組み込み向けのパフォーマンスの最適化

フロントエンドのパフォーマンス

• SD​​K を遅延読み込みします。 Power BI JavaScript SDK は約 300 KB です。ユーザーが分析ページに移動したときのみ、非同期的にロードします。
• 埋め込みトークンをプリロードします。 ユーザーがレポートを要求する前に埋め込みトークンを生成します。ユーザーが (ナビゲーション パターンに基づいて) 分析を表示する可能性が高いことがアプリケーションでわかっている場合は、ページ遷移中にトークンをプリロードします。
• ブートストラップ埋め込みを使用します。 SDK は、埋め込みトークンが使用可能になる前に iframe を初期化するブートストラップ パターンをサポートし、体感的な読み込み時間を 200 ～ 500 ミリ秒短縮します。

// Bootstrap first (fast — creates iframe immediately)
const report = powerbi.bootstrap(container, { type: 'report' });

// Load later when token is available
const embedConfig = { /* full config */ };
report.load(embedConfig);

• レポート キャッシュを実装します。 レポートが読み込まれると、iframe はそれをメモリに保持します。ユーザーが移動して戻ってきた場合は、再埋め込む代わりに既存の iframe を再利用します。これにより、同じセッション内での再訪問のロード時間が完全に排除されます。

バックエンドのパフォーマンス

• 埋め込みトークンをキャッシュします。 埋め込みトークンは、その存続期間全体にわたって有効です (デフォルトは 1 時間)。それらを Redis またはメモリ内にキャッシュし、同じレポートと ID の組み合わせに対するリクエスト間で再利用します。
• バッチ トークンの生成。 ユーザーのダッシュボードに複数の埋め込みレポートが含まれている場合は、GenerateToken エンドポイントのマルチリソース機能を使用して、単一の API 呼び出しですべての埋め込みトークンを生成します。
• API レート制限を監視します。 Power BI REST API には、サービス プリンシパルごとのレート制限があります。 429 応答を監視し、指数バックオフを実装します。大規模なアプリケーションの場合は、複数のサービス プリンシパルに負荷を分散します。

組み込み用のレポート設計

埋め込みで使用するために設計されたレポートは、視覚的な複雑さよりもパフォーマンスを優先する必要があります。

• ビジュアルをページごとに 8 ～ 12 に制限します (ビジュアルごとに個別のクエリが生成されます)
• 可能な場合は、DirectQuery ではなくインポート モードを使用します (10 ～ 100 倍高速)
• 適切な粒度でデータを事前に集計する
• ランディング ページでの複雑な DAX メジャーを回避します (ドリルスルーの詳細のために保存します)。
• 動的計算ではなく、事前に計算されたビューにブックマークを使用します。
• シングルユーザーだけでなく、予想される同時実行レベルでレポートの読み込み時間をテストします

ECOSIRE は、組み込み分析を実装する組織向けに、初日から最適なパフォーマンスを保証する アーキテクチャ コンサルティングおよび開発サービス を提供します。

---

組み込みのセキュリティに関する考慮事項

トークンのセキュリティ

埋め込みトークンは、Power BI コンテンツへのアクセスを許可します。これらを機密の資格情報として扱います。

• クライアント側のソース コードまたは URL パラメータで埋め込みトークンを公開しないでください
• サーバー側でトークンを生成し、認証された API エンドポイントを通じて配信します
• 実用的な最短のトークン有効期間を使用します (ほとんどのアプリケーションではデフォルトの 1 時間が妥当です)
• 有効期間の長いトークンを生成するのではなく、トークン更新ロジックを実装します。
• トークン生成パターンの異常（異常な量、予期しないレポート ID）を監視します。

テナント分離の検証

マルチテナント アプリケーションの場合は、テナントの分離を継続的に検証します。

• テナント A の埋め込みトークンを生成し、テナント B のデータにアクセスできないことを確認する自動テスト
• テナント間のデータアクセス試行を検出するためのクエリロギング
• 定期的な RLS 構成監査 (RLS ロールは Power BI Desktop で変更され、誤って弱くなる可能性があります)
• RLS フィルター エラーに関するアラート (構成ミスを示す可能性があります)

ネットワークセキュリティ

• Azure AD 条件付きアクセスを使用して Power BI REST API アクセスを既知の IP 範囲に制限する
• オンプレミス データ ソースへのゲートウェイ接続にプライベート エンドポイントを使用する
• Power BI 管理ポータルで監査ログを有効にして、すべての API 呼び出しを追跡し、トークン生成を埋め込む
• Content Security Policy ヘッダーを実装して、iframe の埋め込みをアプリケーションのドメインに制限します

---

よくある質問

ユーザーが 10,000 人の SaaS アプリケーションの Power BI Embedded のコストはいくらですか?

コストは、総ユーザー数ではなく、同時ユーザー数によって決まります。 10,000 ユーザーの 5% がピーク時に同時接続する場合 (同時ユーザー 500 人)、月額約 8,200 ドル (従量課金制) で約 F32 の容量が必要になります。予約 (1 年間の契約) を使用すると、月額約 5,500 ドルに下がります。実際のコストは、レポートの複雑さ、データセットのサイズ、使用パターンに応じて高くなったり低くなったりする可能性があります。パイロットとして F8 から開始し、現実的な同時実行で負荷テストを行い、実際の測定に基づいてスケールします。

Azure なしで Power BI Embedded を使用できますか?

Power BI Embedded には、認証用の Azure AD と、Azure を通じてプロビジョニングされたファブリック/埋め込み容量が必要です。アプリケーション自体はどこでも (AWS、GCP、オンプレミス) ホストできますが、Power BI リソースは Azure に存在する必要があります。サービス プリンシパルまたはマスター ユーザー アカウントは Azure AD 内に存在する必要があり、容量は Azure リソースである必要があります。既存の Azure フットプリントがない組織の場合、このセットアップにより、約 2 ～ 4 時間の Azure 構成作業と、キャパシティ自体を超える最小限の継続的な Azure 管理が追加されます。

Power BI Embedded A SKU、EM SKU、および Fabric F SKU の違いは何ですか?

A SKU は、Azure を通じてプロビジョニングされた元の Power BI Embedded 容量でした。 EM SKU は、Office 365 を内部に組み込むためのライセンス オプションでした。どちらも、すべての Power BI および Fabric ワークロードに統合された容量モデルを提供する Fabric F SKU に置き換えられました。 F SKU は、秒単位の請求、一時停止/再開機能、およびよりシンプルな料金体系を提供します。新しい実装の場合は、F SKU のみを使用してください。既存の A SKU のお客様は、価格と機能を向上させるために F SKU への移行を計画する必要があります。

ユーザーは埋め込みレポートからデータをエクスポートできますか?

はい、ただしこれは埋め込み設定を通じて制御します。 JavaScript SDK を使用すると、レポートごとにエクスポート機能 (Excel、PDF、PowerPoint へのエクスポート) を有効または無効にすることができます。また、エクスポート API を使用してカスタム エクスポート機能を実装することもできます。これにより、形式、適用されるフィルター、監査ログをより詳細に制御できるようになります。機密データの場合は、組み込みのエクスポートを無効にし、追加の承認チェックと透かしを適用する独自のエクスポート メカニズムを提供します。

埋め込みシナリオでレポート開発を処理するにはどうすればよいですか?

レポート開発は標準の Power BI ワークフローに従います。つまり、Power BI Desktop でレポートを作成し、開発ワークスペースに発行し、サンプル埋め込みトークンを使用してテストし、展開パイプラインを通じて運用環境に昇格します。主な違いは、埋め込みレポートでは、RLS の動作、同時実行時のパフォーマンス、画面サイズ全体の応答性の高いレイアウト、およびアプリケーションの UI との対話について追加のテストが必要であることです。すべてのレポート展開の一部として、自動化された RLS 検証とパフォーマンス回帰テストを含む CI/CD パイプラインを確立します。