最終更新日: / 公開日:
最終更新日: / 公開日:
フォームからの問い合わせに気づいたのが翌朝だった。商談ステージが動いたのを週次ミーティングで初めて知った。BtoB の現場でよく聞く話ですが、原因の多くはツールではなく「通知が届く場所」にあります。
HubSpot と Slack の標準連携は、無料プランを含む全プランで使えます。設定はインストールから通知の振り分けまで、初回でも 15 分前後で終わります。私たち humbulls も自社の HubSpot (Starter) を Slack 通知前提で運用しており、フォーム送信や商談の動きは管理画面を開かずに把握しています。
この記事では、標準連携の 15 分設定、フォーム通知・商談通知の実務的な使い分け、Starter プランで詰まりやすいポイントの回避策、そして Claude Code で通知に AI 要約を載せる発展形まで、順番に解説します。
1. なぜ HubSpot の通知を Slack に集めるのか — リード放置を 10 分の通知設計で潰す
リード対応の初動スピードは、商談化率に直結します。 対応が遅れる原因の大半は、担当者の怠慢ではなく「気づいていない」こと。 だから HubSpot × Slack 連携で最初にやるべきは、HubSpot の通知をチームが常時見ている Slack へ揃えることです。
BtoB マーケティングの定石として、獲得したリードには速く接触するほど商談化しやすい、という原則があります。見込み顧客は複数社を並行して比較しており、先に有益な返答をした会社が会話の主導権を握るからです。マーケと営業の間で「何分以内に対応するか」を取り決める SLA (サービスレベル合意) の考え方も、この原則が土台になっています。マーケと営業の SLA 設計の手順は、今後の記事で詳しく解説する予定です。
従来のやり方は、HubSpot からのメール通知か、管理画面の定期巡回です。ただ、メール通知はメルマガや社内メールに埋もれますし、「1 日 3 回 HubSpot を見る」という運用ルールは、忙しい週から順に崩れていきます。通知の見落としは仕組みの問題なのに、「対応が遅い」と人の問題として扱われてしまうのが典型的な落とし穴です。
humbulls では、この問題を「通知の置き場所」の問題として扱います。チームが 1 日中開いているのは HubSpot ではなく Slack です。であれば、フォーム送信・商談の変化・タスクのリマインドを Slack に流し込むのが、いちばん安い解決策になります。ツールの追加費用はゼロ、必要なのは初回 15 分の設定だけです。
ただし、注意点がひとつあります。「とりあえず全部 Slack に流す」と、今度は Slack 側で通知が埋もれ、数週間で誰も見なくなります。設定の前に、どのイベントを・誰に・どこへ届けるかを 10 分だけ棚卸ししておくと、後の章の設定がそのまま設計図どおりに進みます。
🤖 AI で実行する — 使ったプロンプト / ワークフロー
目的: Slack に流すべき通知イベントを棚卸しし、通知設計の下書きを作る 所要時間: 10 分 ツール: Claude / ChatGPT
プロンプト:
BtoB マーケ・営業チームの通知設計を作ってください。
前提:
- CRM: HubSpot
- チャット: Slack
- チーム構成: (例: マーケ 1 名、営業 2 名、代表 1 名)
- 月間の新規リード数: (例: 30 件)
- 現在の通知手段: (例: メール通知のみ)
通知したいイベント候補:
- フォーム送信 (問い合わせ / 資料DL)
- 商談 (取引) の作成・ステージ変更
- タスクの割り当て・期限
- レコードへのメンション
- ウェブチャットの着信
出力形式:
| イベント | 重要度(高/中/低) | 届け先(DM/チャンネル名案) | 期待する初動 | 通知しない判断もあり得るか |
条件:
- 「全部通知する」提案は禁止。月間リード数から通知件数を概算し、
1 チャンネルあたり 1 日 10 件を超える設計は分割か削減を提案してください。
- 迷うものは「まず通知しない」に倒してください。
運用 Tips: - 出力はそのまま採用せず、営業側に「この通知が来たら何分で動けるか」を確認してから確定します。 - 「期待する初動」が書けないイベントは、通知ではなくレポートで見る対象です。
2. 標準連携を 15 分でつなぐ — インストール 5 分 + 通知振り分け 10 分
HubSpot の App Marketplace から Slack をインストールし、 通知設定で「どの通知を Slack に送るか」を選ぶだけです。 つまずくのは権限とメールアドレスの 2 点だけです。
HubSpot 公式の手順はシンプルです。まず前提条件として、HubSpot 側はスーパー管理者または App Marketplace 権限を持つユーザー、Slack 側はワークスペースへのアプリ追加を承認できる立場のユーザーが必要です。少人数チームなら代表や管理者がそのまま両方を満たしていることが多いはずです。
手順は 4 ステップです。(1) HubSpot の設定から App Marketplace を開き、Slack を検索してインストール。(2) Slack 側の画面で権限を確認して承認。(3) HubSpot と Slack のメールアドレスが一致しているか確認。一致していない場合は連携設定でマッピングし、Slack に届く確認メッセージで承認します。(4) HubSpot の「設定 → 通知 → その他のアプリ」タブで Slack をオンにし、受け取りたい通知の種類にチェックを入れる。ここまでで、フォーム送信やメンション、タスクのリマインドが Slack に届き始めます。
実務でつまずくのは 2 ヵ所です。1 つ目は権限不足で App Marketplace のインストールボタンが押せないケース。2 つ目が、HubSpot と Slack で登録メールアドレスが違っていて、通知の宛先ユーザーとして認識されないケースです。会社ドメインの表記ゆれ (info@ と個人アドレスの混在など) があるチームは、先にどちらかへ揃えておくと早く終わります。また、HubSpot に接続できる Slack ワークスペースは 1 つだけという制限があるので、複数ワークスペースを使い分けている会社は「どこにつなぐか」を先に決めてください。
なお、この章の設定はすべて HubSpot 公式のナレッジベースに沿った内容です。UI の文言は更新されることがあるため、画面が違う場合は記事末尾の参考文献から最新の公式手順を確認してください。
🤖 AI で実行する — 使ったプロンプト / ワークフロー
目的: 1 章の棚卸し結果を、そのまま作業できる設定チェックリストに変換する 所要時間: 5 分 ツール: Claude / ChatGPT
プロンプト:
以下の通知設計をもとに、HubSpot × Slack 連携の設定チェックリストを作ってください。
通知設計:
(1 章のプロンプトで出した表を貼る)
チーム情報:
- HubSpot の管理者: (名前)
- Slack のワークスペース管理者: (名前)
- メンバーの HubSpot / Slack 登録メールが一致しているか: (はい/いいえ/不明)
出力してほしいこと:
1. 作業チェックリスト (担当者名入り、所要時間の目安つき)
2. 事前に確認が必要な項目 (権限・メールアドレス不一致など)
3. 設定完了後の動作テスト手順 (テストフォーム送信 → Slack 着信確認まで)
条件:
- HubSpot の通知設定は「設定 → 通知 → その他のアプリ」の画面を前提にしてください。
- テスト手順には「誰が・何を送信し・どこで受信を確認するか」を明記してください。
運用 Tips: - 動作テストは必ず本番と同じフォームで行います。テスト専用フォームだと通知条件の差分に気づけません。 - チェックリストは Slack の該当チャンネルに貼っておくと、後から入ったメンバーの引き継ぎ資料になります。
3. フォーム通知と商談通知の実務設計 — DM とチャンネルの 2 レーン + AI 文面設計 15 分
フォーム送信・タスク・メンションは「自分宛て」の通知として DM へ。 チーム全員が知るべき商談の動きはチャンネルへ。 この 2 レーンに分けるだけで、通知の見逃しと通知疲れの両方が減ります。
HubSpot の Slack 通知は、大きく 2 系統に分かれます。1 つはユーザー通知で、フォーム送信、レコードでのメンション、タスクの割り当てとリマインドなどが、HubSpot アプリからの DM として本人に届きます。もう 1 つはチャンネル向けの通知で、レコードに関連づけたチャンネルへのアクティビティ共有や、ワークフローからのカスタム通知 (これは後述のとおりプラン制限があります) がここに入ります。
実務では、この 2 系統を「初動する人が決まっているか」で使い分けます。フォーム送信への一次対応が営業 1 名に決まっているなら DM で十分です。一方、「今週どんな問い合わせが来ているか」「大型商談がステージを進んだか」はチームの共有知にしたいので、#lead-alert や #sales-pipeline のようなチャンネルに流します。なお、チャンネル通知を受けられるのはパブリックチャンネルか、HubSpot アプリを招待済みのプライベートチャンネルだけなので、チャンネル作成時にアプリの追加まで済ませておいてください。
見落とされがちなのが、通知文面の設計です。「新しいフォーム送信があります」だけの通知は、結局リンクを開かないと判断できず、初動が遅れます。通知を見た瞬間に動けるかどうかは、会社名・流入元 (どのフォームか)・確度を推測できる情報 (従業員規模や検討時期など)・次にやるべきアクションの 4 点が本文に入っているかで決まります。ワークフロー通知が使えるプランならパーソナライズトークンでプロパティを埋め込み、使えないプランでも後述のスクリプト通知で同じ形式を再現できます。まず「理想の通知文面」をテキストで確定させておくのが、プランに関係なく効く投資です。
🤖 AI で実行する — 使ったプロンプト / ワークフロー
目的: 見た瞬間に動ける通知文面フォーマットを、イベント別に設計する 所要時間: 15 分 ツール: Claude / ChatGPT
プロンプト:
Slack に流す HubSpot 通知の文面フォーマットを設計してください。
対象イベント:
1. 問い合わせフォーム送信
2. 資料ダウンロードフォーム送信
3. 商談 (取引) のステージ変更
利用できる情報 (HubSpot プロパティ):
- 会社名 / 氏名 / メールアドレス / 従業員規模
- 流入元フォーム名 / 送信日時
- 取引名 / 金額 / ステージ / 担当者
条件:
- 各イベント 3 行以内。1 行目だけで「対応要否」が判断できること。
- 絵文字は行頭の識別用に 1 つだけ (例: 🔥 = 即対応、📄 = 資料DL、💰 = 商談)。
- 最終行に「次のアクション」を 1 つだけ書く形式にすること。
- 個人情報の載せすぎに注意し、パブリックチャンネルに出してよい範囲に絞ること。
出力形式:
イベントごとに、フォーマット定義とサンプル文面 (架空データ) をセットで。
運用 Tips: - 「次のアクション」を書けないイベントは通知から外します。文面設計は通知の削減装置としても機能します。 - パブリックチャンネルに流す場合、メールアドレスや商談金額を出すかはチームで先に合意を取ってください。
4. Starter の壁 — ワークフローの Slack 通知は Professional 限定。回避ルートは 3 つ
「商談ステージが動いたらチャンネルに通知」をワークフローで組むには Professional 以上が必要です。 ただ Starter でも、ユーザー通知の範囲設計・中間ツール・API + Webhook の 3 ルートで実務は回せます。 humbulls は自社 Hub で 3 つ目の API ルートを使っています。
ここまでの標準連携は全プランで使えますが、1 つだけ大きなプランの壁があります。ワークフローの「Slack 通知を送信」アクションと「Slack チャンネルを作成」アクションは、HubSpot の Professional / Enterprise 限定です (HubSpot ナレッジベース、2026-07 確認)。「商談が特定ステージに進んだら、金額と担当者付きで #sales-pipeline に流す」といった条件付きのチャンネル通知は、Starter のフォーム自動化 (最大 10 自動アクション) では組めません。Starter の自動化で何がどこまでできるかは HubSpot ワークフロー活用例 10 選 で整理しているので、本記事では Slack 通知に関わる範囲だけ扱います。
従来この壁に当たったチームの選択肢は「Professional に上げる」か「あきらめて手動共有」の 2 択でした。ただ、通知のためだけのアップグレードは月額コストが大きく跳ねます。実務では、先に次の 3 ルートを検討する方が現実的です。
| 回避ルート | 概要 | 費用 | 向いているチーム |
|---|---|---|---|
| (a) ユーザー通知の範囲で設計 | フォーム送信・タスク・メンションの DM 通知でカバーし、商談はデイリーで手動共有 | 0円 | リード月 10 件以下 |
| (b) 中間ツール (iPaaS) | Zapier 等で HubSpot のイベントを拾って Slack へ投稿 | 無料枠〜月数千円 | ノーコードで完結させたい |
| (c) HubSpot API + Slack Incoming Webhook | 小さなスクリプトで新着レコードを取得し、指定チャンネルに整形投稿 | 0円 (実行環境のみ) | Claude Code 等の AI 開発環境がある |
humbulls の自社 Hub は Starter 運用のため、(c) を採用しています。Slack 側で Incoming Webhook (チャンネルに投稿できる専用 URL) を発行し、HubSpot API で直近のフォーム送信と商談の変化を取得して、3 章で設計した文面フォーマットに整形して POST する。この程度のスクリプトなら、Claude Code に書かせれば初回でも 30 分ほどで動くところまで行けます (humbulls 実測の目安)。定期実行は Mac の cron でも Google Apps Script でも構いません。
注意点が 2 つあります。まず Webhook URL は秘密情報です。URL を知っていれば誰でもそのチャンネルに投稿できるため、コードに直書きして公開リポジトリに上げるのは厳禁です (Slack 公式ドキュメントでも明記されています)。もう 1 つは HubSpot API のレート制限で、Starter は 1 日あたりの呼び出し上限があるため、ポーリング間隔は 5〜10 分程度に抑えるのが安全です。
🤖 AI で実行する — 使ったプロンプト / ワークフロー
目的: Starter プランのまま、商談・フォーム通知のチャンネル投稿スクリプトを作る 所要時間: 30 分 ツール: Claude Code / HubSpot Private App トークン / Slack Incoming Webhook
プロンプト:
HubSpot の新着イベントを Slack に通知するスクリプトを作ってください。
環境:
- 実行: Node.js (ローカル、cron で 10 分おきに実行予定)
- HubSpot: Private App トークンを環境変数 HUBSPOT_TOKEN で渡す
- Slack: Incoming Webhook URL を環境変数 SLACK_WEBHOOK_URL で渡す
やりたいこと:
1. 直近 10 分に作成されたコンタクト (フォーム送信由来) を取得
2. 直近 10 分にステージが変わった取引を取得
3. それぞれ以下のフォーマットで Slack に投稿
(3 章で確定した文面フォーマットをここに貼る)
条件:
- トークンや Webhook URL をコードに直書きしない
- 前回実行分と重複して通知しないよう、最終実行時刻をローカルファイルに保存して差分取得する
- HubSpot API の呼び出しは 1 回の実行で 5 リクエスト以内に収める
- 取得 0 件のときは Slack に何も投稿しない
- 完成したら、テスト用に「直近 24 時間」を対象にした dry-run モードも付ける
運用 Tips: - 最初は dry-run で 24 時間分を流し、文面と件数の肌感を確認してから cron 登録します。 - 「0 件のときは投稿しない」を忘れると、無意味な定時投稿がチャンネルの信頼を下げます。
5. 通知に AI 要約を載せる — 45 分の拡張で「読む通知」を「動ける通知」に
通知は届くようになった。次の課題は「通知を読んで判断する時間」です。 定期実行の Claude Code にリードの要約と推奨アクションを書かせて、通知自体を意思決定の単位にします。 ここが標準連携だけでは到達できない、AI 前提の設計です。
4 章までで、イベントは Slack に届くようになりました。ただ、リードが増えてくると今度は「通知は見たが、どれから対応するか判断する時間がない」という第 2 の詰まりが来ます。1 件ずつ HubSpot を開いて、会社概要を調べて、過去の接点を確認して……という下調べが初動を遅らせるのです。
そこで humbulls では、通知の生成そのものを AI に任せる構成にしています。仕組みは 4 章のスクリプトの拡張です。定期実行時に Claude Code をヘッドレスモード (claude -p、対話なしでプロンプトを 1 回実行して結果を返すモード) で呼び出し、新着リードのプロパティと過去の接点履歴を渡して、「3 行要約 + 推奨ネクストアクション + 優先度」を書かせてから Webhook で投稿します。Claude Code はパイプ連携や定期実行が公式にサポートされているため、この用途に素直にはまります。
たとえば「経営企画室の方が料金資料をダウンロード。従業員 200 名、前回接点は 3 ヶ月前のウェビナー。優先度: 高。推奨: 当時の担当から 24 時間以内にメール」という通知が届けば、受け取った営業はリンクを開く前に動き出せます。さらに MCP (AI とツールをつなぐ接続規格) を使えば、通知から一歩進んで AI に HubSpot を直接操作させることもできます。この構成は MCP で HubSpot を AI から操作する で詳しく解説しています。
ただし、AI 要約には必ず幻覚 (もっともらしい誤り) のリスクがあります。回避策は 2 つ。要約の根拠になるプロパティ値 (会社名・従業員規模・最終接点日) は AI の出力ではなくスクリプト側でそのまま転記すること。そして「推奨アクション」はあくまで提案として扱い、実行の判断は人間に残すことです。通知に「AI 要約」というラベルを付けておくと、チームも出力を鵜呑みにしにくくなります。
🤖 AI で実行する — 使ったプロンプト / ワークフロー
目的: 新着リードの通知に、3 行要約と推奨アクションを自動で載せる 所要時間: 45 分 (4 章のスクリプトがある前提) ツール: Claude Code (ヘッドレスモード) / HubSpot API / Slack Incoming Webhook
4 章のスクリプトで取得した新着リードの JSON を、以下のプロンプトごと claude -p に渡します。返ってきた要約を文面フォーマットに差し込んで Webhook で投稿すれば完成です。
プロンプト (claude -p に渡す本文):
以下の新着リード情報を、Slack 通知用に要約してください。
リード情報 (JSON):
(スクリプトが取得したプロパティと接点履歴を貼る)
出力形式 (この 3 行のみ、前置き不要):
要約: 会社名・部署・何をしたかを 1 行で
背景: 過去の接点と確度のヒントを 1 行で (履歴がなければ「初回接点」)
推奨: 誰が・いつまでに・何をすべきかを 1 行で
条件:
- JSON に存在しない情報を推測で書かない。不明な項目は「不明」と書く。
- 会社の一般情報 (業界の景況など) を勝手に補足しない。
- 優先度を 高/中/低 で行頭に付ける。判断基準: 従業員規模と問い合わせ種別。
運用 Tips: - 「JSON にない情報を書かない」の 1 行が幻覚対策の要です。外すと架空の背景情報が混ざります。 - 運用開始から 1 週間は、要約と元データを人間が突き合わせて精度を確認してから信頼度を上げていきます。
6. 通知過多を防ぐ運用ルール — 全部流すと 3 週間で見なくなる
通知設定は「足す」より「削る」方が難しい。 緊急度でチャンネルを分け、少なく始めて、定期的に監査する。 この 3 つの運用ルールが、連携を形骸化させないための本体です。
最後に、いちばん大事な失敗談を書いておきます。humbulls でも初期は、フォーム送信・商談・タスク・メンションの通知を 1 つのチャンネルにまとめて流していました。結果は想像どおりで、数週間もするとチャンネルは既読スルーの置き場になり、肝心の問い合わせ通知への反応も遅れるようになりました。通知は増やした瞬間がいちばん見られていて、そこから減衰していきます。
回避策として現在は 3 つのルールで運用しています。1 つ目は緊急度によるチャンネル分離です。即対応が必要な問い合わせ通知は専用チャンネルに隔離し、それ以外 (資料 DL、商談の進捗、タスク) は「1 日数回見ればよい」チャンネルへ。緊急チャンネルは通知件数が少ないからこそ、鳴った瞬間に見る文化が保てます。2 つ目は「少なく始めて足す」です。HubSpot の通知設定はチェックボックスを増やすのは簡単ですが、外す判断は「誰かが困るかも」で先送りされがちです。最初はフォーム送信と商談ステージ変更の 2 種類だけで始めて、現場から要望が出たものだけ足していきます。
3 つ目は月 1 回の通知監査です。チャンネルごとの通知件数と、実際に初動につながった件数をざっくり見て、反応されていない通知種別を削るか、レポートに格下げします。ここも AI に任せられる作業で、Slack のログを渡して「削る候補」を挙げさせれば、監査会議は 15 分で終わります。
通知設計・SLA・チャンネル運用まで含めた営業とマーケの連携体制は、1 社ごとに最適解が違います。自社だけで設計しきれない場合は、humbulls の Growth Partner サービス で HubSpot の実装から運用ルールづくりまで伴走していますので、あわせて検討してみてください。
🤖 AI で実行する — 使ったプロンプト / ワークフロー
目的: 月 1 回の通知監査で、削るべき通知をリストアップする 所要時間: 15 分 ツール: Claude / ChatGPT / Slack のエクスポートまたはコピペ
プロンプト:
Slack の通知チャンネルを監査し、削減案を出してください。
入力データ:
- 対象チャンネルと直近 1 ヶ月の通知ログ (コピペで貼る):
- 各通知への反応状況 (リアクション / スレッド返信 / 既読スルー) が分かる範囲で:
- チームの人数と役割:
出力してほしいこと:
1. 通知種別ごとの件数と、反応があった割合の概算
2. 「削除候補」「レポート化候補 (週次まとめに格下げ)」「維持」の 3 分類
3. 分類の理由 (1 行ずつ)
4. 削減後の想定通知件数 (1 日あたり)
条件:
- 「念のため残す」は禁止。維持する通知には「この通知で誰が何をするか」を必ず書くこと。
- 反応ゼロでも、対応漏れ防止の安全網として機能している通知はその旨を明記して維持してよい。
運用 Tips: - ログ全文を貼れない場合は、通知種別と件数のメモだけでも分類は十分機能します。 - 削った通知は記録しておき、四半期後に「削って困ったか」を振り返ると設計精度が上がります。
まとめ: 15 分の標準連携で 8 割、残りは AI で埋める
HubSpot × Slack 連携の要点を整理します。標準連携は全プランで使えて、設定は初回でも 15 分前後。フォーム送信・タスク・メンションは DM、チームで共有すべき商談の動きはチャンネルという 2 レーンで設計します。ワークフローからの条件付き Slack 通知は Professional 限定ですが、Starter でも HubSpot API + Incoming Webhook の小さなスクリプトで実務上は同等の通知が組めます。そして通知が回り始めたら、Claude Code の要約を載せて「読む通知」を「動ける通知」に育て、月 1 回の監査で通知過多を防ぐ。
大がかりな導入プロジェクトは要りません。今日 15 分で標準連携をつなぎ、来週 30 分でスクリプト通知を足す。その積み重ねで、リード放置は仕組みとして消えていきます。
参考文献
- Connect HubSpot and Slack — HubSpot ナレッジベース (取得日: 2026-07)
- Manage notifications in Slack — HubSpot ナレッジベース (取得日: 2026-07)
- Marketing Hub Starter 料金 — HubSpot (取得日: 2026-07)
- Sending messages using incoming webhooks — Slack Docs (取得日: 2026-07)
- Claude Code overview — Anthropic (取得日: 2026-07)
