完全性：設定シナリオ

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

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

これらのウォークスルーは、メインの完全性記事の概念を基にしています。完全性指標や診断ファネルに不慣れな方は、まずそちらをお読みください。

シナリオ1：Contactのメール衛生

問題

営業チームは、メールキャンペーンの配信率が低いと報告しています。マーケティング運用チームはデータのせいにしていますが、実際にどれほどのメールデータが欠けているかは誰にもわかりません。使用可能なメールアドレスを持たないContactの明確な件数が必要です。

設定

これは単純な入力率チェックです。ContactオブジェクトでBasic Completenessモードを使い、Emailフィールドを対象とします。

EmailフィールドはSalesforceのテキスト系フィールドなので、DQSはnullと空欄の内訳の両方を生成します。

サンプル結果

総Contactレコード：10,000件。

結果の読み方

看板指標から始めます。完全性73%。つまり2,700件のContactにメールアドレスがありません。メールキャンペーンは10,000件のうち最大でも7,300件にしか到達できません。

次に診断ファネルを進み、なぜ2,700件のレコードが空なのかを理解しましょう。

**null件数：1,800。**これらのContactには一度もメールが入力されていません。フィールドは触れられていません。このパターンは、担当者が迅速なデータ入力中にメールフィールドをスキップして手動作成されたレコードや、メールを取得しないシステムからインポートされたレガシーレコードで一般的です。

**空欄件数：900。**これらのContactはメールフィールドに空文字列を持ちます。フィールドは書き込まれましたが、値はありません。このパターンは異なる根本原因を示します。メールフィールドが空のままでもレコードを送信するWebフォームインテグレーションです。インテグレーションはフィールドをnullのままにせず、''（空文字列）を書き込みます。

2つの根本原因には2つの異なる修正が必要です。

• **1,800件のnullには：**データ入力のギャップに対処します。Contactページレイアウトでメールフィールドを必須にするか、レコード作成時にプロンプトを追加します。
• **900件の空欄には：**インテグレーションを修正します。Webフォームにクライアントサイドの検証を追加して空のメールフィールドが送信されないようにするか、メールで空文字列を拒否するSalesforce入力規則を追加します。

次に行うこと

空件数（2,700）を使ってデータエンリッチメントプロジェクトの範囲を決めます。データベンダーと協力する場合、これがコスト見積もりのレコード数です。完全性率を時系列で追跡し、修正が機能しているかを測定します。

シナリオ2：Accountの業種プレースホルダ検出

問題

Accountセグメンテーションレポートは、Accountの94%に業種値があることを示しています。マーケティングはこの数字を信頼し、キャンペーンのターゲティングに使っています。94%は「N/A」や「Unknown」などデータに見えるが情報を持たないプレースホルダ値で水増しされているのではないかと疑っています。

設定

AccountオブジェクトでContextual Completenessモードを使い、Industryフィールドを対象とします。このモードはプレースホルダ検出を有効にし、仮説をテストするために必要なものです。

このスキャンでは大文字小文字の区別をオフにしましょう。ユーザーはプレースホルダをあらゆる大文字小文字で入力します。「n/a」「N/a」「N/A」のように。すべてのバリアントを捕捉することで真の姿が見えます。

サンプル結果

総Accountレコード：10,000件。

結果の読み方

看板数値は健全に見えます。完全性94%。しかしこれがまさに誤解を招くと疑っていたものです。

空件数とIncompleted件数の差を見ましょう。空件数は600件のレコードに全く値がないと伝えます。Incompleted件数は2,400件のレコードに使用可能な値がないと伝えます。その差は1,800件のプレースホルダ値を持つレコードです。

計算は次の通りです。

Incompleted件数（2,400）= 空件数（600）＋ プレースホルダ件数（1,800）

600件のレコードは目に見えて空です。標準的なSalesforceレポートを実行すれば誰でもこれらに気づきます。しかし1,800件のレコードには「N/A」「Other」「Unknown」のような値が含まれており、実際のセグメンテーションデータを提供せずに完全性率を水増ししています。

真の使用可能な完全性は94%ではなく76%に近い値です。その18ポイントのギャップは、標準レポートが見逃す隠れた不完全性です。

