この構成が向くケース
WordPressフォームの内容をHubSpotへ登録したいが、入力直後に外部CRMへ流したくない場合に向きます。複数の分岐、重複検査、人の承認、将来の通知連携が必要になるとn8nを挟む意味が出ます。
先に確認：フォーム、チャット、コンタクト管理だけなら、HubSpot公式WordPressプラグインだけで足りる可能性があります。n8nを追加すると更新・障害・権限の管理対象も増えます。
外部送信前の7ゲート
- Webhook認証
WordPressとn8nだけが知るHeader Authを使い、無認証の公開Webhookを避ける。 - 入力上限
氏名100文字、メール254文字、会社名150文字、本文2,000文字を上限にする。 - 同意とhoneypot
個人情報の利用同意を必須にし、見えないwebsite欄が埋まっていればbot候補として拒否する。 - 公開応答の最小化
受付番号と一般文だけを返し、メール、氏名、本文をレスポンスや監査イベントへ載せない。 - 重複の扱い
同じ問い合わせを再送しても二重登録しない識別子と更新規則を決める。 - 人の承認
優先度は参考情報に留め、担当者がapproveを選ぶまでCRM payloadを作らない。 - 最小CRM payload
既定ではemail、firstname、company、受付IDだけ。自由記述本文は自動でContactへコピーしない。
保存する情報を先に減らす
問い合わせ本文には、顧客が意図せず機密情報や要配慮情報を書くことがあります。「取れるから保存する」ではなく、目的に必要な項目、保持日数、削除依頼、閲覧権限、バックアップ上の残存を決めます。
公開応答: accepted, ticket_id, generic_message
監査イベント: event, ticket_id, reason_code, priority_hint
レビュー画面: contact, message, consent_recorded
CRM候補: email, firstname, company, source_ticket_id保持日数は導入先の事業・法務条件に合わせて決める必要があり、このサンプルでは UNMEASURED です。本番利用前に導入責任者が決定してください。
失敗しやすい5点
1. 成功実行ログに本文が残る
画面上でCRMへ送っていなくても、n8n実行履歴やエラーログ、バックアップに入力が残る場合があります。候補JSONは成功実行データ保存をnoneにしていますが、実機で必ず再確認します。
2. 承認URLが認証ではない
実行ごとの固有URLは推測しにくくても、担当者本人の認証を保証しません。認証済み管理画面、期限、失効、操作監査が必要です。
3. 自動返信を早く追加する
分類ミスや不適切な内容を第三者へ送る可能性があります。最初は受付完了だけを同期応答し、個別返信は人が確認します。
4. 顧客の認証情報を自分のn8nで預かる
顧客ワークフロー・認証情報の代行ホスティングはn8nのライセンス区分が変わり得ます。読者自身の環境へ導入するテンプレート提供と、代行サービスを混同しません。
5. エラー時だけ個人情報を保存する
成功ログを止めても、エラー保存がallなら失敗入力が残ります。本番では原因調査と最小保存を両立するエラーハンドリングへ置き換えます。
非稼働n8n候補JSON
Header Authの資格情報を含まず、HubSpotの直前で停止します。構造検査済みですが、実n8nへのインポートとノード互換性は未測定です。
候補JSONを見る 安全契約を見る有効化禁止：認証、担当者アクセス、保持・削除、HubSpot最小権限、復旧試験が完了するまで、本番Webhookを有効化しないでください。