Notion Automationの基本｜自動化の作り方・ボタン・Webhookを徹底解説

Notionでタスクや顧客、問い合わせ、記事制作などを管理していると、担当者の設定、状態の変更、確認依頼の通知、定期タスクの作成といった同じ操作を何度も繰り返すことになります。件数が少ない間は手動でも対応できますが、利用者やデータが増えると、更新漏れや入力のばらつきが発生しやすくなります。担当者を設定し忘れたタスクが放置されたり、承認済みの資料が次の工程へ進まなかったりする問題も起こります。

Notion Automationは、データベースで特定の変化が発生したときに、あらかじめ設定した処理を実行する機能です。例えば、新しい問い合わせが登録されたら受付担当者を設定する、タスクがレビュー待ちになったら責任者へ通知する、承認ボタンが押されたら状態と承認日を更新する、といった処理をNotion内で構築できます。公式ヘルプでは、データベース自動化を、特定の変更をきっかけに一連のアクションを実行する仕組みとして説明しています。

ただし、すべての手動操作を自動化すればよいわけではありません。判断が必要な業務まで自動化すると、誤った担当者設定や不要な通知が大量に発生する可能性があります。本記事では、データベース自動化、ページボタン、データベースボタン、繰り返しテンプレート、Webhookの違いから、設定手順、実務例、権限、制限、エラー対処までを段階的に解説します。

1. Notion Automationとは

Notion Automationとは、Notion上のデータや利用者の操作をきっかけに、ページの作成、プロパティの更新、通知、外部サービスへの送信などを実行する仕組みの総称です。利用者が何も操作しなくても条件に応じて動く自動化と、利用者がボタンを押したときに動く半自動化を使い分けます。

1.1 トリガーとアクションで構成される

Notionのデータベース自動化は、処理を開始する条件である「トリガー」と、条件が満たされた後に実行する「アクション」で構成されます。例えば、「状態がレビュー待ちへ変更された」がトリガーであり、「レビュー担当者を設定し、通知を送る」がアクションです。Notion公式も、データベース自動化を、開始条件となるトリガーと、その結果として実行されるアクションの組み合わせとして説明しています。

自動化を設計するときは、最初にアクションを考えるのではなく、「どの変化を業務上の合図とするか」を決めます。単にページが編集されたことを合図にすると、タイトルの修正や説明文の追記でも処理が動く可能性があります。「状態が承認済みになった」「担当者が空欄から設定された」など、業務上の意味が明確な変化をトリガーにする方が安全です。

1.2 手動処理を完全になくす機能ではない

自動化は、定型的な操作を減らすための機能であり、人の判断を完全に置き換えるものではありません。担当者の割り当て規則が明確な場合は自動化できますが、案件の専門性、担当者の負荷、顧客との関係を確認して割り当てる場合は、人が判断してからボタンを押す方法が適しています。

自動化する対象は、頻度が高い、判断基準が一定である、入力漏れが起こりやすい、失敗しても容易に修正できるという条件を満たす処理から選びます。発生頻度が低く、失敗時の影響が大きい契約承認や請求確定などは、完全な自動処理ではなく、確認画面付きのボタンを利用する方が安全です。

1.3 Notionで利用できる自動化の種類

Notionでは、データベースの変更を検知して自動実行するデータベース自動化、ページ上で利用者が押すページボタン、各データベース項目に表示するデータベースボタン、定期的にページを作成する繰り返しテンプレート、外部サービスへHTTPリクエストを送るWebhookなどを利用できます。これらは似ていますが、処理が始まる条件と利用目的が異なります。

初心者は、最初にページボタンまたはデータベースボタンを使い、利用者が意図的に実行する仕組みから始めると安全です。その後、同じ処理が繰り返し実行されており、条件も安定していることを確認してからデータベース自動化へ移します。

2. 自動化を作る前に業務を整理する

Notionの自動化画面を開く前に、現在の業務フローを文章または簡単な図で整理します。どの項目が入力され、誰が判断し、どの状態へ変わり、次に誰が作業するのかが曖昧なままでは、自動化の条件も曖昧になります。

2.1 自動化する目的を明確にする

