kintone通知カスタマイズの設計方法｜ポップアップ・Webhook・外部連携の使い分け

kintoneの通知を使い始めると、次に出てくる相談が「通知カスタマイズ」です。

通知内容をもっと分かりやすくしたい。

画面上にポップアップを出したい。

SlackやTeamsに通知したい。

重要な通知だけメールやチャットに流したい。

通知を見逃したら上長にも知らせたい。

Webhookで外部サービスと連携したい。

こうした要望は自然です。

ただし、通知カスタマイズは、手段から入ると失敗しやすいです。

次のような状態になります。

• すべての更新をSlackに流し、チャンネルがすぐ読まれなくなる
• ポップアップを出したが、ユーザーが閉じるだけで対応が進まない
• Webhookが失敗していたのに、誰も気づかない
• 通知文面は詳しくなったが、誰が対応するかは曖昧なまま
• メール、デスクトップ、チャットに同じ通知が出て、重要度が分からない
• プラグインやJavaScriptの保守担当が決まっていない
• 外部連携先で通知が止まったときの確認手順がない
• 標準通知で足りるものまで個別カスタマイズしている

通知カスタマイズは、通知を増やすための作業ではありません。

標準通知、画面上のポップアップ、デスクトップ通知、Webhook、チャット連携、一覧・ダッシュボードを、業務上の重要度に応じて分ける作業です。

kintone通知カスタマイズで最初に決めるべきなのは、実装方法ではなく、「この通知を受けた人がどこで見て、何をするか」です。

この記事では、kintone通知カスタマイズを、標準通知、デスクトップ通知、JavaScriptダイアログ、プラグイン、Webhook、Slack・Teams連携、外部通知ログ、誤通知防止まで含めて設計する方法を整理します。

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

先に結論：通知カスタマイズは「外に出す通知」を絞る設計

通知カスタマイズでは、まず通知を4つに分けます。

分類	使う手段	目的
kintone内で足りる通知	標準通知、自分宛通知、すべて通知	kintoneを見る人が対応する
画面上で止めたい通知	デスクトップ通知、JavaScriptダイアログ	その場で注意喚起する
チームへ共有したい通知	Webhook、Slack、Teams、連携サービス	チームで状況を把握する
通知ではなく一覧で見るもの	一覧、グラフ、ダッシュボード	未対応や滞留を定期確認する

すべてを外部チャットへ流す必要はありません。

すべてをポップアップにする必要もありません。

通知は、受け手の行動に合わせて分けます。

通知の例	推奨する扱い
自分が承認者になった	kintone自分宛通知、必要ならメール
重要顧客の問い合わせが登録された	担当者へ自分宛通知、責任者へチャット通知
期限超過が発生した	担当者へ通知、上長は期限超過一覧で確認
大量データの一括更新が終わった	チャットではなく処理ログで確認
連携エラーが発生した	管理者へ外部通知、ログ確認
参考共有したい更新	kintone内のすべて通知や一覧

通知カスタマイズの価値は、通知を目立たせることではなく、外に出す通知とkintone内で見る通知を分けることです。

標準通知で足りるケース

まず、標準通知で足りるものを切り分けます。

kintoneヘルプでは、アプリの通知設定で、レコード操作、レコード内データの条件、日時項目を基準にしたリマインダー通知を設定できると説明されています。

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

標準通知で足りるのは、次のようなケースです。

ケース	標準通知で足りる理由
担当者へ通知したい	ユーザー選択フィールドや作業者へ通知できる
承認者へ知らせたい	プロセス管理と組み合わせやすい
期限前にリマインドしたい	日時項目を起点に通知できる
kintoneを日常的に開く人へ知らせたい	通知画面やポータルで確認できる
参考通知を追いたい	すべて通知として見れば足りる

標準通知で足りるものまで外部チャットに流すと、通知量だけが増えます。

たとえば、営業案件アプリで「レコード編集」をすべてSlackに流すと、次のような更新も流れます。

• 誤字修正
• メモ追記
• 金額未確定の仮更新
• 自動計算項目の更新
• 一括更新
• 対応済み案件の軽微な修正

