JinJin48

SAP Consultant | BTP · S/4HANA · US Global Rollout

July 19, 2026 · 17 min read

SAP SF 権限ロール

権限ロールは、特定の権限カテゴリ、タイプ、アクセスレベルを単一の名前付き権限にまとめ、その権限を「許可対象」母集団と「対象」母集団にバインドするマスタデータオブジェクトです。これにより、権限グループによって定義された再利用可能な母集団プリミティブを、具体的で実施可能なアクセス制御に変換します。これはフェーズ2（権限とシステム設定）で設定される2番目のオブジェクトです。権限グループが「この母集団は誰か」に答えるのに対し、権限ロールは「その母集団は何ができ、誰のレコードに対してできるか」に答えます。この記事では、権限ロールとは何か、その一般的なスコープパターン（従業員セルフサービス、マネージャセルフサービス、HR/管理者、システム）、同じランドスケープゾーン内で並行する時間設定チェーンとの関係、および管理者センタのコンサルタントが設定するすべてのフィールドについて説明します。

パート 1: 権限ロール — 基本概念 (全モジュール共通)#

1.1 権限ロールとは#

権限ロールは、実際にアクセス制御を実行するオブジェクトです。これは、特定のアクセスレベルで設定された権限カテゴリ付与の名前付きセットであり、Granted-To母集団がそれを受け取るよう指示され、かつTarget母集団がそのレコードに適用されることが指示された場合にのみ有効になります。権限グループが独自のロジックを持たない再利用可能な「誰が」のプリミティブであるのに対し、権限ロールは、その「誰が」が最終的に「何を」とペアになる場所であり、ロールベース権限（RBP）フレームワーク全体が動作可能になるポイントです。

1.2 権限ロールのスコーピングパターン#

権限ロールのスコープ設定パターン — 「許可対象者」と「対象母集団」の組み合わせ方 — によって、誰が誰のデータにアクセスできるかが決まります。このペアリングを誤ることは、SuccessFactorsのアクセス制御監査で最もよく見られる指摘事項の一つです。つまり、ある目的で作成されたロールを、より広い目的に再利用すると、ビジネスの拡大に伴い、静かに過剰なアクセス権が付与されてしまうのです。

設計原則: 権限ロールは、少数の広範で汎用的なロールではなく、狭い「母集団＋目的」の組み合わせ（明確に範囲設定されたユースケースごとに1つのロール）を中心に構築します。狭いロールは監査が容易であり、ビジネス再編時に過剰なアクセス権限を付与する可能性がはるかに低くなります。

1.3 組織レベルとデータ階層#

具体的な例を用いたデータ階層

権限ロールは、SuccessFactors マスタデータランドスケープのテナントレベルの「権限と時間」ゾーン内で、権限グループ (SF-A03-01) と同じ位置にあります。これは、そのゾーンにバンドルされた3つの並行かつ独立したクライアントレベルの設定チェーンの最初のものです（権限管理、休日カレンダー→勤務スケジュール、勤怠タイプ→勤怠勘定タイプ（タイムプロファイルで結合））。この記事の対象オブジェクトは、権限管理チェーンの2番目のノードです。他の2つのチェーンは同じランドスケープゾーンに存在しますが、関連記事 (SF-A03-03 から SF-A03-06) に属しています。

Client (SuccessFactors Instance)
   │
   ├── Permission Group "PG_Manager" — Managers, Direct Reports  (see SF-A03-01)
   │      │
   │      └── Permission Role "PR_ESS" — Employee Self-Service, of PG_Manager
   │
   ├── Holiday Calendar "HC_JP2024" — Japan 2024, 16 holidays  (Time Configuration chain, see SF-A03-03/04)
   │      │
   │      └── Work Schedule "WS_JP_Std" — JP Standard, 40H/week, of HC_JP2024
   │
   └── Time Type "TT_Annual" — Annual Leave, category  (Time Configuration chain, see SF-A03-05/06)
          │
          └── Time Account Type "TAT_Annual" — 20 days, 5-day carryover, of TT_Annual

Time Profile "TP_JP_Std" — JP Standard, Work Schedule + Time Account Type bundle
   ├── assigned to ──> Work Schedule "WS_JP_Std"
   └── assigned to ──> Time Account Type "TAT_Annual"

必須のランドスケープ検証に関する注意: モジュールMaster.mdのER図は、権限グループ ↔ 権限ロールの関係を「N:M」とラベル付けしており、そのデータフローテーブルは、単一の権限グループ（「PG_Manager」）が2つのロール例（「PR_ESS」および「PR_MSS」）にリンクされていることを示しています。公開されているSuccessFactorsマスタデータランドスケープ（sf-a01/images/04-sf-a01-master-landscape.html、ゾーンC）は、これを1つの実線の親子コネクタ — PG_Manager → PR_ESS — として描画しており、これはその関係の単一インスタンスを表すものであり、すべての権限グループが正確に1つの権限ロールを所有するという主張ではありません。実際の設定では、権限ロールの「許可対象」および「対象母集団」設定は、それぞれ異なる権限グループを参照でき、単一の権限グループは、多くの無関係な権限ロール割り当てにわたって日常的に再利用されます — これはMaster.mdソースが説明する多対多のカーディナリティです。この再利用が実際にどのように機能するかについては、セクション1.4および2.3/2.4を参照してください。

設計原則: 権限ロールは組織階層内に独自の下位レベルを持ちません。これは権限グループと同様にクライアントレベルの設定オブジェクトです。このオブジェクトにとって重要な構造上の複雑さはすべて、追加の階層ネスティングではなく、独自のフィールド設定（権限カテゴリ/タイプ付与、付与対象母集団、ターゲット母集団 — パート2）に存在します。

1.4 他のマスタデータオブジェクトとの統合#

権限ロールはRBPフレームワークの要であり、入力側では権限グループを消費し、出力側では「このユーザーは許可されているか」を確認する必要がある他のすべてのオブジェクトが、この権限ロールに解決されます。

パート 2: SF 固有のフィールド詳細#

2.0 SFの所有範囲#

凡例: ◎ = オーナー / クリティカル、○ = 直接関与

2.1 ロール定義（コア識別）#

ロール定義は、権限ロールが存在するために最低限必要なレコードであり、すべてのルートマップ↗のロール参照と、各ユーザーに割り当てられたロールリストが最終的に解決される対象です。

2.2 権限カテゴリとタイプの設定#

権限カテゴリ & タイプ設定は、実際の許可付与です。つまり、RBP対応のすべてのモジュールにおいて、フィールドごと、機能ごとに、ロールの対象ユーザーが何を表示・実行できるかを決定するセクションです。

2.3 許可対象ユーザー（このロールを許可する対象）#

付与対象母集団は、「このロールを誰が受け取るか」を定義します。ロールは、固定の権限グループバインディング、ターゲット母集団への動的リレーションシップ、または組み込みの「全員」グループを通じて付与できます。

2.4 対象母集団の割当#

対象母集団は、「権限付与されたユーザーがどのレコードに対して操作を実行できるか」を定義します。この設定は権限付与母集団とは独立して構成され、両者の不一致はRBPのトラブルシューティングチケットで最もよく見られる原因の一つです。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction