次の方法で共有


Power BI でのページの自動更新

適用対象: Power BI Desktop Power BI サービス

重要なイベントを監視する場合、ソース データが更新された場合にすぐにデータが更新されるようにする必要があります。 たとえば、製造業では、機械が誤動作している場合、または誤動作に近い状態の場合に把握できる必要があります。 ソーシャル メディア センチメントのような信号を監視している場合は、突然の変化が発生したらすぐに知る必要があります。

Power BI のページの自動更新を使用すると、アクティブなレポート ページから、定義した間隔で DirectQuery ソースの新しいデータのクエリを実行することができます。 さらに、[ページの自動更新] では、プロキシ モデルもサポートされています。

更新の種類

ページの自動更新を使用する場合は、固定間隔と変更の検出の 2 種類の更新を使用できます。

固定間隔

この更新の種類では、1 秒または 5 分などの一定の間隔に基づいて、レポート ページ内のすべてのビジュアルを更新できます。 その特定の間隔に達すると、そのページ内のすべてのビジュアルから更新クエリがデータ ソースに送信され、それに応じて更新されます。

変更検出

この更新の種類を使用すると、特定の更新間隔ではなく、データの変更の検出に基づいて、ページ上のビジュアルを更新できます。 具体的には、このメジャーによって DirectQuery ソースへの変更がポーリングされます。 メジャーを定義するだけでなく、Power BI Desktop が変更を確認する頻度も選択する必要があります。 サービスに発行する場合、この更新の種類は、Premium 容量の一部であるワークスペースでのみサポートされます。 Analysis Services や Power BI セマンティック モデルなどの LiveConnect ソースはサポートされていません。

Power BI Desktop でページの自動更新を使用してレポートを作成する

ページの自動更新は、DirectQuery ソースおよび一部の LiveConnect シナリオで使用できるため、サポートされているデータ ソースに接続している場合にのみ使用できます。 この制限は、ページの自動更新の両方の種類に適用されます。

Power BI Desktop でページの自動更新を使用するには、ページの自動更新を有効にするレポート ページを選択します。 [視覚化] ペインで [書式] ボタン (ペイント ローラー) を選択し、ペインの下部付近にある [ページの更新] セクションを見つけます。

[ページの更新] の場所

  1. ページの更新をオンまたはオフにします。
  2. 更新の種類
  3. 入力と情報 (更新の種類によって異なります)

[ページの更新] カードは、DirectQuery ソースに接続している場合にのみ使用できます。 ページの自動更新を有効にするには、トグルが [オン] の位置にある必要があります。 必要な入力と提供する情報は、選択した更新の種類によって異なります。

固定間隔の設定

更新の種類として [ページの自動更新] を選択した場合は、必要な更新間隔を指定する必要があります。 既定値は 30 分です。 (最小更新間隔は 1 秒です)。設定した間隔でレポートの更新が開始されます。

管理者であり、更新間隔を変更する必要がある場合は、「Premium 容量でワークロードを構成する」を参照してください。

[詳細の表示] をクリックすると、Power BI により次の情報が提供されます。

  • 機能が管理者によって有効にされているかどうか (Power BI アカウントにログインしている場合のみ)。
  • 管理者によって許可された最小間隔 (Power BI アカウントにログインしている場合のみ)。
  • 実際の更新頻度 (通常は選択した間隔より長い)。
  • 最終更新時刻。

詳細が表示されている [ページの更新]

変更の検出の設定

更新の種類として [変更の検出] を選択すると、[変更の検出の追加] へのリンクが表示されます。 リボンの [モデリング] タブから [変更の検出] ウィンドウにアクセスすることもできます。 次に、 [ページの更新] セクションの [変更の検出] アイコンをクリックします。 最後に、[値] ウェルの任意の値の横にあるドロップダウン矢印を右クリックまたは選択し、メメニューから [変更の検出] を選択します。

[変更の検出] カード

ウィンドウが開くと、[メジャーの種類] オプションが表示されます。ここで、既存のメジャーを選択したり、新しいものを作成したりできます。 既存のメジャーを選択する場合は、フィールドの一覧から目的のメジャーを選択するか、[Choose existing measure](既存のメジャーの選択) セクションにドラッグ アンド ドロップするだけで済みます。 新しいメジャーを作成するときに、[計算の選択] で count、count distinct、minimum、maximum、sum の中からメジャーを選択することができます。 たとえば、count distinct を使用して顧客 ID をカウントし、新しい顧客がリストに追加された場合にのみ更新することができます。 メジャーを選択したら、Power BI が変更を確認する頻度を定義する必要があります。 これは、Power BI によってメジャーが計算され、変更がポーリングされる間隔です。 [適用] をクリックすると、[変更の検出] アイコンが付いた新しいメジャーがフィールドの一覧に表示されます。

[変更の検出] ウィンドウ

次に、[ページの更新] セクションに戻ると、変更の検出に使用されているメジャーと、定義されている間隔の情報が参考のために表示されます。

詳細が表示された [変更の検出] カード

注意

1 つのモデルに対して許可される変更の検出メジャーは 1 つだけです。

更新間隔を決定する

ページの自動更新が有効な場合、Power BI Desktop からは常に DirectQuery ソースにクエリが送信されます。 クエリが送信された後、データが返される前に遅延があります。 そのため、更新間隔を短くするには、構成された間隔内でクエリからクエリ対象のデータが正常に返されることを確認する必要があります。 データが間隔内に返されない場合、視覚化の更新頻度は構成より少なくなります。

これらの考慮事項は、固定間隔と変更の検出の両方の更新の種類に適用されます。 主な違いは、変更の検出では、固定間隔でソースに戻るクエリは 1 つしかなく、変更の検出メジャーの値が変更された場合にのみ、ビジュアルの更新がトリガーされる点です。

ベスト プラクティスとして、更新間隔は、想定する新しいデータの到着率と一致する必要があります。

  • 新しいデータが 20 分ごとにソースに到着する場合、更新間隔を 20 分未満にすることはできません。
  • 新しいデータが毎秒到着する場合、間隔を 1 秒に設定します。

1 秒のような短い更新間隔の場合は、次のような要因を考慮します。

  • DirectQuery データ ソースの種類。
  • クエリによって生成される負荷。
  • 容量のデータセンターからレポート ビューアーまでの距離。

Power BI Desktop のパフォーマンス アナライザーと、固定間隔の更新の種類の [ページの更新] セクションにある [詳細の表示] メニューを使用して、戻り時間を推定できます。 パフォーマンス アナライザーを使用すると、各視覚化のクエリでソースからの結果を返すのに十分な時間があるかどうかを確認できます。 また、時間がかかっている場所を決定することもできます。 パフォーマンス アナライザーからの結果に基づいて、データ ソースを調整たり、レポートで他の視覚化やメジャーを試してみたりできます。

次の図は、パフォーマンス アナライザーの DirectQuery ソースの結果を示しています。

パフォーマンス アナライザーの結果

このデータ ソースの他の特性:

  • データは 2 秒間隔で到着します。
  • パフォーマンス アナライザーでは、最大クエリ + 表示時間が約 4.9 秒 (4,688 ミリ秒) と表示されます。
  • データ ソースは、1 秒あたり約 1,000 個の同時クエリを処理するように構成されています。
  • 約 10 人のユーザーが同時にレポートを表示すると想定しています。

これらの特性の結果、次の式のようになります。

  • 5 個ビジュアル x 10 人のユーザー = 約 50 個のクエリ

この計算の結果では、データ ソースでサポートできるより高い負荷であることが示されています。 データは 2 秒の速度で到着するため、これを更新頻度にする必要があります。 ただし、クエリが完了するまでに約 5 秒かかるため、5 秒を超える値に設定する必要があります。

また、この結果は、レポートをサービスに発行すると異なる場合があることにも注意してください。 この違いが発生するのは、クラウドでホストされている Azure Analysis Services インスタンスがレポートで使用されるためです。 必要に応じて、更新間隔を調整することもできます。

クエリと更新のタイミングを考慮するために、Power BI では、残りの更新クエリがすべて完了すると、次の更新クエリのみが実行されます。 そのため、更新間隔がクエリの処理にかかる時間よりも短い場合でも、Power BI では残りのクエリが完了した後でのみ更新が行われます。

更新の種類が変更の検出の場合、これらの考慮事項は引き続き適用されます。 また、パフォーマンス アナライザーでは、レポート内のどのビジュアルとも一致しない場合でも、変更の検出メジャー クエリの結果が表示されます。 前に説明したのと同じガイダンスに従って、この種類のメジャーをトラブルシューティングできるように、この機能を提供しています。 この更新の種類の主な違いは、すべてのビジュアルからすべてのクエリがデータ ソースに送られるのではなく、1 つのクエリのみが送られることです。 これは、複数のユーザーがレポートを表示している場合にも当てはまります。

変更の検出を使用したパフォーマンス アナライザーの結果

前に説明したのと同じシナリオの場合:

  • 5 つのビジュアルに対して 1 つの変更の検出メジャー クエリにより、任意の数のビューアーに対して 1 つのクエリのみが生成される

  • 以前と同じシナリオ (5 つのビジュアル x 10 ユーザー = 約 50 のクエリ) を想定して、変更の検出メジャーによって更新がトリガーされる場合

要約すると、変更の検出を使用すると、変更が検出されるまで、1 つのクエリのみがデータ ソースに送信されます。 この場合、固定間隔の更新の種類に使用されるのと同じロジックが、同じ数のクエリを生成しているすべてのユーザーのすべてのビジュアルの更新に適用されます。 このアプローチは、長期的に見ればより効率的です。

パフォーマンスとトラブルシューティングに関するその他の質問と回答については、後の「よく寄せられる質問」セクションで確認できます。

Power BI サービスでのページの自動更新

データ ソースが DirectQuery である限り、Power BI サービスに発行されたレポートに対してページの自動更新を設定することもできます。

Power BI サービスのレポートに対してページの自動更新を構成する場合、手順は Power BI Desktop の場合と同様です。 Power BI サービスで構成した場合、ページの自動更新では埋め込み Power BI コンテンツもサポートされます。 この図では、Power BI サービスの [ページの更新] の構成が示されています。

サービス内のページの更新場所

  1. ページの更新をオンまたはオフにします。
  2. 更新の種類。
  3. 入力と情報 (更新の種類によって異なります)。

Note

ページの自動更新対応レポートを Power BI Desktop からサービスに発行するときに、セマンティック モデル設定メニューで DirectQuery データ ソースの資格情報を指定する必要があります。 ソースで設定されているセキュリティを考慮して、レポートの閲覧者が独自の ID でこのデータ ソースにアクセスできるように資格情報を設定できます。 変更の検出メジャーは、作成者の資格情報で評価されます。

ページの更新間隔

Power BI サービスで許容されるページの更新の種類と間隔は、レポートのワークスペースの種類の影響を受けます。 これは、次のシナリオに適用されます。

  • ページの自動更新が有効なワークスペースへのレポートの発行。
  • 既にワークスペースにあるページの更新間隔の編集。
  • サービスでのレポートの直接作成。

Power BI Desktop に更新間隔の制限はなく、1 秒間隔にすることができます。 ただし、レポートが Power BI サービスに発行されると、特定の制限が適用されます。これについては以降のセクションで説明します。

更新間隔に関する制限事項

Power BI サービスでは、レポートが発行されているワークスペース、Premium サービスを使用しているかどうか、Premium 容量管理者の設定、およびデータ ソースの種類に基づいて、ページの自動更新に関する制限が適用されます。

これらの制限のしくみをわかりやすくするため、容量とワークスペースに関する背景から説明します。

"容量" は、Power BI コンテンツのホストと配信に使用される一連のリソース (ストレージ、プロセッサ、メモリ) を表します。 容量は共有か予約済みです。 "共有容量" は、Microsoft の他のお客様と共有されます。 "予約容量" は、1 人の顧客用に予約されています。 予約容量の概要については、「Premium 容量を管理する」を参照してください。

