【Power Automate】休日を除く計算が想定どおり進まない時の実行履歴と設定値の確認

【Power Automate】休日を除く計算が想定どおり進まない時の実行履歴と設定値の確認
🛡️ 超解決

Power Automateで営業日計算や休日を除いた日付計算を実装しても、実際のフロー実行結果が期待と異なるケースは少なくありません。特に祝日や会社独自の休業日が正しく認識されず、処理がずれてしまうことがよくあります。原因は休日リストの設定ミスやタイムゾーンの扱い、関数の使い方の誤解など多岐にわたります。この記事では、計算結果が想定どおりにならない場合に、実行履歴の詳細と各設定値を系統的に確認する方法を解説します。

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

  • 最初に見る場所: 実行履歴の各アクションの入力値・出力値、エラーメッセージ、およびアクションの設定画面内の休日関連パラメーター。
  • 切り分けの軸: 休日リストの内容・フォーマット、タイムゾーンとUTCの違い、関数(workday, addDaysなど)の仕様の理解不足、トリガーの条件設定。
  • 注意点: 会社の共有休日カレンダーを参照する場合、アクセス権限やキャッシュの影響で最新の休日が取得できないことがあります。管理者に確認の上、設定を見直してください。

ADVERTISEMENT

休日を除く計算が失敗する代表的な原因

休日リストの定義ミス

Power Automateで休日を除く計算を行う際、多くの場合は関数workdayaddDaysに休日リストを配列で与えるか、Office 365のカレンダーから取得します。休日リストに日付のフォーマットが統一されていない(例:"2024-12-25""12/25/2024"が混在)と、正しく除外されません。また、リストに休日が漏れている、または不要な日付が含まれているケースもよくあります。

タイムゾーンとUTCのズレ

Power Automateのアクションは基本的にUTCタイムゾーンで動作します。そのため、utcNow()で取得した現在日時をそのまま日付計算に使うと、ローカルの日付とずれる可能性があります。特に深夜0時付近の実行では、日付が1日ずれることがあります。このずれが休日判定に影響し、結果が想定と異なることがあります。

関数の仕様の誤解

例えばworkday(startDate, days, [holidays])関数では、開始日が休日の場合、その日はカウントせず次の営業日から計算が始まります。しかし、開始日を休日として除外したいのか、開始日が休日でもその日を1日目とみなすのかによって結果が変わります。この仕様を誤解していると、想定とずれます。

実行履歴で確認すべきポイント

各アクションの入力と出力を展開する

  1. Power Automate ポータル(make.powerautomate.com)にサインインし、該当のフローを開きます。
  2. 左メニューから「実行履歴」を選択し、問題が発生した実行をクリックします。
  3. 実行画面で各アクションの「入力」と「出力」を展開します。特に日付計算を含むアクションに注目してください。
  4. 入力値にある開始日、営業日数、休日リストの内容を確認します。休日リストが正しく渡されているか、フォーマットは適切か(標準のISO 8601形式であること)をチェックします。
  5. 出力値の日付が期待する値と一致しているか比較します。もし異なる場合、その差分が休日によるものか、タイムゾーンによるものか分析します。

エラーメッセージの活用

実行履歴にエラーが表示されている場合、そのメッセージから原因を特定できます。例えば、「InvalidTemplate」や「BadRequest」は関数の引数が間違っている可能性が高いです。また、休日リストのサイズが大きすぎる場合などもエラーになります。

設定値の確認手順:休日リストと関数の使い方

休日リストの定義を確認する

  1. フロー編集画面で日付計算アクション(「Apply to each」の中の「Compose」や「日付計算」アクションなど)を開きます。
  2. 休日リストが静的な配列として書かれている場合、その内容をすべて確認します。日付がyyyy-MM-dd形式(例:"2024-12-25")になっているか確認してください。他の形式(MM/dd/yyyyなど)は正しく認識されません。
  3. 休日リストをOffice 365カレンダーから動的に取得している場合、そのカレンダーの権限と最新状態を確認します。カレンダーに休日イベントが正しく登録されているか、イベントの件名などフィルター条件が適切かをチェックします。
  4. 休日リストが変数に格納されている場合、その変数が意図した値になっているか、フロー内の別のアクションで上書きされていないか確認します。

関数パラメーターの順序と値を再確認する

workday関数は第1引数に開始日(日付型)、第2引数に加算する営業日数(整数)、第3引数に休日リスト(配列)を指定します。うっかり第2引数と第3引数を入れ替えたり、休日リストを省略してしまうと、休日が考慮されません。また、addDays関数は単純に日数を加算するだけなので、休日を除外したい場合はworkdayを使う必要があります。フロー内で両方を混在させていないか確認してください。

タイムゾーン補正を確認する

開始日をutcNow()から取得している場合、convertFromUtc(utcNow(), 'Tokyo Standard Time', 'yyyy-MM-dd')のようにローカル日付に変換してから使用します。これを行わないと、UTCの日付で計算が行われ、休日判定がずれる原因になります。

