%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段階と、担当者が空のレコードを含めるかどうかで決まります。設定の入口は、設定アイコンの［ユーザーとチーム］です。
多くの現場で迷うのは、機能の使い方ではなく、どの役割にどの範囲を渡すかという判断です。範囲を絞りすぎれば現場が止まり、広げすぎれば営業の取引金額や顧客情報が意図しない人に見えます。
この記事では、公式ナレッジで確認できた画面の場所と挙動をもとに、次の内容を整理します。
- 範囲の選び方の判断表：「全て」「チーム」「自分」「未割り当て」をどの役割に渡すかを決めます
- 権限セットとチームの役割分担：それぞれが決めるものと、対象プランの違いを確認します
- チームの階層と追加チームの見え方：親チーム・子チームで閲覧がどう流れるかを確認します
- 効かない経路と上書きの落とし穴：作成権限の例外、権限セットの上書き、プロパティ制限の限界を扱います
権限セットとチームは、決めるものが違う
権限セットが決めるのは「何ができるか」、チームと担当者が決めるのは「どのレコードに対してできるか」です。同じ権限でも、範囲を「全て」にするか「自分」にするかで、見えるレコードの件数は大きく変わります。まず、ユーザーを追加するときに関わる3つの要素を分けて押さえます。
| 要素 | 決めるもの | 対象プラン（公式ナレッジの記載） |
|---|---|---|
| シート | ユーザーが使える製品の範囲（コア・Sales・Serviceなど） | Starter以上で種類が異なる。表示のみシートは無料で数に制限なし |
| ユーザー権限 | ツールごとの操作と、CRMオブジェクトごとの範囲 | 基本の権限設定はすべての製品・プラン |
| 権限セット | 権限の組み合わせを名前を付けて保存し、複数ユーザーに割り当てる | Enterprise |
| チーム | 「チームのオブジェクト」の範囲の単位 | ProfessionalとEnterprise |
権限セットがEnterprise限定である点は、設計の前提になります。Professionalでは、ユーザーごとに権限を設定する運用になるため、役割の型をスプレッドシートなどの権限表で管理し、ユーザーを追加するたびに同じ設定を再現します。公式ナレッジ（HubSpotユーザーを追加する（HubSpotナレッジベース））にも、プリセットとチームはProfessionalとEnterprise、カスタム権限セットの保存はEnterpriseと整理されています。
権限セットは「役割の型」、チームは「見える範囲の単位」、担当者は「そのレコードが誰のものか」です。3つを混ぜて考えると、誰に何が見えているのか説明できなくなります。
シートと権限が別物である点も見落とされがちです。公式ナレッジ（シートの管理（HubSpotナレッジベース））では、シートを変更しても権限は自動的には変わらないと案内されています。たとえばSalesシートからコアシートに変えると、関連する権限が有効でも、Sales Hubの一部機能は使えなくなります。
閲覧範囲は「全て・チーム・自分・未割り当て」の4択で決める
CRMオブジェクトの権限は、公式ナレッジ（HubSpotユーザー権限ガイド（HubSpotナレッジベース））によると、表示・編集・削除・マージのそれぞれについて、［全てのオブジェクト］［チームのオブジェクト］［自分のオブジェクト］［なし］から範囲を選びます。チームまたは自分を選ぶと、担当者が未設定のレコードも対象にするかを選べるチェックボックスが現れます。
最初に決めるのは、役割ごとの範囲です。次の表は、判断の観点を整理したものです。企業様（チーム）によって最適な形は異なりますので、自社の運用に合わせて調整してください。
| 役割の例 | 表示 | 編集 | 削除・マージ | 判断の理由 |
|---|---|---|---|---|
| 営業担当 | チーム | 自分 | なし | 同じチームの案件は参考にしたいが、他人のレコードは書き換えさせない |
| 営業マネージャー | チーム | チーム | チーム | 配下の案件を修正し、重複を整理する立場 |
| マーケティング担当 | 全て | 全て | なし | リード全体を見て施策を打つが、削除は管理者に寄せる |
| カスタマーサポート | 全て | 自分 | なし | 問い合わせの文脈で、どの顧客も参照する |
| 経営層 | 全て | なし | なし | 閲覧のみ。シートは表示のみシートを検討する |
削除とマージは、表示や編集と同じ範囲にしないのが基本です。公式ナレッジには、一括削除には専用の権限が必要であること、［編集］を持つユーザーはアクティビティを削除できることも明記されています。「編集を渡したら削除もできる」場面があるため、削除の範囲は編集より狭く決めます。
担当者が空のレコードは、「自分」「チーム」の範囲では［未割り当て］をオンにしないと対象外になる
「自分」や「チーム」の範囲は、レコードの担当者プロパティで判定されます。担当者が空のレコードは、範囲が「自分」「チーム」のユーザーでは、［未割り当て］をオンにしない限り範囲に入りません。「全て」の範囲を持つユーザーやスーパー管理者には、引き続き見えます。たとえば、フォームから流入したコンタクトに担当者が付く前の段階で、営業担当が「自分」の範囲だけを持っていると、そのレコードは、その営業担当には対象外になります。公式の記述は［未割り当て］チェックの説明までで、実際の見え方は設定画面とテスト用ユーザーで確認します。
対策は2つあります。1つは、［未割り当て］を有効にして、担当者が決まる前のレコードを拾えるようにする方法です。もう1つは、ワークフローなどで担当者を即時に割り当て、未割り当ての時間を作らない方法です。担当者の割り当て設計は、HubSpotの担当者割り当て設計で扱っています。範囲の設計と担当者の割り当て設計は、必ずセットで決めます。
カスタムのユーザープロパティにも「自分」の範囲は効く
公式ナレッジ（レコードへのアクセスを割り当てる（HubSpotナレッジベース））では、「自分のオブジェクト」の設定は標準の担当者プロパティだけでなく、HubSpotユーザー型のカスタムプロパティにも適用されると案内されています。たとえば、取引に「サポート担当」というユーザー型のプロパティを作れば、そのユーザーにも取引へのアクセスを付与できます。
ただし、［未割り当て］は標準の担当者プロパティだけが対象で、カスタムのユーザープロパティでは無視されます。複数の担当者を持つ業務では、どのプロパティで範囲を判定させるかを設計書に書いておきます。
チームの階層は、見える方向が一方向になる
チームの作成は、設定アイコンの［ユーザーとチーム］から［チーム］タブを開き、［チームを作成］で行います。公式ナレッジ（チームの作成と管理（HubSpotナレッジベース））によると、チームはMarketing Hub・Sales Hub・Service Hub・Data Hub・Content Hubの ProfessionalとEnterpriseで使え、別のチームの下に置く階層はEnterpriseだけです。
階層での見え方は、次の表のとおりです。
| 構造 | 見える範囲 | 設計上の意味 |
|---|---|---|
| 親チーム | 配下のチームが担当するすべてを閲覧できる | 事業部や本部のマネージャーに適する |
| 子チーム（ネストされたチーム） | 親チームが所有するものすべては閲覧できない | 親が持つデータは子に流れない |
| 追加チーム | そのチームのレコードとコンテンツにのみアクセスできる | チームレポート・割り振りルール・チーム通知の対象にならない |
親は子を見られても、子は親を見られない点が、階層設計の要です。営業本部を親にして東日本・西日本の子チームを作る構成では、本部長は両方の案件を見られ、東日本の担当者は西日本の案件が見えなくなります。この設計は、営業の部門ごとに数字や案件を区切りたい場合に向きます。
追加チームは「アクセスを足す」ための機能で、チーム運用の機能ではない
兼務のメンバーに別チームのレコードを見せたいとき、追加チームを使います。ただし、追加チームのメンバーは、チームレポート・割り振りルール・ワークフローのローテーションアクションの対象にならず、チームのカスタムレコードビューも表示されません。兼務者を営業ローテーションに入れたい場合は、追加チームではなくメインチームでの設計を検討します。
また、複数のチームに所属するユーザーは、いずれかのチームに割り当てられたレコードにアクセスできます。兼務が増えるほど、ユーザーが見える範囲は意図より広がります。定期的に、ユーザーごとの所属チームを一覧で確認します。
権限セットの作り方と、上書きで起きる事故
権限セットは、設定アイコンの［ユーザーとチーム］から［権限セット］タブを開き、［権限セットを作成］で作ります。公式ナレッジ（権限セットを作成して割り当てる（HubSpotナレッジベース））では、作成と編集にスーパー管理者権限が必要で、作成できるのは最大100件と案内されています。
作成の手順は次のとおりです。
- 役割ごとの権限表を作り、名前を役割名で決める（例：営業担当、営業マネージャー）
- ［権限セットを作成］で、スーパー管理者・テンプレート・ゼロからのいずれかを選ぶ
- ［権限を選択］で、CRMオブジェクトの範囲、マーケティング、セールス、自動化、レポート、アカウントの権限を設定する
- ［レビュー］タブで、選択した内容を確認する
- ［ユーザー］タブで割り当て、［作成］を押す
- 割り当て後は、テスト用ユーザーでログインして、見えるレコードの件数を確認する
上書きについて、公式ナレッジは2点を明記しています。権限セットを割り当てると、そのユーザーの個別の権限設定は上書きされること。権限セットを編集すると、その権限セットを割り当てられている全ユーザーに変更が反映されることです。
| 場面 | 起きること | 回避策 |
|---|---|---|
| 個別に権限を足していたユーザーへ権限セットを割り当てた | 個別の追加分が消え、権限が減る | 割り当て前に、個別の追加分を権限表へ書き出す |
| 1つの権限セットを編集した | 割り当て済みの全ユーザーに即時に反映される | 編集前に、対象人数と影響する役割を確認する |
| 自分が持たない権限を含むセットを割り当てようとした | 割り当てできない | 管理を担うユーザーの権限を事前に確認する |
| シートがないユーザーへ割り当てた | 権限セットとシートの組み合わせの範囲でのみ使える | シートと権限セットをセットで管理する |
編集の影響が全員に及ぶため、役割の見直しは「新しい権限セットを複製して作り、ユーザーを段階的に移す」進め方が安全です。公式ナレッジには複製の手順も載っています。
権限だけでは守れない経路と、プロパティ制限の限界
権限を設計しても、適用されない経路があります。公式ナレッジのユーザー権限ガイドでは、「作成」の権限は、ワークフロー、フォーム送信、連携などで作られたレコードには適用されないと明記されています。また、ステージごとの編集制限（取引パイプラインなどで設定）を設けても、ワークフロー、予測ツール、ユーザーIDを含まないAPIリクエストによる編集、関連付けの編集、アクティビティの作成は引き続き可能です。
| 守りたいこと | 権限で止まるもの | 権限で止まらないもの |
|---|---|---|
| 担当外のレコードを編集させない | 画面での編集（範囲が自分・チームの場合） | ワークフローによる更新 |
| 特定ステージの取引を固定する | ユーザーによるフィールド編集 | ワークフロー・APIによる編集、関連付けの編集 |
| レコードを勝手に作らせない | 画面からの作成 | フォーム・連携による作成 |
| 特定の項目を見せない | プロパティのアクセス制限（Enterprise） | APIや手動作成時の設定・編集 |
プロパティ単位の制限は、設定アイコンの［データ管理］の［プロパティー］から、対象プロパティの［その他］＞［アクセス権を管理］で設定します。公式ナレッジ（プロパティーの表示および編集アクセス権を制限する（HubSpotナレッジベース））では、Enterpriseが対象で、セキュリティ対策には推奨されないと明記されています。APIやレコードの手動作成では、制限されたプロパティも設定・編集できるためです。
さらに、表示できないユーザーには、そのプロパティで絞り込んだ保存済みビューのレコードが表示されない影響があります。ワークフローやレポートが正しく読み込まれない場合もあります。公式の注記を踏まえ、プロパティ制限は「表示の整理」として位置づけます。取引金額のような項目を隠したいときは、プロパティ制限だけに頼らず、オブジェクトやツールの権限と組み合わせて設計します。
外部の人・経営層には、シートから先に決める
社外のパートナーや経営層に見せたいだけなら、まず「表示のみシート」を検討します。公式ナレッジでは、表示のみシートは無料で数に制限がなく、閲覧とレポートのフィルタリングはできる一方、レコードの編集・レポートの保存・設定の変更・ツールの管理はできないと案内されています。
ここで注意したいのは、権限の［表示］と、シートの「表示のみ」が別物であることです。権限が「表示」だけでも、メモやタスクは作成できます。反対に、表示のみシートのユーザーは、権限を「編集」にしても、編集はできません。
| 状況 | 向いている設計 | 理由 |
|---|---|---|
| 経営層がダッシュボードと案件を見たい | 表示のみシート＋範囲は全て | 編集事故が構造的に起きない |
| 営業が他チームの案件を参考にしたい | 有料シート＋表示はチーム以上・編集は自分 | 閲覧と編集の範囲を分けられる |
| 外部のパートナーが一部の案件だけ見たい | カスタムのユーザープロパティで範囲を判定する設計を検討 | 担当者とは別の軸でアクセスを与えられる |
| 退職・異動が発生した | 異動先のチームを変更し、担当者を付け替える | 範囲が「自分」「チーム」で［未割り当て］がオフのユーザーには、担当者が空のレコードが見えなくなる |
権限設計をどの工程で進めるか：StartLinkの支援の進め方
StartLinkは、権限の設計を設定作業の最後ではなく、要件定義の段階から扱います。権限は、担当者の割り当てルール、パイプラインのステージ、ワークフローの動きと互いに影響するためです。
| 工程 | 権限・チームに関する作業 | 成果物 |
|---|---|---|
| 現状の整理・要件定義 | 役割ごとの業務と、見る必要があるデータ・見せてはいけないデータを洗い出す | 役割別の権限表（案） |
| 設計・構築 | 範囲（全て・チーム・自分・未割り当て）、チーム階層、権限セットを設計して設定する | 権限セット一覧、チーム構成図 |
| データ移行 | 移行するレコードに担当者を付与し、未割り当ての状態を作らない | 担当者の付与ルール、確認結果 |
| テスト・検証 | 役割ごとのテスト用ユーザーで、見える件数・編集できる範囲を確認する | 役割別の確認結果 |
| 定着・運用改善 | ユーザーの所属チームと権限セットの棚卸し、異動・退職時の手順の運用 | 棚卸しのメモ、運用手順 |
最初から全役割を細かく設計するのではなく、営業担当・マネージャー・閲覧者の3つの型から始めるスモールスタートを勧めています。運用で見えた不足を足してから、チームの階層や追加チームへ広げます。準委任で伴走する形では、設計だけでなく、テスト用ユーザーでの確認や運用開始後の棚卸しまでを一緒に進めます。
権限の設計書には、役割・範囲・担当者の判定プロパティを残します。設計書の書き方は、HubSpotの基本設計書の書き方も参考になります。本番に反映する前に試したい場合は、HubSpotサンドボックスの使い方も確認してください。
権限設計で起きやすいつまずきと回避策
| つまずき | 原因 | 回避策 |
|---|---|---|
| 営業担当から新規リードが見えない | 範囲が「自分」で、未割り当てが無効 | 未割り当てを有効にするか、担当者を即時に割り当てる |
| 権限を変えたのに反映されない | 変更はユーザーが再ログインするまで反映されない | 変更後は、対象ユーザーに再ログインを依頼する |
| 閲覧を制限したのに見えてしまう | 対象ユーザーがスーパー管理者のまま | 範囲を絞る前に、スーパー管理者権限を外す |
| 個別に調整した権限が消えた | 権限セットの割り当ては、ユーザーの個別設定を上書きする | 割り当て前に個別設定を権限表へ書き出す |
| 親チームの担当者が想定より広く見ている | チームの範囲を選んだユーザーには、配下のネストされたチームのレコードも含まれる | 親チームに置くユーザーは、配下すべてを見てよい役割に限る |
| 権限セットを増やしすぎた | 例外ごとにセットを作った | 例外は新しい役割として整理し、上限の100件を意識する |
公式ナレッジの「レコードへのアクセスを割り当てる」には、権限の変更はユーザーがいったんログアウトして再度ログインするまで反映されない旨が、レコード単位の権限の注意点として記載されています。設定後の動作確認は、再ログインを前提に行います。入力のルールまで含めて設計したい場合は、CRM運用ルール設計ガイドも参考になります。
なお、権限設定の全体像や既定の権限セットについては、HubSpot権限設定・チーム管理ガイドと、HubSpotパーミッション権限設計ガイドが整理しています。この記事は、その先の「範囲をどう選ぶか」に絞っています。
よくある質問
Q1. 権限セットは、どのプランから使えますか。
公式ナレッジでは、権限セットの作成はEnterprise版が対象と案内されています。ProfessionalやStarterでも、ユーザーごとに権限を設定することはできます。その場合は、役割ごとの権限表を別に管理して、同じ設定を再現する運用になります。
Q2. チームと権限セットは、どちらから決めればよいですか。
先に、役割ごとにどのレコードを見せるかを決め、その範囲の単位としてチームを作ります。そのうえで、役割ごとの権限の型を権限セットにします。チームを先に作り込むと、後から範囲の単位が合わなくなることがあります。
Q3. 担当者が空のレコードは、営業担当に見えますか。
範囲が「自分」や「チーム」のときは、未割り当てを含めるチェックを入れた場合に限り範囲に入ります。担当者が決まる前のレコードがある運用では、未割り当ての扱いを設計の段階で決めます。
Q4. ワークフローで作成・更新されるレコードにも、権限は効きますか。
「作成」の権限は、ワークフローやフォーム送信、連携で作られたレコードには適用されないと、公式ナレッジに明記されています。また、ステージ編集制限を設けても、ワークフローによる編集は可能です。これらの経路は、ワークフロー側の設計で制御します。
Q5. 特定のプロパティを隠したいとき、プロパティ制限だけで十分ですか。
十分ではありません。公式ナレッジでは、セキュリティ対策には推奨されないと明記されています。APIやレコードの手動作成では制限されたプロパティも編集できるためです。オブジェクトやツールの権限と組み合わせて設計します。
まとめ：権限は「型」「単位」「担当者」の3つに分けて設計する
- 権限セットは役割の型、チームは範囲の単位、担当者は判定の根拠です。3つを分けて設計します
- 範囲は「全て・チーム・自分・未割り当て」から選び、削除とマージは編集より狭く決めます
- 親チームは子チームを見られますが、子チームは親を見られません。追加チームはチーム運用の機能に入りません
- 権限セットの割り当ては個別設定を上書きし、編集は全ユーザーに反映されます。複製して段階的に移します
- ワークフロー・フォーム・APIには権限が効かない場面があります。経路ごとに設計します
最初の一歩は、営業担当・マネージャー・閲覧者の3つの役割について、表示・編集・削除の範囲を表に書き出し、担当者が空になる場面を洗い出すことです。
自社の状況に当てはめた進め方を検討したい場合は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお問い合わせください。
参考にした公式ドキュメント
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
