Notion Slack連携の使い方｜通知・タスク化・DB連携を業務に組み込む

NotionとSlackは、相性のよい組み合わせです。

Slackで依頼が来る。Notionにタスクを作る。Notionのデータベース更新をSlackへ通知する。Slackに貼ったNotionリンクからページの内容を確認する。こうした流れを作ると、会話と業務DBをつなぎやすくなります。

ただし、実務で失敗するのは、連携できないことではありません。

失敗するのは、連携後の運用ルールがないことです。

• Slackの会話に依頼が埋もれたままになる
• Notionに転記したタスクの担当者と期限が空欄になる
• すべてのDB更新をSlackへ流して、誰も通知を見なくなる
• Slackから作ったページが、どのDBに入ったか分からなくなる
• 顧客情報や社内メモを含むNotionページを、広いSlackチャンネルに貼ってしまう
• 通知は来るが、誰が対応済みにするか決まっていない
• SlackスレッドとNotionタスクのどちらが正か分からなくなる

Notion Slack連携は、通知機能ではなく、Slackで発生した会話をNotionの業務DBに変換し、必要な更新だけをSlackへ戻す設計 として扱うべきです。

この記事では、NotionとSlackの連携を、Slackメッセージのタスク化、Notionデータベースへの登録、DB更新通知、権限、通知疲れを防ぐ運用ルールまで実務目線で整理します。

先に結論：Slackは入口、Notionは台帳

NotionとSlackを連携するときは、まず役割を分けます。

役割	向いている場所
相談、依頼、確認、雑談	Slack
正式なタスク、案件、問い合わせ、ナレッジ	Notion
担当者、期限、状態、履歴	Notionデータベース
更新通知、リマインド、エスカレーション	Slack
週次レビュー、未対応確認、棚卸し	Notionビュー

Slackは、会話のスピードに強いです。

一方で、過去の依頼、未対応、期限、担当者を管理するには弱いです。

Notionは、DBとして担当者、期限、ステータス、確認者、関連資料を持てます。

一方で、緊急の呼びかけや日々の会話にはSlackの方が向いています。

そのため、連携の基本は次の形です。

流れ	目的
SlackからNotionへ登録	依頼やアイデアをDBに残す
NotionからSlackへ通知	対応が必要な更新だけ知らせる
SlackリンクをNotionに残す	発生元の会話へ戻れるようにする
NotionリンクをSlackに貼る	正式な情報源を共有する

Notion公式ヘルプでは、Slack連携によりSlackメッセージをNotionデータベースへ送ったり、Notion上のアクティビティをSlack通知として受け取ったりできると説明されています。

Notion公式ヘルプ：Integrate Slack

ただし、連携できる機能を全部使う必要はありません。

最初に決めるべきなのは、どのSlack会話をNotionのどのDBに入れるかです。

SlackからNotionに送る

Slack上で発生した依頼やアイデアは、そのままでは流れていきます。

Notion連携では、SlackメッセージをNotionデータベースへ送れます。

公式ヘルプでは、Slackの /notion create やメッセージメニューの Send to Notion から、Notionデータベースにページを作成できると説明されています。また、/notion task や Create task in Notion でNotionタスクを作る流れも紹介されています。

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

Slackの内容	入れるDB	理由
作業依頼	タスクDB	担当者、期限、状態を管理する
顧客からの相談	問い合わせDB	対応履歴と担当を残す
改善アイデア	改善要望DB	優先度と採否を判断する
障害、エラー報告	インシデントDB	影響範囲、対応者、再発防止を残す
会議で出た宿題	タスクDB、議事録DB	決定事項と対応事項を分ける

Notion側のDBには、最低限次のプロパティを用意します。

プロパティ	型	目的
タイトル	タイトル	依頼内容を短く表す
発生元	セレクト	Slack、会議、メール、フォームなどを分ける
Slackリンク	URL	元の会話に戻れるようにする
依頼者	ユーザー、テキスト	誰から来た依頼か残す
担当者	ユーザー	対応責任者を決める
期限	日付	放置を防ぐ
ステータス	ステータス	未確認、対応中、確認待ち、完了を分ける
通知先	セレクト	どのSlackチャンネルに戻すか決める
確認状態	ステータス	担当者が見たか、完了確認済みかを分ける

SlackからNotionへ送るだけでは不十分です。

Notionに入ったあと、担当者、期限、ステータスが入って初めて業務管理になります。

Notionタスク管理の作り方

NotionからSlackへ通知する

Notionの更新をSlackに通知する方法もあります。

公式ヘルプでは、NotionのSlack通知として、メンション、コメント、データベースのプロパティ変更、ページへの招待、アクセスリクエストなどをSlackで受け取れると説明されています。

また、Notionのボタン、データベースボタン、データベースオートメーションから、特定のSlackチャンネルへ通知を送ることもできます。

ただし、すべての更新をSlackに流すと失敗します。

通知は、行動が必要なものだけに絞ります。

通知する条件	通知先	理由
新しい問い合わせが追加された	担当チャンネル	初動を早くする
期限が近いタスクが未完了	担当者、管理チャンネル	放置を防ぐ
ステータスが確認待ちになった	確認者	レビューを促す
障害ステータスが発生中になった	インシデントチャンネル	即時共有が必要
重要顧客の対応が完了した	営業、CSチャンネル	関係者へ共有する

逆に、次の通知は絞った方がよいです。

通知しすぎる例	問題
すべてのプロパティ変更	ノイズになり重要通知が埋もれる
コメント追加すべて	雑談や軽微な確認まで流れる
自分用DBの更新	チームに不要な通知が増える
作成直後の下書きページ	未整理の情報が広がる

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

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

通知は「何が起きたか」を知らせるだけでは弱いです。

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

項目	例
何が起きたか	新しい問い合わせが登録されました
誰が見るか	担当者：山田
いつまでか	期限：6月10日
どこで処理するか	Notionページへのリンク
次に何をするか	初回返信後、ステータスを確認待ちへ変更

通知は、業務の入口です。

正式な処理はNotion DBで行います。

タスク化の運用ルール

Slack連携で最初に作るべきなのは、便利な自動化ではありません。

タスク化のルールです。

Slack上のどの投稿をNotionに入れるのかを決めます。

Slack投稿	Notionに入れるか
「あとで確認お願いします」	入れる
顧客からの対応依頼	入れる
障害や不具合の報告	入れる
雑談や参考情報	入れない、またはナレッジ候補
決定事項を含むスレッド	議事録DBまたは決定事項DBに入れる
単なるリアクション	入れない

Notionに入れる基準は、次のどれかに当てはまるかです。

• 担当者が必要
• 期限が必要
• 完了判定が必要
• 後から検索する必要がある
• 顧客や案件の履歴として残す必要がある
• 会議や週次レビューで確認する必要がある

Notionに入れたら、Slackスレッドで「Notionに起票済み」と返す運用も有効です。

これにより、同じ依頼が複数タスクになるのを防げます。

DB設計の例

Slack連携用に、最初から大きなDBを作る必要はありません。

まずは、タスクDBか問い合わせDBに寄せるのが現実的です。

タスクDB

プロパティ	型	入力例
タスク名	タイトル	見積書の修正
発生元	セレクト	Slack
Slackリンク	URL	元スレッドURL
関連案件	リレーション	A社導入支援
担当者	ユーザー	佐藤
確認者	ユーザー	森田
期限	日付	2026-06-10
ステータス	ステータス	未確認、対応中、確認待ち、完了
通知先	セレクト	#project-a

問い合わせDB

プロパティ	型	入力例
問い合わせ名	タイトル	請求書の再発行依頼
顧客	リレーション	A社
発生元	セレクト	Slack
Slackリンク	URL	元スレッドURL
分類	セレクト	請求、障害、要望、質問
初回対応者	ユーザー	田中
対応期限	日付	2026-06-07
対応状態	ステータス	未対応、対応中、顧客確認中、完了
重要度	セレクト	高、中、低

Notionデータベースの作り方

大事なのは、Slackの投稿本文をそのままNotionに貼ることではありません。

Notion側で、担当者、期限、状態、関連案件、確認者を持たせることです。

権限とチャンネル設計

Slack連携では、権限も重要です。

