Make.comでAirtable更新→Slack通知 チームの情報共有を自動化
Airtable で案件や在庫を管理しているのに、「ステータスが変わったこと」 にチームが気づかず対応が遅れる──そんな取りこぼしは、Make.com を1つ挟むだけで解消できます。本記事は中小企業・個人事業主が月¥1,500 規模で組める「Airtable 更新 → Slack 自動通知」 レシピを、編集部の試算と60分のセットアップ手順つきで整理した記事です。
- Airtable のレコード更新を Make.com が検知し、Slack に即時通知、見落としを防ぐ
- 「ステータスが◯◯に変わった時だけ」 など 条件を絞った通知 でチャンネルの騒がしさを抑える
- 個人事業主の小規模運用なら Make.com 無料プラン (月1,000オペレーション) でも十分回せる
- 本格運用でも 月 約¥1,500 (Make.com Core 相当) から、Zapier より安価に組める
- 案件管理・在庫・タスク・採用など 更新を共有したいあらゆる台帳 に応用できる設計
編集長の見解 ── チームの情報共有でよくある失敗は「台帳は更新されているのに、誰もそれを見ていない」 ことです。Airtable は静かなデータベースなので、レコードが変わっても自分から知らせてはくれません。Make.com で変化を Slack に押し出せば、台帳は「見に行くもの」 から「向こうから知らせてくれるもの」 に変わります。本レシピが重視するのは、Airtable を1次データの台帳に据え、Slack はあくまで「お知らせ係」 として切り離す設計です。これにより、後でチャットを Chatwork や LINE に変えても台帳は無傷で残ります。
なぜ Airtable→Slack 自動通知でチームの対応が速くなるのか
Airtable をチームで使っていると、「更新したのに気づかれない」 というすれ違いが必ず発生します。編集部が中小事業者にヒアリングしてまとめた「通知が手作業のときの典型フロー」 は次のとおりです。
| 工程 | 1件あたり所要 | 月100件換算 |
|---|---|---|
| 担当者がレコードを更新する | 約1分 | 月 約1.7時間 |
| 更新を関係者にチャットで手動連絡 | 約2分 | 月 約3.3時間 |
| 連絡を忘れて後から思い出して連絡 | 約2分 | 月 約2.0時間 |
| 「言った/聞いてない」 の確認・再連絡 | 約3分 | 月 約2.5時間 |
| 合計 | 約8分/件 | 月 約9.5時間 |
このうち「手動連絡」 と「言った/聞いてない の確認」 はまるごと自動化できます。Make.com が Airtable の更新を監視し、条件に合致したらすぐ Slack に流すため、担当者は更新するだけで連絡が完了します。編集部試算で 月 約5-7時間の圧縮 に相当します。
時給¥3,000 換算で月¥15,000-21,000 の人件費に対し、Make.com の月額は無料〜¥1,500。差し引いても 月 約¥15,000 前後の手取り改善 が試算できます。何より、対応の遅れによる機会損失が減る効果は金額換算しにくい価値です。
続いて、導入前後でチームの情報共有がどう変わるかを示します。
導入前後の比較 (BeforeAfter)
- 更新してもチームが気づかない
- 連絡を忘れて対応が遅れる
- 都度チャットで手入力連絡 (月5時間)
- 「聞いてない」 のすれ違いが起きる
- 誰が何を変えたか後から追えない
- 更新が即Slackに流れる
- 連絡漏れがゼロに近づく
- 手動連絡ゼロ (自動投稿)
- 全員が同じ通知を共有
- 変更内容が通知ログに残る
編集部試算で月 約5-7時間の削減
ポイントは「人が連絡しない」 ことです。更新という行為そのものが通知のトリガーになるため、担当者は連絡を意識する必要がなくなります。これにより、複数人で台帳を触る体制でも「変化が全員に届いている」 状態を保てます。
次に、編集部が実装した自動化の全体像を ProcessFlow で示します。
完成形のフロー (ProcessFlow)
Airtable のレコード更新を Make.com が監視し、条件に合致したものだけ整形して Slack に通知する自動化設計
このフローの肝は 「Airtable を1次データの台帳、Slack を置き換え可能なお知らせ係」 にする設計です。通知先を Slack から Chatwork や Discord に変えても、台帳である Airtable はそのまま使い続けられます。通知ツールに業務データを抱え込ませない構造が、長く使える自動化のコツです。
続いて、Make.com と Zapier のどちらで組むかの判断材料を比較します。
Make.com を選ぶ理由 — Zapier との比較
Airtable→Slack 通知は Zapier でも組めますが、編集部は中小企業の固定費を抑える観点から Make.com を推奨しています。料金は $1 = ¥155 で換算 (2026 年 6 月時点の編集部参照値、契約時の実レートで再計算してください)。
| 比較項目 | Make.com | Zapier | 編集部の見解 |
|---|---|---|---|
| 無料枠 | 月1,000オペレーション | 月100タスク | Make.com の方が無料で長く試せる |
| 有料の入口 | 月 約¥1,500 (Core) | 月 約¥3,000〜 | コスト重視なら Make.com |
| 操作画面 | 線でつなぐ視覚型 | 一直線のステップ型 | 分岐が多いなら Make.com が見やすい |
| 日本語情報 | 増加中 | 豊富 | 初心者の情報量は Zapier がやや有利 |
「とにかく安く・分岐を含めて組みたい」 なら Make.com、「日本語の解説記事を多く参照したい」 なら Zapier、というのが編集部の整理です。今回はコスト優先で Make.com を採用します。Zapier で同種の通知を組む手順はZapier で Airtable→Slack 通知レシピで扱っています。
💡 編集部のヒント ── Make.com の「オペレーション」 は、シナリオが実行する1ステップごとにカウントされます。1回の通知でモジュールを3つ通れば3オペレーション消費する計算です。Watch Records の監視間隔を短くしすぎると、更新がなくても定期チェックでオペレーションを消費するため、まずは15分間隔から始めるのが無駄のない設定です。
次に、Airtable 側の台帳をどう整えておくかを示します。
Airtable 側の準備 (通知しやすい台帳設計)
通知の質は、Airtable のフィールド設計で大きく変わります。編集部が中小事業者によく勧める案件管理の最小構成は次のとおりです。
- record_id (Autonumber) : 自動採番 (案件番号として使える)
- project_name (Single line text): 案件名・商品名など
- status (Single select) : 未着手 / 進行中 / 確認待ち / 完了
- assignee (Single select) : 担当者
- due_date (Date) : 期限
- last_modified (Last modified) : 最終更新日時 (自動記録)
- notify_channel (Single select): 通知先チャンネル名 (任意・複数案件種別の振り分け用)通知の核になるのは status です。「status が 確認待ち または 完了 に変わった時だけ通知する」 とフィルター条件を組めば、細かな途中更新で Slack を騒がせずに済みます。last_modified フィールドを入れておくと、Make.com 側で「いつ変わったか」 を扱いやすくなります。
| フィールド | 役割 | 通知設計上のコツ |
|---|---|---|
| status | 通知トリガーの判定 | 特定の値に変わった時だけ通すフィルターを組む |
| assignee | 誰の案件かを明示 | 通知本文に差し込んでメンション代わりにする |
| due_date | 期限の共有 | 期限が近い案件を強調する条件にも使える |
| last_modified | 更新検知の基準 | Make.com の Watch Records が拾う基準になる |
このフィールド設計のまま、Make.com 側の構築手順に進みます。
実際の60分セットアップを時系列で見ていきましょう。
60分セットアップ・タイムライン (TimelineSteps)
status の選択肢 (未着手 / 進行中 / 確認待ち / 完了) を整える。last_modified フィールドが無ければ追加。テスト用にレコードを1件用意しておく。last_modified を選ぶ。「Limit」 を 2 程度にしてテスト実行し、既存レコードが取得できれば成功。status equals 完了」 (または 確認待ち) を指定。これで対象ステータスに変わったレコードだけが先へ進み、途中更新では通知されない。status を「完了」 に変えてみて、Slack に通知が届くか最終確認する。届けば本番稼働完了。中小企業の担当者または個人事業主が独力で組める60分手順 (PC操作のみ、コード不要)
ここまでで「Airtable 更新 → 条件判定 → Slack 通知」 の基本ラインが完成します。複数のチャンネルに振り分けたい場合は、Slack モジュールの前に Make.com の「Router」 を挟み、notify_channel フィールドの値ごとに投稿先を出し分けると実現できます。
最後に、運用上の注意点と料金の考え方を整理します。
料金と運用上の注意
Make.com の料金は「月あたりのオペレーション数 (= モジュール実行回数)」 で決まります。中小企業の更新頻度を目安に、編集部がプランの考え方を整理します。為替は $1 = ¥155 換算です。
| 想定通知数 | 推奨プラン | 月額目安 | 備考 |
|---|---|---|---|
| 月数十件 (お試し) | 無料プラン | ¥0 | 月1,000オペレーション・最短15分間隔。まず試すならここ |
| 月数百件 (本格運用) | Core プラン | 約¥1,500〜 | 監視間隔を短く・複数シナリオを回すなら |
| 大量・複数チーム | Pro 以上 | ¥1,500超 | Router での多段振り分けや高頻度監視向け |
無料プランは最短実行間隔が15分のため、「秒単位の即時性」 が必要な業務には向きません。最新の正確な料金とオペレーション上限は、必ずMake.com の公式料金ページで確認してください。
⚠️ 編集部の警告 (1) ── 通知の出しすぎに注意してください。フィルターを設定せずに全更新を Slack に流すと、誰かがレコードを少し直すたびに通知が飛び、チャンネルが騒がしくなって誰も読まなくなります。「どの変化を全員に知らせる価値があるか」 を先に決め、status が特定の値に変わった時など条件を必ず絞ってください。通知は少なく・重要なものだけ、が定着のコツです。
⚠️ 編集部の警告 (2) ── 情報の取り扱いに注意してください。案件名や顧客名を Slack に流す以上、その通知チャンネルに招いてよいメンバーかを確認する必要があります。社外の協力者が入っているチャンネルに、機密性の高い案件情報を自動投稿しない設計にしてください。通知本文には最小限の情報だけ載せ、詳細は Airtable のレコード URL を開いて確認する運用が安全です。
💡 編集部のヒント ── 「期限切れアラート」 にも応用できます。Make.com の「Schedule」 と Airtable「Search Records」 を組み合わせ、due_date が今日を過ぎても status が完了でないレコードを毎朝抽出して Slack に再通知するだけです。更新通知と合わせて組めば、対応漏れを仕組みで防げます。
よくある質問
Q. Make.com の無料プランでも実用になりますか。 A. 月数十件程度の通知なら十分実用になります。ただし最短実行間隔が15分のため、即時性が必要な場合は有料の Core プラン (約¥1,500/月) で間隔を短くするのが現実的です。
Q. プログラミングの知識は必要ですか。 A. 不要です。本レシピはすべて画面操作 (モジュールを線でつなぎ、項目を選ぶだけ) で完結します。コードを書く場面はありません。
Q. Slack を使っていない場合はどうすれば。 A. 通知先を Chatwork・Discord・Microsoft Teams などに差し替えられます。Airtable を台帳の中心に据えているため、通知ツールは後からいつでも変更できます。
チームの更新共有を仕組み化したら、次はデータの入口や請求まわりも自動化したくなります。Make.com で Airtable→請求書を自動作成や、Make.com で Notion→Slack 通知、フォームからのリード取り込みを扱ったMake.com でフォーム→リード自動化レシピも参考になります。
出典・参考情報
- Make.com 公式料金ページ: https://www.make.com/en/pricing
- Airtable 公式サイト: https://airtable.com/
- Slack 公式サイト: https://slack.com/
※本記事の時間・金額の試算は編集部のシミュレーションです。実際の効果は更新件数や運用体制により異なります。料金・プラン仕様は変動するため、契約前に各公式ページで最新情報をご確認ください。
Mira ／ AI経営ラボ 編集長
Make.com を無料で試す → ※ PR・アフィリエイトリンクを含みます