確認項目 チェック内容 正常な例 異常な例
休日リストの形式 日付がISO 8601形式(yyyy-MM-dd)か [“2024-12-25″,”2025-01-01”] [“12/25/2024″,”2025/01/01”]
タイムゾーン変換 開始日にUTCのまま使っていないか convertFromUtc(utcNow(),’Tokyo Standard Time’) utcNow() をそのまま使用
関数の選択 営業日計算にworkdayを使用しているか workday(outputs(‘Compose’),5,holidays) addDays(outputs(‘Compose’),5) (休日無視)
休日リストの動的参照 カレンダーから取得する場合、正しいイベントが取得できているか フィルタークエリでisAllDayEvent eq true など フィルターなしで全てのイベントを取得

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

開始日が休日の場合のカウント方法の誤解

workday関数は開始日が休日である場合、その日は営業日にカウントせず、次の営業日を起点として計算します。例えば、開始日2024-12-25(水)(祝日)で営業日数1を指定すると、2024-12-26(木)が返ります。もし開始日を含めて翌営業日としたい場合は、営業日数から1を引くか、開始日を調整する必要があります。この仕様を理解していないと、計算結果が1日ずれることがあります。

休日リストの更新漏れ

静的な休日リストをフロー内に直接記述している場合、祝日が変更されたり新しい祝日が追加されると、フローを更新しない限り古いリストのまま動作します。この問題を防ぐには、Office 365の共有休日カレンダーを参照する方法が有効です。ただし、カレンダーのキャッシュが原因で最新の休日が反映されないこともあるため、フロー実行時に強制的に再取得する処理(例:毎回カレンダーから取得する)を組み込むと安心です。

UTCとローカル時間の境界付近での不整合

たとえば、午前3時にフローが実行され、utcNow()が2024-12-26T18:00:00Z(日本標準時では2024-12-27午前3時)を返す場合、日付だけ見ると2024-12-26となります。この日を開始日として営業日計算を行うと、実際の日本時間の日付とずれます。このような場合は、必ずconvertFromUtcでローカル日付に変換してから計算に使います。

管理者に依頼すべき確認事項

フローが会社全体の休日カレンダーを参照している場合、以下の点を管理者に確認してください。

  • カレンダーのアクセス権限: フローが使用するサービスアカウントまたは接続に、そのカレンダーを読み取る権限があるか。権限がないと休日データを取得できず、エラーは出ないが空配列が渡されます。
  • 休日イベントの形式: イベントが終日イベントとして登録されているか。予定が時間指定の場合、フロー側でフィルター条件が異なります。
  • テナント全体の休日設定: Microsoft 365には「営業時間と場所」の設定がありますが、Power Automateの標準関数はこれを直接参照しません。代わりに、組織が配布している会社休日カレンダーのメールボックスを指定する必要があります。

再発防止のための運用ルール

休日計算のトラブルを再発させないためには、以下のルールをチーム内で共有しましょう。

  • デバッグ用の出力を追加する: 日付計算アクションの直後に、計算結果や使用した休日リストをメールやファイルに出力するアクションを配置すると、実行履歴を見なくても問題を把握できます。
  • 定期的なテスト実行: 特に祝日が近い時期(年末年始、GWなど)には、事前にテストフローを手動実行して結果が正しいか確認します。
  • 休日リストのバージョン管理: 静的なリストを使う場合は、コメントに更新日を記入し、変更履歴を残します。動的なカレンダー参照が推奨です。
  • ドキュメント化: フローの説明欄に、使用している関数の引数や休日リストの取得元、タイムゾーン補正の有無を明記しておくと、後任者が修正しやすくなります。

よくある質問

Q1: 休日リストを毎年更新する必要がありますか?
A: 静的な配列で記述している場合は毎年手動更新が必要です。Office 365の共有休日カレンダーを参照している場合、カレンダーが自動更新されていれば、フロー側の変更は不要です。ただし、カレンダー自体が最新であることを確認してください。

Q2: UTCとローカル時間の違いはどのように影響しますか?
A: フローの日付計算はUTCで行われるため、ローカル時間で午前0時に近い時間帯に実行すると、UTCの日付が1日ずれることがあります。その結果、休日判定がずれ、営業日計算が想定より1日早くなったり遅くなったりします。必ずローカル日付に変換してから使用してください。

Q3: アクションの「実行条件」設定は休日計算に影響しますか?
A: いいえ、実行条件はアクションを実行するかどうかの制御であり、日付計算のロジック自体には影響しません。ただし、条件が誤っていて日付計算アクション自体がスキップされている可能性があります。その場合は実行履歴でアクションがスキップされたかどうかを確認してください。

まとめ

休日を除く計算が想定どおり進まない場合、まず実行履歴で各アクションの入力値・出力値を確認し、休日リストの形式や関数の使い方、タイムゾーン補正の有無をチェックします。特に、workday関数の仕様(開始日が休日の扱い)とUTCとローカル時間のずれは頻出の原因です。静的な休日リストは更新漏れのリスクがあるため、可能ならOffice 365カレンダーの動的参照に切り替えると管理が楽になります。また、デバッグ用出力を追加しておけば、問題発生時の原因特定が迅速になります。


この記事の監修者
✍️

超解決 第一編集部

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