ADVERTISEMENT

【Power Automate】日付のタイムゾーンがずれる時の直し方

【Power Automate】日付のタイムゾーンがずれる時の直し方
🛡️ 超解決

Power Automateで日付や時刻を扱うと、思ったタイムゾーンと違う値が表示されることがあります。これは多くの場合、Power Automateが内部的にUTC(協定世界時)で動作していることが原因です。データソースや出力先のタイムゾーン設定も絡むため、問題の所在を切り分ける必要があります。この記事では、タイムゾーンずれが発生する仕組みと、具体的な修正手順を解説します。フロー内で正しく日付変換を行う方法を身につけてください。

【要点】この記事で確認すること

  • 最初に見る場所: フロー内の日付関数(utcNow、convertTimeZone)、データソース(SharePoint、Excelなど)の日付列のタイムゾーン設定、出力先の表示設定
  • 切り分けの軸: フロー内の処理が原因か、データソース側のタイムゾーン保存形式が原因か、それとも出力先の表示設定が原因か
  • 注意点: 会社PCのタイムゾーン設定を変更するのではなく、Power Automateの式やデータソース側の設定で対応すること。管理者に確認すべき設定もあります

ADVERTISEMENT

タイムゾーンずれの原因を理解する

Power Automateの標準関数(utcNow()など)で取得される時刻は、すべてUTCで出力されます。これはクラウドサービスが広く使う共通の基準で、地域ごとのローカルタイムとは異なります。一方、SharePointやExcelといったデータソースでは、日付列がUTCで保存されるものとローカルタイムで保存されるものがあります。SharePointの日付列はデフォルトでUTCで保存され、画面表示時にユーザーのタイムゾーンに変換されます。しかし、Power Automateで取得するとUTCのまま取得されるため、直接表示すると日本時間と9時間ずれて見えるわけです。逆にExcel Onlineの日付は、Excelファイルのタイムゾーンに依存し、多くの場合はローカルタイムで保存されます。そのため、フローの中で適切に変換しないと、期待する値にならないのです。

原因を切り分ける手順

問題の原因を特定するには、次の手順を順に試してください。フローのテスト実行を繰り返して、日付がどの段階でずれているかを確認します。

  1. フロー内で日付を取得する場所を確認する
    utcNow()やtriggerOutputs()、SharePointの「作成日」など、どの関数・アクションで日付を取得しているかを確認します。それぞれのアクションの出力をログに出力して、実際の値を確かめてください。
  2. データソースのタイムゾーン保存形式を調べる
    SharePointリストの場合、日付列のプロパティで「協定世界時 (UTC)」と「ユーザーのローカルタイム」のどちらで保存するか設定できます。既定はUTCです。Excelの場合は、ファイル自体のタイムゾーンやセルの書式設定が影響します。
  3. convertTimeZone関数で明示的に変換する
    Power Automateの式エディタで次のように記述して、UTCから日本時間(Tokyo Standard Time)に変換します。
    convertTimeZone(outputs('Get_item')?['Created'], 'UTC', 'Tokyo Standard Time')
  4. 出力先での表示設定を確認する
    メールやTeamsメッセージに日付を挿入する場合、そのアプリケーション側のタイムゾーン設定も考慮します。特にメールは送信者のタイムゾーンで解釈されることがあります。
  5. フローをテスト実行し、結果を検証する
    実際にフローを実行し、生成された日付を確認します。必要に応じて、変換後の値をさらに別の形式に整形するためにformatDateTime関数と組み合わせてください。

主な修正方法

convertTimeZone関数の基本

Power Automateでタイムゾーンを変換するには、convertTimeZone関数を使用します。構文は convertTimeZone(sourceTime, sourceTimezone, destinationTimezone) です。sourceTimeには変換したい日付・時刻の文字列、sourceTimezoneには元のタイムゾーンID、destinationTimezoneには変換後のタイムゾーンIDを指定します。たとえば、UTCから日本時間に変換する場合は convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time') とします。タイムゾーンIDは「Tokyo Standard Time」のようにWindows形式で指定します。「Asia/Tokyo」では動作しませんので注意してください。

日付のみ・時刻のみを変換する場合

