HubSpotの権限設定で相談が持ち込まれるとき、原因はたいてい同じところにあります。導入初期に数人で立ち上げたため全員をスーパー管理者にし、利用部門が増えても誰も戻さなかった。結果として、誰でも取引を削除でき、誰でもワークフローを止められ、誰でも全件エクスポートできる状態のまま、従業員1,000名規模の組織に展開されている。情報システム部門の監査で指摘を受けてはじめて、権限を一から設計し直すことになります。
権限の一つひとつが何を意味するかは、調べればすぐに分かります。難しいのはそこではなく、自社の役割をどう切り、どの単位でアクセスを絞り、異動や退職のたびに何を付け替えるかという設計のほうです。本記事では、権限セットとチームを軸に、設計から運用・監査までの考え方を整理します。個々の権限項目の意味はHubSpot権限とは？既定の権限セットやカスタム権限セットの違いで扱っているため、本記事は設計論に絞ります。
目次
HubSpotのアクセス制御は、ひとつのスイッチで決まるものではありません。シート、権限セット、個別権限、チーム、レコード共有、プロパティ単位のアクセス、パイプラインのステージルールという複数の層が重なり、最終的に「このユーザーはこのレコードのこの項目をどうできるか」が決まります。層の関係を理解しないまま個別のスイッチを触ると、絞ったつもりが絞れていない、という状態になります。
シートはサブスクリプションに応じてユーザーがどのツールにアクセスできるかを決め、権限は表示・編集・削除といった具体的な操作を定義します。つまりシートは「入れる部屋」、権限は「部屋の中でできること」です。
Starter・Professional・Enterpriseのすべてのユーザーにシートが割り当てられ、閲覧専用シートはこれらのサブスクリプションで無料かつ無制限です。閲覧専用シートのユーザーはレコード・ダッシュボード・レポートの閲覧とフィルタリング、閲覧できるレコードへのメモの記録ができます。一方でレポートの保存、レコードの編集、設定の変更、スーパー管理者の付与はできません。コア、セールス、サービスのいずれかのシートから閲覧専用シートに変更すると、Eメールのロギングが無効になります。
この区別を押さえておくと、ライセンス費用の議論と権限設計の議論を分けて進められます。「参照だけさせたい部署」に有償シートを割り当てる必要はありません。逆に、有償シートを割り当てたからといって、その人に全件へのアクセスを与える必要もありません。各シートで利用できる機能は製品・サービスカタログで定義されており、内容は変更される可能性があります。
権限セットは、役割ごとの権限の束をテンプレート化し、ユーザーに割り当てる仕組みです。権限セットはMarketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Revenue HubのいずれかのEnterpriseで利用でき、作成と編集にはスーパー管理者権限が必要です。アカウントあたり最大100個まで作成できます。
設計上、重要な挙動が3つあります。第一に、権限セットを割り当てると個人に設定していた権限が上書きされます。第二に、ユーザーに与えられるアクセスは、割り当てられた権限セットとシートで利用できる機能の組み合わせのうち最大のものになります。第三に、ユーザーの追加・編集権限を持つ担当者は、自分が持っている権限を含む権限セットしか割り当てられません。権限セットを後から編集すると、そのセットが割り当てられた全ユーザーに即座に反映されます。変更の影響範囲を事前に確認してから保存してください。
なお、権限セットをチームに対して直接割り当てる設定について、公式ドキュメントに記載は確認できませんでした。権限セットはユーザー単位の割り当てであり、チームはレコードの可視範囲とレポートの単位です。この2つを混同したまま設計すると、「チームを作ったのにアクセスが変わらない」という行き違いが起きます。
権限設計を画面の上で始めると、必ず迷子になります。CRM・マーケティング・セールス・サービス・自動化・レポート・AI機能・アカウントと、タブごとに数十個のスイッチが並ぶためです。先に紙の上で役割と権限の対応表を作り、それを画面に写す順序にしてください。
部署名で切ると破綻します。営業部といっても、インサイドセールス、フィールドセールス、営業企画、営業事務では必要な権限がまったく違うからです。私たちが大企業の権限設計を支援する際は、部署ではなく「データに対する関わり方」で切っています。具体的には、データを作る人、データを更新する人、データを見る人、データの構造を変える人、データを外に出す人の5区分です。
この5区分のうち、特に慎重に扱うのは「データの構造を変える人」と「データを外に出す人」です。前者はプロパティ設定の編集権限（Edit property settings）に相当し、オブジェクトのプロパティの作成・編集・アクセス管理に加えて、パイプラインとステージの作成・編集も可能にします。後者はエクスポート権限で、エクスポート、承認なしのエクスポート、エクスポートの承認という3つのスイッチが別々に用意されています。
マトリクスの列は役割、行は権限項目にします。行として最低限押さえるべき項目を権限の区分に沿って整理すると、次のようになります。すべての項目を書き出す必要はなく、社内で揉める項目だけを明示的に決めるのが実務的です。
| 区分 | 決める項目 | 典型的な分岐点 |
|---|---|---|
| CRMオブジェクト | 表示・編集・作成・削除・マージの範囲 | 全件／チームのレコード／自分のレコード／なし |
| CRMツール | 一括削除、インポート、エクスポート、関連付けの編集 | エクスポートを承認制にするか |
| コミュニケーション | メール・通話・ミーティングを記録できる対象 | 全レコード／チームの所有／自分の所有 |
| 自動化 | ワークフローの表示・編集・公開・登録・削除 | 公開権限を限定するか |
| レポート | ダッシュボードの作成・所有、管理者権限 | 管理者権限は他タブの設定を上書きする |
| AI機能 | Breeze Assistant、Agent Builder | エージェントを作れる人を限定するか |
| アカウント | プロパティ設定の編集、監査ログ、ユーザー追加、チーム追加 | 情報システム部門に寄せるか各部門に配るか |
レポートタブの管理者権限は、他のタブの設定を上書きします。「レポートだけ自由に作らせたい」という要望で安易にオンにすると、分析ツール全体へのアクセスが開きます。ユーザー権限の設定画面を触る前に、この上書き関係を押さえておいてください。
テンプレートから始める方法が用意されています。権限セットの作成時には、「スーパー管理者にする」「テンプレートから始める（他のユーザーの権限のコピー、または一般的な役割に基づく推奨セット）」「ゼロから作る」の3つから選べます。既存ユーザーの権限をコピーして新規ユーザーを作る操作も用意されています。
私たちが権限セットを組む際は、役割ごとにゼロから作らず、最小権限のベースセットを1つ作り、それを複製して役割ごとに足していく手順を取っています。複製はClone操作で行えます。足し算で作ると、後から「なぜこの権限が付いているか」を説明できる状態が保てます。引き算で作ると、不要な権限が残っていても気づけません。
チームはレポートの集計単位であると同時に、レコードの可視範囲を決める単位でもあります。組織図をそのまま写すのが自然に見えますが、HubSpotのチームは組織図とは別の制約を持っているため、写す前に仕様を確認してください。
チームはMarketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue HubのProfessionalまたはEnterpriseで利用でき、入れ子のチームを作るにはEnterpriseが必要です。ユーザーを追加チームに割り当てるには、Marketing Hub・Sales Hub・Service HubのProfessionalまたはEnterpriseが必要です。
両者の差は小さくありません。主チームのメンバーは、そのチーム用に設定されたカスタムレコードビューを見られます。追加チームのメンバーは、チームのレコードとコンテンツへのアクセスは得られますが、チームレポートに含まれず、会話のルーティングルールやチーム通知（フォーム通知を除く）、ワークフローのローテーションアクションの対象にもなりません。左サイドバー・中央カラム・右サイドバーのカスタムレコードビューも見られません。「とりあえず追加チームに入れておく」では、レポートもルーティングも機能しません。
レコードの所有者を更新すると、HubSpotチームのプロパティにそのユーザーの主チームが自動で入ります。チーム別の売上レポートが実態と合わない場合、主チームの設定が実態とずれている可能性を先に疑ってください。なお、スーパー管理者は複数の主チームを完全にサポートするベータにアカウントをオプトインでき、この場合は「主チーム」と「追加チーム」が「チーム」フィールドに置き換わります。
入れ子チームは、親チームが配下の所有するものをすべて閲覧でき、配下のチームは親の所有するものをすべて見られるわけではない、という一方向の構造です。管理職の閲覧範囲を自動的に広げる仕組みとして機能します。
一方で、階層を深く作りすぎると運用が持ちません。異動のたびに所属を付け替える必要があり、階層が深いほど付け替えの影響範囲が読めなくなります。私たちが設計する際は、レポートで集計したい粒度と、レコードを見せたい粒度が一致する階層までで止める方針を取っています。作成できるチーム数は、サブスクリプションによって異なります。
権限設計の本丸はここです。「営業担当者には自分の案件だけ見せたい」「特定のステージに入った取引は勝手に動かせないようにしたい」という要求に、HubSpotがどこまで応えられるかを把握しておくと、業務要件の擦り合わせが早く終わります。
各オブジェクトについて、表示・編集・削除の範囲を「すべて」「チームの所有」「自分の所有」から選べます。チームの所有や自分の所有を選んだ場合、未割り当てのレコードを対象に含めるかどうかをチェックボックスで指定できます。
ここで見落とされやすい仕様が3つあります。第一に、スーパー管理者はすべてのレコードを表示・編集・削除・マージできるため、アクセスを制限する前にスーパー管理者権限を外す必要があります。第二に、権限の変更はユーザーが一度ログアウトして再ログインした後に反映されます。第三に、所有者判定は既定の所有者プロパティに加えて、カスタムのHubSpotユーザー型プロパティも対象になります。副担当者をカスタムプロパティで持たせている場合、その人にも所有者としてのアクセスが発生します。
所有者ベースで絞ったうえで例外的に見せたい場合は、レコード共有を使います。レコード共有はEnterpriseの機能で、共有されたユーザーはそのユーザー自身のオブジェクト権限に沿った範囲でレコードにアクセスできます。閲覧権限しかないユーザーに共有しても、編集はできません。誰が共有できるかは「Shared users」「Shared teams」プロパティのアクセス設定で制御します。実際に誰がアクセスできているかは、レコードごとのアクセス一覧で把握できます。
止められます。取引・チケット・プロジェクト・カスタムオブジェクトについて、特定のステージにあるレコードを編集できる対象を、全ユーザー、特定のユーザーとチーム、スーパー管理者のみ、から選べます。ProfessionalまたはEnterpriseが必要です。承認済みの案件を営業が勝手に戻せないようにする、といった統制がここで実装できます。
ただし抜け道もあります。ステージを管理者限定にしても、ワークフロー、フォーキャストツール（取引のみ）、ユーザーIDを伴わないAPIリクエストからは編集できます。関連付けの編集や、アクティビティの作成・記録も止まりません。統制の穴をふさぐには、ワークフローとAPIの権限側も併せて設計する必要があります。
アクティビティにも個別の権限があります。表示権限しか持たないユーザーでもメモやタスクは作成でき、メールや通話といった他のアクティビティを作るにはコミュニケーション権限が必要です。また編集権限を持つユーザーはレコード上のアクティビティを削除できるため、削除させたくない場合は編集権限を外すことになります。
日本の大企業では、商談メモに顧客の内部情報や人事情報が書き込まれることがあります。アクティビティの可視範囲を「自分の記録のみ」に絞るか、機密性の高い情報は後述の機密データプロパティに寄せるか、どちらの方針を取るかを先に決めてください。組織をまたいだ情報の見せ方については組織のサイロ化を解消するで整理した考え方が参考になります。
個人情報保護法は、個人データの取扱いについて安全管理措置を求めています。個人情報保護委員会の個人情報の保護に関する法律についてのガイドライン（通則編）は、組織的・人的・物理的・技術的な安全管理措置を示しており、アクセス制御はこのうち技術的安全管理措置に位置づけられます。HubSpot側の実装手段を把握しておくと、社内規程との対応づけが取りやすくなります。
機密データはEnterpriseの機能で、有効化にはスーパー管理者権限と利用規約への同意が必要です。プロパティを機密としてマークすると、転送中・保存時の暗号化に加えてアプリケーションレイヤー暗号化という追加の層が適用されます。高機密データのプロパティは値が暗号化され、アクセス権を持つユーザーも復号操作をしてから閲覧・編集することになります。
有効化の前に必ず確認すべき制約が2つあります。第一に、一度選択したデータカテゴリーは後から削除できません。追加はできますが、取り消しはできません。第二に、機密データのプロパティは一部のツールで使えません。機密データのプロパティは、パーソナライゼーショントークン、サンドボックス、チャットボット、プレイブックでは利用できません。既定のプロパティを機密データプロパティに変換することもできないため、設計段階で新規のカスタムプロパティとして定義する必要があります。
機密データを使わない場合でも、プロパティ単位のアクセス制御は設定できます。プロパティエディタの「Manage access」タブで、全員が閲覧できる、スーパー管理者のみ、といった設定を選べます。ユーザーとチームごとに閲覧のみ・閲覧と編集を割り当てることもできます。
私たちがプロパティ単位の制御を設計する際は、対象を絞ります。全プロパティに個別のアクセス設定を入れると、誰も全体像を把握できなくなるためです。制御するのは、与信情報、価格の原価、人事評価に類する項目、個人を特定しうる識別子の4系統に限定する方針で運用しています。それ以外はオブジェクト単位の権限で足ります。
機密データプロパティに対する操作は、監査ログで追跡できます。スーパー管理者は、機密データのプロパティ値に関するユーザー操作をあとからたどれます。
権限設計がうまくいっている組織でも、人の出入りで崩れます。退職者のアカウントが残っている、異動した担当者がまだ前部署のレコードを持っている、といった状態は、監査で必ず指摘されます。HubSpot側には手順が整理されているため、社内の人事プロセスと接続してください。
ユーザーを削除するには、まず無効化が必要です。無効化するとログインできなくなりますが、ユーザープロフィールと関連データはレポートと予測のために残り、レコードへの割り当ても維持されます。有償シートは保持されますが、アカウントのシート総数にはカウントされません。削除すると、プロフィールがアカウントから消え、会話やアセットの割り当てが外れ、レポートからも除かれます。
実務上は、退職直後は無効化にとどめ、期末のレポート確定後に削除する二段構えが扱いやすくなります。無効化されたユーザーを再有効化すると、プロパティの変更履歴やコンテンツの更新といった過去の操作履歴は引き続き参照できます。
無効化の前に点検すべき項目は、ひととおり列挙されています。見落としやすいのは、ワークフローのフィルタ条件に個人名が入っているケース、ミーティングのスケジューリングページやラウンドロビンのローテーションに含まれているケース、請求設定の連絡先に指定されているケースです。特にスケジューリングページでは、既定のミーティングリンクを削除することも、所有権を移管することもできません。無効化の前に本人にスケジューリングページをオフにしてもらうか、無効化後にユーザーを削除する対応になります。
無効化したユーザーは、レコード所有者のローテーションアクションでスキップされ、所有者の選択肢からも外れます。個人のメールアドレスの接続も解除されるため、予約されていたシーケンスのメールは送信されません。引き継ぎ先を決めてから無効化するという順序を、人事の退職手続きのチェックリストに入れてください。
放置アカウントの検出は自動化できます。90日以上ログインしていないユーザーを毎月自動で無効化する設定があり、既定でオンになっています。毎月初にHubSpotが対象者を特定し、スーパー管理者に通知、2週間後に対象者本人にもリマインド、前日に最終通知という流れです。たまにしか使わないユーザーは除外設定にできます。
加えて、セキュリティヘルスを使えば、スーパー管理者のアクセス、2要素認証の登録状況、非アクティブユーザー、パートナーユーザーのアクセスといった主要な権限設定をまとめて点検できます。ここでも、90日間ログインしていないユーザーが非アクティブとみなされます。スーパー管理者には四半期ごとに通知が届きます。
権限設計は作って終わりではなく、意図どおりに運用されているかを定期的に確認して初めて統制になります。内部監査やJ-SOXの対象に入っている場合、証跡を出せるかどうかが問われます。
監査ログはMarketing Hub・Sales Hub・Service Hub・Data Hub・Content HubのStarter以上で利用でき、閲覧とエクスポートにはスーパー管理者権限が必要です。「すべてのログ」「ログイン履歴」「セキュリティアクティビティ」の3つのビューがあり、いずれも直近30日が対象です。StarterとProfessionalではログインとセキュリティアクティビティで絞り込め、Enterpriseでは承認、コンテンツ、ワークフローなどのカテゴリーも対象になります。
監査ログの重要な特性として、記録されるのはHubSpotユーザーによる操作に限られる点があります。フォーム送信などユーザー起因でないプロパティ更新は表示されません。また、削除されたレコードは削除から90日以内であれば監査ログから復元でき、エクスポートのログからは実際に出力されたファイルをダウンロードできます。「誰が何を持ち出したか」を後から確認できるのは、情報システム部門にとって説明材料になります。
30日より長い期間のログを画面上で保持する設定について、公式ドキュメントに記載は確認できませんでした。長期保全が必要な場合は、定期的にエクスポートして自社のログ基盤に蓄積する運用にしてください。ログからユーザーの行動パターンを読み解く用途には、監査アナライザーアシスタントが使えます。
監査のたびに観点が変わると、前期との比較ができません。四半期ごとに同じ項目を見る形にしてください。私たちが定着支援の中で点検している項目は、スーパー管理者の人数とその妥当性、エクスポート権限保有者の一覧、90日以上未ログインのユーザー、権限セットごとの所属人数、機密データプロパティのアクセス設定、パイプラインステージの編集制限の6点です。
ログイン方法の制限や2要素認証の方式も、併せて確認します。利用できるログイン方法と承認する2要素認証の方式は、いずれもアカウント単位で制限できます。不審なセッションの確認と強制ログアウトは、ログインセッションの管理画面から行えます。
調査のためにユーザーの画面を再現したい場合、Enterpriseでは他のユーザーとしてログインできます。利用にはいくつかの条件が伴います。この操作自体もセキュリティアクティビティとして記録されます。複数ポータルを運用している場合はマルチアカウント管理、ユーザー属性の一括管理はユーザープロパティと環境設定、新規ユーザーの追加はユーザーの追加と更新の手順に沿って進めます。
権限とチームの初期設定の操作手順は【HubSpot初期設定解説】権限セット、チーム作成、ユーザー追加、セキュリティ設定全般はHubSpotセキュリティー設定とはにまとめています。全社導入でガバナンスが崩れる典型的な失敗についてはCRM全社導入で失敗する企業と成功する企業、データの一元管理の考え方はSSOT（信頼できる唯一の情報源）とはで扱っています。
権限設計を進める過程で、本文の流れには乗らないものの実務で必ず直面する論点をまとめます。
人数の推奨値について、公式ドキュメントに具体的な数値の記載は確認できませんでした。スーパー管理者が少ないほど、リスクの高い操作が発生する可能性は下がります。実務では、情報システム部門とCRM管理者の2系統で合計3名前後に収め、代替要員を含めても5名を超えない構成を目標にしています。
CRMオブジェクトのレコードアクセスに関する権限は、ユーザーが一度ログアウトして再ログインした後に反映されます。また、スーパー管理者権限が残っていると制限が効かないため、先にスーパー管理者を外す必要があります。
絞られません。チームはあくまで所属の定義であり、レコードの可視範囲は各ユーザーのオブジェクト権限を「チームの所有」に設定してはじめて効きます。チームを作っただけで権限側を触っていない状態は、設計漏れとしてよく見つかります。
ユーザー数が10名程度であれば個別設定でも回ります。ただし人数が増えると、同じ役割のはずの2人の権限が微妙に違う、という状態が必ず発生します。監査で「この2人の差は何か」を説明できなくなった時点で、権限セットへの移行を検討してください。既存ユーザーの権限をコピーして新規ユーザーを作る機能は、権限セットがないプランでも利用できます。
渡すこと自体は一般的です。問題はスーパー管理者権限を付けたまま放置することです。パートナーユーザーにスーパー管理者権限を与えると、請求情報の閲覧・管理やユーザーの追加・削除まで可能になります。作業期間と権限範囲を契約で定め、終了時に棚卸ししてください。
選択したデータカテゴリーは、後から削除できません。Enterpriseからダウングレードした場合、スーパー管理者は既存の機密データプロパティを削除できますが、新規作成や詳細の編集はできなくなり、それまで値を見られていた非管理者ユーザーは閲覧も編集もできなくなります。有効化は不可逆な設定として扱ってください。
付け替えの対象を減らす設計に変えるのが現実的です。レコードの可視範囲をチーム基準にせず、所有者基準に寄せたうえで、管理職には入れ子チームの親側に入ってもらう構成にすると、異動時に触る箇所が1人あたり1か所になります。チームのインポートによる一括作成も用意されており、Smart CRMのProfessionalまたはEnterpriseが必要です。
権限設定の画面には、内部名を表示する切り替えがあります。内部名を含めた形で権限セットの一覧を作ると、設定値と提出資料の対応が取りやすくなります。ユーザー単位の一覧は、ユーザー設定のエクスポートと監査ログのエクスポートを組み合わせて作成してください。
本記事に記載したHubSpotの仕様・提供条件・上限値は、2026年10月23日時点で公式ナレッジベースおよび公式ドキュメントを確認したものです。機能および提供条件は変更される可能性があるため、実装前に必ず最新の一次情報をご確認ください。