Power BI コンポジットモデル入門：DirectQueryとImportを混ぜて使うときの注意点

「最新データはなるべくリアルタイムで見たい。でも、全部をDirectQueryにすると遅いし、モデルも作りづらい。かといって全部Importにすると更新が間に合わない」
こういう“現実の板挟み”を解決する手段のひとつが、power bi composite model（コンポジットモデル）です。

コンポジットモデルは、ざっくり言うと「同じセマンティックモデル（データモデル）の中で、Import（取り込み）とDirectQuery（ライブ参照）を混ぜる」考え方です。うまく設計できると、

参照マスタはImportで軽快に
巨大な明細や頻繁に変わる事実データはDirectQueryで最新性を確保
必要なら集計テーブルをImportして高速化

といった“いいとこ取り”ができます。
ただし、混ぜれば混ぜるほど落とし穴も増えます。この記事では、入門として押さえておきたい注意点を、できるだけわかりやすく整理します。

ImportとDirectQueryを混ぜると、何が難しくなるのか

Importは、Power BI側にデータを取り込んで圧縮し、メモリ上で計算します。基本的に速いです。
DirectQueryは、可視化のたびに元データベースへクエリを投げ、結果を返してもらいます。最新性は高い一方で、速度は「元データベースの性能」「ネットワーク」「クエリの複雑さ」に強く左右されます。

ここまでは単純ですが、コンポジットモデルでは次の“ねじれ”が起きやすくなります。

フィルターや集計の一部はPower BI側、別の一部はDB側で処理される
テーブル同士の結合が「DBでできる場合」と「Power BI側でやらざるを得ない場合」がある
同じディメンションでも、使われ方によってImportとして動いたりDirectQueryとして動いたりする（後述のDual）
DAX（メジャー）の書き方次第で、DBへ重たいクエリが飛び、体感が一気に悪化する

つまり「速い・最新・自由」のうち、全部を同時に満たすのは難しい、という前提に立つのが大事です。設計で“どれを優先するか”を決めないと、どれも中途半端になりがちです。

2. まず押さえるべき3つの保存モード：Import / DirectQuery / Dual

コンポジットモデルを理解する鍵は、保存モード（ストレージモード）です。

Import

取り込んで保持。速い。更新はスケジュール/手動。

DirectQuery

保持しない（基本はライブ参照）。最新性は高いが、クエリ性能が命。

Dual（デュアル）

ここが混ぜるときの重要ポイントです。Dualは「状況に応じてImportのようにもDirectQueryのようにも振る舞う」モードです。
典型例として、

DirectQueryの事実テーブル（売上明細など）
ImportまたはDualのディメンション（商品、店舗、日付など）

を組み合わせると、フィルターをDB側へ押し込みやすくなり、パフォーマンスが改善することがあります。

ただし、Dualは魔法ではありません。設定を誤ると、想定外のクエリが発生したり、どこで計算されているか把握しづらくなります。入門段階では「まずはディメンションにDualを使う理由が説明できるか」を目安にすると安全です。

3. 失敗しにくい王道パターン（まずはこれで組む）

入門として現場で成功しやすい構成は、次の“スター型”です。

事実（Fact：売上、受注、アクセスログなどの明細）＝DirectQuery
ディメンション（Dim：商品、顧客、店舗、日付、担当者など）＝Import（またはDual）
必要なら「集計Fact（例：日次×店舗×商品カテゴリ）」＝Import

この形が強い理由はシンプルで、

明細はDBに任せる（量が多いから）
マスタはPower BIに持つ（小さいし、スライサー操作が軽い）
よく見る粒度の集計はImportして“近道”を作る

という役割分担が明確だからです。

逆に、最初からやりがちな危険パターンはこれです。

複数の巨大テーブルをDirectQueryにして、Power BI側で複雑なリレーションや多対多を組む
複数の別システム（別DB）をDirectQueryでつないで、モデル上で横断分析しようとする
便利だからと双方向フィルターを多用する

このあたりは、動いたとしても「遅い・不安定・原因が追いにくい」の三重苦になりやすいです。まずは王道に寄せて、必要なところだけ例外を作る方が結果的に早いです。

4. 注意点の本丸：リレーションとフィルター設計

DirectQueryとImportを混ぜるとき、いちばん効くのが“リレーション設計”です。ここでミスると、DBに重たいクエリが飛んだり、Power BI側に無理な結合処理が発生します。

4-1. スター型を基本にする

Factは中心、Dimは周辺。できるだけ一方向のフィルター（Dim → Fact）で済ませます。
多対多や雪だるま（DimがDimにつながる）構造は、コンポジットモデルでは難易度が上がります。

4-2. 双方向フィルターは“最後の手段”

双方向にすると「このフィルターがどこまで伝播して、どのテーブルの絞り込みになっているか」が読みづらくなります。
特にDirectQueryが絡むと、意図しない結合・サブクエリが発生しがちです。
どうしても必要なら、対象を最小範囲に絞り、性能検証してから採用します。

4-3. 高カーディナリティ列（ユニークが多い列）をスライサーに置きすぎない

例えば「明細の伝票番号」「ユーザーIDの完全一致」など、値が膨大な列をスライサーで触らせると、フィルター条件が巨大になり、DBへ投げるクエリが重くなります。
スライサーは、カテゴリや階層（カテゴリ→サブカテゴリ→商品など）で段階的に絞れる形が扱いやすいです。

4-4. “フィルターの持ち方”を意識する（大量の選択が危険）

Importのディメンションで大量の値を選択すると、その条件がDirectQuery側へ渡るときに「長い条件リスト」になりやすいです。
結果として、DB側の最適化が効きにくくなったり、応答が不安定になったりします。

対策としては、

検索で1件選ぶUIに寄せる
そもそも選択肢を階層化して減らす
必要なら“グループ化したキー”を作る

などが有効です。

5. パフォーマンスの落とし穴：DAXとクエリの関係

コンポジットモデルで「作れたけど遅い」を生む最大要因は、メジャー（DAX）がDBへ無理をさせることです。

5-1. 明細に対する反復計算（SUMXなど）は慎重に

DirectQueryの巨大Factに対して、行ごとに計算するようなDAXを書くと、DB側に複雑な計算を押し付けることになりがちです。
可能なら、

DB側（ビューや計算列）で前計算する
粒度を落とした集計テーブル（Import）を作る
DAXは“集計後の計算”に寄せる

という方針が効きます。

5-2. 「まず絞ってから計算」を徹底する

同じ計算でも、先に対象が狭い状態を作ってから集計した方が軽いです。
レポートの導線として、

日付や部門で先に絞らせる
初期表示で全期間・全文細を出さない
“詳細表示”はドリルスルーに逃がす

など、画面設計も性能の一部です。

5-3. “表”ビジュアルに明細を出しすぎない

コンポジットモデルでは「集計は速いが、明細一覧は遅い（または制限に当たりやすい）」が起きやすいです。
明細一覧が必要なら、

ページを分ける（詳細ページ）
必須フィルターを設定する（選ばないと表示しない）
DB側で明細出力用の最適化ビューを作る

などの割り切りが重要です。

5-4. 変換（Power Query）で“折りたたみ”を壊さない

DirectQueryでは、Power Queryの変換が元DBのクエリに変換できる（折りたためる）ほど有利です。
折りたたみが壊れると、

そもそもDirectQueryで許容されない変換になる
あるいは想定外に重たい処理になる

といった問題につながります。
DirectQuery対象のクエリは、変換を最小限にし、できるだけDB側で整形してから取り込むのが安全です。

6. “混ぜ方”の注意点：どこで結合されるかを意識する

コンポジットモデルで重要なのは「結合がどこで行われるか」です。

理想：DB側で結合・集計が完結して返ってくる
危険：Power BI側で大きな中間結果を持って結合しようとする

危険な状態になる典型は、次のようなときです。

別々のデータソースをまたいで分析し、Power BI側で突合せが発生する
多対多、複雑なリレーション、双方向が絡み、DBが素直に最適化できない
ディメンションのフィルター条件が肥大化し、DB側が苦手なクエリ形状になる

実務上のコツは、可能な限り「DirectQueryする元を一つのDWH/DBに寄せる」ことです。分析のための結合は、Power BIではなく、DB側（ビューやデータマート）に寄せた方が、性能も運用も安定しやすいです。

7. 更新と運用：Importが混ざる時点で“更新設計”が必要

「DirectQueryだから更新不要」と思っていると、コンポジットモデルでは痛い目を見ます。Importが1枚でも入れば、そのテーブルの更新が必要です。

7-1. Import側の更新頻度を決める

ディメンションが古いままだと、スライサーに出る選択肢が古い、結合できない、などが起きます。
“最新性が必要なのはFactだけ”とは限りません。マスタも更新要件を整理しましょう。

7-2. ゲートウェイと資格情報の設計

オンプレのDBをDirectQueryするなら、ゲートウェイが実質必須になります。
さらに、

誰の資格情報で接続するか
SSOが必要か
RLSと整合するか

を先に決めておかないと、公開後に「見えるはずの人が見えない」「逆に見えてはいけない人に見える」といった事故につながります。

7-3. “最新×高速”が必要なら、集計Importやハイブリッド的な発想を検討

レポートでよく見る粒度（例：日次、週次、部門別）をImportで持っておき、必要なときだけDirectQueryで明細を見る、という二段構えは非常に効きます。
「普段は速い」「掘ったときは少し待つ」が受け入れられる業務では、体感が大きく改善します。

8. セキュリティ：RLSが絡むときの落とし穴

行レベルセキュリティ（RLS）を使う場合、混在モデルは特に注意が必要です。

Import側：Power BIのモデル内でフィルターが適用される
DirectQuery側：条件がDBクエリに反映される形になりやすい

ここで重要なのは、「Power BIのRLSを設定したから、元DB側のアクセス制御は不要」とは限らないことです。
DirectQueryは元DBに問い合わせる以上、DB側でも適切な権限設計が必要になります。特にSSOやユーザーごとの権限制御を絡める場合は、関係者（DB管理者、セキュリティ担当）と早めに握っておくのが安全です。

また、RLSの条件を複雑にしすぎると、DBへ投げるクエリが複雑になり、性能に影響することがあります。
入門段階では、

RLSはできるだけ単純なキー（部門ID、担当者IDなど）で絞る
権限表（ユーザー×許可キー）をImportで持ち、関係をスター型に寄せる

といった設計が扱いやすいです。

9. 作り方の流れ（迷わないための手順）

最後に、コンポジットモデルを“事故りにくく”作るための流れをまとめます。

1) 要件を3つに分けて決める

最新性が必要な範囲（秒/分/時間/日）
許容できる待ち時間（操作時に何秒までOKか）
同時利用者数とピーク（重くなるタイミング）

2) テーブルを役割で分類する

巨大明細＝DirectQuery候補
小さめマスタ＝Import候補
頻出の集計粒度＝Importの集計テーブル候補

3) まずスター型で組む

Fact（DQ）＋Dim（Import）で一方向フィルターを基本に作る。

4) 重いところを測る

“なんとなく遅い”で対処しない。どのビジュアルが遅いか、どの操作が遅いかを特定する。

5) 改善カードを切る順番を守る

DB側で整形（ビュー、インデックス、集計）
Power Queryの変換を減らす
モデルを単純化（多対多、双方向を減らす）
必要ならDimをDualにする
それでもだめなら集計Importを作る

この順で進めると、「とりあえずDual」「とりあえず双方向」みたいな場当たり対処を減らせます。

10. すぐ使えるチェックリスト（最重要ポイントだけ）

FactはDirectQuery、DimはImport（または必要に応じてDual）を基本にする
多対多、双方向フィルターは最小限にする
高カーディナリティ列をスライサーで乱用しない
DirectQuery対象のPower Query変換は最小限（DB側で整える）
DAXは明細反復を避け、集計後に計算する設計に寄せる
“よく見る粒度”の集計テーブルをImportで持つと体感が改善しやすい
Importが混ざるなら更新設計（頻度、ゲートウェイ、資格情報）が必須
RLSは単純に、DB側権限との整合も含めて設計する

まとめ

power bi composite model（コンポジットモデル）は、DirectQueryとImportを混ぜられるからこそ、現場の要件に寄せた“現実的に強い”モデルを作れます。
一方で、混ぜる＝境界が増える、ということでもあります。境界が増えると「どこで計算しているのか」「どこがボトルネックなのか」が見えづらくなり、設計が崩れた瞬間に遅くなります。

入門としては、まず王道のスター型（FactはDirectQuery、DimはImport）で組み、重い箇所が見えてからDualや集計Importを追加していくのがいちばん安全です。
“混ぜること”が目的ではなく、“速さ・最新性・運用性のバランスを取ること”が目的。ここを忘れなければ、コンポジットモデルは強い武器になります。