JinJin48

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

July 8, 2026 · 10 min read

SAP Fieldglass ユーザロール

ユーザロールは、フェーズ2「ユーザ＆権限設定」シーケンスで最初に設定されるオブジェクトです。上流のマスタデータ依存関係はなく、その後作成されるすべてのユーザは、ログインして何か有用な操作を行う前に、少なくとも1つのロールが割り当てられている必要があります。ロールは、ユーザが表示および実行できる内容（開くことができるFieldglassモジュール、実行を許可されるアクション、テナントデータのうちユーザに表示される範囲）を定義します。この記事では、ユーザロールの中核的概念をすべてのFieldglass機能領域にわたってマッピングし（パート1）、その後、管理者がロールレコードを作成および保守する際に設定するすべてのフィールドを詳細に説明します（パート2）。

パート 1: ユーザロール — 基本概念（全モジュール共通）#

1.1 ユーザロールとは#

ユーザロールは、SAP Fieldglass における名前付き権限セットであり、テナント全体でユーザがアクセスおよび実行できる内容を決定します。管理者は、個々の人に直接権限を割り当てるのではなく、一度だけ「採用マネージャ」「承認者」「管理者」などの小さなロールライブラリを定義し、それらのロールを各ユーザに1つ以上割り当てます。これは、フェーズ2の「ユーザ＆権限設定」セットアップシーケンスで最初に作成されるオブジェクトであり、上流のマスタデータ依存関係はありません。シーケンス内の次のオブジェクトである「ユーザ」は、割り当てる既存のロールが少なくとも1つなければ作成できません。

1.2 ユーザタイプ別のユーザロールカテゴリ#

ユーザロールには、レートカテゴリがレートタイプを持つような正式な「ロールタイプ」コードフィールドはありません。代わりに、すべてのロールは3つのユーザタイプスコープのいずれかの中で作成され、そのスコープによって、ロール構築時に選択可能な画面、権限カタログ、およびモジュールアクセスオプションが決まります。設計時にこれらのスコープを混同すること（例えば、サプライヤスコープのロールに別のサプライヤの提出物への可視性を付与しようとすること）は、本番稼働前のセキュリティレビューで不合格となる一般的な原因です。

設計原則: Fieldglassには、正式な親/子ロール継承モデルはありません。組織階層がネストするように、ロールがより広範なロールを「拡張」することはありません。ユーザーの実際の職務に最も合致する、最も狭いロールを割り当ててください。ロールが広すぎることが判明した場合、そのロールに個別に割り当てられたすべてのユーザーを、一人ずつ再割り当てする必要があります。修正するための親ロールが中央に存在しないためです。

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

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

User Role "ROLE-MGR" — Hiring Manager  ◄── this article
│
└── User "u.mavis" — Mavis, Eng Mgr
       └── Approval Group "AG-ENG-01" — Eng approvers pool

User Role "ROLE-APR" — Approver
│
└── User "u.brian" — Brian, Program Mgr

User Role "ROLE-ADMIN" — Administrator
│
└── User "u.admin" — System Admin
       └── Distribution List "DL-ENG-ALL" — Notification group

ユーザロールは、このゾーンの最上位に位置し、他の会社構造やレートオブジェクトと同じテナントレベルにあります。つまり、組織上の親を持ちません。ユーザとの関係は真の包含関係ではなく、その背後にある多重度はN:Mです（1つのロールを複数のユーザに割り当てることができ、1人のユーザが同時に複数のロールを保持できます）。上図では、具体例を読みやすくするために、ロールごとに1つの割り当てのみを表示しています。承認グループのメンバーシップも同様に、ユーザを介して流れるN:Mの割り当てであり、ロールを直接介して行われるものではありません。ユーザは、承認グループに追加される前に、適切な権限を持つロールを最初に保持している必要があります。

この同じゾーンには、管理上の近接性から配布リストが表示されます（ユーザや承認グループと同じ管理領域から管理されます）。しかし、その実際のマスタデータ前提条件は、ユーザロールやユーザではなく、仕入先です。この関係の詳細については、FG-A03-04（配布リスト）を参照してください。

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

ユーザロールレコードは単独で存在するものではなく、ユーザおよび権限設定フェーズ全体、およびその下流のすべてが依存する前提条件です。

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

2.0 FG所有権の範囲#

凡例: ◎ = オーナー/重要、○ = 直接関与

2.1 基本識別とステータス#

これらのフィールドはロールを一意に識別し、新しいユーザーに割り当て可能かどうかを制御します。

2.2 権限とアクセス範囲#

これらの3つのフィールドは、ロールの実際のアクセス制御ロジックであり、これらが連携して、このロールに割り当てられたユーザーが何を表示し、何を実行できるかを決定します。

前提条件: ユーザを作成して割り当てる前に、ユーザロールが存在し、かつアクティブである必要があります（セットアップフローフェーズ2、ステップ8 → ステップ9）。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction