LWP | Power Queryのプライバシー設定を目的から理解する
LWP TECHNICAL ARTICLE | 190
Power Queryのプライバシー設定を目的から理解する
Copyright © 2026 LWP 山中 一弘
本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。
記事要約
Power Queryのプライバシー設定は、ファイルを開く権限ではなく、複数のデータソースを組み合わせた際に一方の情報が他方へ意図せず渡ることを防ぐ仕組みです。本記事では、運用ポリシー、データソースの分類、設定の保存範囲という3軸で、Privacy Level、Formula.Firewall、Fast Combine、グローバル設定と現在のブック設定の関係を整理します。
本記事の対象とゴール
ExcelまたはPower BIでPower Queryを使い、複数データソースの結合やプライバシー警告に直面する方を対象とします。画面上の項目名を暗記するのではなく、情報の移動方向と管理責任から安全な設定を判断できることをゴールとします。
このテーマで最も重要なこと
Power Query のプライバシー設定は、画面上の設定項目から理解しようとすると非常に分かりにくい。
理由は単純で、Power Query には次のような設定が別々の場所に存在するからである。
クエリ オプションの「グローバル」
クエリ オプションの「現在のブック」
データ ソース設定
データ ソースごとの Privacy Level
データ ソース設定の「現在のブック」
データ ソース設定の「グローバル アクセス許可」
認証情報
Privacy Level
Fast Combine
Formula.Firewall
しかも「グローバル」「現在のブック」という言葉が複数の場所に登場する。
そのため、
どの設定が何を制御しているのか
が非常に分かりにくい。
しかし、これらをUIからではなく、
Power Query は、そもそも何を防ごうとしているのか
という目的から逆算すると、全体像はかなり整理できる。
1. Power Query のプライバシー機能は何を防ぐためのものか
最初に理解するべきなのは、
Power Query のプライバシー機能は、複数のデータソースを組み合わせたとき、一方のデータソースの情報が、もう一方のデータソースへ意図せず送信されることを防ぐための仕組み
であるということ。
これは「誰がファイルを開けるか」というアクセス制御とは違う。
また、「誰がデータベースへログインできるか」という認証の話とも違う。
問題になるのは、
あるデータソースから取得した値を、別のデータソースへの問い合わせ条件として送信してしまうこと
である。
2. なぜ「データを結合するだけ」で情報漏えいが起こり得るのか
例えば、次の二つのデータソースがあるとする。
データソースA社内Excel / 社内DB 社員ID001002003そして、
データソースB外部のWeb API / 外部DBこれらをPower Queryで結合する。
利用者の頭の中では、
Aからデータを取得 ↓Bからデータを取得 ↓自分のPC上で結合という処理を想像しやすい。
しかし、Power Query は処理を高速化するために、処理の一部をデータソース側へ押し戻すことがある。
これがクエリフォールディングである。
その結果、概念的には、
社内データ001002003 ↓「この3件だけ検索してください」 ↓外部データソースという処理になる可能性がある。
つまり、
社内側の情報が、外部データソースへの問い合わせ条件として送信される
可能性がある。
これがPower Query のPrivacy機能が警戒していること。
3. 問題は「複数データソース」そのものではない
ここは非常に重要。
Power Query のPrivacy機能は、
複数のデータソースを使うこと自体を禁止する
ものではない。
例えば、
Public+Publicなら問題になりにくい。
また、
Organizational+Organizationalも適切に設定されていれば組み合わせることができる。
問題になるのは、
一方のデータが、より公開範囲の広いデータソースへ流れる可能性
である。
したがって、
複数データソース ↓即エラーではない。
より正確には、
複数データソース ↓ソース間でデータが移動する可能性 ↓Privacy Firewall が評価である。
4. 一つのデータソースでは、なぜ問題が起こりにくいのか
一つのデータソースしか使っていない場合、
Source A ↓Filter ↓Group ↓Join ↓Aggregateなどを行っても、処理は基本的に同じデータソース内部に閉じる。
Power Query がクエリフォールディングしても、
Aの情報 ↓Aへ送るだけである。
つまり、
別のデータソースへ情報が漏れる
という問題がそもそも発生しない。
そのためPrivacy Firewallの必要性が表面化するのは、多くの場合、
複数の異なるデータソースを組み合わせたとき
である。
5. 最初に理解するべき3つの問い
Power Query のプライバシー設定は、実は三つの異なる問題を解いている。
問い1
Privacy Firewall を使うのか？
これを決めるのが、
クエリ オプション
グローバル
現在のブック
である。
問い2
各データソースは、どれくらい機密なのか？
これを決めるのが、
データ ソース設定
Privacy Level
である。
問い3
そのデータソースの設定を、このブックだけで使うのか、それともExcel全体で再利用するのか？
これを決めるのが、
データ ソース設定
現在のブック
グローバル アクセス許可
である。
6. 全体を先に一枚で整理する
| レイヤー | 設定場所 | 何を決めるか |
|---|---|---|
| 1 | Query Options / Global | Privacy機能の運用方針 |
| 2 | Query Options / Current Workbook | このブックでPrivacyを守るか |
| 3 | Data Source Settings / Privacy Level | 各データソースの機密区分 |
| 4 | Data Source Settings / Current Workbook / Global Permissions | その接続設定をどの範囲で保存・再利用するか |
これを先に理解すると、UIの各設定が別々に存在する理由が分かる。
7. クエリ オプションは「Privacyをどう運用するか」
まず、
データ↓データの取得↓クエリ オプション↓プライバシーにある設定。
ここで決めているのは、
各データソースに設定されたPrivacy Levelを、Power Queryが実際のクエリ評価時に考慮するか
である。
重要なのは、
ここではPrivacy Levelそのものを設定しているわけではない
ということ。
8. クエリ オプションの「グローバル」
グローバル設定には概念的に三つの運用方針がある。
常にPrivacy Levelに従う
意味は、
Excel全体として、Privacy保護を強制する。
各ブック側で無効にしようとしても、グローバル方針を優先する。
概念的には、
Excel全体 ↓Privacy Firewallを必ず使うである。
各ブックの設定に従う
意味は、
Excel全体では判断せず、それぞれのブックに判断させる。
概念的には、
Excel全体 ↓ブックごとに判断である。
これがあるため、
現在のブック
という設定が必要になる。
常にPrivacy Levelを無視する
意味は、
Excel全体として、Privacy Levelをクエリ評価に使わない。
いわゆるFast Combine側の考え方になる。
概念的には、
Excel全体 ↓Privacy Firewallによるソース分離を行わないである。
9. 現在のブックの設定
グローバル設定が、
各ブックの設定に従うとなっている場合、
現在のブック側の設定が意味を持つ。
概念的には二択になる。
Privacy Levelに従う
このブック ↓各データソースのPrivacy Levelを考慮するPrivacy Levelを無視する
このブック ↓Privacy Levelを考慮せず結合するつまりFast Combineの考え方。
10. グローバルと現在のブックの関係
概念的な優先関係は次のように整理できる。
| グローバル方針 | ブック側：従う | ブック側：無視 |
|---|---|---|
| 常にPrivacyを守る | 守る | 守る |
| ブックごとに判断 | 守る | 無視 |
| 常にPrivacyを無視 | 無視 | 無視 |
つまり、
ブック側の設定が本当に意味を持つのは、グローバル側が「ブックごとに判断」になっているとき
と考えるとよい。
11. クエリ オプションの「グローバル」は何を意味するか
ここでのグローバルは、
Excel全体の実行ポリシー
である。
言い換えると、
「Privacy Firewallをどのような方針で運用するか」
というルール。
後述する「グローバル アクセス許可」とは全く違う。
この二つを混同すると理解できなくなる。
12. データ ソース設定は「各接続先は何者なのか」
次に、
データ↓データの取得↓データ ソースの設定を見る。
ここでは、
個々のデータソースについての情報
を管理する。
例えば、
SQL Server
SharePoint
Web
Excelファイル
CSV
OData
Access
その他の接続先
など。
13. データソースには「識別」がある
Power Query は、単に、
SQL Serverという種類だけで管理しているわけではない。
概念的には、
データソースの種類+データソースの場所で接続先を識別する。
例えば、
SQL ServerServerADatabaseAあるいは、
Webhttps://example.com/など。
つまり、
どこまでを同じデータソースとして扱うか
という境界が存在する。
これはPrivacy Levelや認証情報の適用範囲にも関係する。
14. Privacy Levelは「そのソースの機密区分」
各データソースにはPrivacy Levelを設定できる。
代表的には、
Private
Organizational
Public
None
である。
15. Public
概念的には、
外部へ流れても問題ない情報
である。
例えば、
公開Webサイト
公開統計
公開API
一般公開されている価格情報
など。
Publicデータを他のデータソースへ送ることは比較的安全。
16. Organizational
概念的には、
組織内部であれば共有してよい情報
である。
例えば、
社内SharePoint
社内SQL
社内業務システム
社内ファイルサーバー
など。
Publicより保護されるが、組織内の同等レベルのソース間では情報移動を許容できる。
17. Private
概念的には、
そのデータソースから得た情報を、他のデータソースへ流してはいけない
という最も厳しい区分。
例えば、
特に機微な個人情報
極秘データ
他ソースへの転送を避けたい情報
など。
重要なのは、
Privateは「アクセスできる人が少ない」
という意味ではない。
Power QueryのPrivacy Levelとしては、
そのデータを他のデータソースへ流してよいか
という意味合いが重要。
18. None
Noneは、
第4の機密レベル
と単純に考えない方がよい。
概念的には、
このデータソースについてPrivacy分類を設定しない
という扱いに近い。
したがって、
PublicOrganizationalPrivateNoneを単純な4段階の序列として並べるより、
PrivateOrganizationalPublic ＋ Noneと考えた方がよい。
19. Privacy Levelは「アクセス権」ではない
ここは記事で強調したい。
Privacy Levelの名前は、
PrivateOrganizationalPublicなので、
誰が閲覧できるのか
というアクセス制御のように見える。
しかしPower Queryの文脈では、
そのデータソースから取得した情報を、別のデータソースへどこまで流してよいか
と考えた方が理解しやすい。
20. 認証とPrivacyは別問題
データ ソース設定には認証情報も存在する。
例えば、
Windows
Microsoftアカウント
組織アカウント
Basic
Anonymous
OAuth
など。
これは、
そのデータソースへアクセスしてよいか
の問題。
一方、Privacy Levelは、
取得した情報をどこへ流してよいか
の問題。
整理すると、
認証↓このデータソースに入ってよいか？ Privacy↓取得した情報を別ソースへ流してよいか？である。
完全に別の問題。
21. Privacy Levelの方向性
Privacy Levelを情報の流れる方向として見ると理解しやすい。
概念的には、
Public ↓Organizational ↓Privateという、
より公開された情報から、より閉じた環境へ持ち込む
方向は安全になりやすい。
逆に、
Private ↓Organizational ↓Publicという、
より機密な情報を、より公開されたソースへ出す
方向が問題になる。
22. 情報移動の概念マトリックス
Privacy保護を有効にしている場合、考え方としては次のように整理できる。
| 情報の出元 ↓ / 送り先 → | Private | Organizational | Public |
|---|---|---|---|
| Private | 制限される | 制限される | 制限される |
| Organizational | 許容され得る | 許容される | 制限される |
| Public | 許容される | 許容される | 許容される |
ここで注意したいのは、
制限される = その二つのデータを絶対に結合できない
ではないということ。
23. Privacy Firewallは「結合禁止装置」ではない
Privacy Firewallの目的は、
危険な方向へデータが送信されることを防ぐ
こと。
したがって、
Private+Publicという組み合わせが存在したからといって、
即座に、
結合禁止となるわけではない。
Power Queryは、安全な方法で評価できるなら、
処理を分離する
データをバッファする
ローカル側で処理する
クエリフォールディングを制限する
などを行う。
24. Formula.Firewallとは何か
Formula.Firewallは、
複数データソースを使ったから発生した
という単純なエラーではない。
より正確には、
Power Query がPrivacy境界を守ったまま、安全にクエリを評価できないと判断した
ときに発生するものと考える。
概念的には、
複数ソース ↓Privacy境界を評価 ↓安全な方法で分離できる？ ↓YES ↓処理続行 NO ↓Formula.Firewallとなる。
25. クエリフォールディングとの関係
Privacyが重要になる理由の一つが、クエリフォールディング。
Power Queryは、
FilterGroupJoinAggregateなどの処理を、自分で全部実行するとは限らない。
可能であれば、
SQL ServerWeb APIODataなどのデータソース側に処理を委譲する。
これは性能上非常に有利。
例えば、
SQL Serverに1000万行ある場合、
Power Queryが全部取得してから絞るより、
SELECT ...WHERE ...としてサーバー側で必要な100行だけ返してもらう方が圧倒的に速い。
26. Privacyとパフォーマンスのトレードオフ
Privacy Firewallが、
この条件を外部ソースへ送ってはいけない
と判断すると、
本来フォールディングできた処理をローカル側へ戻す可能性がある。
すると、
本来1000万行↓サーバー側で100行へ絞る↓100行取得だったものが、
1000万行↓大量取得↓ローカル側で処理になる可能性がある。
そのため、
Privacy保護とクエリパフォーマンスにはトレードオフが存在する
場合がある。
27. Fast Combineとは何か
Fast Combineは概念的には、
各データソースのPrivacy Levelによる分離を行わず、Power Queryに最適化を許す
という考え方。
その結果、
クエリフォールディングしやすい
パフォーマンスが改善する可能性がある
Formula.Firewallを避けられる場合がある
一方で、
一方のソースの情報が、もう一方へ送信される可能性
を利用者自身が管理する必要がある。
したがって、
速いから常にFast Combine
という考え方ではなく、
データフローを自分で把握して安全だと判断できる場合に使う
という位置づけがよい。
28. 「現在のブックでPrivacyを無視する」の意味
例えば、
社内SQL+社内SharePoint+社内Excelしか使っていないブックがある。
しかも設計者自身が、
このブックでは外部ソースへ機密情報を渡す処理はない
と保証できる。
この場合、
現在のブック↓Privacy Levelを無視とする判断はあり得る。
重要なのは、
Excel全体のPrivacy機能を殺しているわけではない
という点。
そのブックだけ、
このブックのデータフローについては設計者が責任を持つ
という設定になる。
29. グローバルでPrivacyを無視する場合
グローバル側で、
常にPrivacy Levelを無視するとすると、
今後作る別のブックも含めてPrivacy Firewallが機能しなくなる。
例えば将来、
社内機密DB+外部Web APIというブックを作っても、
Privacy保護が働かない可能性がある。
そのため、
グローバルで無効化する方が影響範囲は大きい
と考えるべき。
30. 実務上の運用案
一つの合理的な考え方として、
グローバル↓各ブックの設定に従うとしておき、
安全性を確認した特定ブックだけ、
現在のブック↓Privacy Levelを無視とする。
これなら、
Excel全体の安全装置を無効化するのではなく、
このブックだけ例外にできる。
31. そしてもう一つの「グローバル」が出てくる
Power Query がさらに分かりにくい理由がここにある。
データ ソース設定を開くと、
現在のブックグローバル アクセス許可というタブがある。
これは、
Query Options↓Globalとは意味が違う。
同じ「グローバル」という言葉だが、役割は全く別。
32. Query Options の Global
これは、
Excel全体のPrivacy実行ポリシー
である。
つまり、
Privacyを強制する？ブックに任せる？無視する？を決める。
33. Data Source Settings の Global Permissions
こちらは、
データソースごとの接続設定を、他のブックでも再利用できる範囲で保持する
という意味。
例えば、
SQL Server Aについて、
認証方式
ユーザー情報
Privacy Level
接続先
などをExcel側が記憶する。
その設定を、
このブックだけで使うのか、
他のブックでも共通利用するのか。
そのスコープが、
Current Workbook
Global Permissions
である。
34. 同じ「グローバル」でも意味が違う
これを表にすると非常に重要。
| 表示 | 意味 |
|---|---|
| Query Options / Global | Excel全体のPrivacy動作方針 |
| Data Source Settings / Global Permissions | 接続先ごとの設定をExcel全体で再利用 |
つまり、
Query Options / Global= ポリシーのスコープ Data Source Settings / Global Permissions= データソース設定のスコープである。
ここを混同すると全体が理解できなくなる。
35. 「現在のブック」も二種類ある
同様に、
Current Workbookも二種類存在する。
Query Options / Current Workbook
意味：
このブックではPrivacy Firewallを使うか。
Data Source Settings / Current Workbook
意味：
このブック内で使われているデータソース設定を管理する。
この二つも役割が違う。
36. 4つを並べると理解しやすい
| 設定場所 | スコープ | 対象 | 意味 |
|---|---|---|---|
| Query Options / Global | Excel全体 | Privacy実行方針 | 守る・ブック任せ・無視 |
| Query Options / Current Workbook | 1ブック | Privacy実行方針 | 守る・無視 |
| Data Source Settings / Current Workbook | 1ブック | データソース設定 | 接続・認証・Privacy |
| Data Source Settings / Global Permissions | Excel全体 | データソース設定 | 接続・認証・Privacyを再利用 |
この表は記事の中心資料として使える。
37. 「ポリシー」と「分類」を分ける
さらに簡潔にすると、
Query Options↓ルールを適用するか？に対して、
Data Source Settings↓各データは何者か？である。
具体的には、
Query Options= Privacyポリシー Data Source Settings= データ分類と考える。
38. さらに「保存範囲」という第三軸
ここに、
Current WorkbookGlobal Permissionsが加わる。
つまりPower QueryのPrivacy設定を理解するためには、
ポリシー
分類
スコープ
の3軸で考えるとよい。
39. 3軸モデル
軸1：ポリシー
Privacyを守る？無視する？ブックに任せる？軸2：分類
PrivateOrganizationalPublicNone軸3：スコープ
Current WorkbookGlobalこれがPower Queryのプライバシー設定全体の骨格。
40. 一連の処理として考える
Power Query が実際に判断する流れを概念化すると、次のようになる。
① クエリを評価する ↓② 複数のデータソースが関係する ↓③ Privacyポリシーは有効か？ ↓NO ↓Fast CombinePrivacy Levelを考慮せず最適化 YES ↓④ 各データソースのPrivacy Levelを見る ↓PrivateOrganizationalPublic ↓⑤ データがどちらからどちらへ流れる可能性があるか ↓⑥ Privacy境界に違反しないか ↓安全 ↓フォールディング等を許可 危険 ↓分離 / バッファリング / ローカル処理 ↓それでも安全に評価できない ↓Formula.Firewallこの流れが最も本質的。
41. 設定マトリックスの考え方
設定を整理する場合、
二種類のマトリックスを作るとよい。
マトリックスA：Privacy運用ポリシー
| Global Query Option | Workbook: Respect | Workbook: Ignore |
|---|---|---|
| Always Respect | Respect | Respect |
| Workbook Controlled | Respect | Ignore |
| Always Ignore | Ignore | Ignore |
これは、
Privacy Levelを実際に評価するか
を示す。
42. マトリックスB：Privacy Level間の情報移動
| From ↓ / To → | Private | Organizational | Public |
|---|---|---|---|
| Private | 制限 | 制限 | 制限 |
| Organizational | 許容され得る | 許容 | 制限 |
| Public | 許容 | 許容 | 許容 |
こちらは、
Privacy Levelを評価すると決まった後で、どの方向への情報移動を許すか
を示す。
この二つのマトリックスは別物。
43. 二つのマトリックスを混ぜない
非常に重要。
まず、
Privacyを評価する？を決める。
その後に、
評価するなら、各ソースのPrivacy Levelは？を見る。
つまり、
Query Options ↓Privacyを使うか ↓Data Source Privacy Levels ↓どう情報を流してよいかという順番。
44. 典型例1：Public + Public
公開Web+公開API両方Public。
Privacyを有効にしていても、
Public → Publicなので基本的に問題になりにくい。
45. 典型例2：Public → Organizational
例えば、
公開為替レート ↓社内売上DB公開情報を社内側で使う。
これは、
公開情報がより閉じた領域へ入る
方向なので比較的安全。
46. 典型例3：Organizational → Public
例えば、
社内顧客ID ↓外部Web APIこれは、
組織内データを公開範囲のデータソースへ送る
可能性がある。
Privacy Firewallが警戒する典型例。
47. 典型例4：Private + Public
例えば、
機微な個人情報+公開Webこの場合、
Private側の値をPublic側へ問い合わせ条件として送らないようにする必要がある。
そのため、
フォールディング制限
バッファリング
ローカル処理
Formula.Firewall
などが起こり得る。
48. 典型例5：すべて社内ソースで設計者が管理
例えば、
社内SQL+社内SharePoint+社内Excelかつ、
すべて信頼できる
送信先も組織内部
クエリ設計を理解している
外部Webソースを利用しない
という場合、
ブック単位でFast Combineを選ぶ合理性はある。
ただし、
安全性をPower Queryに判定してもらうのではなく、設計者自身が保証する
ことになる。
49. 「何も考えずPrivacyを無効化」は避ける
Privacy機能は確かに、
パフォーマンス
Formula.Firewall
クエリ設計
の面で邪魔に見えることがある。
しかし、
なぜ存在しているか
を理解せずに無効化すると危険。
まず確認するべきなのは、
このクエリで、一方のデータソースの値がもう一方へ送信されても問題ないか？である。
50. Privacy設定を判断する実務フロー
このクエリは複数データソースを使うか？ ↓NO ↓Privacyによるソース間漏えいは問題になりにくい YES ↓一方のソースの値が、もう一方への問い合わせに使われる可能性があるか？ ↓NO / 問題ないと保証できる ↓Fast Combineを検討 YES / 分からない ↓Privacyを有効 ↓各データソースに適切なPrivacy Levelを設定51. 「分からないなら有効」が基本
Privacy機能は、
データフローを完全に理解していない利用者
を保護する意味もある。
特に、
外部Web API
社内機密DB
個人情報
クラウドサービス
外部ベンダー環境
などを混在させる場合、
安易に無効化しない方がよい。
52. 「自分で制御できるなら無効化」の意味
逆に、
データソースが明確
データの流れを理解している
外部送信がない
全ソースが同一の信頼境界内
パフォーマンスを優先したい
という場合、
ブック単位でPrivacyを無視することには合理性がある。
ここでも重要なのは、
ブック単位
という点。
53. グローバル無効化とブック単位無効化の違い
グローバル無効化
すべてのブック↓Privacy無視影響範囲が大きい。
ブック単位無効化
このブックだけ↓Privacy無視影響範囲を限定できる。
実務では、
グローバルはブックごとに判断する設定にして、必要なブックのみFast Combine
という設計が理解しやすい。
54. なぜ設定がこんなに分かれているのか
Power QueryのUIだけ見ると、
なぜこんなに設定を分ける必要があるのか
と思える。
しかし目的から見ると、それぞれ役割が違う。
Query Options
Power Queryの動作方針。
Privacyを使うか？Data Source Privacy Level
各データソースの分類。
このソースはどれくらい機密か？Data Source Permissions
接続情報とその保存範囲。
このソースへどう接続するか？その設定をどこまで再利用するか？この3つは本来別問題なので、別設定になっている。
55. UIではなく「設計図」で考える
全体は次のように考えるとよい。
┌──────────────────────────┐│ Query Options ││ ││ Privacy機能を使うか？ │└────────────┬─────────────┘ │ ▼┌──────────────────────────┐│ Data Source Settings ││ ││ Source A = Private ││ Source B = Public ││ Source C = Organizational│└────────────┬─────────────┘ │ ▼┌──────────────────────────┐│ Privacy Firewall ││ ││ A → B は安全か？ ││ B → C は安全か？ │└────────────┬─────────────┘ │ ▼┌──────────────────────────┐│ Query Evaluation ││ ││ Folding ││ Buffering ││ Local Processing ││ Formula.Firewall │└──────────────────────────┘56. さらにアクセス許可を加える
データソース自体には、
Source A├─ 接続先├─ 認証方式├─ 資格情報└─ Privacy Levelがある。
そして、それを、
このブックだけに保持するのか、
グローバルに再利用するのか。
という別のスコープが存在する。
57. 最終的な3層モデル
最終的には次の3層で説明するとよい。
第1層：ポリシー
Privacyを使うか。
設定場所：
Query Options第2層：分類
各データソースはどれくらい保護すべきか。
設定場所：
Data Source Settings→ Privacy Level第3層：保存・再利用範囲
そのデータソース設定をどこまで使うか。
設定場所：
Current WorkbookGlobal Permissions58. この3層を一言で表す
Policy↓Classification↓Scope日本語なら、
運用方針↓データ分類↓設定の適用範囲である。
これがPower Query Privacy設定を理解する最も整理されたモデルの一つ。
59. よくある誤解
誤解1
複数データソースを使うとエラーになる。
正しくは、
複数データソース間で危険な情報移動が起きないか評価される。
誤解2
Privacy Levelは閲覧権限。
正しくは、
Power Query内でデータを他ソースへどこまで流してよいかを判断する分類。
誤解3
Privateなら安全。
Privateを設定しても、Privacy Levelをグローバルまたはブックで無視していれば、その分類はクエリ評価に使われない。
誤解4
NoneとFast Combineは同じ。
違う。
Noneは、
特定データソースにPrivacy分類を持たせない
という話。
Fast Combineは、
クエリ評価時にPrivacy Levelを考慮しない
という話。
誤解5
グローバルは一種類。
違う。
Query Options / Globalと、
Data Source Settings / Global Permissionsは別物。
60. None と Fast Combine の違い
これは記事で一節作ってもよい。
None
対象：
1つのデータソース意味：
このデータソースのPrivacy分類を設定しないFast Combine
対象：
クエリ評価全体意味：
複数データソースのPrivacy境界を考慮しないつまり、
None = データソース側の分類
Fast Combine = クエリエンジン側の評価方針
である。
61. 「グローバル」と「現在のブック」も2種類ある
これも表で整理するとよい。
| 言葉 | 場所 | 意味 |
|---|---|---|
| Global | Query Options | Excel全体のPrivacyポリシー |
| Current Workbook | Query Options | このブックのPrivacyポリシー |
| Global Permissions | Data Source Settings | データソース設定を全ブックで再利用 |
| Current Workbook | Data Source Settings | このブックのデータソース設定 |
同じ言葉が別の概念に使われることが、混乱の大きな原因。
62. ここでは説明の順番が非常に重要
このテーマはUI順に説明しない方がよい。
悪い順番：
まずQuery Optionsを開きます↓次にGlobalがあります↓Current Workbookがあります↓Data Source Settingsがありますこれでは読者は、
何のために設定しているのか
を理解できない。
63. 推奨する説明順
ここでは次の順番がよい。
なぜPrivacyが必要なのか
複数ソース間での情報漏えい。
なぜ単純なMergeでも漏れる可能性があるのか
クエリフォールディング。
Power Queryは何を判断する必要があるのか
Privacyを使う？各ソースは何者？設定をどこまで使う？Query Options
ポリシー。
Data Source Privacy Level
分類。
Current Workbook / Global Permissions
設定のスコープ。
マトリックス
設定の組み合わせ。
Fast Combine
安全性と性能のトレードオフ。
Formula.Firewall
仕組みが分かればエラーの意味も理解できる。
64. 最終的な理解モデル
Power Query のPrivacy設定を最終的に一枚で表現すると、
【目的】異なるデータソース間で意図しない情報漏えいを防ぐ ↓【ポリシー】Query OptionsPrivacy機能を使うか ↓【分類】Data Source Privacy LevelPrivate / Organizational / Public ↓【評価】Privacy Firewallどちらからどちらへ情報を流せるか ↓【実行】Folding / Buffering / Local Processing ↓【失敗した場合】Formula.Firewallさらにその横に、
【設定の保存範囲】Current WorkbookGlobal Permissionsがある。
これがPower Query のPrivacy設定全体。
65. 最後に押さえたいこと
Power Query のPrivacy設定が難しいのは、機能が無意味に複雑だからではない。
実際には、
何を守るか
どのソースをどの程度信頼するか
その判断をどこまで適用するか
という、本来別の問題を別々に設定している。
UI上ではそれが断片的に見えるため分かりにくい。
しかし、
目的↓ポリシー↓データ分類↓適用範囲↓Privacy Firewall↓クエリ実行という流れで理解すると、各設定にはそれぞれ明確な存在理由がある。
そして実務上最も重要なのは、
Privacy機能を無効にするかどうかを先に決めるのではなく、「このクエリでは、あるデータソースの情報が別のデータソースへ送られても安全なのか」を先に判断すること。
そこが分かれば、
Privacyを有効にするべきブック
Fast Combineを使ってよいブック
Privateにするべきソース
Organizationalで十分なソース
Publicとして扱えるソース
グローバル設定にするべきもの
ブック単位で限定するべきもの
を、設定画面の暗記ではなく、意味に基づいて判断できるようになる。
出典メモ
本記事は、ほえほえ作成のPower Queryプライバシー設定整理原稿をもとに再構成しました。画面名や選択肢はExcel、Power BI Desktop、更新時期によって異なる場合があります。実運用では、組織の情報管理規程と各データソースの管理者方針を優先してください。
参考: Microsoft Learn: Privacy levels in Power Query（https://learn.microsoft.com/en-us/power-query/privacy-levels）、Microsoft Learn: Behind the scenes of the Data Privacy Firewall（https://learn.microsoft.com/en-us/power-query/data-privacy-firewall）