合同会社小村ソフト
相談する
メニュー

Power Automateで定期実行フローを設計する ── 月末処理・営業日判定・リマインドの実務

· · Power Automate, クラウドフロー, 定期実行, 営業日, 祝日, SharePoint, Microsoft 365, 業務自動化, 技術相談

「毎月末が近づくと、経理担当が各部署に『経費精算の締切は◯日です』とメールを打つ」「毎朝始業後に、受注リストを開いて未処理が残っていないか目視で確認する」「提出期限を過ぎた書類を、台帳と突き合わせて1件ずつ督促する」。Microsoft 365を導入済みの会社でも、こうした「カレンダーと台帳を見て人が動く」仕事は意外なほど残っています。忘れると事故になるのに、忘れないための仕組みが担当者の記憶とOutlookの予定表しかない、という状態です。

Power Automateのスケジュール実行(Recurrenceトリガー)を使えば、この種の定期作業は自動化できます。ただ、日本の業務で実際に組もうとすると、すぐに3つの壁に当たります。時刻の既定がUTC(協定世界時)であること、「営業日」という概念が組み込みには存在しないこと、そして「月末」「20日締め」の判定を式で書く必要があることです。この記事では、Recurrenceトリガーの仕様と罠、日付計算の道具箱、祝日マスタによる営業日判定、督促しすぎないリマインド設計、そして定期実行フロー特有の運用リスクまでを整理します。

なお、和暦・祝日・締め日という日本の日付要件をシステム全般でどう扱うかは、別記事「業務アプリの和暦・祝日・締め日処理 ── 改元に強い設計とJapaneseCalendar・営業日計算の実務」で詳しく書きました。本記事はその考え方をPower Automateのフローに適用する実践編です。

1. まず結論

  • Recurrenceトリガーの時刻は、タイムゾーンを指定しなければUTC扱いです。「毎朝9時」のつもりが日本時間18時に動く事故は、タイムゾーン欄で「(UTC+09:00) 大阪、札幌、東京」を選び、開始時刻を明示することで防ぎます。12
  • 「平日のみ実行」は頻度「週」+曜日指定(月〜金)で作れます。ただし祝日は考慮されません。「毎月20日」のような固定日は開始日時+頻度「月」で作れますが、「毎月末」「締め日が休日なら前営業日」のような変動する日付は指定できないため、「毎日実行して式で判定」が実務解です。2
  • 式の中のutcNow()も常にUTCです。日本時間の「今日」はconvertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time')で変換してから使います。朝8時台のフローで変換を忘れると「今日」が前日になります。34
  • 日本の祝日を判定する仕組みは組み込みにはありません。式の関数一覧にも祝日関数はなく5、祝日マスタ(SharePointリスト等)を自前で持ち、フロー冒頭で「今日は営業日か」を判定して営業日でなければ終了する構成が定石です。マスタの一次ソースには内閣府の祝日CSVが使えます。6
  • リマインドは「1件1通」ではなく担当者別にまとめて1通にします。Filter arrayやCreate HTML tableなどのデータ操作アクションを使うと、Apply to eachの入れ子を避けて読みやすく組めます。7
  • 定期実行フローは「動いていないこと」に気づきにくい。連続失敗14日でオフ・90日間トリガーなしでオフ・実行履歴は既定28日という仕様を前提に、失敗通知と実行記録を最初から設計します。89

2. 「人がカレンダーを見て動く業務」の棚卸し

最初にやるべきは、フローを作ることではなく「カレンダーを見て動いている業務」を洗い出して、定期実行に向くかどうかを仕分けることです。

業務 定期実行との相性 補足
毎朝の未処理・異常チェック(受注、申請、在庫) 向く 判定条件がリストの列で表現できることが前提
月末・締め日前の一斉リマインド(経費精算、勤怠締め) 向く 営業日調整(月末が休日なら前営業日)の仕様化が必要
提出期限超過の督促(書類、報告、承認放置) 向く 台帳がデータ(SharePointリスト等)になっていることが前提
定期レポートの集計・配信 条件付きで向く 集計が単純ならフロー、複雑ならフローは配信だけ担当
月次の請求・支払など確定処理(締め、赤黒、再計算) 向かないことが多い 分岐と例外が多く、失敗時の巻き戻しが必要(8章)
基幹システムを跨ぐ夜間バッチ 向かない 開発領域。リラン・整合性の設計が本体