自動化の目的は、「便利そうだから」ではなく、「担当者の設定漏れをなくす」「問い合わせ受付から初回対応までの時間を短縮する」「週報ページの作成忘れを防ぐ」のように具体化します。目的が明確であれば、自動化が成功したかどうかを、漏れ件数、処理時間、手動操作数などで確認できます。

一つの自動化へ複数の目的を持たせないことも重要です。例えば、新しい案件が登録されたときに、担当者設定、顧客ページ作成、Slack通知、電子メール送信、タスク生成を同時に行うと、どこで失敗したのか分かりにくくなります。最初は担当者設定だけを自動化し、安定した後に処理を追加します。

2.2 データベースの項目と状態を統一する

自動化は、データベースのプロパティ値を条件として動くため、入力ルールが統一されている必要があります。「確認中」「レビュー中」「確認待ち」が同じ意味で使われていると、どの値をトリガーにすべきか決められません。まず状態名を整理し、各状態へ移る条件と責任者を定義します。

自由入力の文章を条件として利用するより、選択、状態、人物、チェックボックスなど、値が限定されたプロパティを使用する方が安定します。電話番号や顧客名のように自由入力が必要な情報と、自動化の判断に使う分類情報を分けることで、誤作動を減らせます。

2.3 本番とは別の検証用データを用意する

自動化を作成したら、実際の顧客や重要なプロジェクトではなく、検証用のページで動作を確認します。「テスト顧客」「テストタスク」のような項目を用意し、通常、例外、空欄、誤入力の複数パターンを試します。正常な値だけで確認すると、実際の運用で空欄や想定外の値が入力されたときに問題が発生します。

通知や電子メールを送る自動化では、最初は作成者本人またはテスト用チャンネルだけを送信先に設定します。顧客やチーム全体へ通知する設定を最初から使用すると、検証中のメッセージが送られる可能性があります。動作確認後に本番の送信先へ変更します。

3. データベース自動化の基本

データベース自動化は、データベース内で特定の変更が発生したとき、または設定した周期になったときに処理を実行する機能です。Notionでは、データベース上部の稲妻アイコンから新しい自動化を作成し、トリガーとアクションを設定します。

3.1 データベース自動化を作成する

対象データベースの上部にある自動化メニューを開き、新しい自動化を選択します。次に、後から内容を理解できる名前を付け、トリガーとアクションを設定します。「自動化1」のような名称ではなく、「レビュー待ちになったら担当者へ通知」「新規問い合わせへ受付担当を設定」のように、条件と結果が分かる名前を付けます。

自動化には複数のアクションを追加できますが、最初は一つまたは二つに抑えます。例えば、状態変更と通知を一つの自動化へ含めることは理解しやすい一方、複数データベースへのページ作成や外部Webhookまで含めると、問題発生時の調査が難しくなります。

3.2 3種類のトリガーを理解する

公式ヘルプでは、データベース自動化の主なトリガーとして、ページが追加されたとき、特定のプロパティが編集されたとき、一定の頻度で実行する場合が案内されています。プロパティ編集では、項目の種類に応じて「特定の値に設定された」「特定の文字を含む」など、より具体的な条件を選択できます。

「ページが追加されたとき」は、問い合わせ受付や新規案件の初期設定に向いています。「プロパティが編集されたとき」は、状態変更や担当者設定を基準にした処理へ利用します。「一定の頻度」は、毎週の通知や定期処理に使えますが、どのページを対象とするかを慎重に設計する必要があります。

3.3 複数条件の扱いに注意する

自動化には複数のトリガーを設定し、いずれかが発生した場合、またはすべてが発生した場合に実行するよう指定できます。ただし、複数の編集トリガーを「すべて発生した場合」として設定すると、それらの編集が約3秒以内の短い時間に行われなければ、期待どおりに動かない可能性があります。公式ヘルプでは、この場合に自動化を分けるか、より具体的なトリガーを使う方法が案内されています。

例えば、「状態が承認済みで、担当者が設定されたとき」という条件を、二つの編集トリガーで表現すると不安定になる場合があります。状態が承認済みへ変更されたことだけをトリガーにし、運用上、承認前に担当者を必須とする方が単純です。複雑な条件を自動化側だけで解決せず、入力ルールやデータ構造も改善します。

4. アクションの種類と使い方

アクションは、トリガーが成立した後にNotionが実行する処理です。プロパティの編集、ページの追加、別データベースのページ更新、通知、電子メール、Slack、Webhookなどを組み合わせられます。利用できる内容や条件はプランと権限によって異なります。

4.1 プロパティ編集とページ作成

代表的なアクションは、対象ページのプロパティを変更する処理です。新規問い合わせの状態を「未対応」にする、担当者を受付チームに設定する、完了時に完了日を記録するといった初期設定や更新へ利用できます。別のデータベースへページを追加したり、既存ページを編集したりする処理も設定できます。

ただし、自動化がページを編集するためには、対象ページとデータベースへの適切なアクセス権が必要です。非公開または制限されたページを編集しようとすると処理が失敗する可能性があります。自動化作成者だけでなく、対象となるデータベースの共有状態も確認します。

4.2 Notion・Slack・Gmailへ通知する

Notion内の特定利用者へ通知を送り、ページへの確認や対応を依頼できます。Slack連携を設定している場合は、指定したチャンネルへメッセージを送る自動化も利用できます。例えば、重大な障害が登録されたら運用チャンネルへ通知し、高額案件が受注済みになったら営業管理チャンネルへ知らせる運用が考えられます。

ボタンでは、接続したGmailアカウントから電子メールを送るアクションも利用できます。この機能は有料プラン向けであり、接続したGmailアカウントを持つ本人だけがボタンを編集できます。メールの到着に最大約2分かかる場合や、Gmail側の送信数・宛先数制限を受ける点にも注意が必要です。

4.3 変数・メンション・数式を利用する

ボタンや自動化のメッセージには、固定文だけでなく、ページ名、担当者、日付などの値を埋め込めます。ボタンでは変数を定義し、数式やメンションを使って、後続のアクションから参照することもできます。例えば、ボタンを押した人の名前、現在日、対象ページのタイトルを組み合わせて通知文を作成できます。

動的な値を使い過ぎると、送信内容を事前に予測しにくくなります。最初は「資料『ページ名』がレビュー待ちになりました」のような単純なメッセージから始めます。数式を追加した場合は、空欄、長いタイトル、複数担当者などの条件でも読みやすい文章になるかを確認します。

5. ページボタンとデータベースボタン

ボタンは、利用者がクリックしたときに一つまたは複数の処理を実行します。完全な自動化とは異なり、人が内容を確認してから実行できるため、承認、申請、完了処理、定型ページの作成などに向いています。

5.1 ページボタンの特徴

ページボタンは、Notionページ内でスラッシュメニューから追加します。ボタンには名称と絵文字を設定し、ブロックの挿入、データベースへのページ追加、既存ページの編集、通知、メール、Webhook、ページまたはURLを開く処理などを設定できます。ボタン自体はすべてのプランで利用できますが、一部のアクションは有料プランに限定されます。

例えば、会議ページに「新しい議題を追加」ボタンを置き、定型の見出しとチェック項目を挿入できます。プロジェクトダッシュボードに「新規タスク」ボタンを置き、担当チームや関連プロジェクトを初期設定したタスクを作成することも可能です。

5.2 データベースボタンの特徴

データベースボタンは、データベースの各行へ表示するボタン型プロパティです。「承認」「完了」「再依頼」「請求書作成」など、各項目に対して実行する操作を一つの列として配置できます。ボタンを押すと、対象行の状態変更、別ページの作成、通知などを行えます。

状態プロパティを利用者が直接変更するより、専用ボタンを使う方が安全な場合があります。「承認」ボタンを押すと、状態を承認済みにし、承認日と承認者を記録し、申請者へ通知するという複数処理を一度に実行できます。必要な情報を同時に更新できるため、記録漏れを減らせます。

5.3 確認画面と権限を設定する

重要なボタンには確認画面を設定し、誤クリックを防ぎます。Notionのボタンアクションには、実行前に小さな確認画面を表示する機能があります。請求確定、顧客へのメール送信、完了済みデータの作成など、取り消しに手間がかかる処理へ利用すると安全です。

ページボタンを作成・編集・クリックするには、基本的にページへの編集権限が必要です。別のデータベースへページを追加または編集する場合、ボタンを押す利用者にも対象データベースの編集権限が必要になります。データベースボタンは、内容のみ編集できる権限の利用者でもクリックできますが、作成や編集にはより強い権限が必要です。

6. 繰り返しテンプレートと定期実行

毎日、毎週、毎月発生するタスクや会議ページは、繰り返しテンプレートまたは定期トリガーを利用して作成できます。両者は似ていますが、定型ページを作成するのか、指定周期で複数の処理を実行するのかという違いがあります。

6.1 繰り返しデータベーステンプレート

データベーステンプレートには、ページ本文とプロパティの初期値を登録できます。繰り返し設定を有効にすると、日次、週次、月次、年次などの周期でテンプレートの複製が自動作成されます。週次レポート、月次請求確認、定例会議、定期点検など、同じ構成のページを繰り返し作る用途に適しています。

テンプレートへ担当者や分類を初期設定できますが、リレーションを固定すると、すべての複製が同じ既存ページへ関連付けられます。毎回異なるプロジェクトを選ぶ必要がある場合は、リレーションを空欄にしておき、作成後に入力します。

6.2 指定した頻度の自動化トリガー

データベース自動化には、毎日、毎週、毎月などの周期で実行するトリガーがあります。開始日、終了日、時刻、タイムゾーンも指定できます。定期的に通知を送る、別データベースへ集計用ページを作るなど、ページ複製以外の処理も必要な場合に利用します。

定期トリガーは、別の種類のトリガーと同じ自動化へ組み合わせることができません。また、定期トリガーでは「プロパティを編集する」アクションを利用できないという制限もあります。設定前に、目的とする処理が定期トリガーに対応しているかを確認します。

6.3 どちらを使うべきか判断する

同じページ構成を定期的に生成するだけなら、繰り返しテンプレートの方が簡単です。毎週の会議議事録、毎月の経費確認、毎日の習慣ページなどは、テンプレートに必要な本文と初期値を登録し、周期を設定します。

複数データベースへのページ作成、通知、Webhookなど、ページ作成以外の処理を定期的に行いたい場合はデータベース自動化を検討します。ただし、繰り返しテンプレートによって作成されたページは、別のデータベース自動化を起動しません。後続処理が必要な場合は、利用者がボタンを押す設計や、外部連携を含む別の方法を検討します。

7. 実務で使える自動化の例

Notion Automationは、業務の種類を問わず利用できますが、最初は結果が分かりやすく、失敗しても容易に修正できる処理から導入します。以下では、タスク管理、承認、問い合わせ、定例業務の代表例を紹介します。

7.1 タスクの担当者と状態を設定する

新しいタスクが追加されたら、分類に応じて担当チームを設定し、状態を未着手にする自動化を作れます。例えば、分類が「デザイン」のタスクにはデザインチーム、分類が「記事」のタスクには編集担当者を設定します。ただし、担当者の負荷を考慮せず個人へ直接割り当てると、特定の人へ作業が集中する可能性があります。

安全な方法は、最初に担当チームまたは受付担当者だけを自動設定し、個人への割り当ては担当者が確認して行うことです。業務量と専門性を考慮する必要がない単純な定例タスクのみ、個人へ自動割り当てします。

7.2 承認フローをボタンで作る

申請データベースへ「承認」と「差し戻し」のデータベースボタンを追加します。「承認」ボタンは、状態を承認済みに変更し、承認日と承認者を記録し、申請者へ通知します。「差し戻し」ボタンは状態を修正依頼に変更し、申請者へ再確認を依頼します。

承認者が内容を読まずに状態だけ変更することを防ぐため、確認画面を表示します。また、承認者だけがボタンを押せるよう、共有範囲やビューを設計します。Notionの権限だけで完全な職務分離を表現できない場合は、重要な法的承認や支払い承認を専用システムで行い、Notionは進捗表示に限定します。

7.3 問い合わせと定例業務を処理する

問い合わせフォームから新しい項目が追加されたら、受付日時、初期状態、担当チームを設定し、対応チャンネルへ通知します。問い合わせ種別が契約、技術、請求などに分かれている場合は、分類に応じて担当チームを変えます。ただし、顧客へ自動返信する前に、送信内容と個人情報の扱いを十分に確認します。

週次レポートや定例会議には繰り返しテンプレートを利用します。毎週月曜日に新しい週報ページを作り、本文へ先週の成果、今週の予定、課題、支援依頼の見出しを用意します。担当者は白紙から作成する必要がなくなり、チーム全体で記載形式も統一できます。

8. Webhookで外部サービスと連携する

Webhookアクションを使うと、Notionのボタン、データベースボタン、データベース自動化から、指定したURLへHTTP POSTリクエストを送信できます。ZapierやMakeなどの自動化サービス、自社の受付システム、通知サービスなどへ処理を渡す入口として利用できます。

8.1 Webhookアクションの仕組み

Webhookアクションでは、送信先URLを入力し、必要に応じて独自のヘッダーを設定します。データベース自動化から送信する場合は、ページのプロパティを送信内容として選択できます。Notion側から外部サービスへ処理開始の合図と必要な情報を渡し、外部側でメッセージ送信、データ変換、別システムへの登録などを行います。

例えば、記事の状態が公開承認済みになったら、Webhookで外部の投稿処理へタイトル、公開日、URLを送る構成が考えられます。ただし、Webhook送信だけで公開が成功したとは限りません。外部側の処理結果をNotionへ戻す仕組みが必要な場合は、Notion APIや別の連携方法も検討します。

8.2 Zapier・Make・自社システムと接続する

WebhookをZapierやMakeで受信すれば、Notionから送られた情報を基に、電子メール、チャット、表計算、顧客管理などの別サービスへ処理をつなげられます。Notion公式も、Webhookアクションをローコード・ノーコードの自動化サービスや社内アプリケーションのワークフロー開始に利用できると説明しています。

外部サービスへ接続すると、Notionだけを確認しても処理全体の状態が分からなくなります。自動化名、送信先、管理者、外部側の処理内容を運用ページへ記録します。担当者が退職した後も接続先と認証情報を管理できるよう、個人アカウントへの依存を避けます。

8.3 Webhookの制限と安全性を理解する

NotionのWebhookアクションは有料プラン向けで、POSTリクエストのみをサポートします。一つの自動化に設定できるWebhookアクションは最大5件であり、送信できるのはデータベースページのプロパティで、ページ本文は送信できません。また、Notion上で送信ペイロードを事前表示する機能はありません。

Webhookアクション自体は認証を必須としていないため、推測されにくいURLを利用し、可能であれば独自ヘッダーや受信側の検証を設定します。個人情報、契約情報、秘密情報を必要以上に送信しません。Webhookが失敗すると自動化が一時停止され、手動で再開する必要があるため、外部サービスの障害も含めて定期的に状態を確認します。

9. プラン・権限・制限とエラー対処

Notion Automationが動かない原因は、条件の設定ミスだけではありません。利用プラン、データベースの権限、ページの共有状態、ロック、ビューの絞り込み、自動化同士の連鎖制限なども確認する必要があります。

9.1 利用できるプランを確認する

データベース自動化は、原則として有料プランで利用できます。有料プランでデータベースへのフルアクセス権を持つ利用者は、自動化の作成、編集、削除が可能です。無料プランではSlack通知の自動化を作成できますが、それ以外の種類の自動化は作成できません。無料プランの利用者は、テンプレートに含まれる既存自動化を使用できても編集できません。

ページボタンとデータベースボタンはすべてのプランで利用できますが、Gmail、Webhook、一部のSlackアクションなどは有料プランが必要です。NotionにはFree、Plus、Business、Enterpriseの区分がありますが、利用可能なプランはワークスペースによって異なる場合があります。契約時点の管理画面と公式料金を確認します。

9.2 アクセス権とページ状態を確認する

自動化がページやデータベースを追加・編集するには、対象への編集権限が必要です。非公開ページ、制限されたページ、共有範囲外のデータベースへ処理を行おうとすると、自動化が実行されない可能性があります。対象データベースだけでなく、関連先や作成先の共有状態も確認します。

