MDM 故障イベント融合

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

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

現在のレビュー API

故障イベントレビュー API は、マスターエンティティのレビュー API と分かれています。

操作	API ファミリー
候補一覧	/api/v1/dfslite/fault-fusion/candidates
重複グループ承認	/api/v1/dfslite/fault-fusion/candidates/{id}/approve
重複グループ却下	/api/v1/dfslite/fault-fusion/candidates/{id}/reject

読み取りには DFS read 権限を使い、承認と却下はレビュー判断を書き込みます。API レベルの連携を計画する場合は MDM API Reference を参照してください。

候補生成の境界

故障イベント融合では、多数の重複イベント候補が生成されることがあります。本番実行では、融合メソッドが管理対象のレビュー画面に候補を作成し、persisted と skipped candidate などの実行件数を返します。運用担当者は UI または API で候補をレビューします。

候補は steward 判断の証跡です。下流レポート、信頼性分析、AI Agent の証跡取得、保全ワークフローでイベント ID が重要な場合は、確定済みグループまたはレビュー済みイベントデータセットを使います。

実行出力	意味	確認場所
Persisted candidate count	レビュー用に作成された候補グループ数。	故障融合候補キュー。
Skipped candidate count	空、無効、重複、範囲外などで書き込まれなかった候補数。	実行履歴とタスクログ。
Approved group	複数レコードが同じイベントを表すと steward が確認したグループ。	レビュー済みイベント出力と下流データセット。
Rejected group or pair	steward が重複関係を却下したグループまたはペア。	同じ誤候補を抑止するための却下履歴。

公開済みルールセットビュー

DFS Pro の故障融合エントリは、導入環境で現在公開されている融合ルールセットを表示します。このビューでは、融合サービスが実際に使うフィールド抽出、照合ルール、サバイバーシップルール、信頼度重み、AI 補助設定を確認できます。空のルールブロックは、その部分がまだ設定されていないことを示します。

レビュアーが見るルールと実際の融合実行を揃えるため、トレーニングや引き渡し資料も運用中タスクで使う公開済みルールセットを基準にします。

利用シーン

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

ワークフロー

候補シグナル

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

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

競合比較の範囲

競合比較は、イベントの業務上の意味を変えるフィールドに集中します。管理済み 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 を参照してください。