HubSpot × Slack 連携 — 商談・フォーム通知を 15 分で設定する
最終更新日: / 公開日:
最終更新日: / 公開日:
本記事のポイント
- HubSpot と Slack の標準連携は無料プランを含む全プランで使えます。インストール 5 分 + 通知振り分け 10 分の計 15 分で、フォーム送信・商談・タスクの通知が Slack に届き始めます
- 「商談ステージが動いたらチャンネルに通知」といったワークフロー通知は Professional 以上が前提です。ただし Starter でも HubSpot API + Slack Incoming Webhook の小さなスクリプトで同等の通知が月額 $0 で組めます
- そのスクリプトに Claude Code の要約を足すと、「会社名・確度・次アクション」まで載った通知になり、受け取った瞬間に動ける状態になります。コードは巻末の一括実行プロンプトで生成できます
「フォームからの問い合わせに気づいたのが翌朝だった」「商談ステージが動いたのを週次ミーティングで初めて知った」。HubSpot を使う BtoB の現場でよく聞く悩みです。原因はプランでも担当者の怠慢でもなく、通知が「チームが常時見ている場所」に届いていないことにあります。本記事では、HubSpot の通知を Slack に集める標準連携の 15 分設定から、Starter の壁を越える自前スクリプト、Claude Code で通知に AI 要約を載せる発展形までを、そのまま再現できる STEP 順に公開します。スクリプトのコードは巻末の一括実行プロンプトで生成できるので、必要なのは「どの通知を・誰に・どこへ届けるか」を決める力だけです。
できあがるもの — 15 分で標準連携、あとは Starter でも AI 通知まで
完成形から見せます。HubSpot のフォーム送信・商談の変化・タスクのリマインドが Slack に流れ込み、チームが管理画面を開かずに初動できる状態を作ります。標準連携だけで 8 割は足り、残りは Starter のまま自前スクリプトと AI 要約で埋めます。
| 項目 | 内容 |
|---|---|
| 標準連携の所要時間 | 約 15 分 (インストール 5 分 + 通知振り分け 10 分) |
| 自前スクリプトの所要時間 | 約 30 分 (Claude Code に生成させた場合の humbulls 実測目安)、AI 要約まで足すと約 45 分 |
| 前提条件 | HubSpot (無料〜Starter 以上) / Slack ワークスペース / (発展形のみ) Claude Code またはブラウザ版 Claude |
| 追加ランニングコスト | 標準連携 $0/月。自前スクリプトも実行環境のみで $0/月 |
私たち humbulls も自社の HubSpot (Starter) を Slack 通知前提で運用しており、フォーム送信や商談の動きは管理画面を開かずに把握しています。以下、STEP 1 から順に進めます。
STEP 1. 通知設計を 10 分で棚卸しする — 何を・誰に・どこへ
「とりあえず全部 Slack に流しておけばいい」。連携の入り口で必ず出る発想ですが、これが最初の落とし穴です。全部流すと数週間で Slack 側が既読スルーの置き場になり、肝心の問い合わせ通知への反応も遅れます。設定に入る前に、どのイベントを・誰に・どこへ届けるかを 10 分だけ棚卸しします。ここで作った設計図が、STEP 2 以降の作業指示書になります。
やることは 3 つです。
- Slack に流す候補イベントを洗い出す (フォーム送信 / 商談の作成・ステージ変更 / タスクの割り当て・期限 / レコードへのメンション / ウェブチャット着信)
- 各イベントを「初動する人が決まっているか」で仕分ける。決まっているものは本人宛の DM、チーム全員で共有すべきものはチャンネル
- 「この通知が来たら誰が何分で動くか」を書けないイベントは、通知ではなくレポートで見る対象として外す
判断基準はシンプルです。1 チャンネルあたり 1 日 10 件を超える通知設計は、その時点で分割か削減のサインです。緊急度の高い問い合わせ通知は専用チャンネルに隔離し、それ以外 (資料 DL、商談の進捗、タスク) は「1 日数回見ればよい」チャンネルに寄せます。緊急チャンネルは件数が少ないからこそ、鳴った瞬間に見る文化が保てます。
つまずきポイントは、通知を「足す」より「削る」ほうが難しいことです。チェックボックスを増やすのは簡単ですが、外す判断は「誰かが困るかも」で先送りされがちです。最初はフォーム送信と商談ステージ変更の 2 種類だけで始めて、現場から要望が出たものだけ足す方針にしておくと、後から通知過多で作り直す手間がなくなります。
→ この棚卸しは巻末の実行キット①の入力にもなります。迷ったら先にキットで下書きを作ってください。
STEP 2. 標準連携を 15 分でつなぐ — インストール 5 分 + 通知振り分け 10 分
「Token とか難しい設定が要るのでは」。身構える方が多いのですが、標準連携は画面をクリックしていくだけで、初回でも 15 分前後で終わります。前提として、HubSpot 側はスーパー管理者または App Marketplace 権限を持つユーザー、Slack 側はワークスペースへのアプリ追加を承認できるユーザーが必要です。少人数チームなら代表や管理者がそのまま両方を満たしていることが多いはずです。
やることは 4 ステップです。
- HubSpot の設定から App Marketplace を開き、Slack を検索してインストールする
- Slack 側の画面で権限を確認して承認する
- HubSpot と Slack のメールアドレスが一致しているか確認する。一致していなければ連携設定でマッピングし、Slack に届く確認メッセージで承認する
- HubSpot の「設定 → 通知 → その他のアプリ」タブで Slack をオンにし、STEP 1 で決めた通知の種類にチェックを入れる
ここまでで、フォーム送信・メンション・タスクのリマインドが Slack に届き始めます。

つまずきポイントは 2 ヵ所です。1 つ目は権限不足で App Marketplace のインストールボタンが押せないケース。2 つ目が、HubSpot と Slack で登録メールアドレスが違っていて、通知の宛先ユーザーとして認識されないケースです。会社ドメインの表記ゆれ (info@ と個人アドレスの混在など) があるチームは、先にどちらかへ揃えておくと早く終わります。もう 1 点、HubSpot に接続できる Slack ワークスペースは 1 つだけという制限があるので、複数ワークスペースを使い分けている会社は「どこにつなぐか」を先に決めてください。UI の文言は更新されることがあるため、画面が違う場合は記事末尾の参考文献から最新の公式手順を確認してください。
STEP 3. DM とチャンネルの 2 レーンに振り分ける — 通知文面の設計込み
「通知は来るようになったが、結局リンクを開かないと何の件か分からない」。標準連携を入れた直後に来る不満がこれです。通知の効きは、宛先の振り分けと文面の 2 つで決まります。
HubSpot の Slack 通知は大きく 2 系統に分かれます。1 つはユーザー通知で、フォーム送信・レコードでのメンション・タスクの割り当てとリマインドが、HubSpot アプリからの DM として本人に届きます。もう 1 つはチャンネル向けの通知で、レコードに関連づけたチャンネルへのアクティビティ共有や、ワークフローからのカスタム通知 (これは STEP 4 のとおりプラン制限があります) がここに入ります。

