JinJin48

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

July 7, 2026 · 13 min read

SAP Ariba ユーザー

ユーザーは、SAP Ariba 導入において最初に設定されるマスタデータオブジェクトであり、誰がログインできるか、何を表示できるか、どのアクションを実行できるかを確立します。フェーズ1～5のセットアップフローにおける後続のすべてのオブジェクトは、直接的または間接的にこれに依存します。ロール割当（フェーズ1）はユーザーレコードを読み取り、承認ルールマッチング（フェーズ4）はユーザーに割り当てられたロールを通じて解決され、CIGベースの統合（フェーズ5）はS/4HANAからユーザーレコードをプロビジョニングまたは同期する場合があります。この記事では、すべてのAriba機能領域におけるユーザーのコアコンセプトをマッピングし（パート1）、その後、購買/ソーシング/請求書管理の管理者がユーザーレコードを作成および保守する際に設定するすべてのフィールドを詳細に説明します（パート2）。

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

1.1 ユーザーとは何か#

ユーザーは、SAP Aribaサイトとやり取りする個人（または自動統合用のサービスアカウント）を表すIDレコードです。認証資格情報、ロケール設定、そして重要なことに、その人がアクセスできる画面、トランザクション、承認ステップを決定するグループ/ロール割当を保持します。ECC/S4ユーザーレコード（SU01）とは異なり、AribaユーザーはAribaサイト上で直接管理される（またはSAP Cloud Identity Servicesを介してプロビジョニングされる）クラウドネイティブオブジェクトであり、明示的に設定されない限り、自動的なリアルタイム同期は行われません。

1.2 ユーザータイプ#

ユーザタイプは独立した設定項目というよりも、個人に割り当てられたグループ/ロールの組み合わせを実用的に簡略化したものであり、その人が日常的に何を行うことが期待されているかを表します。これを本稼働開始時に誤ると、最も一般的な手戻りの原因の一つとなります。「要求元」にしかならないはずの担当者に「購買担当者」のアクセス権を割り当てると、購買ガバナンスが意図していなかった発注書作成や仕入先可視化の権限が付与されてしまいます。

設計原則: ユーザーが業務を遂行できる最も狭いユーザータイプを割り当て、後で明示的なロール変更リクエストによってアクセスを拡大します。全員をデフォルトでバイヤーや管理者として本稼働開始することは避けてください。

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

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

Buyer Realm (client-level scope — equivalent to Client in S/4HANA terms)
│
├── 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

ユーザーはレルムを所有しません。レルムは厳格なクライアントレベルの階層の最下部に位置します。すなわち、レルム（Aribaにおける最上位のサイト/テナント境界）は権限グループを含み、各権限グループは正確に1つのロールを付与し、各ロールは1人以上のユーザーが保持します。したがって、ユーザーの実効アクセス権はこのチェーンを下って継承され、ユーザーレコードに直接設定されるわけではありません。承認ルールは別個の設定オブジェクトであり、この階層の一部ではありません。承認ルールは実行時にユーザーのロールを読み取り、ルーティングを決定します（セクション1.4を参照）。

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

Userレコードは単独で存在するわけではありません。これは、フェーズ1～5の他の3つのオブジェクトが読み取り元またはプロビジョニング先とするアンカーです。

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

2.0 ARIBAの所有範囲#

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

2.1 基本プロファイルとID#

以下は、Aribaサイト上で個人を一意に識別する属性であり、グループや承認コンテキストが割り当てられる前に必須となります。

2.2 アクセスタイプと権限グループ#

このセクションでは、ユーザーが表示および実行できる内容を制御します。これは、セクション1.2で説明されているユーザータイプを具体的な設定に変換したものです。

2.3 組織と承認のコンテキスト#

これらのフィールドは、ユーザーを組織的および財務的なコンテキストに配置します。これは、承認ルール（フェーズ4）とレポートの両方が依存するものです。

2.4 認証とセキュリティ#

認証設定は、ユーザーがどのように本人確認を行うか、そしてフェデレーション時には、実際にこれらの値を維持する責任者が誰であるかを決定します。

2.5 通知とロケール設定#

ユーザーごとの表示設定とコミュニケーション設定 — これらはアクセス権には影響しませんが、ユーザーの導入率とサポートチケットの件数に実質的な影響を与えます。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction