序
Power BI Desktop で作成したレポートの内、SharePoint リストをデータソースにしているものがあるとします。
そのレポートのデータソースを、今度は別の SharePoint サイトに作成した同じ構造のリストへ切り替えたいということがあった時、単純な「データソースの切り替え」だけでは上手く行かないことがあります（※以下の画像は取り込もうとした結果）
お引っ越し先の SharePoint リストは、旧リストをベースに「既存のリスト」から複製しているため、基本的な列構成は同じです。それでも、データソース設定から正しい手順で再接続をしたつもりが、上の画像のように取り込めない時の対処方法をまとめました。
1. 前提
今回の前提を箇条にすると以下の通りです：
- Power BI Desktop から SharePoint リストに接続している
- 接続元の SharePoint サイトを別サイトに変更したい
- 移行先リストは「既存のリスト」から作成している（基本的な列構造や外部列名は同じ）
2. 原因と対処
先に結論ですが、たとえ SharePoint リストを複製して列が同じでも、Power BI（の Power Query）は別のリストとして扱うので、サイト URL だけでなく Power Query 内のリスト ID 参照も差し替える必要があります。
誤解を恐れずに言うと、Power BI は、リスト名を読み取りに行っているのではなく、Id を読み取りに行っているということです。つまり、新しいリストの Id を、古いリストの Id と入れ替えることで、データソースを再接続できます。
3. 手順
3.1. 新しいリストをデータソースとして追加する
手順はいたって単純です。まずは、お引っ越し先となる「新リスト」を Power BI のデータソースとして紐付けます（※古いリストはそのままにしておきます）
SharePoint リストをデータソースに設定する方法は Microsoft Learn をご参考ください。現在の画面と異なる部分はありますが基本操作は変わりません。
3.2. 新リストの Id を旧リストの Id に置き換える
Power Query エディタを開き、新しいリストを選択した後で詳細エディターを開きます。開いたら、let と in の間にある「ソース＝」から始まる文と「#"ナビゲーション 1"＝」から始まる文をコピー元に取っておきます。
今度は、旧リストに入っている「ソース＝」から始まる文と「#"ナビゲーション 1"＝」から始まる文を、新リストのものと置き換えます。この時、コンマ（ , ）を消さないように注意します。
置き換えが完了したら、新しくインポートした方のリストは用済みなので削除します。
「閉じて適用」をクリックして作業完了です。Power BI Desktop の方に戻る際、エラー等が出なければ、無事、データソースのお引っ越しは完了です。
結
正直なところ、ナレッジとして蓄積・管理されていたデータをサイトごと入れ換えるシチュエーションはそう多くないと思っていますが、それでも中には、こういった場面に遭遇する方もいるかもしれません。
例えば、検証用サイトで作ったリストを本番用サイトへ移したい場合、部署ごとに分かれていた SharePoint サイトを整理したい場合、あるいは、最初は個人や小さなチームで作った仕組みを、あとから組織内の正式な場所へ移したい場合も考えられるでしょう。
当記事がそんな方々のお役に立てたのであれば幸いです。
補足
記事の公開直後、非常によいフィードバックがありましたので共有いたします。
今回のように、既存レポートのデータソースだけを切り替えたい場合、業務上はまず安全に接続先を変更できることが重要です。
すでにレポートが作り込まれている場合、メジャー、リレーションシップ、ビジュアル、フィルター設定などを含めて最初から作り直すのは負荷が大きくなります。そのため、急ぎの対応であれば、既存の Power Query を確認し、接続先のサイト URL やリスト ID の参照を必要な範囲で差し替える方が現実的です。
一方で、今後の障害対応も見越した学習目的であれば、いったん新しい SharePoint リストに最初から接続し直してみるのも効果的だと思います。
Power Query は、マウス操作でデータを加工できるツールですが、裏では M言語というプログラミングコードが走っています。どのようなコードが書かれているのか、既存クエリと新規クエリを見比べることで、SharePoint サイト URL、リスト ID、ナビゲーション、列変換の関係が見えやすくなります。
単に「ここを書き換えれば動く」という Tips として覚えるだけでなく、Power Query の処理がどのように積み上がっているのかを確認しておくと、次に似たようなトラブルが起きたときにも原因を追いやすくなります。
急ぎの業務対応では、まず安全に直し、学習の機会として捉えられる場合は、あえて Power Query 部分を作り直して見比べる⋯といったように、両者を分けて考えると、実務にも学習にも繋げられやすいと思います。
優吾さん（掲載元の発信者）の「残念な気持ちになる」というのは、筆者自身が元々高等教育に携わってきた経歴からも痛み入る言葉でした。改めてフィードバックありがとうございました。