公式資料を参照して構成した手順です。本記事の操作・コードの実行は未確認です。小さな入力例で期待結果を確かめてから利用してください。
できあがるもの
2026-10-01T18:30:00Zは2026-10-02 03:30へ変わる想定。クラウドフローでの実行確認は未実施。
始める前に
- Power Automateのクラウドフローを作成できるアカウント。組織の環境ポリシーと契約上の利用条件を確認する。
- 手動トリガーの検証用フローを使う。外部コネクタや実メール送信は追加しない。データ操作の出力は実行履歴内で確認する。
入力例
UTCの文字列2026-10-01T18:30:00Zを使用する。結果は日本時間で2026-10-02 03:30を想定する。
手順
- 手動トリガーの検証フローを作り、ComposeをUtcInputと命名する。入力へ2026-10-01T18:30:00Zを文字列として設定する。末尾ZはUTCであることを示す前提として使う。
- 次のComposeをJapanDisplayと命名し、式convertTimeZone(outputs('UtcInput'),'UTC','Tokyo Standard Time','yyyy-MM-dd HH:mm')を入力する。地域名に日本語の東京を直接入れない。
- 保存して手動でテストする。実行履歴でJapanDisplayが2026-10-02 03:30になるかを確認する。UTCの日付と日本の表示日付が異なるサンプルなので、日跨ぎの取り違えを発見しやすい。
- 次に別コピーで2026-10-01T00:00:00Zを入力し、同日の09:00になるかを確かめる。元のUTC日時は別項目として保持し、表示文字列から元の瞬間を推測して戻す設計にしない。
- 実データへ適用する前に、取得元が本当にUTCなのかを提供元の仕様で確認する。すでに日本時間の値へ同じ変換をかけると9時間ずれるため、タイムゾーンを欠く日時は先に受け取り仕様を決める。
期待結果と照合する
2026-10-01T18:30:00Zは2026-10-02 03:30へ変わる想定。クラウドフローでの実行確認は未実施。
まずこの入力例で確認し、件数や値が一致しているかを見ます。完了表示だけで判断せず、重複・空欄・対象外データも残っていないか確認してください。
うまくいかないとき
- 日本時間の文字列をUTCと誤認すると二重に時差を加えてしまう。データ提供元の仕様を確認する。
- 表示形式からオフセットを落とすと時刻の意味が曖昧になる。保存用には元のUTCも保持する。
止める・元に戻す
実行を終え、検証用フローをオフにする。不要になったらそのフローだけを削除する。外部コネクタを使わないため業務データの復元は発生しない。
公式資料・対応範囲
参照日：2026-10-17。公式資料の一般的な機能説明と、本記事固有の入力例の実行検証は別です。実務での短縮時間や効果は未計測です。