テキスト置換

概要

Replace Text エンリッチメントは、データセット全体のテキスト属性に対して検索・置換操作を行う強力なデータ変換オペレーターです。このエンリッチメントを使うことで、ケース属性やイベント属性にわたって体系的にテキストの置換を行い、用語の標準化や体系的な誤りの修正、データフォーマットの一貫した変換が可能になります。古い製品コードの置換、部署名の標準化、プロセスデータの繰り返し発生する誤字の訂正など、大量のテキスト変更を効率的かつ信頼性高く実施したい場合に最適なソリューションです。

手動の検索・置換操作では見落としや不整合の導入リスクがありますが、このエンリッチメントは指定されたテキストパターンのすべての出現箇所を対象属性全体から処理します。大文字小文字を区別するモードと区別しないモードの両方に対応しており、テキストマッチングの方法を細かく制御可能です。異なるERPシステムや地域拠点のデータ統合のように大文字小文字の慣習が異なる複数ソースのデータに対しては、この柔軟性が不可欠です。

Replace Text エンリッチメントはデータセット内の文字列属性に対して直接値を書き換えるため、データの関係性や整合性を維持しつつ変換を行います。この方法により、ダウンストリームの分析やフィルター、計算は追加設定やデータマッピングなしに標準化されたテキスト値の恩恵を受けることができます。

主な用途

異なるシステムにおける部署名や拠点名の標準化（例：「NY Office」「New York」「NYC」を「New York Office」に統一）
システム移行やブランド変更後の旧製品コードやSKUの更新
活動名における体系的な誤字や略語の修正によるプロセス可視化の明確化
個人情報保護のための機微情報を匿名化値に置換
日付や時刻書式のテキストフィールド内での区切り文字や書式文字の標準化
ステータスコードや略語を読みやすい業務用語に変換してレポートの質を向上
複数バリエーションが存在するベンダー名や顧客名の統一

設定

Attribute Name: 置換操作を適用するテキスト属性を選択します。ドロップダウンにはケースレベルとイベントレベルの両方の文字列属性が表示されます。非表示または計算フィールドではない文字列型属性のみ選択可能です。置換したいテキスト値を含む属性を特定して選びます。

Original Text: 検索して置換する正確なテキスト文字列を入力します。これがデータ内でマッチするパターンとなります。置換を行うにはここに入力した文字列が正確に（Ignore Case 設定を考慮して）一致する必要があります。空欄にすると空文字列を特定の値に置換することが可能です。よくある例としては古いコード、誤字、用語の不統一などがあります。

New Text: Original Text のすべての出現箇所を置き換える新しいテキストを指定します。空文字列を指定すれば、元のテキストを完全に削除できます。属性値内の一致箇所すべてに対して置換が行われます。ダウンストリームの処理へ与える影響を考慮し、新しいテキストがデータの整合性と意味を保つようにしてください。

Ignore Case: これを有効にすると Original Text 検索時に大文字小文字を区別しません。有効時は「approved」「Approved」「APPROVED」など大文字・小文字の差を無視してマッチングします。無効の場合は完全なケースの一致のみが置換されます。手入力や複数ソース間での不統一な大文字化への対応に役立ちます。

例

例 1：購買発注における部署名の標準化

シナリオ: 多国籍企業の購買発注システムで、「Information Technology」「IT Dept」「I.T.」「InfoTech」が同じ部署を指しているが分析や承認経路が分断されているため標準化を行う必要がある。

設定:

Attribute Name: Department
Original Text: IT Dept
New Text: Information Technology
Ignore Case: チェックあり

出力: 「IT Dept」および「it dept」「It Dept」などのバリエーションすべてが Department 属性内で「Information Technology」に置換される。さらに「I.T.」「InfoTech」など異なる原文でも複数回パスをかけることで完璧に統一。

置換前: | Case ID | Department | Amount | |---------|------------|--------| | PO-001 | IT Dept | $5,000 | | PO-002 | Information Technology | $3,000 | | PO-003 | it dept | $2,500 | | PO-004 | I.T. | $4,000 |