これでは、重要な通知が埋もれます。

標準通知で足りる通知は、kintone内に残します。

外に出すのは、次のように条件を絞った通知です。

外に出す候補	理由
重要顧客の新規問い合わせ	初動の遅れが影響しやすい
高額見積の承認待ち	責任者判断が必要
期限超過が一定日数を超えた	担当者だけでは解消しない
外部連携の失敗	管理者対応が必要
顧客影響のある障害連絡	チームで即時把握する必要がある

標準通知を設計してから、足りない部分だけをカスタマイズします。

デスクトップ通知と画面ポップアップの違い

「ポップアップ通知を出したい」という相談では、2つの意味が混ざりがちです。

1つは、WebブラウザーやOSの通知として出るデスクトップ通知です。

もう1つは、kintone画面上に独自のダイアログや注意表示を出すカスタマイズです。

種類	役割	注意点
デスクトップ通知	kintone以外の画面を見ているときに自分宛通知へ気づく	個人設定、ブラウザー、OSの許可が必要
JavaScriptダイアログ	kintone画面上で確認や注意喚起を出す	画面を開いているときに限られる
フィールド横の注意表示	入力中にルールを伝える	通知ではなく入力補助に近い
レコード一覧の色分け	滞留や危険状態を見つけやすくする	即時通知ではない

kintoneヘルプでは、デスクトップ通知は個人設定で有効化し、ブラウザーやOS側でも通知を許可する必要があると説明されています。

kintoneヘルプ：デスクトップ通知を設定する

また、対象外になるブラウザーやゲストユーザーの条件もあります。

そのため、デスクトップ通知は「全員に必ず表示される通知」として設計しない方がよいです。

自分宛の重要通知に気づきやすくする補助として扱います。

一方、画面上のダイアログは、kintoneのJavaScriptカスタマイズで作る領域です。

kintoneヘルプでは、JavaScriptやCSSでアプリの動作や画面をカスタマイズでき、PC用とスマートフォン用で分けて設定すると説明されています。

kintoneヘルプ：JavaScriptやCSSでアプリをカスタマイズする

cybozu developer networkでは、kintone上にダイアログを作成でき、表示内容を独自にカスタマイズできるAPIも公開されています。

cybozu developer network：ダイアログを作成する

ただし、画面上のダイアログは万能ではありません。

向いている用途	向かない用途
保存前の確認	画面を開いていない人への通知
高額案件の注意喚起	チーム全体への共有
入力漏れや危険条件の確認	長期滞留の管理
重要項目変更時の確認	外部連携エラーの監視

画面ポップアップは、通知というより「その画面を操作している人への確認」です。画面を開いていない人へ知らせる用途には向きません。

Webhookで外部通知へ流すケース

SlackやTeams、Gmail、外部ワークフロー、連携基盤へ通知したい場合は、Webhookや連携サービスを検討します。

kintoneヘルプでは、Webhookを使うと、kintoneアプリで特定の操作が行われた際に、指定した外部サービスへ操作内容を送信できると説明されています。

kintoneヘルプ：Webhookの設定

cybozu developer networkでも、kintoneアプリでWebhookを設定すると、レコード追加、編集、削除、コメント書き込み、プロセス管理のステータス更新などをきっかけに通知できると整理されています。

cybozu developer network：kintone Webhook

Webhookが向いているのは、次のような通知です。

通知したいこと	Webhookが向く理由
重要顧客の問い合わせをSlackへ流す	チームで初動を見られる
承認待ちを外部ワークフローへ渡す	kintone外の承認運用とつながる
連携エラーを管理者へ通知する	管理者がkintoneを常時見なくても気づける
レコード削除を監視する	操作ログとして外部にも残せる
ステータス変更をTeamsへ流す	チームの進行状況を共有できる

ただし、Webhookは「通知を外に出す仕組み」です。

外部チャットに流した後、誰が対応するかは別途設計しなければなりません。

たとえば、Slackに「重要顧客の問い合わせが登録されました」と流れても、担当者が決まっていなければ対応は進みません。

Webhookで外に出す前に、次を決めます。