やることは 2 つです。
- STEP 1 の仕分けに沿って、初動する人が決まっている通知 (フォーム送信の一次対応が営業 1 名など) は DM、チーム全員が知るべき動き (大型商談のステージ進行など) は #lead-alert や #sales-pipeline のようなチャンネルに割り当てる
- 通知文面に「会社名・流入元 (どのフォームか)・確度を推測できる情報 (従業員規模や検討時期)・次にやるべきアクション」の 4 点を必ず入れる形式を、先にテキストで確定させておく
この 4 点が本文に入っていれば、受け取った営業はリンクを開く前に動き出せます。ワークフロー通知が使えるプランならパーソナライズトークンでプロパティを埋め込み、使えないプランでも STEP 4 のスクリプト通知で同じ形式を再現できます。「理想の通知文面」を先に決めておくのは、プランに関係なく効く投資です。
つまずきポイントは、チャンネル通知を受けられるのがパブリックチャンネルか、HubSpot アプリを招待済みのプライベートチャンネルだけという点です。チャンネルを作るときに、アプリの追加まで一緒に済ませておいてください。もう 1 つ、パブリックチャンネルにメールアドレスや商談金額を出すかどうかは、文面を固める段階でチームの合意を取っておくと、後で「この情報は載せたくなかった」という手戻りを防げます。
STEP 4. Starter の壁を回避する — API + Incoming Webhook で自前通知
「商談が特定ステージに進んだら、金額と担当者付きで #sales-pipeline に流したい」。ここで多くの Starter ユーザーの手が止まります。ワークフローの「Slack 通知を送信」「Slack チャンネルを作成」アクションは HubSpot の Professional / Enterprise 限定で (HubSpot ナレッジベース、2026-07 確認)、Starter のフォーム自動化 (最大 10 自動アクション) では条件付きのチャンネル通知は組めないためです。
従来この壁に当たったチームの選択肢は「Professional に上げる」か「あきらめて手動共有」の 2 択でした。ただ、通知のためだけのアップグレードは月額コストが大きく跳ねます。実務では、先に次の 3 ルートを検討する方が現実的です。Starter の自動化で何がどこまでできるかは HubSpot ワークフロー活用例 10 選 で整理しているので、本記事では Slack 通知に関わる範囲だけ扱います。
| 回避ルート | 概要 | 費用 | 向いているチーム |
|---|---|---|---|
| (a) ユーザー通知の範囲で設計 | フォーム送信・タスク・メンションの DM 通知でカバーし、商談はデイリーで手動共有 | 0 円 | リード月 10 件以下 |
| (b) 中間ツール (iPaaS) | Zapier 等で HubSpot のイベントを拾って Slack へ投稿 | 無料枠〜月数千円 | ノーコードで完結させたい |
| (c) HubSpot API + Slack Incoming Webhook | 小さなスクリプトで新着レコードを取得し、指定チャンネルに整形投稿 | 0 円 (実行環境のみ) | Claude Code 等の AI 開発環境がある |
humbulls の自社 Hub は Starter 運用のため、(c) を採用しています。やることは 3 つです。
- Slack 側で Incoming Webhook (チャンネルに投稿できる専用 URL) を発行する
- HubSpot API で直近のフォーム送信と商談の変化を取得し、STEP 3 で決めた文面フォーマットに整形する
- その本文を Webhook に POST するスクリプトを書き、cron や Google Apps Script で 10 分おきに定期実行する
スクリプトの骨格はこの程度です。差分取得と整形投稿だけの小さなコードで、Claude Code に書かせれば初回でも 30 分ほどで動くところまで行けます。
const HUBSPOT_TOKEN = process.env.HUBSPOT_TOKEN;
const SLACK_WEBHOOK_URL = process.env.SLACK_WEBHOOK_URL;
async function notifyNewContacts(sinceIso) {
const res = await fetch('https://api.hubapi.com/crm/v3/objects/contacts/search', {
method: 'POST',
headers: {
Authorization: `Bearer ${HUBSPOT_TOKEN}`,
'Content-Type': 'application/json',
},
body: JSON.stringify({
filterGroups: [{ filters: [{ propertyName: 'createdate', operator: 'GT', value: sinceIso }] }],
properties: ['email', 'firstname', 'lastname', 'company', 'jobtitle'],
limit: 20,
}),
});
const { results } = await res.json();
if (results.length === 0) return; // 0 件なら投稿しない
for (const c of results) {
const p = c.properties;
const text = `🔥 新規フォーム送信\n${p.company ?? '会社名不明'} / ${p.firstname ?? ''} ${p.lastname ?? ''} (${p.jobtitle ?? '役職不明'})\n次アクション: 24 時間以内に一次返信`;
await fetch(SLACK_WEBHOOK_URL, {
method: 'POST',
headers: { 'Content-Type': 'application/json' },
body: JSON.stringify({ text }),
});
}
}
つまずきポイントは 2 つです。1 つ目、Webhook URL は秘密情報です。URL を知っていれば誰でもそのチャンネルに投稿できるため、コードに直書きして公開リポジトリに上げてはいけません (Slack 公式ドキュメントでも明記されています)。上のコードのように環境変数から読み込んでください。2 つ目、HubSpot API のレート制限です。Starter は 1 日あたりの呼び出し上限があるため、ポーリング間隔は 5〜10 分程度に抑え、前回実行時刻を保存して差分だけ取得するのが安全です。
→ この STEP のスクリプトは、次の STEP 5 の AI 要約とまとめて、巻末の実行キット①で一括生成できます。
STEP 5. 通知に AI 要約を載せる — claude -p で「動ける通知」に
「通知は見たが、どれから対応するか判断する時間がない」。リードが増えると来る第 2 の詰まりです。1 件ずつ HubSpot を開いて会社概要を調べ、過去の接点を確認して……という下調べが初動を遅らせます。通知そのものに要約を載せて、届いた瞬間を意思決定の単位にします。
仕組みは STEP 4 のスクリプトの拡張です。定期実行時に Claude Code をヘッドレスモード (claude -p、対話なしでプロンプトを 1 回実行して結果を返すモード) で呼び出し、新着リードのプロパティと過去の接点履歴を渡して、「3 行要約 + 推奨ネクストアクション + 優先度」を書かせてから Webhook で投稿します。Claude Code はパイプ連携や定期実行が公式にサポートされているため、この用途に素直にはまります。

やることは 3 つです。
- STEP 4 のスクリプトで取得した新着リードの JSON を、要約用プロンプトごと
claude -pに渡す - 返ってきた「3 行要約 + 推奨アクション + 優先度」を、STEP 3 の文面フォーマットに差し込む
- その本文を Webhook で投稿する
たとえば「経営企画室の方が料金資料をダウンロード。従業員 200 名、前回接点は 3 ヶ月前のウェビナー。優先度: 高。推奨: 当時の担当から 24 時間以内にメール」という通知が届けば、受け取った営業はリンクを開く前に動き出せます。さらに MCP (AI とツールをつなぐ接続規格) を使えば、通知から一歩進んで AI に HubSpot を直接操作させることもできます。この構成は MCP で HubSpot を AI から操作する で解説しています。
つまずきポイントは、AI 要約に必ずついてまわる幻覚 (もっともらしい誤り) です。回避策は 2 つ。要約の根拠になるプロパティ値 (会社名・従業員規模・最終接点日) は AI の出力ではなくスクリプト側でそのまま転記すること。そして「推奨アクション」はあくまで提案として扱い、実行の判断は人間に残すことです。通知に「AI 要約」というラベルを付けておくと、チームも出力を鵜呑みにしにくくなります。
動作確認 — 何が見えれば成功か
標準連携 (STEP 2) を組んだら、本番と同じフォームからテスト送信して、次の 3 点を確認します。テスト専用フォームだと通知条件の差分に気づけないので、必ず実運用のフォームで行ってください。
- Slack への着信: STEP 1 で DM に割り当てた通知は宛先本人の DM に、チャンネルに割り当てた通知は該当チャンネルに届いている
- 文面の 4 点: 会社名・流入元・確度のヒント・次アクションが本文に載っていて、リンクを開かなくても対応要否が判断できる
- 宛先の一致: DM が想定した担当者に届いている (メールアドレス不一致があるとここでずれる)
自前スクリプト (STEP 4-5) は、まず dry-run モードで「直近 24 時間」を対象に流し、文面と件数の肌感を確認してから cron 登録します。AI 要約付きの場合は、運用開始から 1 週間ほど、要約と元データを人間が突き合わせて精度を確認してから信頼度を上げていきます。この 2 段構えで、いきなり本番チャンネルに誤通知が流れる事故を防げます。
まとめ — 15 分で 8 割、残りは Starter のまま AI で埋める
HubSpot × Slack 連携は、標準連携が全プランで使えて設定は初回でも 15 分前後。フォーム送信・タスク・メンションは DM、チームで共有すべき商談の動きはチャンネルという 2 レーンで設計します。ワークフローからの条件付き通知は Professional 限定ですが、Starter でも HubSpot API + Incoming Webhook の小さなスクリプトで実務上は同等の通知が組め、そこに Claude Code の要約を足せば「読む通知」が「動ける通知」に変わります。
長く回すコツは、通知を増やしすぎないことに尽きます。緊急度でチャンネルを分け、フォーム送信と商談ステージ変更の 2 種類だけで少なく始め、月 1 回 15 分の通知監査で反応されていない通知種別を削るかレポートに格下げする。この 3 つの運用ルールが、連携を形骸化させない本体です。今日 15 分で標準連携をつなぎ、来週 30 分でスクリプト通知を足す。その積み重ねで、リード放置は仕組みとして消えていきます。
通知設計・SLA・チャンネル運用まで含めた営業とマーケの連携体制は、1 社ごとに最適解が違います。自社だけで設計しきれない場合は、humbulls の Growth Partner サービス で HubSpot の実装から運用ルールづくりまで伴走しています。実装テンプレを含む詳細ガイドは BtoB マーケ AI 活用ガイド で配布しているので、あわせてご活用ください。
🤖 AI 実行キット
本文の STEP 4〜5 を、そのまま Claude Code に丸ごと実行させるためのキットです。プロンプトの記入例を自社の値に置き換えて渡してください。標準連携 (STEP 1〜3) は画面操作なのでキット化していませんが、STEP 1 の通知棚卸しに迷ったら、このプロンプトの冒頭に「まず通知設計の表を作ってから」と足せば下書きから始められます。
キット① Starter のまま AI 要約つき Slack 通知スクリプトを一括構築する — 45 分
種別: 実装キット 使うもの: Claude Code (ブラウザ版 Claude でもコードは生成できますが、実行環境への配置は手動になります) 事前に用意するもの: HubSpot の Private App トークン (Settings → Integrations → Private Apps で発行、Contacts / Deals の読み取り scope) / Slack の Incoming Webhook URL / STEP 3 で確定した通知文面フォーマット
プロンプト:
HubSpot の新着イベントを AI 要約つきで Slack に通知するスクリプトを書いてください。
【私の環境】
- 実行: Node.js(ローカル、cron で 10 分おきに実行予定)
- HubSpot: Private App トークンを環境変数 HUBSPOT_TOKEN で渡す
- Slack: Incoming Webhook URL を環境変数 SLACK_WEBHOOK_URL で渡す
- 要約: Claude Code をヘッドレスモード(claude -p)で呼び出す
【通知したいイベントと文面フォーマット(STEP 3 で確定したものを転記)】
1. 問い合わせフォーム送信 → 🔥 で始め、会社名 / 流入元 / 次アクションを 3 行以内
2. 資料ダウンロード → 📄 で始め、同上
3. 取引のステージ変更 → 💰 で始め、取引名 / 金額 / ステージ / 担当者を 3 行以内
(記入例。自社の文面に置き換える)
【必ず守る実装条件(本文の対策を転写)】
1. トークンや Webhook URL はコードに直書きせず、環境変数から読む
2. 前回実行時刻をローカルファイルに保存し、差分(直近 10 分)だけ取得する
3. HubSpot API の呼び出しは 1 回の実行で 5 リクエスト以内に収める
4. 取得 0 件のときは Slack に何も投稿しない
5. 要約は claude -p に渡し、以下の条件を厳守させる:
- JSON に存在しない情報を推測で書かない。不明な項目は「不明」と書く
- 会社名・従業員規模・最終接点日はスクリプト側の値をそのまま転記し、AI 出力で上書きしない
- 優先度を 高/中/低 で行頭に付ける(判断基準: 従業員規模と問い合わせ種別)
- 通知本文に「AI 要約」ラベルを付ける
6. テスト用に「直近 24 時間」を対象にした dry-run モードを付ける
【出力】
- 差分取得関数 + 要約呼び出し + Webhook 投稿 + 最終実行時刻の保存/読み込み
- cron に 10 分間隔で登録する手順を最後にコメントで併記
出力の確認ポイント:
- トークンと Webhook URL が環境変数から読まれ、コードに直書きされていないか
- 「取得 0 件なら投稿しない」の分岐が入っているか (無意味な定時投稿はチャンネルの信頼を下げます)
- 会社名・従業員規模などの事実値が、AI の出力ではなくスクリプト側の値で埋まっているか
- dry-run モードが「直近 24 時間」を対象にできるか
うまくいかないとき:
- HubSpot API が 403 を返す → Private App の scope 不足です。エラーに出る scope 名を追加して再実行してください
- 同じリードが何度も通知される → 最終実行時刻の保存/読み込みが効いていません。ファイルパスと保存タイミングを見直すプロンプトを追記してください
- 要約に実在しない背景情報が混ざる → 「JSON にない情報を書かない」条件が弱いです。プロンプトで最優先条件として明記し直してください
よくあるつまずきの早見表:
| 症状 | 原因 | 対処 |
|---|---|---|
| ワークフローで Slack 通知アクションが出ない | Professional 限定機能 | Starter は API + Incoming Webhook で代替 |
| Webhook URL が漏れて不正投稿 | コードに直書き | 環境変数化 + リポジトリから除外 |
| 通知が重複する | 差分取得が効いていない | 最終実行時刻を保存して GT フィルタ |
| API がレート制限に当たる | ポーリングが速すぎ | 間隔を 5〜10 分に、1 回 5 リクエスト以内 |
| 要約に架空の情報 | 幻覚 | 事実値はスクリプト転記、不明は「不明」 |
参考文献
- 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)