Notionオートメーションの使い方｜DB更新・通知・Webhookを業務に組み込む

Notionオートメーションを使うと、データベースのページ追加、プロパティ変更、定期実行などをきっかけに、DB更新、通知、Slack通知、メール送信、Webhook送信などを実行できます。

問い合わせが追加されたらSlackに通知する。ステータスが「確認待ち」になったら確認者へ通知する。期限を過ぎたタスクを期限超過ビューに出す。Webhookで外部処理へ渡す。

こうした定型処理には向いています。

ただし、会社で使う場合は「自動化できることを増やす」だけでは足りません。

• 何が起きたら自動化するのか
• どのDBのどのプロパティを変えるのか
• 誰に通知するのか
• 通知後に誰が確認するのか
• 失敗したときに誰が気づくのか
• 人が判断する工程をどこに残すのか
• 外部サービスへ送ってよい情報か

ここを決めずにオートメーションを増やすと、通知が増え、ステータスが勝手に変わり、失敗しても気づけない運用になります。

Notion公式ヘルプでは、データベースオートメーションはトリガーとアクションで構成され、ページ追加、プロパティ編集、定期実行などを起点にできると説明されています。また、アクセスが制限されているページではアクションを実行しないことや、既存のオートメーションがエラーになると一時停止する場合があることも説明されています。

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

Notionオートメーションは、判断をなくす機能ではなく、定型処理を自動化し、人が確認すべき状態をDB上に作る機能です。

この記事では、Notionオートメーションの使い方を、向く業務、トリガーとアクション、DB更新、通知とSlack、Webhook連携、権限と失敗時の確認、人が確認するポイントまで整理します。

Notionインテグレーションの基本はこちら
Notion通知設定の基本はこちら

先に結論：自動化は受付・通知・初期分類までに絞る

Notionオートメーションは、最初から複雑にしない方が安定します。

まず自動化するのは、次の範囲です。

自動化する処理	例
受付	新規問い合わせを未確認にする
初期分類	種別に応じて担当チームを入れる
通知	新規受付、確認待ち、期限超過を通知する
期限設定	受付日から初回返信期限を設定する
ログ作成	Webhook送信結果や確認待ちを記録する
確認ビューへの移動	確認待ち、期限切れ、要レビューを見えるようにする

逆に、最初から自動化しない方がよいものもあります。

自動化しすぎない処理	理由
承認可否	判断責任が残る
顧客への正式返信	文脈、契約条件、表現確認が必要
金額、契約、労務の確定	監査や原本管理が必要
例外対応	条件分岐が増え、誤作動しやすい
外部DBとの双方向同期	競合、重複、削除反映が難しい

Notionオートメーションは、業務を完全自動化するためではなく、見落としを減らし、次に人が見るべき状態を作るために使います。

自動化で向く業務

Notionオートメーションに向いているのは、条件が明確で、失敗時に戻しやすい処理です。

業務	向いている自動化
問い合わせ管理	新規追加時にSlack通知、ステータスを未確認に設定
社内申請	申請種別に応じて承認者を設定
タスク管理	ステータス変更時に確認者へ通知
期限管理	期限超過ビューに集め、担当者へ通知
マニュアル改善	フォーム回答を改善要望DBに追加
FAQ運用	解決済み問い合わせをFAQ候補にする
外部連携	条件に合うページのプロパティをWebhookで送る

業務DBには、最低限次のプロパティを持たせます。

プロパティ	型	自動化での役割
ステータス	ステータス	未確認、対応中、確認待ち、完了を分ける
種別	セレクト	通知先や担当者の分岐に使う
担当者	ユーザー	誰に通知するかを決める
確認者	ユーザー	承認やレビューの通知先
期限	日付	期限超過ビュー、リマインドに使う
通知要否	チェックボックス	下書きや軽微更新を除外する
最終通知日	日付	重複通知を抑える
最終確認日	日付	棚卸しやレビューに使う
外部連携ID	テキスト	Webhookや外部システムとの重複防止

プロパティが整理されていないDBに自動化を足すと、後で壊れます。

先にDBの状態、担当、期限、通知対象を決めます。

Notionフォームの作り方はこちら

トリガーとアクション

Notionオートメーションは、トリガーとアクションに分けて考えます。

トリガーは「何が起きたら動くか」です。

アクションは「何をするか」です。

