Notion自動化の落とし穴｜小規模運用5つの注意点

Notion自動化の落とし穴

Notionのデータベースを使い始めると、「入力後の通知や担当変更も自動化したい」と考える場面が増えます。小規模な運用では、最初から大きな仕組みを作るより、1つのトリガーと1つのアクションから始めるほうが状況を把握しやすくなります。

ただし、仕組みが小さくても、連鎖できない処理、Webhookの上限、送信できない情報、失敗後の再開方法を知らないまま組むと、「設定は合っているように見えるのに動かない」という状態が起こります。この記事では、Notion公式ヘルプで確認できる5つの事実だけを土台に、小規模チームが設計前に決めておきたい確認点を整理します。

自動化連鎖の壁｜トリガーとアクションを一枚にする

Notionのデータベースオートメーションは、データベースの特定の変更をきっかけに動く処理で、トリガーとアクションから構成されます。まず「何が起きたら」「何をするか」を一文で書ける状態にすると、設定画面の項目と業務上の目的を対応させやすくなります。

たとえば、問い合わせ管理なら「ステータスが対応待ちになったら担当者へ通知する」、記事管理なら「確認状態になったら編集担当を設定する」という形です。ここで大切なのは、2つ目、3つ目の処理まで勢いでつなげず、最初の処理が完了したと判断する条件を先に置くことです。

自動化が動かなかったとき、起点・処理・完了確認が混ざっていると原因を切り分けられません。1つの自動化につき、誰が見ても同じ判定になる完了条件を置くと、手動対応へ戻す場合にも迷いにくくなります。

別の自動化は起動不可｜連鎖前提を外す

データベースオートメーションを、別のデータベースオートメーションから直接トリガーすることはできません。つまり「自動化Aが変更した値を見て、自動化Bが続けて動く」という連鎖を前提にすると、設計どおりの流れにならない可能性があります。

小規模運用では、連鎖を増やす代わりに、1つの自動化へ必要な処理をまとめられるかを最初に確認します。まとめられない場合は、次の処理を人が確認して進める境界を設けるか、外部サービス側の処理として明確に分離します。

設計	確認すること	失敗時の戻し方
1つの自動化に集約	処理順と各アクションの必要性	最後のアクションから順に無効化
人の確認を挟む	確認担当と期限	未確認の項目を手動キューへ戻す
外部処理へ分離	送信項目と受信結果	送信停止後に未処理件数を照合

「すべて自動にする」ことよりも、「どこまで自動で、どこから人が確認するか」を明確にすることが重要です。運用担当が不在でも判断できるよう、Notion内の説明欄やチームの手順書へ境界を残しておきます。

Webhookは最大5件・POSTのみ｜送信設計を絞る

1つのオートメーションに設定できるWebhookアクションは最大5件で、リクエスト方式はPOSTのみです。送り先を追加するたびにWebhookを増やす設計は、上限へ近づくだけでなく、どの送信が成功し、どこで止まったかを追いにくくします。

最初は送信先を1つに絞り、受信側で処理を分ける必要が本当にあるかを検討します。送信先を複数にする場合は、各Webhookの役割を「通知」「記録」「後続処理」のように分け、同じ内容を重複送信しないようにします。

1. 送信先のURLと管理者を記録する
2. どのプロパティを送るかを一覧化する
3. 受信成功をどこで確認するかを決める
4. 失敗時に再送するか、手動処理へ切り替えるかを決める
5. 不要になったWebhookを削除する前に依存先を確認する

POSTのみという前提があるため、受信側には「同じ内容が届いた場合の扱い」も決めておきます。今回の復旧用canaryでは、曖昧な結果が出ても再送せず、認証済みの読み取りで結果を照合する方針にします。これは二重作成を避けるための運用上の決定です。

ページ本文は送れない｜プロパティを先に整える

Webhookアクションで送信できるのはデータベースページのプロパティで、ページ本文は送信できません。本文にだけ重要情報を書いている場合、その情報をWebhookの送り先で使うことはできません。

外部処理に必要な情報は、最初からデータベースのプロパティとして持たせます。タイトル、担当、状態、期限、外部処理用IDなど、送信先で必要になる項目を分けておくと、本文の書き方に左右されにくくなります。

一方、背景説明、議事録、長い手順、文章そのものは本文へ残します。何でもプロパティにすると入力負担が増えるため、「自動処理や検索に必要か」を基準に切り分けます。既存データを移すときは、一度に全件を書き換えず、少数で入力・送信・確認が成立するかを確かめます。

失敗後は自動停止｜手動再開の担当を決める

Webhookアクションが失敗するとオートメーションは自動的に一時停止し、再利用には手動での再開が必要です。失敗原因を直しても、自動化が停止したままなら新しい処理は再開しません。

そのため、運用開始前に「誰が停止を見つけるか」「何を確認して再開するか」「停止中の未処理をどう回収するか」を決めます。担当者が再開ボタンを押すだけでは、停止中に発生した対象が処理されたか分からないため、未処理件数の照合までを復旧手順へ含めます。

• 検知：自動化の停止表示と受信側の最終成功時刻を確認
• 原因確認：送信先、必須プロパティ、受信側の応答を確認
• 応急対応：必要な対象を手動キューへ退避
• 再開：少数のテスト対象で結果を確認してから通常運用へ戻す
• 回収：停止中の未処理・重複・取りこぼしを照合

自動化は「設定したら終わり」ではありません。停止を見つけ、原因を直し、再開し、取りこぼしを回収するところまでが運用です。再開担当を一人に固定できない場合は、確認項目と判断基準を短いチェックリストにして共有します。

小規模運用の確認表｜1本ずつ確かめる

Notion自動化を小さく始めるときは、機能の多さより、結果を確認できることを優先します。最後に、設計から復旧までの確認点をまとめます。

段階	確認項目
設計前	トリガー、アクション、完了条件を一文で説明できる
設定時	別automationの連鎖を前提にしていない
Webhook	最大5件、POSTのみ、送信先と役割を記録した
データ	外部送信に必要な情報をプロパティへ置いた
障害対応	停止検知、手動再開、未処理回収の担当を決めた

最初の1本で、入力、実行、受信、確認、停止時の戻し方まで通せれば、次の自動化にも同じ確認方法を使えます。反対に、確認方法がないまま本数だけ増やすと、失敗したときの影響範囲が見えません。

まずは1つのデータベース、1つのトリガー、必要最小限のアクションで試し、結果を記録してください。実行前の値、実行後の値、受信側の結果、確認した時刻を同じ形式で残すと、次回の比較がしやすくなります。担当を交代するときも、その記録を見れば正常な状態と異常な状態を区別できます。その記録が、次の自動化を安全に追加する判断材料になります。

参照したNotion公式情報

• Database automations
• Webhook actions