kintone通知の設計方法｜通知疲れを防ぐ条件・宛先・対応ルール

kintoneでアプリを作ると、すぐに通知の相談が出ます。

新しい問い合わせが入ったら通知したい。

申請が承認待ちになったら承認者に知らせたい。

期限が近づいたら担当者にリマインドしたい。

コメントで確認依頼を出したい。

ステータスが変わったら関係者に共有したい。

こうした通知は、設定自体は難しく見えません。

kintoneには、アプリの条件通知、レコードの条件通知、リマインダーの条件通知、コメント通知、プロセス管理に関わる通知、メール通知、デスクトップ通知、モバイルプッシュ通知があります。

ただし、実務で問題になるのは、通知機能を知らないことではありません。

次のような運用になってしまうことです。

• レコード追加のたびに部署全員へ通知が届く
• 「参考までに」の通知が多く、重要な通知が読まれない
• 通知は届いているが、誰が次に動くのか決まっていない
• 自分宛通知とすべて通知の違いを考えずに設定している
• 担当者フィールドが空のままなので、通知先が固定メンバーに寄る
• 期限通知が毎日届くが、期限超過のレコードは減らない
• メール、デスクトップ、モバイルに同じ通知が出て、現場が無視する
• 作成者、更新者、コメント参加者への初期通知を理解せず、想定外の通知が出る
• 通知設定を作った後、誰も棚卸ししない

通知は、多ければよいものではありません。

多すぎる通知は、対応漏れを減らすどころか、重要な通知を見落としやすくします。

kintone通知で最初に決めるべきなのは、通知条件ではなく、「通知を受けた人が次に何をするか」です。

この記事では、kintone通知を、アプリの条件通知、レコードの条件通知、リマインダー、自分宛通知とすべて通知、メール・デスクトップ・モバイル通知、通知棚卸しまで含めて設計する方法を整理します。

kintoneメール通知の設計方法はこちら
kintoneプロセス管理の設計方法はこちら

先に結論：通知は「対応が必要な状態」だけに絞る

kintone通知は、次の3つを決めてから設定します。

決めること	設計の問い
何を通知するか	その状態になったら、人が動く必要があるか
誰に通知するか	次に対応する本人か、判断する責任者か
どこで通知するか	kintone内、メール、デスクトップ、モバイル、一覧のどれで見るか

通知すべきなのは、業務上のアクションが必要な状態です。

単に「レコードが更新された」「誰かがコメントした」「ステータスが変わった」だけでは、通知として広すぎます。

通知を受けた人が、次にすることまで決めます。

通知する状態	通知先	次の行動
問い合わせが新規受付になった	一次担当者	内容確認、担当割当
申請が承認待ちになった	承認者	承認、差し戻し、保留判断
見積金額が一定額を超えた	責任者	条件確認、承認判断
初回返信期限が近い	担当者	顧客へ返信
期限を過ぎても未対応	担当者と上長	優先順位の見直し
重要顧客から登録があった	担当者、責任者	内容確認、対応方針決定
連携エラーが発生した	管理者	エラー原因の確認

逆に、次のような通知は削る候補です。

削る候補	理由
すべての編集通知	誤字修正や自動更新まで通知される
部署全員への参考通知	責任者が曖昧になる
毎日同じ期限超過通知	届くだけで滞留が解消しない
自動計算フィールドの更新通知	人の対応につながりにくい
一括更新時の通知	大量通知になりやすい
確認済みの状態変更通知	受け手に新しい判断がない

「通知を受けた人が何をするのか」を1行で書けない通知は、設定する前に削る候補です。

kintone通知で使う機能を整理する

まず、kintoneの通知機能を大きく分けます。

kintoneヘルプでは、kintoneにはアプリ、スペース、ピープルなどの更新を通知する機能があると説明されています。

kintoneヘルプ：通知

アプリの通知設定では、レコード操作、レコード内データの条件、日時項目を基準にしたリマインダーで通知を送信できます。

kintoneヘルプ：アプリの通知設定でできること

設計時には、次のように分けて考えます。

通知機能	使いどころ	設計上の注意
アプリの条件通知	レコード追加、編集、削除、コメントなど操作起点	操作全部を通知対象にしない
レコードの条件通知	金額、種別、ステータスなどデータ条件起点	条件を狭くし、行動と結びつける
リマインダーの条件通知	期日、納期、回答期限など日時起点	期限前、期限当日、期限超過を分ける
コメント通知	個別の確認依頼、相談、差し戻し	宛先指定を徹底する
プロセス管理通知	作業者、承認者、次ステータスの担当	ステータス設計とセットにする
メール通知	kintoneを常時見ない人への重要通知	すべて通知をメールに出しすぎない
デスクトップ通知	作業中の即時確認	自分宛中心で考える
モバイルプッシュ通知	外出中、現場作業、緊急確認	緊急度の高い通知に絞る

通知設定は、機能単体ではなく、業務の流れで配置します。

たとえば問い合わせ管理なら、次のようになります。

状態	通知
フォームから問い合わせが登録された	一次担当者へ自分宛通知
重要顧客または緊急種別だった	責任者にも通知
初回返信期限の前日になった	担当者へリマインダー
期限を超過した	担当者と上長へ通知
対応完了になった	通知せず、一覧や週次確認で見る

このように、通知は「状態変化」と「対応責任」をセットで設計します。

kintone問い合わせ管理の設計方法はこちら

自分宛通知とすべて通知を分ける

kintone通知で重要なのが、自分宛通知とすべて通知の違いです。

kintoneヘルプでは、kintoneの通知には「自分宛」と「すべて」があり、宛先に自分を指定された通知などが自分宛に届くと説明されています。

kintoneヘルプ：「自分宛」通知と「すべて」通知の違い

また、通知が送信されるタイミングと宛先のヘルプでは、レコード追加や更新時の通知先が、自分宛通知とすべて通知に分けて整理されています。

kintoneヘルプ：通知が送信されるタイミングと宛先

実務上は、次のように使い分けます。

種類	位置づけ	設計方針
自分宛通知	自分が次に動く通知	対応が必要な通知に絞る
すべて通知	参考、ウォッチ、関連情報	kintone内で見る前提にする
メールで受ける通知	kintone外でも気づくべき通知	自分宛と重要例外に寄せる
一覧で見る通知相当の情報	未対応、期限超過、滞留	通知ではなくビューで管理する

自分宛通知は、本人の対応を起こすために使います。

担当者フィールドに入った人。

プロセス管理の作業者になった人。

コメントで宛先指定された人。

期限が近いレコードの担当者。

こうした人には、通知が必要です。

一方、すべて通知は、参考情報として見る性質が強くなります。

部署全体に知らせたい。

アプリの動きをウォッチしたい。

担当ではないが状況を追いたい。

こうした用途では便利ですが、メールやデスクトップにまで出すと、すぐに多すぎます。

自分宛通知は「自分が動く通知」、すべて通知は「状況を追う通知」と分けると、通知疲れを減らしやすくなります。

アプリの条件通知は、操作ではなく行動で決める

アプリの条件通知では、レコードの追加や編集など、操作をきっかけに通知できます。

便利ですが、操作そのものを通知条件にすると広くなりがちです。

たとえば「レコードが編集されたら営業部全員へ通知」とすると、次のような更新もすべて届きます。

• 表記ゆれの修正
• 入力ミスの修正
• 自動連携による更新
• 管理者による一括変更
• 集計用フィールドの更新
• すでに対応済みのレコードの軽微な変更

これでは、重要な編集が埋もれます。

アプリの条件通知は、操作と行動を結びつけて使います。

操作	そのまま通知すると	設計し直した通知
レコード追加	新規登録すべてが通知される	新規受付で、一次対応が必要なものだけ通知
レコード編集	軽微な修正も通知される	担当者変更、重要項目変更だけ通知
コメント	雑談や記録も通知される	宛先指定された確認依頼を通知
ステータス更新	状態変更すべてが通知される	承認待ち、差し戻し、期限超過だけ通知

「追加されたら通知」ではなく、「追加された後に誰が初動を取るか」まで決めます。

「編集されたら通知」ではなく、「どの項目が変わったときに判断が必要か」を決めます。

レコードの条件通知は、重要条件だけに絞る

レコードの条件通知は、フィールドの値が特定条件を満たしたときに通知できます。

たとえば、金額、重要度、種別、ステータス、担当者、顧客ランクなどです。

この機能は、実務ではかなり重要です。

ただし、条件を広くしすぎると、結局は全件通知に近づきます。

条件通知の例	良い条件か	理由
ステータスが未対応	弱い	未対応は一覧で見る方がよい
ステータスが未対応、かつ重要度が高い	良い	対応優先度が明確
金額が100万円以上	良い	承認や確認が発生しやすい
種別が問い合わせ	弱い	件数が多いと通知過多になる
種別がクレーム、かつ未対応	良い	初動が必要
担当者が空欄	場合による	通知より入力ルールの見直しが必要なこともある

条件通知は、次のように書き出してから設定します。

設計項目	例
条件	金額が100万円以上、かつステータスが申請中
通知先	承認者フィールド、または部門責任者
通知の目的	条件確認と承認判断
期限	当日中
対応後の状態	承認済み、差し戻し、保留
通知を止める条件	承認済みになったら通知しない

ここまで書ける条件だけを通知にします。

曖昧な条件は、通知ではなく一覧やダッシュボードで管理します。

kintoneダッシュボードの設計方法はこちら

宛先は固定メンバーではなく、担当者フィールドで決める

通知設計でよくある失敗が、固定ユーザーや部署全体へ通知してしまうことです。

小さなチームなら一時的には動きます。

しかし、人数が増えたり、担当が変わったり、部署が分かれたりすると、すぐに合わなくなります。

kintoneヘルプでは、通知先に組織、グループ、ユーザーを指定できること、フォームにユーザー選択、組織選択、グループ選択フィールドがある場合は、そのフィールドで選択されたユーザーも通知先に指定できることが説明されています。

kintoneヘルプ：アプリの通知設定でできること

実務では、できるだけレコード内の担当者フィールドに寄せます。

宛先の指定方法	向いている場面	注意点
固定ユーザー	管理者通知、小規模な例外通知	異動、退職、担当変更に弱い
組織	部署全体への共有	誰が対応するか曖昧になりやすい
グループ	横断チームへの通知	メンバー管理が必要
ユーザー選択フィールド	レコードごとの担当者通知	担当者未入力を防ぐ必要がある
組織選択フィールド	レコードごとの担当部署通知	個人の責任まで分ける必要がある
作業者	プロセス管理の次担当	ステータス設計と連動させる

問い合わせなら、一次担当者。

営業案件なら、案件担当者。

申請なら、現在の作業者や承認者。

請求なら、経理担当者。

在庫なら、品目担当者。

このように、通知先はレコードの担当情報から決めます。

固定メンバーへの通知は、管理者通知や例外通知に限定した方が保守しやすいです。

リマインダーは、期限前・期限当日・期限超過を分ける

リマインダーは、期限管理に向いています。

ただし、「期日になったら担当者へ通知」だけでは弱いです。

実務では、期限前、期限当日、期限超過で、通知先と目的を分けます。

タイミング	通知先	目的
期限3日前	担当者	事前に準備する
期限前日	担当者	明日までに対応する
期限当日	担当者	今日対応する
期限超過	担当者、上長	滞留を解消する
期限超過3日	責任者	体制や優先度を判断する

リマインダーの対象になる日時項目も、業務ごとに分けます。

業務	日時項目	通知の目的
問い合わせ	初回返信期限	顧客への返信漏れを防ぐ
見積	提出期限	見積提出を間に合わせる
申請	承認期限	承認滞留を防ぐ
契約	更新期限	更新確認を始める
請求	請求予定日	請求作業を開始する
入金	支払期限	入金確認、督促判断

期限超過の通知を毎日送るだけでは、現場は慣れてしまいます。

期限超過通知は、担当者だけでなく、上長や責任者が見る一覧と組み合わせます。

通知で気づく。

一覧で滞留を確認する。

会議で対応方針を決める。

この3つを分けると、期限通知が単なるアラートで終わりにくくなります。

メール・デスクトップ・モバイル通知の使い分け

kintoneの通知は、kintone内だけでなく、メール、デスクトップ通知、モバイルプッシュ通知でも確認できます。

kintoneヘルプでは、通知の確認方法として、ポータル、通知画面、メール、デスクトップ通知、モバイルアプリのプッシュ通知が整理されています。

kintoneヘルプ：通知を確認する

それぞれの役割は違います。

確認方法	向いている通知	向かない通知
ポータル	日常的な確認、参考通知	即時対応が必要な通知
通知画面	自分宛、あとで確認する通知	長期滞留の管理
メール	kintoneを常時見ない人の重要通知	すべて通知、参考通知、大量更新
デスクトップ通知	作業中に即時確認したい自分宛通知	関係者全体への共有
モバイルプッシュ	外出中や現場で必要な通知	多頻度の参考通知
一覧・ダッシュボード	未対応、期限超過、滞留	即時の呼び出し

メール通知を詳しく設計する場合は、別の記事で整理しています。

kintoneメール通知の設計方法はこちら

この記事で強調したいのは、通知チャネルを増やせば解決するわけではないという点です。

同じ通知を、kintone、メール、デスクトップ、モバイルへ全部出すと、重要な通知でも無視されやすくなります。

チャネルごとに、通知する意味を分けます。

通知の重要度	推奨チャネル
自分が今すぐ動く	自分宛通知、必要に応じてデスクトップまたはモバイル
当日中に対応する	自分宛通知、メール
週次で確認する	一覧、ダッシュボード
参考として追う	すべて通知、ポータル
異常時だけ確認する	管理者通知、外部通知、ログ一覧

同じ通知を複数チャネルへ出す前に、そのチャネルで受け取った人が本当に行動するかを確認します。

通知と一覧を分けて設計する

通知は、受け身で気づくための仕組みです。

一覧は、能動的に状況を確認するための仕組みです。

この2つを混ぜると、通知が多くなります。

たとえば、未対応の問い合わせを全部通知する必要はありません。

未対応一覧を作り、担当者が毎日見る方が安定します。

ただし、重要顧客の問い合わせ、期限前日、期限超過は通知します。

管理したいこと	通知で扱うか	一覧で扱うか
新規受付	通知する	当日受付一覧でも見る
未対応全件	通知しない	一覧で見る
期限前日	通知する	期限順一覧でも見る
期限超過	通知する	期限超過一覧で見る
完了済み	通知しない	必要なら履歴一覧で見る
重要顧客	通知する	重要顧客一覧で見る

通知だけに頼ると、通知を見逃した瞬間に業務が止まります。

一覧だけに頼ると、見に行かない人には届きません。

両方を分けて設計します。

通知疲れを防ぐ棚卸し

通知設計は、一度作って終わりではありません。

運用が始まると、必ずズレます。

担当者が変わる。

通知条件が古くなる。

重要度の低い通知が増える。

期限が実務と合わなくなる。

外部連携や一括更新で通知量が増える。

そのため、月1回程度は通知を棚卸しします。