仕分けの基準は3つです。判定条件がデータで表現できるか(「なんとなく怪しい案件」は自動化できません)、実行日のルールが言語化できるか、失敗しても翌日リカバリできるか(できないものは8章の開発領域)です。

このうち2つ目が、日本の業務では一番の難所になります。「毎月末に締めリマインド」と言っても、実際に人がやっているのは「月末が土日祝なら前営業日に前倒しして、ゴールデンウィークの年は連休前に送る」といった調整です。この暗黙知を仕様として書き出す作業が、フロー作りの本体だと考えてください。ここが曖昧なままフローだけ作ると、「祝日に督促メールが飛んだ」「連休前のリマインドが連休中に飛んだ」という形で信頼を失います。

3. Recurrenceトリガーの基本と罠

スケジュール実行のクラウドフローは、「スケジュール済みクラウドフロー」として作成し、Recurrence(繰り返し)トリガーで頻度と間隔を設定します。1 頻度は秒・分・時間・日・週・月から選べ、間隔の最小は60秒、最大は500日です。8 仕様自体は単純ですが、罠が多いトリガーでもあります。

罠1: 既定はUTC ── 「9時のはずが18時」

一番多い事故です。Recurrenceトリガーの開始時刻は、タイムゾーンを選択しない場合、末尾にZを付けたUTC形式(YYYY-MM-DDThh:mm:ssZ)で解釈されます。タイムゾーン欄で日本を選べば、開始時刻はそのタイムゾーンのローカル時刻(YYYY-MM-DDThh:mm:ss、Zなし)として扱われます。12 「毎朝9時に通知するフロー」を作るなら、タイムゾーンを「(UTC+09:00) 大阪、札幌、東京」にして開始時刻を9:00にする、が正解です。

罠2: 開始時刻を指定しないと、保存した瞬間に1回動く

開始日時を指定しない場合、フローを保存した時点で最初の実行が即座に走ります。2 テスト中ならよいですが、督促メールを組み込んだフローを夕方に保存して、その場で全員に督促が飛ぶ、という事故になり得ます。開始日時は必ず指定してください。

さらに、詳細オプションの「設定時刻(これらの時間/これらの分)」を指定しない場合、2回目以降の実行時刻は前回実行からの相対で計算されるため、遅延の積み重ねで実行時刻が少しずつずれて(ドリフトして)いきます。2 毎日決まった時刻に動かしたいフローでは、開始日時に加えて実行時刻も明示しておくのが安全です。

罠3: 「平日のみ」はできるが、月次の詳細指定は限定的

頻度を「週」にすると曜日(月〜金)を選べ、「日」または「週」なら実行時刻(時・分)も指定できます。つまり「平日の朝9時だけ」はトリガーの設定だけで作れます。一方、これらの詳細オプションが使えるのは頻度が「日」「週」のときだけで、頻度「月」には「毎月20日」「毎月末」のような日付指定の欄がありません。2

ただし、日付が固定の月次であれば毎日動かす必要はありません。開始日時を対象日(例: 来月の20日 9:00)に設定して頻度を「月」にすれば、実行は開始日時を起点に1か月ごとになるため、「毎月20日の9時」はトリガーの設定だけで作れます。2 月に12回で済むフローを毎日365回起動して判定で捨てるのは、実行履歴が読みにくくなり要求数も無駄に消費するので避けます。

「毎日実行+フロー冒頭の式で今日が対象日かを判定する」構成が必要になるのは、日付が変動する月次です。「毎月末」(月によって28〜31日)、「20日が土日祝なら前営業日」、「毎月第N営業日」のような日付はトリガーでは表現できません。この判定式を次章で扱います。なお29〜31日を開始日にした固定日指定は、その日が存在しない月の挙動を作り込みで確かめる必要があるため、月末付近の処理は最初から「毎日実行+判定」側に寄せておくのが安全です。

