2026.10.03 DX

ワークフローシステムの通知機能の設計：承認を止めないリマインド・催促と宛先の絞り方

ワークフローシステムを入れたのに承認が止まる職場では、通知機能の設定が初期値のまま放置されていることが多くあります。承認依頼の通知は届いているのに埋もれて読まれない、期限を過ぎても誰も催促しない、休暇中の承認者で申請が数日止まる、といった滞留は、通知の宛先とタイミングと回数を決め直すことで、大半は解消できる滞留です。この記事では、通知が飛ぶイベントと経路の違い、営業日で数えるリマインドと期限の日付選択欄の扱い、自動エスカレーションの発動条件、通知過多で無視される失敗の避け方を整理します。あわせて、通知メールやチャット通知が届かない原因と、パッケージ標準の通知で足りない場合に追加開発へ進む判断基準も示します。

まとめ：ワークフローシステムの通知機能は宛先・タイミング・回数の設計で決まる滞留対策

通知機能の良し悪しを決めるのは、搭載の有無ではなく設定の中身です。承認依頼は今その申請を処理できる1人にだけ送り、申請者には差し戻しと最終結果だけを返します。CCで関係者全員に送る設定は、通知の総数を増やして既読スルーを招くので外します。

リマインドは暦日でなく営業日で数え、書式ごとに基準日数を変えます。同じ申請への催促は1ステップにつき1回までに抑え、それでも動かない申請は代理承認者か上長へ自動で回す運用にしてください。毎朝の未承認件数のまとめ通知を併用すると、1件ずつの通知を減らしつつ取りこぼしを防げます。

通知が届かない問題は、ワークフロー製品ではなく経路側で起きます。自社ドメインから送るメールは送信ドメイン認証を整え、TeamsやSlackへの通知は投稿上限を超えないよう送信をまとめます。チャット上で承認まで完結させたい、勤怠や人事のデータで宛先を自動で切り替えたい、という要件はパッケージの標準設定では届かないことが多く、追加開発の対象です。

ワークフローシステムの通知機能の種類と届くタイミング：申請・承認・差し戻し・完了の4場面

承認依頼・差し戻し・最終承認・コメントの4イベントと受け手の違い

ワークフローシステムの通知は、申請の状態が変わった瞬間に飛びます。実務で設定を見直す対象は次の4イベントで、受け手と目的がそれぞれ違います。

イベント	受け手	通知の目的	設定の指針
承認依頼	次の承認者	処理の開始	即時・個別に送る
差し戻し	申請者	修正の依頼	即時・理由欄を本文に含める
最終承認・却下	申請者・経理など後工程	結果の確定	後工程は件数が多ければ日次まとめ
コメント・質問	宛先に指定された人	確認の往復	メンションされた人だけに送る

優先度が最も高いのは承認依頼です。ここが遅れると申請全体が止まるため、即時かつ個別に送ります。最終承認の通知は、申請者には即時で返し、経理や総務など後工程の担当には1日分をまとめて送る設定のほうが処理しやすくなります。途中の承認者が承認したことを申請者に毎回知らせる設定は、多段の経路では通知が段数分だけ増えるので、申請一覧で進捗を確認できるなら切ってかまいません。

到達の速さと記録の残り方で比べるメール・チャット・プッシュ通知

通知の経路は、メール・ビジネスチャット・スマホアプリのプッシュ通知の3つが主流です。到達の速さはプッシュ通知とチャットが上で、記録の残り方と社外を含めた到達範囲はメールが上です。

実務の第一候補は、承認依頼をチャットに、結果の確定をメールに送る組み合わせです。チャットは社員が日中に常に開いている画面なので気づかれやすく、メールは承認の結果を証跡として残すのに向きます。プッシュ通知は外出の多い営業職や現場の承認者に効きますが、端末の通知許可や省電力設定で止まることがあり、プッシュ通知だけに頼る設計は避けてください。プッシュ通知の配信の仕組みはFCM（Firebase Cloud Messaging）のプッシュ通知の仕組みと送信方法で詳しく扱っています。

経路は承認者ごとに選ばせる製品もあります。選択肢を与えると、メールを見ない人がメールを選んだまま放置する事態も起きるため、会社として既定の経路を1つ決め、例外だけ個人設定を許す運用にします。

承認滞留を止めるリマインドと期限管理：経過日数・営業日・自動エスカレーションの設計

滞留の基準日数を書式ごとに分ける設計と営業日カレンダーの持ち方

リマインドの基準を決める際に見るのは「承認依頼から何日経ったか」です。全書式で一律3日のような設定は、急ぎの支払申請には遅すぎ、月1回の規程改定の稟議には早すぎます。書式ごとの基準日数の決め方と、通知先を人事マスタから引く大企業の要件は大企業のワークフローシステム選定で整理した多階層の承認経路と滞留通知で扱っているので、ここでは日数の数え方に絞ります。

数え方は暦日でなく営業日にします。金曜の夕方に出た申請を暦日2日で催促すると、日曜に通知が飛び、月曜の朝には古い通知として埋もれます。営業日で数えるために必要なのは、土日に加えて祝日と自社の休業日を登録したカレンダーです。祝日は内閣府が「国民の祝日」についてのページで昭和30年から令和9年までの祝日一覧CSVを公開しており（2026年10月時点）、翌年分の追加は毎年の公表を待って取り込みます。年末年始や夏季休業など会社独自の休みは、総務が年初に登録する運用を決めておかないと、休業中にリマインドが鳴り続けます。

期限日の日付選択欄で申請者に希望納期を入力させる運用の落とし穴

申請フォームに日付選択の欄を設け、申請者に「いつまでに承認が欲しいか」を入れさせる方法もあります。期限日を基準にすれば、期限の2営業日前に承認者へ知らせる、といった逆算のリマインドを組めます。

落とし穴は、申請者が全件に翌日の日付を入れることです。希望日を自由に選ばせると、急ぎでない申請まで急ぎに見え、期限ベースのリマインドが一斉に鳴って意味を失います。日付選択欄を使う場合は、選べる最短日を書式ごとの標準処理日数より後に制限し、それより早い日付を求める場合だけ理由欄を必須にします。期限日を過ぎた申請を自動で却下する設定は、承認者の怠慢を申請者の不利益に変えるため入れません。期限超過は催促とエスカレーションで扱います。

未承認が続いたら上長や代理承認者へ回す自動エスカレーションの発動条件

催促しても動かない申請は、別の人に回す仕組みが要ります。自動エスカレーションは、基準日数を超えた申請を代理承認者か承認者の上長へ自動で転送する機能で、休暇や出張で承認者が不在のときに効きます。

発動条件は「催促を1回送ったあと、さらに基準日数の半分が過ぎた時点」程度が目安です。催促の前にいきなり上長へ回すと、承認者は自分を飛ばされたと受け取り、上長には本来見なくてよい案件が流れ込みます。転送先は上長より先に代理承認者を指定するほうが、決裁権限の段を崩さずに済みます。代理承認者が未設定の承認者にだけ上長への転送を許す、という二段構えが現実的です。承認経路そのものの設計はワークフローシステムとは何かを機能と選び方から整理した解説で全体像を確認できます。

勤怠システムの休暇データを見て、休暇中の承認者を自動で飛ばす連携は、多くのパッケージでは標準で用意されていません。必要なら連携の開発範囲として扱います。

通知過多で無視される失敗パターンと宛先の絞り方：まとめ通知と1回限りの催促

1件ごとの即時通知が承認者の受信箱を埋めて既読スルーを生む構造

通知が増えるほど、1通あたりに向けられる注意は少なくなるものです。部長職のように1日に数十件の承認依頼を受ける人に、1件ずつ即時の通知を送り、さらに毎日リマインドを重ねると、受信箱はワークフローの通知で埋まります。すると承認者は件名を見ずに既読にする習慣がつき、本当に急ぎの申請も同じ扱いになります。

この失敗は、通知を増やすほど滞留が悪化するという逆転を生みます。承認が遅いから通知を増やす、という対策を何度か繰り返した職場ほど、この状態に陥っています。通知の総数を週単位で数え、承認者1人あたりの件数が多い人から設定を見直すのが近道です。

毎朝の未承認件数まとめ通知と同一ステップ1回限りの催促の使い分け

通知を減らしつつ取りこぼしを防ぐには、性質の違う2つの通知を組み合わせます。1つは毎朝決まった時刻に、未承認の件数と一覧へのリンクだけを送るまとめ通知です。もう1つは、基準日数を超えた申請に対する個別の催促です。

個別の催促は1回で止めるのが基本です。ジンジャーワークフローが2026年9月15日に公開したアラート通知（リマインド）機能のお知らせでは、経過日数と通知タイミングを設定でき、同一申請・同一承認ステップ・同一承認者につき、あえて1回のみ送る設計だと説明しています。催促を毎日繰り返す設定は、承認者にとってまとめ通知と同じ情報を重ねて受け取るだけになるためです。

実務では、まとめ通知を既定にし、個別の催促は1回、その後はエスカレーションへ進む、という順で組みます。製品によってはリマインドの頻度を細かく選べないこともあるため、選定時に「催促の回数上限を設定できるか」を確かめます。

申請ごとのCC・関係者通知を外す判断基準と閲覧権限で代替する方法

稟議や購買申請で、関係部署の担当者をCCに入れて結果を知らせる設定はよく見られます。紙の回覧の名残で、知っておいてほしい人に全件を送る運用です。稟議システムの機能と紙・メール稟議の課題でも触れているとおり、回覧の目的は情報共有であって処理ではありません。

CCを外してよいかの判断基準は、受け手がその通知を見て何か作業をするかどうかです。作業をしない人への通知は外し、代わりに申請一覧の閲覧権限を与えて、必要なときに自分で見に行ける状態にします。経理のように承認後に処理が発生する部署は、CCではなく後工程として日次のまとめ通知を送ります。

通知が届かない原因と経路別の対策：メールの認証設定・チャットの投稿上限・端末設定

自社ドメインから送る通知メールで必要なSPF・DKIM・DMARCの設定

クラウド型のワークフロー製品が、送信元を自社ドメインのアドレスに変えて通知メールを送る設定を選んだ場合、そのドメインの送信ドメイン認証を整えないと、通知が迷惑メールに振り分けられます。Googleのメール送信者のガイドラインは、Gmail宛てに送るすべての送信者にSPFまたはDKIMの設定と迷惑メール率0.3%未満の維持を求め、1日5,000件以上を送る送信者にはSPF・DKIM・DMARCの3つすべてを求めています（2026年10月時点の記載）。

社内の承認者がGoogle Workspaceを使っている会社では、この条件がそのまま通知の到達率に効きます。製品のマニュアルで、送信元ドメインのSPFに追加するレコードとDKIMの署名設定の手順を確認し、情報システム部門と一緒にDNSへ登録します。DMARCの仕組みとレコードの書き方はDMARCとは何かとSPF・DKIMとの違いの解説を参照してください。送信元を製品ベンダーのドメインのままにしておけば、この設定は不要です。

Teams・Slack・LINE WORKSへの一斉通知で欠ける投稿上限と送信の間引き

チャットへの通知が欠ける原因の一つは、投稿の上限を超えることです。Microsoftの受信Webhookの作成手順では、Workflowsアプリで受けるメッセージは28KBまでで、1秒間に4つ以上の要求を送ると接続が調整されると書かれています。Slackもchat.postMessageのリファレンスで、1つのチャンネルへの投稿は毎秒1件程度、ワークスペース全体では毎分数百件に制限すると説明しています。

月末に数百件の申請が一斉に承認されると、完了通知を1件ずつ同じチャンネルへ送る設定ではこの上限に届きます。対策は、後工程向けの通知を1件ずつ送らず、一定時間ごとにまとめて1通にすることです。TeamsのOffice 365コネクタは2026年5月に停止しており、移行後の通知経路と所有者の扱いはワークフローシステム連携の方式と設計で整理しています。LINE WORKSを使う会社はLINE WORKS Incoming Webhookの設定手順と送信の上限も確認してください。

スマホのプッシュ通知が届かない端末側の設定確認と社用端末の管理

プッシュ通知が届かない原因は、多くが端末側にあります。アプリのインストール時に通知を許可しなかった、OSの省電力機能でアプリがバックグラウンドで止められている、ログアウトしたまま放置している、の順によく起きます。

社用スマホを配っている会社では、MDM（モバイル端末管理）でワークフローのアプリを配布し、通知の許可状態を一括で確認できるようにすると、問い合わせが減ります。私物のスマホで承認させる運用では、端末の設定を会社が管理できないため、プッシュ通知は補助に留め、承認依頼の主経路はチャットかメールに置きます。

パッケージ標準の通知で足りない場合の追加開発：判断基準と開発範囲の見積り観点

標準の通知設定で済ませるべき範囲と追加開発に進む条件の線引き

通知まわりの不満の多くは、標準の設定変更で解決します。宛先の絞り込み、まとめ通知への切り替え、催促の回数、営業日カレンダーの登録は、追加開発の前にまず試すべき範囲です。設定を見直さずに開発を発注するのは、費用の使い方として過剰です。

追加開発に進むのは、次のように製品の外のデータや画面が絡む場合です。

勤怠や人事のデータを見て、休暇中や異動直後の承認者を自動で飛ばしたい
Teams・Slackのメッセージ上のボタンで承認や差し戻しまで完結させたい
基幹システムの締め日や支払日から逆算して、期限とリマインドを自動で決めたい
独自に作った業務システムの中に申請・承認・通知を組み込みたい

このうち最後の要件は、パッケージに通知を足すより、ワークフローを業務システムに組み込んで作るほうが早い場合があります。一創のワークフローシステム開発では、承認経路と通知の設計を既存の業務システムに合わせて組み込む開発を扱っています。

チャット上で承認まで完結させる通知連携の開発範囲と見送る場面

チャットの通知に承認ボタンを付けると、承認者は画面を切り替えずに処理できます。ただしTeamsでは、Microsoftの受信Webhookの説明に、Workflowsで投稿するカードはボタンのレンダリングに対応しないと記載されています。ボタン付きの承認を実現するには、Power Automateの承認アクションを使うか、ボットを含むTeamsアプリを開発することが必要です。Power Automateで組む場合の実装と権限の設計はPower AutomateのTeams連携でカード通知と承認を実装する手順で扱っています。

見送るべき場面もはっきりしています。添付書類や金額の内訳を見ないと判断できない稟議は、チャット上のボタンで承認させるべきではありません。ボタンが手軽なぶん、中身を確かめずに承認する操作を増やすためです。チャット承認は、経費の少額申請や勤怠の修正のように、通知の本文だけで判断できる申請に限ります。Slackへの通知を自前で組む場合の実装はSlack Incoming Webhookの実装手順と429対策が参考になります。

追加開発を開発会社へ依頼する前に通知要件として書き出しておく5項目

通知の追加開発は、要件が曖昧なまま依頼すると見積りの幅が大きく開きます。依頼の前に、次の5項目を書式ごとに書き出しておくと、開発会社は工数を見積もりやすくなります。

通知を飛ばすイベントと、その受け手（役職・部署・個人のどれで指定するか）
経路（メール・チャット・プッシュ）と、経路ごとの本文に載せる項目
リマインドの基準日数・回数上限と、営業日カレンダーの持ち主
エスカレーションの転送先と、転送先も不在だった場合の扱い
通知が送れなかったときの再送と、管理者への失敗通知の要否

5つ目の再送と失敗通知は見落とされやすく、ここを決めないと、チャットの上限に当たって欠けた通知に誰も気づきません。開発費の相場と内訳はワークフローシステムの費用相場と自社開発との5年総額で確認できます。

ワークフローシステムの通知機能でよく寄せられる質問と運用上の答え

通知機能の設定や運用について、導入前後によく出る質問をまとめました。

ワークフローシステムの通知はメールとチャットのどちらに送るべきですか？

社内で日中に常に開いているのがチャットなら、承認依頼はチャットに送るほうが気づかれやすくなります。結果の確定や差し戻しの理由など、あとで見返す通知はメールにも残すと、証跡として使えます。両方に同じ通知を二重に送ると、どちらも読まれなくなる原因になるため、イベントごとに経路を1つに決めてください。社外の取引先が承認者に含まれる場合は、メールを主経路にします。

承認のリマインドは何日おきに送るのが適切ですか？

何日おきに繰り返すかより、何回で止めるかを先に決めます。個別の催促は基準日数を超えた時点で1回送り、それでも動かなければ代理承認者か上長へのエスカレーションに切り替えるのが基本です。基準日数は書式ごとに変え、支払のように締めのある申請は短く、規程改定のような稟議は長く取ります。数え方は暦日でなく営業日にしてください。

承認者が休暇中のとき通知や申請はどうなりますか？

代理承認者を設定していなければ、申請は休暇明けまで止まり、通知とリマインドは不在の承認者に届き続けます。休暇の予定が分かっている場合は、承認者本人が期間を指定して代理承認者を設定する運用を決めておいてください。急な病欠に備えるには、基準日数を超えた申請を上長へ自動で回すエスカレーションを併用します。勤怠データと連動して自動で代理に切り替える仕組みは、多くの製品で追加開発の範囲です。

スマホのプッシュ通知だけで承認まで済ませても問題ありませんか？

通知の本文だけで判断できる少額の経費や勤怠の修正なら、スマホで通知を受けてそのまま承認する運用で問題ありません。添付の見積書や契約書を確認する必要がある稟議は、スマホの小さな画面では中身を確かめずに承認しがちなので、PCで承認する運用を残します。プッシュ通知は端末の設定で止まることがあるため、通知の主経路にはせず、チャットかメールと併用してください。

通知を送った記録は内部統制や監査で必要になりますか？

監査で問われるのは主に、誰がいつ承認したかという承認の履歴です。通知の送信記録まで求められる場面は多くありませんが、催促したのに承認されなかった、という経緯を説明するときには、通知とリマインドの送信日時が残っていると説明しやすくなります。製品の操作ログに通知の送信履歴が含まれるか、保存期間は何年かを選定時に確認しておくと安心です。