一意性：設定シナリオ

これらのシナリオがカバーする内容

このページでは、DQS一意性分析の3つの実世界の設定を解説します。各シナリオは特定のビジネス問題を取り上げ、使用する正確な設定を示し、結果の読み方を説明します。

これらのウォークスルーは、メインの一意性記事の概念を基にしています。一意性指標、診断レイヤー、Basic UniquenessとAdvanced Uniqueness Analysisの違いに不慣れな方は、まずそちらをお読みください。

シナリオ1：Leadでのメール重複排除監査

問題

あなたのマーケティングチームはSalesforceを通じてナーチャーキャンペーンを実行しています。開封率は低下しており、メールプラットフォームは「重複送信」の増加を報告しています。同じ人が同じメールを2回受け取っているのです。重複管理ルールは完全一致のレコードを捕捉しますが、部分的な重複はすり抜けます。同じメールアドレスを持つ同じ人の2件のLeadレコードが両方ともキャンペーンを受け取ります。具体的な数字が必要です。何件のLeadメールアドレスが複数のレコードで共有されているでしょうか。

設定

これは単純な重複検出チェックです。LeadオブジェクトでBasic Uniquenessモードを使い、Emailフィールドを対象とします。

Case Sensitive OFFがデフォルトで、メールに対する正しい選択です。2件のレコードが「jsmith@acme.com」と「JSmith@Acme.com」を保存しているとき、それらは同じアドレスです。大文字小文字の区別を有効にすると、それらを別々に数え、重複を隠してしまいます。

サンプル結果

基礎指標：

評価された総Leadレコード：25,000件。

結果の読み方

看板から始めます。一意性74%。つまり26%のメールアドレスが複数のLeadレコードに現れているということです。25,000件のLeadのうち、異なるメールアドレスは18,500件しか存在しません。6,500件のギャップは共有されたメールアドレスです。

**26%の重複メールが実際にはどのようなものか。**一部は正当です。同じ会社の複数のContactで共有されるinfo@company.comやsales@company.comなどの部門アドレスです。ほとんどは異なる源から作成された重複Leadです。Webフォームが1件のLeadを作成します。リストインポートがもう1件を作成します。営業担当者が名刺から3件目を作成します。3件すべてが同じメールアドレスを持っています。

**Include Blanks ONが全体像を明らかにします。**Include Blanksを有効にすると、メールアドレスのないLeadはすべて1つの「空欄」値を共有します。25,000件のLeadのうち2,000件にメールがなければ、それらの2,000件のレコードは互いに重複としてカウントされます。これにより空欄を除外した場合と比べて一意性率が下がりますが、正直な数字が得られます。キャンペーンが到達できるのは25,000件ではなく、最大で18,500件の異なるアドレスです。

**ここではBasic Uniquenessで十分な理由。**問いは「何件のメールが重複しているか」です。一意性率とDistinct件数がその問いに答えます。重複排除プロジェクトを開始するかを決定するのにEntropyやRarityは必要ありません。後で分布パターン（何件のメールがちょうど2回現れるか対10回現れるか）を理解したければ、完全な姿のためにAdvanced Uniqueness Analysisに切り替えましょう。

次に行うこと

Distinct件数（18,500）をメールキャンペーンの実際の到達可能な母集団として使います。共有メールを持つレコードの重複排除プロジェクトの範囲を設定します。メールアドレスでグループ化したLeadをエクスポートし、重複をマージまたは削除します。クレンジング後、スキャンを再実行し、一意性率を時系列で追跡します。スキャン間で下がれば、新しい重複源が現れています。リストインポート、重複排除ロジックのないWebフォーム、既存レコードをチェックせずにレコードを作成するインテグレーションです。

シナリオ2：AccountのIndustryフィールド分布

問題

あなたのデータチームは、Accountを業種でグループ化するセグメンテーションモデルを構築しました。モデルは24の業種選択リスト値を使ってターゲットセグメントを作成します。しかしセグメントは不均等です。2つのセグメントがすべてのAccountの70%を含み、残りの22セグメントが他の30%を分け合っています。データサイエンスチームは、問題がモデルではなく業種フィールドの分布にあると疑っています。フィールドの値分布が本当に偏っているかを確認し、支配的な値を特定する必要があります。