罠4: 夏時間 ── 海外拠点向けだけ注意

タイムゾーンを選択せずUTCの時刻で書いた場合、夏時間(DST)のある地域では切り替わりのたびに実行時刻が1時間ずれます。タイムゾーンを選択しておけば、季節の切り替えに追従してスケジュールが維持されます。10 日本には夏時間がないので国内だけなら実害はありませんが、海外拠点向けの通知を同じフローで扱う場合は、拠点のタイムゾーンを明示的に選ぶ必要があります。

罠5: トリガーに書いた式は保存時に固定される

トリガーの入力にutcNow()のような式を書くと、その値はフローを保存した時点で計算されて固定されます。実行のたびに再計算はされません。11 「開始時刻を今日にしたいから」とトリガーに式を入れる発想は通用しない、と覚えておいてください。

罠6: 止めていた間の分は、後から実行されない

Recurrenceトリガーは、フローがオフだった期間に過ぎたスケジュールを再開後にまとめて処理せず、次の周期から再開します。10 「月末処理のフローを改修のため数日オフにしていたら、ちょうど月末実行日を跨いでいて今月分が動かなかった」という事故があり得ます。定期実行フローを止めるときは、次の実行予定日を確認してから止める運用にしてください。

4. 日付計算の道具箱 ── 月末・月初・締め日を式で判定する

フロー内の日付計算は、Logic Appsと共通の式(関数)で書きます。5 前提として、utcNow()が返すのは常にUTCの現在時刻です。12 そこで、フローの最初に「日本時間の今日」を作って変数(またはCompose)に入れ、以降はそれを使い回す構成にすると、式が読みやすくなります。

convertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')

convertTimeZone(タイムスタンプ, 変換元, 変換先, 書式)はタイムゾーン変換の関数で13、タイムゾーン名はWindowsのタイムゾーン一覧の名前を使います。日本は「Tokyo Standard Time」です。4 式を書きたくない場合は、同じことをする「タイムゾーンの変換」アクションもあります。13

なぜ変換が必須かというと、UTCと日本時間には9時間の差があるからです。日本時間の朝9時までは、UTCではまだ前日です。朝8時に動くフローでformatDateTime(utcNow(), 'yyyy-MM-dd')と書くと、返ってくる「今日」は前日の日付になります。日付のずれは実行時刻によって出たり出なかったりするため、テストでは気づきにくく、本番で「月初のはずの処理が月末最終日にも動いた」といった形で発覚します。

「日本時間の今日」(以下今日)を作った後の判定パターンをまとめます。

やりたいこと 式の例 補足
曜日を取る dayOfWeek(今日) 0=日曜、1=月曜、…、6=土曜。12
土日かどうか or(equals(dayOfWeek(今日), 0), equals(dayOfWeek(今日), 6)) 「5より大きければ週末」と書くと日曜(0)を取りこぼします12
月初(1日)かどうか equals(formatDateTime(今日, 'dd'), '01') startOfMonth()で月初日付そのものも取れます5
20日締めの締め日かどうか equals(formatDateTime(今日, 'dd'), '20') 締め日はハードコードせず環境変数や設定リストに出すと使い回せます
月末かどうか not(equals(formatDateTime(今日, 'MM'), formatDateTime(addDays(今日, 1), 'MM'))) 「今日の月と明日の月が違えば今日は月末」。2月でもうるう年でも正しく動きます
今月の月末日付 addDays(startOfMonth(addToTime(今日, 1, 'Month')), -1, 'yyyy-MM-dd') 「翌月の月初の前日」として導出。月の日数を意識せずに済みます
N日前・N日後 addDays(今日, -3) / addDays(今日, 7) 暦日の加減算。営業日ベースは5章

addDays、addToTime、startOfMonth、formatDateTime、dayOfWeekは、いずれもLogic Apps/Power Automate共通の式リファレンスに定義された関数です。5 表の組み合わせ式そのものは筆者の実装パターンなので、導入時は月末・月初・うるう年(2月29日)を跨ぐ日付でテストしてから本番に載せてください。特定の日にしか発症しない日付バグの怖さと事前に試すべき日付の選び方は、和暦・祝日・締め日の記事の4章で書いたとおりです。

