ADVERTISEMENT

【Power Automate】日本時間への変換が想定どおり進まない時の実行履歴から原因を読む方法

【Power Automate】日本時間への変換が想定どおり進まない時の実行履歴から原因を読む方法
🛡️ 超解決

Power Automateでフローを実行した際、日時データを日本時間に変換したいにもかかわらず、想定した時刻にならないケースは多く報告されています。特に、UTC(協定世界時)からJST(日本標準時)への変換で9時間のオフセットを加える処理がうまくいかない、あるいはタイムゾーンが認識されずにそのままの値で出力される、といった問題が典型的です。こうしたトラブルは、フローのロジック自体よりも、実行環境のタイムゾーン設定や、関数の使い方、入力データの形式に起因することがほとんどです。本記事では、Power Automateの実行履歴を正しく読み解き、日本時間変換が失敗する原因を自分で特定する方法を段階的に解説します。

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

  • 最初に見る場所: フロー実行履歴の「入力」「出力」ペイン。アクションごとに実際に渡されたデータを確認します。
  • 切り分けの軸: 入力データのタイムゾーンがUTCかどうか、変換関数の指定ミス、アクションのタイムゾーン設定の3つを重点的に確認します。
  • 注意点: 会社PCでフローを作成する場合、テナントの地域設定やコネクタのAPI仕様によって動作が変わるため、管理者に問い合わせる前に実行履歴を取得しておきましょう。

ADVERTISEMENT

1. 日本時間変換に失敗する代表的なパターン

まず、どのような状況で変換が想定どおり進まないのかを整理します。以下の3パターンが頻出です。

パターン1:convertTimeZone関数の引数が間違っている

Power Automateでタイムゾーン変換を行う際、convertTimeZone関数を使用します。この関数の第1引数にタイムスタンプ文字列、第2引数に変換元のタイムゾーン、第3引数に変換先のタイムゾーンを指定します。例えば、convertTimeZone(triggerOutputs()?['startTime'], 'UTC', 'Tokyo Standard Time')のように記述します。よくある間違いは、第2引数(元のタイムゾーン)を省略したり、’JST’や’Asia/Tokyo’などの誤った文字列を指定することです。Power Automateではタイムゾーン名はWindows標準の表示名(例:’Tokyo Standard Time’)でなければ認識されません。

パターン2:入力データがすでに日本時間であるのに再変換している

フローのトリガーで受け取る日時データが、すでに日本時間として送られてくる場合があります。例えば、SharePointのリスト項目の日付列はサイトのタイムゾーン設定に依存し、また、Microsoft FormsのタイムスタンプはUTC固定です。入力データにタイムゾーン情報(末尾のZや+09:00)が含まれているかどうかで判断できます。もし末尾がZ(UTC)なら変換が必要ですが、+09:00が付いていれば日本時間とみなせるため、追加の変換は逆に9時間ずれてしまいます。

パターン3:アクションのタイムゾーン設定がローカル環境に依存している

フローエディター上で日時を表示する際、ブラウザのタイムゾーンやPower Automateのユーザー設定が影響することがあります。特に、アクションの「タイムゾーン」プロパティが明示的に設定されていないと、実行環境(クラウド側)のUTCで処理が進み、期待と異なる結果になります。

2. 実行履歴から原因を特定する手順

実際にフローが実行された後、履歴を確認して変換が失敗した原因を掘り下げます。以下の手順で進めてください。

  1. Power Automateポータル(make.powerautomate.com)にサインインし、該当フローの「実行履歴」タブを開きます。
  2. 失敗した実行をクリックし、詳細画面を開きます。アクションごとに「入力」「出力」が表示されるので、日本時間変換を行ったアクションを探します。通常は「Compose」や「Apply to each」内の「変換」アクションです。
  3. 「入力」ペインで、変換元の日時文字列を確認します。末尾に「Z」があればUTC、「+09:00」または「+09:00:00」があれば日本時間として扱われている可能性があります。
  4. 「出力」ペインで変換後の日時を確認します。期待する日本時間(例:2025-03-15T10:00:00Zがあれば、出力は2025-03-15T19:00:00+09:00になるはず)と実際の出力を比較します。
  5. もし出力がUTCのまま、または9時間ずれていない(8時間や10時間などバラバラ)場合は、convertTimeZone関数の引数が誤っているか、入力データのタイムゾーンが想定と異なる可能性が高いです。

3. 状況別の比較表で原因を絞り込む

実行履歴のデータをもとに、以下の表でどのパターンに該当するか判断します。

