Power BI DirectQuery の制限事項を正しく理解する

「常に最新のデータをダッシュボードに表示したい！」

Power BIを活用し始めると、誰もが一度は憧れる「リアルタイム更新」。それを実現する魔法の機能のように見えるのが「DirectQuery（ダイレクトクエリ）」モードです。

しかし、「データを取り込まなくていいから楽そう」という理由だけで安易にDirectQueryを選ぶと、開発の後半で「使いたい関数がエラーになる」「レポートが信じられないほど重い」と頭を抱えることになります。

DirectQueryは、Power BIの中にデータを持つのではなく、「グラフをクリックするたびに、元のデータベースへ直接質問（クエリ）を投げに行く」仕組みです。この記事では、DirectQueryを採用する前に絶対に知っておくべき「5つの厳しい制限事項」と、それを乗り越えるためのプロの設計作法を分かりやすく解説します。

1. 致命的？ 便利なDAX関数が制限される

インポートモードでは自由自在に使えていたDAX関数の一部が、DirectQueryでは突如として使えなくなったり、著しく制限されたりします。

理由はシンプルで、**「元のデータベース（SQLなど）が理解できる言語に翻訳できない計算は実行できない」**からです。

• タイムインテリジェンス関数の制限: SAMEPERIODLASTYEAR（前年同期比）や TOTALYTD（年初来累計）など、日付テーブルを駆使する複雑な関数は、そのままではデータベース側に翻訳して渡すことができず、エラーになるケースが多発します。

• 複雑な反復処理の制限: RANKX（順位付け）や TOPN など、行ごとに複雑な評価を繰り返す処理も、DirectQueryとは非常に相性が悪いです。

【回避策】

Power BI側（DAX）で複雑な計算をするのではなく、あらかじめデータベース側（SQLのビューなど）で前年対比や順位を計算した結果の列を作っておき、Power BIは「それを読み込むだけ」にする設計への転換が必要です。

2. パフォーマンスは「データベースの体力」に完全依存する

DirectQueryモードにおけるレポートの表示速度は、Power BIの性能ではなく**「接続先のデータベースの処理能力」**に100%依存します。

スライサー（絞り込みボタン）を1つクリックするたびに、裏側ではデータベースに対して重い集計クエリが走ります。もしデータベース側のインデックス設計が甘かったり、スペックが低かったりすると、グラフが表示されるまでに数十秒待たされる「使えないダッシュボード」になってしまいます。

さらに恐ろしいのは「同時アクセスによる負荷」です。

月曜日の朝9時に、全社員50人が一斉にレポートを開いて操作したとします。データベースには一瞬で数百の重いクエリが殺到し、最悪の場合は他の業務システムまで巻き込んでダウンさせてしまう危険性があります。

3. Power Queryでのデータ加工（クエリフォールディング）の壁

データのクレンジングを行うPower Queryエディターにも、大きな制限がかかります。

インポートモードなら「列のピボット解除」「複雑な条件分岐」など何でもできますが、DirectQueryの場合は**「データベース側で処理できる形（クエリフォールディング）に変換できるステップ」しか許されません**。

もしデータベース側で解釈できない加工ステップを挟んでしまうと、そこでフォールディング（処理の押し込み）が切れ、意図しない全件データのスキャンが発生してパフォーマンスが崩壊するか、インポートモードへの切り替えを強制されます。

4. 計算列と計算テーブルが作れない・重い

モデリング画面でDAXを使って新しい列を作る「計算列」も、DirectQueryでは要注意です。

インポートモードの計算列は「データ読み込み時」に一度だけ計算されますが、DirectQueryではデータの読み込みという概念がないため、クエリのたびに計算が走り、パフォーマンスを大きく低下させます。

また、CALENDAR 関数などを使ってDAXでカレンダーテーブルを自動生成する「計算テーブル」は、DirectQueryモードの中では作成すること自体ができません（別途インポートモードのテーブルとして追加し、コンポジットモデルにする必要があります）。

5. 行レベルセキュリティ（RLS）の複雑化

「営業担当者には自分の担当エリアのデータしか見せない」といった行レベルセキュリティ（RLS）を設定する場合、DirectQueryではそのセキュリティ条件がそのまま「SQLのWHERE句」としてデータベースに毎度投げられます。

条件式に USERPRINCIPALNAME() などの関数を多用して複雑なRLSを組むと、発行されるクエリも複雑怪奇になり、結果として応答速度の低下を招きます。また、データソース側がPower BIのユーザー情報を正しく解釈できるかどうかの厳密なテストが不可欠になります。

DirectQueryと正しく付き合うための「判断基準」

ここまで制限事項を並べると「DirectQueryは使わない方がいいのでは？」と思われるかもしれません。しかし、以下のような明確な理由がある場合は、強力な武器になります。

重要なのは、**「Power BIだけで何とかしようとしないこと」**です。データベースのインデックスチューニングや、中間ビューの作成など、データ基盤（上流）を含めた全体設計ができなければ、DirectQueryを安定運用することはできません。

まとめ：データモデル設計の「正解」を最短で学ぶために

DirectQueryは、ビジネスの状況をリアルタイムに把握するための素晴らしい機能ですが、その裏にある技術的な制限を理解せずに飛びつくと、大やけどを負うことになります。

「リアルタイム性」と「サクサク動くパフォーマンス」、そして「複雑なDAX計算」。これらをどうバランスよく設計し、時にコンポジットモデル（インポートとDirectQueryの混在）をどう組み上げるか。これは、Power BIにおける最も高度で、最も価値のあるスキルです。

• 「自社のデータ量と要件なら、インポートとDirectQueryのどちらを選ぶべきか自信がない」

• 「現在DirectQueryで作ったレポートが重すぎて、改善の手がかりが掴めない」

• 「クエリフォールディングを意識した正しいPower Queryの書き方を学びたい」

もしこうした壁にぶつかっているなら、独学でデータベースと格闘する時間をショートカットし、プロの設計手法を学んでみませんか？

私たちのPower BI実践セミナーでは、表面的なビジュアルの作り方だけでなく、「裏側のデータモデル設計」「パフォーマンスチューニングの鉄則」「DirectQueryの正しい使い所」など、実務で絶対に外せないコアな技術を体系的にお伝えしています。

▼ 失敗しないデータ基盤設計を身につける

Power BI セミナー 公式ページで詳細を見る