5. 営業日判定 ── 祝日はマスタで持つ

組み込みの祝日判定は存在しない

繰り返しになりますが、Power Automateに日本の祝日を判定する組み込み機能はありません。Recurrenceトリガーの曜日指定は文字どおり曜日しか見ませんし、式の関数一覧にあるのは日付の加減算・整形・タイムゾーン変換までで、「この日は祝日か」を返す関数はありません。5 祝日を計算式で求めること自体が原理的に不可能(春分・秋分は前年に確定し、法改正や特別措置法で祝日自体が動く)という事情は、和暦・祝日・締め日の記事の3章で詳しく書きました。結論は同じで、祝日はデータ(マスタ)+更新運用で持つが正解です。

Power Automateでの持ち方は、SharePointリストに「祝日マスタ」(日付列+名称列)を作るのが手軽です。一次ソースには、内閣府が公表している昭和30年から翌年分までの祝日月日・名称のCSVが使えます(振替休日も行として含まれます)。6 公表されているのは確定分だけなので、年1回、翌年分をマスタへ取り込む作業を業務カレンダーに載せるところまでが設計です。更新を忘れると、翌年の祝日に督促が飛ぶ形でそのまま誤動作になります。また、夏季休業や創立記念日のような会社休業日は、祝日マスタに混ぜず別リストにしてください。「銀行振込の期日判定は祝日だけ見る」「社内督促は会社休業日も見る」のように、用途によって参照すべき休日の集合が違うからです。

フロー冒頭の「営業日ガード」

営業日にだけ動かしたいフローは、Recurrenceの曜日指定(月〜金)に加えて、フロー冒頭に次の判定を置きます。

  1. 「日本時間の今日」を作る(4章)
  2. 祝日マスタに対してSharePointの「複数の項目の取得(Get items)」を実行し、フィルタークエリでHolidayDate eq '今日'のように今日の日付を検索する14
  3. 会社休業日リストにも同じ検索をする
  4. 1件でもヒットしたら、「終了(Terminate)」アクションで実行を止める

Terminateは、フローの実行をその場で止めて指定した状態(成功/失敗/キャンセル)で終了させるアクションです(Apply to eachやDo untilループの中には置けません)。15 ここで状態を「キャンセル済み」にしておくと、実行履歴上で「営業日でないためスキップした日」と「実際に処理が動いた日」を一目で見分けられます。すべて「成功」で揃えてしまうより、後からの調査が楽になります。

「前営業日に前倒し」と「N営業日前」

月末の締めリマインドで実際に要るのは「毎月末」ではなく「月末が休みなら前営業日」です。これは毎営業日実行のフローで「今日は営業日、かつ明日から月末までに営業日が1日もない」と判定すれば表現できます。実装としては、明日から月末日付(4章の式)までの日付を順に回し、土日でも祝日マスタにもない日が見つかった時点で「今日は最終営業日ではない」と確定して抜ける形になります。

「支払期日の3営業日前に督促」のようなN営業日前も、発想は同じ読み替えです。「期日のN営業日前になったら」を「毎営業日に実行し、今日から期日までの営業日数を数えてNと一致したら」に置き換えます。営業日の数え方は「土日でない・祝日マスタにない・会社休業日にない」日をカウントするだけです。ただし、フローのループで日付を1日ずつ数える処理は、対象案件が数百件を超えると件数×日数のループになり、実行時間もAPI呼び出しも膨らみます。その規模になったら、営業日計算をフローの外(データベースの営業日テーブルや小さなAPI)へ出すか、8章の開発領域として扱うほうが健全です。

6. リマインド・督促の設計 ── 担当者別にまとめて1通

前提: 台帳がデータになっていること

期限超過の督促を自動化できるのは、「何が・誰の担当で・いつ期限か」がデータとして取れる場合だけです。台帳が共有フォルダのExcelでメール添付で回っている状態なら、先にSharePointリストへの置き換えを検討してください(「Excel台帳をSharePointリストへ置き換える」で扱っています)。以下はSharePointリストに「期限」「状態」「担当者」列がある前提です。