共有容量の場合、ワークロードは他のお客様と共有される計算リソースで実行されます。 容量ではリソースを共有する必要があるため、最大モデル サイズ (1 GB) や最大日次更新頻度 (1 日 8 回) の設定など、"フェア プレイ" を確保するための制限が課されます。

Power BI の "ワークスペース" は、容量内に存在します。 それらによって、セキュリティ、コラボレーション、デプロイ コンテナーが表されます。 各 Power BI ユーザーには、マイ ワークスペースと呼ばれる個人用のワークスペースが用意されます。 追加のワークスペースを作成して、コラボレーションとデプロイを有効にすることができます。 それらは "ワークスペース" と呼ばれます。 既定では、ワークスペース (個人用のワークスペースも含む) は、共有容量内に作成されます。

2 つのワークスペース シナリオの詳細を次に示します。

共有ワークスペース。 通常のワークスペース (Premium 容量の一部ではないワークスペース) の場合、ページの自動更新の最小間隔は 30 分 (許容される最小間隔) です。 変更の検出の更新の種類は、共有容量では使用できません。

Premium ワークスペース。 Premium ワークスペースでページの自動更新 (固定間隔と変更の検出の両方) を使用できるかどうかは、Premium 管理者が Power BI Premium の容量に対して設定したワークロード設定によって変わります。 ページの自動更新を設定する機能に影響する可能性がある変数は 2 つあります。

  • 機能のオンとオフ。 容量管理者がこの機能を無効にした場合、発行されたレポートでどの種類のページの更新も設定できません。 固定間隔と変更の検出は、個別に有効または無効にすることができます。

  • 最小更新間隔。 固定間隔のページの自動更新を有効にする場合、容量管理者が最小更新間隔 (既定値は 5 分) を設定する必要があります。 間隔が最小値よりも少ない場合、Power BI サービスでは、容量管理者によって設定された最小間隔に合わせて間隔が上書きされます。

  • 最小実行間隔。 変更の検出を有効にする場合、容量管理者が最小実行間隔 (既定値は 5 秒) を設定する必要があります。 間隔が最小値よりも少ない場合、Power BI サービスでは、容量管理者によって設定された最小間隔に合わせて間隔が上書きされます。

警告

セマンティック モデルで有効にされていると、変更の検出メジャーによって、メジャーを計算して変更をポーリングするために、DirectQuery データ ソースへの接続が開かれます。 この接続は、Power BI で既に行われている低優先度の更新接続とは異なります。

容量管理ポータルのページの自動更新設定

次の表は、この機能を使用できる場所と、各容量の種類とストレージ モードの制限を詳しく説明したものです。

ストレージ モード 専用容量 共有された容量
DirectQuery FI のサポート: はい
CD のサポート: はい
最小: 1 秒
管理者のオーバーライド: はい
FI のサポート: はい
CD のサポート: いいえ
最小: 30 分
管理者のオーバーライド: いいえ
[インポート] FI のサポート: いいえ
CD のサポート: いいえ
最小: 該当なし
管理者のオーバーライド: 該当なし
FI のサポート: いいえ
CD のサポート: いいえ
最小: 該当なし
管理者のオーバーライド: 該当なし
混合モード (DirectQuery とその他のデータ ソース) FI のサポート: はい
CD のサポート: はい
最小: 1 秒
管理者のオーバーライド: はい
FI のサポート: はい
CD のサポート: いいえ
最小: 30 分
管理者のオーバーライド: いいえ
Analysis Services (Azure とオンプレミス) FI のサポート: はい
CD のサポート: いいえ
最小: 30 分
管理者のオーバーライド: はい
FI のサポート: はい
CD のサポート: いいえ
最小: 30 分
管理者のオーバーライド: いいえ
Power BI セマンティック モデル (ライブ接続) FI のサポート: はい
CD のサポート: いいえ
最小: 1 秒
管理者のオーバーライド: はい
FI のサポート: はい
CD のサポート: いいえ
最小: 30 分
管理者のオーバーライド: いいえ
Power BI セマンティック モデル (DirectQuery 接続) FI のサポート: いいえ
CD のサポート: いいえ
最小: 該当なし
管理者のオーバーライド: 該当なし
FI のサポート: いいえ
CD のサポート: いいえ
最小: 該当なし
管理者のオーバーライド: 該当なし
Power BI プッシュ セマンティック モデル FI のサポート: はい
CD のサポート: いいえ
最小: 30 分
管理者のオーバーライド: はい
FI のサポート: はい
CD のサポート: いいえ
最小: 30 分
管理者のオーバーライド: いいえ
Power BI ストリーミング セマンティック モデル FI のサポート: いいえ
CD のサポート: いいえ
最小: 該当なし
管理者のオーバーライド: 該当なし
FI のサポート: いいえ
CD のサポート: いいえ
最小: 該当なし
管理者のオーバーライド: 該当なし

表の凡例 :

  1. FI: 固定間隔
  2. CD: 変更の検出

警告

Power BI Desktop から Analysis Services または Power BI セマンティック モデルに接続し、更新間隔が 30 分以上の場合、既知の問題が発生します。 30 分後にレポート ページの視覚化にエラーが表示される場合があります。

インポート モードを使用する場合の開いているレポートに対するモデルの更新の影響

レポート ページが開いているときにセマンティック モデルが更新されると、開いているレポート ページが更新されて最新のデータが反映されます。 開いているレポートに更新されたデータを表示すると、古いデータに関連する問題が解決されます。これは、ページの自動更新に似ています。 セマンティック モデルが更新されたときに開いているレポートが自動的に更新されるのを確認できるのは、書き込みアクセス許可を持つユーザーのみです。

書き込みアクセス許可を持つ多数のユーザーがいるセマンティック モデルの場合 (たとえば、書き込みアクセス許可を持つユーザーが 1,000 人を超える場合)、開いているレポートの自動更新の信頼性が低下します。

考慮事項と制限事項

Power BI Desktop または Power BI サービスでページの自動更新を使用する場合に注意が必要な点がいくつかあります。

  • インポート ストレージ モードはページの自動更新ではサポートされていませんが、基になるセマンティック モデルが更新されており、ユーザーに書き込みアクセス許可がある場合、開いているレポートが自動的に更新されます。 更新の信頼性が低下する可能性がある場合については、前のセクションを参照してください。
  • 少なくとも 1 つの DirectQuery データ ソースを持つ複合モデルがサポートされています。
  • 変更の検出のメジャーは、セマンティック モデルごとに 1 つだけ設定できます。
  • Power BI テナントには、変更の検出メジャーを含む最大 10 個のモデルしか存在できません。

パフォーマンス診断

ページの自動更新は、シナリオを監視し、急速に変化するデータを探索する場合に便利です。 ただし、容量またはデータ ソースに過度の負荷がかかることがあります。

データ ソースに過度の負荷がかからないように、Power BI には次の保護策が用意されています。

  • 対話型のクエリ (ページの読み込み、クロス フィルタリングの視覚化など) が確実に優先されるように、すべてのページの自動更新クエリは低い優先度で実行されます。
  • 次の更新サイクルの前にクエリが完了しない場合、前のクエリが完了するまで、Power BI から新しい更新クエリは発行されません。 たとえば、更新間隔を 1 秒に設定し、クエリにかかる平均時間が 4 秒の場合、Power BI からは実質的に 4 秒ごとにクエリが発行されます。

それでもパフォーマンスのボトルネックが発生する可能性がある領域は 2 つあります。

  1. 容量。 クエリは、まず Premium 容量に到達し、レポートの視覚化から生成された DAX クエリが折りたたまれ、ソース クエリに評価されます。
  2. DirectQuery データ ソース。 前の手順で変換されたクエリは、ソースに対して実行されます。 ソースは、SQL Server インスタンスや SAP Hana ソースなどです。

管理者は Microsoft Fabric Capacity Metrics アプリを使用して、低優先度のクエリによって使用されている容量のサイズを視覚化できます。

低優先度のクエリは、ページの自動更新クエリとモデル更新クエリで構成されます。 現在、ページの自動更新クエリとモデル更新クエリの負荷を区別する方法はありません。

