JinJin48

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

July 7, 2026 · 12 min read

SAP Ariba ロール

ロールは、フェーズ1「ユーザー＆アクセス」設定で構成される2番目のマスタデータオブジェクトであり、ユーザーレコードの直後に作成され、SAP Ariba内でユーザーが何を表示・実行できるかを実際に決定します。各ロールは、正確に1つの権限グループによって付与され、1人以上のユーザーによって保持されます。その後、承認ルール（フェーズ4）は、ユーザーのロールと品目を照合して、すべての購買依頼、購買発注、請求書のルーティングを決定します。この記事では、まずすべてのAriba機能領域におけるロールのコアコンセプトをマッピングし（パート1）、次に管理者がロールを定義、構造化、割り当てる際に構成するすべてのフィールドを詳細に説明します（パート2）。

パート 1: ロール — コアコンセプト（全モジュール）#

1.1 ロールとは何か#

ロールは、一連のシステム権限を単一の割り当て可能な単位にまとめるアクセス制御のマスターです。ロールは、それを付与する権限グループと、それを保持するユーザーとの間に位置します。ロールがユーザーに直接設定されることはなく、常にそれを所有する権限グループを介して到達されます。この間接性により、管理者は影響を受けるすべてのユーザーを個別に変更することなく、1つのロールを編集することで、ジョブ機能全体のアクセス権を変更できます。

1.2 ロールタイプ#

Go-Live時にロールタイプを誤ると、修正に多大なコストがかかります。システムグループは直接編集できず、親/子継承チェーンが誤って設定されると、その下のすべてのロールに誤った権限が伝播してしまいます。

設計原則: SAP Aribaでは、1サイトあたりのカスタムグループは最大25個に制限されています。設計上可能な限り少ないロールに職務機能を統合し、ほぼ同一のカスタムグループを複製するのではなく、親/子継承を使用してこの上限内に収めてください。

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

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

Buyer Realm (client-level)
├── Permission Group "PG-BUY" (Buyer permissions) → Role "ROLE-REQ" (Requester) → User "u.smith" (John Smith, Sales)
├── Permission Group "PG-APR" (Approval permissions) → Role "ROLE-APR" (Approver) → User "u.tanaka" (Aiko Tanaka, Mgr)
└── Permission Group "PG-ADM" (Admin permissions) → Role "ROLE-ADM" (Administrator) → User "u.admin" (System Admin)

このロールは、厳格な4階層クライアント階層の中間に位置します。すなわち、バイヤーレルム（最上位のサイト/テナント境界）には権限グループが含まれ、各権限グループは正確に1つのロールを付与し、各ロールは1人以上のユーザーが保持します。設定はトップダウンで流れます。ロールが直接自分自身に権限を付与することはなく、常に親の権限グループから継承します。一方、実行時のアクセスはボトムアップで行われます。これは、ユーザーの実効権限が、そのユーザーが保持するロールが持つ権限となるためです。承認ルールは、この包含チェーンの一部ではなく、別個の設定オブジェクトです。実行時にユーザーのロールを読み取り、ルーティングを決定します（セクション1.4参照）。

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

ロールは単独で存在するわけではありません。権限グループ、ユーザー、承認ルールはすべて、このロールを中心に構築されています。

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

2.0 ARIBAの所有範囲#

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

2.1 ロールの識別と定義#

これらのフィールドは、権限や継承の設定が追加される前に、ロールを一意に識別し、そのロールが何を表すかを確立します。

2.2 権限割当#

これはロールの実質的な内容です — 保持するユーザーがアクセスできる実際のアクションと画面のセットであり、その上の権限グループ（セクション1.3）から具体的で割り当て可能なバンドルに変換されたものです。

2.3 グループ階層（親 / 子）#

ロールが単独で存在することは稀であり、ほとんどのサイト設計では親/子の継承チェーンを使用して、共通のベースライン権限を一度維持し、各バリアントごとに再入力するのではなく拡張します。

2.4 ユーザー割当とガバナンス#

ロールが定義され、階層内に配置された後、誰がそのロールを保持しているか、そしてそのレビューがどの程度の頻度で行われるかについての継続的なガバナンスが、アクセスモデルの信頼性を長期にわたって維持する鍵となります。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction