# 妥当性

> DQSが測定する6つの妥当性指標、フォーマットエラーとノイズを見つける診断フロー、そしてパターンベースの検証を設定する方法について解説します。

Source: https://dataqualitysense.com/ja/resources/data-quality/validity/
Last updated: 2026-04-16

---

## 妥当性とは

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

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

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

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

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

### 妥当性と精度の違い

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

| チェック対象 | 妥当か | 正確か |
|-------|--------|-----------|
| john@company.com | はい | 検証なしでは不明 |
| john@company | いいえ | 該当なし（フォーマットが不正） |
| john.doe@formerjob.com | はい | いいえ（本人が退職済み） |
| 555-123-4567 | はい | 電話するまでは不明 |
| 555-12-456 | いいえ | 該当なし（桁数が誤り） |

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

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

## 妥当性が重要な理由

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

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

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

| システム | 妥当性の影響 |
|--------|-----------------|
| メールキャンペーン | バウンスが送信者評価を損なう |
| テレフォニー | 無効な番号がダイヤラー時間を浪費する |
| Webリンク | 壊れたURLがエンリッチメントとナビゲーションを妨げる |
| API | 不正なデータが同期失敗を引き起こす |
| AIとAgentforce | 一貫性のないフォーマットがモデル精度を下げる |

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

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

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

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

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

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

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

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

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

| 指標 | 示す内容 |
|--------|-------------------|
| **Invalid率** | 妥当性スコアの否定的な表現です。「メールアドレスの29%は構造的に無効」のほうが、「71%が妥当」よりも経営会議で注目を集めます。同じデータですが、行動を促すフレーミングです。 |
| **Invalid件数** | クレンジング作業量を具体的な数字で示します。あなたの会社はE.164フォーマットを要求する新しいテレフォニーシステムに移行しています。電話フィールドのInvalid件数は23,400件です。これが移行稼働前に再フォーマットが必要な正確なレコード数です。 |

### ステップ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つの問題を区別します。

| 問題 | 指標 | 根本原因 | 対処法 |
|---------|---------|------------|-----|
| **フォーマットエラー** | 妥当性率、Invalid率、Valid/Invalid件数 | 人のミス、インテグレーションのバグ、入力規則の欠如 | データをクレンジング：入力規則、データ変換、エンリッチメント |
| **ノイズとゴミ** | Noise率、Noisy Records件数 | ボット、強制フォーム送信、デフォルト値にゴミが入った一括インポート | 発生源を修正：CAPTCHA、必須フィールドの再設計、レコード削除 |

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

## 指標リファレンス

### 基礎指標

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

| 指標 | タイプ | 測定内容 |
|--------|------|-----------------|
| 妥当性率 | パーセンテージ | 設定したパターンに一致するレコードの割合 |
| Valid件数 | 件数 | 設定したパターンに一致するレコードの数 |

### 高度指標

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

| 指標 | タイプ | 測定内容 |
|--------|------|-----------------|
| Invalid率 | パーセンテージ | 設定したパターンに失敗するレコードの割合 |
| Invalid件数 | 件数 | 設定したパターンに失敗するレコードの数 |
| Noise率 | パーセンテージ | ノイズパターン（ゴミデータ）を含むレコードの割合 |
| Noisy Records件数 | 件数 | ノイズパターンを含むレコードの数 |

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

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

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

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

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

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

| 指標 | 全6フィールドタイプ | StringとTextAreaのみ |
|--------|:--:|:--:|
| 妥当性率 | X | |
| Valid件数 | X | |
| Invalid率 | X | |
| Invalid件数 | X | |
| Noise率 | | X |
| Noisy Records件数 | | X |

パターンベースの指標（妥当性率、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指標すべてを生成します。フォーマットエラーとゴミデータを区別する必要がある場合、またはクレンジングプロジェクトの計画で正確な件数が必要な場合にこのモードを使います。

| ビジネスニーズ | 推奨モード |
|---------------|-----------------|
| 簡易フォーマット準拠チェック | Format Validation |
| コンプライアンスレポートまたは監査 | Advanced（規制当局向けの完全な内訳） |
| Lead品質評価 | Advanced（フォーマットチェックを通過するゴミをNoise率で捕捉） |
| 移行前のデータ評価 | Advanced（カテゴリ別に対応範囲を設定するための完全な内訳） |
| 継続的データガバナンス | Format Validationから始め、ノイズ検出のためにAdvancedへ |

