MakeとNotion連携の作り方｜ノーコード自動化を業務フローに組み込む

MakeとNotionを連携すると、いろいろな業務を自動化できます。

フォーム回答をNotion DBに追加する。

SlackやGmailの内容からタスクを作る。

CRMの商談更新をNotionの案件DBへ反映する。

Notionのステータス変更をきっかけに、外部サービスへ通知する。

Notion DBの内容を使って、レポートや作業依頼を作る。

こうした使い方は、実務でも便利です。

ただし、MakeとNotion連携で失敗する会社も多いです。

• 何のDBを正とするか決めないまま同期している
• NotionのすべてのプロパティをMakeで更新しようとしている
• 自動作成されたページの担当者、期限、確認者が空欄になる
• エラー時に止まったことへ誰も気づかない
• 再実行したら同じページが重複登録される
• 外部サービスのデータをNotionに転記しすぎて権限が広がる
• AI要約や分類をそのまま正式ステータスにしてしまう
• 作った本人しかMakeのシナリオを理解していない

こうなると、ノーコード自動化は便利なはずなのに、運用の不安要素になります。

MakeとNotion連携は、ノーコードで何でも自動化する話ではなく、Notion DBを業務台帳として設計し、定型処理だけをMakeへ任せ、人の確認が必要な更新を残す設計 として考えるべきです。

この記事では、MakeとNotionの連携を、トリガー、Notion API、DB追加・更新、Webhook、エラー処理、再実行、人の確認ポイントまで実務目線で整理します。

先に結論：定型処理はMake、判断はNotion DBで確認する

MakeとNotionを連携するときは、自動化する処理と人が見る処理を分けます。

役割	向いている場所	理由
外部サービスからの定型入力	Make	トリガーとアクションで処理できる
Notion DBへのページ追加	Make、Notion API	決まった項目を登録しやすい
担当者、状態、期限の管理	Notion DB	ビューとレビューで確認しやすい
承認、例外判断、内容確認	人、Notion DB	誤登録や誤判定を防ぐ
エラー通知、再実行判断	Make、Slack、Notion確認DB	止まった処理を見える化する
正式な顧客、請求、会計台帳	CRM、会計、kintoneなど	監査、権限、履歴が必要

Makeは、決まった処理をつなぐのに向いています。

Notionは、業務状態を見て判断する場所に向いています。

フォーム回答をNotionに入れるだけならMakeで十分です。

しかし、どの問い合わせを優先するか、誰が返信するか、内容を正式記録にしてよいかは、人が確認する必要があります。

Notionデータベースの作り方

Makeでできること

Make公式のNotion連携ページでは、Notionを外部トリガーから更新したり、プロジェクトページを作成したり、共有データベースを更新したり、CRMと連動したコンテンツカレンダーを作ったりできることが紹介されています。

Make公式：Notion Integration

同ページでは、Notion連携にトリガー、アクション、検索のモジュールがあり、ページ作成、データベース作成、ページコンテンツ追加、データソース項目作成などのアクション例も示されています。

実務でよく使うのは、次のような処理です。

Makeで行う処理	例
外部サービスをトリガーにする	フォーム回答、Gmail受信、Slack投稿、CRM更新
Notion DBにページを追加する	問い合わせ、タスク、議事録候補、改善要望
Notionページを更新する	ステータス、外部URL、処理日時、同期状態
Notion DBから条件に合う行を探す	顧客名、外部ID、メールアドレスで既存行を探す
外部サービスへ通知する	Slack通知、メール、Webhook、CRM更新

ただし、Makeでできるからといって、全部自動化する必要はありません。

自動化してよい	人が確認した方がよい
受付データの登録	顧客への正式返信
外部IDやURLの保存	ステータスの完了判定
担当候補の仮設定	優先度の最終判断
通知の送信	契約、請求、個人情報の扱い
重複候補の検出	レコード統合や削除

Makeは、手作業の入口を減らす道具です。

業務判断を消す道具ではありません。

Notion APIとの関係

MakeのNotion連携は、裏側ではNotionの接続やAPIの考え方に近いものです。

