ウェビナーが終わった翌日、マーケティング担当者がやっていることはだいたい同じです。配信ツールから参加者CSVを落とし、申込者CSVと突き合わせ、参加した人としなかった人に分け、営業に渡すリストをExcelで作る。この作業は1回あたり数時間で済みますが、月に2本開催していれば年に24回発生します。しかも、その成果物はCRMの外に置かれたまま残りません。

半年後に「去年のウェビナーに3回以上参加している企業はどこか」と聞かれたとき、答えられる組織は多くありません。CSVを突き合わせて作ったリストは、作った本人のフォルダの中にあるからです。株式会社100はHubSpotの認定エリートパートナーとして、こうしたイベント運用をCRMの中に載せ替える支援をしています。

HubSpotには、この用途のためにマーケティングイベントという専用のオブジェクトが用意されています。この記事では、マーケティングイベントで何が記録され、申込から参加・フォローアップ・商談化までをどう設計するかを整理します。Zoomとの接続手順そのものはHubSpotとZoomの連携で扱っているため、本記事はイベントオブジェクトの設計に軸を置きます。

マーケティングイベントは、何を記録するオブジェクトなのか？

「ウェビナーの参加者をHubSpotに入れる」と言ったとき、入れ先の候補は複数あります。コンタクトのプロパティにチェックを付ける、リストに入れる、カスタムオブジェクトを作る。マーケティングイベントは、この選択肢のうち標準で用意されている専用の器です。まず何が入るのかを確認します。

マーケティングイベントはイベントの概要を1か所で把握するための機能で、全プロダクト・全プランで利用できます。ただし機能ごとに条件が異なり、ワークフローでの登録にはProfessional以上、キャンペーンへの紐づけにはMarketing Hub Professional以上、アトリビューションレポートにはMarketing Hub Enterpriseが必要とされています。

標準プロパティには、何が用意されているのか？

器の中身を知らないまま運用設計を始めると、後から「その項目は持てません」という話になります。既定で用意されているプロパティを押さえておきます。

私たちがクライアントのイベント運用を設計するときは、TypeとOwnerの2つを最初に決めます。この2つを空欄のまま運用を始めた組織は、1年後に「部門別・形式別の参加実績」を出そうとして手詰まりになります。プロパティの統制についてはマーケティングイベントのプロパティ標準化も併せてご確認ください。

参加ステータスは何種類あり、どこに記録されるのか？

出欠の管理は、コンタクト側のプロパティではなくイベントとの関係として記録されます。開発者ドキュメントでは、参加状態として REGISTERED（登録済み）、ATTENDED（参加）、CANCELLED（キャンセル）、NO_SHOW（登録したが不参加）が定義されています（Marketing events API guide）。

コンタクトレコード側では、マーケティングイベントのカードにイベント名・タイプ・ステータス・登録日・参加日・キャンセル日・開催日が表示されます（View marketing events on contacts）。過去と今後の両方のイベントが並ぶため、営業が商談前にこの画面を開けば、相手が何に興味を示してきたかが時系列で見えます。

この構造の利点は、コンタクト側にイベントごとのカスタムプロパティを増やさずに済むことです。ウェビナーを開催するたびに「○○ウェビナー参加」というチェックボックスを増やしていく運用は、半年でプロパティ一覧が破綻します。HubSpotのプロパティ設計の観点でも、関係として持てるものをプロパティにしない判断が重要です。

コンタクトは、どうやってイベントに紐づくのか？

ここに明確な制約があります。コンタクトレコードから手動でマーケティングイベントに関連付けることはできません。紐づけの経路は3つに限られます。インポート、ワークフローの「Add participant to marketing event」アクション、そしてZoom・Microsoft Teams webinars・GoToWebinar・Eventbriteといった連携アプリ経由の参加ステータス変更です。

この制約は運用設計に直結します。オフラインのセミナーで紙の名簿を回収した場合、担当者が画面から1件ずつ追加することはできず、インポートかワークフローのどちらかを通す必要があります。インポートの運用ルールを先に整えておかないと、イベントのたびに属人的な作業が発生します。

