Slack・Notion・生成AIで承認フローをつなぐ｜通知設計のコツ

ビジネスのスピードが加速する中で、従来の「紙」や「専用ワークフローシステム」による承認フローは、柔軟性の欠如や通知の埋没という課題に直面しています。特に、日常的なドキュメント管理をNotionで行い、コミュニケーションの主軸をSlackに置いているチームにとって、ツール間を横断する承認作業は大きなオーバーヘッドです。

本記事では、Notionをデータ基盤、Slackをフロントエンド、生成AIをインテリジェントなフィルタリング層として活用し、iPaaS（MakeやZapier）でそれらを統合する「次世代型承認フロー」の構築手法を詳述します。現場の人間が「Notionをわざわざ見に行かなくても、Slack上で内容を把握し、一瞬で判断を下せる」環境をどう作るか、その実務的な最適解を提示します。

Slack・Notion・生成AIを連携させるべき理由と全体像

多くの企業が、Notionの「ステータス」プロパティを更新することで承認を運用しようと試みます。しかし、Notion標準の通知機能だけでは、大量のログの中に重要な承認依頼が埋もれてしまい、結果として「Slackで『承認お願いします』とURLを送る」という二重の手間が発生しています。

なぜ標準の通知機能だけでは不十分なのか

Notionの通知は、あくまで「変更があったこと」を知らせるものであり、その内容が「自分にとってどれほど緊急か」「承認に必要な判断材料は揃っているか」を瞬時に判別させるには不向きです。また、Slack通知に飛ばすだけでは、結局URLをクリックしてNotionを開き、ログインして、該当箇所を探すという数クリックのロスが生じます。この「数クリック」が積み重なることで、意思決定のボトルネックが発生するのです。

Notion（蓄積）・Slack（意思決定）・生成AI（仕分け）の役割分担

効率的なフローを構築するためには、各ツールの役割を明確に分担する必要があります。

• Notion：情報のマスター。申請内容、関連資料、過去の経緯をすべて蓄積する「Single Source of Truth」。
• Slack：インターフェース。承認者が最も時間を過ごす場所であり、ここですべての「判断」と「指示」を完結させる。
• 生成AI（OpenAI / Anthropic等）：監査・要約者。申請内容に論理的な矛盾がないか、金額や条件が規定内かをチェックし、承認者が読むべきポイントを数行に要約する。

モダンな承認フロー構築に必要なツール群とコスト感

この仕組みを実現するためには、各ツールを繋ぐ「iPaaS」が不可欠です。以下に代表的な構成例と、2024年現在の目安コストをまとめます。

※料金の詳細は、各社公式の料金ページ（Notion料金、Slack料金、Make料金）をご確認ください。

こうしたツール連携による業務効率化は、バックオフィス全体の見直しにも繋がります。例えば、SaaSコストを削減。フロントオフィス＆コミュニケーションツールの「標的」と現実的剥がし方で解説しているように、ツールの整理と統合を同時に進めることで、ライセンスコストの最適化も可能になります。

【実践】承認フロー自動化のアーキテクチャ設計

単に「Notionが更新されたらSlackに送る」だけでは、実務に耐えうるフローにはなりません。ここでは、エラーが起きにくく、運用が回る設計図を定義します。

DB設計：Notion側で準備すべきプロパティとステータス管理

Notionのデータベースには、連携をスムーズにするための「制御用プロパティ」を持たせることがポイントです。

• Status： 「下書き」「承認待ち」「生成AIチェック中」「承認済み」「差戻し」といった細かいフェーズ管理。
• Slack Thread ID： 連携時に発行されるSlackのスレッドIDを保存するテキストプロパティ。これにより、同じ案件のやり取りを一つのスレッドに集約できます。
• AI Summary： 生成AIが書き出す要約内容を格納するテキストエリア。
• Assignee (承認者)： ユーザープロパティ。ここで指定されたユーザーをSlack側でメンションします。

トリガー設計：iPaaS（Make/Zapier）を介したリアルタイム連携

NotionのAPIには、特定のプロパティ変更を直接トリガーにするWebHookが標準では存在しません（2024年現在）。そのため、MakeなどのiPaaS側で「Watch Database Items」モジュールを使用し、数分おきに「ステータスが承認待ちに変更されたアイテム」をポーリング（監視）する手法が一般的です。

Tips: 即時性を高めたい場合は、Notionの「ボタンプロパティ」を活用し、ボタン押下時に外部Webhookを叩く設定にすることで、ポーリングのタイムラグをゼロにできます。

AIによる一次審査：申請内容の要約と不備検知のプロンプト構成

承認依頼が飛んでくる前に、生成AIに内容を精査させます。例えば、以下のような指示（プロンプト）をMake内のOpenAIモジュールに設定します。

指示

以下のNotionからの申請内容を分析し、承認者が判断しやすいように3行で要約してください。
また、もし「金額が10万円を超えているのに見積書の添付がない」などの明らかな不備があれば、[警告]として出力してください。

申請内容

{{Notion_Content}}

この結果をSlack通知の冒頭に配置することで、承認者は「AIが一次チェックをパスした案件かどうか」を瞬時に把握できます。