抽出は取得時に絞る

期限超過の抽出は、リスト全件を取ってからフロー内で条件分岐するのではなく、Get itemsのフィルタークエリ(ODataフィルター)でサーバー側で絞り込みます。14

DueDate lt '2026-07-18' and Status ne '完了'

日付部分には4章で作った「日本時間の今日」の式を埋め込みます。フィルタークエリの列名は画面の表示名ではなくSharePointの内部名で書く必要があること、既定では100件しか返らないため件数が多いリストでは上限(Top Count)の指定やページネーションの設定が要ることに注意してください。14

Apply to each地獄を避ける ── まとめて1通の作り方

抽出結果をそのままApply to eachで回して1件ずつメールを送ると、担当者Aに未処理が10件あれば毎朝10通届きます。これを数週間続けると通知は確実に読まれなくなり、リマインドの仕組み自体が死にます。通知は担当者別に1通へまとめるのが原則です。データ操作アクションを使うと、次の流れで組めます。7

  1. Selectで抽出結果から担当者メールアドレスの配列を作り、union()で重複を除いた「今日通知すべき担当者一覧」を作る5
  2. 担当者一覧をApply to eachで回し、その中でFilter arrayを使って「この担当者の件だけ」を抽出する
  3. Create HTML tableで件名・期限・状態の表に整形し、メール(またはTeamsメッセージ)本文に埋め込んで1通だけ送る(メールの場合はHTML表示を有効にします7)

全体像はこうなります。

あるないなしありRecurrenceトリガー平日 朝9:00 タイムゾーン: 大阪、札幌、東京日本時間の今日を作成convertTimeZone祝日マスタ・会社休業日に今日があるかTerminate キャンセル済み営業日でないため終了Get items期限超過かつ未完了を抽出対象あり?終了 通知なしSelectで担当者一覧を作成unionで重複排除担当者ごとにループFilter arrayこの担当者の件だけ抽出Create HTML tableで表に整形担当者へ1通だけ通知Teams または Outlook実行結果をログ用リストへ記録

TeamsとOutlookの使い分け

通知の出口は、性質で使い分けます。

観点 Teams(チャット・チャネル) Outlook(メール)
気づきやすさ 高い。ただし流れて埋もれやすい 通知疲れしにくいが、受信トレイに埋もれる
記録性 弱い。後から探しにくい 残る。督促の証跡として使える
宛先 社内のみ 社外にも送れる
向く通知 毎朝の未処理サマリーなど日次の軽い通知 締め切りの正式な通告、督促の記録が要るもの、社外宛て

日次のサマリーはTeams、締め日前の正式なリマインドと期限超過の督促はメール、のように分けるのが定番です。両方に同じ内容を流すのは、通知の総量を増やすだけなのでお勧めしません。

督促しすぎない設計

リマインドの自動化で一番怖いのは、送りすぎて全部無視されることです。人手の督促には「言いにくいから頻度が抑えられる」という自然なブレーキがありますが、フローにはありません。設計で組み込みます。

  • 総量を設計する。毎朝・全員・全件が最悪のパターンです。日次で送るのは当日期限と超過分だけ、事前リマインドは3営業日前と前日の2回だけ、のように送る条件を絞ります。
  • 段階を付ける。まず本人だけに通知し、超過がN営業日続いたら上長を宛先に加える、のようにエスカレーションを分けます。全部を最初から上長に送ると、通知はただの騒音になります。
  • 止まる仕組みを作る。担当者がリストの状態列を「完了」にすれば翌日から通知が止まる、という出口を必ず用意します。完了報告がメール返信のままだと、フローは督促を続け、担当者はフローを憎むようになります。
  • 「通知が来ない=問題なし」を信頼できる状態に保つ。これは次章の監視とセットで初めて成立します。

7. 運用の注意 ── 定期実行フローは「止まったことに気づけない」