なお、ワークフローの「Add participant to marketing event」アクションは手動で作成したイベントにのみ使え、連携経由で生成されたイベントには使えません。手動作成と連携作成を混在させる運用では、この違いが設計の分岐点になります。

イベントは、何通りの方法で作れるのか？

作り方によって、後から変更できる範囲と自動化できる範囲が変わります。開催形式が複数ある組織では、どの形式をどの作り方に割り当てるかを先に決めておくと、運用が安定します。

手動で作る場合、何を決めてから作るか？

Marketing配下のイベント画面から作成する方法が基本です。Marketing Hub ProfessionalまたはEnterpriseをご利用の場合は、Marketing Studioのキャンバス上からマーケティングイベントを作成・追加することもできます（Create and add marketing events in Marketing Studio）。キャンペーンの構成要素として扱えるため、施策全体の中での位置づけが明確になります。

作る前に決めるのは、名前の付け方です。私たちがクライアントと決める命名規則は「開催日_形式_テーマ_共催先」の順で、検索と並び替えが同時に効く形にしています。命名規則がないと、同じテーマの再演が3回あったときに、どれがどれか分からなくなります。

ウェビナーツールと連携すると、何が自動で同期されるのか？

Zoom、Microsoft Teams webinars、GoToWebinar、Eventbriteのいずれかを接続している場合、ウェビナーのイベントがマーケティングイベントとして自動的に同期されます。手動で作る必要はありません。

同期の内容と間隔は、ツールによって差があります。たとえばGoToWebinarでは、登録者データはリアルタイムで、参加者データはウェビナー終了の15分後にHubSpotへ追加されると記載されています（Use HubSpot's integration with GoToWebinar）。終了直後にフォローアップメールを送るワークフローを組む場合、この遅延を見込んだ待機時間が必要です。

Microsoft Teams webinarsでは、同期されたウェビナーが登録者数・参加者数・キャンセル数・イベント名・日付・開始終了時刻・主催者・ステータス・説明を含むマーケティングイベントとして作成されます（Use HubSpot and Microsoft Teams webinars）。Eventbriteの場合はイベント画像も同期対象になります（Use HubSpot's integration with Eventbrite）。

APIで作る場合、何を設計しておくのか？

自社の申込システムや外部のイベントプラットフォームから流し込む場合は、Marketing Events APIを使います。設計で最初に決めるのは externalEventId と externalAccountId の採番ルールです。この2つが外部システム側のイベントとHubSpot側のイベントを結ぶキーになります。

開発者ドキュメントには、イベントの作成・更新・削除のほか、参加状態を更新するエンドポイントが整理されています。コンタクトIDで更新する経路とメールアドレスで更新する経路の両方が用意されており、外部システムがHubSpotのIDを保持していない場合でも連携できます。一覧取得の limit は既定値が10で、指定できる範囲は1から100と記載されています。

私たちがAPI連携を設計する際は、参加状態の更新を冪等に組むことを必須条件にしています。再送や再実行で二重に記録されない構造にしておかないと、参加者数が実態とずれ、レポートの信頼性が落ちます。

申込フォームは、どう設計するのが安全か？

申込フォームは、イベント運用で最も事故が起きやすい場所です。取りたい情報を増やすほど申込率が下がるという一般論ではなく、連携の仕様上、増やすと登録そのものが失敗するという実務上の制約があります。

連携が受け付ける項目は、なぜ限られているのか？

Zoom連携が受け付けて同期する必須項目は、First name・Last name・Emailの3つだけです。他の必須項目を追加すると登録が失敗するおそれがあります。Microsoft Teams webinarsでも同様に、必須項目は3つに限られ、追加すると失敗の原因になります。

つまり「役職」「部門」「課題」を必須にした申込フォームをそのままウェビナー登録に連動させると、登録が通らない事態が起きます。設計の答えは単純で、連携に渡す必須項目は3つに固定し、それ以外は任意項目として収集することです。

フォーム自体の作り方は公式ナレッジベースのCreate formsに整理されています。社内の設計基準はHubSpotのフォームにまとめています。

申込時に取りたい情報は、どこに持たせるか？

必須にできないからといって、情報を諦める必要はありません。持たせ方を変えます。

