【管理者向け】Salesforceの権限管理の要「ロール階層」とは？プロファイルとの違いと設計のコツ

投稿日： 2026.08.31
更新日： 2026.08.25

#Salesforce #プロファイル #権限管理 #ロール階層

「Aさんの商談をBさんに見せたいが、どう設定すればいいかわからない」
「役職変更のたびに権限設定でつまずく」
このような権限管理の悩みは、システム管理者の方からよく相談を受けるテーマです。

これらの悩みの多くは、「ロール階層」という仕組みを正しく理解することで解決の道筋が見えてきます。

本記事では、ロール階層がどういうものかという基本的な内容に加え、プロファイルとの役割の違い、設計時に意識しておきたい考え方について順を追って説明していきます。

ロール階層とは？

ロール階層とは、組織内のユーザーがそれぞれどこまでデータを見られるかを、階層という構造を使って管理する仕組みです。階層の中で上位に位置するユーザーは、自分より下位にいるユーザーが持っているレコードを、特別な操作をしなくても見られるようになります。

ロール階層が必要な理由

Salesforceでは、レコードへのアクセス権限を厳しく制限することができます。たとえば商談を「所有者のみ閲覧可能」に設定した場合、営業マネージャーが部下の商談を確認したくても、そのままでは見ることができません。

そこで活用できるのがロール階層です。ロール階層を設定することで、マネージャーが部下のレコードを自動的に参照できるようになります。個別に共有設定をしなくても、階層構造に基づいてデータアクセスが制御されるため、組織全体の権限管理をシンプルに保つことができます。

ロール階層の基本的な仕組み

ロール階層では、各ユーザーに1つのロールを割り当て、そのロールを階層構造で管理します。上位のロールに属するユーザーは、下位のロールに属するユーザーが所有するすべてのレコードにアクセスできます。

たとえば以下のような階層を設定したとします。
●　営業部長（上位）
　　　○　営業マネージャー（中位）
　　　　　　■　営業メンバーA（下位）
　　　　　　■　営業メンバーB（下位）

営業部長は営業マネージャー・営業メンバーA・Bすべてのレコードを見ることができます。営業マネージャーはメンバーA・Bのレコードを見られますが、営業部長のレコードは見られません。また、メンバーAはBのレコードを見られません。

なお、ロール階層でアクセスできるのは「参照」が基本です。編集権限はオブジェクトの共有設定やプロファイル、権限セットによって別途制御されます。

プロファイルとロール階層の決定的な違い

「プロファイルもロール階層も権限に関わる設定」というイメージはあっても、実際に何が違うのか曖昧なまま運用しているケースは少なくありません。両者の違いを一言でまとめると、プロファイルは「機能」、ロール階層は「レコード」に対する権限を制御するものです。

プロファイルは「何ができるか」を決める

プロファイルは、ユーザーがSalesforce上でどの操作を行えるかを規定します。各オブジェクトに対する作成・参照・更新・削除といった操作のほか、使えるアプリケーションや、表示される項目・タブなど、機能に関連する設定全般が含まれます。

たとえば「商談オブジェクトを編集できるか」「特定のカスタムオブジェクトを表示できるか」といった設定は、プロファイルによって決まります。

ロール階層は「何が見えるか」を決める

一方、ロール階層が制御するのは「どのレコードが見えるか」です。プロファイルによって商談を編集する権限があったとしても、ロール階層の設定によっては他のユーザーが所有する商談レコードは見えない、ということが起こります。

たとえば、営業メンバーAとBに同じプロファイルが割り当てられていたとしても、Aが登録した商談をBが見られるかどうかは、ロール階層の設定と、この後で取り上げる組織の共有設定の組み合わせによって変わります。

両者の関係を整理すると、プロファイルが「操作の許可範囲」を決め、ロール階層がその操作を「どのレコードに対して行えるか」を決める、という構造になっています。この2つを組み合わせることで、組織全体の権限管理が実現されています。

組織の共有設定とロール階層の連動性

ロール階層は単体で機能するわけではなく、「組織の共有設定」と連動して動作します。この関係性を理解していないと、「ロール階層を設定したのにレコードが見えない」といった事象に直面することがあります。

組織の共有設定とは何か

組織の共有設定とは、それぞれのオブジェクトのレコードに対して、組織全体に適用される基本のアクセスレベルを定めるものです。「非公開」「公開/参照のみ」「公開/参照・更新可能」などをオブジェクトごとに設定します。

