JinJin48

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

July 8, 2026 · 11 min read

SAP Fieldglass ユーザ

ユーザーは、フェーズ2「ユーザーおよび権限設定」シーケンスで2番目に設定されるオブジェクトです。少なくとも1つのユーザーロールが既に存在していなければ作成できず、テナント内のすべての個人（クライアント、サプライヤー、MSPの従業員を問わず）が実際にログインする際に使用するレコードです。ユーザーは、ID属性（名前、メール、ステータス）、表示および操作可能な内容を決定する1つ以上の割り当てられたユーザーロール、およびそのロールが承認権限を付与する場合に承認グループに追加できるようにする承認権限を持ちます。この記事では、パート1でFieldglassのすべての機能領域にわたるユーザーのコアコンセプトをマッピングし、パート2で管理者がユーザーレコードを作成および保守する際に設定するすべてのフィールドを詳細に説明します。

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

1.1 ユーザーとは何か#

Userは、SAP Fieldglassにおける個々のログインアカウントです。これは特定の個人を表すレコードであり、割り当てられたロールを通じて、その人物がテナント全体でアクセスおよび実行できる内容を決定します。再利用可能な小さな権限テンプレートであるUser Roleとは異なり、Userは大量のオブジェクトです。中規模のプログラムでも、システムにアクセスする従業員、サプライヤのリクルーター、MSPコーディネーターごとに、数百から数千のアクティブなUserレコードを簡単に保持できます。

1.2 アクセスドメイン別のユーザータイプ#

すべてのユーザーは、3つのアクセスドメインのいずれかで作成され、そのドメインは作成時に固定されます。これは後で変更されるフィールドではありません。なぜなら、どの企業のメール/ログイン形式が期待されるか、どのユーザーロールを割り当てることができるかを決定するからです。オンボーディング時にこれを誤ると（例えば、サプライヤの採用担当者をクライアントユーザーとして作成するなど）、アクセスレビューが失敗する早道となります。そのユーザーが実際の職務要件よりもはるかに広範なロールの対象となるためです。

設計原則: ユーザのアクセスドメインは、割り当てられたすべてのロールのユーザタイプスコープと一致する必要があります。Fieldglassはこれを手動の慣行ではなく、割り当て時に強制します。最初のロールがアタッチされる前にドメインが正しいことを確認してください。後から修正するには、フィールドを編集するのではなく、ユーザを非アクティブ化して再作成する必要があります。

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

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

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

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

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

ユーザーはこのゾーンの中央に位置し、上部の「ユーザーロール」と下部の「承認グループ」の間にあります。ユーザーロールとの関係は真の包含関係ではありません。その根底にある多重度は N:M です（1つのロールを複数のユーザーに割り当てることができ、1人のユーザーが同時に複数のロールを保持できます）。上図では具体例を読みやすくするために、ユーザーごとに1つの割り当てのみを表示しています。例えば、u.mavis は ROLE-MGR に加えて、2つ目のより範囲の狭いロールも保持できます。承認グループのメンバーシップも同様に N:M の割り当てであり、ロールを介さずにユーザーを経由します。ユーザーは、承認グループに追加される前に、適切な承認権限を持つロールを最初に保持している必要があります。そのため、この例では承認者ロールを持つユーザー u.brian には承認グループが表示されていません。承認グループの割り当ては、ロールの自動的な結果ではなく、別個の追加ステップです。

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

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

ユーザレコードは単独で存在するものではありません。テナントに記録されるすべてのログインとすべてのアクションは、1つのユーザレコードに遡ります。

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

2.0 FG所有権の範囲#

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

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

これらの項目は個人を一意に識別し、そのアカウントがログインに使用できるかどうかを制御します。

2.2 ロールと承認割当#

これらのフィールドは、ユーザーを権限モデルに接続し、該当する場合は承認ワークフローにも接続します。

前提条件: ユーザを作成して割り当てる前に、少なくとも1つの有効なユーザロールが存在している必要があります（セットアップフローフェーズ2、ステップ8 → ステップ9）。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction