【Power Automate】タイムゾーン変換が想定どおり進まない時の失敗した場所を特定する方法

Power Automateで日時のタイムゾーン変換を実装したものの、期待した時刻と異なる結果になるケースが多くあります。特に日本時間とUTCの変換でずれが生じると、業務の正確性に直結するため早急な原因特定が必要です。しかし、変換に関わる要素はアクションの設定、関数の引数、環境の標準タイムゾーンなど多岐にわたるため、どこで失敗したのかを切り分けるのが難しいと感じる方も少なくありません。本記事では、タイムゾーン変換が想定どおり進まない場合に、具体的にどの場所を確認すればよいかを、実行履歴の見方や代表的な失敗パターンとともに解説します。手順に沿って確認することで、問題箇所を特定し、次の修正行動を確実に決定できるようになります。

1. タイムゾーン変換の基本とよくある誤解

Power Automateでタイムゾーン変換を行う主な方法は、「Convert time zone」アクション(v2)と「ConvertTimeZone」関数(式内)の二つです。どちらも変換元のタイムゾーン(Source time zone)、変換する日時、変換先のタイムゾーン(Destination time zone)を指定します。しかし、よくある誤解として、「タイムゾーン識別子の指定方法がWindowsのタイムゾーン名(例:Tokyo Standard Time)とIANAタイムゾーン(例:Asia/Tokyo)のどちらを使うべきか」「日時文字列にUTCオフセットが含まれている場合の扱い」などがあります。たとえば、Convert time zoneアクションのSource time zoneに「UTC」と指定したにもかかわらず、入力日時がすでに日本時間だったために二重変換が発生し、結果が想定より9時間ずれるケースが頻繁に報告されています。このような誤解を避けるためには、まず各アクションや関数の仕様を正しく理解し、実行履歴で実際の入出力を確認することが第一歩です。

2. フロー実行履歴で入力値と出力値を確認する手順

問題の特定には、実際にフローを実行し、その履歴から該当アクションの詳細を確認するのが最も確実です。以下の手順で確認してください。

1. Power Automateポータルにサインインし、対象のフローを開きます。
2. 左側のメニューから「実行履歴」を選択し、直近の失敗または想定外の結果が発生した実行をクリックします。
3. 実行詳細画面で、タイムゾーン変換に関係するアクション(例:Convert time zone)を選択します。
4. アクションの「入力」タブを開き、「sourceTimeZone」「destinationTimeZone」「baseTime」の各項目に設定された値が意図したものであるかを確認します。特にタイムゾーン識別子のスペルミスがないか注意してください。
5. 次に「出力」タブを開き、変換結果の日時とタイムゾーンが期待どおりかを確認します。出力値にタイムゾーンオフセット(例:+09:00)が正しく付与されているかも重要です。

この手順で、アクションの設定自体に問題がないかどうかを切り分けられます。もし入力が正しいのに出力がおかしい場合は、アクションの内部処理に問題があるか、あるいはデータ型の不一致が疑われます。

2.1 入力の詳細確認で押さえるべきポイント

入力値を見るときは、文字列としての日時表現に注目してください。「baseTime」に「2025-03-15T10:00:00Z」のようなUTC表記が渡されていれば、Source time zoneを「UTC」に設定するのが正しいですが、「2025-03-15T10:00:00」のようにタイムゾーン情報がない文字列の場合は、Source time zoneに指定したタイムゾーンとして解釈されます。この違いを見逃すと二重変換や無変換の原因になります。また、タイムゾーン識別子は「Tokyo Standard Time」のようにWindows標準の名前である必要がある点も覚えておきましょう。Power AutomateのアクションではIANA名(Asia/Tokyo)は使えません。

3. 代表的な失敗パターンとその切り分け

実際に発生しやすい失敗パターンをいくつか挙げ、それぞれの切り分け方法を説明します。

3.1 タイムゾーン識別子の誤り

最も多い原因が、タイムゾーン識別子のスペルミスや存在しない識別子の指定です。たとえば「Tokyo Standard Time」を「Tokyo Standard」と省略したり、「UTC」を「UCT」と間違えたりするケースです。この場合、アクションはエラーにならずに実行されるものの、Source time zoneが正しく認識されず、変換結果がUTC基準のまま出力されることがあります。切り分けには、実行履歴の入力タブで識別子をコピーし、Microsoftの公式ドキュメントで有効な識別子リストと照合してください。

3.2 夏時間(DST)の考慮漏れ

Power AutomateのConvert time zoneアクションは、変換先タイムゾーンが夏時間を採用している場合、自動的に夏時間を考慮して変換してくれます。しかし、変換元の日時が夏時間に該当するかどうかの判定は、元のタイムゾーンに依存します。たとえば、アメリカ東部時間(Eastern Standard Time/Eastern Daylight Time)を指定した場合、アクションは対象日時に応じて標準時と夏時間を自動判定します。この動作を理解していないと、「夏時間の期間に1時間ずれる」と誤認することがあります。対策としては、変換前後の日時を手計算で検算し、ずれが1時間の倍数である場合はDSTの影響を疑ってください。

3.3 文字列形式の日時とDateTime型の混在

