MDM 故障イベント融合

故障イベント融合は、複数のソースシステムの記録が同じ実イベントを表すかをレビューするためのパターンです。システムごとに説明、時刻、カテゴリ、ID が異なる場合、マッチ漏れや重複集計を減らせます。

このページはガバナンスパターンを説明します。具体的なスコア設定は実装とソースシステムによって異なります。

利用シーン

• 複数システムが同じ故障またはイベントを報告する。
• 自然キーでは説明や時刻の揺れを持つ重複イベントを見つけられない。
• レポートでイベントが重複集計される。
• 保全、点検、信頼性分析にレビュー済みイベント ID が必要。
• AI Agent の回答が複数ソースの証跡を引用する。

ワークフロー

候補シグナル

シグナル	役割
解決済み entity ID	記録が同じ対象物を指すことを確認します。
時間窓	十分近い記録を見つけます。
説明類似度	同じ状態の異なる表現を見つけます。
カテゴリまたは重要度	ソース分類の比較を助けます。
作業指示または点検リンク	運用証跡を提供します。

イベントグループを確定する前に複数のシグナルを組み合わせます。別資産の似た説明は個別イベントとして扱います。

イベントグループ状態

状態を明確にし、下流ユーザーが raw events と reviewed event groups を混同しないようにします。

状態	意味	下流での使い方
Raw	ソースイベントはまだ比較されていません。	ソース監査と取り込みトラブルシュートに使います。
Candidate	resolver が重複の可能性があるグループを見つけました。	steward review のみに使います。
Confirmed group	steward が同じイベントを表す記録群として確定しました。	信頼性分析、イベント件数、AI Agent 証跡、レポートに使います。
Rejected pair	steward が候補関係を却下しました。	同じ誤候補を抑止するために使います。
Split required	候補グループ内に複数の実イベントがあります。	reviewed output の公開前に分割します。

レビュー手順

1. 資産または設備 ID を確認します。
2. ソース時刻を比較します。
3. 故障説明、カテゴリ、重要度を比較します。
4. 可能であれば作業指示や点検証跡を確認します。
5. 同じイベントか判断します。
6. 表面的に似ているだけの候補は却下します。

レビューではイベント証跡と運用フォローの両方を確認します。故障記録と作業指示は異なる文章で同じインシデントを表す場合があります。同じアラーム文でも、資産や運転時間帯が違えば別イベントとして扱います。

Reviewed output フィールド

レビュー済みイベントデータセットには、下流チームが使える十分な文脈を含めます。

フィールド	目的
Reviewed event ID	確定イベントグループの安定 ID。
Master entity ID	イベントを管理済み資産または設備 ID に接続します。
Source event IDs	raw ソースシステム記録への追跡性を保持します。
Primary timestamp	レポートで使うイベント時刻を定義します。
Time window	グループに含まれるソース記録の時間範囲を示します。
Review status	raw、candidate、confirmed、rejected、split-required を分けます。
Decision note	信頼性レポートや AI Agent 回答に影響する人の判断を説明します。

reviewed IDs と一緒に raw source IDs を公開します。これにより監査担当者は、回答やレポートを元のシステム記録まで追跡できます。

出力の用途

確認済みイベントグループは、次に利用できます。

• 信頼性分析；
• 予知保全の証跡；
• インシデントレビュー；
• 点検と作業指示のフォロー；
• BI レポート；
• AI Agent の証跡説明。

実装シナリオ

施設または製造環境では、実用的な設定は次の流れになります。

1. DFS Lite がアラーム、保全依頼、点検結果、作業指示記録を取り込みます。
2. MDM が資産または設備 ID を解決してからイベントグループ化を開始します。
3. resolver が entity ID、時間窓、テキスト類似度、カテゴリ、作業証跡に基づいて候補グループを作成します。
4. steward がキューでグループを承認または却下します。
5. DFS Pro が raw source IDs と reviewed event IDs を含むレビュー済みイベントデータセットを公開します。
6. Inspector、信頼性レポート、AI Agent ワークフローが reviewed event identity を使用し、重複件数を減らしながらソース証跡を引用します。

このシナリオは、ソースシステムに一貫した資産 ID、イベント時刻、運用カテゴリがあるほど安定します。フィールドが弱い場合は、resolver をより多くのソースへ広げる前に mapping を改善します。

確認項目

• イベントグループを信頼する前に、資産または設備 ID が解決されています。
• 時間窓が業務ドメインに合っています。
• 類似度はレビューシグナルとして扱います。
• 却下された候補が記録されています。
• 下流レポートが raw events と reviewed event groups のどちらを使うか明記しています。
• reviewed event output に audit 用の raw source IDs が含まれます。
• confirmed groups は作業指示または点検証跡に対してサンプリング確認されています。
• split-required groups は本番レポートで使う前に解決されています。

よくある問題

症状	原因	対処
重複イベントが残る	時間窓が狭すぎる、または資産 ID が未解決。	entity aliases と scoring configuration を確認します。
別イベントがグループ化される	時間窓が広すぎる、または説明マッチが緩すぎる。	ルールを調整し、誤グループを却下します。
レビューキューが大きすぎる	ソース品質または match keys が弱い。	ソース mapping を改善し、より強い ID シグナルを追加します。
AI 回答の証跡が分かりにくい	raw events と reviewed event sets が混在している。	reviewed dataset または grouping status を明確に引き渡します。

次に読む

Industry Recipes を参照してください。