Power BI「他のクエリまたはステップを参照しているため、データ ソースに直接アクセスできません」を一発で直す実務ガイド

Power BIやPower Queryを使っていると、突然こんな冷たいエラーメッセージに出会うことがあります。

「他のクエリまたはステップを参照しているため、データ ソースに直接アクセスできません。このデータの組み合わせを再構築してください。」

初めて見るとギョッとしますが、実は原因と対処のパターンは3つしかありません。
この記事では、現場でそのまま使える「一発で直す実務手順」をまとめます。

🎯この記事のゴール

Power BIで発生する上記エラーを「原因別に切り分け」「安全に再構築」すること。
焦点は3つだけです。

  1. プライバシーレベルの壁（Formula.Firewall）

  2. クエリの参照関係が複雑すぎる構造

  3. 動的なデータソース（パス／URL／サーバー名）

この3つを順番に整理すれば、更新・発行・ゲートウェイ運用まで安定稼働できます。

⏱60秒でわかる診断チェックリスト

まずは、上から順に確認するだけで解決の道筋が見える「簡易診断リスト」です。

1️⃣ 混在ソースか？
　→ 例：SharePoint＋ローカルExcel、SQL＋Webなど。混ざっていればFormula.Firewallの可能性大。

2️⃣ プライバシーレベルを揃える
　→ [ファイル] → [オプションと設定] → [データ ソースの設定] から「組織内」で統一。

3️⃣ 参照関係のねじれを解消する
　→ “A→B→C”のような跨ぎ参照をやめ、ソースごとに分離（stg/ref/fact構成に）。

4️⃣ 動的パスやURLを固定化
　→ File.ContentsやWeb.Contentsのベース部分を変数化しない。RelativePathを活用。

5️⃣ 最後の手段はTable.Buffer
　→ 構造が正しいのに直らない場合のみ。メモリ消費に注意。

原因①：プライバシーレベルの壁（Formula.Firewall）

🔍なにが起きている？

Power Queryは、異なるデータソース間で情報が“漏れないように”制御しています。
この仕組みが「Formula.Firewall」。
たとえば「組織内 × プライベート」のようにレベルが食い違うと、Power BIは結合をブロックします。

🧭直し方（安全順）

A案：すべて同一レベルに揃える
　→ “組織内”で統一（社内データ前提）。公開データなら“公開”で統一。

B案：ソース数を減らす
　→ 例：SharePointサイト内の複数ファイルは「SharePoint.Contents」で1ソースに。

C案：Desktopでの“プライバシー無視”は避ける
　→ 一時的な検証には便利ですが、Serviceで再発します。本番では正攻法で。

原因②：参照関係のねじれ（他クエリを跨いだ結合）

⚡よくある構造

Staging_SQL（SQL）
　↓参照
Clean_SQL

Staging_CSV（SharePoint）
　↓参照
Clean_CSV

Clean_SQL と Clean_CSV をマージ

この構造自体は普通ですが、途中で他クエリをさらに参照したり、
Excel.CurrentWorkbookを混ぜると、評価順が狂い、エラーが発生します。

✅正しい再構築パターン（ステージング方式）

レイヤー 役割 命名例
stg_ 純粋な取り込みのみ（加工なし） stg_SQL_Sales
ref_ 同一ソース内の整形 ref_SQL_Sales
fact_ / dim_ 複数ソースの最終結合 fact_Sales

つまり「stgで壁を作り、refで整え、factで初めて繋ぐ」。
この構造に変えるだけで、9割のエラーが消えます。

原因③：動的データソース（パス・URL・サーバー名）

😱ありがちな落とし穴

File.Contents(Parameter & "/file.csv") // NG：Parameterが他クエリ参照
Web.Contents("https://host/" & [列]) // NG：行データでURL生成

Power Queryはベースのデータソースが静的であることを前提にします。
動的だと、セキュリティ上「別ソース」とみなされてブロックされます。

✅再構築の原則

  • ベース部分は固定し、可変部分はRelativePath/Queryで渡す

  • パラメータは“静的”にManage Parametersで入力

  • フォルダ結合は1ソースに寄せる

例：正しいWeb API呼び出し

Source = Web.Contents(
"https://api.example.com",
[
RelativePath = "v1/orders",
Query = [from="2024-01-01", to="2024-12-31"] ] )

ケース別・一撃レシピ

ケース 原因 対処
A SharePoint＋ローカルExcelのマージ stg_SP / stg_Local に分離し、refで整形→最後に結合。両方「組織内」に。
B Web APIで行ごとにURL生成 ベース固定＋RelativePathで統一。行呼び出しは関数化。
C フォルダ結合＋Excel.CurrentWorkbook併用 各ソースを別レイヤーで完結、最後にだけ結合。
D SQL接続情報をCSVで切替 静的パラメータ化し、環境ごとにPBIXを分ける。

💡Table.Bufferは“最後の一押し”

Table.Bufferは評価の境界をつくり、参照トラブルを抑えますが、

  • メモリ消費大

  • クエリ折りたたみが壊れる
    という副作用があります。

構造を直しても再発する場合のみ、refの末尾で限定的に使用してください。

Power BI Service／ゲートウェイ運用の注意点

  • サービス側でもプライバシー設定を揃える
    　Desktopで動いても、Serviceで資格情報が未設定なら再発します。

  • ゲートウェイで同定義に寄せる
    　同じSQLでも認証方法が違うと別ソース扱いになります。

  • “プライバシー無視”に頼らない
    　本番では「揃える・分ける・固定する」が鉄則です。

🧱再発防止の設計テンプレ

  • stg_ / ref_ / fact_ の3層構成をテンプレ化

  • 各ソースは1つの起点にまとめる（SharePoint.Contentsなど）

  • 接続文字列・URL・パスは静的パラメータで管理

  • 命名規則を統一して参照方向を明確に

  • 混在を避ける（ローカル×SharePointなど）

  • Table.Bufferは最小限・理由をコメントで残す

🧾コピペで使えるチェックリスト

☑ 混在ソースを洗い出した
☑ プライバシーレベルを組織内で統一
☑ stg/ref/fact構成に分離
☑ 他ソース参照は最終クエリのみ
☑ ベースURL／パスを固定化
☑ パラメータを静的化
☑ Table.Buffer使用を最小限に
☑ サービス／ゲートウェイでも設定を整合

まとめ：3ステップで直す

1️⃣ 揃える（プライバシー）
2️⃣ 分ける（stg/ref/fact）
3️⃣ 固定する（ベースURL/パス）

この3つの原則をテンプレ化しておけば、
Power BIの「他のクエリまたはステップを参照しているため…」エラーは怖くありません。

【もし困り事があるなら、まずは無料相談はこちら】
https://powerbiseminar.com/lp/

コンサルサービスの詳細や成功事例なども合わせてご紹介いたします。

社内にデータ活用のノウハウや専門人材が十分いない場合でも、弊社が伴走しながら最短ルートで成果を出せるようサポートいたします。

関連記事

この記事へのコメントはありません。

カテゴリー

アーカイブ

検索