%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段階と引き継ぎの型を整理しました。
HubSpotの社内管理者とは、権限を持つ人ではなく、設定・データ・ユーザーの状態を定期的に点検し、変更の理由を残す運用の責任者です。 HubSpotの画面上の「スーパー管理者」は権限の名前であり、日々の運用業務はその権限を持つ人が自動的にこなしてくれるわけではありません。運用担当を決め、見る画面と頻度を決めて初めて、導入時の設計が保たれます。
導入の時点では整っていた設定が、半年たつと担当の異動、プロパティの増殖、動かなくなったワークフロー、退職者が所有したままのレコードで崩れていく——。多くの場合、原因は操作の難しさではなく、点検する人と頻度が決まっていないことにあります。
この記事では、運用担当が日次・週次・月次・四半期に行う業務を、HubSpotの公式ナレッジで確認できた画面名と合わせて整理し、担当者を育てる段階と引き継ぎの型までを示します。
- 権限と役割は別物として決める ── スーパー管理者の権限は最小限にし、業務の担当は役割で定義します
- 業務は頻度で分ける ── 日次はエラー確認、月次はデータ品質と権限、四半期は設計の見直しです
- ユーザーの入退社には順序がある ── 無効化、レコードの再割り当て、削除の順で進めます
- 変更履歴は監査ログで追える ── 見られる範囲はプランで異なるため、事前に確認します
- 管理者は3段階で育てる ── 閲覧、軽微な変更、設計判断の順に任せる範囲を広げます
管理者の役割は「権限」と「業務」に分けて考える
「管理者を決めてください」と言われたとき、最初に整理したいのは、HubSpotの権限としての管理者と、社内の業務としての管理者が別のものだという点です。この2つを混ぜると、権限を渡す人数が増えすぎるか、業務の担当が誰にも割り当たらないかのどちらかになります。
HubSpotの権限としての「スーパー管理者」
公式ナレッジのHubSpotユーザー権限ガイド（HubSpotナレッジベース）では、権限の中核にあたるものとして「スーパー管理者」が説明されています。スーパー管理者は、有料のSales HubとService Hubの機能を除き、ガイドに記載のあるすべてのツールと設定にアクセスできます。ほかのユーザーをスーパー管理者にできるのも、スーパー管理者だけです。また、スーパー管理者の権限セットは変更できません。
権限の設定画面は、上部の設定アイコンから、左サイドバーの［ユーザーとチーム］を開きます。権限は、CRM、マーケティング、Sales、サービス、データ管理、自動化、レポート作成、収益、AI機能、アカウントなどのタブに分かれています。つまり、最初から「営業用」「経理用」といった固定の役割が用意されているのではなく、タブごとの権限の組み合わせで役割を作る設計です。
社内の業務としての運用担当
一方、運用担当は業務上の役割です。プロパティの追加依頼を受ける、ワークフローのエラーを確認する、退職者のレコードを再割り当てする、といった定期業務の持ち主を指します。運用担当は、必ずしもスーパー管理者である必要はありません。確認と軽微な修正に必要な権限だけを渡し、アカウント全体に影響する変更は別の人が承認する形にもできます。
次の表は、権限と業務を切り分ける考え方の一例です。企業様（チーム）によって最適な形は異なりますので、自社の体制に合わせて読み替えてください。
| 項目 | 権限としての管理者 | 業務としての運用担当 |
|---|---|---|
| 決める単位 | ユーザーごとの権限セット | 定期業務ごとの持ち主 |
| 人数の考え方 | 必要最小限に絞る | 業務の量に合わせて複数人で分担する |
| 主な判断 | 誰にどこまでの操作を許すか | 何を、どの頻度で、どの画面で確認するか |
| 記録に残すもの | 権限の付与・変更の理由 | 点検の結果と、依頼への対応履歴 |
管理者を「誰にするか」より先に、「どの業務を誰が持つか」を書き出します。業務の持ち主が決まれば、必要な権限は後から逆算できます。
日次・週次・月次・四半期に分けた業務一覧
運用担当の業務は、頻度で分けると抜けが見えます。ここでは、公式ナレッジで画面と手順を確認できたものを中心に、頻度ごとに整理します。頻度や項目は一例であり、ユーザー数や自動化の量で増減します。
| 頻度 | 主な業務 | 確認する画面 |
|---|---|---|
| 日次 | 自動化の問題の確認、ユーザーからの依頼の受付 | ワークフロー、自動化の問題を確認 |
| 週次 | 重複候補の確認、入退社・異動の反映 | データ品質、ユーザーとチーム |
| 月次 | データ品質の傾向確認、権限の棚卸し、監査ログの確認 | データ品質、ユーザーとチーム、監査ログ |
| 四半期 | プロパティ・ワークフロー・パイプラインの見直し、運用ルールの更新 | 各設定画面、運用ルールの文書 |
この表で重要なのは、日次の作業を重くしないことです。毎日やる作業は、数分で終わる確認に絞ります。判断が必要な見直しは、月次か四半期にまとめたほうが、他の業務と両立します。
日次業務は「止まっているものがないか」の確認に絞る
日次の確認は、自動化が止まっていないか、依頼が滞留していないかの2点です。変更や新規構築は日次に入れません。毎日の確認で修正まで抱え込むと、運用担当の時間が尽き、点検そのものが続かなくなります。
月次・四半期は「判断が要る見直し」に使う
月次では、データ品質の傾向と権限の棚卸しを行います。四半期では、使われていないプロパティやワークフローの整理、パイプラインのステージ定義の見直しといった、設計に関わる変更を扱います。四半期の見直しでは、変更の前後で何が変わるかを説明できる形で記録しておきます。
日次業務：ワークフローの問題を毎日確認する
自動化は、動いているように見えて止まっていることがあります。登録されたレコードでエラーが起きていても、画面を開かなければ気づけません。日次の確認は、ここに絞ると効果が大きくなります。
公式ナレッジの一般的なワークフローエラーのトラブルシューティング（HubSpotナレッジベース）によると、エラーのあるワークフローの確認は、［その他］＞［自動化］＞［ワークフロー］から入り、右上の「自動化の問題を確認」で行います。［その他］が表示されない場合は、ワークフローに直接移動します。
自動化の問題を確認する手順
- ワークフローの画面を開き、右上の「自動化の問題を確認」をクリックします。
- 左上の問題件数のドロップダウンから、「〜件の自動化」を選びます。
- 表の「作成者」ドロップダウンで「ワークフローツール」にチェックを入れます。
- 対象ワークフローの名前にマウスを合わせ、「問題を確認」をクリックします。
- 問題の説明にマウスを合わせて「問題を確認」をクリックし、詳細を表示します。
- 原因がワークフローの設定にある場合は「自動化を編集」から、レコード側にある場合は該当レコードを開いて修正します。
- 対応後、「ステータス」のドロップダウンから「修正」「無視」「延期」のいずれかを選び、必要に応じてメモを残します。
最後のステータスとメモが、運用の引き継ぎで効きます。「無視」や「延期」を選んだ理由が残っていれば、担当が替わっても同じ問題を最初から調べ直さずに済みます。
エラーの種類で最初の対処を決めておく
公式ナレッジには、よくあるエラーの原因と対処が整理されています。運用担当が最初の切り分けをできるように、次のような対応表を社内で持っておくと、日次の確認が短くなります。
| 起きていること | 最初に確認すること |
|---|---|
| 関連レコードがなく「レコードを編集」が実行できない | 関連付けの有無、登録条件に関連の有無を確認する条件があるか |
| ライフサイクルステージを逆方向へ更新しようとした | 先に値をクリアしてから設定する手順になっているか |
| 同じメールアドレスや会社ドメインのレコードがあり作成に失敗する | 既存レコードを確認する分岐、または関連付けのアクションに替えられないか |
| マーケティング対象外のコンタクトにメールを送ろうとした | 登録条件がマーケティングコンタクトに限定されているか |
レート制限やタイムアウト、Webhookの失敗といった情報ログは、通常は自動的に再試行されます。繰り返し発生する場合に限り、アカウント内の他のワークフローの負荷や、外部サービスの応答状況を確認します。ワークフロー自体の設計は、HubSpotワークフローの設定方法の記事も参考になります。
週次・月次業務：重複とデータ品質を定期的に点検する
データの乱れは、一度に起きるのではなく、少しずつ積み上がります。重複したコンタクト、書式の揺れ、空のプロパティが増えると、レポートの数字が信用されなくなり、入力する側の意欲も下がります。運用担当が週次と月次で見る対象を、画面ごとに決めておきます。
データ品質ツールで全体の状態を見る
公式ナレッジのデータ品質ツールを使用する（HubSpotナレッジベース）によると、データ品質ツールは「その他」から「データ管理」＞「データ品質」で開きます。ここでは、データの概要、重複の管理、書式の問題の修正、レコードエンリッチメントの管理、プロパティ分析を扱えます。概要ページを閲覧できるのは、スーパー管理者、またはデータ品質ツールのアクセス権と表示権限を持つユーザーです。
重複の上限超過テーブル、プロパティ異常のアラート、自動修正ルールなどは、Data HubのProfessionalとEnterpriseの機能と記載されています。使えるプランによって点検の方法が変わるため、運用ルールを作る前に、自社のプランで何が使えるかを確認しておきます。
重複の管理は「確認、マージ、却下」の3操作
重複の管理は、公式ナレッジの重複レコードを管理する（HubSpotナレッジベース）に手順があります。コンタクトまたは会社の画面で、右上の「アクション」から「重複を管理」を開き、ペアごとに2つのレコードのプロパティを比較します。
デフォルトの判定は、コンタクトでは名、姓、Eメールアドレス、IPの国、電話番号、郵便番号、会社名、会社ではドメイン名、会社名、国／地域、電話番号、業種が基準です。判定は新規作成時に行われ、さらに1日1回の確認があります。ここで運用担当が守るべき点は2つです。
- マージは元に戻せない。 一括マージの前に、関連付けられたレコードを確認します
- 却下は取り消せる期間が限られる。 却下から最大14日以内であれば「履歴のビュー」から元に戻せます
却下の取り消しに期限があるため、重複の確認は週次で行い、迷うペアは却下せずに保留して担当者に確認します。この運用は、データ移行後の整理にも共通します。移行時の重複の扱いは、CRMデータクレンジングの設計と運用でも整理しています。
月次点検に使う観点表
月次では、数字の大小よりも、乱れの発生元を特定することに絞ります。次の表は、乱れの種類ごとに発生元の候補をたどるための例です。
| 乱れの種類 | 発生元の候補 | 特定の手がかり |
|---|---|---|
| 重複 | フォーム、インポート、外部連携 | 重複ペアの作成元の情報と作成日を比べる |
| 書式の揺れ | 手入力、インポート時の列対応 | 書式の問題の画面で、対象プロパティと件数を確認する |
| 空欄 | 入力画面の項目設定、ワークフロー | 空欄のレコードの作成経路を共通点から探す |
| 使われないプロパティ | 作成後に運用へ載らなかった項目 | プロパティ分析の利用状況を見て四半期の整理候補に入れる |
データ品質の点検は、きれいにすることが目的ではありません。乱れの発生元を特定して、乱れが増える仕組みを止めることが目的です。
ユーザーの入退社・異動を管理する手順
運用担当の業務のうち、事故につながりやすいのがユーザーの入退社と異動です。退職したユーザーのレコードが所有されたまま残る、削除したら戻せなかった、といったことが起きるのは、この場面です。
公式ナレッジのHubSpotユーザーの削除（HubSpotナレッジベース）では、ユーザーを削除するには、まず無効化が必要と説明されています。無効化してもユーザーのプロファイルや関連データは残り、後から再有効化できますが、削除するとプロファイルとそれに紐づく情報がアカウントから消えます。削除したユーザーは復元できません。
退職・異動のときの標準手順
- 設定アイコンから［ユーザーとチーム］を開き、対象のユーザーを確認します。
- そのユーザーが所有するレコード（コンタクト、会社、取引、チケット）の引き継ぎ先を決めます。
- 所有者を引き継ぎ先に再割り当てします。担当者の割り当てを自動で行うワークフローがある場合は、条件にそのユーザーが入っていないかを確認します。
- 日程設定ページやミーティングのローテーションにそのユーザーが含まれていれば、外すか再割り当てします。ユーザーが所有するアセットや、ワークフローの条件に含まれる場合は、各ツールから手動で外す必要があります。
- ユーザーを無効化します。この時点では復元できるため、一定期間は無効化の状態で運用します。
- 問題がないことを確認してから、必要な場合に限って削除します。アカウント・請求設定の担当者に設定されている場合は、その役割から外してから削除します。
この手順の要点は、削除を最後に置くことです。無効化の状態で数週間置いても、レポートやワークフローへの影響を確認する時間が取れます。担当者の割り当て設計は、HubSpotパーミッション権限設計ガイドと合わせて決めておくと、異動のたびに迷いません。
入社・異動のときに決めておく項目
新しいユーザーを追加するときは、役割ごとに権限の雛形を持っておくと、付与のばらつきを防げます。権限は、チームに所属させる、オブジェクトごとに「全て」「チーム」「自分」を選ぶ、ツールごとに「表示」「編集」「公開」を選ぶ、といった単位で設定できます。雛形がない状態で個別に付けていくと、半年後に誰が何をできるのかを説明できなくなります。具体的な設計の考え方は、HubSpot権限設定・チーム管理ガイドでも扱っています。
監査ログで「誰が何を変えたか」を追う
設定が変わって数字が動いたとき、原因を探す最短の手段が監査ログです。運用担当が月次で見る対象に加えておくと、勝手な変更や誤操作の早期発見につながります。
アカウントアクティビティー履歴の表示とエクスポート（HubSpotナレッジベース）によると、監査ログは、設定アイコンから［アカウント管理］の［監査ログ］で開きます。表示とエクスポートにはスーパー管理者の権限が必要です。ここで運用担当に監査ログの閲覧を任せる場合は、スーパー管理者の権限が必要になる点を踏まえて、体制を決める必要があります。
見られる範囲はプランで異なる
記録されるのはHubSpotユーザーによる操作のみで、フォーム送信など、ユーザーが行っていないプロパティ更新は含まれません。ログインとセキュリティのアクティビティは全プランで利用できます。承認・ワークフローなどの記録が使えるプランは、公式ナレッジの記載が箇所により異なるため、自社の監査ログ画面で対象カテゴリを確認します。一元化ログの各ビューは過去30日分を表示し、コンテンツアクティビティの保持期間は、Starter・Professionalが365日、Enterpriseが無制限と記載されています。
| 見たいこと | 確認できる可能性 | 注意点 |
|---|---|---|
| ログインの履歴 | 全プランで利用可能 | 表示は過去30日分のビュー |
| ワークフロー・承認の変更 | 利用できるプランは自社の画面で確認 | プランが対象外の場合は別の記録が必要 |
| フォーム送信による更新 | 監査ログには含まれない | 記録対象はユーザー操作のみ |
| ユーザー分析 | Enterpriseが必要 | 他のタブとは対象プランが異なる |
監査ログで追えない範囲がある以上、重要な設定変更は、変更の理由と日付を運用担当が自分で残すのが確実です。変更履歴の書き方は、四半期の見直しで使う書式と同じものにそろえると、保守の負担が減ります。
運用担当を育てる3段階と、引き継ぎの型
管理者の人選より難しいのは、担当者が替わっても運用が続く状態を作ることです。特定の人しか設定を知らない状態は、その人の異動や退職で運用が止まります。育成は、任せる範囲を段階的に広げていくのが現実的です。
任せる範囲を3段階で広げる
次の表は、任せる範囲を広げていく段階の一例です。各段階の終わりに、次へ進んでよいかを判断する基準を置きます。
| 段階 | 任せる範囲 | 次へ進む基準 |
|---|---|---|
| 第1段階：確認 | 日次のエラー確認、重複候補の閲覧、依頼の受付 | 確認結果を記録し、判断が要るものを切り分けられる |
| 第2段階：軽微な変更 | ユーザーの追加・無効化、プロパティの説明文の更新、リストの作成 | 変更の前後を記録し、影響範囲を説明できる |
| 第3段階：設計判断 | プロパティ・ワークフロー・パイプラインの追加や変更、権限の設計 | 変更の理由と、戻し方を文書で残せる |
第3段階の変更は、スモールスタートで試してから広げる考え方が有効です。いきなり全体へ反映するのではなく、特定のチームや一部のレコードで動きを確認し、問題がなければ範囲を広げます。
引き継ぎの文書に残す5項目
運用担当が替わるときに、次の5項目が文書になっていれば、引き継ぎは短く済みます。
- 定期業務の一覧（頻度、確認する画面、判断基準）
- 権限の雛形と、付与の判断基準
- ワークフローの一覧と、止まったときの連絡先
- 過去の変更履歴（日付、変更内容、理由）
- 未解決の課題と、保留にしている判断
この文書は、設計の段階から作り始めるのが理想です。導入後に作ろうとしても、設計時の判断理由は思い出せません。
StartLinkの定着支援での進め方
StartLinkはHubSpotゴールドパートナーとして、導入の工程を、現状の整理・要件定義、設計・構築、データ移行、テスト・検証、定着・運用改善の流れで進めています。運用担当の育成は、最後の定着・運用改善の工程に位置づけ、準委任の伴走で、日次・月次の業務を一緒に回しながら、確認から設計判断へと任せる範囲を広げていきます。
運用の中でAIを使える場面もあります。たとえば、Breezeを使った問い合わせの分類や、Claudeを使った点検結果の要約など、運用担当の確認作業を減らす設計も可能です。ただし、AIに任せる範囲は、人が判断する箇所を先に決めてから決めます。運用体制の全体像は、HubSpot運用体制の構築ガイドや、CRMが定着しない原因と対策も併せてご覧ください。
運用担当の置き方を自社に当てはめて決める
最後に、自社にどの体制が合うかを決める判断表です。担当を何人置くか、社内で持つか、外部の伴走を使うかは、ユーザー数と自動化の量、変更の頻度で決まります。
| 状況 | 向いている置き方 | 注意点 |
|---|---|---|
| ユーザー数と自動化の量が限られる | 兼務の担当を1名、予備を1名 | 予備がいないと、休暇で日次の確認が止まる |
| 複数チームが使い、ワークフローが多い | 業務ごとに担当を分け、まとめ役を置く | 変更の承認ルートを決めないと設定が競合する |
| 社内に詳しい人がおらず、設計も見直したい | 外部の伴走で設計と運用を並行して進める | 社内に残す文書と、任せる範囲を最初に合意する |
| 複数の事業やポータルを運用している | 共通ルールを定める担当と、事業ごとの担当を分ける | 権限と命名規則を事業間でそろえる |
どの体制でも共通するのは、担当が替わっても文書で運用が続くことと、日次の確認を止めないことです。自社の運用の全体像を設計から見直したい場合は、HubSpot導入支援のサービスの内容も参考にしてください。導入から定着までの全体の流れは、HubSpot導入・活用・定着ガイドにまとめています。
よくある質問
Q1. スーパー管理者は何人までにするのがよいですか
人数の上限を一律に決める必要はありませんが、必要最小限に絞るのが基本です。スーパー管理者は、ほかのユーザーのスーパー管理者への昇格、アカウント全体の設定、監査ログの表示ができるため、権限が広すぎます。日々の運用担当には、確認と軽微な変更に必要な権限だけを渡し、アカウント全体に影響する変更は別の承認を挟む形が安全です。
Q2. 運用担当はスーパー管理者である必要がありますか
必須ではありません。データ品質ツールは、スーパー管理者のほか、データ品質ツールのアクセス権と必要なオブジェクト権限を持つユーザーも使えます。ただし、監査ログの表示とエクスポートはスーパー管理者の権限が必要です。担当させたい業務ごとに、必要な権限を公式ナレッジで確認して決めます。
Q3. 退職者のアカウントは、すぐ削除してよいですか
すぐに削除せず、まず無効化することをおすすめします。無効化は後から再有効化できますが、削除は復元できません。レコードの再割り当てと、ワークフロー・日程設定ページなどからの除外を済ませ、影響がないことを確認してから、必要に応じて削除します。
Q4. 日次の確認にはどのくらいの時間を見ればよいですか
自動化の問題がなければ、短時間で終わる確認です。時間がかかるのは、エラーの修正が必要な日です。確認と修正を同じ時間枠に入れず、修正は別の枠に回すと、点検が途切れません。
Q5. 運用担当が替わるとき、最低限何を引き継げばよいですか
定期業務の一覧、権限の雛形、ワークフローの一覧と連絡先、変更履歴、未解決の課題の5項目です。口頭の説明だけでは、判断の理由が伝わりません。文書にしておけば、新しい担当が自分で確認できます。
まとめ：管理者は権限ではなく、点検の習慣で決まる
- 権限と業務を分ける。 スーパー管理者は必要最小限にし、運用担当は定期業務の持ち主として決めます
- 業務は頻度で分ける。 日次はワークフローの問題の確認、週次は重複、月次はデータ品質・権限・監査ログ、四半期は設計の見直しです
- ユーザーの退職は、再割り当て、無効化、削除の順で進める。 削除は復元できないため最後に置きます
- 監査ログの範囲はプランで違う。 追えない変更は、理由と日付を自分で残します
- 管理者は確認、軽微な変更、設計判断の順に育てる。 引き継ぎ文書の5項目を最初から残します
最初の一歩は、現在の定期業務を書き出し、頻度と担当を一覧にすることです。担当が決まっていない行が、運用の抜けです。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