たとえば商談オブジェクトを「非公開」にした場合、初期状態ではそのレコードを作成した本人以外は、見ることも編集することもできなくなります。組織の共有設定は、Salesforceにおけるアクセス制御の出発点となるものであり、ロール階層や共有ルールは、この出発点を踏まえたうえでアクセスできる範囲を広げていくための機能と考えることができます。

組織の共有設定とロール階層の組み合わせで何が変わるか

ロール階層による自動的な共有が実際に意味を持つのは、組織の共有設定が「非公開」になっているオブジェクトに対してです。「非公開」の状態では、本来であればレコードの作成者しかアクセスできませんが、ロール階層が組まれていれば、上位のロールに属するユーザーは下位のロールに属するユーザーのレコードへアクセスできるようになります。

たとえば、商談を「非公開」に設定している場合、ロール階層によって上位ロールのユーザーは下位ロールのユーザーが所有する商談を自動的に参照できるようになります。一方、組織の共有設定がすでに「公開/参照のみ」「公開/参照・更新可能」の場合、全ユーザーがすべてのレコードにアクセスできる状態のため、ロール階層による拡張が発生する余地がありません。

つまり、ロール階層を設定しても効果が現れない場合は、対象オブジェクトの組織の共有設定を確認することが重要です。「非公開」になっているはずが「公開」になっていないか、見直してみるとよいでしょう。

ロール階層の設計ポイント

ロール階層を設計する際、多くの方が最初に思いつくのは「会社の組織図どおりに作ればよいのでは」ということです。しかし、組織図をそのままロール階層に反映すると、思わぬ問題が発生することがあります。

組織図どおりに設定した場合に起こる問題

組織図とロール階層は、本来目的が異なるものです。組織図は「指揮命令系統」を表すものですが、ロール階層は「誰が誰のレコードを参照できるか」を表すものです。この2つを安易に一致させると、以下のような問題が発生します。

役職変更のたびにロール階層の修正が発生する

組織図と完全に一致させていると、人事異動や組織変更があるたびに、ロール階層の修正作業が必要になります。組織変更の頻度が高い企業ほど、この修正作業の負荷が大きくなります。

意図しないデータが上位ロールに見えてしまう

組織図どおりに設定すると、部長は部内の全データ、本部長は本部内の全データを参照できる状態になります。これが共有要件と一致していればよいのですが、「特定のチームのデータは特定のメンバーだけに見せたい」といった要件がある場合、組織図どおりの階層では対応できません。

階層が深くなりすぎてパフォーマンスに影響する

組織図が複雑な大企業では、ロール階層も同様に深くなります。階層が深くなるとデータ共有の再計算に時間がかかるようになり、ロールの変更やユーザーのロール変更などの操作に影響が出ることがあります。

共有要件に合わせたロール階層にする

こうした問題を避けるためには、「組織図を再現する」のではなく、「どのデータを誰に共有したいか」という共有要件を起点にロール階層を設計することが重要です。

具体的には、以下の考え方で設計を進めます。

• 組織内でどのデータをどの範囲のユーザーに共有する必要があるかを整理する
• 整理した共有範囲をもとに、必要最小限のロール階層を構築する
• 組織図には存在するが、データ共有の観点では区別が不要な階層は、ロール階層では1つにまとめる
• 組織図にはない共有範囲（例：プロジェクト単位・地域単位）が必要な場合は、それに応じたロールを設ける

ロール階層はできるだけシンプルな構造を維持することが推奨されています。複雑な共有要件のすべてをロール階層だけで実現しようとすると、階層が複雑化し管理が難しくなります。ロール階層で対応しきれない共有要件は、次に紹介する「共有ルール」と組み合わせて実現するのが一般的な設計方針です。

共有ルールとの使い分け

ロール階層は組織内の上下のつながりに基づいたデータ共有を実現する仕組みですが、現場では「上下の関係とは無関係にデータを共有したい」という場面も出てきます。そういった場面で活躍するのが「共有ルール」です。

ロール階層だけでは解決できないケース

ロール階層が実現するのは、いわば「縦方向」のデータ共有です。上位ロールのユーザーは下位ロールのユーザーが所有するレコードを参照できますが、同じ階層に属するユーザー同士や、階層上関係のない部門間などの「横方向」でのデータ共有はロール階層だけでは実現できません。

たとえば、以下のようなケースはロール階層だけでは対応できません。

• 同じ営業部内の別チームのメンバーにも、特定の取引先のレコードを共有したい
• マーケティング部門が作成したリードを、営業部門のメンバーにも参照させたい
• 特定の大口顧客に関するレコードだけ、関連する複数部門のメンバーに共有したい