公式ヘルプでは、トリガーとしてページ追加、プロパティ編集、定期実行が説明されています。また、アクションとしてプロパティ編集、ページ追加、ページ編集、通知送信、メール送信、Webhook送信、Slack通知、変数定義などが説明されています。

実務では、次の表で整理します。

トリガー	使いどころ	注意点
ページが追加された	フォーム回答、問い合わせ、申請の受付	重複登録やテスト送信を除外する
プロパティが編集された	ステータス変更、担当者設定、種別変更	何でも編集で発火させない
特定の値に変わった	確認待ち、完了、差し戻しなど	値の定義をチームで揃える
定期実行	週次棚卸し、期限超過確認	リアルタイム処理と混ぜない

アクション	使いどころ	注意点
プロパティ編集	ステータス、担当者、期限の初期設定	人の入力を上書きしない
ページ追加	タスク、通知ログ、FAQ候補を作る	どのDBに追加するか限定する
ページ編集	関連DBの状態更新	権限と対象ページを確認する
通知送信	Notion内で担当者へ知らせる	通知だけで管理しない
Slack通知	チームに即時共有する	チャンネルを増やしすぎない
メール送信	外部相手や管理者へ知らせる	文面と送信元の責任を決める
Webhook送信	外部APIや自動化基盤へ渡す	送る情報、認証、失敗時対応を決める

「プロパティが編集されたら何でも通知」は避けます。

通知が増えすぎ、重要な変更が埋もれるからです。

条件は、業務上意味のある状態変化に絞ります。

DB更新の例

問い合わせDBを例にします。

プロパティ	型	値の例
件名	タイトル	見積相談、サポート依頼
種別	セレクト	相談、資料請求、サポート、その他
ステータス	ステータス	未確認、対応中、確認待ち、完了
担当者	ユーザー	営業、サポート、管理者
初回返信期限	日付	受付日の翌営業日
優先度	セレクト	高、中、低
通知済み	チェックボックス	初回通知済みか
最終確認日	日付	管理者が見た日

最初に作る自動化は、次の程度で十分です。

自動化名	トリガー	アクション
新規問い合わせ受付	ページが追加された	ステータスを未確認にする
種別別担当設定	種別が相談になった	営業担当を担当者に入れる
初回通知	新規ページ追加、通知済みが未チェック	Slackへ通知し、通知済みをチェック
確認待ち通知	ステータスが確認待ちになった	確認者にNotion通知
期限超過確認	毎日朝	期限超過ビューを管理者が確認

この設計で重要なのは、完了まで自動化しないことです。

問い合わせ内容の判断、返信方針、見積可否、契約条件は人が確認します。

Notionオートメーションは、見落としを防ぎ、担当者と確認者へ渡すところまでです。

通知とSlack

通知は、Notion内通知とSlack通知を分けます。

通知先	向いている用途
Notion通知	個人の確認依頼、担当者へのレビュー依頼
Slack通知	チーム全体で拾う新規受付、期限超過、障害
ビュー	日次で見る未対応、担当未設定、確認待ち
メール	外部相手への受付連絡、責任者への重要通知

Slack通知は便利ですが、増やしすぎると読まれません。

Slackに出すのは、次のようなものに絞ります。

Slackに出す	Slackに出さない
新規問い合わせ	軽微なページ編集
期限超過	下書き作成
障害、Webhook失敗	参考資料の追加
承認待ちの滞留	通常のコメント返信

Notion公式ヘルプでは、Slack通知アクションは指定したSlackチャンネルへ通知できると説明されています。

ただし、通知を受けた後の正式な状態管理はDB側に残します。

Slackで「見ました」と反応しても、Notionのステータスが変わらなければ業務上は進んでいません。

Notion Slack通知の作り方はこちら

Webhook連携

Webhookは、Notionの自動化から外部処理へ渡すために使います。

Notion公式のWebhookアクションヘルプでは、ボタン、データベースボタン、データベースオートメーションの Send webhook アクションから、特定URLへHTTP POSTリクエストを送れると説明されています。

Notion公式ヘルプ：Webhook actions

使いどころは、次のような処理です。

使い方	例
外部APIへ通知	問い合わせを自社APIへ渡す
ノーコード基盤へ渡す	Make、Zapierで後続処理を動かす
通知ログを作る	外部側で送信履歴や失敗を記録する
生成AI処理へ渡す	問い合わせ分類や要約の下書きを作る
専用システムへ作成	サポートチケットやタスクを作成する

