NotionとDiscordを連携する方法｜Make・Webhook・GASを実務で比較

2026年3月13日2026年8月18日

NotionとDiscordを橋のように繋ぎ、情報の流れをスムーズにする連携イメージ図。

SkillStack Lab運営者のスタックです。

Notionでタスクやマニュアルを管理し、Discordでチームのやり取りをしていると、「重要な更新だけ自動でDiscordへ通知できないかな」と思いますよね。

私も実務でNotionのタスク管理データベースとDiscordを連携し、タスクの完了や緊急案件をプロジェクト別チャンネルへ通知する仕組みを継続運用しています。

その中で分かったのは、「連携できるものを全部自動化する」のは逆効果だということです。

スタック

「APIで繋がるから」という理由だけで自動化しないでください。判断基準は「その通知を見て誰かが行動するか」と「半年後に別の人でも直せるか」の2つです。

実際、私は最初にNotionのタスク作成・更新・完了をすべて通知して大失敗しました。1日に何十件も流れた結果、メンバーがチャンネルをミュートし、本当に重要な通知まで見られなくなったからです。

現在は、「承認してほしい」「緊急対応してほしい」といったアクションが必要なものと、リリース完了など重要なマイルストーンだけに絞っています。

この記事で分かること

NotionからDiscordへ通知するおすすめ構成
Make・Zapier・Webhook・GAS・Botの使い分け
Discord Incoming Webhookで通知する考え方
Notion公式Webhookを直接Discordへ送ると失敗しやすい理由
DiscordからNotionへ何でも保存しない方がよい理由
WebhookやGASを安全に運用する注意点

結論｜NotionとDiscordの連携はMakeから始める

中小企業でNotionとDiscordを連携するなら、私はまずMakeを候補にします。

理由は、NotionとDiscordをノーコードでつなげるだけでなく、フィルターやRouterを使って「どの条件なら、どのチャンネルへ送るか」を視覚的に分岐できるからです。

私の実運用では、Notionのタスク管理データベースを起点に、次のようなルールで通知しています。

Notion側の条件	Discord側の処理
タスクが完了	該当プロジェクトのチャンネルへ完了通知
「緊急」タグが付いた	該当チャンネルへ優先通知
プロジェクトA	DiscordのAチャンネル
プロジェクトB	DiscordのBチャンネル

通知には、タスク名、担当者、Notionページへのリンクなど、本当に確認してほしい情報だけを入れています。

Makeは現在もNotionとDiscordの連携を提供しています。Routerでは条件ごとに処理ルートを分岐し、Filterで通過条件を設定できます。

Make公式：DiscordとNotionの連携

Make公式：Routerの使い方

NotionからDiscordへ通知する実務的な流れ

1．通知するイベントを絞る

最初に決めるのはツールではなく、「何を通知するか」です。

私が現在通知対象にしているのは、主に次のようなイベントです。

承認など、誰かに具体的な行動を求めるもの
緊急対応が必要なもの
リリース完了など重要なマイルストーン

逆に、単なるタイトル修正や軽微なプロパティ変更まで通知する必要はほとんどありません。

初期は「作成・更新・完了」のすべてをメインチャンネルへ流していました。結果は完全なオオカミ少年状態です。通知が多すぎて全員がチャンネルをミュートし、本当に見てほしい通知まで埋もれました。

2．FilterとRouterで送信先を分ける

Makeでは、条件に合わないデータをFilterで止め、Routerで複数の処理先へ分岐できます。

たとえば、

営業プロジェクト → 営業チャンネル
システム案件 → 開発チャンネル
緊急案件 → 責任者への通知を追加

という形です。

こうして「必要な人に必要な通知だけ届く」状態を作る方が、全社チャンネルへ何でも流すより機能します。

3．Discordにはタスク名とURLを送る

通知本文も詰め込みすぎないことが大切です。

私なら最低限、

何が起きたか
対象タスク
担当者
NotionページへのURL

程度にします。

詳細はNotionを正本として確認してもらえばよく、Discordにすべてのプロパティを複製する必要はありません。

ZapierとMakeはどちらを使う？

ZapierでもNotionとDiscordを連携できます。

私もPoCで試しましたが、画面が分かりやすく、初めてノーコード自動化に触れる場合の導入しやすさは魅力でした。

一方、実務で通知量や条件分岐を増やすことを考えた結果、私はMakeを本採用しています。

項目	Zapier	Make
私の利用状況	PoC・テスト	継続運用
始めやすさ	◎	○
条件分岐	○	◎
視覚的なルーティング	○	◎
私の用途との相性	シンプルなPoC向き	本番運用向き

Zapierにも現在、Notionの更新からDiscordへメッセージを送る連携や、DiscordからNotionへデータを渡す連携が用意されています。

Zapier公式：DiscordとNotionの連携

料金体系や無料枠は変更されるため、「Zapierは高い」「Makeは必ず安い」と一般化はしません。私の業務量と分岐数ではMakeの方が運用しやすかった、という実体験です。

単方向の通知ならDiscord Incoming Webhookで十分

