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

「月末前の経費精算リマインド」「毎朝の未処理チェック」「期限を過ぎた書類の督促」。カレンダーと台帳を見て人が動いている仕事は、Power Automateの定期実行で自動化できる候補です。¹ ただし、担当者の記憶やOutlookの予定表をフローへ置き換えるには、「何時に起動するか」だけでなく、休日の扱いと、止まったときに気づく方法まで決める必要があります。

この記事では、対象業務を決める → 起動時刻を設定する → 日本時間の日付を作る → 営業日・締め日を判定する → 通知する → 実行を確認する、という順に説明します。和暦・祝日・締め日をシステム全般でどう扱うかは、別記事「業務アプリの和暦・祝日・締め日処理 ── 改元に強い設計とJapaneseCalendar・営業日計算の実務」を参照してください。本記事は、その考え方をクラウドフローに適用する実践編です。

1. まず結論 ── 起動と業務上の判定を分ける

Recurrenceは「いつフローを起動するか」を決めるものです。「今日が処理すべき日か」は、フロー内の日付式と休日マスタで判断します。 固定日ならトリガーだけで済ませ、日付が変動する場合に毎日実行と判定を組み合わせる、という使い分けです。¹²

特に混同しやすいのは、「平日」と「営業日」、トリガーのタイムゾーンと式のutcNow()です。曜日指定だけでは祝日は除かれず、トリガーで日本時間を選んでもutcNow()はUTCのままです。朝8時台のフローでは、日本時間へ変換しない「今日」が前日になります。²³⁴⁵

定期実行フローは、処理しない日にも理由が分かるようにします。連続失敗・連続スロットリングによる14日での自動オフ、条件付きの90日未起動による停止、実行履歴の既定28日という注意点と例外は、8章にまとめます。⁶⁷

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全18件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

2. 対象業務を決める ── 通知と確定処理の境界

2.1. カレンダーと台帳を見ている仕事を洗い出す

最初に行うのは、フローの作成ではなく業務の仕分けです。「何を見て」「どの日に」「誰が動いているか」を書き出し、次の表で定期実行との相性を確認します。

2.2. 休日の調整を暗黙知のままにしない

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

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

2.3. 「気づかせる」と「確定させる」を分ける

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

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

3. 起動時刻を設定する ── Recurrenceの基本と6つの罠

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

先に全体像を早見表にします。国内向けの業務フローで踏みやすい順に並べました(6は海外拠点を含む場合だけの話です)。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 日本時間の「今日」を作り、日付を判定する

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

4.1. 最初に日本時間へ変換する

変数の値、または「作成(Compose)」の入力欄で式タブを開き、次の式を入力します。トリガーの開始時刻欄に書く式ではありません。

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

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

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

4.2. 変数とComposeを使い分ける

Power Automateを触り始めた段階で迷うのがここなので、先に決めておきます。

• 変数を初期化する(Initialize variable): 「アクションの追加」で「変数」の中にあるアクションです。名前・種類(文字列など)・値を指定して作り、以降はvariables('today')のように参照します。ループの中で値が変わるものや、後から「変数の設定」で上書きしたいものはこちらです。
• 作成(Compose): 「アクションの追加」でcomposeを検索すると「データ操作」の下に出てくるアクションで、「入力」に書いた式の結果をそのまま保持します。同じ内容を何度も書かずに済ませるためのアクションなので¹²、「日本時間の今日」のように一度計算したら変わらない値はこちらが向いています。参照はoutputs('Today')のようにアクション名で行います。
• 式そのものを書く場所: どちらのアクションでも、値の入力欄を選ぶと動的なコンテンツと式を選ぶパネルが開くので、「式」タブ(fxのアイコンが目印です)に上のconvertTimeZone(...)を貼り付けて確定します。デザイナーのバージョンによって見た目は変わりますが、「入力欄をクリックしてから式タブ」という順序は同じです。
• アクション名や変数名は式から参照するため、英数字で付けておくと安全です(名前に含まれる空白はアンダースコアに置き換わります)。

4.3. 月初・月末・締め日の判定式

以降の式に出てくる今日は、説明用の置き換え記号です。そのまま入力する文字列ではありません。 実際のフローでは、4.1節で作った値の参照variables('today')またはoutputs('Today')へ読み替えます。6章の月末と残り日数も、同じように計算結果を保持するアクションや変数への参照です。

日本時間の「今日」を作った後は、次の式を組み合わせます。

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

5. 営業日だけ処理する ── 休日マスタと冒頭のガード

5.1. 祝日と会社休業日を分けて管理する

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

Power Automateでの持ち方は、SharePointリストに「祝日マスタ」(日付列+名称列)を作るのが手軽です。一次ソースには、内閣府が公表している昭和30年から翌年分までの祝日月日・名称のCSVが使えます(振替休日も行として含まれます)。¹³ 公表されているのは確定分だけなので、年1回、翌年分をマスタへ取り込む作業を業務カレンダーに載せるところまでが設計です。更新を忘れると、翌年の祝日に督促が飛ぶ形でそのまま誤動作になります。

また、夏季休業や創立記念日のような会社休業日は、祝日マスタに混ぜず別リストにしてください。「銀行振込の期日判定は祝日だけ見る」「社内督促は会社休業日も見る」のように、用途によって参照すべき休日の集合が違うからです。

5.2. 土日と休業日を除いてから処理へ進む

以下は、土日を休みとする社内業務の構成です。Recurrenceの曜日指定(月〜金)で土日を除き、フロー冒頭で祝日と会社休業日を確認します。頻度「日」で毎日起動する構成なら、4.3節の土日判定も先に加えます。 曜日指定を使わないまま、祝日マスタの検索だけで営業日と判定しないようにしてください。

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

5.3. 休日スキップを実際の処理と見分ける

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

6. 月末・締め日を前営業日に前倒しする

6.1. 「今日が営業日」を先に確定させる

月末の締めリマインドで実際に要るのは「毎月末」ではなく「月末が休みなら前営業日」です。これは毎営業日実行のフローで「今日は営業日、かつ明日から月末までに営業日が1日もない」と判定すれば表現できます。言い換えると、「今日が今月の最終営業日か」を毎朝判定するだけで、前倒しは自動的に実現します。

この記事で一番写しにくい部分なので、式とアクション構成まで書きます。前提は、営業日ガード(前項)を通過していること ── つまり今日は営業日だと確定していることです。

flowchart TD
    Start[営業日ガードを通過<br/>今日は営業日と確定] --> Hol[今月の休日一覧を作成<br/>祝日マスタと会社休業日をGet items]
    Hol --> Days[残り日数を計算<br/>月末の日から今日の日を引く]
    Days --> Zero{残り日数は0か}
    Zero -- はい --> Run[今日が最終営業日<br/>月末処理・リマインドを実行]
    Zero -- いいえ --> Range[明日から月末までの日付配列を作成<br/>range と addDays]
    Range --> Filter[Filter arrayで土日と休日を除外]
    Filter --> Len{残った件数は0か}
    Len -- 0件 --> Run
    Len -- 1件以上 --> Skip[Terminate キャンセル済み<br/>今日は前倒し日ではない]

図1: 今日が営業日であることを確定させてから、月末までに残る営業日を調べます。

6.2. 最終営業日を判定する6ステップ

具体的な中身は次のとおりです。

1. 今月の休日一覧を作る。祝日マスタと会社休業日リストをGet itemsで今月分だけ取得し、「選択」(Select)でyyyy-MM-dd形式の文字列だけの配列にして、union()で1本にまとめます。¹⁴³ 後続の式は、休日一覧がオブジェクトではなく日付文字列の配列で、body('Holidays')から取得できる前提です。例えば、統合した配列を入力にしたSelectをHolidaysと名付け、マップをテキストモードでitem()にすれば、この形を保てます。Composeで保持する構成なら、後続のbody('Holidays')はoutputs('Holidays')へ読み替えます。

2. 月末の日付と残り日数を出す。4章の式をそのまま使います。

   月末:     addDays(startOfMonth(addToTime(今日, 1, 'Month')), -1, 'yyyy-MM-dd')
   残り日数: sub(int(formatDateTime(月末, 'dd')), int(formatDateTime(今日, 'dd')))
   

3. 残り日数が0なら、今日が月末。営業日ガードを通っている以上、今日が最終営業日です。そのまま処理へ進みます。
4. 残り日数が1以上なら、明日から月末までの日付配列を作る。「選択」(Select)アクションの開始にrange(1, 残り日数)、マップをテキストモードにしてaddDays(今日, item(), 'yyyy-MM-dd')を指定し、日付文字列の配列を作ります。range()の2つ目の引数は正の整数でなければならないため³、手順3の分岐を必ず先に置いてください(ここを省くと、月末当日だけフローがエラーで落ちます)。

5. 土日と休日を除外する。「アレイのフィルター処理」(Filter array)に手順4の出力を渡し、条件を詳細モードにして次の式を書きます。¹² createArray(0, 6)は日曜と土曜の曜日番号¹⁰、body('Holidays')は手順1で作った休日一覧です。

   @and(not(contains(createArray(0, 6), dayOfWeek(item()))),
        not(contains(body('Holidays'), item())))
   

6. 残った件数で判定する。手順5のアクション名をFilter arrayにした場合、その出力はbody('Filter_array')で参照できます(名前の空白がアンダースコアに置き換わります)。length(body('Filter_array'))が0なら「今日より後に営業日がない」= 今日が今月の最終営業日なので処理を実行、1以上なら今日は前倒し日ではないのでTerminate(キャンセル済み)で終了します。³¹⁵

6.3. 20日締めなど、月末以外の日へ応用する

「毎月20日、休日なら前営業日」のような締め日の前倒しも、同じ形です。月末日付の代わりに締め日(20日)を使い、「今日が締め日以前で、明日から締め日までに営業日がない」と読み替えるだけで、判定の構造は変わりません。導入時は、締め日が月曜・土曜・日曜・祝日に当たる月をそれぞれ選んでテストしてください。

6.4. N営業日前は数える範囲と処理量を確認する

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

7. リマインドを送る ── 対象を絞り、担当者別に1通へまとめる

7.1. 台帳の列で通知対象を決める

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

7.2. Get itemsで必要な案件だけ取得する

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

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

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

7.3. 案件ごとではなく担当者ごとに送る

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

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

全体像はこうなります。

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

図2: 営業日判定の後で対象案件を絞り、担当者ごとにまとめて通知し、結果を記録します。

7.4. 通知の性質に合わせて出口を選ぶ

通知の出口は、性質で使い分けます。以下は本記事の社内通知の運用上の比較です。Teamsは社内向け、社外宛ての正式な通知はメールを使う前提で整理しています。

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

7.5. 送る頻度・段階・止まる条件を決める

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

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

8. 運用を確認する ── 「通知なし」と「停止」を見分ける

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

8.1. 自動オフの条件と例外を確認する

トリガーやアクションが失敗し続けるフローは14日で、スロットリングされ続けるフローも14日でオフになります。さらに90日間一度もトリガーされなかったフローはオフになることがあります(所有者がプレミアムライセンスまたは容量ライセンス(Process等)を持つフローは対象外。オフになる30日前に所有者・共同所有者へ通知され、オンに戻せば継続できます)。⁶ 「四半期に1回だけ動くフロー」を作る場合は、この90日ルールに注意が要ります。

8.2. 月次処理の実行記録を別に残す

実行履歴は既定で28日しか見えない。⁷ 月次フローでは、前月分がすでに見えないこともあります。フローの最後に「実行日時・処理件数・結果」をログ用のSharePointリストへ1行追記するステップを入れておくと、「先月ちゃんと動いたか」を履歴の期限切れと無関係に確認できます。7章の図2の最後にログ記録を置いているのはこのためです。

8.3. 失敗時の通知を用意する

失敗時に管理者へ通知する分岐(実行条件の構成で「失敗した場合」に走るアクション)を入れておかないと、オフになるまでの14日間、誰も失敗に気づきません。エラー処理とリトライの組み方は「Power Automateのエラー処理とリトライ設計」で詳しく扱っています。

8.4. 所有者と接続を引き継ぐ

所有者の退職・異動も、定期実行が止まる原因になります。Recurrenceトリガーのフローは、フロー作成者の接続で実行されます。⁸ 所有者のアカウントが無効化されれば、接続が切れてフローは失敗し始め、やがてオフになります。共同所有者の設定と接続の棚卸しを稼働初日に済ませてください。¹⁶ 引き継ぎの実務は「Power Automateの属人化対策 ── 作った人が辞めてもフローが止まらないために」にまとめています。

8.5. 停止前に次回予定を確認し、取りこぼしを補う

止めていた期間の分は動かない(3章の罠5)。改修や障害対応でフローをオフにするときは、次回実行予定日を確認し、跨いでしまった場合は手動実行で補う運用を決めておきます。⁹

8.6. 本番前に境界の日付で確認する

日付の不具合は、普段の日だけでは見つかりません。4〜6章の式を導入するときは、月末・月初・うるう年の2月29日、締め日が月曜・土曜・日曜・祝日に当たる月で、想定する実行日になるか確認します。特に、月末当日に残り日数0の分岐へ入ることと、日本時間の朝9時前でも「今日」が前日にならないことを確認してください。

そのうえで、対象なし・休日スキップ・正常処理・失敗を運用上見分けられるか、完了した案件への督促が止まるかを確認します。「通知が来ないから問題なし」と判断するためには、フローが予定どおり動いていることを実行記録と合わせて確認できる必要があります。

9. まとめ ── カレンダーのルールと運用まで設計する

定期実行フローの本体は、Recurrenceの設定だけではありません。作る前には、月末や締め日が休日ならどうするか、どの休日マスタを見るか、誰が翌年分を更新するかを仕様にします。作った後には、実行記録・失敗通知・所有者と接続の引き継ぎ・停止中の取りこぼしへの対応を用意します。

実装は、タイムゾーンを明示して起動する → 日本時間の「今日」を一度作る → 営業日ガードを通す → 必要なら前倒し日を判定する → 担当者別にまとめて通知する、という順で追うと整理しやすくなります。督促には送る段階と、完了したら止まる出口も必要です。

未処理チェックや締め忘れ防止のように「気づかせる」処理はPower Automateに向いています。一方、複雑な締め処理や基幹バッチのように「確定させる」処理では、巻き戻し・リラン・整合性まで含めて、既存システムや開発側へ切り分けることを検討してください。

関連記事

• Power Automateで業務を自動化する ── クラウドフロー・デスクトップフローの使い分けとエラー処理設計
• 業務アプリの和暦・祝日・締め日処理 ── 改元に強い設計とJapaneseCalendar・営業日計算の実務
• Power Automateのエラー処理とリトライ設計
• Power Automateの属人化対策 ── 作った人が辞めてもフローが止まらないために
• Power AutomateとPowerShell/タスクスケジューラの使い分け

関連する相談領域

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

• 技術相談・設計レビュー
• Windowsアプリ開発
• お問い合わせ

参考リンク

関連する記事

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

関連トピック

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

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

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

よくある質問

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

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