ただし、Webhookは万能ではありません。

公式ヘルプでは、Webhookアクションには次の制約が説明されています。

制約	実務での意味
POSTのみ	取得、更新、削除を直接使い分ける設計ではない
ワークスペース全体のWebhookではない	DBやボタンの自動化から送る前提
送れるのはDBページのプロパティ	ページ本文をそのまま送る設計にしない
オートメーションごとに最大数がある	1つの自動化に外部送信を詰め込まない
失敗時は一時停止が必要になる	エラー監視と復旧手順が必要

Webhookを使うなら、最低限次を決めます。

項目	決めること
送信条件	どのステータス、どの種別で送るか
送信プロパティ	外部へ渡してよい項目だけに絞る
認証	受信側でどう検証するか
再実行	失敗時に誰がどう再送するか
ログ	送信日時、結果、エラー内容を残す
停止方法	誤送信、障害、契約終了時に止める方法

Webhookで個人情報や契約情報を外へ送る場合は、特に注意します。

Notionにあるから送ってよいわけではありません。外部サービス側の権限、保存場所、ログ、削除手順まで確認します。

権限と失敗時の確認

Notionオートメーションは、権限がなければ期待通りに動きません。

公式ヘルプでは、アクセスが制限されているページではオートメーションがアクションを実行しないこと、ページやDBを追加・編集する場合は必要な権限を確認することが説明されています。

実務では、次を確認します。

確認項目	見ること
作成者	誰がオートメーションを作ったか
編集権限	誰が変更、停止、削除できるか
対象DB	どのDBに対して動くか
対象ビュー	全体か、フィルター済みビューか
通知先	通知先がページやDBを見られるか
外部接続	Slack、Gmail、Webhookなどが有効か
失敗通知	エラー時に誰が気づくか

壊れやすいのは、次のケースです。

失敗例	原因
通知が飛ばない	通知先、Slack接続、権限が変わった
ステータスが変わらない	対象プロパティ名や値が変わった
Webhookが止まる	URL変更、受信側エラー、認証不備
期限処理がずれる	日付プロパティが空欄、タイムゾーン、条件ミス
重複通知が出る	通知済みフラグや最終通知日がない
誰も直せない	作成者や管理者が不明

公式ヘルプでは、以前機能していたオートメーションにエラーが起きると一時停止する場合があり、修正後に手動でアクティブに戻す必要があると説明されています。

つまり、オートメーションは作ったら終わりではありません。

管理者は、月次で次のビューを見ます。

ビュー	目的
自動化一覧	どのDBにどの自動化があるか
期限超過	通知だけで拾えていないものを見る
通知済み未対応	通知後に止まっているものを見る
Webhookエラー	外部送信に失敗したものを見る
最終確認日が古い	使われていない自動化を棚卸しする

人が確認するポイント

Notionオートメーションで最も重要なのは、人の確認点を残すことです。

自動化してよい	人が確認する
ステータスを未確認にする	どの対応方針にするか
担当候補を設定する	本当にその担当でよいか
確認者へ通知する	承認するか、差し戻すか
要約や分類の下書きを作る	正式な分類、返信文、判断
Webhookで外部処理へ送る	送信結果、例外、再実行可否
期限超過を通知する	優先順位と対応順

AIを組み合わせる場合も同じです。

問い合わせの要約、分類候補、FAQ下書き、議事録からのタスク抽出は使えます。

ただし、正式な顧客返信、承認、契約条件、個人情報の判断は人が確認します。

Notionオートメーションは、業務の責任を消すものではありません。

責任者、確認者、停止手順、エラー時の復旧方法をDBに残し、定型処理だけを任せるのが安全です。

最後に、最初の1週間で見るべきチェックリストを置いておきます。

チェック	見ること
通知量	SlackやNotion通知が多すぎないか
見落とし	通知されない重要状態がないか
誤作動	意図しないステータス変更がないか
権限	通知先やアクション対象が見えるか
エラー	一時停止、Webhook失敗、外部接続切れがないか
人の確認	承認や返信が自動化されすぎていないか

Notionオートメーションは、小さく作り、ビューで監視し、月次で棚卸しする。

この運用にしておけば、便利さと安全性を両立しやすくなります。