Notion公式APIドキュメントでは、Notion接続は外部ツールや自動化スクリプトとワークスペースをつなぎ、REST APIでページ、データベース、ユーザー、コメントなどを読み書きできると説明されています。

Notion公式API：Overview

ここで重要なのは、接続に渡す権限です。

Notion APIの接続は、何でも自由に読める前提ではありません。

ページやDBへの明示的なアクセス許可、読み書きできる内容、接続ごとの権限設計が必要です。

Makeを使う場合も同じです。

設計項目	決めること
接続先ワークスペース	どのNotionワークスペースにつなぐか
対象DB	どのDBを読み書きするか
更新するプロパティ	Makeが自動更新してよい項目はどれか
参照するプロパティ	検索や重複判定に使う項目はどれか
権限管理者	接続アカウントやトークンを誰が管理するか
保守責任	エラー時に誰が見るか

特に、Makeの接続アカウントを個人任せにしない方がよいです。

担当者が退職したり、権限が変わったり、接続先DBが移動したりすると、自動化が止まります。

最初から、管理者、接続名、対象DB、目的をNotion内に記録しておきます。

よくある自動化例

MakeとNotion連携は、まず小さく始める方がよいです。

よくある例は次の通りです。

自動化	流れ	注意点
フォーム回答から問い合わせDB追加	フォーム送信 → Make → Notion DB追加	重複判定と初回担当者を決める
Gmailから対応タスク作成	特定条件のメール → Make → タスクDB追加	本文を転記しすぎない
Slack投稿から改善要望DB追加	Slack絵文字やコマンド → Make → 改善DB追加	投稿者と元リンクを残す
CRM商談更新をNotionへ反映	CRM更新 → Make → 案件DB更新	CRMを正とする項目を決める
Notionステータス変更でSlack通知	Notion DB更新 → MakeまたはWebhook → Slack	通知条件を絞る
Notion行から外部サービスへ登録	Notionで確認済み → Make → 外部ツール作成	確認済みだけを対象にする

最初に作るなら、問い合わせDBの追加がおすすめです。

1行の意味が分かりやすく、担当者、期限、ステータス、発生元リンクを設計しやすいからです。

プロパティ	型	Makeで入れるか
件名	タイトル	入れる
発生元	セレクト	入れる
外部ID	テキスト	入れる
元URL	URL	入れる
依頼者	テキスト、メール	入れる
要約	テキスト	下書きとして入れる
担当者	ユーザー	仮設定まで
期限	日付	条件付きで仮設定
ステータス	ステータス	未確認にする
確認者	ユーザー	人が入れる

Makeで作った行は、いきなり対応中にしない方がよいです。

まず 未確認 に入れます。

人が見て、担当者、期限、優先度、返信要否を確認します。

Notionタスク管理の作り方

対象DBの設計

Make連携で一番大事なのは、対象DBの設計です。

DBが曖昧だと、自動化も曖昧になります。

悪いDB	起きる問題
何でも受付DB	問い合わせ、タスク、要望、障害が混ざる
メモDB	担当者や期限を設定できない
外部サービス同期DB	どの外部サービスが正か分からない
自動化テストDBのまま本番化	権限やプロパティ名が整理されていない

Makeで使うDBには、最低限次の項目を用意します。

プロパティ	型	目的
タイトル	タイトル	何のレコードか分かるようにする
発生元	セレクト	フォーム、Gmail、Slack、CRMなど
外部ID	テキスト	重複判定や再実行に使う
元URL	URL	原本へ戻る
担当者	ユーザー	対応責任を決める
確認者	ユーザー	人の確認を入れる
期限	日付	放置を防ぐ
ステータス	ステータス	未確認、対応中、確認待ち、完了
同期状態	セレクト	未処理、処理済み、エラー、再実行待ち
最終同期日時	日付	いつMakeが触ったか分かるようにする
エラーメモ	テキスト	失敗理由を残す

外部IDは重要です。

フォーム回答ID、GmailスレッドID、SlackメッセージURL、CRM商談IDなどを保存します。

外部IDがないと、再実行時に同じページが重複して作られます。

Makeのシナリオでは、まず外部IDで既存レコードを検索します。

