Notion Slack通知の作り方｜DB更新をチームに届ける自動化設計

NotionのSlack通知は便利です。

Notionでページが追加された。データベースのステータスが変わった。コメントやメンションが来た。確認待ちになった。期限超過が発生した。

こうした更新をSlackへ流せると、チームの反応は早くなります。

ただし、Notionの更新をすべてSlackへ流すと、すぐに読まれなくなります。

• どの通知が重要か分からない
• 同じDBから似た通知が何度も来る
• 作成直後の下書きまでSlackに流れる
• Slackでは通知を見たが、Notion側のステータスが変わらない
• 期限超過なのか、ただのコメントなのか分からない
• 誰が対応する通知なのか分からない
• 通知設定を誰が作ったか分からず、止められない

Notion Slack通知は、更新を全部知らせる機能ではなく、行動が必要なDB更新だけをSlackに出し、一覧確認はNotionビューに残す設計 として扱うべきです。

この記事では、NotionのSlack通知を、個人通知、データベースオートメーション、ボタン通知に分け、通知条件、通知先、文面、権限、通知疲れを防ぐ運用まで整理します。

先に結論：Slack通知は即時対応だけに絞る

NotionからSlackへ出す通知は、即時に誰かが動くものだけに絞ります。

通知の種類	Slackへ出すか	理由
新規問い合わせ	出す	初動が遅れると顧客対応に影響する
障害、緊急対応	出す	すぐに関係者へ共有する必要がある
確認待ち	出す	確認者の作業を促す
期限超過	出す	放置を止める必要がある
重要顧客の状態変更	出す	営業やCSが即時に把握したい
全ページの軽微な修正	出さない	ノイズになりやすい
下書きページの作成	出さない	未整理の情報が広がる
日次で見ればよい未対応一覧	出さない	Notionビューで確認できる

Slackに流すべきなのは、チームが今すぐ気づく必要がある更新です。

それ以外は、Notion側にビューを作って確認します。

Notionビュー	見るタイミング
未対応	朝会、日次確認
確認待ち	確認者が毎日見る
期限超過	朝会、週次会議
担当者未設定	管理者が日次で見る
7日以上更新なし	週次棚卸し

通知で全部拾おうとすると、通知が増えます。

ビューで拾えるものはビューに逃がす。

これがNotion Slack通知の基本です。

Notion Slack連携全体の設計はこちら

NotionのSlack通知は3種類に分ける

NotionのSlack通知は、1つの機能として見ると混乱します。

実務では、次の3つに分けます。

種類	目的	主な使いどころ
個人通知	自分へのメンションやコメントに気づく	個人の見落とし防止
DBオートメーション通知	DB更新をチャンネルへ流す	問い合わせ、タスク、案件、承認
ボタン通知	人が押したタイミングで通知する	確認依頼、完了報告、エスカレーション

Notion公式ヘルプでは、Slack連携により、Notion上のアクティビティをSlack通知として受け取れること、またデータベースオートメーションなどから特定のSlackチャンネルへ通知できることが説明されています。

Notion公式ヘルプ：Integrate Slack

この3種類を混ぜると、通知の責任が分からなくなります。

個人通知は、自分が気づくための通知です。

DBオートメーション通知は、チームが業務状態を知るための通知です。

ボタン通知は、人が明示的に次の担当者へ渡すための通知です。

個人通知で済むもの

まず、個人通知で十分なものを切り分けます。

公式ヘルプでは、Slack通知でNotionのメンション、コメント、データベースの人物プロパティでのメンションなどを受け取れると説明されています。

Notion公式ヘルプ：Notification settings

Notion本体の通知設定、メール通知、日次ビューまで含めた全体設計は、Notion通知設定の基本で整理しています。

個人通知で済むのは、次のようなケースです。

使いどころ	例
自分への確認依頼	コメントで「確認お願いします」とメンションされた
自分が所有するページのコメント	自分のページに質問が来た
担当者として呼ばれた	DBの人物プロパティで自分が指定された
アクセスリクエスト	自分が所有するページへのアクセス依頼が来た

個人通知は、チーム全体へ流す必要がありません。

個人が気づけばよい通知をチャンネルへ流すと、関係ない人のノイズになります。

ただし、個人通知だけに頼ると弱い場面もあります。

個人通知だけでは弱いケース	理由
問い合わせの初動	誰か1人が休むと止まる
障害対応	関係者全員がすぐ把握する必要がある
承認待ち	確認者だけでなく依頼者も状態を知りたい
期限超過	管理者が横断的に見る必要がある

このようなケースは、DBオートメーション通知にします。

DBオートメーション通知で設計する

Notionのデータベースオートメーションでは、ページ追加やプロパティ変更などをトリガーに、Slack通知などのアクションを設定できます。

Notion公式ヘルプ：データベースオートメーション

実務では、DBごとに通知条件を決めます。

DB	通知条件	通知先
問い合わせDB	新規問い合わせが追加された	#support
問い合わせDB	ステータスが顧客確認中になった	#support-review
タスクDB	ステータスが確認待ちになった	#ops-alert
タスクDB	期限超過で未完了	#ops-alert
案件DB	重要度が高い案件の状態が変更された	#sales
インシデントDB	状態が発生中になった	#incident

大事なのは、通知条件を「更新されたら全部」にはしないことです。

通知条件は、次のように絞ります。

絞る軸	例
ステータス	確認待ち、期限超過、発生中だけ通知
重要度	高だけ通知
担当者	担当者未設定だけ通知
期限	今日以前で完了以外だけ通知
発生元	フォーム、Slack、メールなど外部入力だけ通知
顧客分類	重要顧客だけ通知

DBオートメーション通知は、Notionを正式な台帳にする前提で使います。

Slackに通知が来ても、状態更新はNotionで行います。

Notionデータベースの作り方

ボタン通知で人の判断を残す

すべてを自動通知にしない方がよい場面もあります。

たとえば、担当者が「レビューへ回す」と判断したタイミング、管理者が「エスカレーションする」と判断したタイミングです。

この場合は、ボタン通知が向いています。

公式ヘルプでは、Notionのボタン、データベースボタン、データベースオートメーションからSlack通知を送れることが説明されています。

ボタン	押す人	通知先	目的
確認依頼	担当者	#review	確認者に見るべきページを渡す
完了報告	担当者	#project	関係者に完了を共有する
緊急共有	管理者	#incident	重要な変更だけ即時共有する
承認依頼	申請者	#approval	承認待ちを明示する
顧客返信済み	CS担当	#sales	顧客対応の完了を共有する

ボタン通知の利点は、人の判断を挟めることです。

自動通知では、下書きや仮置きの情報まで流れがちです。

ボタン通知なら、担当者が「今、通知する」と判断してからSlackへ送れます。

通知文面に入れる項目

Slack通知は、文面が弱いと見落とされます。

「ページが更新されました」だけでは、次に何をすればよいか分かりません。

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

項目	例
何が起きたか	新しい問い合わせが登録されました
優先度	重要度：高
担当者	担当者：未設定
期限	対応期限：6月10日
状態	ステータス：確認待ち
どこを見るか	Notionページへのリンク
次にすること	担当者を決めて初回返信してください

通知文面は、読む人がSlack上で判断できる粒度にします。

ただし、詳細な議論や正式な状態管理はNotionページで行います。

通知文面にすべてを書こうとすると、Slackが再び台帳になります。

通知は、Notionページへ戻る入口です。

通知先チャンネルを分ける

通知先チャンネルは、業務責任で分けます。

チャンネル	通知するもの
#support	新規問い合わせ、顧客確認中
#sales	重要商談、顧客対応完了
#ops-alert	期限超過、担当者未設定、確認待ち
#incident	障害、緊急対応
#notion-admin	通知設定変更、エラー、棚卸し

1つのチャンネルに全部流すと、通知はすぐに見られなくなります。

逆に、チャンネルを細かく分けすぎても管理できません。

最初は3つで十分です。

初期チャンネル	目的
業務通知	新規対応や確認待ち
緊急通知	障害や期限超過
管理通知	通知設定や棚卸し

通知先を決めるときは、そのチャンネルに外部ゲストがいないかも確認します。

顧客情報、個人情報、商談メモが含まれるNotionページを、広いSlackチャンネルへ流すのは危険です。

Notion権限設定の基本

通知しない更新を決める

Notion Slack通知で重要なのは、通知する条件より、通知しない条件です。

通知しない更新	理由
下書きページの作成	内容が未整理で誤解を招く
タイトル修正	行動が必要ないことが多い
説明文の軽微な編集	通知価値が低い
自分用メモDBの更新	チームに不要
完了済みページの整理	業務上の即時対応が不要
一括移行中の更新	大量通知になりやすい

通知しない更新は、代わりにNotionビューで確認します。

ビュー	条件
最近追加	作成日が過去7日以内
最近更新	更新日が過去7日以内
未確認	確認状態が未確認
確認待ち	ステータスが確認待ち
期限超過	期限が今日以前、完了以外

通知を減らすことは、情報を隠すことではありません。

即時通知と一覧確認を分けることです。

権限と設定者を決める

Slack通知は、誰でも自由に作れる状態にしない方がよいです。

公式ヘルプでは、データベース通知を作るにはNotionデータベースへのFull Accessが必要と説明されています。また、既存のSlack通知はView権限でも見られる一方、作成や編集はできないと説明されています。

この前提を踏まえて、実務では次の役割を決めます。

役割	担当
通知設計者	どのDBで何を通知するか決める
DB管理者	DBプロパティとオートメーションを管理する
Slack管理者	通知先チャンネルや外部ゲストを確認する
業務責任者	通知が業務に合っているか判断する
棚卸し担当	月次で通知を見直す

通知設定を作った人が退職したり、異動したりすると、誰も止められない通知が残ることがあります。

そのため、通知設定は個人の工夫ではなく、DB管理の一部として扱います。

月次で通知を棚卸しする

Notion公式ヘルプでは、データベース通知は作成された個別DBで管理できる一方、ワークスペース全体のDB通知を一か所で見る方法は現時点ではないと説明されています。

つまり、通知は増えたあとに見つけにくいです。

そのため、通知台帳を作っておくと管理しやすくなります。

項目	例
通知名	新規問い合わせ通知
対象DB	問い合わせDB
トリガー	ページ追加
条件	重要度が高または中
通知先	#support
文面	新規問い合わせ、担当者、期限、ページリンク
管理者	山田
最終確認日	2026-06-06
継続判断	継続、修正、停止

月次では、次を確認します。

見ること	判断
まだ読まれているか	誰も反応しない通知は停止候補
通知条件が広すぎないか	条件を絞る
通知先が適切か	チャンネルを変える
権限事故がないか	ゲストや広いチャンネルを確認する
Notionビューで代替できないか	Slack通知を減らす
管理者が残っているか	担当を更新する

通知は、作ったあとに増えます。

増えた通知を減らす運用まで決めておく必要があります。

よくある失敗

Notion Slack通知でよくある失敗は、次の通りです。

失敗	原因	対策
通知が多すぎる	全更新を流している	条件を確認待ち、期限超過、重要度高に絞る
誰も対応しない	担当者や次アクションが書かれていない	通知文面に担当者、期限、次アクションを入れる
機密情報が広がる	通知先チャンネルが広すぎる	通知先とNotion権限をセットで確認する
同じ通知が重複する	複数人が似た自動化を作った	通知台帳を作る
Slackだけで処理される	Notionへ戻るルールがない	正式状態はNotion DBに寄せる
古い通知が残る	棚卸ししていない	月次で継続、修正、停止を決める

特に危ないのは、Slack通知を作って満足することです。

通知は、業務フローの一部です。

通知が来たあと、誰がNotionを更新するかまで決めて初めて運用になります。

まとめ

Notion Slack通知は、見落としを減らすために便利です。

しかし、通知を増やすだけでは、むしろ見落としが増えます。

まず、Slackへ出す通知とNotionビューで見る情報を分けます。

Slackへ出すのは、新規問い合わせ、確認待ち、期限超過、障害、重要顧客の更新など、行動が必要なものだけです。

個人通知、DBオートメーション通知、ボタン通知も分けます。

個人通知は、自分へのメンションやコメントに気づくためのものです。

DBオートメーション通知は、チームで対応が必要なDB更新を知らせるものです。

ボタン通知は、人が判断して確認依頼や完了報告を送るものです。

通知文面には、何が起きたか、担当者、期限、状態、Notionページリンク、次アクションを入れます。

通知先チャンネルは、業務責任で分けます。外部ゲストや機密情報にも注意します。

最後に、通知台帳を作り、月次で棚卸しします。

Notion Slack通知は、更新を流す機能ではありません。

Notion DBで管理すべき業務状態を、必要な人へ、必要なタイミングで知らせる仕組みとして設計することが大切です。