外部システムからDiscordへ通知するだけなら、独自Botを作る必要はありません。

DiscordのIncoming Webhookは、特定チャンネルに紐づいたURLへHTTPリクエストを送ることでメッセージを投稿できる仕組みです。

Botユーザーを常時稼働させなくても利用できます。

Discord公式：Webhook Resource

テキストだけでなくEmbedも使える

DiscordのWebhookでは、単純なcontentだけでなく、embedsを使ったリッチな表示もできます。

私の運用でも、アラートと通常の完了通知を見分けやすくするためにEmbedを利用しています。

また、役職者など特定ロールへ通知したい場合は、必要なケースだけロールメンションを組み合わせます。

@everyoneや@hereを常用するのはおすすめしません。通知を強くするほど読まれるのではなく、頻度が高いとチャンネル自体をミュートされる可能性があります。対象ロールと通知条件を絞る方が実務では機能します。

NotionのWebhookには2種類ある

Notionの「Webhook」を調べると情報が分かりにくいのですが、現在は大きく2つを区別して考える必要があります。

種類	用途	向いている人
Webhook action	ボタン・DBオートメーションからPOST送信	ノーコード・ローコード
Integration Webhooks	API連携で変更イベントを受信	開発者向け

Webhook actionは手軽だが本文は送れない

NotionのWebhook actionは、有料プランのボタン・データベースボタン・データベースオートメーションからHTTP POSTを送信できる機能です。

データベースオートメーションでは送信するプロパティを選べますが、現在の仕様ではページ本文そのものは送信できません。

また、1つのオートメーションに設定できるWebhook actionは最大5つ、HTTPメソッドはPOSTのみです。

Notion公式：Webhook actions

NotionからDiscordへ直接送ると400になることがある

「NotionにWebhookがあるなら、DiscordのWebhook URLをそのまま入れればよいのでは？」と思うかもしれません。

しかし、DiscordのWebhookはメッセージ送信時にcontent、embedsなどDiscord側が理解できる形式を必要とします。

Notionから送られるJSONをそのまま渡すと、Discordが必要とする形式と一致せず、HTTP 400などで失敗する可能性があります。

このため、私はMakeやGASなどを中継させ、Discord用のJSONへ整形する構成を使います。

GASは「特殊な中継処理」が必要なときに使う

Makeでつなげられるなら、何でもGASで自作する必要はありません。

一方、iPaaSに標準コネクタがない社内システムなどではGASが便利です。

私は実際に、マイナーな社内システムの更新通知をGASのdoPost(e)で受け取り、JSONを解析し、必要な顧客名や金額だけを取り出してDiscordへ送る中継処理を運用したことがあります。

外部システムのJSONをGASで必要な情報だけに整形してDiscordへ送信する中継処理のイメージ

GASで行う処理の基本

doPost(e)でHTTP POSTを受信
e.postData.contentsから本文を取得
JSON.parse()でJSONを解析
必要な値だけ抽出
Discord用のJSONに整形
UrlFetchApp.fetch()でDiscordへPOST

GASのdoPostで受信しJSON解析と整形を行ってUrlFetchAppでDiscordへ送信する処理フロー

DiscordのWebhook URLなどをコードへ直接書き込むのではなく、GASのProperties Serviceなどを使って設定値として管理する方法もあります。

Google公式：Apps Script Web Apps

Google公式：Properties Service

Notion Integration Webhookの署名検証をGASだけで行わない

開発者向けのNotion Integration Webhooksでは、Notionから送信された正規のリクエストか確認するため、X-Notion-SignatureというHTTPヘッダーを使ったHMAC-SHA256検証が公式に用意されています。

ただし、Google Apps ScriptのWebアプリでdoPost(e)に渡される公式イベントオブジェクトには、任意のHTTPリクエストヘッダーを取得する項目が公開されていません。

そのため、Notion Integration Webhooksの公式署名検証をGAS Web Appだけで実装する構成はおすすめしません。署名検証が必要なら、HTTPヘッダーを扱えるCloud Run、Cloud Functions、Workersなどの受信基盤や、適切なiPaaSを使う方が設計しやすくなります。

Notion Developers：Integration Webhooks

DiscordからNotionへの全自動保存はおすすめしない

次に逆方向の「Discord → Notion」です。

MakeやZapierを使えば、DiscordのメッセージをNotionへ保存する仕組み自体は作れます。

私も、重要なチャットへ特定のリアクションを付けるとNotionの備忘録データベースへ保存する仕組みをテストしました。

しかし、本番運用にはしませんでした。

単体のメッセージだけNotionへ保存すると、前後の会話が抜け落ちます。数週間後に読むと「これは何の話だったのか」が分からないページが増え、Notionがゴミ屋敷になりかけました。

これは、自動化すればするほど情報資産が増えるとは限らない典型例だと感じています。

チャットは議論、Notionは確定情報と役割を分ける

私の現場では、SlackやDiscordで契約書のフォーマットなどを議論して決定したのに、その決定がチャットにしか残っておらず、半年後に新しい担当者が再び過去ログを探すという無駄が起きていました。

そこで現在は、

Discord・Slack → 議論する場所
Notion → 決定事項を残す場所

と役割を分けています。

そして「チャットで決定したことは、発案者がNotionの該当ページを更新する」というルールにしました。

最後は人間が文脈を整理してストックする方が、チャットを機械的に全部保存するより後から使えるナレッジになります。

Notionを社内Wikiとして運用する考え方は、Notionで社内Wikiを作る方法でも解説しています。

独自Discord Botは最後の選択肢にする

Discord Botを作れば、リアクションの検知、コマンドへの応答、メッセージ取得などIncoming Webhookではできない処理まで実装できます。

私もDeveloper Portalでアプリを作成し、Bot Token、Gateway Intentsを設定して、Pythonでリアクションを検知するところまではテストしました。

しかし、本番運用には採用していません。

理由は、Botを動かすサーバーの維持、Token管理、障害対応、Discord APIの仕様変更への追従など、機能以外の保守が増えるからです。

Discordへ一方向に通知するだけならIncoming Webhook。条件分岐まで必要ならMake。特殊なデータ変換ならGAS。本当に双方向の対話・リアクション監視・コマンド処理が必要になった段階でBotを検討する。この順番なら過剰設計を避けやすくなります。

なお、Discordアプリが通常のメッセージ本文を読み取る場合は、Message Content Intentなど権限設計にも注意が必要です。

Discord公式：Message Resource

NotionとDiscordが連携できないときの確認ポイント

HTTP 400が返る

Discord Webhookへ直接POSTして400になる場合は、まずJSON形式を確認します。

DiscordのExecute Webhookでは、少なくともcontent、embedsなど対応するフィールドが必要です。

Notionや別システムのJSONをそのまま送るのではなく、MakeやGASでDiscord向けに整形します。

Discordのメッセージ本文が取得できない

Discord側からメッセージを取得する連携では、利用するBotや接続方法によってMessage Content Intentが関係します。

Make公式も、標準の接続ではメッセージ本文などが空になるケースがあり、必要な場合は独自アプリ認証と適切なIntent設定が必要になると案内しています。

Make公式：Discordモジュール

通知が多すぎる

これはシステムエラーではありませんが、実運用では最も大きな失敗原因の一つです。

「通知できているから成功」ではなく、通知後に誰かが行動しているかを確認してください。

反応されない通知は、削る候補です。

Notionのデータが取得できない

APIやiPaaSからNotionを操作する場合は、対象ページやデータソースへ接続先のIntegrationがアクセスできる状態か確認します。

「Tokenが正しいのに取得できない」という場合は、権限や接続対象を見直しましょう。

Notion×Discord連携の選び方

やりたいこと	第一候補	理由
Notion更新をDiscordへ通知	Make	条件分岐と運用のバランスが良い
外部システムからDiscordへ単純通知	Incoming Webhook	Bot不要でシンプル
標準連携にないJSON変換	GAS	必要部分だけ柔軟に自作できる
簡単なPoC	Zapier	構築を始めやすい
Discordで対話・コマンド処理	Bot	双方向処理が必要な場合だけ
チャットをNotionへ全部保存	原則おすすめしない	文脈を失いノイズ化しやすい

NotionとDiscordの連携でよくある質問

NotionとDiscordは連携できますか？: できます。MakeやZapierなどのiPaaS、NotionのWebhook、Discord Incoming Webhook、APIなどを組み合わせる方法があります。私の実運用ではMakeを使ってNotionの重要なタスク更新だけDiscordへ通知しています。
NotionからDiscordへ直接Webhookを送れますか？: NotionにはWebhook actionがありますが、Discord側が要求するJSON形式と一致しない場合があります。直接接続で失敗する場合は、MakeやGASなどでDiscord向けのcontent・embeds形式へ整形します。
ZapierとMakeはどちらがおすすめですか？: 簡単なPoCならZapierも使いやすいです。私の場合は複数チャンネルへの条件分岐や運用コストを考え、Makeを継続利用しています。現在の料金・必要機能を比較して選んでください。
Discordのメッセージを自動でNotionへ保存するべきですか？: 私はおすすめしていません。リアクションを付けた投稿だけNotionへ保存する仕組みを試しましたが、前後の文脈が消えて意味の分からないメモが増えました。議論はDiscord、確定した内容は人がNotionへ整理する運用にしています。
Discord通知のためにBotを作る必要がありますか？: 一方向の通知だけなら基本的に必要ありません。Incoming Webhookで投稿できます。Botはリアクション監視、コマンド、双方向の対話などWebhookでは足りない要件がある場合に検討します。
Notion WebhookをGASで安全に受信できますか？: 一般的なPOST本文をGASのdoPost(e)で受け取ることはできます。ただし、Notion Integration Webhooksが要求するX-Notion-Signatureヘッダーを使った公式署名検証は、Apps Script Web Appの公開イベントオブジェクトだけでは実装しにくいため、署名検証が必要な用途では別の受信基盤を検討してください。