見つかれば更新。

見つからなければ新規作成。

このルールを入れるだけで、運用の安定度が上がります。

エラー処理と再実行

Make連携では、エラー処理を最初から設計します。

自動化は、必ず止まります。

外部サービスのAPI制限、Notionの権限変更、DBプロパティ名の変更、接続アカウントの期限切れ、入力データの形式違いなどが起きるからです。

エラー	起きる原因	対応
Notion DBが見つからない	DB移動、権限変更	接続権限を確認する
プロパティ更新に失敗	プロパティ名や型の変更	Make側のマッピングを直す
同じページが重複	外部IDで検索していない	外部ID検索を先に入れる
担当者が入らない	Notionユーザーと外部名が一致しない	担当者マスタを用意する
通知が来ない	通知先条件やSlack接続の問題	エラー通知DBや管理チャンネルを作る
本文が長すぎる	外部データの転記量が多い	要約と原本リンクに分ける

エラー時は、いきなり失敗した処理を何度も再実行しない方がよいです。

まず、Notion側に 同期状態 = エラー の行を作るか、管理用DBへエラーを登録します。

エラー管理DBのプロパティ	型
エラー名	タイトル
シナリオ名	テキスト
対象DB	URL、リレーション
外部ID	テキスト
エラー内容	テキスト
発生日時	日付
担当者	ユーザー
状態	ステータス
再実行可否	セレクト

再実行するときは、同じ外部IDで既存レコードを検索します。

すでに作成済みなら更新だけにします。

新規作成を繰り返さない設計が必要です。

Webhookとの使い分け

MakeとNotion連携では、Webhookもよく出てきます。

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

Notion公式ヘルプ：Webhook actions

このWebhookをMakeの入口にすると、Notion側の操作をきっかけにMakeのシナリオを動かせます。

起点	向いている使い方
Makeの外部トリガー	フォーム、CRM、Gmail、SlackからNotionへ入れる
NotionのWebhookアクション	Notion上の確認済みステータスから外部処理へ送る
Notion APIの定期取得	定期的にNotion DBを見て処理する
開発者向けWebhook	高度なリアルタイム連携や複数DB監視

NotionのWebhookアクションには制約もあります。

公式ヘルプでは、WebhookアクションはPOSTのみ、1つのオートメーションにつき最大5つ、送れるのはデータベースページのプロパティでページ本文は送れない、と説明されています。

そのため、Webhookにすべてを詰め込まない方がよいです。

Webhookで送る	NotionやMake側で別途見る
ページID	ページ本文
ステータス	長文メモ
外部ID	添付ファイル
担当者	詳細な履歴
元URL	権限の要る外部データ

Webhookは、外部処理を起動する合図です。

業務データの全量を渡す箱ではありません。

人の確認ポイント

MakeとNotion連携で最後に決めるべきなのは、人が確認するポイントです。

自動化で作った情報を、そのまま正式情報にしない方がよい場面があります。

自動化結果	人が確認すること
問い合わせ登録	種別、担当者、初回返信要否
AI要約	誤読、抜け漏れ、個人情報
優先度候補	顧客影響、期限、契約条件
外部サービスへの登録	登録先、権限、重複
ステータス変更	完了条件を満たしているか
通知送信	通知先が広すぎないか

Notion DBには、確認用のビューを用意します。

ビュー	条件
Make未確認	発生元 = Make かつ ステータス = 未確認
同期エラー	同期状態 = エラー
担当者未設定	担当者 が空
期限なし	期限 が空
再実行待ち	同期状態 = 再実行待ち
確認待ち	ステータス = 確認待ち

MakeとNotion連携は、シナリオを作って終わりではありません。

DBに入った情報を誰が見て、いつ確認し、どの条件で次の処理へ進めるかまで決める必要があります。

最初は、小さな片方向連携から始めます。

外部サービスからNotionへ登録する。

Notionで人が確認する。

確認済みになったらMakeで外部処理を実行する。

この段階を分けるだけで、自動化の事故はかなり減ります。

ノーコードでつなぐこと自体は簡単です。

難しいのは、つないだ後に業務として崩れない設計です。