Power BIでAzure Storage上のデータをレポート化している場合、「Table Storage Mode in Power BI Semantic Models」はまずAzure Table Storageそのものの設定ではなく、Power BIセマンティックモデル内の各テーブルをどの方式で保持・参照するかを決める設定だと理解するのが重要です。
結論から言うと、確認すべきポイントは「データをPower BI側にキャッシュするのか」「毎回データソースへ問い合わせるのか」「Fabric OneLake上のDeltaテーブルをDirect Lakeで扱うのか」です。設定を誤ると、レポート表示が遅くなる、Azure側のクエリ負荷が増える、更新後のデータが反映されない、移行後にDirectQueryへ戻せないといった問題につながります。
この記事では、Microsoft Learnの公式情報をもとに、Power BIセマンティックモデルにおけるTable Storage Modeの変更点、影響範囲、管理者・開発者が確認すべき設定、移行・展開時の注意点を実務目線で整理します。公式ドキュメントでは、テーブルのStorage modeによってPower BIがデータをメモリに保存するか、ビジュアル表示時にデータソースから取得するかを制御できると説明されています。(Microsoft Learn)
Azure Storageの「Table Storage Mode in Power BI Semantic Models」で押さえるべきこと
Power BIのTable storage modeは、セマンティックモデル内のテーブル単位で動作する設定です。モデル全体に対して一律に「Import」や「DirectQuery」を選ぶだけではなく、テーブルごとに保存方式を変えられる点がポイントです。
Azure StorageやFabric OneLake、Azure SQL Database、Azure Synapse AnalyticsなどのデータをPower BIで可視化する場合、この設定は次のような判断に直結します。
| 判断項目 | 影響する内容 |
|---|---|
| レポート表示速度 | ImportやDualはキャッシュを使えるため高速化しやすい |
| データの鮮度 | DirectQueryやDirect Lakeは最新データに近づけやすい |
| Azure側の負荷 | DirectQueryはユーザー操作のたびにデータソースへ問い合わせる可能性がある |
| 更新設計 | Importはスケジュール更新、Hybridは増分更新とリアルタイム取得を組み合わせる |
| コスト・容量 | キャッシュするデータ量、Fabric容量、データソース負荷に影響する |
| 移行のしやすさ | 一部のStorage mode変更は元に戻せない場合がある |
特に「Table Storage Mode」という名前から、Azure Table Storageのストレージアカウント設定と混同しやすい点に注意が必要です。ここでいう「Table」は、Power BIセマンティックモデル内のテーブルを指します。Azure Storage側のテーブルサービスやBlobの冗長化、アクセス層、ライフサイクル管理とは別の概念です。
何が変わるのか：Storage modeの理解がより重要になった理由
今回の公式情報で重要なのは、新しい単一機能の追加というより、Power BIセマンティックモデルで利用できるテーブルストレージモードの整理が進み、Import、DirectQuery、Dual、Hybridに加えて、Fabric時代のDirect Lake関連の扱いを理解する必要性が高まっている点です。
公式ページでは、Power BIセマンティックモデルのテーブルストレージモードとして、Import、Direct Lake on OneLake、Direct Lake on SQL、DirectQuery、DirectQuery on Power BI semantic models、Dual、Hybridが整理されています。(Microsoft Learn)
従来のPower BIでは、まずImportかDirectQueryかを選ぶケースが多くありました。しかし、現在は次のような構成が現実的になっています。
| 構成 | 実務での例 |
|---|---|
| Import中心 | 毎朝更新される売上集計レポート |
| DirectQuery中心 | 数分単位で変わる運用監視データや在庫データ |
| Import + DirectQuery | マスタはImport、明細やログはDirectQuery |
| Dual活用 | 日付、顧客、商品などのディメンションテーブルをキャッシュしつつDirectQueryにも対応 |
| Hybrid | 過去データはImport、直近データはDirectQuery |
| Direct Lake | Fabric OneLake上のDeltaテーブルをPower BIで低遅延に分析 |
Azure Storageをデータ基盤として使っている組織では、将来的にFabric OneLakeやLakehouseへデータを集約し、Power BIのDirect Lakeで分析する構成も増えます。そのため、Power BI Desktop上の見た目だけでなく、データがどこにあり、どのタイミングで読み込まれ、どこにキャッシュされるのかを設計段階で明確にする必要があります。
各Table Storage Modeの違い
Power BIのTable Storage Modeは、単に「速い・遅い」だけで選ぶものではありません。データ量、更新頻度、セキュリティ、ソースシステムの負荷、レポート利用者数を合わせて判断します。
Import：高速表示を優先する基本モード
Importは、データのスナップショットをPower BI側のネイティブストレージに保存し、レポート表示時にはキャッシュされたデータを使う方式です。公式情報でも、Importはビジュアルをすばやく読み込むためにデータのスナップショットを保存し、最新データを取得するにはセマンティックモデルまたはテーブルの更新が必要とされています。(Microsoft Learn)
向いているのは、次のようなケースです。
| 向いているケース | 理由 |
|---|---|
| 日次・時間単位の更新で十分 | 更新スケジュールで鮮度を管理しやすい |
| レポート利用者が多い | データソースへ毎回問い合わせないため負荷を抑えやすい |
| 集計・分析操作が多い | Power BIのインメモリエンジンで高速に処理しやすい |
| 複雑なPower Query変換やDAXを使う | DirectQueryより制約を受けにくい |
Azure Storage上のCSV、Parquet、JSONなどを定期的に取り込み、部署別・月別に集計する用途ではImportが第一候補になります。
ただし、Importには「更新されるまで最新データにならない」という弱点があります。たとえばAzure Storageに5分前に追加されたログをすぐレポートへ反映したい場合、Importだけでは要件を満たしにくくなります。
DirectQuery：データを保持せず、表示時にデータソースへ問い合わせる
DirectQueryは、Power BI側にデータを保存せず、ビジュアルを表示するタイミングでデータソースへ問い合わせる方式です。公式ドキュメントでは、DirectQueryはデータをインポートせず、各ビジュアルが基になるデータソースへクエリを発行すると説明されています。(Microsoft Learn)
DirectQueryが向いているのは、次のようなケースです。
| 向いているケース | 注意点 |
|---|---|
| データ更新頻度が高い | レポート操作のたびにソースへ負荷がかかる |
| データ量が非常に大きい | ソース側のクエリ性能が低いとレポートも遅くなる |
| データをPower BIに複製したくない | ビジュアルやタイルのキャッシュには注意が必要 |
| ソース側のセキュリティを活かしたい | SSOや権限設計の確認が必要 |
Azure SQL DatabaseやAzure Synapse Analyticsをソースにする場合はDirectQueryが有効な選択肢になります。一方、Azure Storage上のファイルを直接参照する構成では、Power Queryの折りたたみやコネクタの対応状況によって実用性が変わります。DirectQueryを選ぶ前に、データソースがDirectQueryに適しているか、クエリがソース側で効率よく処理されるかを確認してください。
DirectQueryでよくある失敗は、「最新に近いデータが見られるから」という理由だけで採用してしまうことです。ユーザーが多いレポート、ビジュアル数が多いページ、複雑なDAXを含むモデルでは、Azure側のクエリ負荷や応答遅延が問題になりやすくなります。
Direct Lake on OneLake：Fabric環境の大規模分析向け
Direct Lakeは、Microsoft FabricのOneLake上にあるDeltaテーブルをPower BIで扱うためのテーブルストレージモードです。MicrosoftのDirect Lake概要では、Direct LakeはFabricで利用できるPower BIセマンティックモデルのテーブルストレージモードであり、OneLake上のDeltaテーブルから大容量データをすばやくメモリへ読み込む用途に最適化されていると説明されています。(Microsoft Learn)
ImportとDirectQueryの中間のように見えますが、設計思想は異なります。
| 観点 | Direct Lake |
|---|---|
| 主な対象 | Fabric OneLake上のDeltaテーブル |
| 強み | 大容量データを低遅延で分析しやすい |
| 更新 | Importのような全データ再取り込みではなく、メタデータ更新に近い |
| 前提 | Fabric容量、Deltaテーブル設計、OneLake上のデータ整備 |
| 注意点 | Fabricの容量制限、Direct Lakeのガードレール、セキュリティ設計 |
Azure StorageのデータをFabric LakehouseやOneLakeへ取り込み、Power BIで分析する構成ではDirect Lakeが重要になります。ただし、Direct Lakeは「Azure Storageに置いたファイルを何でも自動的に高速分析できる」機能ではありません。Deltaテーブル、Fabric容量、権限、モデル設計を含めたアーキテクチャとして考える必要があります。
Direct Lake on SQL：条件によってDirectQueryにフォールバックする
Direct Lake on SQLは、FabricアイテムのSQL分析エンドポイントで新しいセマンティックモデルを作成する場合に関係します。公式情報では、ビューを使う場合、SQLの細かなアクセス制御が有効な場合、Direct Lakeのガードレールに達した場合などに、Power BIがDirectQueryストレージモードでデータにアクセスするケースがあるとされています。(Microsoft Learn)
ここで重要なのは、Direct Lakeのつもりで設計していても、条件次第でDirectQuery相当の動きになる可能性があることです。
たとえば、レポートが急に遅くなった場合、単にPower BI側の問題ではなく、SQLビューの利用、権限設定、容量ガードレール超過によってDirectQueryへ切り替わっている可能性があります。管理者は、更新履歴や容量メトリック、クエリの実行状況を確認し、どのモードで実際に処理されているかを追跡できるようにしておくべきです。
DirectQuery on Power BI semantic models：既存モデルを拡張する場合に使う
DirectQuery on Power BI semantic modelsは、既存のPower BIセマンティックモデルに接続し、そのモデルに対して小さな変更を加えたい場合に使われます。公式情報では、既存のセマンティックモデルに接続して「Make changes to this model」を選択した場合などに利用され、元モデルのメジャーを使いながら新しいモデル側で一部の列プロパティを上書きできると説明されています。(Microsoft Learn)
実務では、次のような用途に向いています。
| 利用シーン | 例 |
|---|---|
| 既存の全社モデルを部門向けに拡張 | 表示名や書式を部門レポート向けに調整 |
| 元モデルを複製せずにレポートを作る | 共通メジャーを再利用 |
| 小さな追加テーブルを組み合わせる | 部門管理表や目標値を追加 |
ただし、乱用すると「元モデル」「拡張モデル」「レポート」の依存関係が複雑になります。誰がどのモデルを管理するのか、変更時にどのレポートへ影響するのかをドキュメント化しておくことが重要です。
Dual：ディメンションテーブルの性能改善に効く
Dualは、DirectQueryとImportが混在するモデルで特に重要です。Dualに設定されたテーブルは、可能な場合はキャッシュからデータを返し、必要に応じてDirectQueryとしても動作します。公式情報では、Dualテーブルは可能であればキャッシュからデータを返し、そうでなければDirectQueryモードに戻ると説明されています。(Microsoft Learn)
典型的には、次のようなディメンションテーブルに使います。
| Dualに向くテーブル | 理由 |
|---|---|
| 日付テーブル | スライサーや集計軸として頻繁に使う |
| 商品マスタ | Factテーブルと結合されることが多い |
| 顧客マスタ | フィルター条件として使われやすい |
| 地域・拠点マスタ | 小さく、キャッシュ効果が出やすい |
たとえば、売上明細テーブルはDirectQuery、日付・顧客・商品テーブルはDualにすることで、スライサー表示や初期表示の体感速度を改善できる場合があります。
ただし、Dualは万能ではありません。キャッシュの値が古い場合、DirectQueryで取得した最新値とズレる可能性があります。公式情報でも、Dualテーブルはキャッシュに当たる場合と当たらない場合があり、古いキャッシュから返る値がソースから返る値と異なる可能性があるため、データフローを理解して設計する責任があるとされています。(Microsoft Learn)
Hybrid：過去データはImport、最新データはDirectQuery
Hybridは、増分更新のシナリオでImportテーブルの最新パーティションだけをDirectQueryにする構成です。公式情報では、HybridはImportテーブルの増分更新シナリオで利用され、最新パーティションをDirectQueryモードにして、Import更新の間も最新データを利用できるようにすると説明されています。(Microsoft Learn)
大量のログ、売上明細、IoTデータ、トランザクションデータを扱う場合に有効です。
| データ範囲 | 推奨構成の例 |
|---|---|
| 過去2年分 | Importで保持し、高速に集計 |
| 直近1日〜数日 | DirectQueryで最新データを取得 |
| 古い履歴 | 集計済みデータやアーカイブに分離 |
増分更新とリアルタイムデータの公式情報では、最新のImportパーティションだけを更新し、必要に応じてリアルタイム用のDirectQueryパーティションを使うことで、更新量を減らしながらデータソースの最新変更をクエリ結果に含められると説明されています。(Microsoft Learn)
ただし、リアルタイムDirectQueryパーティションはPremium系の容量が必要になる場合があります。公式情報では、DirectQueryによるリアルタイムデータ取得はPower BI Premium、Premium per user、Power BI Embeddedモデルでのみサポートされるとされています。(Microsoft Learn)
対象者：誰が確認すべきか
Table Storage Modeは、Power BIレポート作成者だけの話ではありません。Azure StorageやFabric、Power BIをまたいで管理している組織では、管理者、開発者、データエンジニア、レポート作成者がそれぞれ確認すべきポイントを持ちます。
| 対象者 | 確認すべきこと |
|---|---|
| Power BI管理者 | 容量、更新スケジュール、ゲートウェイ、データセット設定、利用者数 |
| Azure管理者 | データソース側の負荷、ネットワーク、認証、アクセス権 |
| データエンジニア | Deltaテーブル、パーティション、集計テーブル、データ更新パイプライン |
| Power BI開発者 | テーブルごとのStorage mode、DAX、Power Query、リレーションシップ |
| セキュリティ担当者 | RLS、OLS、SSO、データ複製可否、機密データのキャッシュ |
| 運用担当者 | 更新失敗時の対応、性能劣化の監視、展開パイプライン |
特にAzure StorageからPower BIへデータを取り込む場合、Power BI側でImportしているのか、Fabric OneLakeを経由してDirect Lakeで扱っているのか、DirectQueryでソースへ問い合わせているのかを明確にしてください。
現在のStorage modeを確認する手順
Power BI Desktopでは、テーブルごとのStorage modeをModel viewから確認できます。公式情報では、Model viewで対象テーブルを選択し、PropertiesペインのAdvancedセクションからStorage modeを確認する手順が示されています。(Microsoft Learn)
| 手順 | 操作 |
|---|---|
| 1 | Power BI Desktopで対象のPBIXまたはセマンティックモデルを開く |
| 2 | 左側メニューからModel viewを開く |
| 3 | 確認したいテーブルを選択する |
| 4 | Propertiesペインを表示する |
| 5 | Advancedセクションを展開する |
| 6 | Storage modeの値を確認する |
確認時は、単に値を見るだけでなく、次の観点でメモを残すと運用に役立ちます。
| 確認項目 | 記録例 |
|---|---|
| テーブル名 | FactSales、DimDate、DimCustomer |
| 現在のStorage mode | Import、DirectQuery、Dualなど |
| データソース | Azure SQL、Fabric Lakehouse、Azure Storage上のファイルなど |
| 更新頻度 | 日次、時間単位、リアルタイム要件あり |
| データ量 | 行数、容量、増加ペース |
| 利用箇所 | 重要レポート、役員ダッシュボード、部門レポート |
| 変更可否 | 変更すると戻せない可能性があるか |
この棚卸しをせずにモード変更を行うと、レポートの速度、データ鮮度、権限、更新処理に予期しない影響が出ることがあります。
Storage mode変更時の注意点
最も注意すべきなのは、Storage modeは自由に何度でも切り替えられる設定ではないという点です。
公式情報では、多くのテーブルでStorage modeはテーブル追加時にのみ設定でき、作成時にDirectQueryまたはDirect Lake on OneLakeだった場合に限って変更できるとされています。DirectQueryテーブルはImportまたはDualに変更できますが、その後DirectQueryへ戻せない場合があります。例外として、Power BI web modelingやPower BI Desktopのlive editingではバージョン管理で戻せる場合があります。(Microsoft Learn)
実務では、次のように判断してください。
| 変更内容 | 注意点 |
|---|---|
| DirectQueryからImportへ変更 | レポートは速くなりやすいが、更新設計が必要になる |
| DirectQueryからDualへ変更 | ディメンションテーブル向き。キャッシュ整合性に注意 |
| ImportからDirectQueryへ変更 | 単純な切り替えではなく、再設計が必要になることが多い |
| Direct LakeからImportへ変更 | Fabric Notebookのsemantic link labsなど、通常UI以外の手段が関係する場合がある |
| Hybrid化 | 増分更新、Premium容量、パーティション設計を確認する |
「とりあえずImportにして速くする」「あとでDirectQueryに戻せばよい」という進め方は避けましょう。検証用モデルで性能、更新、DAX、権限を確認してから本番モデルへ展開するのが安全です。
Azure Storage利用者が特に確認すべき設計ポイント
Azure StorageやFabricをデータ基盤としている場合、Power BI側のStorage modeだけを見ても十分ではありません。データの配置、形式、更新パイプライン、権限、容量を合わせて確認する必要があります。
データはファイルなのか、Deltaテーブルなのか
Azure Storage上のCSVやJSONファイルをPower BIにImportしている場合と、Fabric OneLake上のDeltaテーブルをDirect Lakeで参照している場合では、設計が大きく異なります。
| データ配置 | Power BI側の主な選択肢 |
|---|---|
| Azure Blob Storage上のCSV/JSON | Importが現実的なことが多い |
| Azure Data Lake Storage Gen2上のParquet | Import、またはFabric経由での活用を検討 |
| Fabric LakehouseのDeltaテーブル | Direct Lakeを検討 |
| Azure SQL Database | Import、DirectQuery、Dualを要件で選択 |
| Azure Synapse Analytics | Import、DirectQuery、Hybridを要件で選択 |
Direct Lakeを使いたい場合は、単にファイルを置くだけではなく、分析に適したDeltaテーブルとして整備されているかが重要です。Direct Lakeの公式情報でも、Direct LakeはFabricのLakehouse、WarehouseなどのDeltaテーブルを持つ大規模データソースに適しているとされています。(Microsoft Learn)
キャッシュしてよいデータか
ImportやDualはPower BI側にデータをキャッシュします。これは性能面では有利ですが、データ複製の観点では確認が必要です。
たとえば、個人情報、機密情報、契約情報、監査ログなどを含むテーブルでは、次の点を事前に確認してください。
| 確認項目 | 具体例 |
|---|---|
| Power BI側への複製が許可されているか | 社内規程、データ分類、契約条件 |
| RLS/OLSをPower BI側でも再現できるか | 部門別・ユーザー別の閲覧制御 |
| エクスポート制限が必要か | Excel出力、CSV出力、Analyze in Excel |
| 更新遅延が許容されるか | 何分・何時間前のデータまで許容するか |
| キャッシュ削除・モデル削除の運用があるか | 退職者、プロジェクト終了、監査対応 |
DirectQueryを使えばデータを完全にPower BIへ複製しない構成に近づけられますが、ビジュアルやダッシュボードのキャッシュに集計結果が残る可能性は考慮すべきです。DirectQueryの公式情報でも、ダッシュボードタイルはスケジュールに基づいて結果をキャッシュすることが説明されています。(Microsoft Learn)
Azure側のクエリ負荷を見積もる
DirectQueryを採用する場合、Power BIのユーザー操作がAzure側のクエリになります。1つのレポートページに10個のビジュアルがあり、50人が朝9時に同時に開くと、短時間で多数のクエリが発生する可能性があります。
見積もり時は、次のように考えます。
| 観点 | 確認方法 |
|---|---|
| レポートページ数 | 主要ページごとのビジュアル数を数える |
| 1ページあたりのクエリ数 | Performance AnalyzerやProfilerで確認 |
| 同時利用者数 | 利用ログや部門規模から見積もる |
| ピーク時間 | 朝会、月次締め、経営会議前など |
| ソース側性能 | インデックス、パーティション、集計テーブルを確認 |
| 課金影響 | クエリ量、コンピュート、容量、データ転送を確認 |
DirectQueryの公式情報では、ビジュアルの応答遅延はデータソース性能やネットワーク、ゲートウェイの影響を受け、各ユーザー操作がクエリを発生させるため、利用者数やビジュアル数が多いほど負荷計画が重要になります。(Microsoft Learn)
管理者が確認すべき設定
Power BI管理者やAzure管理者は、個別レポートの表示確認だけでなく、ワークスペース、容量、更新、認証、監視を含めて確認する必要があります。
確認チェックリスト
| 項目 | 確認内容 |
|---|---|
| ワークスペース容量 | Premium、Fabric容量、PPU、Proのどれか |
| 更新スケジュール | Importや増分更新の頻度、失敗時の通知 |
| ゲートウェイ | オンプレミスやVNet経由の接続が必要か |
| 認証方式 | OAuth、サービスプリンシパル、固定ID、SSO |
| データソース資格情報 | 本番用アカウントか、個人アカウントに依存していないか |
| RLS/OLS | Power BI側とソース側の権限が矛盾していないか |
| 容量メトリック | CPU、メモリ、クエリ時間、スロットリング |
| 監査ログ | 誰がモデルやレポートを変更したか追えるか |
特にDirect Lakeを使う場合はFabric容量の確認が必須です。Direct Lakeの公式情報では、Direct LakeセマンティックモデルにはFabric容量ライセンスが必要であり、容量SKUごとの制限やガードレールが存在すると説明されています。(Microsoft Learn)
更新失敗時の切り分けポイント
ImportやHybridでは、更新失敗がレポート鮮度に直結します。次の順で切り分けると原因を見つけやすくなります。
| 順番 | 確認ポイント |
|---|---|
| 1 | Power BIサービスの更新履歴でエラー内容を確認 |
| 2 | データソース資格情報が期限切れでないか確認 |
| 3 | Azure StorageやSQL側の権限が変わっていないか確認 |
| 4 | スキーマ変更で列名・型が変わっていないか確認 |
| 5 | Power Queryのステップが折りたたみ可能か確認 |
| 6 | 容量不足、タイムアウト、メモリ不足がないか確認 |
| 7 | 増分更新のRangeStart、RangeEnd条件が正しいか確認 |
Azure Storage上のファイル構成が変わった場合、たとえばフォルダー名、ファイル拡張子、列名、日付形式が変わるだけでもPower BI更新が失敗することがあります。Power BI側だけでなく、データ生成側の変更管理も必要です。
開発者が確認すべきモデル設計
Power BI開発者は、Storage modeの選択をDAXやPower Query、リレーションシップ設計とセットで考える必要があります。
まずファクトとディメンションを分けて考える
テーブルごとのStorage modeは、スター スキーマを前提に考えると判断しやすくなります。
| テーブル種別 | 例 | 推奨候補 |
|---|---|---|
| 大容量ファクト | 売上明細、アクセスログ、センサーデータ | DirectQuery、Hybrid、Direct Lake |
| 小〜中規模ファクト | 月次売上、予算実績 | Import |
| ディメンション | 日付、商品、顧客、地域 | Import、Dual |
| 補助テーブル | 目標値、分類表、手入力マスタ | Import |
| 直近データ | 当日売上、最新在庫、監視ログ | DirectQuery、Hybrid |
よくある失敗は、すべてのテーブルをDirectQueryにしてしまうことです。小さなマスタまでDirectQueryにすると、スライサー表示やフィルター操作のたびに余計なクエリが発生し、レポート全体が遅くなります。小さく安定したディメンションはImportまたはDualにする方が実用的です。
Power Queryの折りたたみを確認する
DirectQueryや増分更新では、Power Queryの変換がデータソース側へ折りたたまれるかが重要です。DirectQueryの公式情報では、スケーラブルな性能のためにはPower Query foldingが必要であり、複雑な手順やカスタム関数などがエラーや性能低下につながる可能性があると説明されています。(Microsoft Learn)
確認すべき変換の例は次の通りです。
| 変換 | 注意点 |
|---|---|
| 列の削除・選択 | 早い段階で不要列を除外する |
| 日付フィルター | 増分更新ではRangeStart、RangeEndの適用を確認 |
| 型変換 | ソース側で明示的に型を整える方が安全 |
| カスタム列 | DirectQueryではDAXやMの制約に注意 |
| 結合 | ソース側で処理できる形にする |
| グループ化 | Power BI側ではなくソース側集計を検討 |
特にAzure Storage上のファイルを複数結合している場合、ファイル数の増加に伴って更新時間が伸びやすくなります。可能であれば、Power BIで複雑な加工を行う前に、Data Factory、Fabric Data Pipeline、Spark、SQLなどで分析用の形に整えておくと安定します。
リレーションシップとDualの伝播を理解する
DirectQueryとImportを混在させると、リレーションシップが制限付きになる場合があります。公式情報では、DirectQueryテーブルとImportテーブルの関係には制限があり、DirectQueryからDualへ切り替えることで通常のリレーションシップを保ちやすくなるケースが説明されています。(Microsoft Learn)
開発者は、Storage mode変更後に次を必ず確認してください。
| 確認項目 | 理由 |
|---|---|
| リレーションシップの種類 | Many-to-manyや制限付き関係になっていないか |
| フィルター方向 | 双方向フィルターが過剰でないか |
| カーディナリティ | 1対多の「1」側に重複がないか |
| スライサーの応答速度 | ディメンションがDirectQueryのままだと遅くなることがある |
| 集計結果 | ImportとDirectQueryの混在で値ズレがないか |
Dualは性能改善に効きますが、キャッシュの鮮度差による業務影響を確認せずに使うのは危険です。たとえば、顧客マスタの所属部門が更新された直後に、売上明細は最新、顧客マスタは古いキャッシュという状態になると、部門別売上が一時的にズレる可能性があります。
移行時の注意点
既存のPower BIモデルを見直す場合、Storage modeの変更は「ボタンを切り替える作業」ではなく、モデル移行として扱うべきです。
移行前に確認すること
| 確認項目 | 具体的な確認内容 |
|---|---|
| 現在の利用状況 | 重要レポート、利用者数、ピーク時間 |
| データ鮮度要件 | 何分遅れまで許容されるか |
| データ量 | 現在サイズ、月次増加量、履歴保持期間 |
| 更新時間 | 現在の更新所要時間、失敗頻度 |
| DAXの複雑さ | DirectQueryで制約を受ける式がないか |
| Power Query | 折りたたみできないステップがないか |
| 権限 | RLS、OLS、ソース側権限の整合性 |
| ロールバック | 変更前モデルのバックアップ、展開パイプライン |
移行パターン別の考え方
| 移行パターン | 向いている状況 | 注意点 |
|---|---|---|
| DirectQueryからImport | 表示速度を上げたい、更新頻度が低い | データ更新スケジュールと容量を再設計 |
| ImportからDirectQuery | データ鮮度・データ複製制限が重要 | 再構築に近い。DAX、Power Query、ソース性能を検証 |
| ImportからHybrid | 大容量履歴と最新データを両立したい | Premium容量、増分更新、日付列設計が必要 |
| DirectQuery + Dual | ディメンション参照を高速化したい | キャッシュ整合性、リレーションシップ確認が必要 |
| ImportからDirect Lake | Fabric/OneLake中心へ移行する | Deltaテーブル化、容量、権限設計が必要 |
移行時は、いきなり本番モデルを変更せず、複製したワークスペースで検証してください。Power BIのレポートは利用者が気づかないところで複数の部門資料やExcel分析に使われていることがあります。変更前に利用状況メトリックや依存関係を確認しておくと、影響範囲を把握しやすくなります。
展開・運用で失敗しやすいポイント
本番と開発でStorage modeがズレる
開発環境ではImport、本番ではDirectQueryというように、環境ごとにStorage modeが異なると、テスト結果が本番の動作を再現しません。表示速度、DAX結果、権限、更新処理が変わるため、可能な限り本番に近い構成で検証してください。
スキーマ変更を軽視する
DirectQueryでは、ソース側の列削除やリネームがPower BIサービスに自動反映されるわけではありません。DirectQueryの公式情報では、スキーマ変更時にはPower BI Desktopでの更新が必要になると説明されています。(Microsoft Learn)
Azure Storage上のファイルを使う場合も、列名や日付型の変更はPower BI更新失敗の原因になります。データ生成側の変更は、Power BI開発者にも事前共有する運用にしておきましょう。
DirectQueryでレポートページを作り込みすぎる
DirectQueryでは、ビジュアル、スライサー、クロスフィルター、TopN、DistinctCount、複雑なメジャーなどがクエリ増加や性能低下につながります。DirectQueryの公式情報でも、ビジュアル数やフィルター、相互作用を抑えることが推奨されています。(Microsoft Learn)
実務上は、DirectQueryレポートでは次の方針が有効です。
| 改善策 | 効果 |
|---|---|
| 1ページのビジュアル数を減らす | 同時クエリ数を抑える |
| スライサーに適用ボタンを使う | 操作ごとのクエリ発行を減らす |
| 不要なクロスハイライトを無効化 | 高コストな再計算を抑える |
| 集計テーブルを用意する | 明細への直接クエリを減らす |
| ソース側にインデックスやパーティションを設計 | クエリ応答を改善する |
「最新データ」と「一貫した時点」を混同する
DirectQueryやHybridは最新データに近づけやすい一方、複数ビジュアルが完全に同じ時点のデータを見ているとは限りません。DirectQueryの公式情報でも、異なるビジュアルや内部クエリがわずかに異なる時点で実行される可能性があり、厳密な時点整合性が必要な場合は設計上の配慮が必要とされています。(Microsoft Learn)
経営数値、監査レポート、月次締め資料では「最新」よりも「確定時点の一貫性」が重要な場合があります。その場合は、スナップショットテーブルを作る、締め処理後のImportモデルを使う、レポート上にデータ基準時刻を表示するなどの対策を取りましょう。
実務での選び方
Storage modeを選ぶときは、次の順で考えると判断しやすくなります。
| 質問 | 判断 |
|---|---|
| レポートは秒単位・分単位の最新性が必要か | 必要ならDirectQuery、Hybrid、Direct Lakeを検討 |
| データ量はImport可能な範囲か | 可能ならImportを基本にする |
| ソース側へ高頻度クエリを投げてもよいか | 難しいならImportや集計テーブルを検討 |
| Fabric OneLake上のDeltaテーブルか | 条件が合えばDirect Lakeを検討 |
| 履歴は大きいが直近だけ新しい必要があるか | Hybridを検討 |
| 小さなマスタがDirectQueryファクトと結合されるか | Dualを検討 |
| データ複製に制約があるか | DirectQueryやDirect Lakeの権限設計を確認 |
| 厳密な時点整合性が必要か | Importやスナップショット方式を検討 |
迷った場合は、まずImportを基準に考えるのが現実的です。DirectQueryの公式情報でも、最大の対話性と変換の柔軟性が必要な場合はImportが第一候補とされ、DirectQueryはレイテンシ、サイズ、ガバナンス、セキュリティ、アーキテクチャ上の制約がある場合に検討する位置づけです。(Microsoft Learn)
すぐ実施したい確認リスト
Power BIとAzure Storageを連携している環境では、まず次の確認から始めてください。
| 優先度 | 確認内容 | 対応者 |
|---|---|---|
| 高 | 主要セマンティックモデルの各テーブルのStorage modeを棚卸しする | Power BI開発者 |
| 高 | Import、DirectQuery、Dual、Hybrid、Direct Lakeの混在状況を確認する | Power BI管理者 |
| 高 | DirectQueryのレポートでソース側負荷と応答時間を測定する | Azure管理者 |
| 高 | Importモデルの更新時間と失敗履歴を確認する | 運用担当者 |
| 中 | Dualテーブルのキャッシュ鮮度が業務要件を満たすか確認する | データ責任者 |
| 中 | 増分更新やHybrid化の対象となる大容量ファクトを洗い出す | データエンジニア |
| 中 | Direct Lakeを使う候補データがDeltaテーブルとして整備されているか確認する | Fabric担当者 |
| 中 | 本番展開前にロールバック手順を用意する | 管理者・開発者 |
この確認により、単に「レポートが遅い」「更新が重い」という症状ではなく、Storage mode、データソース、更新方式、モデル設計のどこに問題があるかを切り分けやすくなります。
まとめ：Table Storage Modeは性能・鮮度・運用コストを左右する設計項目
Table Storage Mode in Power BI Semantic Modelsは、Azure StorageやFabric上のデータをPower BIで活用するうえで、性能、データ鮮度、ソース負荷、セキュリティ、運用コストを左右する重要な設計項目です。
まず押さえるべき結論は次の通りです。
| 要点 | 実務上の意味 |
|---|---|
| Table Storage ModeはPower BIセマンティックモデルのテーブル単位の設定 | Azure Table Storageのサービス設定ではない |
| Importは高速だが更新が必要 | 定期更新レポートに向く |
| DirectQueryは最新性を得やすいがソース負荷が増える | データソース性能と利用者数の見積もりが必須 |
| Dualはディメンションテーブルの性能改善に有効 | キャッシュ整合性を確認する |
| Hybridは大容量履歴と最新データの両立に有効 | Premium容量や増分更新設計を確認する |
| Direct LakeはFabric OneLake時代の重要な選択肢 | Deltaテーブル、容量、ガードレールを含めて設計する |
| Storage mode変更は元に戻せない場合がある | 本番変更前に複製環境で検証する |
次に取るべき行動は、主要なPower BIセマンティックモデルを開き、各テーブルのStorage mode、データソース、更新頻度、利用レポートを一覧化することです。そのうえで、遅いレポートはDirectQueryのクエリ負荷を確認し、更新が重いImportモデルは増分更新やHybrid、Fabric環境ではDirect Lakeの適用可否を検討してください。
コメント