営業企画や経理の担当者から、スプレッドシートを1枚渡されることがあります。
商材ごと、数量ごと、契約プランごとに月額が違う。年度によって金額が改定されている。前払いならさらに割引がある。そういう条件表です。手作業で金額を計算しているので自動化したい、という依頼です。
ワークフローで組もうとして、最初の分岐を作ったところで気づきます。
条件が5つあると、組み合わせは掛け算で増えます。商材2種類、数量11段階、割引プラン2種類、契約年度2種類、前払いの有無で、176通り。分岐で表現するなら、176本の枝が必要です。
さらに厳しいのは、その後です。
「HubSpotでは無理そうなので、当面は手計算で」という結論になりがちな領域です。
ただ、これは作り方を変えると解決します。ワークフローの分岐は1本も使いません。
理由は、条件の数と分岐の数が比例していないことです。
条件が1つ増えるだけで、分岐は掛け算で増えます。上の例で割引プランをもう1種類（A・B・C）追加すると、88通りは132通りになります。増えるのは条件1つですが、作業量は44本の枝です。
そして分岐は、次の3点で保守に向きません。
条件表そのものは、営業企画が普段Excelで更新しています。その表を更新する行為が、そのままHubSpotに反映される形にできれば、この3点はすべて解消します。
やることは1つです。
条件表の1行を、HubSpotの1レコードにします。
「商材が定期便A、数量130、割引プランB、契約年度2026、前払いあり → 月額36,000円」という1行を、カスタムオブジェクトのレコードとして登録します。88通りなら88レコードです。
そして条件を1本の文字列（キー）にまとめます。
定期便A_130_B_2026_前払あり
親レコード（取引や契約など）の側でも同じ形式のキーを組み立てておけば、文字列が一致するマスタレコードを探して、その金額を持ってくるだけで済みます。
ワークフローの中身は2つのアクションだけです。
1. キーが一致するマスタレコードを関連付ける 2. そのマスタレコードの金額をコピーする 分岐はゼロです。条件が何通りあっても変わりません。
「88レコードは多いのでは」と感じるかもしれません。ここは考え方を切り替えてください。
レコードはインポートで作ります。 88行のCSVを取り込むのに、10行と88行で手間の差はありません。翌年度分を追加するときも、既存の行をコピーして金額を直したCSVを1枚作るだけです。
一方で分岐は人が1本ずつ作ります。 ここに決定的な差があります。
レコード数を惜しまず、ロジックをゼロにする。
これがこの方式の要点です。
| ワークフローの分岐で組む | マスタレコードで組む | |
|---|---|---|
| 条件を追加するとき | ワークフローを編集する | CSVをインポートする |
| 88通りの条件 | 分岐88本 | レコード88行・分岐0本 |
| 変更履歴 | 追いにくい | インポート履歴に残る |
| テスト | 全分岐を通す必要がある | 代表パターンと境界値で足りる |
| 引き継ぎ | 分岐を読み解く | 表を見れば分かる |
| 更新できる人 | HubSpot管理者のみ | 表を管理している部門 |
運用面では、次のような変化が出ます。
適用根拠が記録として残る
どのマスタレコードが適用されたかを親レコードに書き込んでおけば、「なぜこの金額になったのか」を担当者が自分で確認できます。金額に関する問い合わせは、この一言が書かれているだけで減ります。
過去の取引に影響しない
マスタの金額を改定しても、すでに確定した取引の金額は変わりません（後述の「書き込み方式」による）。年度改定のたびに過去データが書き換わる心配がなくなります。
条件表とHubSpotがずれない
表を更新してインポートする運用にしておけば、二重管理が発生しません。
手順に入る前に、以下の4つの原則を押さえておくと後で作り直しになりません。
複数の条件を1つの文字列に連結し、それだけで金額が一意に決まる状態にします。キーの部品が足りていると、探し方は「完全一致」だけで済みます。
ここが実装の分かれ目です。
キーを組み立てる数式に条件分岐（「この場合はこう置き換える」）を入れると、避けたかったロジックが復活します。そうならないように、プロパティ側をキーに合わせて整えます。
数式は連結だけになり、条件分岐が1つも入りません。
ワークフローの「レコードを編集」アクションは、値のコピーと設定ができますが、足し算や引き算はできません。
そのため「表から引いた金額から、さらに前払い分を引く」といった処理をワークフローでやろうとすると、また別の仕組みが必要になります。
そこで、前払いの有無もキーに含めて、前払いを差し引いた後の最終金額をマスタに持たせます。 レコード数は倍になりますが、演算が一切不要になります。原則1の「レコードを惜しまない」と同じ考え方です。
数式で常に再計算される形にすると、マスタを改定した瞬間に過去の取引の金額まで変わります。 実績レポートが過去にさかのぼって書き換わることになり、事故になります。
ワークフローで通常のプロパティに書き込む形にしてください。あわせて「計算した日時」も記録しておくと、いつ時点の値かが判断できます。
なお、プログラミングは不要です。 すべて標準機能の設定で完結します。
複数のシートに分かれている表を、1枚のシートに統合します。列は「条件の項目」＋「金額」です。
| 商材 | 契約年度 | 数量 | 定価 | 割引プランA適用後 | 割引プランB適用後 |
|---|---|---|---|---|---|
| 定期便A | 2026 | 130 | 60,000 | 41,000 | 36,000 |
そして、この統合シートからインポート用の行を数式で生成する構成にします。人が編集するのは統合シートだけ、という状態を作ってください。ここを分けておかないと、改定のたびに手作業が発生します。
条件の項目を並べる順番と、区切り記号を決めます。
商材_数量_割引プラン_契約年度_前払い区分 → 定期便A_130_B_2026_前払あり
表に存在しない値が来る場合の扱いも、ここで決めておきます。たとえば「数量200以上は割引なし」なら、その範囲のレコードを作っておくか、「該当なしのときは定価をそのまま使う」というルールにします。
設定 > オブジェクト から作成します。プロパティの構成例です。
| プロパティ | 型 | 役割 |
|---|---|---|
| マスタキー | 単一行テキスト | 主表示プロパティ。マッチングに使う |
| 商材／数量／割引プラン／契約年度／前払い区分 | ドロップダウン・数値 | キーの部品。人が読むための内訳 |
| 定価 | 数値（通貨） | 整合性チェック用 |
| 最終金額 | 数値（通貨） | 親レコードにコピーする本体 |
| 割引額／割引率 | 数値 | レポートの軸として使う |
| 備考 | 複数行テキスト | 運用メモ |
カスタムオブジェクトの作成枠は先に確認してください。 アカウントで作成できる数には上限があります。枠が残っていない場合は、製品オブジェクトに「レコード種別＝マスタ」というプロパティを付けて間借りする方法があります。動作は同じです。
マスタキーのプロパティ設定で、一意の値（重複を許可しない）を有効にします。
これには2つの効果があります。
改定のたびにレコードが増えていく事故を防げるので、必ず設定してください。
Step 1の統合シートから、キーと金額を含む行を生成し、CSVとしてインポートします。
インポート前にキーの重複チェックをシート上で行ってください。重複があると、意図しない行が採用されます。表計算ソフトの重複カウント式を1つ置いておくだけで確認できます。
金額を反映したい側のオブジェクト（取引、契約など）に、計算プロパティ（カスタム数式）でキーを作ります。出力タイプはテキストです。
商材 & "_" & 数量 & "_" & 割引プラン & "_" & 契約年度 & "_" & 前払い区分
原則2のとおり、条件分岐は入れません。
このStepで必ず確認することがあります。作成後に1件だけ実際の値を見て、キーが想定どおりの表記になっているかを目視してください。
特に数値の扱いに注意が必要です。数量が 130 ではなく 130.0 として連結されることがあります。表記が違えば完全一致しないので、金額が入りません。もし小数表記になる場合は、マスタ側のキーをその表記に合わせてください（統合シートで生成しているので一括で直せます）。
なお、文字列を連結する関数の書き方は数式エディタの関数一覧で確認してください。
親オブジェクトのワークフローを1本作ります。
登録トリガー： キーのプロパティが変更されたとき。キーの部品のいずれかが変わると数式が再計算されるので、これだけで全条件の変更を拾えます。再登録はオンにします。
アクション1：レコードを関連付ける 対象をマスタオブジェクトにし、マスタキーが親レコードのキーと一致するレコードを関連付けます。
アクション2以降：レコードを編集 関連付けたマスタレコードの値を、親レコードのプロパティにコピーします。
| コピー元（マスタ） | コピー先（親レコード） |
|---|---|
| 最終金額 | 月額（金額のプロパティ） |
| マスタキー | 適用マスタキー（適用根拠の記録） |
| 割引額／割引率 | レポート用のプロパティ |
| — | 計算日時（ワークフロー実行日を設定） |
「適用マスタキー」の記録は省略しないでください。 関連付けは実行のたびに積み上がっていくため、レコードの関連付け一覧を見ても最終的にどれが採用されたのか分かりません。採用された1件をプロパティに残しておくことで、根拠が特定できます。
3種類のパターンで確認します。
1. 代表パターン 条件表の中央付近の値で、期待する金額が入ることを確認します。
2. 境界値 表の最小値・最大値、および前払いの有無を切り替えたときの金額を確認します。演算をマスタに寄せた設計が正しく効いているかは、ここで分かります。
3. 条件の変更 割引プランをAからBに変更し、金額とあわせて「適用マスタキー」も更新されることを確認します。関連付けは累積しますが、値のコピーは直近に関連付けたレコードから行われるため、正しく切り替わるはずです。
4. 該当なし 表に存在しない条件のレコードで、想定した挙動（定価のまま／空欄のまま）になるかを確認します。
改定作業は3ステップで固定できます。
ワークフローには一切触りません。 これが最初に設定した目的そのものです。
手順書としてこの3ステップを残しておけば、HubSpot管理者以外でも運用できます。インポート権限の付与範囲は、あわせて検討してください。
キーに一致するレコードが無いと、金額が入りません。入らないこと自体は正しい挙動ですが、気づけないと放置されます。
「金額のプロパティが空欄」かつ「キーが入力済み」という条件のアクティブリストを1つ作っておいてください。ここに件数が入っていれば、マスタの行が足りていないというサインになります。通知を飛ばす設定を追加してもよいでしょう。
保守を属人化させないために、次の内容をドキュメントに残しておくことを勧めます。
| 記録項目 | 内容 |
|---|---|
| マスタオブジェクト名 | 作成したカスタムオブジェクト |
| キーの構成 | 項目の並び順と区切り記号 |
| 統合シートの場所 | 人が編集する唯一の場所 |
| ワークフロー名 | 条件変更時に触らない対象として明記 |
| レコード数 | 現在の行数（増減の目安になる） |
| 更新手順 | 上記3ステップ |
条件表そのものが仕様書として機能するのが、この方式の利点です。表を見れば、どの条件でいくらになるかが誰でも分かります。
| 症状 | 原因 | 対処 |
|---|---|---|
| 金額が入らない | キーの表記が一致していない（130 と 130.0 など） |
実際のキーの値を目視し、マスタ側の表記を合わせる |
| 一部のレコードだけ入らない | キーの部品が空欄 | 「なし」の選択肢を用意し、空欄を禁止する |
| 意図しない金額が入る | 同じキーのマスタが重複している | マスタキーを一意の値プロパティに設定する |
| 過去の金額が書き換わった | 数式プロパティで計算している | ワークフローで通常のプロパティに書き込む |
| 反映された値が消える | 書き込み先が外部システムとの連携項目 | 連携で上書きされないプロパティに書き込む |
| 条件を変えても値が変わらない | ワークフローの再登録がオフ | 再登録をオンにする |
最後の2つは、稼働してしばらく経ってから気づきやすい種類の不具合です。書き込み先のプロパティが外部システムから上書きされる項目かどうかは、設定前に確認してください。
「条件の組み合わせで値が決まる」構造であれば、そのまま転用できます。
返す値は金額に限りません。区分名や担当部署といった文字列でも同じ形で使えます。「業種 × 従業員規模 → 担当チーム」のような割り当てルールも、マスタレコードとして持たせることができます。
条件表がスプレッドシートで運用されていて、HubSpot側では手入力している。そういう箇所があれば、いずれもこの方式の対象です。
条件の組み合わせをワークフローの分岐で表現すると、条件が増えるたびに作業量が掛け算で増え、いずれ誰も触れなくなります。
条件表をレコードとして持たせれば、ワークフローは1本・分岐ゼロで済みます。 条件が増えても、変わるのはインポートするCSVの行数だけです。
押さえるべきは4点です。
そして運用の目標は1つです。条件が変わったときに、ワークフローを開かなくていい状態にすること。 ここが達成できているかどうかで、半年後の運用負荷が決まります。
自社の条件表がこの方式に乗るかどうか、キーの設計をどうするかといった点は、実際の表を見ながら整理するのが確実です。判断に迷う場合はお気軽にご相談ください。