データベースがロックされている場合や、処理後にページが対象ビューの絞り込み条件から外れる場合も、想定どおりに動かないことがあります。自動化がビューに関連付けられている場合は、トリガーの瞬間にページがそのビューへ残っているかを確認します。

9.3 自動化同士は連鎖しない

Notionのデータベース自動化による変更は、別のデータベース自動化を起動しません。自動化Aが別データベースへページを作成しても、そのページ追加を条件とする自動化Bは実行されません。繰り返しテンプレートで作成されたページも、データベース自動化を起動しません。一方、利用者がボタンを押してページを作成した場合は、データベース自動化を起動できます。

この制限を知らずに、状態変更、通知、別ページ作成を複数の自動化へ分割すると、途中から動かなくなる場合があります。連続して必ず行う処理は一つの自動化またはボタン内の複数アクションとして構成します。複雑な分岐や連鎖が必要な場合は、Webhook、Notion API、外部自動化サービスの利用を検討します。

10. Notion Automationを段階的に導入する

自動化を長期間活用するには、作成数を増やすより、誰でも仕組みを理解し、問題発生時に修正できる状態を維持することが重要です。小さな処理から始め、結果を確認しながら範囲を広げます。

10.1 最初は一つの定型処理から始める

最初の自動化には、「新しいタスクへ初期状態を設定する」「レビュー待ちになったら責任者へ通知する」など、処理前後の違いが分かりやすいものを選びます。新規ページの作成、複数データベースの更新、外部送信を同時に行う処理は避けます。

一週間から二週間運用し、誤作動、実行漏れ、不要な通知がないことを確認します。問題がなければ、担当者設定や完了日の記録など、関連するアクションを一つずつ追加します。自動化による削減時間だけでなく、修正や確認に必要な時間も評価します。

10.2 命名・管理者・記録を統一する

自動化名には、対象、条件、処理を含めます。「タスク｜レビュー待ち｜責任者へ通知」のような命名規則を使うと、件数が増えても内容を判別しやすくなります。SlackやGmailなど、作成者だけが編集できる設定については、管理者が誰かを運用ページへ記録します。

各自動化について、目的、対象データベース、トリガー、アクション、管理者、作成日、最終確認日を一覧にします。業務を廃止した後も自動化だけが残ると、不要な通知やページ作成が続く可能性があります。四半期ごとに一覧を確認し、利用されていない処理を停止または削除します。

10.3 自動化の効果を定期的に見直す

自動化導入後は、処理件数、エラー件数、手動修正件数、不要な通知数を確認します。多く実行されているから効果が高いとは限りません。利用者が自動化の結果を毎回修正している場合は、条件や入力項目が業務の現実と合っていない可能性があります。

業務フローが変わったときは、自動化も更新します。状態名の変更、担当チームの再編、データベースの統合を行った場合、古い条件や宛先が残っていないかを確認します。Notion Automationは一度作って終わる機能ではなく、業務ルールをNotion上へ反映した仕組みであるため、業務と同じように保守する必要があります。

おわりに

Notion Automationとは、データベースの追加や変更、指定した周期、利用者のボタン操作などをきっかけに、プロパティ更新、ページ作成、通知、外部送信などを実行する仕組みです。自動的に動くデータベース自動化だけでなく、ページボタン、データベースボタン、繰り返しテンプレート、Webhookも業務効率化に利用できます。

初心者は、最初から複雑な完全自動化を作らず、利用者が確認して押すボタンから始める方法が安全です。処理内容と判断基準が安定した後で、状態変更や新規ページ追加をトリガーとするデータベース自動化へ移行します。定期ページには繰り返しテンプレート、外部サービスとの接続にはWebhookというように、目的に合った機能を選ぶことが重要です。

Notion Automationの価値は、多数の自動化を作ることではなく、更新漏れを減らし、利用者が判断や創造的な仕事へ集中できる状態を作ることにあります。業務ルールを整理し、小さく導入し、結果を検証し、不要な処理を削除しながら、誰でも理解できる単純な仕組みを維持してください。