置換後: | Case ID | Department | Amount | |---------|------------|--------| | PO-001 | Information Technology | $5,000 | | PO-002 | Information Technology | $3,000 | | PO-003 | Information Technology | $2,500 | | PO-004 | Information Technology | $4,000 |

ポイント: 標準化後、情報技術部門の購買発注がバラバラの部署参照ではなく合計$14,500として把握されるようになり、予算管理やベンダーとの数量割引の交渉機会を発見。

例 2：システム移行後の製品コード更新

シナリオ: 小売業で新しい在庫管理システムに移行し、従来の「PROD-」コードを「SKU-」へ歴史的な注文データに対しても一括更新し、在庫調整の正確さを確保。

設定:

Attribute Name: Product_Code
Original Text: PROD-
New Text: SKU-
Ignore Case: チェックなし

出力: 「PROD-」で始まるすべての製品コードのプレフィックスを「SKU-」に変更。番号部分は保持し新フォーマットに一致させる。

置換前: | Case ID | Product_Code | Quantity | Order_Date | |---------|--------------|----------|------------| | ORD-501 | PROD-12345 | 10 | 2024-01-15 | | ORD-502 | PROD-67890 | 5 | 2024-01-16 | | ORD-503 | prod-12345 | 3 | 2024-01-16 | | ORD-504 | PROD-54321 | 8 | 2024-01-17 |

置換後: | Case ID | Product_Code | Quantity | Order_Date | |---------|--------------|----------|------------| | ORD-501 | SKU-12345 | 10 | 2024-01-15 | | ORD-502 | SKU-67890 | 5 | 2024-01-16 | | ORD-503 | prod-12345 | 3 | 2024-01-16 | | ORD-504 | SKU-54321 | 8 | 2024-01-17 |

ポイント: 「prod-12345」は大文字・小文字が違うため置換されず、47件の誤った小文字製品コードが別途品質調査の対象に。特定の倉庫管理の入力ミスが判明。

例 3：患者名の匿名化によるコンプライアンス対応

シナリオ: 医療提供者が研究目的で予約スケジュールのプロセスデータから患者名を匿名化しつつ、異なる患者を区別できる要件。

設定:

Attribute Name: Patient_Name
Original Text: Smith, John
New Text: Patient_001
Ignore Case: チェックなし

出力: 特定患者名を識別子に置換し、HIPAA準拠の匿名化を実現。プロセス分析に支障がない形で個人情報保護を達成。

置換前: | Case ID | Patient_Name | Appointment_Type | Department | |---------|--------------|------------------|------------| | APT-101 | Smith, John | Initial Consultation | Cardiology | | APT-102 | Jones, Mary | Follow-up | Orthopedics | | APT-103 | Smith, John | Test Results | Cardiology | | APT-104 | Brown, David | Emergency | Emergency |

置換後（最初の置換後）: | Case ID | Patient_Name | Appointment_Type | Department | |---------|--------------|------------------|------------| | APT-101 | Patient_001 | Initial Consultation | Cardiology | | APT-102 | Jones, Mary | Follow-up | Orthopedics | | APT-103 | Patient_001 | Test Results | Cardiology | | APT-104 | Brown, David | Emergency | Emergency |

ポイント: 同一患者の予約間の関係を保持しつつ、個人識別情報を除去。解析結果は初回心臓科受診患者の30日以内のフォローアップ率が73％であることを明らかに。

例 4：製造業での活動名の誤字訂正

シナリオ: 製造プラントのMESシステムで、オペレーターが「Quality Check」を誤って「Quaility Check」と入力することが多く、プロセス適合性チェックで誤った逸脱判定がされている。

設定:

Attribute Name: Activity
Original Text: Quaility Check
New Text: Quality Check
Ignore Case: チェックあり

出力: 大小文字違いを含めて誤字の全出現箇所を修正し、プロセスの正確な発見と適合性分析を実現。