Slack通知設計の極意：ノイズ化を防ぎ「即断」を促すUI

承認者の負荷を最小化するためには、Slackの「Block Kit」を活用した視認性の高い通知が不可欠です。単なるテキストメッセージではなく、ボタンやセクションを活用しましょう。

Block Kitを用いた「Notionを開かせない」通知レイアウト

SlackのBlock Kit Builderを使用すると、JSON形式でリッチなUIを設計できます。通知に含めるべき要素は以下の通りです。

• Header：案件名と申請カテゴリ。
• Section：AIによる要約（Summary）。ここに要点が凝縮されていることが重要。
• Context：申請者名、申請日時、Notionへの直リンク。
• Actions： 「承認（Approve）」「差戻し（Reject）」の2つのボタン。

承認・却下ボタンの挙動とNotionへのステータス書き戻し

Slack上のボタンが押された際、その信号（Interactivity）をMakeの「Custom Webhook」で受け取ります。その後、以下の処理を自動実行します。

1. Notion側の該当アイテムの「Status」を「承認済み」または「差戻し」に更新。
2. Notionの「承認日時」「承認者名」プロパティを更新。
3. Slackの元のメッセージを「この案件は承認されました」というテキストに書き換える（二重承認の防止）。

こうした高度な自動化は、経理業務などのミスが許されない領域で特に威力を発揮します。例えば、楽楽精算×freee会計の「CSV手作業」を滅ぼす。経理の完全自動化とアーキテクチャに見られるような、厳格なデータ連携の考え方と通じるものがあります。

ステップバイステップ：Make（旧Integromat）を用いた構築手順

ここでは、最も汎用性の高いMakeを使用した具体的な設定手順を解説します。

STEP 1：Notionの特定ステータス変更を検知する

Makeのシナリオを作成し、最初のモジュールに「Notion – Watch Database Items」を選択します。Filter設定で「Status equals 承認待ち」を指定します。また、一度取得したアイテムを再度処理しないよう、内部的なID管理（Limit設定）を適切に行います。

STEP 2：OpenAIモジュールで内容の論理チェックと要約を行う

次に「OpenAI – Create a Completion」を繋ぎます。モデルはコストと精度のバランスが良い「gpt-4o-mini」や、より高度な推論が必要なら「gpt-4o」を選択します。ここで、Notionから取得した「申請理由」や「金額」などのデータをプロンプトに埋め込みます。

STEP 3：SlackのBlock Kitに動的データを流し込む

「Slack – Create a Message」モジュールを追加します。Message Text欄ではなく、Blocksプロパティ（JSON）を記述します。前段のOpenAIモジュールから出力された要約テキストを、Block KitのJSON内に変数として挿入します。

STEP 4：Webhookを用いた「逆方向（Slack→Notion）」の同期設定

Slackのボタン操作を受け取るための「別シナリオ」を作成します。トリガーは「Custom Webhook」です。SlackのApp管理画面（api.slack.com）で「Interactivity & Shortcuts」を有効にし、MakeのWebhook URLを登録します。ボタンが押された際に飛んでくるJSONから、NotionのPage IDを特定し、Update a Pageモジュールでステータスを書き換えます。

よくあるトラブルと回避策

運用を開始すると、技術的、あるいは組織的な課題に直面することがあります。事前に以下の対策を講じておくべきです。

レートリミット（API制限）への対処法

Notion APIやSlack APIには、短時間の大量リクエストを制限するレートリミットがあります。特に全社員が利用するようなフローでは、Makeの「Sleep」モジュールを挟んで実行間隔を調整するか、キューイングの仕組みを検討してください。

承認者が不在の場合の「エスカレーション」設計

「承認ボタンが24時間押されなかった場合」を検知するシナリオを別途作成します。Notionの「最終更新日時」をチェックし、一定時間経過してもステータスが「承認待ち」のままなら、Slackのメンション先を上長や代理承認者に切り替えて再通知する設計が有効です。

ログ管理：いつ、誰が、なぜ承認したかのエビデンスを残す

監査対応のため、Notionのページ内に「承認ログ」をプロパティではなく、ページ本文（Content）の末尾に追記する形で残すことを推奨します。Makeの「Notion – Append a Content Block」を使用すれば、Slackでのコメントも含めて自動で記録できます。これは、Excelと紙の限界を突破する「Google Workspace × AppSheet」業務DX完全ガイドで強調されている「データの整合性と証跡」の重要性と同じく、信頼性の高いシステム構築に欠かせない要素です。

まとめ：自律型バックオフィスへの第一歩

Slack、Notion、そして生成AIを組み合わせた承認フローは、単なる自動化を超えた「意思決定の高速化」をもたらします。承認者は「探す」「読む」という苦痛から解放され、AIによるスクリーニング済みの情報に対して「判断」を下すという、人間にしかできない本来の業務に集中できるようになります。

まずは、最も頻度の高い「経費精算」や「備品購入申請」など、小規模なフローから実装を開始してみてください。API連携の柔軟性が、組織のオペレーショナル・エクセレンスを一段上のレベルへと引き上げるはずです。