記事公開日
Power Automateで日本時間に変換する3つの方法｜UTCとの9時間差を解消
この記事の重要ポイント
- Power Automateの内部的な時刻基準は世界標準時（UTC）のため、日本時間（JST）とは9時間の時差が生じます。
- スケジュール実行時のタイムゾーン設定や「タイムゾーンの変換」アクション、addHours関数のいずれかで補正をすると最適なフローを作成できます。
- 時差を放置すると、深夜～早朝のデータが「前日のデータ」として登録されるなど、トラブルに直結する可能性があります。
こんにちは、DXソリューション営業本部の伊藤です。
本ブログでは、Power Automateで発生しがちな「時間のズレ」を解消し、日本時間（JST）へ正しく変換・調整するための基礎知識と具体的なアプローチを学べる記事です。
「スケジュールが思い通りに動かない」「データの日付が1日ズレる」といったお悩みをお持ちの方は、ぜひ最後までご覧ください。
Power Automateの内部時間は「UTC」で動いている
クラウドサービスであるPower Automateは、世界中のユーザーが利用するため、内部的な時刻基準はすべて「UTC（協定世界時）」で統一されています。
一方、私たちが普段業務を行っているのは「JST（日本標準時）」です。日本時間はUTCよりも「9時間進んでいる（UTC+9）」ため、取得した日時をそのままメールやTeamsなどに出力すると、システム側は正しい時間として処理しているにもかかわらず、私たちから見ると「9時間前の時刻」として表示されてしまいます。
そのまま使用した場合に発生する3つのトラブル
タイムゾーンを意識せずにフローを作成すると、具体的に以下のようなトラブルが発生します。
スケジュールのズレ
毎日朝9時に起動する設定をしても、タイムゾーン指定がないとシステムは「UTCの朝9時」と解釈します。これは日本時間の「夕方18時」に該当し、業務終了時にリマインドが届くといった事態を招きます。
日付データのズレ（1日ズレる罠）
例えば、SharePointリストなどで日本時間の「1月2日の午前8時」に新しいアイテム（データ）が作成された場合、Power Automateはこれを「1月1日の23時（UTC）」として認識します。このままExcelへの書き込みや、メール・Teamsの本文に日付を出力すると、記載される日付が前日になってしまい、業務上の報告や月次レポートなどの集計が合わなくなる原因になります。（※SharePointの「日時と時刻」列への登録については、後述の注意点をご確認ください）
実行履歴の混乱
エラー調査の際、履歴のタイムスタンプがUTC表記だと「日本の何時何分に発生したのか」を確認するのに手間がかかります。
日本時間（JST）へ変換する3つの解決策
日本の業務時間に合わせて正しく稼働させるには、以下のいずれかのアプローチで時差を調整します。
- トリガー設定で「タイムゾーン」を日本にする
- 「タイムゾーンの変換」アクションを追加する
- addHours 関数を使用する
【解決策1】トリガー設定で「タイムゾーン」を日本にする
「スケジュール済みクラウドフロー」において、最もシンプルで確実な方法です。
💡 設定のポイント
「繰り返し」トリガーの「詳細パラメーター」から、必ず「設定：タイムゾーン」を表示させ、「(UTC+09:00) Osaka, Sapporo, Tokyo」を選択してください。これを忘れると、開始時刻を日本時間で入力してもUTCとして処理されてしまいます。
また、確実に朝9時に実行したい場合は、同じく詳細パラメーターで「設定時刻（時間）」を「9」、「設定時刻（分）」を「0」と併せて指定します。
【解決策2】「タイムゾーンの変換」アクションを追加する
フローの途中で取得したUTC日時をJSTに変換したい場合に推奨される、視覚的にわかりやすい方法です。
STEP 1 「タイムゾーンの変換」アクションを追加します。
STEP 2 「基準時間」に元データを指定し、「変換元のタイムゾーン」を「(UTC) 協定世界時」、「変換先のタイムゾーン」を「(UTC+09:00) 大阪、札幌、東京」に設定します。
STEP 3 「書式設定文字列」で、出力したい形式を選択します。Excel等で見やすくしたい場合は「カスタム値の入力」から yyyy/MM/dd HH:mm:ss と直接入力することも可能です。
STEP 4 以降のアクションでは、このアクションで生成された「動的なコンテンツ（変換後の時間）」を使用します。
【解決策3】関数「addHours」を使用する
アクションを増やさず、数式で直接9時間を足す方法です。
addHours(utcNow(), 9, 'yyyy/MM/dd HH:mm:ss')
第3引数にフォーマットを指定することで、日時の計算と見た目の整理を同時に行えます。この1行で、現在時刻（utcNow()）を、変換アクションを使わずに出力できます。
また、utcNow() の部分を「動的なコンテンツ（取得した日時のデータ）」に置き換えれば、過去や未来のデータでも同様に9時間を足すことができます。
⚠️ 使用時の注意点とポイント
- データ登録時の「型」に注意：「タイムゾーンの変換」アクションや addHours 関数でJSTに変換した値は、メール本文やTeamsへの投稿など「テキスト（文字列）」として表示したい場合に使用します。
SharePointやDataverseの「日時型」列にデータを登録する場合は、JSTへ変換してはいけません。これらのデータベースは内部的にUTCで保存し、画面表示時にユーザーの設定に合わせて自動で日本時間に変換する仕様です。そのため、Power Automate側でJSTに変換してから渡すと、さらに9時間足されて表示される「二重変換」のバグが起きてしまいます。日時型列には、トリガー等で取得したUTCの値をそのまま渡すようにしてください。 - 日本だからできる手法：サマータイム（夏時間）がある地域では、時期によって時差が変わるため単純に「9足す」手法は使えません。日本にはサマータイムがないため、年間を通じてこの関数で安全に処理できます。
よくある質問
Q. なぜ最初から日本時間になっていないのですか？
Power Automateはグローバルなクラウド基盤で動作しているため、世界共通の基準物差しとしてUTC（協定世界時）が採用されているからです。
Q. 変換アクションと関数、どちらを使うべきですか？
視認性を重視し、後から誰が見ても設定内容がわかるようにしたい場合は「変換アクション」を、フローのステップ数を減らしてシンプルに保ちたい場合は「関数」をお勧めします。
まとめ
Power Automateにおける「UTCと日本時間の9時間の壁」は避けて通れない仕様です。スケジュールならトリガー設定、取得データなら変換アクション、現在時刻なら関数と、状況に合わせて最適なアプローチを使い分けましょう。
正しい時差の調整方法を身につけて、思い通りの自動化フローを実現してください！
QES では Power Platform の開発支援、QAサポート、開発者教育、ガバナンス整備など、組織で Power Platform を活用するためのサポートを包括的にご提供しています。Power Platform 活用についてご興味がある／利用中だが課題を感じていらっしゃるお客様はまずはお気軽にお問い合わせください。
このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。