イベント起動のフローは、業務側が「申請したのに動かない」と気づいてくれます。定期実行フローにはその検知器がありません。月末リマインドが止まっていても、誰も何も言わないまま締めが遅れるだけです。運用設計では次の仕様を前提にしてください。

  • フローが自動的にオフになる条件がある。トリガーやアクションが失敗し続けるフローは14日で、スロットリングされ続けるフローも14日でオフになります。さらに90日間一度もトリガーされなかったフローはオフになることがあります(所有者がプレミアムライセンスまたは容量ライセンス(Process等)を持つフローは対象外。オフになる30日前に所有者・共同所有者へ通知され、オンに戻せば継続できます)。8 「四半期に1回だけ動くフロー」を作る場合は、この90日ルールに注意が要ります。
  • 実行履歴は既定で28日しか見えない。9 月次フローだと直近1回分しか確認できない計算です。フローの最後に「実行日時・処理件数・結果」をログ用のSharePointリストへ1行追記するステップを入れておくと、「先月ちゃんと動いたか」を履歴の期限切れと無関係に確認できます。6章の図の最後にログ記録を置いているのはこのためです。
  • 失敗に気づく仕組みをフロー自身に持たせる。失敗時に管理者へ通知する分岐(実行条件の構成で「失敗した場合」に走るアクション)を入れておかないと、オフになるまでの14日間、誰も失敗に気づきません。エラー処理とリトライの組み方は「Power Automateのエラー処理とリトライ設計」で詳しく扱っています。
  • 所有者の退職・異動でスケジュールごと止まる。Recurrenceトリガーのフローは、フロー作成者の接続で実行されます。11 所有者のアカウントが無効化されれば、接続が切れてフローは失敗し始め、やがてオフになります。共同所有者の設定と接続の棚卸しを稼働初日に済ませてください。16 引き継ぎの実務は「Power Automateの属人化対策 ── 所有者・接続・引き継ぎ」にまとめています。
  • 止めていた期間の分は動かない(3章の罠6)。改修や障害対応でフローをオフにするときは、次回実行予定日を確認し、跨いでしまった場合は手動実行で補う運用を決めておきます。10

8. どこまでPower Automateでやるか

定期実行は自動化の入り口として優秀ですが、「定期的に動くもの」を何でもフローにするのは危険です。線引きの目安を挙げます。

状況 判断
毎朝の未処理チェック、期限リマインド、締め日前の一斉通知 Power Automateの得意領域。本記事の構成で十分
営業日判定・前営業日への前倒しを含む通知 Power Automate+祝日マスタで可。マスタ更新の運用をセットで決める
数百件×N営業日の計算、複数リストを突き合わせる集計 フローのループでは苦しい。ロジックを外へ出すか開発領域へ
締め日が取引先ごとに違い、赤黒訂正や再計算が絡む締め処理 分岐が爆発し、失敗時の巻き戻しも必要。受託開発・専用システムの領域
基幹システムのデータベースを跨ぐ夜間バッチ 開発領域。トランザクション・リラン・整合性の設計が本体
サーバーが1台あり、社内で完結するファイル処理・DB処理の定期実行 PowerShell+タスクスケジューラも有力。比較は別記事参照

感覚としては、「気づかせる」まではPower Automate、「確定させる」(基幹のデータを書き換える)は開発、というあたりに線があります。締め処理そのものをフローで組もうとして分岐だらけになった案件を何度か見てきましたが、たいていは「締めの実行は既存システムか受託開発、締め忘れ防止の通知だけフロー」に分け直すことで安定しました。また、クラウドを経由せずサーバー内で完結する定期処理なら、PowerShellとタスクスケジューラのほうが単純で保守しやすいこともあります。使い分けは「Power AutomateとPowerShell/タスクスケジューラの使い分け」で整理しています。

9. まとめ

定期実行フローの設計は、Recurrenceトリガーの設定よりも、その手前と後ろに本体があります。手前にあるのは「カレンダーを見て動く」暗黙知の仕様化です。月末が休日ならどうするのか、祝日は誰がいつマスタに入れるのか。ここを決めずに作ったフローは、日本のカレンダーの前で必ず誤動作します。後ろにあるのは、止まったことに気づくための運用です。実行履歴28日、自動オフの各条件、所有者退職で止まるスケジュール。定期実行フローは黙って止まる、という前提で、失敗通知と実行ログを最初から組み込んでください。

技術面の要点は3つに集約できます。時刻はタイムゾーンを明示する(既定はUTC)、日付は日本時間に変換してから判定する、祝日はマスタで持ち、フロー冒頭の営業日ガードで弾く。この3つを押さえた上で、通知は担当者別にまとめ、督促には段階と出口を付ける。ここまでやれば、「人がカレンダーを見て動く」業務のかなりの部分は、安心して任せられる定期実行フローに置き換えられます。そして、締め処理や基幹バッチのように「確定させる」処理に踏み込みたくなったときが、開発領域への切り替えを検討するタイミングです。

関連記事

関連する相談領域

合同会社小村ソフトでは、Power Automateによる定期処理・リマインドの設計レビューから、フローでは収まらない締め処理・営業日計算・基幹連携バッチの開発まで扱っています。

参考リンク

  1. Microsoft Learn, Run a cloud flow on a schedule. スケジュール済みクラウドフローの作成手順、Recurrenceトリガーのタイムゾーン欄で開始時刻をどのタイムゾーンとして扱うか指定すること、開始時刻の書式(YYYY-MM-DDTHH:MM:SSZ)について。 ↩ ↩2 ↩3

  2. Microsoft Learn, Schedule and run recurring workflows with the Recurrence trigger in Azure Logic Apps. タイムゾーン未選択時は開始時刻を末尾Z付きのUTCとして解釈すること、頻度・間隔の指定、曜日指定(weekDays)が頻度「週」のみ・時刻指定(hours/minutes)が頻度「日」「週」のみで使えること、開始日時を指定しないと保存時に最初の実行が即座に走ること、詳細な時刻指定がない場合は前回実行からの相対計算で実行時刻がドリフトすることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  3. Microsoft Learn, Customize or format date and time values in a flow. Power Automateが既定でUTCを使うこと、formatDateTimeとconvertTimeZoneを組み合わせてローカル時刻を扱う方法について。 ↩

  4. Microsoft Learn, Default Time Zones. Windowsのタイムゾーン名一覧。日本(UTC+09:00 大阪、札幌、東京)のタイムゾーン名が「Tokyo Standard Time」であることについて。 ↩ ↩2

  5. Microsoft Learn, Reference guide to functions in expressions for workflows in Azure Logic Apps and Power Automate. 式で使える日付関数(utcNow、addDays、addToTime、startOfMonth、formatDateTime、dayOfWeek、convertTimeZone等)とコレクション関数(union等)の一覧・構文。祝日を判定する関数が存在しないことの確認元。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  6. 内閣府, 「国民の祝日」について. 国民の祝日に関する法律に基づく祝日の一覧、春分の日・秋分の日が前年に確定して公表されること、振替休日の規定、昭和30年から翌年までの祝日月日・名称のCSVの提供について。 ↩ ↩2

  7. Microsoft Learn, Use data operations. Select・Filter array・Join・Create HTML table等のデータ操作アクションの使い方、HTMLテーブルをメールで送る際にIsHtmlを有効にすることについて。 ↩ ↩2 ↩3

  8. Microsoft Learn, Limits of automated, scheduled, and instant flows. 繰り返し間隔の最小60秒・最大500日、トリガーやアクションの失敗が続くフローが14日でオフになること、90日間トリガーされないフローがオフになり得ること(プレミアム・容量ライセンス所有者のフローは対象外、30日前に所有者・共同所有者へ通知)、スロットリングが続くフローが14日でオフになることについて。 ↩ ↩2 ↩3

  9. Microsoft Learn, Missing runs or triggers history for a flow. フローの実行履歴が既定で28日間しか保存されないことについて。 ↩ ↩2

  10. Microsoft Learn, Schedules for recurring workflow triggers in Azure Logic Apps. タイムゾーンを選択しない場合に夏時間の切り替えで実行時刻が1時間ずれること、タイムゾーンを選択すればスケジュールが季節変化に追従すること、Recurrenceトリガーが停止中に逃したスケジュールを後から処理せず次の周期から再開することについて。 ↩ ↩2 ↩3

  11. Microsoft Learn, Troubleshoot Power Automate trigger issues and errors. トリガーの入力に書いた式(utcNow()等)がフロー保存時に計算されて固定され、実行のたびには再計算されないこと、Recurrenceトリガーのフローがフロー作成者の接続で実行されることについて。 ↩ ↩2

  12. Microsoft Learn, Expression cookbook for cloud flows. utcNow()が常にUTCを返すこと、dayOfWeek()の戻り値が0=日曜〜6=土曜であること、「5より大きい」の判定では日曜を取りこぼすことについて。 ↩ ↩2 ↩3

  13. Microsoft Learn, Convert a time zone. convertTimeZone式の引数(タイムスタンプ・変換元・変換先・書式)と、同等の機能を持つ「タイムゾーンの変換」アクションについて。 ↩ ↩2

  14. Microsoft Learn, In-depth analysis into Get items and Get files SharePoint actions. Get itemsのODataフィルタークエリ(eq/ne/lt/gt等、式の埋め込み)、既定の取得件数が100件でTop Countで変更できること、5,000件超のリストでのページネーション設定について。 ↩ ↩2 ↩3

  15. Microsoft Learn, Schema reference guide for trigger and action types in Azure Logic Apps. Terminateアクションが実行を停止して指定した状態(Succeeded/Cancelled/Failed)を返すこと、ForeachやUntilループの中には置けないことについて。 ↩

  16. Microsoft Learn, Share a cloud flow. 共同所有者ができること(フローの編集、接続の資格情報更新等)と、接続が作成ユーザーに紐づくことについて。 ↩

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

