妥当性

妥当性とは

妥当性は、データ値が期待されるフォーマットやパターンに準拠しているかを測定します。値は定義された構造に一致するときに妥当といえます。フォーマットルールを破るときは無効となります。

メールアドレスは「@」記号とドメインを含むときに妥当です。URLはプロトコルで始まり、ドメインを含むときに妥当です。製品コードはシステムが要求する正確な文字数を持つときに妥当です。

DQSは正規表現（regex）パターンを使ってフィールド値を検証します。Email、URL、Fixed Lengthといった一般的なフォーマットの組み込みパターンから選ぶか、業務固有のフォーマット向けに独自の正規表現を記述できます。

妥当性率 =（パターンに一致するレコード / 全レコード）× 100

Contactレコード50,000件のうち35,500件のメールアドレスがメールフォーマットパターンに一致すれば、Emailの妥当性率は71%です。残り29%はパターンチェックに失敗する値を含んでいます。

妥当性と精度の違い

妥当性と精度は異なる概念です。

DQSは妥当性を測定します。フォーマットチェックは自動化できるからです。精度には外部での検証または人による確認が必要です。

妥当なデータは、現実を反映していなくてもシステム内で機能します。無効なデータは現実の真偽に関係なくシステムを破綻させます。まず妥当性に焦点を当て、精度は検証プロセスを通じて対処しましょう。

妥当性が重要な理由

無効なデータはスタック全体で障害を引き起こします。バウンスメールは送信者評価を損ない、不正な電話番号はダイヤラーの時間を浪費し、壊れたURLはユーザーを苛立たせエンリッチメントツールを妨げます。

APIは不正なデータを拒否します。インテグレーションが無効なメール形式をマーケティングプラットフォームに送ると、バッチ全体が失敗することがあります。フィールド値を解析するSalesforceのフローは、フォーマットが想定外だと破綻します。

AIモデルはテキストをそのまま処理します。電話フィールドにクリーンな番号ではなく「Phone: 555-1234」が入っていると、モデルは一貫性のないパターンを見ることになります。無効なフォーマットはAIの有効性を下げ、信頼できないAgentforce出力を生みます。

DQSによる妥当性の測定方法

DQSは次の診断的な問いを軸として6つの妥当性指標を算出します。「データはパターンに一致しているか、そして通過した値の中にゴミが隠れていないか」

これらの指標は診断フローのようなものです。各ステップが問題のより深い層を明らかにします。

ステップ1：パターンに一致しているか

妥当性率は看板となる指標です。フィールド値が設定したパターンに一致するレコードの割合を計算します。ダッシュボードに掲載する数字がこれです。

ContactのEmailフィールドにEmailパターンを設定します。妥当性率は71%と返ります。つまり29%のメールアドレスがフォーマットチェックに失敗しているということです。「@」記号が欠けていたり、ドメインがなかったり、スペースを含んでいたりします。これらのアドレスに送ったマーケティングキャンペーンはすべてバウンスします。メールでトリガーされる自動化ワークフローはすべて無言で失敗します。

Valid件数は絶対数を示します。Contact 50,000件のうち、35,800件が妥当なメールアドレスを持ちます。それが実際にメールキャンペーンで到達可能な母集団です。システム内の50,000件ではありません。マーケティングは水増しされた数字ではなく、現実的なキャンペーン予測を立てられます。

ステップ2：全体像はどうか

率は深刻度を示し、件数は作業量を示します。2つの指標が画像を完成させます。

ステップ3：フォーマットエラー以外にゴミはあるか

値はフォーマットチェックを通過しても、ゴミである可能性があります。Web-to-leadフォームがCompanyフィールドを必須にしているとします。Companyの妥当性率は98%です。ほとんどすべてが基本的なテキストパターンを通過するからです。しかしNoise率を見ると、それらの値の14%が「asdf」「test」「xxxxx」「na na na」といった入力であることがわかります。フォーマット的には妥当ですが、営業ルーティング、エンリッチメント、セグメンテーションには全く使えません。

Noisy Records件数はクレンジングの範囲を示します。50,000件のレコードでNoise率が14%なら、7,000件のLeadに意味のない会社名が入っていることになります。運用チームはクレンジングキューを構築し、工数を見積もり、自動削除にするか手動レビュー対象とするかを決められます。

2種類の障害

妥当性指標は、根本的に異なる2つの問題を区別します。

この区別は重要です。修正の方法がまったく異なるからです。フォーマットエラーはデータクレンジングで改善します。ノイズは発生源を修正することで改善します。

指標リファレンス

基礎指標

次の2つの指標は、妥当性分析の基盤を成します。一致率と通過したレコード数を示します。

高度指標

次の4つの指標は「一致するか」を超えて、ノイズ検出を含む完全な内訳を提供します。Advanced Format Validation分析モードが必要です。

率と件数がペアである理由

ほとんどの指標は率（パーセンテージ）と件数（絶対数）の両方で提供されます。これは意図的なものです。

• 率はダッシュボード、経営層向けレポート、トレンド追跡のためのものです。「妥当性が今四半期で71%から92%に改善した」
• 件数はプロジェクト計画、作業量見積もり、クレンジング範囲設定のためのものです。「再フォーマットが必要な電話番号が23,400件ある」

進捗の伝達には率を使いましょう。作業計画には件数を使いましょう。

フィールドタイプのカバレッジ

6つの妥当性指標はすべて同じ基本フィールドタイプをサポートします。ただしノイズ指標はテキストフィールドに限定されます。

