Power BI（Power Query）でSmartsheetを取り込めるのに、手動更新やスケジュール更新だけが毎回「Web.Contents … (500) Internal Server Error」で落ちるケースがあります。原因を切り分けやすい順に、現場で効く対策と確認手順をまとめます。
現象を整理：Power BI × Smartsheet の更新だけが失敗する
今回のトラブルは「初回の接続・読み込みは成功するのに、その後の更新が必ず失敗する」という点がポイントです。資格情報（認証情報）やコネクタの有効化が正しいのに落ちる場合、認証ではなく更新処理のタイミングで発生する“呼び出し形式の不整合”や“Power BI側の不具合・設定”が疑わしくなります。
DataSource.Error: Web.Contents failed to get contents from {URL} (500): Internal Server Error
「500」は一般的にサーバー側の内部エラーを示しますが、Power BI（Power Query）が投げるリクエストの形やURLエンコードの失敗、APIバージョン指定などがきっかけで、結果として接続先が500を返すこともあります。つまり、表示は“サーバーエラー”でも、手元のPower BI側で直るパターンが現実にあります。
| 状況 | よくある見え方 | 示唆 |
|---|---|---|
| 初回読み込みは成功 | プレビューや読み込みは完走する | ネットワーク遮断や完全な権限不足の可能性は低め |
| 更新だけ失敗（手動/スケジュール両方） | 更新時にのみ500で停止 | 更新処理の呼び出し差分（並列・再評価・API指定・エンコード）が疑わしい |
| 複数のSmartsheetデータセットを使用 | PBIX内にSmartsheet由来のクエリが多数 | 同時アクセス増・クエリ再評価増で不具合が顕在化しやすい |
結論：まず試すべき対策は「Power BI更新」「パスの特殊記号排除」「ApiVersion見直し」
本件で優先順位が高い対策は、次の3つです。手戻りを減らすために、上から順に試すのが効率的です。
| 優先 | 対策 | 狙い | 効果が出やすい条件 |
|---|---|---|---|
| 高 | Power BI Desktop /（必要ならゲートウェイも）最新版へ更新 | コネクタや更新処理の不具合（バグ）を潰す | 以前のバージョンから長く更新していない |
| 高 | PBIXや保存パス、ファイル名から「%」など特殊記号を排除 | URL扱い・エンコード不整合を回避 | ファイル名/フォルダ名に記号や空白が多い |
| 高 | Smartsheet接続の ApiVersion を 14 または “Auto” に | APIバージョン不整合を回避 | Mコードに ApiVersion 指定がある / 更新時のみ失敗 |
Power BIを最新版に更新する（最優先）
Smartsheetコネクタは内部的にWebアクセス（Web.Contents）を使うため、Power BI側の更新処理やコネクタ実装の差分が結果に影響します。初回読み込みが通るのに更新で落ちる場合、まずは「最新版に上げて再現するか」を確認するのが最短ルートです。
Power BI Desktop のバージョン確認と更新のコツ
- バージョン確認：Power BI Desktop の「ファイル」→「ヘルプ」→「Power BI Desktop について」（表記は環境で多少異なります）
- 更新：Microsoft Store版ならStoreから更新、ダウンロード版（インストーラー）なら公式配布版を入れ替え
- 更新後に必ず再起動：Power Queryのエンジンが更新されるため、起動し直してから検証
また、Power BIサービス側のスケジュール更新も失敗する場合は、Desktopだけでなく関連コンポーネントにも注意します。
| コンポーネント | 更新が必要になりやすいケース | チェックポイント |
|---|---|---|
| Power BI Desktop | 手動更新（Desktop）も失敗する | まずここを最新版へ |
| オンプレミス データ ゲートウェイ | （通常Smartsheet単体では不要だが）プロキシ配下や社内経由でWeb接続を制御している | 企業ネットワーク特有の経路があるなら更新対象 |
| Power BI Service のデータセット設定 | Desktopでは通るのにService更新だけ落ちる | 資格情報の再設定・接続方式の整合を再確認 |
ポイント：500エラーが毎回出る場合でも、クライアント更新だけで解消する例があります。特に「特定の月のDesktopで発生し、その後の更新で修正された」系の不具合は珍しくありません。
PBIXの保存パス・ファイル名から特殊記号を排除する
意外に見落とされがちなのが、PBIXファイル名や保存先フォルダ名に含まれる特殊記号です。たとえば%（パーセント）はURLエンコードや内部処理で特別な意味を持ちやすく、コネクタの更新処理で「想定外のURL」になった結果、Web.Contentsが失敗することがあります。
特に、次のような環境では発生しやすくなります。
- OneDrive/SharePoint同期フォルダ配下で運用していて、ローカルパスとURL表現が混ざりやすい
- フォルダ名にプロジェクト記号や日付記号、括弧、スペースを多用している
- PBIXをメール添付などで受け渡しし、保存先が毎回変わる
推奨する命名ルール（運用で事故を減らす）
Power BIに限らず、BIファイルは「人が読める」より「機械が安全に扱える」を優先すると、更新系トラブルが減ります。
| 項目 | 避けたい例 | 推奨例 | 理由 |
|---|---|---|---|
| PBIXファイル名 | Sales%Report(確定版).pbix | sales_report_v1.pbix | 特殊記号や括弧は内部処理でエスケープが絡みやすい |
| 保存フォルダ | C:\Work\BI\%案件\ | C:\Work\BI\project_a\ | % はURL/エンコード関連のトラブル要因になりやすい |
| 推奨文字 | （記号多用） | 半角英数字、ハイフン（-）、アンダースコア（_） | 多くのシステムで安全に扱える |
実施手順（やることはシンプル）
- PBIXを閉じる
- PBIXファイル名から「%」などの特殊記号を取り除く
- 保存先フォルダ名も同様に見直し、短いパス（例：C:\Work\PowerBI\）へ移動
- PBIXを開き直し、手動更新を実行
これで改善した場合、更新時にだけ参照される内部パス（キャッシュや一時ファイル）でエンコードが崩れていた可能性が高いです。
Smartsheet接続の ApiVersion を見直す（14 / “Auto”）
Power Query（M言語）でSmartsheetに接続している場合、コネクタ呼び出しのオプションとしてApiVersionが指定されていることがあります。特定のApiVersion（例：15）で更新時に不安定になり、500エラーにつながるケースがあるため、ApiVersionを14に下げる、もしくは“Auto”で自動選択に任せるのが有効です。
ApiVersionの指定がどこにあるかはPBIXによって異なりますが、典型的にはPower Queryの「ソース」付近にあります。
ApiVersionを変更する場所
- Power BI Desktop →「データの変換（Transform data）」でPower Query エディターを開く
- 対象のSmartsheetクエリを選択
- 「詳細エディター（Advanced Editor）」を開く
- ソース（Source）ステップ付近に ApiVersion の指定がないか探す
Mコードの修正例（イメージ）
コネクタ関数名（Smartsheet.XXXX）は環境やクエリ生成方法で異なることがありますが、「オプションのレコード」にApiVersionが入っている点は共通しやすいです。
// 更新でNGになりやすい例（ApiVersionが固定で高め）
let
Source = Smartsheet.XXXX([ApiVersion = 15]),
...
in
...
// 推奨：ひとつ下のバージョンに落とす
let
Source = Smartsheet.XXXX([ApiVersion = 14]),
...
in
...
// 推奨：自動選択に任せる（文字列指定）
let
Source = Smartsheet.XXXX([ApiVersion = "Auto"]),
...
in
...
注意点：
- 14は数値、“Auto”は文字列です（ダブルクォーテーションが必要）
- オプションが複数ある場合、ApiVersionだけを変更し、他のパラメーターは触りすぎない方が切り分けしやすいです
- 変更後は「閉じて適用（Close & Apply）」を実行し、手動更新で再テストします
更新が通るようになったら、次はPower BIサービスへ発行（Publish）し、サービス側の更新（手動/スケジュール）でも同じ結果になるか確認しましょう。
切り分けを早くする：Desktop更新 → Service更新 → スケジュール更新の順に確認
同じ「更新失敗」でも、どの環境で落ちるかで原因の当たりが変わります。最短で原因に寄せるために、テストの順番を固定するのがおすすめです。
| テスト | やること | 見るべきポイント | 示唆 |
|---|---|---|---|
| Desktop（手動更新） | Power BI Desktopで「更新」 | 同じ500が即出るか | ここで再現するならPBIX/Mコード/ローカル環境が主因 |
| Service（手動更新） | 発行後、データセットを手動更新 | 資格情報設定や接続方式の差が出ないか | Serviceだけで落ちるなら資格情報/権限/サービス側処理が主因 |
| Service（スケジュール更新） | スケジュール更新を設定して実行 | 時間帯・並列・頻度で差が出るか | 負荷・同時実行・一時的エラー要因も視野に |
複数Smartsheetクエリがあるときの“更新失敗”を減らす工夫
PBIX内で複数のSmartsheetデータセット（シート/レポート/ワークスペースなど）を参照している場合、更新時にAPI呼び出しが増え、問題が顕在化しやすくなります。根本解決（アップデートやApiVersion見直し）を優先しつつ、運用面で再発を減らす工夫も入れておくと安定します。
並列読み込みを抑える（同時アクセスが疑わしいとき）
Smartsheet側が一時的に不安定になったり、同時アクセスが多いと失敗しやすい環境では、Power BIの並列読み込み設定を見直すと改善することがあります。
- Power BI Desktop →「ファイル」→「オプションと設定」→「オプション」→「データの読み込み」
- 「テーブルの並列読み込み（並列ロード）」に関する設定があれば、一度オフにして検証
並列を抑えると更新時間は伸びる傾向がありますが、「毎回落ちる」状態から「更新が完走する」状態へ持っていけることがあります。
同じSmartsheetデータを“参照”で使い回し、呼び出し回数を減らす
Power Queryは、クエリ設計によっては同じデータを複数回評価（再取得）することがあります。特に、同じSmartsheetソースを複数クエリが個別に取りに行っている場合は、次のように整理すると安定しやすくなります。
- Smartsheetから取得する“元データ用クエリ（ステージング）”を1つ作る
- ステージングは「読み込みを有効にしない（Enable loadをオフ）」にして、データモデルには載せない
- 以降はステージングを「参照（Reference）」して派生テーブルを作る
これにより、更新時の外部呼び出しを最小化しやすくなります（ただし、設計や依存関係によって挙動は変わるため、変更後は必ず更新テストをしてください）。
それでも解決しない場合に試す追加チェック
ここまでの「Power BI更新」「パス特殊記号排除」「ApiVersion見直し」をやっても改善しない場合、次の追加チェックを上から順に試すと、原因が絞れます。
| チェック項目 | 手順 | 狙い |
|---|---|---|
| Power BIの資格情報をいったんクリアして再認証 | 「ファイル」→「オプションと設定」→「データ ソース設定」→対象を選んで権限クリア→再接続 | トークン更新の不整合、古い認証状態をリセット |
| データ キャッシュのクリア | 「オプション」→「データの読み込み」周辺のキャッシュ削除（表記は環境依存） | 更新時に参照されるキャッシュが壊れている可能性を排除 |
| 対象クエリを単体で更新できるか | 一時的に他のクエリの読み込みをオフにして更新 | どのSmartsheetクエリで落ちるか特定 |
| 取得対象の列・行を減らしてテスト | 不要な列を早めに削る、フィルターを早めにかける | 更新時の負荷・サイズ起因の失敗を切り分け |
| 別のPBIXで再現するか | 新規PBIXを作り、同じSmartsheetを接続して更新 | ファイル固有（Mコード/依存関係）の問題かを判断 |
特に「別の新規PBIXだと更新できる」のに「既存PBIXだけ更新できない」場合は、Mコードの依存関係やクエリの再評価、参照の組み方に原因が潜んでいることがあります。段階的にクエリを簡素化し、どのステップから500が出るかを突き止めると、対処が決めやすくなります。
コミュニティやサポートに相談するときに用意する情報
最後の手段として、MicrosoftのPower BI / Fabricコミュニティフォーラム等で相談する場合は、情報が揃っているほど原因特定が早くなります。個人情報や機密（URL、トークン、シート名など）は伏せつつ、次の情報を整理して提示するとスムーズです。
- Power BI Desktopのバージョン（年月・ビルド）
- Power BIサービスでの更新か、Desktopでの更新か（両方か）
- エラー全文（500の行だけでなく、前後のメッセージも）
- 問題のクエリのMコード（認証情報や具体URLはマスクしてOK）
- ApiVersion指定の有無（あるなら値：15/14/”Auto”など）
- PBIXの保存場所とファイル名に特殊記号が含まれていないか
- Smartsheet側はシート/レポート/ワークスペースのどれを読んでいるか（概念レベルで）
| 提示すると強い情報 | なぜ重要か | マスクのコツ |
|---|---|---|
| Mコード（Source付近） | ApiVersionや呼び出し形、再評価ポイントが見える | URL、ID、キー、シート名は伏せる（XXXX置換） |
| 再現手順 | 同じ条件で検証してもらえる | 「更新ボタン」「Service手動更新」「スケジュール更新」どれで落ちるか明記 |
| 発生タイミング（いつから） | 特定バージョン更新やAPI変更と結びつけられる | 「○月のアップデート後から」などで十分 |
最後に：500エラーでも“Power BI側で直せる”ことが多い
Smartsheet連携の更新で出る「Web.Contents の500エラー」は、一見すると相手側の問題に見えます。しかし、初回は成功して更新だけ失敗する場合は、次の3点を見直すことで解消する確率が高いです。
- Power BI Desktop（必要なら関連コンポーネント）を最新版へ更新する
- PBIXのファイル名・保存パスから「%」などの特殊記号を排除する
- MコードのApiVersionを14または”Auto”に変更して更新を再テストする
この順番で潰していくと、最小の手間で復旧しやすく、再発防止にもつながります。更新が通ったら、同じPBIXをPower BIサービスに発行して、手動更新とスケジュール更新でも問題が再現しないことまで確認して完了にしましょう。
コメント