【Power Automate】タイムゾーン変換でつまずく時の入力値と条件分岐の直し方

Power Automateでフローを作成する際、日付や時刻を扱うタイムゾーン変換は、しばしば予期せぬエラーや誤った結果を引き起こします。特に、入力値の形式や条件分岐のロジックが原因で、思った通りに動かないケースが多く見られます。この記事では、タイムゾーン変換でつまずく代表的な原因を整理し、具体的な修正手順や条件分岐の考え方を解説します。実際の操作画面を想定した手順を交えながら、自分で問題を切り分けられるようになることを目指します。

Power Automateでタイムゾーン変換がうまくいかない原因

タイムゾーン変換に失敗する原因は大きく分けて三つあります。一つ目は、入力される日時文字列の形式が不正であること。二つ目は、変換先のタイムゾーン指定が間違っていること。三つ目は、条件分岐の中でタイムゾーンを考慮せずに比較していることです。多くのユーザーは、最初に「Convert time zone」アクションを使いますが、その前後でデータ型やUTCとの関係を理解していないと、思わぬ結果になります。特に、SharePointやExcelから取得した日付が暗黙的にUTCとして扱われるケースが多く、意図したローカル時刻とズレることが頻繁に起こります。

タイムゾーン変換の基本設定と注意点

「Convert time zone」アクションは、Power Automateの組み込みアクションです。このアクションは、ベース時刻(Base time)を指定されたタイムゾーンから別のタイムゾーンに変換します。重要なのは、ベース時刻は文字列として渡す必要があり、かつその文字列がタイムゾーン情報を内包しているかどうかです。例えば、「2024-10-01T09:00:00Z」のように末尾にZ(UTC)がある場合と、単に「2024-10-01 09:00:00」のようなローカル時刻を表す文字列では、変換結果が変わります。

ベース時刻の形式チェック

Power Automateでは、内部で日時を扱う際にISO 8601形式を推奨しています。特に「Z」サフィックスがない場合、アクションはその時刻がベースタイムゾーンに属するものとして解釈します。そのため、UTC以外のタイムゾーンをベースタイムゾーンに指定しないと、変換が意図しないものになります。例えば、SharePointの「作成日時」は常にUTCで保存されていますが、表示は自動的にローカルタイムに変換されます。フローで取得した値はUTC文字列であるため、ベースタイムゾーンに「UTC」を指定しなければ正しく変換されません。

タイムゾーン名の正しい指定方法

タイムゾーン名はWindowsの標準タイムゾーン名(例: Tokyo Standard Time)を使用します。よく間違えられるのが「JST」のような略称は使えない点です。また、夏時間(サマータイム)を考慮するかどうかは、Windowsのタイムゾーン定義に依存します。日本は夏時間がないため問題になりにくいですが、海外のタイムゾーンを扱う場合は注意が必要です。

入力値の確認と修正方法

ここでは、実際のフロー編集画面で入力値を確認し、修正する手順を説明します。SharePointリストから日付を取得し、それを東京時間に変換する例を想定します。

1. フローの「トリガー」または「アクション」で日時を取得している箇所を確認します。例えば「アイテムの取得」アクションの出力から’作成日時’フィールドを見ます。
2. その値がどのような形式かを確認するため、「compose」アクションを追加して変数に格納し、実行履歴で実際の文字列を確認します。多くの場合、「2024-10-01T04:30:00Z」のようなUTC形式です。
3. 「Convert time zone」アクションを追加します。ベース時刻には先ほどの値(動的コンテンツ)を指定します。
4. 「ソースタイムゾーン」に「UTC」を指定します。SharePointの日付はUTCであるため、ここを間違えると変換結果がずれます。
5. 「変換先タイムゾーン」に「Tokyo Standard Time」を指定します。ここは東京以外でも適宜変更してください。
6. 「形式」は必要に応じて指定します。例えば「’yyyy-MM-dd HH:mm:ss’」のようにカスタム形式を指定することで、後の条件分岐で使いやすくなります。出力のデータ型は文字列になるため、数値として比較したい場合は注意が必要です。
7. フローを保存し、テスト実行して変換結果を確認します。期待した東京時刻になっていれば成功です。

条件分岐でタイムゾーンを考慮する実践例

条件分岐で日時を比較する際、タイムゾーンの違いが原因で意図しない分岐になることがあります。例えば、現在時刻が9時以降かどうかで処理を分けたい場合、単純に「現在の時刻」と「9:00」という文字列を比較しても正しく動きません。なぜなら、現在時刻はフローの実行環境(クラウド)のUTCで取得されるからです。

現在時刻をローカルタイムに変換して比較する

正しい方法は、まず「utcNow()」関数で現在のUTC時刻を取得し、「Convert time zone」で東京時間に変換します。その後、変換された文字列から時刻部分を取り出して比較します。または、日付全体を数値として比較する場合は、unixタイムスタンプに変換する方法も有効です。Power Automateでは「ticks」関数を使って、1601年1月1日からの経過時間(100ナノ秒単位)を取得し、数値比較を行うことができます。

実例:UTC時刻とローカル時刻の比較