**なぜセグメンテーションにとって重要か：**マーケティングが「Technology」業種のAccountをターゲットとするキャンペーンを実行すると、セグメント件数は正確です。しかし業種別の総カバレッジを示すレポートを実行すると、94%の看板は「入力済み」レコードの5件に1件近くが使用可能な業種情報を持たないという事実を隠します。テリトリー割り当て、業種ベースのルーティング、経営ダッシュボードはすべてこの歪みを引き継ぎます。

次に行うこと

データエンリッチメントプロジェクトの範囲を600件ではなく2,400件にしましょう。クレンジング目標は空件数ではなくIncompleted件数です。Account管理者と協力して実際の業種値を埋めるか、エンリッチメントサービスを使いましょう。クレンジング後にスキャンを再実行して改善を測定します。

シナリオ3：AI対応のためのCase説明の深さ

問題

あなたの会社はサポートエージェント向けにCaseの説明を要約するAIツールを評価しています。ベンダーはAIが効果的に機能するには「リッチテキストデータ」が必要だと述べています。ツールに投資する前に、Case Descriptionフィールドに有用な要約を生成するのに十分な中身があるかを評価する必要があります。

設定

CaseオブジェクトでContextual Completenessモードを使い、Descriptionフィールドを対象とします。コンテキスト指標の完全なセットが必要です。プレースホルダ検出とテキスト品質指標（Rich Text Ratio、Text Field Utilization、Average Utilization）です。

ここでのプレースホルダリストは、サポートエージェントが実際にDescriptionフィールドをどう埋めるかを反映しています。実際の説明を書く代わりに、担当者は素早い略語を入力します。これらのエントリは技術的には入力されていますが、AIに要約するものを何も与えません。

サンプル結果

総Caseレコード：4,200件（空＋入力済み件数から推定、約4,200件中500件の空件数で88%の完全性率）。

結果の読み方

看板から始めます。完全性88%。テキストフィールドとしては健全に聞こえます。しかしこの分析はデータ衛生ではなくAI対応に関するものです。看板数値だけでは不十分です。

**Incompleted件数対空件数。**500件のレコードには説明が全くありません。しかしプレースホルダを含めると、1,800件のレコードが不完全です。1,300件のギャップは「See email」「Call back」「Pending」などのエントリを含みます。これらのレコードは基本的な完全性チェックを通過しますが、AIに使える材料を何も与えません。

**Rich Text Ratio：31%。**これがあなたの問いに答える数字です。Case説明のわずか31%のみが文字数しきい値を超える意味のあるコンテンツを持っています。残り69%の「入力済み」説明は、プレースホルダ（上記で既にカウント済み）か、AIが要約するには短く浅すぎるエントリ（「issue reported」「customer called」「escalated」など）です。

**Text Field Utilization：12%。**DescriptionフィールドはLong Text Areaで大きな文字容量を持ちます。データセット全体の平均でレコードは容量のわずか12%しか使っていません。これは、ほとんどのエントリが非常に短いことを確認します。

**Average Utilization：8.4%。**全レコードにわたる平均使用率はフィールド容量の8.4%です。ほとんどの説明は段落ではなく数語です。

**AI対応の判定：**AI要約ツールはCaseの約31%で有用な結果を生成します。残り69%では、AIは要約生成に失敗するか、文の断片に基づいて何かを生成するかのどちらかです。ツールはCase量の3分の2以上でパフォーマンスが低下します。

次に行うこと

AIツールにコミットする前にこのデータをステークホルダーに提示します。数字が明確に主張を示します。このAIプロジェクトはまずデータエンリッチメントのフェーズが必要です。目標Rich Text Ratio（60%以上から始める）を定義し、説明の品質を改善する計画を立てます。オプションには次のものがあります。

• 説明の最小文字数を要求するようCase作成プロセスを更新する
• 有用な説明の書き方についてサポートエージェントをトレーニングする
• Case受付中に詳細情報を促すスクリーンフローを追加する

各改善サイクル後にスキャンを再実行します。Rich Text RatioをAI対応のための主要進捗指標として追跡します。

設定の選択

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

13の完全性指標すべての完全なリファレンスと、それらが診断ファネルにどう収まるかについては、メインの完全性記事に戻ってください。

完全性とその他のデータ品質次元がAI対応にどう影響するかを確認するには、AI対応度診断を受けましょう。