イベントデータ置換前: | Case ID | Activity | Timestamp | Resource | |---------|----------|-----------|----------| | WO-801 | Material Receipt | 2024-02-01 08:00 | Warehouse | | WO-801 | Quaility Check | 2024-02-01 09:15 | QC Team | | WO-801 | Assembly Start | 2024-02-01 10:00 | Line 1 | | WO-802 | Material Receipt | 2024-02-01 08:30 | Warehouse | | WO-802 | QUAILITY CHECK | 2024-02-01 09:45 | QC Team |

イベントデータ置換後: | Case ID | Activity | Timestamp | Resource | |---------|----------|-----------|----------| | WO-801 | Material Receipt | 2024-02-01 08:00 | Warehouse | | WO-801 | Quality Check | 2024-02-01 09:15 | QC Team | | WO-801 | Assembly Start | 2024-02-01 10:00 | Line 1 | | WO-802 | Material Receipt | 2024-02-01 08:30 | Warehouse | | WO-802 | Quality Check | 2024-02-01 09:45 | QC Team |

ポイント: 訂正後は品質チェックを含むワークオーダーが98％と適合していることが判明。訂正前の67％という数字は実際にはデータ品質の問題による誤判定だった。

例 5：異なるシステム間でのステータスコード標準化

シナリオ: 物流会社が3つの異なる運送業者の配送データを統合する際に、配送ステータスが「DLVRD」「Delivered」「COMPLETE」と異なっているため、統一的な追跡ダッシュボードのために標準化が必要。

設定:

Attribute Name: Delivery_Status
Original Text: DLVRD
New Text: Delivered
Ignore Case: チェックなし

出力: 運送業者固有のステータスコードを共通のビジネス用語に置換し、一貫したステータス管理を可能にする。

置換前: | Case ID | Carrier | Delivery_Status | Delivery_Date | |---------|---------|-----------------|---------------| | SHP-901 | CarrierA | DLVRD | 2024-03-01 | | SHP-902 | CarrierB | Delivered | 2024-03-01 | | SHP-903 | CarrierC | COMPLETE | 2024-03-01 | | SHP-904 | CarrierA | DLVRD | 2024-03-02 |

置換後（最初の置換後）: | Case ID | Carrier | Delivery_Status | Delivery_Date | |---------|---------|-----------------|---------------| | SHP-901 | CarrierA | Delivered | 2024-03-01 | | SHP-902 | CarrierB | Delivered | 2024-03-01 | | SHP-903 | CarrierC | COMPLETE | 2024-03-01 | | SHP-904 | CarrierA | Delivered | 2024-03-02 |

ポイント: 追加置換で「COMPLETE」等も標準化したことで、全運送元の配送完了率が正確に94％と把握可能に。運送業者別の分断した報告では全体パフォーマンスが不明瞭だった。

出力

Replace Text エンリッチメントは、選択した属性値をデータセット内で直接変更し、指定したテキストパターンをインプレースで置換します。元の属性の構造やデータ型は保持しつつ、検索条件に合致したテキストだけを更新します。

ケース属性の場合はケースごとに1回の置換を行い、各ケースに関連付けられた属性値が対象です。イベント属性の場合はデータセット内のすべてのイベントに対して置換を実行し、同一ケース内の複数出現箇所も更新される可能性があります。NULL値は保持され、選択した属性の非NULL文字列のみが処理対象です。

実行後、属性は元の名前と位置のまま変更済みテキスト値を含みます。これらの変更は、変更属性を参照するすべての計算、フィルター、可視化に即座に反映されます。エンリッチメントは新しい属性やバックアップ列を生成せず、設定通りに既存のデータを直接変換します。

置換操作はデフォルトで大文字小文字を区別しますが、Ignore Case 設定により大文字小文字を区別しないマッチングも可能です。大文字小文字を無視する置換時は、マッチしなかった部分の元の大小文字は保持しつつ、マッチした部分のみ指定した New Text で完全に置換されます。

テキスト置換

概要

主な用途

設定

例

例 1：購買発注における部署名の標準化

例 2：システム移行後の製品コード更新

例 3：患者名の匿名化によるコンプライアンス対応

例 4：製造業での活動名の誤字訂正

例 5：異なるシステム間でのステータスコード標準化

出力

関連項目