共有ルールを活用する

共有ルールは、組織の共有設定によって制限されているレコードに対して、特定の条件に基づいてアクセス権を拡張するための機能です。「どのレコードを」「どのユーザー（ロール・公開グループ）と」「どのアクセス権で」共有するかを設定します。

共有ルールには、以下のパターンがあります。
レコード所有者に基づく共有ルール
特定の公開グループまたはロールのユーザーが所有するレコードを、別の公開グループまたはロールのユーザーに共有します。たとえば「Aグループが所有するリードを、Bグループにも参照させる」といった設定が可能です。

条件に基づく共有ルール
レコードの項目値が特定の条件を満たす場合に、指定した公開グループやロールのユーザーに共有します。たとえば「商談規模が一定額以上の場合、関連部門のマネージャーにも共有する」といった設定です。

なお、共有ルールはあくまで組織の共有設定に対する「例外」を作るための仕組みであるという点には注意が必要です。組織の共有設定で許可されている範囲を超えて、アクセスをより厳しくすることはできません。

また、共有ルールをたくさん作りすぎると、それ自体の管理が大変になり、想定外の共有が発生するリスクも上がってしまいます。基本としてはロール階層によるシンプルな構成をベースにしながら、共有ルールについては、どうしても必要な例外にのみ絞って活用するという運用が望ましいでしょう。

マネージャー項目とロール階層の違い

Salesforceのユーザー情報には「マネージャー」という項目が存在します。この項目とロール階層は名前のイメージから混同されやすいですが、まったく別の機能です。

ユーザーのマネージャー項目とは

マネージャー項目というのは、各ユーザーのレコードに対して設定できる、「その人にとっての直属の上司」を表す項目です。主な使われ方としては承認プロセスがあり、たとえば「経費の申請があった場合、その承認者として申請者のマネージャーを自動的に設定する」といった用途で利用されます。

マネージャー項目はあくまでユーザー単位で個別に設定していくものであり、組織全体としての階層構造を表現するためのものではありません。

ロール階層との混同に注意
マネージャー項目とロール階層は、どちらも「上司と部下」という関係性を扱う点が似通っているため、「マネージャー項目を入力しておけば、ロール階層と同じようにデータも共有される」と思い込んでしまうケースが見られます。

しかし実際には、マネージャー項目に値を入力するだけでは、レコードへのアクセス権限には全く影響が及びません。データを階層的に共有する仕組みを作るには、ロール階層を別途用意する必要があります。

両者は以下のように使い分けます。

• マネージャー項目：承認プロセスなどで「申請者の上司」を特定するために使用する
• ロール階層：レコードへのアクセス権限を、組織の階層構造に基づいて自動的に共有するために使用する

マネージャー項目を設定したのに「部下のレコードが見えない」という相談を受けた場合は、ロール階層が正しく設定されているかを確認してみましょう。

まとめ

本記事では、Salesforceにおける権限管理の要である「ロール階層」について、基本的な仕組みからプロファイルとの違い、組織の共有設定との連動性、設計のポイント、共有ルールとの使い分け、マネージャー項目との違いまでを解説しました。

ロール階層は、組織の上下関係に基づいてレコードへのアクセス権を自動的に共有する仕組みです。プロファイルが「何ができるか」を決めるのに対し、ロール階層は「何が見えるか」を決めるという点を押さえておくことが、権限設計の第一歩になります。

設計の際は、組織図をそのまま反映するのではなく、実際のデータ共有要件に基づいてロール階層を構築することが重要です。ロール階層で対応しきれない部分は共有ルールで補い、シンプルな構造を維持することを意識しましょう。

権限管理に関する悩みは、ロール階層の仕組みを理解し、共有要件に基づいた設計へと見直すことで多くが解決できます。ぜひ本記事を参考にしてください。

＜Salesforce＞
弊社ではSalesforceをはじめとするさまざまな無料オンラインセミナーを実施しています！
＞＞セミナー一覧はこちら

また、弊社ではSalesforceの導入支援のサポートも行っています。ぜひお気軽にお問い合わせください。
＞＞Salesforceについての詳細はこちら
＞＞Salesforceの導入支援実績はこちらからご覧いただけます！

医療業界に特化した営業支援、顧客管理(SFA/CRM)のコンサルティングも提供しております。こちらもぜひお気軽にお問い合わせください。
＞＞顧客管理(SFA/CRM)のコンサルティングの詳細はこちら