## 妥当性の設定

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

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

| 設定 | 制御内容 |
|---------|-----------------|
| **Pattern Type** | 検証対象のフォーマット。Email、URL、Fixed Length、Customの正規表現から選択します。必須：スキャンを実行する前にパターンタイプを選択する必要があります。 |
| **Pattern / Fixed Length** | 選択したタイプの具体的な値。Fixed Lengthには文字数（1〜255）を入力します。Customには正規表現を入力します。EmailとURLには組み込みパターンを使用します。 |
| **Custom Pattern** | Pattern TypeをCustomに設定したときに使う独自の正規表現。DQSは保存前に正規表現を検証し、無効な式をブロックします。 |
| **Include Blanks** | 有効にすると、DQSは空欄の値を無効として数えます。無効（デフォルト）にすると、空欄は評価から完全に除外されます。 |
| **Case Sensitive** | 有効にすると、パターンマッチングが大文字小文字を区別します。無効（デフォルト）にすると、マッチングは大文字小文字を区別しません。 |

### パターンタイプ

| タイプ | 検証内容 | 通過例 | 失敗例 |
|------|-------------------|-------------|-------------|
| **Email** | 標準的なメールアドレス形式：user@domain.tld | user@example.com | user@domain、invalid-email |
| **URL** | 有効なドメインを持つHTTP/HTTPS Webアドレス | https://example.com | example.com、htp://site.com |
| **Fixed Length** | 正確な文字数（あなたが数字を定義） | `AAAAAAAAAA`（10文字、length=10の場合） | `SHORT`（5文字） |
| **Custom** | ユーザー定義の任意の正規表現パターン | パターン次第 | パターン次第 |

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

## ノイズ検出

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

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

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

| ヒューリスティクス | 捕捉する内容 | ノイジーな値の例 | クリーンな値の例 |
|-----------|-----------------|---------------------|---------------------|
| 3文字以上の同一文字連続 | パディング、フィラー、キーボード長押し | 「aaaa」「!!!」「---」「xxxxx」 | 「Premium」「DOT AB3 2024」 |
| 50%超の特殊文字 | キーボード叩きつけ、ボット入力、ゴミ | 「!@#$%^」「***test」「//--//」 | 「test@email.com」「O'Brien Inc」 |

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

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

## よくある妥当性の問題

### 無効なメールアドレス

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

| 問題 | 例 |
|-------|---------|
| @の欠落 | john.company.com |
| ドメインの欠落 | john@ |
| ダブルドット | john@company..com |
| タイプミス | john@comapny.com |

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

### 不正な電話番号

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

| 問題 | 例 |
|-------|---------|
| 文字が混在 | 555-CALL-NOW |
| 桁数が誤り | 555-12 |
| 内線がフィールドに | 555-1234 ext 5 |
| 国番号の混乱 | 1-555-123-4567対555-123-4567 |

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

### 無効なURL

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

| 問題 | 例 |
|-------|---------|
| プロトコルの欠落 | www.company.com |
| ドメインの欠落 | https:// |
| タイプミス | htps://company.com |
| ソーシャルハンドル | @company（URLではない） |

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

## ベストプラクティス

### 入力時に検証する

最良の妥当性チェックはデータ入力時に行われます。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://`プロトコルを要求しましょう。チームが標準を知れるよう、フォーマットに関する決定をドキュメント化しましょう。

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

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

| フィールド | 推奨しきい値 | 根拠 |
|-------|---------------------|-----------|
| メインEmail | 95%以上 | コミュニケーションに不可欠 |
| 電話 | 90%以上 | 重要だがレガシーデータもある |
| Webサイト | 85%以上 | 不完全な入力が多い |
| カスタムテキストコード | 98%以上 | システム生成、高い準拠率が期待される |

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

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

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

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

## 次のステップ

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

- **次へ：**[一意性](/ja/resources/data-quality/uniqueness/) - 重複レコードを検出し防ぐ
- **前へ：**[完全性](/ja/resources/data-quality/completeness/) - 必要なデータが存在することを確認する
- **関連：**[5つの次元](/ja/resources/data-quality/five-dimensions/) - すべての次元の概要
- **アクション：**[AI対応度診断](/ja/ai-readiness/) - 現在の妥当性スコアを確認する