1. 任意項目として同じフォームに置く — 入力率は下がるが、申込の失敗は起きない
2. サンキューページで追加入力を促す — 申込完了後なので離脱の影響が小さい
3. 既存コンタクトはプログレッシブに聞く — 既に持っている項目を再入力させない
4. 当日のアンケートで取る — 参加者に限定されるが、回答の質が高い

どれを選ぶかは、その情報を誰がいつ使うかで決まります。営業が初回接触の前に見る情報なら申込時、ナーチャリングの分岐に使う情報なら当日以降でも間に合います。使う時点から逆算せずに項目を増やすと、入力率だけが下がります。

重複申込と表記ゆれを、どう防ぐか？

同一人物が別のメールアドレスで申し込むケースは必ず発生します。HubSpotはコンタクトをEメールアドレスで重複排除するため、個人用アドレスと会社用アドレスの使い分けは別レコードとして入ります。

完全には防げませんが、入口で減らすことはできます。プロパティに検証ルールを設定して前後の空白や全角英数字を弾く、会社名を自由記述ではなく企業レコードとの関連付けで持つ、といった対策です（Set validation rules for a property）。オフライン名簿をインポートする場合は、ファイルの形式要件も確認してください（Format import files）。

リマインドとフォローアップは、どこで組むのか？

イベント運用の自動化は、ワークフローに集約します。ただし起点の選び方を間違えると、連携の同期タイミングに引きずられて配信が前後します。起点ごとの特徴を整理します。

ワークフローの起点を、何にするか？

選択肢は3つあります。フォーム送信を起点にする方法、マーケティングイベントの参加ステータスを起点にする方法、イベントの開催日プロパティを基準に日付で動かす方法です。

利用できるアクションと必要なサブスクリプションは公式ナレッジベースに一覧化されています（Choose your workflow actions）。日付を基準にした待機には、カレンダー日付・日付プロパティ・曜日・時刻といった指定方法が用意されています。ワークフロー設計の基本はHubSpotのワークフローに整理しています。

出欠で分岐させる設計は、どう組むか？

参加した人と欠席した人に同じメールを送る運用は、機会損失です。ステータスで分岐させると、文面も次のアクションも変えられます。

私たちが標準として置いている分岐は4つです。参加者には録画と資料、そして個別相談への導線。欠席者には録画のみと次回案内。キャンセル者には次回案内のみ。申込なしで資料請求だけした層には、別のナーチャリングへ。この4分岐を作っておくと、イベントごとの作業がテンプレートの複製で済みます。

セグメントは、アクティブなものと静的なものを使い分けます（Create active or static lists）。イベント単位の参加者名簿は静的、「直近12か月で2回以上参加」のような横断条件はアクティブにすると、運用が崩れません。

当日の欠席者を、どう扱うか？

欠席者は失敗ではなく、関心を示した見込み客です。NO_SHOW として記録されているため、参加者とは別の導線を設計できます。

実務で効くのは、欠席理由を推定して文面を変えることではなく、録画の視聴行動を次の起点にすることです。録画を最後まで見た欠席者は、途中で離脱した参加者より関心が高い場合があります。視聴行動を記録したい場合は、カスタムイベントを定義する方法があります（Create custom events）。Professional以上で利用でき、1回のイベント発生につき最大50個のプロパティ、プロパティ値はURL・参照元で1024文字、その他は256文字という上限が記載されています。

イベントから商談につなげるには、何を設定するのか？

イベント運用の評価が「参加者数」で止まる組織は多くあります。止まる理由は、商談への接続を測る設定が既定では有効になっていないことです。ここを設定するだけで、議論の質が変わります。

キャンペーンに紐づけると、何が見えるのか？

マーケティングイベントはキャンペーンに関連付けられる資産として掲載されています（Associate assets and content with a campaign）。連携由来のイベントはキャンペーンツール側からのみ関連付けできる、という条件が付きます。

紐づけると、イベント単体ではなく施策全体として実績を見られます。告知メール、ランディングページ、広告、イベント本体を1つのキャンペーンにまとめると、どの入口から申込が来たかが1画面で分かります（Analyze individual campaign performance）。