確認項目	見るポイント
通知条件	今も人の対応が必要な条件か
宛先	固定ユーザーが古くなっていないか
担当者フィールド	未入力や誤入力が多くないか
通知量	1人あたりの通知が多すぎないか
見逃し	重要通知が読まれていない原因は何か
期限	期限前、当日、超過のタイミングは合っているか
チャネル	メール、デスクトップ、モバイルに出しすぎていないか
一覧との分担	一覧で見るべきものまで通知していないか

棚卸しでは、通知を増やすだけでなく、削ることも決めます。

削る通知の例です。

削る通知	代わりの管理
すべての編集通知	重要項目変更だけ通知
参考共有のメール通知	ポータルやすべて通知で確認
毎日の期限超過通知	期限超過一覧と週次確認
部署全員への新規登録通知	一次担当者フィールドへ通知
完了通知	完了一覧や履歴で確認

通知を削ると不安になる場合があります。

そのときは、通知を消す代わりに、一覧やダッシュボードで確認できる状態を作ります。

よくある失敗

失敗1：全員に通知して安心する

全員に通知すると、責任者が曖昧になります。

誰かが見るだろう、という状態になります。

通知先は、担当者、作業者、承認者、責任者に絞ります。

共有が必要な情報は、すべて通知や一覧で見る方がよいです。

失敗2：メール通知で全部解決しようとする

メールは便利ですが、通知量が増えると読まれません。

メールは、自分が対応すべき重要通知や、kintoneを常時見ない人への通知に絞ります。

参考通知は、kintone内通知や一覧で扱います。

失敗3：リマインダーを毎日送る

毎日同じ通知が届くと、現場は慣れます。

期限前、期限当日、期限超過で通知先と行動を変えます。

期限超過が続く場合は、通知ではなく、業務量、担当割当、期限設定を見直します。

失敗4：担当者フィールドが空でも通知設計を進める

担当者フィールドが空のままだと、通知先を固定ユーザーや組織に逃がしがちです。

まず、担当者が必ず入る入力ルールを設計します。

通知は、その担当者フィールドを使って出します。

失敗5：通知設定を誰も管理しない

通知設定は、業務変更に合わせて古くなります。

誰が通知設定を管理するか。

いつ見直すか。

どの通知を削るか。

ここまで決めないと、通知は増え続けます。

kintone通知設計のチェックリスト

最後に、通知を設定する前のチェックリストです。

チェック	確認すること
目的	通知を受けた人の次の行動が書けるか
条件	操作全体ではなく、行動が必要な状態に絞れているか
宛先	固定メンバーではなく、担当者や作業者で指定できるか
種類	自分宛通知とすべて通知を分けているか
期限	期限前、当日、超過で通知先を変えているか
チャネル	メール、デスクトップ、モバイルに出しすぎていないか
一覧	通知ではなく一覧で見るべきものを分けているか
管理者	通知設定を誰が棚卸しするか決めているか

通知は、kintoneアプリの最後に付け足す設定ではありません。

ステータス、担当者、期限、権限、一覧と一緒に設計するものです。

kintoneワークフローの作り方はこちら
kintoneプロセス分岐の設計方法はこちら

Bitlightに相談できること

Bitlightでは、kintoneの通知設定を、単なるアラート設定としてではなく、対応漏れを減らす業務フローとして設計します。

たとえば、次のような整理ができます。

相談内容	支援できること
通知が多すぎる	通知条件、宛先、チャネルを棚卸しして削る
対応漏れがある	担当者フィールド、期限、未対応一覧、リマインダーを設計する
承認が滞留する	プロセス管理、作業者、期限通知を整理する
メール通知が読まれない	自分宛通知、メール通知、一覧の分担を見直す
外部連携で通知が増えた	人が確認すべき例外通知に絞る
誰に通知すべきか分からない	業務フローから担当者、責任者、共有先を整理する

kintone通知は、設定を増やすほど良くなるものではありません。

必要な人へ、必要な状態だけを通知し、残りは一覧やダッシュボードで確認する。

この整理ができると、通知は現場を邪魔するものではなく、対応を前に進める仕組みになります。