Power Automateのスケジュールフローを日本時間の毎朝9時に動かすには？
Recurrenceトリガーのタイムゾーン欄で「(UTC+09:00) 大阪、札幌、東京」を選び、開始時刻を指定します。タイムゾーンを指定しない場合、開始時刻は末尾にZを付けたUTC(協定世界時)として扱われるため、「9:00」のつもりで設定すると日本時間の18時に動きます。また、式の中のutcNow()も常にUTCを返すので、フロー内で「今日の日付」を使うときはconvertTimeZone(utcNow(), 'UTC', 'Tokyo Standard Time', 'yyyy-MM-dd')のように日本時間へ変換してから使います。
Power Automateに日本の祝日を判定する機能はありますか？
組み込みでは用意されていません。Recurrenceトリガーの曜日指定で「平日のみ」の実行はできますが、祝日は考慮されませんし、式の関数にも祝日を返すものはありません。実務では、祝日の日付を持つマスタ(SharePointリストなど)を自前で用意し、フローの冒頭で「今日がマスタにあるか」を検索して、営業日でなければ終了する構成にします。マスタの更新元には、内閣府が公表している祝日CSVが一次ソースとして使えます。
毎月末の営業日にだけ実行するフローは作れますか？
「毎月20日」のような固定日であれば、開始日時を対象日に設定して頻度を「月」にすることで、開始日時を起点に毎月同じ日・同じ時刻の実行を作れます。一方、Recurrenceトリガーに「毎月末」を直接指定するオプションはなく、曜日や時刻の詳細指定ができるのも頻度が「日」「週」の場合だけです。月末のように日付が変動する処理は、毎日(または平日毎日)実行するフローにして、冒頭の式で「今日が月末か」「今日が営業日か」を判定し、条件に合わない日は終了する形にします。月末判定は「今日の月と明日の月が違えば今日は月末」という式で書けます。「月末が土日祝なら前営業日に実行」も、同じ構成に祝日マスタの判定を足して表現します。
定期実行フローが知らないうちにオフになっていました。なぜですか？
Power Automateには、フローが自動的にオフになる条件がいくつかあります。トリガーやアクションが失敗し続けたフローは14日で、スロットリング(制限超過)が続くフローも14日でオフになります。また90日間一度もトリガーされなかったフローはオフになることがあります(所有者がプレミアムライセンスや容量ライセンスを持つ場合は対象外で、オフになる30日前に所有者・共同所有者へ通知されます)。定期実行フローは止まっても誰も気づきにくいため、失敗時の通知と実行記録を最初から組み込んでおくことが重要です。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る