低優先度のクエリで容量が過負荷になっている場合は、次の操作を実行できます。

  • より大きな Premium SKU を依頼します。
  • レポートの所有者に、更新間隔を短くするように依頼します。
  • 容量管理者ポータルでは、次のことができます。
    • その容量のページの自動更新を無効にします。
    • 最小更新間隔を上げます。これは、その容量のすべてのレポートに影響します。

よく寄せられる質問

私はレポート作成者です。 Power BI Desktop でレポートの更新間隔を 1 秒に定義しましたが、発行後、サービスでレポートが更新されません。

  • そのページについて、ページの自動更新がオンになっていることを確認します。 この設定はページごとに行われるため、更新するレポートの各ページで設定をオンにする必要があります。
  • Premium 容量がアタッチされているワークスペースにアップロードしたかどうかを確認します。 そうしないと、更新間隔が 30 分の固定間隔でロックされ、変更の検出に使用できなくなります。
  • レポートが Premium ワークスペースにある場合は、アタッチされた容量に対してこの機能が有効にされているかどうかを管理者に確認します。 また、容量の最小更新間隔がレポートの間隔と同じか、それより低いことを確認します。 これは、固定間隔と変更の検出の両方に対して個別に適用されます。

私は容量管理者です。ページの自動更新間隔の設定を変更しましたが、変更が反映されません。 自動ページ更新を有効にしましたが、レポートは想定よりも遅い速度で更新されているか、更新されません。

  • 容量管理者 UI で行われたページの自動更新設定の変更は、レポートに反映されるまでに最大 5 分かかります。
  • 容量のページの自動更新を有効にするだけでなく、有効にするレポートのページについても有効にする必要があります。
  • どちらの更新の種類も個別に管理されるため、有効にしている更新の種類が有効になっていることを確認してください。
  • Premium 容量でのワークロードの有効化と構成の詳細については、「Premium 容量でワークロードを構成する」を参照してください。

個人用レポートが混合モードで動作しています。 (混合モードとは、レポートに DirectQuery 接続とインポート データ ソースがあることを意味します)。一部の視覚化が更新されません。

  • 視覚化で Import テーブルが参照されている場合は、これは想定される動作です。 ページの自動更新は Import ではサポートされません。
  • このセクションの最初の質問を参照してください。

レポートはサービスで更新されていましたが、突然停止しました。

  • ページを更新してみて、問題が自動的に解決されるかどうかを確認してください。
  • 容量管理者に確認してください。管理者が機能を無効にしたか、または最小更新間隔を上げた可能性があります。 (このセクションの 2 番目の質問を参照してください。)

私はレポート作成者です。 視覚化が指定した頻度で更新されません。 更新間隔が長くなっています。

  • クエリの実行に時間がかかると、更新間隔が遅れます。 ページの自動更新では、すべてのクエリの実行が完了するまで待ってから、新しいものが実行されます。
  • 容量管理者が、レポートに設定したものよりも高い最小更新間隔を設定している可能性があります。 容量管理者に、最小更新間隔を下げるように依頼してください。

ページの自動更新クエリはキャッシュから提供されますか。

  • いいえ。 すべてのページの自動更新クエリでは、キャッシュされたデータはバイパスされます。

変更の検出メジャーにより更新がトリガーされません

  • ページに対して変更の検出が有効になっていることを確認します。 この設定はページごとに行われるため、更新するレポートの各ページで設定をオンにする必要があります。
  • Premium 容量がアタッチされているワークスペースにアップロードしたかどうかを確認します。 なっていない場合、変更の検出は機能しません。
  • レポートが Premium ワークスペースにある場合は、アタッチされた容量に対してこの機能が有効にされているかどうかを管理者に確認します。 また、容量の最小実行間隔がレポートの間隔と同じか、それより低いことを確認します。
  • 前に説明したすべての項目を確認したら、Power BI Desktop または編集モードのいずれかでメジャーがまったく変更されていないかどうかを確認してください。 これを行うには、それをキャンバスにドラッグし、値が変更されているかどうかを確認します。 なっていない場合、そのメジャーがデータ ソースの変更のポーリングに適していない可能性があります。

Analysis Services に接続しても APR トグルが表示されない

詳細については、次の記事を参照してください。