例えば、SharePointアイテムの期限日が今日の東京時刻の18時を過ぎているかどうかをチェックする場合を考えます。以下のような流れになります。

• 期限日の値を「Convert time zone」でUTCから東京に変換します。
• 「utcNow()」を同じく東京時間に変換します。
• 両方の結果を「ticks」関数で数値に変換します。
• 条件アクションで「期限のticks が 現在のticks より小さい」と設定します。
• この方法であれば、タイムゾーンや夏時間の影響を受けずに比較できます。

比較対象	方法	注意点
日付のみの比較	formatDateTimeでyyyy-MM-ddに整形して文字列比較	タイムゾーンを事前に合わせること
時刻のみの比較	formatDateTimeでHH:mm:ssに整形して文字列比較	24時間形式に注意
日時の大小比較	ticks関数で数値化して比較	ticksの基準はUTCのため変換不要

よくある失敗パターンとその対処法

実際によく報告される失敗パターンをいくつか紹介します。これらのパターンを覚えておくと、原因特定が速くなります。

パターン1: ソースタイムゾーンの指定ミス

SharePointから取得した値はUTCであるにもかかわらず、ソースタイムゾーンを「Tokyo Standard Time」と指定してしまうケースです。この場合、変換結果は9時間ずれてしまいます。対処法は、ソースタイムゾーンを常に「UTC」にすることです。ただし、もし入力値がすでにローカル時刻(東京時間)として与えられている場合は、ソースタイムゾーンを「Tokyo Standard Time」にしてください。データの出自を確認しましょう。

パターン2: 変換後の値を条件分岐で直接比較してしまう

「Convert time zone」の出力は文字列です。その文字列を「条件」アクションで「より大きい」や「より小さい」で比較すると、文字列としての比較になるため、日時として正しく評価されません。例えば、「2024-10-01T00:00:00」と「2024-10-01T01:00:00」を文字列比較すると、先頭から1文字ずつ比較されるため、期待通りの大小になりません。対処法は、ticks関数やunixタイムスタンプに変換して数値として比較することです。

パターン3: 「utcNow()」と「convertTimeZone」の実行順序

フローの中で「utcNow()」を複数回使うと、それぞれ異なる時刻を返す可能性があります。特に、条件分岐の中で現在時刻を参照する場合、フロー全体で一度だけutcNowを取得して変数に格納することを推奨します。そうしないと、条件分岐の前後で微妙に時刻が変わってしまい、意図しない結果になることがあります。

管理者に確認すべき設定項目

Power Automateの動作に影響を与える管理者レベルの設定もあります。以下の項目について、管理者に確認することをおすすめします。

• 環境のタイムゾーン設定: Power Automateの環境設定で既定のタイムゾーンが設定されている場合、特定のアクションの初期値に影響することがあります。ただし、Convert time zoneアクションのデフォルト値には影響しないことが多いです。
• カスタムコネクタのタイムゾーン: 独自に作成したコネクタで日時を扱う場合、そのコネクタがどのタイムゾーンを前提としているか確認する必要があります。
• Dataverseのタイムゾーン: Dataverseを使用している場合、テーブルの列にタイムゾーンの設定があります。ここがUTCでないと、フローでの値がずれる原因になります。
• Power Platform管理センターの設定: テナント全体の既定のタイムゾーンは、Power Platform管理センターで確認できます。しかし、個々のフローには直接影響しないため、基本的には無視して構いません。

よくある質問(FAQ)

Q: 「Convert time zone」アクションで「ソースタイムゾーン」と「変換先タイムゾーン」に同じタイムゾーンを指定するとどうなりますか?
A: 変換は行われず、同じ値が出力されます。ただし、書式指定をした場合は整形される可能性があります。

Q: Excel Onlineから日付を取得した場合、タイムゾーンはどうなりますか?
A: Excel Onlineのセルに日付のみが入っている場合、フローでは文字列として取得されます。タイムゾーン情報は含まれないため、必要に応じて明示的にUTCとみなすか、ローカル時刻とみなすかを決めて変換してください。

Q: 夏時間(サマータイム)は自動的に考慮されますか?
A: はい、Windowsのタイムゾーン定義に基づき、Convert time zoneアクションは夏時間を自動反映します。ただし、該当期間かどうかの判定はOSの更新に依存します。

Q: ticks関数を使うときの注意点は?
A: ticks関数は1601年1月1日からの100ナノ秒間隔の数値を返します。日付が1601年より前だと負の値になるため、使用する日付がその範囲内か確認してください。また、ticksは常にUTC基準のため、タイムゾーン変換は不要です。

まとめ

Power Automateでのタイムゾーン変換は、入力値の形式とアクションの設定を正しく理解することで、ほとんどの問題を解決できます。特に、SharePointやExcelから取得した日時はUTCであることを前提にし、条件分岐では数値比較を行うことが安定した動作につながります。今回紹介した手順や比較表を参考に、フローを見直してみてください。トラブルが発生した場合は、まずベース時刻とタイムゾーンの指定が適切かどうかを確認し、それでも解決しない場合は管理者に環境設定を問い合わせることをおすすめします。