決めること	例
通知条件	重要顧客、緊急、未対応、金額100万円以上
通知先	営業チャンネル、管理者チャンネル、承認者
通知文面	レコードタイトル、顧客名、期限、担当者、URL
対応責任	担当者、一次対応者、責任者
失敗時	Webhookログ確認、再送手順、代替通知
棚卸し	月次で条件と通知先を見直す

Webhookの制限とログを前提にする

Webhookは便利ですが、制限があります。

kintoneヘルプでは、Webhookは1アプリにつき10個まで、通知はドメイン単位で1分間に60回までという制限が説明されています。

kintoneヘルプ：Webhookを設定する

また、Webhookの実行ログでは、直近10件までの実行結果を確認でき、古いログは監査ログを確認する必要があります。

kintoneヘルプ：Webhookの実行ログを確認する

この制限を踏まえると、Webhookは大量通知には向きません。

やりたいこと	設計方針
全レコード編集をSlackへ通知	避ける。重要条件に絞る
一括更新の結果を通知	1件ずつではなく、処理結果レポートにする
連携エラーを通知	エラー時だけ管理者へ通知する
承認待ちを通知	ステータス変更と担当者を条件にする
削除監視を通知	管理者向けに絞り、ログ確認とセットにする

Webhookログも、業務上の監視台帳としては弱い場合があります。

直近の確認には使えますが、長期間の通知履歴や対応履歴を持ちたいなら、外部側でログを残す設計が必要です。

ログで見たいこと	kintone側だけで足りるか
直近のWebhook成功・失敗	kintoneの実行ログで確認できる
1か月前の通知履歴	外部ログや監査ログの確認が必要
通知後に誰が対応したか	対応履歴アプリやコメントが必要
通知文面の再送	外部連携側で再送設計が必要
通知先チャンネルの変更履歴	連携設定の管理台帳が必要

Webhookを使うなら、「送れたか」だけでなく、「送れなかったときに誰が見るか」まで決めます。

Slack・Teams連携はチャンネル設計が先

外部チャット通知で多い失敗は、通知先チャンネルを先に決めてしまうことです。

「営業チャンネルに流そう」

「管理部チャンネルに流そう」

「全社チャンネルに流せば見てもらえる」

この発想だと、チャンネルが通知で埋まります。

SlackやTeamsへ流す通知は、チャンネルの役割から決めます。

チャンネル	流す通知	流さない通知
営業初動	重要顧客、新規問い合わせ、期限超過	全案件の軽微な編集
承認管理	高額見積、例外承認、差し戻し	通常承認すべて
連携監視	外部連携失敗、Webhook失敗、バッチ異常	成功ログすべて
経理確認	請求差し戻し、入金期限超過	請求レコードの全更新
現場緊急	顧客影響のある障害、当日対応	参考共有

通知先チャンネルを分けすぎても、見る場所が増えます。

逆に、1つのチャンネルに集めすぎると読まれません。

目安は、通知を受けたチャンネルの人が、次に何をするかで分けることです。

次の行動	通知先
担当者が対応する	担当者への自分宛通知
チームが初動を決める	業務チャンネル
管理者が障害を見る	連携監視チャンネル
責任者が判断する	責任者または承認チャンネル
定例で確認する	ダッシュボード、一覧

チャット通知は、会話を始めるには向いています。

しかし、対応履歴の正本にはしにくいです。

最終的な対応状況は、kintoneレコード、コメント、ステータス、対応履歴アプリに戻す設計にします。

通知文面は「読む人の判断材料」に寄せる

通知文面のカスタマイズで大事なのは、文章を長くすることではありません。

読んだ人が、開くべきか、対応すべきか、誰に渡すべきかを判断できることです。

通知文面には、最低限次を入れます。

項目	理由
業務名	何の通知か分かる
顧客名・案件名	対象を識別できる
重要度	すぐ見るべきか判断できる
期限	今日対応か、後でよいか分かる
担当者	誰が動くか分かる
レコードURL	詳細へ戻れる
次の行動	確認、承認、返信、修正などを明確にする

悪い通知文面は、次のようなものです。

