MDM Steward Queue

Steward Queue は、不確実な ID マッチを処理するレビュー画面です。resolver タスクは「このソースレコードが既存の golden record に属する可能性がある」という候補を作成し、steward が確定前にレビューします。

このキューは ID 判断に使用します。一般的なデータ品質エラーは、データ品質と rejected-row のワークフローで扱います。

前提

• 候補の表示には dfs:read が必要です。
• 承認または却下には dfs:write が必要です。
• レビュアーは比較対象のソースシステムを理解している必要があります。
• 2 つの記録が同じ実物か判断できる権限が必要です。

画面を開く

Data Integration > DFS Pro > Steward Queue

entity type と status でフィルタできます。

状態	意味
Pending	人の判断が必要な候補。
Approved	候補が受け入れられ、alias が確定済み。
Rejected	候補が却下され、今後の resolver 実行で参照されます。

レビューフロー

キューは管理された作業リストとして扱います。各判断には、次回の resolver run、下流データ owner、プロジェクト引き渡し記録で再利用できる文脈を残します。

レビュー手順

1. Review を選択します。
2. incoming source record と candidate golden record を比較します。
3. similarity を確認します。
4. field diff を確認します。
5. 必要に応じてソース証跡を確認します。
6. 同じ実物と確認できる場合だけ approve します。
7. 別物または証跡不足の場合は reject します。

重点的に比較するフィールド：

フィールド群	確認内容
ソース ID	Source system、source ID、オブジェクトタイプ、source owner。
物理 ID	シリアル番号、設備コード、資産タグ、ステーション、場所。
説明フィールド	名称、クラス、型式、ベンダー、自由記述。
有効期間	有効開始、交換日、稼働開始日、廃止状態。
既存判断	Active aliases、rejected pairs、merge history、split history。

Similarity score は並び替えとトリアージのためのシグナルです。最終的な steward 判断はソース証跡に基づけます。

候補の承認

source ID を候補エンティティの alias として扱うべき場合に承認します。

承認すると cross-source alias が作成または更新され、候補は approved になります。この ID が有効な出力に影響する場合は、下流の融合またはレポートを再検証します。

承認後の確認：

1. master entity を開きます。
2. 新しい source alias が active であることを確認します。
3. alias に期待した valid-from 日付があるか確認します。
4. そのエンティティに依存する下流 fusion task を再実行または更新します。
5. alias が本番レポート、AI Agent の証跡、Inspector 記録に影響する場合は、判断を引き渡し記録に残します。

判断の目安

シグナル	扱い
信頼できるソースで同じ安定 ID	強い証跡。ただし entity type と期間を確認します。
表示名だけが同じ	弱い証跡。場所、シリアル、クラス、ソース owner を確認します。
時刻が近く、故障テキストが似ている	イベント候補には有用ですが、資産 ID 判断には単独で使いません。
場所またはシリアルが矛盾	通常は reject、または split レビューに進めます。
重要フィールドが不足	pending のままにするか、理由付きで reject します。

却下メモ

良い note は短く理由を示します。

• 別の物理設備。名称が似ているだけ。
• 交換後に source ID が再利用されているため、履歴期間の確認が必要。
• ソースレコードにシリアルまたは場所の証跡がない。

却下後は、そのソースレコードを新しいエンティティにするか、未マッチのままにするか、ソース修正を待つかを確認します。却下記録は繰り返しレビューを減らすためのもので、データ品質問題を隠すためのものではありません。

キュー運用ポリシー

本番利用前に、簡潔なキューポリシーを決めます。

項目	推奨判断
Owner	entity type ごとに担当 steward グループを決めます。
レビュー頻度	導入中は resolver run の後にレビューし、安定後は定期レビューに移行します。
エスカレーション	ソース証跡が不足する候補は、汎用 backlog ではなくシステム owner に戻します。
Aging threshold	合意した期間を超えて pending の候補を追跡します。
高影響エンティティ	本番レポート、作業指示、AI Agent ワークフローで使うエンティティは二次レビューを検討します。

一括レビューは、低リスクで同じ証跡パターンを持つ候補に限定します。シリアル、場所、交換履歴、source owner が異なる場合は個別に判断します。

確認項目

• Pending candidates はソースシステムを理解する人がレビューしています。
• approve 後、golden record に期待した alias が表示されます。
• 再発しやすい reject には理由があります。
• 影響の大きい ID 変更は下流 owner に通知されています。
• 引き渡し記録にレビュー件数と未処理候補が含まれます。
• 長期間 pending の候補には owner と次アクションがあります。
• approved aliases が次回の下流更新に反映されています。

次に読む

既存の ID 構造を修正する場合は Merge, Split, Re-Point を参照してください。