フローの中で、日時を文字列として保持している変数と、Power AutomateのネイティブなDateTime型を混在させると、変換が期待通りに動かないことがあります。特に、アクションの入力に動的なコンテンツを使用する場合、値の型が文字列か日時かが明示されていないと、アクションが自動的に解釈する方法が変わります。例えば、SharePointのリストから取得した日時列は文字列として扱われることが多く、そのままConvert time zoneアクションに渡すと、Source time zoneが無視される可能性があります。解決策としては、事前に「parseDateTime」関数などで文字列を日時に変換してからアクションに渡すか、アクションの「baseTime」にパース済みの値をセットしてください。

4. 状況別:変換元のタイムゾーン指定ミスの確認方法

変換元のタイムゾーンを誤って指定すると、出力が一律に数時間ずれる結果になります。このケースを特定するには、以下の表を参考に実際の値と期待値を比較してください。

入力日時(文字列)	設定したSource time zone	期待する出力(日本時間)	実際の出力	推定原因
2025-03-15T10:00:00Z	UTC	2025-03-15T19:00:00	2025-03-15T19:00:00	正しい
2025-03-15T10:00:00	Tokyo Standard Time	2025-03-15T10:00:00	2025-03-15T01:00:00	Source time zoneを「Tokyo Standard Time」と指定したが、実は入力日時がUTCだったため、アクションは入力を日本時間とみなしてUTCに変換し、さらに日本時間に変換しようとして9時間戻った
2025-03-15T10:00:00	(空欄)	エラーまたは想定外	エラー	Source time zoneが必須項目であり、空白だとアクションがエラーになる。

このように、実際の出力が想定より9時間ずれている場合は、Source time zoneの設定ミスが最も疑われます。また、出力がエラーになる場合は、必須パラメータの欠落や型の不一致を確認すべきです。

5. 管理者に確認すべき環境設定とコネクタの制限

個人設定では変更できない、テナントや環境レベルの設定が原因でタイムゾーン変換が想定どおりに動作しないこともあります。以下の点を管理者に確認することをおすすめします。

• Power Automate環境の既定タイムゾーン: 環境設定の中で「既定のタイムゾーン」が設定されている場合、アクションの動作に影響を与えることがあります。特に、カスタムコネクタを使用している場合に、この設定値が暗黙的に参照されることがあるため、不一致が生じる可能性があります。
• 使用しているコネクタのバージョン: Convert time zoneにはv1(非推奨)とv2があります。v1ではタイムゾーン識別子の指定方法が異なる場合があるため、v2への移行を検討してください。また、カスタムコネクタ内で独自のタイムゾーン変換ロジックを実装している場合は、その中のバグが原因となっていることも考えられます。
• Azure ADと統合されたサービスのタイムゾーン: フローがMicrosoft 365のサービスと連携している場合、各サービスのタイムゾーン設定も影響します。例えば、SharePointのサイトの地域設定が日本以外になっていると、リストの日時列が異なるタイムゾーンで保存されるため、フローで扱う際に変換が必要になります。

管理者に確認する際は、具体的なアクション名と、期待する結果、実際の結果を伝えることで、迅速な調査が可能になります。

6. よくある質問と補足

Q1: Convert time zoneアクションで「Asia/Tokyo」を指定したらエラーになりました。なぜですか?

A: Power AutomateのConvert time zoneアクションでは、Windowsタイムゾーン識別子(例:Tokyo Standard Time)を使用する必要があります。IANAタイムゾーン識別子(例:Asia/Tokyo)はサポートされていません。正しい識別子は「Tokyo Standard Time」です。同様に、UTCは「UTC」で問題ありません。

Q2: 変換結果が常に1時間ずれています。夏時間の影響ですか?

A: ずれが1時間の場合は、夏時間(DST)の影響が疑われます。たとえば、アメリカ東部時間から日本時間に変換する場合、変換元の日時がDST期間内かどうかで結果が変わります。まずは、変換元の日時がDST期間に該当するかを確認し、該当するならばアクションの自動判定が正しく動作しているかを検算してください。

Q3: フローの実行履歴を見ると「baseTime」にUTCの日時が入っていましたが、Source time zoneを「UTC」に設定しても結果がずれます。なぜですか?

A: もしbaseTimeの文字列にすでにタイムゾーンオフセット(例:「2025-03-15T10:00:00Z」のようにZが付いている)が含まれている場合、Source time zoneの設定は無視され、文字列に含まれるオフセットが優先される可能性があります。この場合、Source time zoneを明示的に設定しなくても、アクションは文字列の情報を使って変換します。そのため、期待と異なる結果になる場合は、baseTimeからタイムゾーン情報を削除するか、明示的にオフセットを指定しない文字列(例:「2025-03-15T10:00:00」)に変換してからアクションに渡すとよいでしょう。

まとめ

タイムゾーン変換の失敗は、フローの実行履歴でアクションの入出力を詳細に確認することで、原因箇所を特定できます。特に、タイムゾーン識別子の正しさ、入力日時の形式(タイムゾーン情報の有無)、アクションのバージョンの違いに注意してください。また、夏時間や環境設定が影響するケースもあるため、管理者との連携も視野に入れてください。これらの手順を踏めば、想定外の変換結果に対して適切な修正アクションをとることができるようになります。