%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
基本設計書は、構築前に決める項目を5章で一枚にまとめる文書です。各章の記載項目と、設定画面で後から変えられないものの扱いを整理します。
HubSpotの基本設計書とは、構築に入る前に「どのデータを・どの形で持ち・誰が扱うか」を決めて一か所に書き留める文書です。 章立ては、前提と範囲、オブジェクトと関連付け、プロパティ、パイプラインとステージ、ユーザー・チーム・権限の5つで足ります。ワークフローの動きや画面の見た目は、別の詳細設計に分けたほうが保守しやすくなります。
設計書がないまま構築を進めると、プロパティの内部名が担当者ごとにばらつく、パイプラインのステージが現場の言葉とずれる、権限が後から場当たりで増える、といった状態になりがちです。——どれも構築した本人にしか理由が分からないため、引き継ぎや改修のたびに調べ直しが発生します。
この記事では、基本設計書に書く項目を章ごとに整理し、公式ナレッジで確認できた設定画面の場所と制約を添えて、そのまま使える項目表の形で示します。
- 基本設計書は5章で構成する ── 章ごとに「決めること」「決める人」「確定の条件」を揃えると、レビューが短くなります
- 後から直せない項目を先に確定する ── 内部名のように作成後に編集できないものは、設計書の段階で表にして合意します
- 契約プランの上限を前提の章に書く ── パイプライン数やカスタムオブジェクトの可否は、設計の選択肢そのものを決めます
- レビューは番号付きの手順で回す ── 現状整理から確定、構築後の突合までを一本の流れにします
基本設計書と詳細設計・運用ルールの線引き
基本設計書の価値は、構築する人と使う人の間で「何を決めたか」が一枚で分かることにあります。すべてを書こうとすると更新されない文書になるため、先に書く範囲を切ります。
基本設計に入れるものと入れないもの
基本設計には、構築後に変えると影響が大きいもの、つまりデータの構造と入口と権限を入れます。具体的には、扱うオブジェクトとその関連付け、プロパティの定義、パイプラインとステージ、ユーザーとチームと権限です。これらは移行やレポートや連携の前提になるため、最初に合意しておく価値があります。
一方、ワークフローごとの登録条件や分岐、メールの文面、ダッシュボードのレイアウトは、運用に入ってから調整することが多い領域です。基本設計では「どの業務を自動化の対象にするか」の一覧までにとどめ、詳細は別の設計書に任せます。
| 文書 | 書く内容 | 変更の頻度 |
|---|---|---|
| 基本設計書 | データ構造・入口・権限の決定事項 | 低い（変更は承認制） |
| 詳細設計書 | ワークフロー・ビュー・レポートの個別仕様 | 中（改善のたびに更新） |
| 運用ルール | 入力規則・命名・棚卸しの手順 | 中（四半期ごとに見直し） |
運用ルール側は、CRM運用ルール設計ガイドのように入力・命名・権限・監査を仕組みにする考え方が参考になります。基本設計書はその土台にあたり、運用ルールの「なぜこの項目があるのか」に答えられる状態を作ります。
要件定義書との違い
要件定義書は「何を実現したいか」を業務の言葉で書き、基本設計書は「HubSpotでどう実現するか」を設定の言葉で書きます。要件の段階では「更新漏れを防ぎたい」と書き、基本設計の段階で「取引パイプラインに更新ステージを置き、契約終了日を日付プロパティで持つ」と落とし込みます。
要件の整理はHubSpot提案・要件定義7ポイントやCRM導入前チェックリストで先に済ませておくと、基本設計書は要件の各行に対する回答として書けます。要件と設計の各行に同じ番号を振っておくと、レビューで「この設定は何の要件のためか」をすぐに追えます。
第1章 前提と範囲｜契約プランと上限を先に書く
設計書の最初の章に、前提条件を書きます。HubSpotは契約しているプランによって、作れるものの数や使える機能が変わります。前提を書かずに設計すると、構築の途中で「このプランでは作れない」と分かり、章の組み直しになります。
目的・対象範囲・対象外
冒頭には、この設計書が何のためのもので、どの部門のどの業務を対象にするかを書きます。対象外も同じ重さで書きます。たとえば「マーケティングの配信設計は対象外」「会計システムとの連携は別設計」と明記しておくと、後から範囲が広がる際に、追加の設計として扱えます。
あわせて、利用するHubと契約プランの一覧、設計の責任者（承認者）、更新の履歴欄を置きます。更新履歴は「日付・変更箇所・変更理由・承認者」の4項目で足ります。
上限と利用状況を「制限」タブで確認する
プランごとの上限は、設計の選択肢を直接狭めます。公式ナレッジによると、データモデルの画面（「その他」から「データ管理」、「データモデル」の順に移動）には「管理」「分析」「制限」のタブがあり、「制限」タブでレコード、関連付け、パイプライン、カスタムプロパティーおよび計算プロパティー、関連付けラベル、カスタムオブジェクトの上限と利用状況を確認できます。設計に着手する前に、この画面で現在値を控えておきます。
| 前提として書く項目 | 確認する場所 | 設計への影響 |
|---|---|---|
| カスタムオブジェクトの可否 | カスタムオブジェクトの作成にはEnterpriseが必要（公式ナレッジ） | 業界固有の対象を持てるか |
| パイプラインの上限 | データモデルの「制限」タブ | 事業別・用途別に分けられる数 |
| 権限セットの作成 | 作成・編集にはEnterpriseが必要（公式ナレッジ） | 役割別の権限をひな形化できるか |
プランに足りない部分は、設計の工夫で埋めるのか、プランを見直すのかを前提の章に書いて合意します。この判断は費用に関わるため、設計者が決めず、承認者が決める事項として明記します。
第2章 オブジェクトと関連付け｜データモデル図を作る
第2章では、HubSpotの中で何をレコードとして持つかを決めます。標準のコンタクト・会社・取引・チケットで足りるのか、業務固有の対象（物件、契約、案件の拠点など）を独立したレコードにするのかが論点です。
オブジェクトの一覧表を作る
オブジェクトごとに、「何を1件とするか」「誰が作るか」「他のオブジェクトとの関係」を表にします。1件の定義が曖昧だと、同じ実体が複数のレコードに分かれたり、1件に複数の実体が詰め込まれたりします。「契約は1契約を1件とする」のように、数え方を一文で決めておきます。
カスタムオブジェクトを使う場合は、作成画面で必須になる項目も設計書に書きます。公式ナレッジでは、オブジェクト名（単数形・複数形）とプライマリー表示プロパティー（レコードの名前として使われる主な識別子）が必須で、「一意の値」のチェックボックスで重複入力を防げます。内部名は後述のとおり作成後に編集できないため、保存前に項目表で確定します。
関連付けとラベルを設計する
オブジェクト間の関係は、「1対多か多対多か」と「関係に役割を付けるか」を決めます。公式ナレッジによると、データモデルの画面では、関連付けの作成、関連付けラベルの作成、関連付けの上限（「多対多」の部分から設定）まで行えます。関連付けラベルの作成にはスーパー管理者権限が必要で、対象はProfessionalまたはEnterpriseです。
ラベルの数はオブジェクトのペアごとに最大50個で、ペアラベルは2つ作っても上限では1つと数えられます。ラベル名には、セミコロンなど英数字以外の文字を避けることが推奨されています。オブジェクト間の関連付けの設計全体は、CRMデータベース設計の基本｜オブジェクト・プロパティ・関連付けを整えるでも整理しています。設計書には「ペア（オブジェクト）・ラベル名・内部名・上限（1件／多数／数値指定）」を表で残します。
データモデル図は画像で書き出して添付する
図は、設計書の読み手が全体像を一目で掴むために置きます。公式ナレッジでは、データモデルのグラフビューで、右上の「その他」から「データモデルを画像としてエクスポート」を選ぶと、キャンバスが画像としてダウンロードされます。構築後に実画面の状態を書き出して、設計時の図と見比べると、設計と実装のずれを機械的に見つけられます。
第3章 プロパティ定義書｜項目表のひな形
プロパティの定義は、基本設計書の中で最も行数が増える章です。1行ごとに迷わず書けるよう、列を固定した項目表にします。
項目表に入れる列
設計書の項目表は、表示名、内部名、フィールドタイプ、選択肢、必須の有無、入力する人、使い道（どのレポートやリストで使うか）を最低限として持ちます。表示名は「ラベル」として後から直せますが、内部名は作成後に編集できません。この事実は本記事で扱う内部名の扱いの基準で、他の章は項目表の内部名の列を参照します。内部名を設計書に書いておくことが、構築後の連携やAPIでの参照を安定させます。
公式ナレッジで確認した画面の場所は、設定アイコンから左サイドバーの「プロパティー」を選び、「オブジェクトを選択」でオブジェクトを指定して、「プロパティーを作成」を押す流れです。基本エディターではラベルとフィールドタイプを設定でき、完全エディターでは既定値、説明文、共有範囲や検証ルール、アクセス権の管理まで設定できます。
| 列 | 書くこと | 決めずに構築した場合の失敗 |
|---|---|---|
| 表示名・内部名 | 画面の名前と、変更できない識別子 | 似た名前の重複プロパティができる |
| フィールドタイプ・選択肢 | 入力形式と、選択肢の定義 | 集計や絞り込みができない |
| 必須・既定値・入力者 | 誰がいつ埋めるか | 空欄が増えレポートが信頼できない |
フィールドタイプと既定値の決め方
フィールドタイプは、集計の方法を決めます。数えたい分類は選択肢で持ち、自由記述のテキストにしないのが基本です。日付は日付型、金額や件数は数値型にしておくと、レポートやリストの条件で期間や大小を使えます。
公式ナレッジでは、既存プロパティのフィールドタイプを変更すると、保存済みの値が無効になることがあり、変更前にエクスポートすることが推奨されています。タイプは「変えられるが、既存データに影響する」設定として設計書に明記し、変更する場合の手順も添えます。既定値を設定できるのは、テキスト、数値、列挙のフィールドタイプで、センシティブデータ以外のプロパティーに限られます。既定値を設定しないカスタムプロパティーはnull値になる点も、項目表の「空欄の扱い」に書いておくと、リストの条件作りで迷いません。
重複を避ける確認と命名の規則
新しい項目を足す前に、同じ意味の既存プロパティがないかを確認する工程を、設計書の運用欄に書きます。命名規則（接頭辞、単位の書き方、略称の可否）は、プロパティの設計と命名規則を扱ったHubSpotプロパティ設計と命名規則、データ型の選び方に沿って決めると、第三者にも読みやすくなります。センシティブデータの設定にはEnterpriseが必要なため、個人情報に近い項目がある場合は前提の章のプランと照らして確認します。
第4章 パイプラインとステージ｜現場の言葉と確度を決める
パイプラインは、取引やチケットなどの進み方を表します。ステージの名前と順番は、現場が普段使う言葉に合わせると定着します。設計書では、ステージごとに「入る条件」「出る条件」「その段階で必要な情報」を書きます。
ステージ設計表の書き方
公式ナレッジによると、パイプラインは設定アイコンから「データ管理」の「オブジェクト」を選び、対象オブジェクトの「パイプライン」タブで設定します。ステージには名前、種類（進行中かクローズ済み）、色、並び順、内部名があり、取引では取引確度を持たせられます。取引確度はボードビューの加重金額の計算に使われます。
| ステージ設計表の列 | 書くこと | 補足 |
|---|---|---|
| ステージ名と順序 | 現場の言葉で、順番どおりに | 色分けもここで決める |
| 入る条件・出る条件 | 何が起きたら次へ進めるか | 曖昧語（検討中など）を避ける |
| 取引確度・必須情報 | 取引のみ確度、必須にするプロパティ | 確度は予測の前提になる |
取引では、「成約」と「失注」の両方を確度に含めることが公式ナレッジで求められています。含めないと、セールスレポートや収益レポートで取引が正しく処理されない場合があります。この2つは、ステージ設計表の最後の行に必ず入れる決まりにしておくと、抜けを防げます。
条件付きステージプロパティと削除の制約
ステージに入ったときに表示する項目を、必須にするかどうかも設計できます。これは条件付きステージプロパティと呼ばれ、スコアや計算のような読み取り専用プロパティは選べません。設計書には「ステージ名・表示するプロパティ・必須か任意か」を書きます。
ステージは、レコードや条件付きプロパティから参照されていると削除できません。削除前に「使用箇所」で参照を確認し、レコードの移動や設定の変更を行う必要があります。ステージを減らす改修は手間がかかるため、最初のステージ数は絞って始め、運用で足りない箇所を足すほうが安全です。ライフサイクルステージとの連動や、MQL・SQLの定義は、パイプライン設計とライフサイクルステージで扱われています。
複数パイプラインに分ける判断
提案と更新、新規と既存など、進み方が違うものは、パイプラインを分けると見通しが良くなります。分ける数の上限は契約プランによって異なり、カスタムパイプラインの数は全オブジェクトで共有されます。上限を越えるなら、1つのパイプラインの中でステージの命名を整理するか、プランを見直すかを、第1章の前提の判断として記録します。ステージ設計の詳しい考え方はHubSpotパイプライン設計ガイドに沿うと、確度の決め方まで揃います。
第5章 ユーザー・チーム・権限｜役割から権限を組み立てる
権限は、人ごとに決めるとすぐ破綻します。先に役割（営業、営業管理、マーケティング、経理など）を決め、役割ごとに必要な権限を割り当てる形にします。
役割と権限の対応表
公式ナレッジのユーザー権限ガイドによると、権限はCRM、マーケティング、セールス、収益、サービス、データ管理、自動化、レポート作成、AI機能、アカウントなどのタブに分かれています。設計書では、役割ごとにタブ別の可否を表にします。特に、アカウントのタブにあるプロパティー設定やユーザー・チームの管理は、設計の変更権限にあたるため、管理者に限定する扱いにします。
| 役割（例） | 主に必要な権限 | 制限したい権限 |
|---|---|---|
| 営業担当 | CRMの表示・編集、セールスのツール | 一括削除、エクスポート、設定の変更 |
| 営業管理者 | 上記に加えレポート、フォーキャスト | アカウント設定、ユーザー管理 |
| 管理者 | プロパティー設定、ユーザーとチーム | 変更は設計書の承認後に限る |
スーパー管理者は、権限ガイドの記載する範囲のアカウントツールと設定にアクセスできます。人数を絞り、誰が持つかを設計書に記録します。権限の編集画面は、設定の「ユーザーとチーム」から対象のユーザーを開き、「アクセス」タブの「権限の編集」で開きます。複数のユーザーをまとめて編集することもできますが、同じシートタイプであることが条件です。
権限セットとチームの使い分け
権限セットは、役割ごとの権限をひな形として作り、ユーザーに割り当てる機能で、作成・編集にはEnterpriseが必要です。契約がそれ以外のプランなら、ユーザーごとに権限を編集する運用になるため、役割と権限の対応表を設計書に残して、手作業の設定を揃える必要があります。
チームは、ユーザーをグループにまとめ、アクセス権、レポート、レコードの表示範囲を管理するために使われます。公式ナレッジでは、設定の「ユーザーとチーム」の「チーム」タブから作成します。ユーザーが主に所属するプライマリチームは1つで、レポート、ルーティング、通知、ワークフローのローテーションの対象になります。親チームの下に子チームを置く階層は、Enterpriseでのみ作成できます。設計書には、チーム名、所属ユーザー、プライマリかどうか、階層の有無を書きます。担当者の振り分けの設計は、チームの定義に依存するため、この章で決めておきます。
権限の考え方を大規模運用の観点まで広げる場合は、HubSpotパーミッション権限設計ガイドが補足になります。
設計書のレビューから確定までの手順
設計書は、書いて終わりではなく、承認を経て確定する文書です。確定前に構築へ入ると、設計書が後追いの記録になり、決定の根拠が失われます。
確定までの流れ
次の手順で進めると、レビューの論点が章ごとに整理され、手戻りが減ります。
- 要件定義の各行に番号を振り、基本設計書の各項目に対応する要件番号を書く
- 前提の章で、契約プランと現在の上限を「制限」タブの画面で確認して控える
- オブジェクトとデータモデル図を作り、1件の定義と関連付けラベルをレビューする
- プロパティの項目表を作り、内部名・フィールドタイプ・必須の可否を確認する
- パイプラインのステージ設計表を作り、入る条件・出る条件・確度を現場と合わせる
- 役割と権限の対応表を作り、設定を変更できる人を限定する
- 承認者が確定を記録し、更新履歴欄に日付と変更理由を書く
- 構築後に実画面と設計書を突き合わせ、差分を履歴に残す
構築後の突合では、データモデルの画像書き出しや、プロパティ一覧、パイプラインのステージ一覧を、設計書の表と並べて確認します。差分があれば、設計を直すのか、構築を直すのかを承認者が決めます。
StartLinkの進め方
StartLinkは、HubSpotゴールドパートナーとして、支援を「現状の整理・要件定義」「設計・構築」「データ移行」「テスト・検証」「定着・運用改善」の工程で進めます。基本設計書は、2つ目の工程の成果物にあたり、構築とデータ移行の両方が参照する基準になります。
最初から全部署分を設計せず、スモールスタートで1つの業務の範囲から確定し、運用の結果を見ながら広げる進め方を勧めています。準委任で伴走する形なら、設計書のレビューを定例の場に組み込めるため、決定が遅れにくくなります。AI（Breezeなど）を使う業務がある場合は、AIが読み書きするプロパティを設計書に明記しておくと、入力規則とAIの動作が食い違いません。企業様（チーム）によって最適な形は異なりますので、自社の業務に合わせて章の粒度を調整してください。
後から変える手順を残す
設計書が古くなる主な原因は、変更の手順がないことです。設計書の末尾に、「変更を提案する人」「確認する人」「承認する人」「反映後の更新先」を書いた変更管理の欄を置きます。軽微な変更（ラベルの文言、選択肢の追加）と重大な変更（フィールドタイプの変更、ステージの削除、権限の拡大）で承認の重さを分けておくと、運用が止まりません。
設計書に書く項目の自己点検表
設計書を提出する前に、次の点検表で抜けを確認します。この表は、承認者がレビューの冒頭で使うこともできます。
| 章 | 確認すること | 抜けた場合の影響 |
|---|---|---|
| 前提 | プランと上限、対象外の範囲が書かれている | 構築途中で作れないと判明する |
| オブジェクト | 1件の定義、関連付け、内部名が決まっている | 同じ実体が複数のレコードに分かれる |
| プロパティ | 内部名、タイプ、必須、入力者が揃っている | 重複項目が増えレポートが崩れる |
| パイプライン | 入る条件・出る条件、成約と失注の確度がある | 予測とレポートが正しく集計されない |
| 権限 | 役割別の対応表と、設定変更者が限定されている | 設計外の変更が入り込む |
「決め切れない項目」は、空欄にせず、暫定値と見直しの時期を書いて確定します。空欄のまま構築に入ると、構築担当者が自分で決めてしまい、後から根拠が追えなくなります。
よくある質問
Q1. 基本設計書は、どのくらいの分量で書けばよいですか？
分量より、決める項目が揃っているかで判断します。5章それぞれに、前提、オブジェクト、プロパティ、ステージ、役割別権限の表があれば、最小の形は成立します。最初は1つの業務の範囲で書き、運用で必要になった項目を追記する形が、更新されやすい文書になります。
Q2. 設計書はスプレッドシートとドキュメントのどちらで作りますか？
プロパティやステージのような表形式の定義は、スプレッドシートが扱いやすい一方、前提や判断の理由は文章で残したほうが読み手に伝わります。両方を使う場合は、1つの文書を正とし、もう一方からリンクで参照する形にして、二重管理を避けます。企業様（チーム）によって最適な形は異なりますので、普段使う文書ツールに合わせてください。
Q3. 構築しながら設計を変えてもよいですか？
変えて構いませんが、設計書を先に直してから構築に反映する順にします。構築が先行すると、設計書が追いつかず、どれが正かが分からなくなります。変更管理の欄に、軽微な変更と重大な変更の承認ルールを書いておくと、小さな変更が止まらずに進みます。
Q4. 権限セットが使えないプランでは、権限をどう設計しますか？
公式ナレッジでは、権限セットの作成・編集にはEnterpriseが必要です。それ以外のプランでは、ユーザーの「アクセス」タブから権限を編集します。役割別の権限の対応表を設計書に残し、新しいユーザーを追加するたびに表のとおりに設定する運用にすると、設定の揃い方を保てます。
Q5. 基本設計書と、移行の設計はどう関係しますか？
データ移行は、基本設計書のプロパティ定義とオブジェクトの定義を、移行元の項目との対応表に落とす作業です。内部名とフィールドタイプが確定していないと、取り込みの対応づけが定まりません。移行の検証手順を含めた進め方は、設計書の確定後に別の計画として作ります。
まとめ：基本設計書は5章を表で揃え、確定してから構築に入る
- 基本設計書は「前提・オブジェクト・プロパティ・パイプライン・権限」の5章で構成し、ワークフローなどの詳細設計とは分ける
- 内部名のように作成後に編集できない項目は、設計書で表にして先に承認を取る
- データモデルの「制限」タブで契約プランの上限を確認し、前提の章に書いて設計の選択肢を決める
- 取引パイプラインでは「成約」と「失注」の確度を必ず含め、ステージは最小で始める
- 権限は役割から組み立て、設定を変更できる人を限定する
最初の一歩は、現在の業務を1つ選び、その範囲でオブジェクトの一覧表と、プロパティの項目表の雛形を作ることです。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
出典（公式ナレッジ）：
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