アトリビューションで、イベントの貢献をどう測るか？

ここが最も見落とされる設定です。アトリビューションレポートの相互作用タイプには「Attended marketing event」と「Registered for a marketing event」が用意されていますが、いずれも既定ではオフになっています（Select interaction types for your attribution reports）。

オフのままレポートを作ると、ウェビナー経由で生まれた商談がイベントの貢献として計上されません。「ウェビナーは数字に出ない」という社内評価の相当部分は、この設定が原因です。設定を有効にしたうえで、コンタクト作成・取引作成・収益のどのアトリビューションを見るかを決めてください（Create attribution reports）。取引作成と収益のアトリビューションはMarketing Hub Enterpriseが対象です。

商談化率を、どう定義するか？

測定の前に定義を決めます。分母を申込者にするか参加者にするか、分子を商談化にするか受注にするか、計測期間を何日にするか。この3つを決めずに数字を出すと、部門ごとに別の数字が出てきます。

私たちが推奨する既定は、分母を参加者、分子をイベント後90日以内に作成された取引、としたうえで、申込者ベースの数字も併記する形です。参加率が低いイベントを「参加者ベースでは優秀」と見せてしまう問題を避けられます。収益側の集計方法は公式ナレッジベースのReport on revenue in HubSpotに整理されており、レポートの作り方はCreate custom reportsにまとまっています。ダッシュボードの考え方はHubSpotのレポートとダッシュボードをご確認ください。

連携先ツールごとに、何がどう違うのか？

どのウェビナーツールを使うかで、設計できる範囲が変わります。ツールの優劣ではなく、HubSpot側から見たときの接続点の違いとして整理します。公開されている公式ドキュメントの記述に基づく比較です。

選定で効くのは、ワークフローから自動登録できるかどうかです。ナーチャリングの流れの中で「興味を示した人を自動でウェビナーに登録する」設計を取りたい場合、この対応可否が分岐になります。

標準機能で足りるのか、専用ツールが要るのか？

イベント管理の専用ツールを併用すべきかどうかは、必ず議論になります。公正に整理すると、分かれ目は参加者数ではなく、イベントの複雑さです。

私たちが判断基準にしているのは、「1人の参加者が同じイベント内で複数のセッションを選ぶか」です。選ぶ構造があるなら専用ツール、1イベント1参加の構造ならHubSpot標準で足ります。参加者数の多寡は、この判断にほとんど影響しません。

運用を始める前に、何を決めておくべきか？

設定そのものは1日で終わります。終わらないのは運用ルールの合意です。イベントを定常開催する前に、次の5点を決めておいてください。

1. イベント名の命名規則 — 開催日・形式・テーマ・共催先の順序を固定する
2. Typeの選択肢 — ウェビナー／セミナー／展示会／社外イベント。自由入力にしない
3. Ownerの付け方 — 主催部門の誰かを必ず入れる。空欄を許容しない
4. 参加の定義 — 何分以上の滞在を参加とみなすか。連携側の判定と整合させる
5. フォローアップの期限 — 参加者への初回接触を何営業日以内に行うか

4つ目は特に揉めます。ツール側が入室だけで参加と判定する場合、HubSpot側の参加者数は実感より多くなります。営業に渡すリストの基準を別に持つのか、ツール側の設定を変えるのかを、運用開始前に決めてください。

マーケティングイベントもCRMのオブジェクトの一種です。どの単位をレコードとして持つかという設計の考え方は、公式ナレッジベースのHow to use objects for business processesに整理されています。権限の設計も忘れずに確認してください（HubSpot user permissions guide）。データの持ち方を1か所に揃える考え方はSSOT（信頼できる唯一の情報源）に、イベントを含むリード獲得全体の設計はBtoBリード獲得の統合設計にまとめています。

よくある質問

コンタクトのレコードから、手動でイベントに追加することはできますか？

できません。コンタクトレコードから手動で関連付けることはできません。紐づけの経路はインポート、ワークフローの「Add participant to marketing event」アクション、連携アプリ経由の3つです。オフラインの名簿を取り込む場合はインポートを使ってください。

過去に開催したウェビナーの参加履歴を、後から取り込めますか？

インポートで取り込めます。手動で作成したマーケティングイベントにも、参加者リストをインポートできます。既存のCSVが残っている場合は、イベント単位で遡って取り込み、過去の参加履歴をCRMの中に置き直すことができます。ただしメールアドレスが変わっている相手は別レコードになる点にご注意ください。

ウェビナーは数字に出ないと社内で言われます。どう反論すべきですか？

反論の前に、アトリビューションの設定をご確認ください。マーケティングイベントの相互作用タイプは既定でオフのため、設定していなければレポート上は貢献ゼロになります。設定を有効にしたうえで数字を出し直すと、議論の前提が変わります。これは運用の問題ではなく設定の問題です。

マーケティングイベントは、取引オブジェクトと直接関連付けられますか？

取引レコードとマーケティングイベントを直接関連付ける機能についての記載は、公式ナレッジベースで確認できませんでした。商談への接続はコンタクト経由となり、評価はアトリビューションレポートとキャンペーンのパフォーマンスで行う設計になります。取引側でイベントを参照したい場合は、取引プロパティに流入施策を持たせる方法を検討してください。

イベントごとにコンタクトのプロパティを作るのと、何が違いますか？

マーケティングイベントを使うと、イベントが増えてもプロパティは増えません。参加・欠席・キャンセルという状態も標準で表現されます。プロパティで管理する方式は、イベント数が一桁のうちは問題になりませんが、年間20本を超えたあたりからプロパティ一覧とセグメント条件の保守が追いつかなくなります。

申込フォームに役職や課題を必須項目として入れたいのですが、問題ありますか？

ウェビナーツールと連携する場合は問題になります。Zoom連携は姓・名・メールアドレスの3項目のみを受け付けると記載されており、他の必須項目を追加すると登録が失敗するおそれがあります。Microsoft Teams webinarsでも同様です。必須は3項目に固定し、それ以外は任意項目として収集してください。

複数のウェビナーツールを併用している場合、どう管理すればよいですか？

マーケティングイベント側で統合されるため、オブジェクトとしては1つの一覧で見られます。ただしTypeやOwnerの入り方がツールごとに異なるため、レポートの軸にする項目については手動で補正するか、ワークフローで既定値を入れる運用を決めてください。レコードソースのプロパティで、どの経路で作られたイベントかを判別できます。

イベント運用をHubSpotに移すのに、どれくらいの期間が必要ですか？

設定と連携だけなら数日です。時間がかかるのは、Typeの選択肢・参加の定義・フォローアップの期限といった運用ルールの合意です。当社が支援する場合も、最初の1本を既存のやり方と並行で走らせ、2本目から完全移行する進め方を取ります。並行期間を設けないと、当日のトラブル対応ができなくなります。

まとめ：イベント管理の設計で、最初に決めるべきことは何か？

この記事の内容を、着手順に整理します。

1. 紐づけの経路が3つに限られることを前提に設計する — インポート、ワークフロー、連携アプリ。手動関連付けはできない
2. 申込フォームの必須項目は3つに固定する — 連携の制約であり、申込率の問題ではない
3. TypeとOwnerを空欄にしない — 1年後のレポートはこの2項目で割る
4. アトリビューションの相互作用タイプを有効にする — 既定ではオフ。設定しない限り貢献は見えない
5. 参加の定義を運用開始前に決める — ツール側の判定と社内の基準を一致させる

ウェビナーが数字にならない組織と、商談の起点になっている組織の差は、集客力ではありません。参加の記録がCRMの中にあるか、担当者のExcelの中にあるかの差です。記録の置き場所を変えるだけで、半年後に答えられる問いの数が変わります。

株式会社100は、世界上位1%・日本唯一のHubSpot認定エリートパートナーとして、イベント運用の設計から商談化までの導線づくりを支援しています。自社の運用をどこから移すべきか具体的にご相談がある場合は、お問い合わせからご連絡ください。

最終更新日: 2026年10月23日（本記事の記載は同日時点の公式ドキュメントに基づきます。仕様・上限・提供条件は変更される可能性があるため、実装前に一次情報をご確認ください）