%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}
この記事の結論
受け入れテストは、構築した設定が業務で使えるかを利用部門が確かめる工程です。ワークフロー・権限・レポートのテストケースと合否の決め方を整理します。
HubSpot導入の受け入れテストとは、構築した設定が「実際の業務シナリオで使える状態か」を、利用する部門が事前に決めた合格基準で確かめる工程です。 構築担当者が「設定どおりに動く」ことを確かめる作業とは目的が違い、現場の担当者が「この画面でこの仕事を最後までやり切れるか」を見ます。
受け入れテストが曖昧なまま本番に切り替えると、ワークフローが想定外のレコードに動く、営業担当が見えるはずの取引が見えない、経営会議のレポートが空白になるといった問題が、切替当日以降の業務の中で発覚します。——テストケースを先に書いておけば、同じ確認を誰が行っても同じ結果になり、合否の判断も揃います。
この記事では、ワークフロー・権限・レポートの3領域を中心に、テストケースの作り方と合否の決め方を整理します。
- 業務シナリオからテストケースを作る ── 設定項目を順に確認するのではなく、現場の仕事の流れを起点にします
- ワークフローは公式のテスト機能の「できること・できないこと」を踏まえて設計する ── シミュレートでは確認できない観点を別の手段で補います
- 権限はロール別の「見える・できる・できない」の表で確かめる ── 反映の時間差やレポート側の設定も確認対象です
- レポートは数字の突合とアクセス権の両方を見る ── 閲覧者によって表示が変わる点を押さえます
- 不具合の重大度と合否の線引きを先に決める ── 切替の判断が人によってぶれません
受け入れテストが他の検証と違う点
導入工程には、目的の違う検証がいくつかあります。受け入れテストをその1つとして位置づけると、何を誰が確かめるのかが整理できます。
データ移行の検証は、元システムとHubSpotの件数や値が一致しているかを見る作業です。構築担当者が設定どおりに動くかを確かめる単体の確認もあります。受け入れテストは、それらが済んだ状態で、利用部門が自分たちの業務を通して確かめる最終の確認です。
| 検証の種類 | 確かめること | 主に確認する人 |
|---|---|---|
| 構築時の動作確認 | 個々の設定が設計書どおりに動くか | 構築担当者 |
| データ移行の検証 | 件数・関連付け・値が元データと一致するか | 移行担当者と業務担当者 |
| 受け入れテスト | 業務シナリオを最後まで実行できるか | 利用部門の担当者 |
受け入れテストは、データ移行の突合が済んだことを前提に、「業務として使えるか」だけを扱います。導入全体の中での位置づけはCRM導入の進め方完全ガイドで整理しています。
合格基準を先に書く理由
受け入れテストで最も揉めやすいのは、テストの途中で「これは不具合なのか、仕様なのか」を議論することです。基準が後から決まると、結果に合わせて基準が動いてしまいます。
そこで、テストを始める前に、合格の条件を文章で合意しておきます。たとえば「重大な不具合が0件」「テストケースの90%以上が合格」のように、判断できる形にします。数字の水準は、企業様（チーム）によって最適な形は異なりますので、業務への影響の大きさから決めます。
テスト範囲は設定項目ではなく業務シナリオから決める
テストの範囲を「作ったプロパティ・ワークフロー・レポートを全部確認する」と決めると、数が膨らむ一方で、業務のつながりが抜け落ちます。取引を作る、担当者が変わる、受注になる、請求の準備をするといった一連の流れの途中で起きる問題は、個別の設定確認では見つかりません。
そこで、要件定義で整理した業務フローから、受け入れテストのシナリオを作ります。1つのシナリオに複数の設定（プロパティ、パイプライン、ワークフロー、権限、レポート）が関わるので、シナリオを実行するだけで設定の組み合わせが確かめられます。
シナリオの切り出し方
シナリオは「誰が・何を起点に・どこまで行うか」の3点で書きます。表にすると、抜けを見つけやすくなります。
| 業務シナリオの例 | 主に関わる設定 | 確認する領域 |
|---|---|---|
| 問い合わせから商談を作り、担当者を割り当てる | フォーム・ワークフロー・担当者 | ワークフロー・権限 |
| 商談を受注にして、請求の準備タスクが作られる | パイプライン・ワークフロー | ワークフロー |
| 営業マネージャーが週次会議の数字を確認する | レポート・ダッシュボード | レポート・権限 |
| 異動した担当者が引き継いだ取引を編集する | 権限・所有者 | 権限 |
シナリオの数は、主要な業務を網羅できる範囲に絞ります。数を増やすことより、「例外のケース」を各シナリオに1つずつ含めるほうが、本番での問題を見つけやすくなります。
範囲に入れないものも書く
テストしないものを明記しておくことも、範囲の決め方の一部です。たとえば、切替後に段階的に導入する機能は、今回の受け入れテストの対象外であることを文書に残します。範囲の外を決めておくと、「テストしたのに問題が出た」という認識のずれを避けられます。
テスト環境とテストデータの用意
受け入れテストでは、本番のデータに影響を与えずに確認できる環境が必要です。環境の選択肢は、利用しているサブスクリプションで変わります。
サンドボックスを使える場合
HubSpotのサンドボックスは、本番アカウントの機能や設定を複製した環境で、公開中のアカウントやエンドユーザーに影響を与えずに変更をテストできます。対象は Marketing Hub、Sales Hub、Service Hub、Data Hub、Content Hub、Smart CRM、Revenue Hub の Enterprise で、作成とデプロイにはスーパー管理者権限が必要です。作成の入口は、設定の「サンドボックス」です（標準サンドボックスアカウントを設定する（HubSpotナレッジベース））。
注意したいのは、複製されないものがあることです。本番の連携は自動ではサンドボックスに接続されず、コンタクトや取引などのレコードIDは本番と異なります。コピー対象外のアセット（たとえばアンケート）に依存するワークフローは、同期もされません。ワークフローがコピーされていても、テスト対象の条件を満たすレコードが無ければ、確認はできません。作成後に必要なテストデータを入れる手順まで、環境準備の作業として見積もります。
サンドボックスの詳しい使い方はHubSpotサンドボックスの使い方で解説しています。
サンドボックスを使えない場合
サンドボックスを使えない場合は、本番アカウントの中にテスト用のレコードを作って確認します。この場合は、テスト用レコードを見分けられる命名にして、確認後に整理する手順まで決めておきます。ワークフローの動作確認は、有効化する前に公式のテスト機能で行い、実際の顧客に動作が走らない状態を保ちます。
| 環境の選択肢 | 向く確認 | 注意点 |
|---|---|---|
| サンドボックス | 構築全体の通し確認 | 連携・ID・一部アセットは別途準備 |
| 本番内のテスト用レコード | ワークフロー・レポートの個別確認 | 命名と後片付けのルールが必須 |
ワークフローのテストケースの作り方
ワークフローは、受け入れテストで問題が出やすい領域です。条件の読み違いや、分岐の順序、再登録の設定によって、設計意図と違う動きになることがあります。設計の考え方はMAワークフロー設計ガイドで扱っているので、ここでは受け入れテストの観点に絞ります。
公式のテスト機能でできること
HubSpotには、ワークフローの動作を事前に確かめるテスト機能があります。「自動化」＞「ワークフロー」で対象のワークフローを開き、登録トリガーのボックスから「Test」で、特定のレコードが登録条件を満たすかを確認できます。右上の「テスト」では、レコードが登録されてからどのアクションを通るかをシミュレートできます（ワークフローをテストする（HubSpotナレッジベース））。
分岐のあるワークフローでは、レコードが通る経路が緑色で強調されるため、想定した分岐に入るかを確認できます。対象はコンタクト、会社、取引、見積もり、チケットです。利用にはスーパー管理者またはワークフロー権限が必要で、Professional または Enterprise のプランが対象です。
テスト機能だけでは確認できないこと
公式ナレッジには、テスト機能の制限も明記されています。受け入れテストのケースは、この制限を補う形で作ります。
| 公式に記載された制限 | 補うテストケース |
|---|---|
| 実際のアクションは実行されない（結果はシミュレート） | 有効化後の少数のレコードで、実際の結果を確認する |
| 再登録が無効で完了済みのレコードは、条件を満たしても登録されないが、トリガーのテストでは判定されない | 完了済みのレコードで再登録の挙動を別に確認する |
| 前のアクションの出力で決まる分岐は自動選択されない | 分岐ごとに手動で経路を選び、結果を記録する |
| 遅延や再スケジュールの挙動は別途確認が必要 | 遅延を含むワークフローは、実時間での確認日を計画に入れる |
「Eメールを送信」アクションの「プレビューを送信」は、実際にテストメールが送信される例外です。送信先は対象コンタクトではなく自分のメールアドレスですが、プレビューのパス上にある他のEメールもすべて送信されます。受け入れテストの日程には、この動作を事前に周知します。
有効化後の実行結果を確認する
テスト機能で確認したあと、ワークフローを有効にした状態の結果は、ワークフロー詳細ページで確認します。一覧でワークフロー名にカーソルを合わせて「その他」から「詳細を表示」を選ぶと、アクションログ、登録履歴、問題、パフォーマンスの各タブが開きます。アクションログは90日間、登録履歴は6か月間保持されます（ワークフロー詳細ページを理解する（HubSpotナレッジベース））。
失敗したアクションの確認は、アクションログの「イベント」フィルターで「エラー」を選び、「診断」列で理由を見る流れです。受け入れテストでは、テスト記録の「実際の結果」欄に、この画面で確認した事実を書きます。
権限のテストケースの作り方
権限は、設定した本人が最も確認しにくい領域です。管理者権限で画面を見ていると、すべてが見えて、すべてができるためです。
ロール別の確認表を作る
権限の確認は、ロール（営業担当、営業マネージャー、事務担当など）ごとに「見える」「できる」「できない」を表にして、実際にそのロールのユーザーでログインして確かめます。公式ナレッジにも、営業担当には自分が担当するコンタクトのみ、営業マネージャーには全コンタクトとのやり取りを許可するといった設定の例が示されています（ユーザー権限を管理する（HubSpotナレッジベース））。
| 確認する操作の例 | 営業担当 | 営業マネージャー |
|---|---|---|
| 自分の取引を編集する | できる | できる |
| 他の担当者の取引を見る | 設計どおり | 設計どおり |
| レポートの設定を変更する | できない | 設計どおり |
表の「設計どおり」の欄には、要件定義で決めた内容を転記します。実際に確かめるときは、期待する結果と実際の結果を並べて記録します。
権限の確認で見落としやすい点
権限の変更は、システム全体に反映されるまで最大5分かかる場合があり、ユーザーは一度ログアウトして再ログインしないと有効になりません。変更の直後にテストして「反映されていない」と判断しないよう、手順に待ち時間と再ログインを入れておきます。
もう1つは、権限セットの扱いです。権限セットの作成と編集は Enterprise が対象で、ユーザーや権限セット同士を並べて比べる機能も Enterprise で提供されています。利用プランによって使える機能が変わるため、テストケースを作る前に、設計した権限の運用方法がプランの範囲に収まっているかを確認します。権限設計の考え方はHubSpotパーミッション権限設計ガイドで整理しています。
レポートとダッシュボードのテストケースの作り方
レポートは、数字が合っているかと、見る人が見られるかの2つを確認します。
数字の突合
レポートの数値は、元のレコードの一覧と突き合わせて確かめます。たとえば、ステージ別の取引件数のレポートであれば、取引の一覧を同じ条件で絞り込んだ件数と比べます。差が出た場合は、フィルターの条件、日付の基準、担当者の範囲のどれが違うのかを、原因の候補として順に確認します。
レポートの一覧は「レポート」＞「レポート」から開けます。カスタムレポートの作成とカスタマイズは Professional と Enterprise で利用できます（レポートリストでレポートを管理する（HubSpotナレッジベース））。ダッシュボードの数値の設計や予実管理の考え方はHubSpot予実管理とKPIダッシュボードの設定方法に詳しく書いています。
アクセス権の確認
ダッシュボードを開けても、レポートの内容が表示されないことがあります。公式ナレッジでは、ダッシュボードのアクセス権は、個々のレポートの共有設定、レポートフォルダのアクセス権、各レポートに必要なデータへのアクセス権を上書きしないと説明されています（ダッシュボードを管理する（HubSpotナレッジベース））。
そのため、レポートのテストは、閲覧者となるロールのユーザーで次の3点を確かめます。
- ダッシュボードが開けるか
- 各レポートが空白やエラーにならず、期待する範囲の数字が出るか
- 編集が許可されていないレポートを、意図せず変更できないか
レポートのアクセス権が、CRMレコードやフィールドの権限を上書きしない点も重要です。必要な権限がないユーザーには、データの一部だけが表示される場合があります。ダッシュボードのアクセス権の細かい指定（チームやユーザーごと）は Enterprise の機能です。
テストケース票の書き方と合否の決め方
3領域のテストを同じ形式で記録すると、結果の集計と切替判断が楽になります。票の項目は、次の程度に絞ります。
| 項目 | 書く内容 |
|---|---|
| ケース番号・シナリオ | どの業務シナリオの何を確かめるか |
| 手順・期待結果 | 操作の順序と、合格とみなす結果 |
| 実際の結果・判定・重大度 | 画面で確認した事実と、合否、不具合の重さ |
不具合の重大度を先に決める
見つかった不具合の扱いは、重大度の区分を先に合意しておくと迷いません。
| 重大度 | 例 | 切替への影響 |
|---|---|---|
| 高 | 見えてはいけないデータが見える、誤った通知が顧客へ送られる | 修正して再テストするまで切替不可 |
| 中 | 業務は進められるが手作業の回避策が必要 | 回避策と修正時期を決めて判断 |
| 低 | 表示名の誤りなど、業務に支障がない | 切替後の改善項目として記録 |
重大度の「高」に何を入れるかが、受け入れテストの肝です。顧客に影響する誤送信や、権限の漏れは、件数に関係なく高とする運用が一般的です。
再テストの範囲
修正を入れたら、不具合の出たケースだけでなく、同じ設定に関わる他のケースも再確認します。ワークフローの条件を直すと、別の分岐の動きが変わることがあるためです。再テストの範囲は、修正した設定が関わるシナリオを票から引いて決めます。
受け入れテストの進め方
受け入れテストは、段取りを決めて進めると短い期間で終えられます。StartLinkの導入支援では、現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の工程のうち、テスト・検証の工程でこの手順を使い、利用部門と一緒に進めます。
- 範囲と合格基準を合意する ── 業務シナリオ、対象外、合格の条件を文書にします
- 環境とテストデータを用意する ── サンドボックスか、本番内のテスト用レコードかを決めます
- テストケース票を作る ── 領域ごとに期待結果を設計書から転記します
- ロール別のテスト担当を割り当てる ── 実際に使う担当者が、自分のアカウントで実行します
- 実施して、事実を記録する ── 画面で確認した結果と、証跡の置き場を残します
- 不具合を分類し、修正と再テストを行う ── 重大度に沿って対応します
- 合否を判定し、切替の可否を決める ── 合意した基準に照らして判断します
AI（BreezeやClaudeなど）を業務に組み込んだ設計では、AIの出力が人の確認を挟む箇所にも、テストケースを置きます。たとえば、AIが下書きした内容を人が承認するまで送信されないことを、ケースとして確かめます。
テストで見つけた入力・運用の不備を、稼働後にどう定着へつなげるかはCRM運用ルール設計ガイドも参考になります。
受け入れテストの合否は、テストを始める前に決めた基準で判定します。結果を見てから基準を動かさないことが、切替の判断をぶれさせない最大の条件です。
よくある質問
Q1. 受け入れテストは誰が行うのがよいですか？
実際にHubSpotを使う利用部門の担当者が行います。構築した担当者が確認すると、設計意図を知っているために見落としが生じやすくなります。構築担当者は、環境の準備と不具合の修正を受け持ち、テストの実行は利用部門に任せる分担が一般的です。
Q2. サンドボックスが使えない場合、受け入れテストはできませんか？
できます。本番アカウント内にテスト用のレコードを作り、ワークフローは有効化する前に公式のテスト機能で確認します。テスト用レコードの命名ルールと、確認後の整理の手順を先に決めておくことが条件です。サンドボックスの対象は Enterprise のため、利用中のプランを確認してください。
Q3. ワークフローのテスト機能で確認すれば、実際の動作確認は不要ですか？
不要とは言えません。公式ナレッジのとおり、テスト機能は実際のアクションを実行せず、結果はシミュレートです。再登録の挙動や遅延を含む動作は別に確認します。有効化後は、ワークフロー詳細ページのアクションログで実際の結果を見ます。
Q4. 権限を変更したのに反映されません。不具合でしょうか？
権限の更新は、システム全体に反映されるまで最大5分かかる場合があり、ユーザーが一度ログアウトして再ログインしないと有効になりません。まずこの2点を確かめます。それでも変わらないときは、アセットに設定された制限付きのアクセス権が権限より優先されている可能性があります。
Q5. テストケースは何件くらい用意すればよいですか？
件数に決まった目安はありません。主要な業務シナリオを漏れなく通すことと、各シナリオに例外のケースを含めることを基準にします。件数を先に決めるのではなく、業務シナリオの数から逆算します。
まとめ：受け入れテストは「業務シナリオ」「領域別の確認」「先に決めた合否基準」で組み立てる
- 業務シナリオからケースを作る ── 設定の確認ではなく、仕事の流れを最後まで通します
- ワークフローはテスト機能の制限を補う ── 再登録・遅延・実際の送信は別のケースで確かめます
- 権限はロール別の表で確かめる ── 反映の待ち時間と再ログインを手順に入れます
- レポートは数字の突合とアクセス権を両方見る ── ダッシュボードが開けてもレポートが見えるとは限りません
- 重大度と合格基準を先に合意する ── 結果を見てから基準を動かさない運用にします
最初の一歩は、要件定義で整理した業務フローから、主要なシナリオを3〜5本書き出し、各シナリオの合格の条件を一文で決めることです。
導入支援の工程のうち、テスト・検証をどう設計し、どこまでを利用部門が受け持つかを自社の状況に当てはめて検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。HubSpotの導入全体の進め方はHubSpot導入支援サービスでもご紹介しています。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
