JinJin48

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

July 8, 2026 · 12 min read

SAP Fieldglass 認定資格

認定は、MSP & 認定設定の下にあるフェーズ4の2つのオブジェクトのうちの2番目であり、その兄弟オブジェクトであるMSP会社は、FG-A05-01で別途文書化されています。認定は、Fieldglassのコンプライアンス追跡マスタデータオブジェクトです。管理者は、プログラムで追跡する必要のある資格情報のタイプ（例：情報セキュリティ認定、バックグラウンドチェック、安全資格）と、それぞれの有効期限ルール、およびそれがハードな必須前提条件（コンプライアンス必須）であるかどうかを定義します。その設定はオプションです。モジュール独自の「必須 vs オプションのマスタ」分類に従い、認定はアクティブなコンプライアンス追跡プログラムを実行しているテナントにのみ適用されます。この記事では、まず、認定が関わるすべてのFieldglassプロセスエリアに共通する概念（パート1）を説明し、セクション1.3では、これがこの記事シリーズでこれまでに文書化された中で最も完全にスタンドアロンなマスタデータオブジェクトである理由を説明した後、Fieldglass管理者が設定するすべてのフィールドを詳細に説明します（パート2）。

パート 1: 認定 — 中核概念（全モジュール）#

1.1 認定資格とは何か#

認定は、プログラムが追跡する単一のコンプライアンス資格またはライセンスの種類を正式に定義するレコードであり、その資格が失効するかどうか、および有効な資格の保持が必須かどうかを決定するルールも含みます。認定自体は、誰が就労資格を持つか、どのレートが適用されるか、または購買依頼がどのように承認されるかを定義するものではありません。これらは、以前のフェーズ1～3の記事で説明されたオブジェクトによって引き続き管理されます。認定は、プラットフォームを既に流れているワーカーとトランザクションに、コンプライアンスチェックを追加するだけです。

1.2 認定コンプライアンスモデルの比較#

認定には、Contingent TypeやSOW Typeのような正式な「タイプ」フィールドはありません。代わりに、その「コンプライアンス必須」フィールドが2つの強制モデルを選択し、この設定を誤ると、黙示的なコンプライアンスギャップが生じるか、不要なオンボーディングブロッカーが発生します。

設計原則: 設定前に、どの資格情報が本当に必須であるかをクライアントのコンプライアンスまたは法務関係者と確認してください。基礎となる契約や規制で実際に必須とされている資格情報を情報提供としてマークすると、Fieldglass が独自に検出できないコンプライアンス上のギャップが生じます。

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

ゾーン D — ジョブ投稿 · SOW · MSP（このオブジェクト自身のゾーン）：認定は、ゾーン D の行 4 にあるスタンドアロンのテナントレベルノードです。子ノードは持たず、他のゾーン D オブジェクトへの出力ラインやチップもありません。また、1 行上の MSP カンパニーとは異なり、他のゾーン D ノードからの入力チップもありません。

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

Zone D position (standalone tenant-level object — no children, no outbound chip,
no inbound chip from any other Zone D node)

Certification "CERT-ISO27001" — ISO 27001 Information Security  ◄── this article
Certification "CERT-BG-CHECK" — Background Check / Drug Screening  ◄── this article

No real-world master data prerequisite documented in the Setup Flow or ER Diagram
(Setup Flow: "25. Certification ← (-)"; ER Diagram: "Certification (独立)") —
genuinely standalone, unlike MSP Company's real Supplier dependency documented in FG-A05-01

認定は、FieldglassマスタデータランドスケープのゾーンDにおいて、派遣タイプ、SOWタイプ、MSPカンパニーの下に、独立したRow 4カードとして位置しています。しかし、これら3つとは異なり、ゾーンDの他のオブジェクトへのアウトバウンドチップも、他のオブジェクトからのインバウンドチップも持ちません。修正されたランドスケープはこれを直接確認しています。認定とMSPカンパニーを結ぶ実線はなく（2つのフェーズ4オブジェクトは互いに独立して設定されており、これはFG-A05-01でMSPカンパニー側から既に述べられている通りです）、また、他のゾーンから認定ノードに入る、または認定ノードから出る破線の参照矢印もありません。

このモジュール独自のセットアップフローエントリ「25. 認定 ← (-)」と、そのER図エントリ「認定 (独立)」は、どちらも認定に文書化された実世界のマスタデータ前提条件がないことを確認しています。これは、MSP会社（FG-A05-01）とは意味が異なります。MSP会社の場合、仕入先への依存関係は実際に存在しますが、現在のランドスケープ上にクロスゾーンチップとしてまだ描かれていないだけです。認定には、ソースデータのどこにも前提条件が文書化されていません。これは、本記事シリーズでこれまでに取り上げられた中で最も完全に独立したオブジェクトです。テナントは、モジュールがプロビジョニングされた時点で、他のマスタデータオブジェクトが先に存在する必要なく、認定レコードを作成できます。

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

認証は、マスタデータソースに文書化された正式なフィールドレベルの参照を通じて他のマスタデータオブジェクトに紐付くわけではありません。しかし、それはプログラムの他の部分から独立して機能することを意味するわけではありません。その実質的な関係は、設定されたオブジェクトリンクではなく、トランザクションレベルのコンプライアンスチェックと管理上のグループ化を通じて成立します。

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

2.0 FG所有権の範囲#

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

2.1 認定 — 識別と分類#

認証には、管理、コンプライアンスレポート、およびオンボーディングチェック全体でレコードを識別し、一貫してラベル付けするフィールドが含まれています。

2.2 コンプライアンス & 有効期限ルール#

コンプライアンス & 有効期限ルールには、資格情報が失効するかどうか、オンボーディングをブロックするかどうか、および失効前にプログラムに警告が発せられる期間を決定する3つのフィールドが含まれています。これは、認定レコードの強制力の中核です。

次に読むべきもの#

L1) Big Picture

L2-A) Master Data

L2-B) Transaction