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ファイルのタイムゾーンに依存し、多くの場合はローカルタイムで保存されます。そのため、フローの中で適切に変換しないと、期待する値にならないのです。
原因を切り分ける手順
問題の原因を特定するには、次の手順を順に試してください。フローのテスト実行を繰り返して、日付がどの段階でずれているかを確認します。
- フロー内で日付を取得する場所を確認する
utcNow()やtriggerOutputs()、SharePointの「作成日」など、どの関数・アクションで日付を取得しているかを確認します。それぞれのアクションの出力をログに出力して、実際の値を確かめてください。 - データソースのタイムゾーン保存形式を調べる
SharePointリストの場合、日付列のプロパティで「協定世界時 (UTC)」と「ユーザーのローカルタイム」のどちらで保存するか設定できます。既定はUTCです。Excelの場合は、ファイル自体のタイムゾーンやセルの書式設定が影響します。 - convertTimeZone関数で明示的に変換する
Power Automateの式エディタで次のように記述して、UTCから日本時間(Tokyo Standard Time)に変換します。convertTimeZone(outputs('Get_item')?['Created'], 'UTC', 'Tokyo Standard Time') - 出力先での表示設定を確認する
メールやTeamsメッセージに日付を挿入する場合、そのアプリケーション側のタイムゾーン設定も考慮します。特にメールは送信者のタイムゾーンで解釈されることがあります。 - フローをテスト実行し、結果を検証する
実際にフローを実行し、生成された日付を確認します。必要に応じて、変換後の値をさらに別の形式に整形するために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」です。
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
超解決 第一編集部
疑問解決ポータル「超解決」の編集チーム。正確な検証と、現場視点での伝わりやすい解説を心がけています。
Office・仕事術の人気記事ランキング
- 【Outlook】添付ファイルが「Winmail.dat」に化ける!受信側が困らない送信設定
- 【Teams】メッセージを「保存済み」にして後で読む!重要なチャットをブックマークして整理する技
- 【神技】保存せずに閉じたExcel・Wordファイルを復元する!消えたデータを復活させる4つの救出法
- 【Word】差し込み印刷で数字の桁を整える!金額にカンマ(桁区切り)を入れる設定
- 【Copilot】「サービスに接続できません」エラーの原因切り分けと対処法
- 【Word】校閲機能の基本!赤字(変更履歴)とコメントで修正を見える化する
- 【PDF】PDFに入力した文字の「フォント・サイズ・色」を変更するプロパティ設定
- 【PDF】PDFのサムネイルプレビューが表示されない!エクスプローラーの設定とAcrobat環境設定
- 【Teams】会議の「参加者リスト」を出席後にダウンロードする!誰が参加したか確認する手順
- 【PDF】結合するPDFの「用紙サイズ」がバラバラな時、すべてを「A4サイズ」に強制リサイズしてから結合する