悪い文面	問題
レコードが更新されました	何が変わったか分からない
新しい通知があります	優先度が分からない
期限が近づいています	どの期限か分からない
エラーが発生しました	誰が何を確認するか分からない

良い通知文面は、短くても判断できます。

文面の型	例
業務 + 状態	問い合わせが緊急で登録されました
対象 + 期限	A社の初回返信期限が本日です
担当 + 行動	田中さん、見積承認を確認してください
エラー + 対応先	会計連携に失敗しました。管理者がログを確認してください

通知文面は、詳しさよりも「開くべきか、誰が動くか、いつまでか」が分かることを優先します。

JavaScript・プラグイン・Webhookの使い分け

通知カスタマイズには、標準設定以外にもいくつかの手段があります。

ただし、どれが一番よいかは要件で変わります。

手段	向いていること	注意点
標準通知	担当者、作業者、期限、条件通知	文面や外部連携の自由度は限られる
デスクトップ通知	自分宛通知への気づき	個人設定、ブラウザー、OSに依存する
JavaScriptダイアログ	画面上の確認、入力前の注意	画面を開いている人にしか出ない
JavaScript表示制御	一覧や詳細画面の注意表示	保守者、適用範囲、モバイル確認が必要
プラグイン	よくある通知補完やチャット連携	費用、権限、アップデート影響を確認する
Webhook	外部チャット、連携基盤、ログへ送る	制限、失敗時、再送、外部側の保守が必要
外部連携サービス	条件分岐や整形、複数サービス連携	連携サービス側の料金と障害対応が必要

JavaScriptは、画面上の注意喚起や入力補助に向いています。

Webhookは、kintone外へ通知を送ることに向いています。

プラグインは、よくある要件を短く実装したいときに向いています。

標準通知は、まず試すべき土台です。

選定の順番は、次の通りです。

順番	判断
1	標準通知と一覧で足りるか
2	自分宛通知やメールで足りるか
3	画面を操作している人への注意表示で足りるか
4	外部チャットへ流す必要があるか
5	Webhookだけで足りるか、外部連携サービスが必要か
6	ログ、再送、障害時の確認を誰が見るか

いきなりJavaScriptやWebhookに進むと、あとから保守が重くなります。

標準で足りる部分は標準で残し、足りない部分だけを外へ出します。

誤通知と通知過多を防ぐ

通知カスタマイズで特に危ないのは、誤通知です。

通知先を間違える。

テストデータを本番チャンネルへ流す。

一括更新で大量通知する。

非公開情報を外部チャットへ流す。

削除や差し戻しを意図せず通知する。

こうした誤通知は、現場の信頼を落とします。

設計時には、次を確認します。

確認項目	見ること
テスト環境	本番チャンネルへ送らない設定か
通知条件	一括更新や軽微な編集を除外できているか
通知先	個人情報や機密情報を見せてよい相手か
通知文面	外部に出してよい項目だけか
失敗時	管理者が失敗を確認できるか
無効化手順	誤通知時にすぐ止められるか
棚卸し	使われなくなった通知を削れるか

Webhookは、必要に応じて無効化できます。

kintoneヘルプでは、Webhook設定を削除せずに無効化する手順も説明されています。

kintoneヘルプ：Webhookを利用できないようにする

本番運用では、誤通知時にすぐ止める手順を用意しておきます。

通知を作る人、止める人、ログを見る人を分けずに、責任者を明確にします。

外部通知ログと対応履歴を分ける

通知カスタマイズでは、「通知したこと」と「対応したこと」を分けます。

Slackに通知が流れた。

Teamsに投稿された。

メールが送られた。

Webhookログでは成功している。

これだけでは、業務が完了したとは言えません。

通知後に、誰が、いつ、何をしたかをkintone側で追える必要があります。

管理したいこと	管理場所
通知が送れたか	Webhookログ、外部連携ログ
誰が通知を見たか	原則、通知ログだけでは分からない
誰が対応したか	kintoneレコード、ステータス、コメント
期限内に対応したか	期限項目、対応日時、一覧
例外対応が必要か	対応履歴アプリ、管理者一覧