convertTimeZone関数は日時全体を変換しますが、日付部分だけ、または時刻部分だけが必要な場合は、その後でformatDateTime関数を組み合わせます。例えば、日本時間の日付だけを「yyyy-MM-dd」形式で取得するには、formatDateTime(convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time'), 'yyyy-MM-dd') とします。同様に時刻だけ必要な場合は、’HH:mm:ss’を指定します。

タイムゾーンIDの一覧と注意点

使用可能なタイムゾーンIDは、Microsoftのドキュメントに一覧があります。日本時間は「Tokyo Standard Time」です。よくある間違いとして、「Japan Standard Time」や「Asia/Tokyo」を指定してしまうケースがありますが、これらは正しく変換されません。また、夏時間がある地域では、標準時と夏時間のIDを区別する必要があります。日本は夏時間がないので「Tokyo Standard Time」で固定です。

状況別の対応方法

データソースごとに推奨される対策は異なります。以下の表を参考に、自分の環境に合った方法を選んでください。

データソース デフォルトのタイムゾーン保存形式 Power Automateでの対策
SharePointリスト UTC(設定でユーザーのローカルタイムも選択可能) convertTimeZoneでUTC→希望タイムゾーンに変換。またはリスト設定でローカルタイム保存に変更(注意:インデックスに影響)
Excel Online ファイルのタイムゾーンに依存(通常はローカルタイム) Excelの日付を文字列として扱い、必要に応じてparseDateTimeとconvertTimeZoneを組み合わせる
Outlook(メール本文など) メールの送信者・受信者のタイムゾーンに依存 メール内の日付文字列を抽出し、タイムゾーン情報があればconvertTimeZoneで変換
SQL Server datetime列のタイムゾーンなし(サーバーのローカルタイムまたはアプリ設定) SQLクエリ側でAT TIME ZONE関数を使って変換するか、フローでconvertTimeZone
Teams(メッセージの日付) Teamsのサーバータイム(UTC基準) 通常は自動変換されるので、明示的な変換は不要な場合が多い

よくある失敗パターン

タイムゾーン変換でよく見られる失敗例をいくつか紹介します。

  • タイムゾーンIDの誤指定: 「Asia/Tokyo」や「Japan Standard Time」は正しく認識されません。必ず「Tokyo Standard Time」を使用してください。また、アメリカ東部時間は「Eastern Standard Time」、インド時間は「India Standard Time」など、Windows標準のIDに従う必要があります。
  • 変換を二重に適用してしまう: 一度変換した日付に対して再度convertTimeZoneを適用すると、さらにタイムゾーンがずれてしまいます。変換後の値を再度変換していないか確認してください。
  • utcNow()をそのまま出力に使用する: 何も変換せずにUTCのままメールやTeamsに送信すると、受信者にとって意図しない時刻で表示されることがあります。必ずconvertTimeZoneで適切なタイムゾーンに変換してから出力してください。
  • SharePointの日付列の設定をローカルタイム保存に変更する影響: リスト設定で「ユーザーのローカルタイム」を選択すると、Power Automateから見た日付の値が変わる可能性があります。また、ビューでの並べ替えやフィルターに影響が出ることがあるので、変更前に管理者に相談してください。

管理者に確認すべきポイント

会社の環境によっては、Power Automateのタイムゾーン変換が制限されている場合があります。以下の点を管理者に確認してください。

  • Power Platform管理センターの環境設定: 各環境にデフォルトのタイムゾーンが設定されています。これを変更する権限がある場合は、環境のタイムゾーンを日本時間に設定すると、一部の日付関数の動作が変わることがあります。ただし、すべての動作に影響するわけではないので注意が必要です。
  • データ損失防止(DLP)ポリシー: DLPポリシーでconvertTimeZone関数の使用が許可されていない場合、式エディタでエラーになることがあります。管理者に連絡して、必要に応じてポリシーを変更してもらってください。
  • SharePointの地域設定: SharePointサイトの地域設定がタイムゾーンに影響を与えることがあります。サイト設定から地域設定を確認し、日本時間になっているか確認してください。

よくある質問

Q1. convertTimeZoneで使えるタイムゾーンIDの一覧はどこで確認できますか?

Microsoftの公式ドキュメント「タイム ゾーン ID の一覧」にすべてのIDが記載されています。Power Automateの式エディタ内の関数リファレンスからもリンクがあります。日本時間は「Tokyo Standard Time」です。

Q2. SharePointの日付が常にUTCで表示されるのはなぜですか?

SharePointリストの日付列は、既定でUTC保存に設定されています。これは、世界中のユーザーがアクセスしても日付の一貫性を保つためです。ユーザーのブラウザ設定に応じて表示時に変換されますが、Power Automateで取得するときはUTCのまま取得されるため、必要に応じてconvertTimeZoneで変換してください。

Q3. フロー内で現在の日本時間を取得するにはどうすればいいですか?

式エディタに次のように入力します。
convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time')
これで日本時間の日時が取得できます。時刻の形式を調整したい場合は、formatDateTime関数を組み合わせてください。

Q4. 複数のタイムゾーンに対応するフローを作るにはどうすればいいですか?

ユーザーのタイムゾーン情報を事前に取得しておく方法があります。例えば、SharePointリストにユーザーのタイムゾーン列を用意しておき、その値に基づいて動的にタイムゾーンIDを指定する式を作成します。変数に格納したタイムゾーンIDをconvertTimeZoneの引数に使えば、フローを複数作成しなくても対応できます。

Q5. 過去のデータのタイムゾーンも変換されますか?

convertTimeZone関数は変換対象の日付が正しいタイムゾーンで指定されていれば、過去の日付でも正しく変換します。たとえば、データソースにUTCで保存された過去の日付があれば、同じ式で日本時間に変換できます。タイムゾーンが異なるデータソースを混在させる場合は、ソースタイムゾーンを間違えないよう注意してください。

まとめ

Power Automateで日付のタイムゾーンがずれる主な原因は、UTCとローカルタイムの違いを理解していないことです。convertTimeZone関数を使って明示的に変換するか、データソースの設定を見直すことで、期待する日付を得ることができます。タイムゾーンIDはWindows標準の「Tokyo Standard Time」を使用してください。管理者の設定が影響する場合は、事前に確認を取ってから変更を加えることをおすすめします。テスト実行を繰り返して、自社の環境で適切に動作することを確認してください。


ADVERTISEMENT

この記事の監修者
✍️

超解決 第一編集部

疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。

ADVERTISEMENT