パターンベースの指標（妥当性率、Valid件数、Invalid率、Invalid件数）はサポートされる6つのフィールドタイプすべてで機能します。String、TextArea、Email、Phone、URL、Picklistです。

ノイズ指標（Noise率、Noisy Records件数）はStringフィールドとTextAreaフィールドにのみ適用されます。連続する文字やキーボードを叩きつけたようなノイズパターンは自由入力テキストの現象です。妥当な選択リスト値を持つPicklistフィールドにはノイズは含まれません。ノイズ検出は、ユーザーが自由入力できるフィールドでのみ意味を持ちます。

2つの分析モード

DQSには2つの妥当性分析モードがあります。

Format Validationは「フィールド値は期待されるパターンに一致しているか」という問いに答えます。2つの基礎指標を生成し、フォーマット準拠チェックや簡単な監査に必要な要素をカバーします。

Advanced Format Validationはさらに深く掘り下げます。完全なValid/Invalidの内訳とノイズ検出を含む6指標すべてを生成します。フォーマットエラーとゴミデータを区別する必要がある場合、またはクレンジングプロジェクトの計画で正確な件数が必要な場合にこのモードを使います。

妥当性の設定

完全性（どのフィールドでも自動的に機能する）とは異なり、妥当性には設定が必要です。DQSがチェックできるようになる前に、各フィールドで「妥当」とは何を意味するかを定義する必要があります。パターンのない妥当性スキャンは無意味です。何と比較して妥当なのか、という問いに答えられないからです。

DQSは5つの設定入力を提供します。それぞれグローバルレベル（すべてのフィールドに適用）で設定し、個別フィールドレベルでオーバーライドできます。

パターンタイプ

**例：**あなたの製品コードは「DQS-」の後に6桁の数字が続く形式です。Pattern TypeをCustomに設定し、正規表現^DQS-\d{6}$を入力します。DQSはこの構造に一致しない製品コードをすべてフラグします。

ノイズ検出

ノイズ検出は、フォーマットチェックを通過してもゴミであるデータを捕捉します。DQSはノイジーな値を特定するために2つの組み込みヒューリスティクスを使います。

**ヒューリスティクス1：連続する同一文字。**同じ文字が3つ以上連続する場合です。「aaaa」「!!!」「---」「xxxxx」といった値がこのチェックに引っかかります。通常、キーボード長押し、パディング、プレースホルダ濫用から生じます。

**ヒューリスティクス2：特殊文字の過剰使用。スペースを除く非英数字が50%を超える場合です。「!@#$%^」「*///---」といった値がこのチェックに引っかかります。これらはキーボードを叩きつけたような入力、ボット入力、または意図的なゴミ入力を示します。

組み込みヒューリスティクスではカバーできない組織固有のゴミについては、正規表現を使ってカスタムノイズパターンを定義することもできます。

**ヒント：**ノイズ検出は、ユーザーが何でも入力できる自由入力フィールドで最も価値があります。Company、Description、Notes、カスタムテキストフィールドなどです。ボット送信や強制入力が最も多いWeb-to-leadフィールドから実行しましょう。

よくある妥当性の問題

無効なメールアドレス

ユーザーが適切なフォーマットなしにメールを入力します。「@」記号の欠落、ドメインの欠落、ダブルドット、タイプミスが最も一般的な問題です。

**影響：**バウンスメール、損なわれた送信者スコア、失われたコミュニケーション。

不正な電話番号

Salesforceの電話フィールドはあらゆるテキストを受け付けるため、一貫性のない無効なフォーマットが生じます。

**影響：**失敗する発信、浪費される営業時間、テレフォニー同期エラー。

無効なURL

Webアドレスフィールドには部分的または不正な値が入ることがよくあります。

**影響：**壊れたリンク、失敗するエンリッチメント、ナビゲーションエラー。

ベストプラクティス

入力時に検証する

最良の妥当性チェックはデータ入力時に行われます。Salesforceの入力規則を使って、データがシステムに入る前にフォーマットを徹底しましょう。

// 例：メールフォーマットの入力規則
NOT(ISBLANK(Email)) && NOT(REGEX(Email, "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,}$"))

スキャン前にフォーマットを標準化する

各フィールドにつき1つのフォーマットを選び徹底しましょう。電話番号では、E.164（+15551234567）が最も広く受け入れられている標準です。URLではhttps://プロトコルを要求しましょう。チームが標準を知れるよう、フォーマットに関する決定をドキュメント化しましょう。

フィールドの優先度でしきい値を設定する

フィールドによって妥当性の基準は異なります。

自由入力フィールドでノイズ検出を使う

ユーザーが自由入力できるフィールドでノイズ検出を実行しましょう。Company、Description、カスタムテキストフィールド、Webフォームで入力されるフィールドです。Noise率は、フォーマット検証では見逃す問題を明らかにします。

期待フォーマットをドキュメント化する

各フィールドの期待フォーマット、許容されるバリエーション、妥当な値と無効な値の例を記載したデータディクショナリを作成しましょう。チームと共有し、データクレンジングプロジェクトの際に参照しましょう。

次のステップ

データフォーマットを検証し、ノイジーな値を検出する方法を理解しました。次の次元について学び続けましょう。

• 次へ：一意性 - 重複レコードを検出し防ぐ
• 前へ：完全性 - 必要なデータが存在することを確認する
• 関連：5つの次元 - すべての次元の概要
• アクション：AI対応度診断 - 現在の妥当性スコアを確認する