HubSpotで新しい問い合わせが入ったら、Chatworkの営業部屋に即座に通知したい。国内の中堅BtoB企業を支援していると、この手の要望に頻繁に出会います。ChatworkはSlackやTeamsに押されつつも国内の中小・中堅企業の社内コミュニケーションでは依然として現役の基盤であり、HubSpotをCRMとして導入した会社の多くが、次のステップとしてこの2つをつなぎたいと考えます。
目次
ところが調べ始めると、拍子抜けするような事実に行き当たります。HubSpotの公式アプリマーケットプレイスを2026年8月時点で確認したところ、SlackやMicrosoft Teams向けの連携アプリは複数存在するのに対し、Chatwork向けの公式連携アプリは見つかりませんでした。検索してヒットするのは、ZapierやMakeといった中間ツールのコネクタページや個人開発者によるスクリプトの解説記事ばかりです。「公式に無いなら諦める」という判断もありますが、実際には方法がないわけではありません。本稿では、HubSpotとChatworkを連携させる4つの現実解を、制約と実装難易度、向き不向きとともに整理します。
HubSpotの公式アプリマーケットプレイスは、HubSpot自身または外部のパートナー企業が申請・審査を経て掲載するものです。ここにChatwork向けの連携アプリが存在しない理由は、技術的な障壁というより事業判断の結果だと考えられます。Chatworkは日本国内向けに特化したビジネスチャットであり、グローバル展開を前提に開発リソースを配分するHubSpotやサードパーティのアプリ開発会社にとって、優先度の高い連携先にはなりにくいという構造があります。
Chatworkの側にも、外部連携を前提としたオープンな設計を進めにくい事情があります。ChatworkのAPIを利用するには、パーソナルプランを除き組織管理者への利用申請が必要と公式に定められており、誰でも自由にアプリを作って配布できる設計にはなっていません（参照：Chatwork「はじめに（API利用申請）」(2026年8月時点)）。この申請制の仕組みは、サードパーティが連携アプリを開発し公開する動機を弱めます。HubSpot側の優先度の低さとChatwork側の参入障壁の高さが重なり、公式アプリが生まれていないというのが実態に近いと考えられます。次に紹介する4つの現実解は、公式アプリが存在しない前提でそれぞれ異なる層に解決策を作り込むアプローチです。
最初に検討すべきは、HubSpot自体が持つ自動化機能でどこまで届くかです。結論から言うと、HubSpotのワークフローには「Chatworkへ通知する」という専用アクションは存在しません。SlackやMicrosoft Teamsであれば専用アクションが用意されている場合がありますが、Chatworkにはそれがないため、汎用的な仕組みで代替する必要があります。
その汎用的な仕組みが、Webhookアクションです。ワークフローのトリガー条件に合致したタイミングで、外部のアプリケーションへWebhookを送信できる自動化アクションです。ワークフロー自体はMarketing HubやSales HubなどのProfessional以上の契約で使えますが、このWebhookアクションの利用には別途Data Hub（旧Operations Hub）のProfessional以上の契約が必要になる点に注意が必要です（参照：HubSpot「ワークフローアクションを選択する」(2026年8月時点)）。
Webhookアクションは外部のアプリケーションへWebhookを送る機能であって、その内容をChatworkのメッセージ投稿フォーマットに変換してChatwork APIへ橋渡しする処理までは面倒を見てくれません。この変換処理を担うのが、同じくData Hub Professional以上で使えるカスタムコードアクションです。ワークフローの中でJavaScriptのコードを実行でき、Chatwork APIへの橋渡し処理を自動化できます（参照：HubSpot「ワークフローアクションを選択する」(2026年8月時点)）。HubSpotからChatworkへ一方向に通知を送るだけであれば、トリガー設定とカスタムコードアクション数十行程度で完結させることが可能です。
見落としがちなのが、Data Hub Professional以上という契約条件です。Sales Hub StarterやProfessionalだけで運用している会社がこの方法を使うには、Data Hubの契約を追加する必要があり、コスト試算の段階で見落とすと後工程で計画が狂います。
現実解1は「HubSpotからChatworkへ」の一方向でした。逆方向、つまりChatworkでの出来事をHubSpot側で検知したい場合は、Chatwork自身が持つWebhook機能を使います。Chatworkの公式ドキュメントによれば、Webhookはメッセージの送信・編集や自分宛てのメンションをリアルタイムに通知する仕組みで、API管理画面から設定します。ここには重要な制約が3つあります。登録できるWebhookが1アカウント最大5件までという上限、受信側がChatworkからのリクエストであることを検証する署名確認を自前で実装する必要があること、そして受信側は10秒以内にHTTPステータス200を返しレスポンスボディを2,048バイト以下に収めなければならず、配信失敗時も再送は行われないという厳しさです（参照：Chatwork「Webhook」(2026年8月時点)）。つまり常時稼働する受信用サーバーかサーバーレス関数を自前で用意する必要があり、HubSpotのワークフローは外部Webhookをトリガーにできても、Chatworkの署名付きリクエストをそのまま渡せるとは限らず、間に検証と変換を行う中継処理を挟むことになります。
さらに、Chatwork APIの呼び出し回数そのものにも上限があります。全体で5分あたり300回、メッセージ投稿とタスク追加のエンドポイントに限っては10秒あたり10回という、より厳しい制限が設けられています（参照：Chatwork「エンドポイントについて」(2026年8月時点)）。展示会後の一括インポートや大量の商談ステータス変更をまとめて通知しようとすると、この制限に触れてエラーが返る場面が実際にあります。バースト的な通知が起きうる設計では、キューイングや遅延実行を組み込む必要があります。
自前でコードを書きたくない、Data Hubの追加契約までは踏み切れないという会社にとって現実的なのが、ZapierやMakeのようなノーコードの自動化プラットフォームを間に挟む方法です。Zapierの公式インテグレーションページを確認したところ、Chatworkとの連携で用意されているアクションは「Create Room（新しいチャットルームの作成）」「Send Message（特定のグループチャットへのメッセージ投稿）」「Create Task（グループチャットへのタスク追加）」の3つでした（参照：Zapier「HubSpot Chatwork Integration」(2026年8月時点)）。HubSpot側で商談のステージが変わったことをトリガーにこれらのアクションを呼び出し、Chatworkへ通知を投げる構成がコードを書かずに実現できます。Makeでも同様の構成が可能で、考え方は共通です。
実務上重要なのが、Zapierのページに掲載されているのは書き込み系のアクションのみで、Chatworkの新着メッセージを検知してZapを起動するトリガーが見当たらなかった点です。ZapierやMakeでも「HubSpotからChatworkへ」の方向は素直に組めますが、「Chatworkでのやり取りをきっかけにHubSpot側を動かす」逆方向は、現実解2のChatwork自身のWebhookを経由させない限り標準機能だけでは完結しません。中間ツールを使えば双方向が自動的に解決するわけではない点は、導入前に確認しておくべきです。
コスト面では、月額利用料に加えタスク実行数に応じた従量課金が発生する料金体系が一般的です。自社の支援経験に基づく目安としては、月間の通知イベントが数百件規模までならZapierやMakeでの構築が最も着手が早く、エンジニアリソースを持たない会社にも現実的です。条件分岐が複雑になったり月数千件を超える規模になると従量課金が積み上がり、後述のカスタム実装のほうが中長期的に有利になる場合があります。
最後の選択肢が、HubSpotのカスタムコードアクションやプライベートアプリ、独立したサーバーレス関数を使って自社で連携ロジックをすべて書く方法です。現実解1のカスタムコードアクションを使えば、ワークフロー基盤に乗せたままChatwork APIへのメッセージ投稿までを一気通貫で実装できます。複数ルームや代理店ごとに送信先を出し分けたい、メッセージ本文を案件情報に応じて動的に組み立てたいといった、ZapierやMakeの標準アクションでは対応しきれない要件がある場合、この選択肢が最も自由度が高くなります。
一方で、双方向の連携やエラーハンドリングまで自前で作り込むとなると、Chatwork側の署名検証やレスポンス時間の制約、再送がないという仕様への対応、双方のレート制限を踏まえたリトライ設計まで、すべて自社の責任範囲になります。弊社の実装支援経験から言えば、この規模のカスタム実装は片手間で対応できる作業ではなく、要件定義から保守体制まで見据えた小規模なシステム開発案件として扱うべきものです。担当者の退職・異動後に誰も保守できず、通知が止まっていることに数か月気づかなかった事例も珍しくありません。
ここまでの4つを、弊社の支援経験に基づく目安として整理します。着手のしやすさでは、Zapier・Makeによる中間ツール活用が最も早く、数日での構築も可能です。次いでHubSpotワークフローのWebhookアクションとカスタムコードアクションの組み合わせで、Data Hubの契約さえあれば一方向の通知程度は1〜2週間が目安になります。Chatwork側のWebhookを絡めた双方向連携や完全なカスタム実装は、要件次第ですが1か月以上を見込むのが現実的です。
コスト面では、Zapier・Makeは初期費用を抑えられる一方、通知量に応じた月額費用が継続的に発生します。HubSpotのワークフロー活用はData Hub Professional以上の追加契約が前提になるため、すでに契約済みの会社なら追加コストは実質ゼロに近く、未契約の会社にとってはそれ自体が投資判断になります。カスタム実装は初期の開発コストが最も重くなる一方、通知量が増えても従量課金が発生しません。
向き不向きで言えば、通知したいイベントが「特定のステージ変更を特定のルームに通知する」程度であれば、ZapierやMakeで十分です。Data Hub Professional以上を契約済みで通知条件に多少の分岐があるなら、ワークフローとカスタムコードアクションの組み合わせが無理のない選択になります。Chatworkでの返信内容をHubSpot側の案件情報に自動反映させたいといった双方向・高頻度の要件があるなら、最初からカスタム実装を前提に予算と体制を確保しておくべきです。
どの現実解を選ぶにしても、実装に着手する前に整理しておくべき論点があります。まず、Chatworkに流す通知を最初から絞り込んでおくことです。あらゆるイベントを通知対象にすると、Chatworkの部屋が通知で埋め尽くされ、本当に見てほしい情報が埋没する「通知疲れ」を招きます。商談のクローズやSLAを超えた未対応リードの通知など、行動につながる数件に絞って始めるのが定石です。
次に、一方向で足りるのか双方向が本当に必要なのかを見極めることです。HubSpotからChatworkへの一方向であれば難易度は大きく下がりますが、逆方向まで求めるならChatwork自身のWebhookの制約を踏まえた設計が必須になり工数は一段階上がります。最後に、誰がこの連携を保守するのかを決めておくことです。API仕様変更で連携が突然止まるリスクは常にあり、担当者の異動・退職を前提に設定内容とAPIトークンの管理場所をドキュメント化しておくことが、後々のトラブルを防ぎます。ワークフローの組み方の基本は、姉妹記事の「HubSpotワークフローの作り方、最初の1本でつまずかない基本手順」で詳しく解説しています。
HubSpotとChatworkの連携は、公式アプリがない分、自社の通知設計や運用体制に合わせて選択肢を組み合わせる余地が大きい領域です。どの現実解が合うか、契約プランや通知イベントを踏まえて相談したい方は、無料相談からお気軽にお問い合わせください。