【Power Query】時刻が9時間ズレる原因とタイムゾーン変換

入力フォームの回答を、Googleフォーム→スプレッドシート→GASのJSON API→Power Queryの経路で取り込みました。このとき、時刻が日本時間より9時間ズレていました。値を見て、「世界標準時か」と気づきました。

この記事では、Power Queryのタイムゾーン変換（DateTimeZone.SwitchZone）と、時刻を突合のキーにしたときの落とし穴を整理します。

想定読者
困った場面：時刻が9時間ズレて届く
解決コード：SwitchZoneでJSTにそろえる
解説：FromText→SwitchZone→RemoveZone
よくある失敗
応用例：時刻ではなく連番で紐付ける
まとめ

想定読者

外部から時刻の文字列を取り込む方、時刻をキーに別の表と突合したい方が対象です。

困った場面：時刻が9時間ズレて届く

取り込んだ時刻は文字列で、末尾に Z が付いていました（例：2026-10-07T03:31:00.000Z）。日本時間より9時間前の値です。Power Queryで日本時間に変換できるので、変換そのものにはさほど困りませんでした。

失敗したのは、この時刻を突合のキーにしたことです。記録側に、記録時刻ではなく処理時間を入れていました。意味の違う時刻を比べていたので、変換しても一致しません。そこで、取り込み時に連番を振り、連番で紐付ける形に変えました。

なお、JSONに変換するときにこの形になるようですが、原因は調べていません。Googleフォーム自体の仕様かどうかも、確認していません。

解決コード：SwitchZoneでJSTにそろえる

let
  Src = #table({"Ts"}, {{"2026-10-07T03:31:00.000Z"}, {"2026-10-07T04:05:30.000Z"}, {"2026-10-07T05:00:00.000Z"}}),
  Utc = Table.AddColumn(Src, "UtcAsIs",
    each DateTimeZone.RemoveZone(DateTimeZone.FromText([Ts])),
    type datetime),
  Jst = Table.AddColumn(Utc, "Jst",
    each DateTimeZone.RemoveZone(
      DateTimeZone.SwitchZone(DateTimeZone.FromText([Ts]), 9)),
    type datetime)
in
  Jst

結果は次の表です。Ts が元の文字列、UtcAsIs がUTCのままの日時、Jst が日本時間に変換した日時です。

Power Queryの結果表。Z付きの文字列（Ts列）、UTCのままの日時（UtcAsIs列）、JSTに変換した日時（Jst列）を3行で並べている。 — 再現用の最小コードの実行結果

解説：FromText→SwitchZone→RemoveZone

DateTimeZone.FromText で、文字列をタイムゾーン付きの日時にします。Z は、ゾーン0として読まれました。
DateTimeZone.SwitchZone(…, 9) で、+9時間のゾーンに切り替えます。03:31 が 12:31 になり、差は9時間でした。
DateTimeZone.RemoveZone で、ゾーン情報を外します。

文字列のままでは、ただのテキストなので変換されません。日付や時刻が数字で扱われる仕組みは、【Excel】日付が数字になる仕組みとVBA・PQでの扱いで説明しています。

関数の仕様は、Microsoft LearnのDateTimeZone.SwitchZoneのページにあります。

同じ文字列を DateTime.FromText で読むと、今回のPCでは 12:31:00 になりました。PCの時刻に自動で変換されたように見えます。そのため、ズレに気づきにくくなります。今回のPCのタイムゾーンはUTC+9です。他のタイムゾーンのPCは未検証です。

検証環境は、Excel 16.0（Windows）です。他のバージョンとMac版は未検証です。