kintoneとSlack連携の設計方法｜通知過多を防ぐ業務フロー

kintoneとSlackを連携したい相談では、最初に「kintoneの通知をSlackへ飛ばしたい」という話になります。

問い合わせが登録されたらSlackで知らせたい。

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

案件ステータスが変わったら営業チャンネルに投稿したい。

障害やクレームのレコードが作られたら全員に気づいてほしい。

期限超過したタスクを毎朝Slackに出したい。

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

ただし、kintoneの通知をそのままSlackへ増やすと、次のような状態になりがちです。

• 通知が多すぎて、重要なレコード追加が流れる
• チャンネルには投稿されるが、誰が対応するのか決まっていない
• Slackでは反応されたが、kintone側のステータスが変わらない
• DM通知とチャンネル通知が重複し、同じ人に何度も届く
• メンションが多すぎて、関係ない人が通知を無視するようになる
• ステータス変更、コメント、編集のたびに似た投稿が出る
• Slackに個人情報や金額を出しすぎる
• Webhook URLやSlackアプリの権限を誰が管理しているか分からない
• 投稿失敗時に、kintone側でどの通知が漏れたのか追えない

Slackは、気づくための場所です。

kintoneは、業務データと対応状態を残す場所です。

この役割を分けずにSlackへ流すと、会話は増えますが、対応責任は曖昧になります。

kintoneとSlack連携で最初に決めるべきなのは、通知先ではなく、「誰が反応し、どこで対応完了を記録するか」です。

この記事では、kintoneとSlack連携を、設定手順ではなく、標準Slack連携、DM通知、チャンネル通知、プロセス管理、Webhook、JavaScript、iPaaS、通知条件、メンション、対応ログ、通知過多と対応漏れの防止まで含めて整理します。

kintone通知の設計方法はこちら
kintone通知カスタマイズの設計方法はこちら
kintone Webhookの設計方法はこちら
kintoneワークフローの設計方法はこちら

Slack連携は通知設計から始める

kintoneとSlackを連携するときは、最初に通知の種類を分けます。

Slackに投稿できるかどうかではなく、通知の目的を決めます。

通知の種類	主な目的	向いている通知先
作業依頼	担当者に動いてもらう	Slack DM、担当者メンション
チーム共有	チームが状況を知る	Slackチャンネル
重要アラート	すぐ反応が必要	専用チャンネル、メンション
期限超過	滞留を減らす	担当者DM、管理者チャンネル
完了報告	状態を共有する	チャンネル、日次まとめ
記録	後から追う	kintone対応ログ、連携ログ

通知先を増やすほど、反応は弱くなります。

全員に届く通知は、誰の仕事でもない通知になりやすいからです。

そのため、設計では次の順番で考えます。

順番	決めること
1	通知すべきイベントか
2	反応する人は誰か
3	反応期限はあるか
4	個人に送るか、チームに送るか
5	Slackで会話するだけか、kintoneで状態を変えるか
6	投稿失敗や未対応をどこで追うか

たとえば、問い合わせ受付はチームチャンネルへ出してもよいです。

ただし、担当が決まった後の対応依頼は、担当者へ絞った方がよいです。

申請の承認依頼は、作業者へのDMに向きます。

一方で、障害やクレームの一次報告は、チームチャンネルへ出して状況を共有する価値があります。

Slack連携は「通知をSlackへ流す設定」ではなく、「反応すべき人に、反応できる量で届ける設計」です。

標準Slack連携でできること

kintoneには標準のSlack連携があります。

kintone公式ヘルプでは、Slackとkintoneを連携すると、レコードの作業者になったユーザーへSlackのダイレクトメッセージで通知できると説明されています。

kintoneヘルプ：Slack連携を設定／解除する

標準Slack連携は、プロセス管理と相性がよいです。

承認待ち。

確認待ち。

対応依頼。

差し戻し。

こうした「作業者が明確な状態」に向いています。

用途	標準Slack連携との相性	理由
承認依頼	高い	作業者が明確で、DMに向く
差し戻し	高い	申請者に戻す通知として使いやすい
担当者変更	高い	新しい作業者へ気づかせやすい
チーム共有	低い	標準連携はチャンネル投稿が主目的ではない
重要アラート	条件次第	作業者が決まるなら使える
日次まとめ	低い	まとめ通知には別設計が必要

標準Slack連携を使うには、kintoneとSlackワークスペース側のメールアドレス一致、外部連携の有効化、アプリ側のプロセス管理設定などが必要です。

公式ヘルプでは、メールアドレス一致、外部連携の有効化、プロセス管理、アプリ側のSlack連携設定が流れとして案内されています。

標準連携でまず確認すべきことは、次です。

確認項目	見ること
作業者	プロセス管理で作業者が明確に設定されているか
メールアドレス	kintoneとSlackで同じメールアドレスか
対象アプリ	Slack連携を設定するアプリが決まっているか
通知量	作業者変更が多すぎないか
代替通知	kintone内通知、メール通知、Slack通知が重複しないか

標準連携は、まず「作業者への気づき」を補うものとして使います。

チーム全員へ投稿したい、特定条件でメンションしたい、文面を細かく変えたい、一覧をまとめて通知したい場合は、別の方法を検討します。

チャンネル通知が必要なケース

Slackチャンネルへ投稿したい場面もあります。

ただし、すべてのkintone通知をチャンネルへ流すのは避けます。

チャンネル通知が向くのは、チームで同じ事実を見たい場面です。

ケース	チャンネル通知が向く理由
新規問い合わせ	チーム全体で受付状況を知る
障害・クレーム	複数人が早く状況を把握する
重要案件のステータス変更	営業、管理、現場が同じ変化を見る
承認完了	後続工程の担当者が動き始める
日次の未対応一覧	管理者が滞留を確認する
緊急度の高い期限超過	担当者だけでなく管理者も把握する

一方で、次の通知はチャンネル投稿に向きません。

通知	向かない理由
軽微なレコード編集	投稿が増え、重要通知が流れる
コメント追加すべて	会話の一部だけSlackに出て文脈が崩れる
個人の承認依頼	チーム全体には関係ないことが多い
個人情報を含む詳細	Slackに出す範囲を絞る必要がある
金額や契約条件の全文	アクセス範囲とログ管理を分ける必要がある

チャンネル通知では、文面を短くします。

詳しい内容はkintoneレコードを見に行く形にします。

Slackに出す情報	kintoneに残す情報
件名、状態、担当、期限、URL	詳細本文、添付、個人情報、対応履歴
重要度、次のアクション	承認履歴、変更履歴、コメント
メンション、対応期限	正式なステータス、完了記録

Slackチャンネルには「見に行くきっかけ」を出し、正式な対応状態と履歴はkintoneに残します。

プロセス管理と通知タイミング

kintoneとSlack連携では、プロセス管理のステータスが通知条件になります。

レコードが作成されたときに通知するのか。

ステータスが「確認待ち」になったときに通知するのか。

担当者が変わったときに通知するのか。

期限を過ぎたときに通知するのか。

ここを整理します。

kintoneプロセス管理の設計方法はこちら

通知タイミングは、次のように分けます。

タイミング	通知先	設計の考え方
新規登録	チームチャンネル	受付共有。担当はまだ決めない場合がある
担当者決定	担当者DM	反応すべき人を明確にする
承認依頼	作業者DM	プロセス管理の作業者通知に寄せる
差し戻し	申請者DM	何を直すかをkintoneに残す
期限前	担当者DM	リマインド。頻度を抑える
期限超過	担当者DM、管理者チャンネル	滞留を見えるようにする
完了	関係者チャンネル	後続工程がある場合だけ出す

「レコードが編集されたら通知する」は、慎重に使います。

編集は頻度が高く、内容も軽重があります。

保存のたびにSlackへ投稿すると、通知はすぐ読まれなくなります。

重要なのは、状態が変わったときです。

受付。

担当決定。

承認依頼。

差し戻し。

対応完了。

期限超過。

こうした業務上の節目に絞ります。

通知先・メンション・重要度の分け方

Slack連携で設計すべきなのは、投稿先だけではありません。

メンションを使うかどうかも重要です。

メンションは強い通知です。

多用すると、緊急度の高い通知まで無視されます。

重要度	通知方法	例
低	kintone内通知、一覧で確認	参考共有、日次確認
中	Slackチャンネル投稿	新規問い合わせ、完了報告
高	担当者メンション、作業者DM	承認依頼、期限超過
緊急	専用チャンネル + 担当者メンション	障害、重大クレーム

通知先は、業務単位で設計します。

業務	推奨する通知先
問い合わせ受付	#support-intake のような受付チャンネル
営業案件の重要更新	営業チームチャンネル
承認依頼	作業者DM
経理確認	経理チームチャンネル、担当者DM
障害・クレーム	専用チャンネル、責任者メンション
日次滞留確認	管理者チャンネル、まとめ投稿

Slackのチャンネル設計も必要です。

1つのチャンネルに、問い合わせ、承認、障害、日次まとめ、雑談が混ざると、通知の意味が弱くなります。

ただし、チャンネルを増やしすぎても見られません。

おすすめは、業務の責任者が見る単位で分けることです。

たとえば、問い合わせ受付、経理確認、障害対応、営業重要更新のように分けます。

文面は、次の要素に絞ります。

要素	目的
何が起きたか	新規受付、承認依頼、期限超過など
誰が対応するか	担当者、チーム、承認者
いつまでか	期限、優先度
どこを見るか	kintoneレコードURL
何をしてほしいか	確認、承認、返信、差し戻し

長文をSlackに出すより、kintoneで確認すべきレコードへ誘導します。

Webhook・JavaScript・iPaaSの使い分け

kintoneからSlackへ通知する方法は複数あります。

標準Slack連携で足りない場合は、Webhook、JavaScriptカスタマイズ、iPaaS、個別API連携を検討します。

方法	向いているケース	注意点
標準Slack連携	作業者へのDM通知	チャンネル投稿や複雑な文面には向かない
kintone Webhook	レコード操作を外部へ知らせる	受信側でSlack投稿処理を作る
JavaScriptカスタマイズ	画面操作やプロセス変更に合わせた投稿	秘密情報をフロントに置かない設計が必要
iPaaS	条件分岐、複数サービス連携、管理画面運用	フロー所有者、実行ログ、料金を確認する
個別API連携	厳密な制御、再実行、監査ログ	開発・監視・保守が必要

kintone公式ヘルプでは、Webhookを使うと、レコード追加、編集、削除、コメント、ステータス更新などの操作を外部サービスへ送信できることが説明されています。

kintoneヘルプ：Webhookを設定する

kintone Developer Programでは、プロセス管理のステータスが完了へ進んだときに、JavaScriptカスタマイズからSlack Incoming Webhookへリクエストを送り、Slackチャンネルへ投稿する例が紹介されています。

ただし、その記事でも、ネイティブWebhook機能ではなくJavaScriptカスタマイズによる実装であることが示されています。

Kintone Developer Program：Share Process Management Statuses with Slack

Slack公式ドキュメントでは、Incoming WebhookはSlackアプリからSlackへメッセージを投稿する方法として説明されています。

Webhook URLは秘密情報であり、公開リポジトリなどに載せないよう注意が必要です。

Slack Developer Docs：Sending messages using incoming webhooks

kintone外部連携の設計方法はこちら
kintone連携サービスの選び方はこちら

設計上は、Slackへ直接投げるだけでなく、通知ログを残すことも考えます。

処理	直接投稿でよいか	ログが必要か
参考共有	直接投稿でもよい	低
承認依頼	標準連携やプロセス管理で追う	中
期限超過	追跡が必要	高
障害・クレーム	投稿失敗が業務影響になる	高
外部顧客対応	記録と監査が必要	高

重要通知では、Slack投稿の成否をkintoneの連携ログに残します。

失敗した場合は、管理者チャンネルや保留一覧で見えるようにします。

通知過多と対応漏れを防ぐ運用

Slack通知は、作って終わりではありません。

運用で見直します。

通知過多を防ぐには、次を決めます。

設計項目	決めること
通知条件	どの状態、どの重要度、どの期限で出すか
抑止条件	下書き、軽微な編集、完了済みでは出さない
まとめ通知	毎朝の未対応一覧など、個別通知をまとめる
再通知	何時間後、何日後に再通知するか
既読後の処理	Slackで見ただけでは完了にしない
対応ログ	kintone側で誰がいつ対応したか残す
通知棚卸し	月1回などで不要通知を止める

対応漏れを防ぐには、Slackだけに頼らないことが重要です。

Slack投稿は流れます。

検索できますが、正式な対応台帳ではありません。

kintone側に、未対応一覧、期限超過一覧、自分が作業者の一覧、管理者確認一覧を作ります。

kintone側の一覧	目的
自分の未対応	個人が今日見る
チーム未対応	チームリーダーが見る
期限超過	滞留を確認する
通知失敗	連携エラーを見る
重要案件	チャンネル通知対象を確認する
対応完了待ち	Slackで反応済みでもkintone未完了のものを見る

Slackには「気づくきっかけ」を出します。

kintoneには「対応状態」を残します。

この2つを分けると、Slackで見落としてもkintone一覧で拾えます。

Slack通知で対応漏れを防ぐには、Slack投稿ではなく、kintone側の未対応一覧と対応ログを正本にします。

よくある失敗

kintoneとSlack連携でよくある失敗を整理します。

失敗	原因	対策
通知が多すぎて読まれない	編集やコメントごとに投稿している	業務上の状態変更に絞る
チャンネル投稿だけで対応者がいない	責任者を決めていない	作業者DM、担当者メンション、kintone作業者を使う
Slackで反応したがkintoneが未対応	対応完了の正本を決めていない	kintoneステータス変更を完了条件にする
DMとチャンネル通知が重複する	通知設計を分けていない	個人依頼とチーム共有を分ける
個人情報を出しすぎる	Slack文面をレコード全文にしている	Slackには概要とURLだけ出す
メンションが乱発される	重要度別のルールがない	緊急・高・中・低で通知方法を分ける
Webhook URLが漏れる	秘密情報として管理していない	環境変数、連携サービス、権限管理で守る
投稿失敗に気づかない	通知ログがない	成功、失敗、再実行可否をkintoneに残す
チャンネルが増えすぎる	業務単位を決めていない	責任者が見る単位にまとめる

特に危ないのは、Slackチャンネル投稿を「全員への作業依頼」として使うことです。

チャンネル投稿は共有には向きます。

しかし、誰かに処理してほしいなら、担当者をkintone上で持たせ、作業者やメンションを明確にします。

Slackで「お願いします」と投稿されても、kintone上の担当者と期限が空欄なら、業務は進みません。

実装前チェックリスト

kintoneとSlackを連携する前に、次を確認します。

チェック	確認内容
通知目的	作業依頼、共有、アラート、完了報告、記録のどれか
通知先	DM、チャンネル、メンション、まとめ通知を分けたか
作業者	kintoneのプロセス管理で作業者が明確か
チャンネル	業務責任者が見る単位で設計したか
通知条件	レコード追加、ステータス変更、期限超過などの条件を絞ったか
抑止条件	下書き、軽微な編集、完了済みを除外したか
文面	Slackには概要、担当、期限、URLだけ出す設計か
個人情報	Slackに出してよい項目を決めたか
連携方法	標準Slack連携、Webhook、JavaScript、iPaaS、個別APIを選んだか
秘密情報	Incoming Webhook URLやトークンを安全に管理できるか
ログ	投稿成功、失敗、再実行可否を残すか
運用見直し	不要通知を定期的に止めるルールがあるか

Slack連携は、導入直後は反応がよく見えます。

しかし、通知が増えるほど、読む側の集中は落ちます。

だからこそ、初期設計で通知を絞り、運用後に止める通知を決められる状態にします。

Bitlightに相談できること

Bitlightでは、kintoneとSlack連携を、通知設定ではなく業務フローとして設計できます。

たとえば、次のような相談に対応できます。

• kintoneのプロセス管理、作業者、ステータスを前提にしたSlack通知設計
• 標準Slack連携で足りる範囲と、チャンネル通知が必要な範囲の切り分け
• Webhook、JavaScript、iPaaS、個別API連携の選定
• 問い合わせ、承認、タスク、障害、経理確認など業務別の通知条件整理
• Slack文面、メンション、チャンネル、通知頻度の設計
• 投稿ログ、失敗通知、再実行、保留一覧の設計
• 個人情報、金額、契約条件をSlackへ出す範囲の整理
• 既存Slack通知の棚卸しと不要通知の停止

kintoneとSlack連携は、通知を増やすための仕組みではありません。

必要な人が、必要なタイミングで気づき、正式な対応状態をkintoneに残すための仕組みです。

kintoneとSlack連携は、Slackを対応台帳にするのではなく、kintoneの未対応レコードへ戻す導線として設計すると使いやすくなります。