Power Queryで相対パスを使うときのプライバシーレベルを考える

本資料は、出典を明記いただければ、商用・非商用を問わず、ご自由に複製・改変・再配布していただけます。なお、著作権表示は改変せず、そのまま記載してご利用くださいますようお願いいたします。

記事要約

Power Queryで相対パスを使うと便利ですが、プライバシーレベルとの関係を理解しないまま使うと、思わぬ情報漏えいリスクを見落とすことがあります。この記事では、Togetter/Posfieの議論と、参照されていた風柳メモの記事をもとに、相対パス、名前定義、テーブル経由、ローカルファイル、ネットワークドライブ、外部DBの組み合わせを整理します。

本記事の対象とゴール

対象は、Power QueryでCSVやExcelファイルを読み込み、別のデータソースと結合する人です。特に、相対パスを使うためにプライバシーレベルのチェックを無効化してよいのか迷っている人を想定します。

ゴールは、相対パスそのものが危険なのではなく、「機微なデータを外部データソースと結合するときに、Power Queryがどこまで情報を相手側へ渡す可能性があるか」を考えられるようにすることです。

先に結論

相対パスを使うために、必ずプライバシーレベルのチェックを無効化しなければならない、とは限りません。議論では、名前定義やテーブル経由でパスを渡す方法、ローカルファイルとネットワークドライブの違い、プライバシーレベルを「組織」にすることで動いた例が出ていました。

ただし、プライバシーレベルは邪魔な警告ではありません。複数のデータソースを結合するときに、片方のデータから得た値がもう片方のデータソースへの問い合わせ条件として渡ることを防ぐための仕組みです。

1. 相対パスは配布しやすいが注意が要る

Power Queryで相対パスを使うと、ブックとデータファイルを同じフォルダー構成で配布しやすくなります。しかし、Power Queryにはプライバシーレベルの考え方があり、複数ソースを組み合わせると制限に当たることがあります。

2. プライバシーレベルはデータの混在を守る仕組み

プライバシーレベルは、別々のデータソース間で意図せず情報が渡ることを防ぐ仕組みです。ローカルファイル、Web、社内データベースを組み合わせるとき、Power Queryはデータの流れを制限する場合があります。

相対パスの問題に見えても、実際には「どのソースとどのソースを組み合わせているか」が原因であることがあります。

3. 実務では設定と説明を残す

配布用ブックでは、フォルダー構成、設定セル、クエリ名、プライバシーレベルの扱いを説明に残します。利用者がファイルだけ移動して壊すことを防ぐためです。

何が問題になるのか

問題になるのは、Power Queryが複数のデータソースをまたいで最適化するときです。例えば、社内のCSVにある社員番号や給与区分を使って、外部または別管理のDBへ問い合わせるような処理を考えます。

Power Queryが処理を効率化するために、CSV側の値をDB側の WHERE 条件へ押し込むと、DB管理者やログから本来見せたくない値が見える可能性があります。議論では、すべてをパブリックにするとwhere句に内部情報が入る一方、ローカルファイル側を組織にするとwhere句が付かない、というログ確認の話が出ていました。

相対パス指定とプライバシーレベル

相対パス指定には、少なくとも次のような経路があります。

Excelの名前定義にパスを持たせる。
シート上のテーブルにパスを持たせ、Power Queryで参照する。
Power Query内で現在ブックの場所を取得し、そこから相対的にファイルを探す。

議論では、名前定義経由のほうがセキュリティ的には緩いように見える、テーブル経由では設定の扱いが変わる、ローカルドライブのファイルではプライバシーレベルを設定しなくても読める場合がある、ネットワークドライブでは設定が必要になる、という観察が出ています。

ここから分かるのは、相対パス指定は単なる文字列操作ではなく、Power Queryが「どのデータソースにアクセスしている」と認識するかに影響するということです。

実務上のリスクをどう見るか

実務では、すべての相対パス利用が危険というわけではありません。ローカルに置いた同一形式のCSVを読み替えるだけなら、問題になる余地は小さい場面が多いでしょう。

一方で、次のようなケースでは注意が必要です。

給与、人事、総務、取引条件などの機微データを含むファイルを読む。
そのデータを、社内DB、クラウドDB、外部Web APIなど別のデータソースと結合する。
DB側のログにSQLや検索条件が残る。
データソースごとの閲覧権限や管理者が異なる。

この場合、Power Queryのプライバシーレベルは、単なる操作上の制約ではなく、情報の混ざり方を制御する安全装置として扱うべきです。

「組織」「パブリック」「プライベート」をどう考えるか

Power Queryのプライバシーレベルは、データソース間で情報をどこまで混ぜてよいかを示す分類です。

パブリックは、外へ出てもよい公開情報に近い扱いです。組織は、同じ組織内では共有してよいが、外部へは出したくない情報です。プライベートは、他のデータソースと安易に混ぜたくない機微情報です。

相対パスを使うと、対象ファイルが静的に決まらないため、Power Queryがプライバシーレベルを厳密に扱いにくくなる場合があります。だからこそ、チェックを無効にするのではなく、どのデータソースをどのレベルに置くのが妥当かを考える必要があります。

回避策として考えられる設計

安全寄りに設計するなら、機微なファイルを直接外部DBと結合しない形にします。

例えば、機微CSVをいったんExcelテーブルとして読み込み、そのテーブルに対する別クエリを作る方法が考えられます。これで必ず安全になると断定はできませんが、少なくとも「どの段階で外部データソースと結合するか」を明示できます。

また、外部DBに問い合わせる前に必要なキーを丸める、集計済みの値だけを渡す、DB側に内部情報が残らないようにクエリ診断やDBログで確認する、という確認も有効です。

まとめ

Power Queryの相対パスは便利です。しかし、複数データソースを結合する場合、便利さだけで判断してプライバシーレベルのチェックを無効化するのは危険です。相対パスを使うかどうかより、どのデータがどのデータソースへ渡り得るのかを考えることが重要です。

ローカルCSVを読み替えるだけなら実務上問題になりにくい場面もあります。一方で、人事・給与・総務のような機微データとDBや外部APIを結合する場合は、プライバシーレベルを設計の一部として扱うべきです。

出典メモ- 元Togetter URL: https://togetter.com/li/1832932

正規Posfie URL: https://posfie.com/@hoehoe1234/p/ExcnwqW
取得日: 2026-06-12
投稿者: ほえほえ＠マクロ師のひとりごとDX @hoehoe1234 ほか、会話参加者
素材として使った範囲: 投稿本文、投稿中の手順説明、リンク先として明示されている参考記事、取得できた画像の目視確認結果
画像確認: 投稿本文と参照リンクを確認した。X側の動的表示制約により本文画像ファイルは取得できなかったため、本文では投稿本文、会話で示されたログ確認内容、参照記事の要旨をもとに再構成した。
注意: 投稿本文は記事素材として要約・再構成し、長文転載ではなく、Power Query学習記事として補足説明を加えた。