MDM エンティティ解決タスク

エンティティ解決タスクは、実装担当者向けの DFS 融合タスクです。MDM 出力を準備し、golden records の作成または更新、deterministic aliases の確定、不確実なマッチの steward queue 送信を行います。

業務 steward は通常、Master Entities と Steward Queue を使用します。このページは実装設定、実行検証、引き渡し向けです。

能力境界

• DFS とバックエンドサービスが MDM 永続化、tenant scope、権限、監査を担当します。
• resolver は渡されたコンテキストからエンティティ、別名、曖昧候補を計算します。
• 曖昧なマッチは steward queue に入り、静かに受け入れられません。
• ソースシステムは業務記録の出所として維持します。

resolver は管理されたデータ準備ワークフローとして扱います。ID プロセスには steward の判断が含まれます。

前提

• ソースデータセットが利用可能で steward がいます。
• 対象 entity type が存在します。
• 必要な reference data が準備済みです。
• method configuration がレビュー済みです。
• ソースフィールドに安定した ID シグナルがあります。
• 下流 owner が、そのタスクがテスト、パイロット、本番のどれかを理解しています。

入力

入力	用途
Source datasets	同じ実物を表す可能性があるソースレコード。
Entity type	device、asset、part、station などの対象タイプ。
Match keys	高信頼 deterministic マッチに使うフィールド。
Fuzzy fields	名称、説明、別名、属性など候補生成に使うフィールド。
Survivorship rule	ソース間で値が違う場合に canonical 属性を選ぶルール。
Existing MDM context	現在のエンティティ、active aliases、rejected pairs。

設定チェックリスト

resolver を全データセットに対して実行する前に、データ owner と設定を確認します。

設定領域	確認する質問
Entity type	そのタイプは安定したライフサイクルを持つ実運用オブジェクトを表すか。
Source priority	名称、場所、クラス、状態が衝突した場合、どのソースを優先するか。
Deterministic keys	steward review なしで安全に確定できるフィールドはどれか。
Fuzzy fields	候補提示には有用だが、人のレビューが必要なフィールドはどれか。
Validity period	交換、廃止資産、再利用された source ID をどう扱うか。
Rejected-pair memory	既存の steward 却下記録を含め、同じ誤候補を抑止するか。
Run mode	preview、pilot、または approved MDM output を書き込む実行か。

最初は小さな slice で検証します。そこには正常な記録、既知の重複、廃止済みオブジェクト、難しいケースを含めます。正常な記録だけのテストでは準備状況を過大評価しやすくなります。

出力

• 作成または更新される entities；
• 確定される aliases；
• steward queue に送られる fuzzy candidates；
• run metrics とエラー；
• 判断を支える lineage。

タスクが MDM output を返す場合、通常の dataset rows を主出力として扱わないでください。MDM output は管理された ID 結果です。

検証フロー

実行結果のレビュー

各実行後に確認します。

• 作成または更新された entity 数；
• 確定された alias 数；
• steward queue に入った fuzzy candidate 数；
• スキップまたは形式不正のレコード；
• task errors；
• steward の作業量が許容範囲か。

候補量が多すぎる場合、match keys、ソース品質、survivorship rules の見直しが必要です。

指標	目的
Deterministic match rate	安定キーでマッチできる記録数を確認します。
New entity rate	予期しないエンティティ増加を検出します。
Fuzzy candidate rate	本番時の steward 作業量を見積もります。
Rejected-pair repeat rate	過去の却下判断が再利用されているか確認します。
Missing-key count	ソース mapping またはデータ品質の課題を示します。
Downstream row movement	ID 更新後に融合記録、作業指示、イベントがどれだけ変わったかを示します。

各バケットから例を確認します。集計指標が健全でも、特定の資産クラスやソースシステムで影響の大きい誤りが起こる場合があります。

エンドツーエンドシナリオ

典型的な実装では、MDM を DFS の他機能とつなげます。

1. DFS Lite で保全、BMS、点検、表計算の資産記録を取り込みます。
2. ソースフィールドを正規化し、必要な ID シグナルを mapping します。
3. 対象 entity type に対して MDM resolver task を実行します。
4. deterministic aliases を確定し、不確実なマッチを Steward Queue に送ります。
5. 作業指示、計測値、点検、イベントを master entity ID に結合する DFS Pro fusion task を再実行します。
6. レビュー済みデータセットを Inspector ワークフロー、AI Agent 証跡検索、BI レポート、または他の運用アプリケーションへ引き渡します。

引き渡しには resolver run ID または task name、source slice、entity type、steward decision counts、open exceptions、downstream refresh status を含めます。

引き渡しチェックリスト

• タスク名と目的が明確です。
• 対象 entity type が正しいです。
• 入力データセットとソースフィールドが記録されています。
• match keys と fuzzy fields がレビュー済みです。
• steward queue の owner がいます。
• 下流ワークフローが出力の利用可否を理解しています。
• 既知の制約と未解決 ID 問題が記録されています。
• 実行指標が引き渡し記録に添付されています。
• 将来のソース更新時の再実行手順が明確です。

次に読む

Steward Queue を参照してください。