Notion公式ヘルプでは、SlackにNotionリンクを貼るとページのプレビューが表示され、Slack内でNotionページへのアクセス権限を付与できる場合があると説明されています。

これは便利ですが、業務では注意が必要です。

注意点	理由
広いSlackチャンネルに機密ページを貼らない	アクセス付与の判断を誤りやすい
顧客情報DBの通知先を限定する	個人情報や商談情報が含まれる
外部ゲストのいるチャンネルを確認する	社外に見せない情報が混ざる
DB通知を作れる人を絞る	通知先や内容を誤ると情報が広がる
Slackリンクだけを正式記録にしない	スレッドが流れ、検索や棚卸しが難しい

Notion側の権限設計は、別記事で整理しています。

Notion権限設定の基本

Slack連携では、次のようにチャンネルを分けると管理しやすくなります。

チャンネル	用途
#project-a	案件別のタスク通知
#support	問い合わせ、障害、顧客対応
#sales	商談、顧客対応、提案進捗
#ops-alert	期限超過、確認待ち、承認待ち
#notion-admin	連携設定、権限、通知ルール変更

通知先を1つにまとめすぎると、すぐに見られなくなります。

Slackチャンネルは、業務責任の単位で分けます。

通知疲れを防ぐ

Slack連携の最大の失敗は、通知疲れです。

通知が多すぎると、重要な通知も見られなくなります。

通知設計では、次の3つを分けます。

通知の種類	例	扱い
即時対応	障害、重要顧客、期限超過	Slackへ送る
日次確認	未対応問い合わせ、確認待ち一覧	Notionビューで見る
週次棚卸し	滞留タスク、完了漏れ、担当者未設定	会議で見る

すべてをSlackに流すのではなく、Slackに流すものとNotionで見るものを分けます。

Notion側には、通知の代わりになるビューを作ります。

ビュー	条件
未確認	ステータスが未確認
今日期限	期限が今日以前、完了以外
確認待ち	ステータスが確認待ち
Slack起票	発生元がSlack
担当者未設定	担当者が空
7日以上滞留	更新日が7日以上前、完了以外

通知で全部解決しようとしない。

Notionビューで拾えるものは、ビューで拾う。

これが通知疲れを防ぐ基本です。

よくある失敗パターン

NotionとSlackの連携では、次の失敗がよくあります。

失敗	原因	対策
Slackから作ったタスクが放置される	担当者、期限、確認者が空	必須プロパティを決める
同じ依頼が重複する	起票済みの返信がない	SlackスレッドにNotionリンクを返す
通知が多すぎる	すべての変更を流している	通知条件を絞る
機密情報が広がる	広いチャンネルにNotionリンクを貼る	通知先と権限を限定する
NotionとSlackで状態がずれる	どちらが正か決めていない	正式状態はNotionに寄せる
自動化が壊れても気づかない	エラー確認者がいない	管理者と月次点検を決める

連携は、作った瞬間よりも、運用が変わったときに崩れます。

チャンネルが増える。DBが増える。担当者が変わる。外部ゲストが増える。通知条件が増える。

そのため、月1回は連携を棚卸しします。

棚卸し対象	見ること
Slack通知	まだ必要な通知か
通知先チャンネル	関係者だけが見ているか
Notion DB	担当者、期限、ステータスが使われているか
権限	外部ゲストや退職者が残っていないか
自動化	エラーや停止がないか
重複タスク	Slack起票が二重になっていないか

まとめ

NotionとSlackの連携は、単なる通知機能として扱わない方がよいです。

Slackは会話の入口です。

Notionは、タスク、問い合わせ、案件、ナレッジを管理する台帳です。

SlackからNotionへ送るときは、担当者、期限、ステータス、Slackリンクを持つDBに入れます。

NotionからSlackへ通知するときは、行動が必要な更新だけに絞ります。

すべての更新をSlackへ流すと、通知疲れが起きます。

権限にも注意が必要です。NotionリンクをSlackに貼るときは、誰がそのチャンネルにいるか、どのページにアクセスできるかを確認します。

正式な状態管理はNotionに寄せ、Slackには起票済みや確認依頼を返す。

この役割分担ができると、Notion Slack連携は、会話を流さず、業務DBへ変換する仕組みになります。