HubSpotでは、コンタクトや会社などのオブジェクトに対して、複数行テキストのプロパティを作成できます。
例えば、次のような用途で使われることが多いはずです。
- 問い合わせフォームの「問い合わせ内容」
- アンケートの自由記述
- インサイドセールスから営業への引き継ぎコメント など
入力画面上では、当然ながら改行を含んだメモとして保存されます。
ところが、このプロパティを内部通知メール本文に差し込むと、こんな問題が起こります。
- メール上では改行がすべて消え、1行に詰まって表示されてしまう
- 長文のメモほど、非常に読みづらくなる
- 営業側・受信側から「読みにくい」「どこが区切りかわからない」とフィードバックが出る
テキストエディタではきれいに段落分けされているのに、メールでは一続きの文章に見えてしまう――。
このギャップが、現場のストレス要因になりがちです。
一体なぜ？
技術的な細かい話は省きますが、ざっくりいうと次のような仕組みです。
- メールのHTMLでは、改行や連続スペースは「1つのスペース」として扱われやすい
- HubSpotのリッチテキストモジュールも、標準状態ではその挙動に沿ってレンダリングされる
そのため、複数行プロパティの「見た目の改行」が、HTML上のスペースとしてまとめられてしまい、
結果としてメール上では改行がなくなったように見えます。
よくある解決案と、その課題
この問題に対して、よく検討される案を先に整理しておきます。
1. HTMLモジュール＋パーソナライズトークンで頑張る案
- HTMLモジュールの中で
<pre> や white-space を指定すれば解決できそうに見える - 実際には「HTMLモジュールではパーソナライズトークンが利用できない」という制約がある
そのため、
「技術的には分かっているのに、HubSpotの仕様上その書き方ができない」
という行き詰まり方をしがちです。
2. ワークフロー＋カスタムコードでプロパティを加工する案
- ワークフローで複数行プロパティを受け取り、改行コードを
<br> に置換して別プロパティへ保存する - メール側では、その「加工済みプロパティ」を差し込む
メリット
- 表示内容を細かく制御できる
- 他の用途（レポートなど）にも流用しやすい場合がある
デメリット／ハードル
- Operations Hub（カスタムコードアクション）が必要になることが多い
- 既存ワークフローへの影響や、管理すべきプロパティ数が増え、運用負荷が上がる
- メール編集だけで完結しないため、運用担当者だけで対処しづらい
今回のケースでは、これらの理由から「現実的ではない」と判断した前提とします。
3. プロパティを行ごとに分割する案
- 「行1」「行2」「行3」…といった形で、フィールド自体を複数用意する
- メールではそれぞれのプロパティを別行に差し込む
メリット
- 仕組みがシンプルで分かりやすい
- HubSpotの標準機能だけで実現可能
デメリット
- 入力側の負担が増える（毎回プロパティを複数埋める必要がある）
- 行数が可変なメモには対応しづらい（「4行以上の場合どうする？」という問題）
- 既に複数行プロパティを運用している場合、移行コストがかかる
今回採用した解決策：リッチテキスト内の「preブロック」を使う
上記の案を検討した結果、よりシンプルで運用しやすい方法として採用したのが、
リッチテキストモジュール内で「pre（整形済みテキスト）」スタイルを使う
という方法です。
preブロックとは何か
<pre> タグ（preformatted text）は、元のテキストの改行やスペースを「そのまま表示する」ためのHTML要素です。
- 通常のテキスト：
- 改行や連続スペースは 1つのスペースとしてまとめられる
<pre> 内のテキスト：
CSSでいうと white-space: pre; に近い挙動になります。
この性質を利用すると、複数行プロパティの改行をほぼそのままメール上で再現できます。
HubSpotのリッチテキストでpreが使えた
HubSpotのメールエディタでは、リッチテキストモジュール内でテキストのスタイルを選択できます。
通常は「段落」「見出し」などしか使わないかもしれませんが、環境によってはこの中に
といった選択肢が含まれていることがあります。
この「preスタイル」を、複数行プロパティを差し込んだテキストに適用することで、
HTMLモジュールもカスタムコードも使わずに、改行を維持した表示が実現できました。
手順：HubSpotメールでpreブロックを設定する流れ
実際の設定手順を、できるだけシンプルに整理します。
1. メールテンプレートの編集画面を開く
- HubSpotのメインメニューから「マーケティング」→「Eメール」を選択
- 対象となるメール（またはテンプレート）を選び、「編集」をクリック
2. リッチテキストモジュールを追加／選択する
- 本文中で、複数行プロパティを差し込みたい位置にリッチテキストモジュールを配置
- 既にあるテキストブロックを流用する場合は、そのブロックを選択する
3. 複数行プロパティのパーソナライズトークンを挿入
- リッチテキストモジュール内でカーソルを置く
- 「パーソナライズ」ボタン（もしくは「パーソナライズトークン挿入」）をクリック
- 該当の複数行プロパティ（例：商談メモ）を選択して、本文に差し込む
エディタ上には、例として
{{ contact.商談メモ }}
のような形でトークンが表示されます。
4. 差し込んだトークンに「pre」スタイルを適用
- 差し込んだトークン全体をドラッグして選択
- エディタのスタイルメニュー（段落／見出しを選ぶプルダウン）を開く
- 一覧の中から「pre」または「整形済みテキスト」に相当する項目を選択
※環境によっては英語表記（Preformatted など）になっている場合があります。
5. プレビュー／テスト送信で表示を確認
- 右上の「プレビュー」または「テスト送信」機能を使い、実際のメール表示を確認する
- 対象コンタクトを指定してテスト送信し、複数行プロパティに改行が含まれる状態でテストする
- 受信したメールで、メモの改行がそのまま再現されているかをチェック
問題なく表示されていれば、このテンプレートを本番配信に利用できます。
preブロックを使うメリットとデメリット
メリット
- 改行がそのまま維持される
- 元のメモと同じ改行位置でメールに表示されるため、情報が読み取りやすい
- 営業側も「メモのどこまでが1つのトピックか」理解しやすくなる
- テンプレート編集だけで対応できる
- HTMLモジュールやカスタムコードを追加する必要がない
- ワークフローの改修や、新しいプロパティ設計も不要
- 既存運用への影響が小さい
- 複数行プロパティの構造を変えずに済む
- 既に入力されているメモも、そのまま活かせる
デメリット・注意点
- 等幅フォントになる場合が多い
- preスタイルは、環境によって等幅フォントで表示されることがある
- メール全体の雰囲気と少し異なる印象になる可能性がある
- 折り返しの挙動が通常テキストと違う場合がある
- 文面の長さや画面幅によっては、横スクロールが出たり不自然な折り返しになるケースもある
- 特に長文メモが入りやすいプロパティでは、事前テストが重要
- 使いどころを限定しないとレイアウトが崩れたように見える
- 本文全体をpreにしてしまうと、デザイン性が損なわれる
- あくまで「メモ部分」「ログ部分」など、範囲を絞って適用するのが現実的
実運用でのポイントとルール化のすすめ
preブロックは便利ですが、運用ルールなしに使うと、いつの間にか元に戻されてしまったり、
想定外の場所で使われてレイアウトが崩れるリスクがあります。以下の観点で整理しておくと安全です。
1. preを使う箇所を明確に決める
- 例：
- 「インサイドセールス → 営業引き継ぎ」のメモ部分
- 「コールログの要点」のみ
- それ以外の文章は通常の段落スタイルを使う
これをテンプレート名・説明欄・社内ドキュメントに明記しておきます。
2. 編集時の注意事項をテンプレート内にメモしておく
- エディタ上のコメントや、テンプレートの説明欄に
- 「このブロックのトークンはpreスタイルにしておくこと」
- 「スタイルを変更すると改行が潰れるため注意」
といったメモを残しておく
後からテンプレートを触るメンバーにも意図が伝わりやすくなります。
3. 大量配信前のテストフローに「改行確認」を含める
- 通常の件名・リンク確認に加えて、
- 「複数行プロパティの改行が正しく表示されているか」をチェック項目に追加
- 特にテンプレートを修正した直後は、必ずテスト送信で確認する
まとめ：ツールの制約の中でも「現実解」を探す
複数行プロパティの改行が潰れてしまう問題は、
一見すると「仕様だから仕方ない」と片付けられがちです。
しかし実際には、
といった条件を一つずつ洗い出し、その中で「UI上から選べるスタイル」を組み合わせることで、
今回のように テンプレート編集だけで実務上十分な解決策 を見つけられるケースがあります。
もし同じような課題に直面している場合は、まずは一度、
リッチテキストモジュールのスタイルメニューに「pre」や「整形済みテキスト」がないか確認してみてください。
- 利用可能であれば、本記事の手順で簡単にテストできます
- 利用できない場合でも、「どの制約で止まっているのか」をチーム内で共有することで、
別の解決案（ワークフローやプロパティ設計の見直し）へと議論を進めやすくなります
エディタの制約に振り回されるのではなく、
その制約を踏まえたうえで「現場が使える形」に落とし込んでいくことが、
マーケ／インサイドセールスの運用改善では重要だと感じています。
