HubSpot Starter は月額 $20/シート (月払い、2026-07 時点) から使える一方、運用を続けるほど「この機能は上位プランでした」という壁に当たります。カスタムオブジェクト、本格的なワークフロー、カスタムレポート。壁に当たるたびに調べ直すのは消耗しますし、そのたびに Pro ($800/月) の稟議を考えるのも現実的ではありません。
私たち humbulls は自社の HubSpot も Starter で運用しており、制限に当たっては回避する、を繰り返してきました。その経験から言えるのは、制限は「当たってから調べる」より「先に一覧で把握して、回避できる壁とできない壁を仕分けておく」方が圧倒的に楽だということです。
この記事では、Starter の制限を 4 分野 30 項目に整理し、それぞれについて Apps Script や Claude Code などの AI・スクリプトでの回避可否を付けました。仕様は 2026-07 時点の公式ドキュメント・料金ページに基づきます。プラン仕様は改定されるため、契約判断の際は必ず公式ページで最新をご確認ください。
制限は場当たり的に調べるのではなく、まず 4 分野の地図として持ちます。 30 項目のうち、AI・スクリプトで実務上回避できる壁は半分以上あります。 回避不能な壁が自社業務の中心にあるかどうかが、プラン判断の分かれ目です。
SaaS のプラン選定でよく言われる定石は、「機能の多さではなく、自社の業務が制約に当たるかどうかで選ぶ」というものです。HubSpot Starter の制限も、公式料金ページと Product & Services Catalog で機能とプランの対応が公開されていますが、項目が多く、どれが自社に効いてくるかを読み解くのに時間がかかります。
従来のやり方は、壁に当たるたびにナレッジベースを検索して「Professional 以上が必要です」の表記を見つけ、落胆する、の繰り返しでした。導入前の検討でも、営業資料の機能比較表を眺めるだけでは「その制限が自社の運用で月何時間の手作業になるか」までは見えません。
humbulls では、制限を次の 4 分野に分けて棚卸しし、それぞれに回避可否を付けて管理しています。全 30 項目の内訳は以下のとおりで、詳細は 2〜5 章で分野ごとに見ていきます。
| 分野 | 壁の数 | 代表的な壁 | AI・スクリプトでの回避余地 |
|---|---|---|---|
| データ・CRM (2 章) | 7 | カスタムオブジェクト不可 | 大きい (設計で吸収) |
| 自動化・メール (3 章) | 9 | 本格ワークフロー不可 | 大きい (Apps Script で外付け) |
| レポーティング (4 章) | 6 | カスタムレポートビルダー不可 | 大きい (Looker Studio で再現) |
| 連携・API (5 章) | 8 | 100 リクエスト/10 秒 | 中程度 (設計次第で実用) |
ただし、最初にひとつ注意点があります。「回避できる」は「無料で済む」と同義ではありません。回避策には構築と保守の工数がかかります。その損益分岐の考え方は 6 章でまとめて扱うので、まずは自社がどの壁に当たるかを特定するところから始めてください。
目的: 自社の HubSpot 利用状況から、これから当たりそうな Starter の壁を先回りで洗い出す 所要時間: 15 分 ツール: Claude / ChatGPT
プロンプト:
以下は自社の HubSpot Starter の利用状況です。この使い方を続けた場合に当たりそうな
プラン制限を予測し、一覧化してください。
利用状況:
- コンタクト数と月間増加ペース:
- 管理したいデータ (例: 契約、機器、店舗など Contact/Company/Deal/Ticket 以外のもの):
- 自動化したい業務 (箇条書き):
- 毎月作っているレポート:
- 外部ツール連携 (例: kintone、Google Sheets、Slack):
出力形式:
| 予測される壁 | 発生時期の目安 | 業務への影響 | 回避の方向性 (設定変更 / スクリプト / 上位プラン) |
条件:
- 影響が大きい順に並べてください。
- 発生時期は利用状況の数字から推定し、根拠を 1 行添えてください。
- 判断できない項目は「要確認」と明記してください。
運用 Tips: - 予測結果はそのまま信じず、この記事の 30 項目一覧と突き合わせて確認してください。 - 「発生時期の目安」を出させると、対応の優先順位が会議で決めやすくなります。
Starter 最大のデータ制約はカスタムオブジェクトが使えないこと (Enterprise 限定) です。 ただし実務では、既存 4 オブジェクト + カスタムプロパティの設計でかなり吸収できます。 吸収しきれない履歴データは、スプレッドシートに逃がします。
CRM 設計の定石は「オブジェクト構造は業務の実態に合わせる」ですが、Starter ではその自由度に上限があります。HubSpot 公式ドキュメントによると、カスタムオブジェクトの作成は Enterprise 系サブスクリプション限定です。データ・CRM 分野の壁は次の 7 つです。
| # | 壁 | Starter での制限 |
|---|---|---|
| 1 | カスタムオブジェクト | 作成不可 (Enterprise 限定) |
| 2 | マーケティングコンタクト | 1,000 件込み、超過は追加課金 |
| 3 | リスト数 | アクティブリスト・静的リストに上限あり |
| 4 | 計算プロパティ | 作成不可 (上位プラン) |
| 5 | 重複管理ツール | 一括の重複検出・統合機能なし |
| 6 | ステージ変更履歴の時系列分析 | 過去時点との比較レポートが組めない |
| 7 | 条件付きプロパティロジック | 入力条件の出し分けなど高度な制御不可 |
従来この壁に当たると、「契約」「導入機器」のような独自データを無理やり Deal のメモ欄に書く、あるいは Excel 台帳との二重管理に戻る、という選択になりがちでした。二重管理は更新漏れの温床で、CRM の信頼性そのものを損ないます。
humbulls では、独自データの大半を「既存 4 オブジェクト (Contact / Company / Deal / Ticket) のどれかにカスタムプロパティを足す」形で吸収しています。たとえば契約情報は Deal のプロパティ群として、問い合わせ種別は Ticket として設計する、という具合です。この構造変換は AI が得意な作業で、管理したい項目を渡せばマッピング案が数分で出ます。吸収しきれない「履歴を積む」タイプのデータ (壁 6) は、Apps Script 30 行で日次スナップショットを Google Sheets に書き出す方法で逃がしています。
注意点がひとつ。既存オブジェクトへの相乗り設計は、1 レコードに複数の関心事を詰め込みすぎると破綻します。「そのデータは誰が・いつ・何件更新するか」を先に書き出し、更新頻度が違うものは別オブジェクト (または Sheets 側) に分ける。この線引きだけは人間が判断してください。
目的: カスタムオブジェクトで管理したかったデータを、既存 4 オブジェクトの設計に変換する 所要時間: 20 分 ツール: Claude / ChatGPT
プロンプト:
HubSpot Starter (カスタムオブジェクト不可) で、以下のデータを管理したいです。
Contact / Company / Deal / Ticket の既存オブジェクトとカスタムプロパティだけで
実現する設計案を出してください。
管理したいデータ:
（例: 保守契約 — 契約開始日 / 更新日 / 年額 / 対象製品 / 担当者）
前提:
- 1 社が複数の契約を持つことがある: はい / いいえ
- 更新頻度:
- 誰が入力するか:
出力してほしいこと:
1. 推奨するオブジェクトとその理由
2. 作成するカスタムプロパティ一覧 (プロパティ名 / 型 / 選択肢)
3. この設計の弱点と、破綻しやすい将来シナリオ
4. HubSpot 内で持たず Google Sheets 側に逃がすべきデータがあれば指摘
運用 Tips: - 「1 社が複数持つか」の回答で設計が大きく変わります。ここを曖昧にしたまま作ると後で作り直しになります。 - 出力された弱点 (3) は必ず読んでください。相乗り設計の限界を先に知っておくことが Pro 移行判断の材料になります。
Starter に本格的なワークフロー機能はなく、簡易オートメーション (最大 10 アクション) のみです。 分岐やレコード更新を伴う自動化は、Apps Script + Claude Code で外付けします。 スコアリングや A/B テストの上限も、この分野に集中しています。
マーケティングオートメーションの定石は「手動作業の反復をトリガーとアクションに置き換える」ことですが、Starter では置き換え先のワークフロー機能自体に大きな制約があります。公式ナレッジベースによると、本格的なワークフローは Professional 以上 (作成上限 300 個、Enterprise は 1,000 個) で、Starter で使えるのはフォームやメール単位の簡易ワークフロー (最大 10 アクション、トリガーごとに 1 本) です。この分野の壁は 9 つあります。
| # | 壁 | Starter での制限 |
|---|---|---|
| 8 | 本格ワークフロー | 利用不可 (Pro で 300 個まで) |
| 9 | 簡易オートメーションのアクション数 | 最大 10、トリガーごとに 1 本 |
| 10 | 条件分岐 (if/then) | 不可 |
| 11 | シーケンス (営業メール自動追客) | 利用不可 (上位プラン) |
| 12 | リードスコアリング | 5 スコアまで (Pro は 50 + AI レコメンド) |
| 13 | メール送信数 | マーケティングコンタクト数 × 5 通/月 |
| 14 | メール・LP の A/B テスト | 不可 (Pro 以上) |
| 15 | スマートコンテンツ (出し分け) | 不可 (Pro 以上) |
| 16 | レコードの自動ローテーション割り当て | 不可 (上位プラン) |
従来は、この壁に当たると「担当者が毎朝リストを目視して手動でタスクを振る」運用に落ちていました。1 回 10 分でも毎営業日なら月 3〜4 時間。しかも抜け漏れが出ます。
humbulls では、簡易オートメーションで足りない自動化を Google Apps Script の時間主導トリガーで外付けしています。「HubSpot API でレコードを取得 → 条件判定 → プロパティ更新や通知」という流れなら、Claude Code に要件を渡してスクリプトを書かせると 30 行前後で収まるケースが多く、実装は初回でも 1〜2 時間程度です。ポイントは、Starter に「ない」機能を嘆くのではなく、HubSpot の外に小さなワークフローエンジンを 1 つ持つという発想の転換です。
ただし、外付け自動化には向き不向きがあります。メール配信そのものの自動分岐 (検討段階別のステップメールなど) は、外部スクリプトで無理に組むと配信事故のリスクが上がります。顧客に直接届く自動化は Starter の標準機能内に留め、社内向けの通知・更新系だけを外付けする、が安全な線引きです。
目的: やりたい自動化を「Starter 標準 / 簡易オートメーション / Apps Script 外付け / 手動維持」に振り分ける 所要時間: 20 分 ツール: Claude / ChatGPT / Google Apps Script
プロンプト:
以下は HubSpot Starter 環境で自動化したい業務の一覧です。それぞれを次の 4 つに
振り分けてください。
振り分け先:
A. Starter の標準機能・簡易オートメーション (最大 10 アクション・分岐不可) で実現可能
B. Google Apps Script + HubSpot API の外付けで実現可能
C. 上位プランでないと現実的でない
D. 自動化せず手動のままが妥当
自動化したい業務:
（ここに箇条書きで貼る。例: フォーム送信から24時間後に営業へ追客タスクを作る）
出力形式:
| 業務 | 振り分け | 理由 | B の場合: 処理の流れ (トリガー→取得→判定→アクション) |
条件:
- 顧客にメールが直接届く自動化は、事故リスクを理由に B にしないでください。
- B に振り分けた業務は、Apps Script の実装難易度を高/中/低で添えてください。
運用 Tips: - B と判定された業務は、そのままこのプロンプトの続きで「Apps Script のコードを書いて」と依頼すれば実装まで進めます。 - 最初の 1 本は通知系 (社内 Slack やメール通知) から始めると、失敗しても実害がありません。
カスタムレポートビルダーは Starter では使えません。 ただしデータを Google Sheets に同期できれば、Looker Studio で Pro 相当の可視化は再現できます。 1.3 万件を 4 分で同期する構成が、実測済みの現実解です。
「計測できないものは改善できない」はマーケティングの古典的な定石ですが、Starter のレポート機能には明確な天井があります。公式料金ページによると、Starter のダッシュボードは 10 個・1 ダッシュボードあたり 50 レポートまでで、カスタムレポートビルダー (Pro で最大 100 レポート) は使えません。レポーティング分野の壁は 6 つです。
| # | 壁 | Starter での制限 |
|---|---|---|
| 17 | カスタムレポートビルダー | 利用不可 (Pro 以上) |
| 18 | ダッシュボード数 | 10 個まで |
| 19 | ダッシュボードあたりレポート数 | 50 まで |
| 20 | アトリビューションレポート | 利用不可 (上位プラン) |
| 21 | ステージ推移の時点比較レポート | 標準では組めない |
| 22 | コホート・ファネル横断の柔軟な分析 | 標準レポートの範囲外 |
従来の対処は「標準レポートで我慢する」か「毎月 CSV をエクスポートして Excel で組み直す」の二択でした。後者は月初に 2〜3 時間かかるうえ、集計ロジックが担当者の Excel に閉じるため、引き継ぎのたびに壊れます。
humbulls の現実解は、HubSpot のデータを Google Sheets に自動同期し、Looker Studio (無料) で可視化する、カスタムレポートビルダーの代替構成です。Apps Script による同期は実測で 1.3 万件を 4 分、日次の自動実行にすれば「毎朝最新のダッシュボード」が Pro なしで手に入ります。構築手順は Apps Script で HubSpot と Sheets を自動同期する記事と、上位プラン相当のレポートダッシュボードを再現した記事でそれぞれ公開しています。
失敗パターンとして多いのは、最初から全オブジェクト・全プロパティを同期しようとすることです。使わない列が数百並んだシートは、それ自体がメンテナンス負債になります。まず「毎月見る数字」を 5 個決めて、その算出に必要な列だけ同期する。足りなくなったら列を足す。この順番が保守コストを最小にします。
目的: 欲しいレポートから逆算して、同期すべきデータとパイプライン設計を決める 所要時間: 30 分 ツール: Claude / ChatGPT / Google Apps Script / Looker Studio
プロンプト:
HubSpot Starter (カスタムレポート不可) の環境で、以下のレポートを
Google Sheets + Looker Studio で実現したいです。設計を出してください。
毎月見たい数字:
（例: 月別の新規リード数、ソース別の商談化率、パイプライン金額の推移）
出力してほしいこと:
1. HubSpot から同期が必要なオブジェクトとプロパティの最小リスト
2. Sheets のシート構成 (シート名 / 列 / 主キー)
3. 同期頻度の推奨 (日次 / 時間ごと) と理由
4. Looker Studio 側で計算すべき指標と計算式
5. この構成で実現できない数字があれば、その理由と代替案
条件:
- 同期プロパティは「レポートに使う列だけ」に絞ってください。
- 全件同期と増分同期のどちらにすべきかを、データ量の観点で判定してください。
運用 Tips: - 「毎月見たい数字」が 10 個を超えたら、まず数字の方を削ってください。見ない数字の同期は負債です。 - 出力 5 (実現できない数字) にアトリビューション系が挙がったら、それは素直に Pro 移行の検討材料に回します。
Starter の API は 100 リクエスト/10 秒・250,000 コール/日です。 少人数チームの連携用途なら、バッチ処理と増分同期の設計で実務上は十分回ります。 ネイティブ連携が上位プラン限定のツールは、API 直結で代替します。
外部ツール連携の定石は「データの正本 (どちらのシステムを信じるか) を決めてから同期を設計する」ことです。その同期の物理的な上限を決めるのが API 制限で、公式開発者ドキュメントによると Free / Starter の非公開アプリは 100 リクエスト/10 秒・250,000 コール/日 (Pro は 190 リクエスト/10 秒・625,000 コール/日) です。連携・API 分野の壁は 8 つです。
| # | 壁 | Starter での制限 |
|---|---|---|
| 23 | API バーストレート | 100 リクエスト/10 秒 |
| 24 | API 日次上限 | 250,000 コール/日 |
| 25 | ワークフローからの Webhook 送信 | 不可 (上位プラン) |
| 26 | ワークフロー内カスタムコード | 不可 (上位プラン) |
| 27 | Salesforce ネイティブ連携 | 不可 (上位プラン) |
| 28 | マルチ通貨 | 利用できる通貨数に上限 |
| 29 | チーム階層・詳細な権限管理 | 不可 (上位プラン) |
| 30 | 承認フロー | 不可 (Enterprise) |
数字だけ見ると心許なく感じますが、冷静に計算すると、100 件ずつのバッチ取得なら 1.3 万件でも 130 リクエスト程度。バーストレートに触れないよう間隔を空けても数分で終わります。実際、前章の Sheets 同期 (1.3 万件・4 分) はこの制限内での実測値です。従来「API 制限が怖いから連携を諦める」と判断されがちだった規模でも、設計次第で十分実用になります。
humbulls では、kintone との並行運用のように「全件を毎回舐めず、更新分だけを同期する」増分同期を基本形にしています。1 回の同期対象が数十件に収まるため、日次上限のごく一部しか消費しません。設計の考え方はKintone と HubSpot を増分同期で並行運用する記事で公開しています。スクリプト自体は、レート制限の仕様を Claude Code に読ませて「制限を守る実装にして」と指示すれば、リトライ処理込みで生成できます。
ただし、日次 250,000 コールは「複数の連携を足し合わせた総量」で消費される点に注意してください。連携を 1 つずつ増やしていくと、ある日突然まとめて上限に触れます。連携ごとの 1 日あたり消費コール数をメモしておき、合計が上限の 5 割を超えたら設計を見直す、という運用ルールを推奨します。
目的: API レート制限を守る同期スクリプトの設計を出し、そのまま実装につなげる 所要時間: 30 分 ツール: Claude Code / Google Apps Script
プロンプト:
HubSpot Starter の API 制限 (100 リクエスト/10 秒、250,000 コール/日) を守りながら、
以下の同期を Google Apps Script で実装するための設計を出してください。
同期要件:
- 同期元と同期先:
- 対象オブジェクトと件数:
- 同期頻度:
- 全件同期か増分同期か: 未定 (推奨を出してください)
出力してほしいこと:
1. 全件 / 増分の推奨と、その根拠 (1 回あたりの想定リクエスト数を計算して示す)
2. バッチサイズとリクエスト間隔の設計
3. 429 (レート超過) が返ったときのリトライ方針
4. 1 日あたりの消費コール数の見積もり
5. 上記を踏まえた処理フロー (擬似コード)
条件:
- 見積もりは計算式ごと示してください。
- 日次上限の 10% を超える設計になる場合は、代替案を提示してください。
運用 Tips: - 設計に納得してから「この設計でコードを書いて」と続けると、手戻りがほぼなくなります。 - 最初の実行は必ず少件数 (10 件程度) のテストモードで。同期系スクリプトのバグは一括でデータを壊します。
回避策はタダではありません。構築と保守の工数がかかります。 「回避策の月間運用時間 × 時給換算」と Pro との差額を並べて、機械的に判定します。 感情ではなく計算で決めると、稟議も通しやすくなります。
プラン判断の定石は TCO (総保有コスト) 比較です。Starter は $20/シート/月、Pro は $800/月 (3 コアシート込み、公式料金ページ・2026-07 時点)。差額はおよそ月 $740 です。一方、この記事で紹介した回避策は無料ツールで動きますが、構築に数時間、保守に月 1〜2 時間程度の工数がかかります (humbulls の自社運用での体感値)。
従来この判断は「そろそろ限界かも」という感覚で行われがちでした。感覚ベースの稟議は通りにくく、逆に「まだ粘れたのに移行して機能を持て余す」ケースもあります。
humbulls では、壁に当たるたびに次の 3 問で判定しています。第一に、その壁は回避可能か (この記事の 30 項目一覧で確認)。第二に、回避策の月間運用工数を時給換算すると差額 $740 を超えるか。第三に、回避不能な壁 (アトリビューション、シーケンス、スマートコンテンツなど顧客接点系) が自社の成長ボトルネックに直結しているか。3 問目が「はい」なら回避で粘らず移行します。逆に 1〜2 問目で収まるうちは、Starter + AI の構成が費用対効果で勝ちます。移行判断の 12 項目チェックリストはStarter と Professional の違いを整理した記事にまとめているので、本格的に検討する段階で併せてお使いください。
失敗パターンは、回避策を増やしすぎて「秘伝のスクリプト群」が属人化することです。回避策が 5 本を超えたあたりから、保守工数は本数に比例して増えます。回避策の一覧 (何が・どこで・何を動かしているか) を 1 枚のドキュメントにしておくこと。これを怠ると、担当者の退職と同時に自動化が全部止まります。
目的: いま当たっている制限について、回避と Pro 移行のどちらが得かを判定する 所要時間: 15 分 ツール: Claude / ChatGPT
プロンプト:
HubSpot Starter で以下の制限に当たっています。回避策で粘るべきか、Professional に
移行すべきかを判定してください。
状況:
- 当たっている制限 (複数可):
- その制限が原因で発生している手作業と月間時間:
- 担当者の時給換算額:
- 現在の Starter 契約シート数:
- 今後 6 ヶ月の事業計画で増える業務:
前提知識:
- Pro との月額差はおよそ $740 (Starter $20/シート、Pro $800/月・3 シート込み)
- Apps Script / Claude Code による外付け回避は、構築に数時間 + 保守に月 1〜2 時間かかる
出力してほしいこと:
1. 制限ごとの判定: 回避可能 / 回避可能だが非推奨 / 回避不能
2. 回避した場合と移行した場合の月間コスト比較表 (計算式つき)
3. 総合判定と、その結論が変わる条件 (例: リード数が月◯件を超えたら)
4. 移行を選ぶ場合に、移行前へ済ませておくべき準備
条件:
- 数字で判定できない要素は「判断材料不足」と明記し、何を測ればよいか示してください。
運用 Tips: - 「結論が変わる条件」(出力 3) が最重要です。判定を 1 回で終わらせず、四半期ごとに同じプロンプトで再判定してください。 - 判定結果はそのまま稟議資料の骨子に使えます。比較表を計算式つきで出させるのはそのためです。
HubSpot Starter の制限 30 項目を、データ・CRM (7)、自動化・メール (9)、レポーティング (6)、連携・API (8) の 4 分野で整理しました。カスタムオブジェクト、本格ワークフロー、カスタムレポートといった大きな壁も、既存オブジェクト設計、Apps Script の外付け、Sheets + Looker Studio の組み合わせで、実務上は多くを回避できます。実測でも 1.3 万件の同期が 4 分、スナップショット取得が 30 行のスクリプトで動いています。
一方で、顧客接点に直結する壁 (シーケンス、A/B テスト、スマートコンテンツ、アトリビューション) は回避で粘るほど機会損失が膨らみます。回避できる壁は AI とスクリプトで越え、回避すべきでない壁に当たったら計算で移行を決める。この仕分けができていれば、Starter は少人数チームにとって長く戦える基盤です。
制限の回避策の実装や、Pro 移行を含めた HubSpot 運用設計に伴走が必要な場合は、humbulls の Growth Partner サービスでご相談いただけます。自社を Starter で回している経験ごと持ち込みます。