外部チャットは、気づきと会話には向いています。

しかし、業務履歴の正本にはしにくいです。

そのため、対応完了はkintoneへ戻します。

たとえば、問い合わせ通知なら、次のようにします。

流れ	管理場所
緊急問い合わせ登録	kintoneレコード
Slackへ通知	Webhookまたは連携サービス
担当者が初動確認	kintoneステータス、コメント
顧客へ返信	対応履歴、返信日時
期限超過の確認	一覧、ダッシュボード

通知を外に出すほど、kintoneに戻す設計が重要になります。

よくある失敗

失敗1：全更新をチャットへ流す

全更新をチャットへ流すと、最初は便利に見えます。

しかし、すぐに読まれなくなります。

外部チャットへ流すのは、重要条件、例外、期限超過、連携失敗に絞ります。

通常の更新は、kintone内通知や一覧で管理します。

失敗2：ポップアップを出せば対応されると思う

ポップアップは、画面を操作している人への注意喚起です。

対応責任や期限が決まっていなければ、閉じられて終わります。

ポップアップを出すなら、表示条件、文面、次の操作、保存可否まで設計します。

失敗3：Webhookの失敗を誰も見ない

Webhookは、設定すれば終わりではありません。

失敗ログを見る人。

再送する人。

通知先を変更する人。

障害時に一時停止する人。

ここまで決めておかないと、外部通知が止まっても気づけません。

失敗4：通知文面に情報を出しすぎる

チャット通知やメール通知に、個人情報、金額、顧客情報を出しすぎると、権限設計が崩れます。

kintone内では見られる人が限定されている情報でも、外部チャットに流すと閲覧範囲が広がることがあります。

通知文面には、外部に出してよい項目だけを入れます。

詳細はレコードURLから確認する設計にします。

失敗5：カスタマイズの保守者を決めない

JavaScript、プラグイン、Webhook、外部連携サービスは、設定後も保守が必要です。

誰が変更するか。

誰がログを見るか。

誰が障害時に止めるか。

誰が退職・異動時に引き継ぐか。

通知カスタマイズは、実装より運用責任の方が重要です。

kintone通知カスタマイズのチェックリスト

最後に、通知カスタマイズ前のチェックリストです。

チェック	確認すること
目的	通知を受けた人が何をするか書けるか
標準通知	kintone内通知やメールで足りるものを分けたか
条件	外部に出す通知を重要条件に絞ったか
宛先	担当者、責任者、チャンネルの役割が明確か
文面	業務名、対象、重要度、期限、URLが分かるか
ポップアップ	画面を開いている人への注意喚起として妥当か
Webhook	制限、ログ、失敗時、無効化手順を確認したか
権限	外部通知に出してよい情報だけか
対応履歴	通知後の対応をkintoneへ戻せるか
保守	設定変更、ログ確認、棚卸しの担当者がいるか

通知カスタマイズは、kintoneを便利に見せるための装飾ではありません。

標準通知で足りるものを残し、外に出すべき通知だけを絞り、通知後の対応履歴まで戻す設計です。

kintoneダッシュボードの設計方法はこちら
kintoneプロセス管理の設計方法はこちら
kintoneフォーム連携の設計方法はこちら

Bitlightに相談できること

Bitlightでは、kintone通知カスタマイズを、単なるチャット連携やポップアップ追加としてではなく、業務上の対応を前に進める通知設計として整理します。

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

相談内容	支援できること
通知が多すぎる	標準通知、メール、チャット、一覧の役割を分ける
SlackやTeamsへ流したい	通知条件、文面、チャンネル、ログ確認を設計する
ポップアップを出したい	JavaScriptダイアログや入力補助の適用範囲を整理する
Webhookを使いたい	制限、失敗時、外部ログ、再送手順まで含めて設計する
誤通知が怖い	本番・テスト、通知先、文面、無効化手順を設計する
対応漏れが残る	通知後のステータス、コメント、対応履歴アプリまで整える

通知カスタマイズは、通知を増やすほど良くなるものではありません。

必要な通知だけを外へ出し、対応履歴はkintoneに戻す。

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