論理和(Logical OR)
概要
論理和(Logical OR)エンリッチメントは、複数のブール属性に対して論理和(OR)演算を実行し、新しい統合されたブール属性を作成します。この論理演算子は、選択された複数のブール属性のうち少なくとも1つがTRUEであればTRUEを返し、すべてがFALSEの場合にのみFALSEを返します。このエンリッチメントは、複数の二値条件やフラグ、指標を組み合わせ、それらのいずれかが満たされているかを表す単一の意味のある属性を作成する際に重要です。
プロセスマイニングや分析において、論理和エンリッチメントは、複数の条件のうち少なくとも1つを満たすケースを特定する必要がある場合に特に役立ちます。たとえば、例外が発生したケースをフラグ付けしたり、任意の種類のアラートを発生させた注文を特定したり、コンプライアンス違反があったかどうかを判断したりする場合などです。このエンリッチメントは、ケース単位で動作し、それぞれのケースに対してブール属性を評価し、その結果を新たなケース属性として保持します。この属性は、さらなる分析やフィルタリング、可視化に利用可能です。
また、エンリッチメントはnull値を賢く扱い、評価対象から除外します。特定のケースで選択されたすべての属性がnullの場合、結果もnullとなり、データの整合性を保ち、誤った真偽判定を防止します。
主な使用例
- 複数の品質チェックのフラグを組み合わせて、品質問題があるケースを特定
- 支払いアラートや配送アラート、詐欺アラートなど任意のアラート条件で注文をフラグ付け
- 複数のコンプライアンスチェックで違反があったかどうかを判定
- 例外やエラー条件があったプロセスを検出
- 複数の適格基準のいずれかを満たす顧客を特定
- いずれかのレビュー条件が満たされた場合にレビュー対象ケースをマーク
- 複数の承認フラグを統合し、いずれかの承認が付与されているかを判定
設定
新しい属性名: OR演算の結果を格納する新しいブール属性の名前を指定します。組み合わせる条件を明確に示す説明的な名前を選択してください。例えば、例外のフラグを組み合わせる場合は"Any_Exception_Occurred"、承認状態を組み合わせる場合は"Any_Approval_Granted"などです。名前は一意で、既存の属性と重複しないようにしてください。
属性名: OR論理で組み合わせたいブール属性を選択します。操作のために少なくとも2つのブール属性を選択する必要があります。エンリッチメントは各ケースの全選択属性を評価し、いずれかがTRUEであればTRUEを返します。選択可能なのはブール(True/False)属性のみです。これは元のデータセット属性であったり、他のエンリッチメントや計算機で作成されたブール属性であったりします。
事例
事例1:品質管理アラートシステム
シナリオ: 製造プロセスの各段階で複数の品質チェックを実施しています。いずれかの品質検査に失敗した製品を特定して詳細検査に回す必要があります。
設定:
- 新しい属性名: Any_Quality_Issue
- 属性名: Visual_Inspection_Failed, Dimension_Check_Failed, Weight_Check_Failed, Functionality_Test_Failed
出力: 任意の品質チェックに失敗した場合にTRUEとなる新たなブール属性"Any_Quality_Issue"を生成:
| Case ID | Visual_Inspection_Failed | Dimension_Check_Failed | Weight_Check_Failed | Functionality_Test_Failed | Any_Quality_Issue |
|---|---|---|---|---|---|
| P-001 | FALSE | FALSE | FALSE | FALSE | FALSE |
| P-002 | TRUE | FALSE | FALSE | FALSE | TRUE |
| P-003 | FALSE | FALSE | TRUE | FALSE | TRUE |
| P-004 | TRUE | TRUE | FALSE | TRUE | TRUE |
インサイト: この統合フラグにより、品質担当者はどの検査で失敗したかにかかわらず検査対象製品をすばやく特定でき、品質管理プロセスの効率化に寄与します。
事例2:カスタマーサービス優先ルーティング
シナリオ: カスタマーサービスセンターでは、複数のエスカレーション条件のいずれかを満たす高優先度のサポートチケットを特定し、即時対応が必要です。
設定:
- 新しい属性名: Requires_Immediate_Attention
- 属性名: Is_VIP_Customer, Multiple_Contact_Attempts, Complaint_Contains_Legal_Terms, Service_Level_Breach
出力: いずれかのエスカレーション条件を満たす場合に"Requires_Immediate_Attention"をTRUEに設定:
| Case ID | Is_VIP_Customer | Multiple_Contact_Attempts | Complaint_Contains_Legal_Terms | Service_Level_Breach | Requires_Immediate_Attention |
|---|---|---|---|---|---|
| CS-101 | FALSE | FALSE | FALSE | FALSE | FALSE |
| CS-102 | TRUE | FALSE | FALSE | FALSE | TRUE |
| CS-103 | FALSE | TRUE | TRUE | FALSE | TRUE |
| CS-104 | FALSE | FALSE | FALSE | TRUE | TRUE |
インサイト: サポートマネージャーは即時対応が必要なチケットを絞り込み優先順位付けが可能となり、重要課題を迅速に処理できます。
事例3:金融取引における詐欺検出
シナリオ: 金融機関では複数の詐欺指標を用いて怪しい取引をフラグ付けしています。いずれかの指標が陽性の場合、詐欺レビューをトリガーします。
設定:
- 新しい属性名: Potential_Fraud_Alert
- 属性名: Unusual_Amount_Flag, Location_Mismatch, Velocity_Check_Failed, Blacklist_Match, Pattern_Anomaly_Detected
出力: いずれかの詐欺指標が陽性のときに"Potential_Fraud_Alert"をTRUEに設定:
| Transaction | Unusual_Amount_Flag | Location_Mismatch | Velocity_Check_Failed | Blacklist_Match | Pattern_Anomaly_Detected | Potential_Fraud_Alert |
|---|---|---|---|---|---|---|
| TXN-8901 | FALSE | FALSE | FALSE | FALSE | FALSE | FALSE |
| TXN-8902 | TRUE | FALSE | FALSE | FALSE | FALSE | TRUE |
| TXN-8903 | FALSE | FALSE | TRUE | FALSE | TRUE | TRUE |
| TXN-8904 | FALSE | TRUE | FALSE | TRUE | FALSE | TRUE |
インサイト: 詐欺チームはレビューフラグの付いた取引を即座に特定でき、迅速な対処が可能です。各指標は調査の文脈情報として役立ちます。
事例4:医療における患者リスク評価
シナリオ: 緊急医療部門では、高リスク患者の基準に該当する患者を特定し、適切なケアを提供する必要があります。
設定:
- 新しい属性名: High_Risk_Patient
- 属性名: Elderly_Patient, Chronic_Condition, Immunocompromised, Recent_Surgery, Critical_Vitals
出力: 複数のリスク要因を評価し、高リスク患者を特定:
| Patient ID | Elderly_Patient | Chronic_Condition | Immunocompromised | Recent_Surgery | Critical_Vitals | High_Risk_Patient |
|---|---|---|---|---|---|---|
| PT-201 | FALSE | FALSE | FALSE | FALSE | FALSE | FALSE |
| PT-202 | TRUE | TRUE | FALSE | FALSE | FALSE | TRUE |
| PT-203 | FALSE | FALSE | FALSE | TRUE | FALSE | TRUE |
| PT-204 | FALSE | TRUE | TRUE | FALSE | TRUE | TRUE |
インサイト: 医療スタッフは迅速に高度な観察や特別なケアが必要な患者を特定でき、患者の安全性とケアの質を向上させます。
事例5:サプライチェーンの混乱検出
シナリオ: 物流企業はサプライチェーン混乱の可能性を示す複数の指標を監視し、いずれかのリスク要因がある配送をフラグ付けする必要があります。
設定:
- 新しい属性名: Disruption_Risk_Flag
- 属性名: Weather_Alert, Port_Congestion, Carrier_Issue, Customs_Hold_Risk, Route_Restriction
出力: 複数のリスク指標を組み合わせて混乱リスクがある配送を特定:
| Shipment | Weather_Alert | Port_Congestion | Carrier_Issue | Customs_Hold_Risk | Route_Restriction | Disruption_Risk_Flag |
|---|---|---|---|---|---|---|
| SH-5001 | FALSE | FALSE | FALSE | FALSE | FALSE | FALSE |
| SH-5002 | TRUE | FALSE | FALSE | FALSE | FALSE | TRUE |
| SH-5003 | FALSE | TRUE | FALSE | TRUE | FALSE | TRUE |
| SH-5004 | FALSE | FALSE | FALSE | FALSE | NULL | FALSE |
インサイト: 物流担当者は任意の混乱リスクがある配送を事前に管理でき、代替プランの立案や顧客対応に役立てられます。
出力
論理和エンリッチメントは、「新しい属性名」設定で指定された名前の新しいブール型ケース属性を作成します。この属性は、選択された入力属性の論理和評価に基づいてTRUEまたはFALSEの値を持ちます。
論理演算: 本エンリッチメントは標準的なブールOR演算を実装しています:
- 選択された属性のうち少なくとも1つがTRUEならTRUEを返す
- すべての選択属性がFALSEならFALSEを返す
- すべての選択属性がNULLならNULLを返す
NULL値の扱い: 入力属性のNULL値は論理和評価から除外されます:
- 一部の属性がNULLで他がFALSEの場合、結果はFALSE
- 一部がNULLで少なくとも1つがTRUEの場合、結果はTRUE
- すべてNULLの場合のみ結果はNULLとなる
データ型: 出力属性は常にブール型であり、mindzieStudioの可視化設定に応じてTRUE/FALSE、Yes/No、または1/0として表示されます。
統合可能性: 本エンリッチメントで作成された新しいブール属性は以下に利用可能です:
- 他の論理エンリッチメントの入力として利用し複雑な論理式を作成
- ケースフィルターで任意の条件を満たすデータを抽出
- 条件付き計算機やエンリッチメントで使用
- プロセスマップで条件を満たすケースを強調表示
- エンリッチされたデータセットの一部として外部分析にエクスポート
- ダッシュボードやレポートで他のブール属性と組み合わせて利用
関連項目
- Negate - ブール値を反転(NOT演算)
- Boolean Count - TRUEのブール属性数をカウント
- Case Compare Attributes - 属性を比較してブール結果を生成
- Filter Cases - OR結果を使ってデータセットをフィルタリング
本ドキュメントはmindzie Studioプロセスマイニングプラットフォームの一部です。