状況 入力データ 出力データ 推定原因
変換後もUTCのまま 2025-03-15T01:00:00Z 2025-03-15T01:00:00Z convertTimeZone関数が実行されていない、または引数が空
9時間ではなくずれている(例:+8時間) 2025-03-15T01:00:00Z 2025-03-15T09:00:00+09:00 入力データのタイムゾーンが間違っている(例:実際はUTC+8で送られてきている)
変換後、日本時間だが9時間加算ではなく減算されている 2025-03-15T10:00:00+00:00 2025-03-15T01:00:00+09:00 変換元と変換先のタイムゾーンが逆になっている
時刻は正しいが日付が翌日などになる 2025-03-15T23:00:00Z 2025-03-16T08:00:00+09:00 日付をまたぐ変換だが、期待通り(正常)

4. よくある失敗パターンと対処法

失敗パターン1:convertTimeZoneの引数にタイムゾーン名を間違えて入力

文字列「Tokyo Standard Time」は正しいですが、「Tokyo Standard Time」のスペルミスや「JST」と省略するとエラーにはならず、変換が実行されないまま元の値が出力されます。実行履歴の「出力」にエラーがない場合、このミスを疑ってください。Power Automateの公式ドキュメントで利用可能なタイムゾーン名一覧を確認しましょう。

失敗パターン2:変換元のタイムゾーンが「UTC」固定ではない

例えば、SharePointの「作成日時」はサイトのタイムゾーンで保存されるため、変換元に「UTC」を指定するとずれが生じます。トリガー出力のタイムスタンプにタイムゾーンオフセットが含まれているか確認し、それに合わせた変換元設定が必要です。多くの場合、SharePointの日付はUTCで保存されますが、サイト設定次第なので要注意です。

失敗パターン3:フロー内で複数回変換している

同じ日時データに対して複数のアクションで変換を適用すると、意図せず二重にオフセットが加わることがあります。実行履歴で各アクションの出力を追跡し、どの段階でずれが生じているかを確認します。

5. 管理者に確認すべき設定と情報

会社の環境でPower Automateを利用している場合、テナント全体の地域設定やデータ損失防止ポリシー(DLP)が影響することがあります。以下の情報を管理者に伝えてください。

  • フローの実行履歴のスクリーンショット(特に変換アクションの入力・出力)
  • 使用しているコネクタ(SharePoint、Office 365 Outlookなど)とそのAPIバージョン
  • テナントの地域設定(Power Platform管理センターの環境設定)が「日本」になっているか
  • フローが実行されるコネクタのタイムゾーン動作に関する既知の問題がないか

6. よくある質問(FAQ)

Q1: convertTimeZone関数で「Tokyo Standard Time」が認識されません。どうすればいいですか?

A: Power Automateで使用できるタイムゾーン名はWindowsのタイムゾーン表示名に準拠しています。正しい名称は「Tokyo Standard Time」です。スペースや大文字小文字に注意してください。もし動作しない場合は、代わりに「Asia/Tokyo」を試すこともできますが、非推奨です。動作確認には以下の式をComposeアクションでテストしてください:convertTimeZone('2025-03-15T00:00:00Z', 'UTC', 'Tokyo Standard Time')。これで正しく変換されれば、元のデータ側の問題です。

Q2: 実行履歴で出力が空になっています。どう解釈すればいいですか?

A: 出力が空の場合は、アクションがスキップされたか、エラーが発生してその後続のアクションが実行されなかった可能性があります。履歴の「エラー」タブを確認し、具体的なエラーメッセージ(例:「Invalid template」など)を探してください。多くの場合、convertTimeZoneの引数にnullや空文字が渡されたことが原因です。

Q3: フローは成功しているのに、変換結果が期待と異なります。原因は何ですか?

A: 成功ステータスでも、ロジック上のミスは検出されません。まずは実行履歴で変換アクションの出力を確認し、期待する値との差を調べてください。例えば、時刻が9時間ずれていない場合は、変換元タイムゾーンがUTCでない可能性があります。また、フロー内で後から別の変換が適用されていないか、アクションの順序を確認してください。

まとめ

Power Automateにおける日本時間変換のトラブルは、実行履歴の入出力を丁寧に比較することで、ほとんどの原因を特定できます。具体的には、変換アクションの入力データにタイムゾーン情報が含まれているか、convertTimeZone関数の引数が正しいか、フロー内で二重変換がないかを確認します。判断に迷った場合は、簡単なテストフローで変換動作を検証すると効率的です。管理者に問い合わせる前に、実行履歴のスクリーンショットを取得しておけば、スムーズに原因を伝えられます。これらの手順を踏めば、日本時間変換の失敗に悩まされることはなくなるでしょう。


ADVERTISEMENT

この記事の監修者
✍️

超解決 第一編集部

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

ADVERTISEMENT