設定

AccountオブジェクトでAdvanced Uniqueness Analysisモードを使い、Industryフィールドを対象とします。値がどのように広がっているかについての問いに答えるために分布指標（Entropy、Max Frequency、Rarity）が必要です。

このシナリオではInclude Blanks OFFが正しい選択です。既存のデータがカテゴリをまたいでどう分布しているかを分析しています。計算に空欄を追加すると、セグメンテーションの問いに答えずに分布指標を歪めます。業種値のないAccountが何件あるかを知りたい場合は、代わりに完全性分析を実行しましょう。

サンプル結果

基礎指標：

高度指標：

評価された総Accountレコード：15,000件。

結果の読み方

**一意性率（0.16%）はここでは想定内で無関係です。**業種は15,000件のレコードにわたって24の値を持つ選択リストです。ほぼすべての値が数百件のレコードで共有されています。選択リストフィールドでの低い一意性率は正常です。この指標はこの分析の焦点ではありません。

**Distinct件数（24）は選択リストが無傷であることを確認します。**設定されたすべての24の値がデータに現れます。無法な自由入力エントリは存在しません。データは一貫性の観点からクリーンです。

**Entropy（2.18）が偏りを明らかにします。**24の異なる値の最大エントロピーはlog2(24) = 4.58です。実際のエントロピーは2.18です。正規化スコアは2.18 / 4.58 = 0.48です。これは「支配的」分布のしきい値0.7を大幅に下回ります。少数の値がほとんどのレコードを占めています。データサイエンスチームの疑いは確認されました。セグメンテーションの問題はモデルではなくデータにあります。

正規化エントロピーの解釈方法：

スコア0.48は「支配的」範囲にあります。

**Max Frequency（5,200）が支配的な値を特定します。**1つの業種値が15,000件のうち5,200件のレコードに現れています。データセットの34.7%です。簡単な確認でそれが「Technology」であることがわかります。2番目に多い値がおそらく残りの集中のほとんどを占めています。合わせて、2つの値がチームが観察した70%の集中を占めています。

**Rarity（0%）はロングテールがないことを確認します。**24の異なる値のすべてが複数回現れます。シングルトン値は存在しません。これはよく管理された選択リストフィールドで想定される結果です。自由入力フィールドでは、タイプミスや一回きりのエントリを捕捉するためにRarityを確認したいところですが、選択リストでは0%のRarityは正常です。

**セグメンテーションの判定：**あなたの24カテゴリモデルは実際には2カテゴリシステムです。「Technology」と別の1つの業種がデータセットを支配しています。残り22カテゴリはレコードの30%を共有し、各カテゴリに平均約200件のレコードがあります。一部のセグメントは意味のある分析には小さすぎます。

次に行うこと

EntropyとMax Frequencyをデータサイエンスチームに提示します。数字が分布問題を確認します。2つのオプションがあります。（1）実際の分布を反映したより少なく広いカテゴリを使うようセグメンテーションモデルを再設計します。22の小さな業種を4〜5のマクロカテゴリにグループ化します。（2）業種データをエンリッチメントします。「Technology」の集中が、レコード作成時に担当者がデフォルトとして使うことで水増しされている場合、5,200件のレコードの大部分が異なる業種に属するかを調査します。定期スキャンを実行し、Entropyを時系列で追跡します。誤分類されたレコードを修正するにつれて、Entropyはより健全な分布に向けて上昇します。

シナリオ3：AI対応のためのCase説明の定型文検出

問題

あなたの会社はサポートチーム向けにAIによるCase要約を評価しています。AIツールはCaseのDescriptionフィールドを読み、次のCaseを担当するエージェント向けに要約を生成します。投資する前に、AIが有用な要約を生成するのに十分な独自コンテンツがCase説明に含まれているかを評価する必要があります。フィールドはCaseの95%で入力されているため、完全性は懸念ではありません。懸念は、サポートエージェントがすべてのCaseに標準テンプレートをコピーペーストしていることです。

設定

CaseオブジェクトでAdvanced Uniqueness Analysisモードを使い、Descriptionフィールドを対象とします。コンテンツの独自性を評価するために定型文指標が必要です。

ここではInclude Blanks OFFが理にかなっています。存在するコンテンツを評価しているのであって、欠けているコンテンツを数えているのではありません。空の説明を持つ5%のCaseは、完全性分析で既に処理されています。

サンプル結果

基礎指標：

高度指標：

評価された総Caseレコード：30,000件。

結果の読み方

**一意性率（97%）は健全に見えますが、誤解を招きます。**ほぼすべてのCase説明は、それぞれ独自のケース番号、顧客名、日付を含むため、技術的には異なります。フィールドは基本的な重複チェックを通過します。しかし「ユニーク」は「独自」を意味しません。

**Boilerplate Rate（42%）が真の物語を語ります。**Case説明全体のテキストコンテンツの42%が繰り返しまたはテンプレート化されています。エージェントは標準の冒頭（「サポートへのお問い合わせありがとうございます。お客様のケース番号は…」）、標準の結び（「他にご質問があればお気軽にお問い合わせください」）、標準の診断チェックリストをすべてのCaseに貼り付けます。ケース固有の詳細は中央部を埋めますが、すべての説明の半分近くがコピーペーストのコンテンツです。

**Boilerplate Percentage（68%）は問題がどれほど広がっているかを示します。**68%のCaseレコードがテンプレート化されたテキストを含みます。30,000件のうち20,400件です。定型文は少数のエージェントや1つのチームに限定されていません。サポートプロセスに組み込まれた組織的なパターンです。

**Boilerplate Records件数（20,400）が範囲数字です。**AIにデータを供給する前にテンプレートをクレンジングする労力を見積もる必要があれば、これが出発点です。20,400件のレコードに、AIがパターンとして学習するコンテンツが含まれていますが、それらのパターンは顧客の問題ではなくテンプレートです。

**AI対応の判定：**AI要約ツールはCaseの68%でテンプレート化されたコンテンツを処理します。顧客の問題ではなく、テンプレートを要約することを学習します。独自コンテンツを持つ32%のCaseでは、AIはうまく機能します。定型文を持つ68%では、要約はエージェントが既に暗記している標準的なフレーズを繰り返すだけになります。

**Entropy（14.8）は高く、テキストが文字レベルで多様であることを確認します。**これは97%の一意性率と整合します。各説明は異なります。Entropyはここで関連する指標ではありません。重複問題は同一の値ではないからです。問題は、それ以外はユニークなテキスト内の繰り返しコンテンツパターンです。それこそが定型文指標が捕捉するために設計されたものです。

次に行うこと

Boilerplate Rate（42%）とBoilerplate Percentage（68%）をAIプロジェクトのステークホルダーに提示します。数字が主張を示します。AIプロジェクトには導入前にコンテンツ品質改善フェーズが必要です。定型文を減らすための3つのアプローチがあります。

• テンプレートを削除する。エージェントが標準の冒頭と結びを貼り付けている場合、それらの要素をCaseレイアウトまたはスクリーンフローに組み込み、Descriptionフィールドを汚染しないようにします。Descriptionはケース固有の情報のみを捕捉するようになります。
• エージェントに効果的な説明の書き方をトレーニングする。高品質な説明の例（独自な32%から）を共有し、テンプレートのないエントリがより良いAI要約を生む理由を説明します。
• 過去データから定型文を取り除く。既存のCaseをAIに供給する前に、既知のテンプレートパターンをDescriptionフィールドから削除するテキスト処理ジョブを実行します。

各改善サイクル後にスキャンを再実行します。Boilerplate RateとBoilerplate Percentageをこのフィールドの主要なAI対応指標として追跡します。目標：AI要約ツールを導入する前にBoilerplate Percentageを30%未満、Boilerplate Rateを20%未満にします。

設定の選択

次の表を使って一意性分析の正しい出発点を選びましょう。

8つの一意性指標、3つの診断レイヤー、設定詳細の完全なリファレンスについては、メインの一意性記事に戻ってください。

自社のデータ品質を測定する準備ができましたか？AI対応度診断を受けて一意性スコアなどを確認しましょう。