# 適時性：設定シナリオ

> 異なるビジネスニーズに対してDQS適時性分析を設定する方法を示す3つの実践的ウォークスルーです。

Source: https://dataqualitysense.com/ja/resources/use-cases/timeliness-scenarios/
Last updated: 2026-04-16

---

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

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

これらのウォークスルーは、メインの[適時性](/ja/resources/data-quality/timeliness/)記事の概念を基にしています。適時性指標、診断フロー、Freshness WindowやNull As Staleなどの設定オプションに不慣れな方は、まずそちらをお読みください。

## シナリオ1：カスタム日付フィールドでのLeadアウトリーチ鮮度

### 問題

あなたの営業チームはLeadオブジェクトのカスタム`Last_Outreach_Date__c`フィールドで、各Leadが最後に連絡された日時を追跡しています。SDRは各通話またはメール後に手動でこのフィールドを更新します。CRMは8,000件のオープンLeadを示していますが、最近アウトリーチがあるLeadが何件あるかは誰も知りません。一部のLeadはフィールドが空欄のまま残され、一度も連絡されていません。営業運用チームは、キューに優先順位をつけ、抜け落ちたLeadを捕捉するために、新鮮対古いLeadの明確な件数が必要です。

> **なぜカスタムフィールドか？**標準のSalesforce日付フィールド（`LastModifiedDate`など）は常に入力され自動的に更新されます。`Last_Outreach_Date__c`のようなカスタム日付フィールドはユーザー入力に依存します。null（一度も連絡されていない）、古い（数か月前に連絡）、または最新のいずれかになり得ます。これがNull As Staleを有効にした鮮度分析の良いターゲットです。

### 設定

これは単純な鮮度チェックです。Leadオブジェクトで**Data Freshness**モードを使い、`Last_Outreach_Date__c`フィールドを対象とします。高度な異常指標ではなく、看板となる鮮度率と古さの内訳が必要です。

| 設定 | 値 | 理由 |
|---------|-------|-----|
| 分析モード | Data Freshness | 期限追跡や異常検出ではなく鮮度率と古さ率が必要 |
| Freshness Window | 30日 | アクティブなLeadは過去1か月以内のエンゲージメントが必要 |
| Null As Stale | ON | `Last_Outreach_Date__c`がnullであれば、Leadは一度も連絡されていない。定義上古い。 |

`Last_Outreach_Date__c`は「最終イベント」フィールドです。ここでは鮮度率が正しい看板指標です。Overdue Rateは、ほとんどのアウトリーチ日付が本質的に過去にあるため、循環論法的に高い値を示してしまいます。

### サンプル結果

| 指標 | 値 |
|--------|-------|
| 鮮度率 | 38% |
| 古さ率 | 62% |

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

### 結果の読み方

看板から始めます。鮮度38%。つまり62%のオープンLead、4,960件のレコードが過去30日間にアウトリーチされていないということです。SDRは8,000件のLeadのプールから働いており、そのうちほぼ3分の2が冷めた状態です。

次に62%の古さに含まれる内容を分解しましょう。

**Null As StaleはONなので、nullは古いとして数えられます。**それらの4,960件の古いレコードのうち1,200件が`Last_Outreach_Date__c`がnullなら、それらのLeadは一度も連絡されていません。Webフォーム、インポート、またはインテグレーションを通じてシステムに入ったが、誰もアウトリーチを記録しませんでした。残り3,760件のレコードにはアウトリーチ日付がありますが、30日より古いです。

2つのグループ、2つの異なるアクション：

- **1,200件のnullには：**これらは触れられていないLeadです。初回連絡のためにSDRにルーティングします。伝統的な意味で「古い」のではありません。抜け落ちたLeadです。
- **3,760件の古いアウトリーチ日付には：**アウトリーチは行われたがエンゲージメントが止まったLeadです。年齢分布をレビューします。ほとんどの日付が31〜45日の範囲に集中していれば、素早いフォローアップキャンペーンで多くを新鮮な範囲に戻せます。ほとんどの日付が90日以上前なら、リサイクルまたはアーカイブを検討します。

### 次に行うこと

鮮度率を使ってLeadプールをセグメント化します。`Last_Outreach_Date__c`が過去30日以内のリストビューまたはレポートを作成し、それらの3,040件の新鮮なLeadをまずSDRにルーティングします。鮮度率を時系列で追跡します。スキャン間で下がれば、Leadフォローアッププロセスにギャップがあります。上がれば、アウトリーチサイクルが機能しています。

---

## シナリオ2：契約更新期限の追跡

### 問題

あなたのカスタマーサクセスチームは2,500件のアクティブな契約を管理しています。更新はAccountオブジェクトの`Contract_End_Date__c`フィールドで追跡されます。チームは四半期ごとに今後の更新レポートを受け取りますが、更新されずに期限を過ぎた契約は数週間気づかれません。誰かが期限切れ契約に気づく頃には、顧客はすでに競合の評価を始めています。何件の契約が期限超過し、どれほど過ぎているかを測定する方法が必要です。

### 設定

Accountオブジェクトで**Advanced Data Freshness**モードを使い、`Contract_End_Date__c`フィールドを対象とします。これは「期限超過」が直接的なビジネス上の意味を持つ期限フィールドなので、猶予期間付きのOverdue Rateが必要です。

| 設定 | 値 | 理由 |
|---------|-------|-----|
| 分析モード | Advanced Data Freshness | 完全な期限の姿のためにOverdue RateとAverage Ageを有効化 |
| Freshness Window | 365日 | 契約は年次更新。過去1年以内の契約終了日は「最新」。 |
| Null As Stale | ON | null契約終了日は日付が一度も設定されていないことを意味する。クリーンなレコードではなくデータギャップ。 |
| Overdue Tracking | ON | これは期限フィールド。何%が期限を過ぎているか知る必要がある。 |
| Grace Period | 30日 | 期限超過としてフラグする前に、契約終了日後30日の更新プロセスの余裕を与える。更新はしばしば期限後の数週間で成立する。 |

`Contract_End_Date__c`は期限フィールドです。ここでは鮮度率ではなくOverdue Rateが正しい看板指標です。問いは「何件の契約日付が最近か」ではなく「何件の契約が期限を過ぎているか」です。

### サンプル結果

**基礎指標：**

| 指標 | 値 |
|--------|-------|
| 鮮度率 | 64% |
| 古さ率 | 34.8% |

**高度指標：**

| 指標 | 値 |
|--------|-------|
| Average Age | 210日 |
| Future Rate | 1.2% |
| Overdue Rate | 14% |

評価された総Accountレコード：2,500件。

### 結果の読み方

**Overdue Rate（14%）が看板数値です。**350件の契約が、更新されずに終了日から30日以上経過しています。これらはアクティブな収益漏れのリスクです。30日の猶予期間は通常の更新期間内の契約を既にフィルタしているので、これらの350件は本当に立ち往生しています。

**鮮度率（64%）がコンテキストを提供します。**契約終了日の64%が過去365日以内にあります。これは、ほとんどの契約が更新サイクル内に触れられていることを示します。古い34.8%には、期限超過の契約と、更新後に一度も更新されなかった非常に古い終了日の契約の両方が含まれます。

**Average Age（210日）が問題の深さを明らかにします。**契約終了日の平均経過期間は210日です。365日の鮮度期間を考えると、この平均は期間内にありますが古さ境界に近いところにあります。データセットは古い日付に偏っており、多くの契約が次の更新期間に近づいています。

**Future Rate（1.2%）が未来の契約終了日を持つ30件のレコードをフラグします。**契約終了日にとって、未来の日付は正常です。契約がまだ期限切れではないことを意味します。2,500件のうち1.2%のFuture Rateは、未来の終了日を持つものが30件だけであることを示します。これは有用なデータポイントです。システム内のほとんどの契約がすでに終了日を過ぎており、`Contract_End_Date__c`フィールドは更新延長を反映するためにめったに更新されていないことを教えてくれます。

**ビジネスの計算：**350件の期限超過契約は、平均契約価値でリスクにさらされている実際の収益を表します。平均年次契約が15,000ドルなら、記録上アクティブな更新のない期限超過の契約に525万ドルが存在することになります。

### 次に行うこと

350件の期限超過契約から優先順位キューを構築します。契約価値と期限超過日数でソートします。それぞれを直ちにアウトリーチのためにカスタマーサクセスマネージャーに割り当てます。初回クレンジング後、毎月スキャンを実行します。Overdue Rateを主要な更新健全性指標として追跡します。スキャン間でOverdue Rateが上昇すれば、更新プロセスが遅れを取っているということです。

---

## シナリオ3：データ移行後のパイプライン日付クレンジング

### 問題

あなたの会社は6か月前にレガシーCRMから12,000件のOpportunityレコードをSalesforceに移行しました。パイプラインレポートは誤っているように見えます。商談が属さない四半期に現れ、予測合計には数年前のOpportunityの金額が含まれます。RevOpsチームは、`CloseDate`フィールドに旧システムからのレガシー日付（一部は2015年から）と、移行ツールが注入したプレースホルダ日付（2099-12-31）が含まれていると疑っています。チームがパイプラインを信頼する前に、現実的な範囲外にある終了日が何件あるかを正確に知る必要があります。

### 設定

Opportunityオブジェクトで**Advanced Data Freshness**モードを使い、`CloseDate`フィールドを対象とします。「現実的な」終了日を定義しその境界外のすべてを捕捉するために、Operational Range Rateが必要です。

| 設定 | 値 | 理由 |
|---------|-------|-----|
| 分析モード | Advanced Data Freshness | 異常検出のためにOperational Range RateとFuture Rateを有効化 |
| Freshness Window | 180日 | 過去6か月以内の終了日はパイプラインの目的では「最新」 |
| Null As Stale | OFF | `CloseDate`はOpportunityの必須フィールド。nullは稀でこの分析の焦点ではない。 |
| Operational Range | ON | この分析の中核。現実的な日付を定義する。 |
| Operational Range Min | 過去365日 | 今日から1年以上前の終了日はレガシーの残滓 |
| Operational Range Max | 未来180日 | 6か月以上先の終了日はプレースホルダまたは非現実的に遠い予測 |

Operational Range入力は今日からの「過去の日数」と「未来の日数」を使います。DQSはスキャン時にこれらを絶対日付に変換します。2026年3月1日にこのスキャンを実行すると、範囲は2025年3月1日から2026年8月28日になります。2025年3月1日より前、または2026年8月28日より後の終了日は範囲外としてフラグされます。

### サンプル結果

**基礎指標：**

| 指標 | 値 |
|--------|-------|
| 鮮度率 | 52% |
| 古さ率 | 38.5% |

**高度指標：**

| 指標 | 値 |
|--------|-------|
| Average Age | 285日 |
| Future Rate | 9.5% |
| Overdue Rate | 計算されない（Overdue Tracking OFF） |
| Operational Range Rate | 71% |

評価された総Opportunityレコード：12,000件。

### 結果の読み方

**Operational Range Rate（71%）が看板数値です。**終了日の71%が現実的な範囲（過去1年から未来6か月）内にあります。つまり29%、3,480件のレコードがこの境界外の終了日を持っています。これらがパイプラインを歪めているレコードです。

範囲外にあるものを分解しましょう。

**Future Rate（9.5%）が未来の終了日を持つ1,140件のレコードをフラグします。**一部は正常です。今後6か月以内の終了日を持つオープンOpportunityは想定内であり、業務範囲内に収まります。ここでFuture Rateがフラグするレコードは、すべて今日より後の終了日です。業務範囲と照合してください。未来日付で*かつ*180日未来境界の外にあるレコードが問題のあるものです。これらは2099-12-31のようなプレースホルダ日付や、移行からの非現実的に遠い終了日です。

**範囲外の内訳は次のようになります：**

| カテゴリ | 推定レコード数 | 意味 |
|----------|-------------------|---------------|
| レガシー日付（365日より古い） | 約2,340 | 旧CRMから移行。クレンジングされなかった商談の2015〜2024年の終了日。 |
| 遠い未来のプレースホルダ | 約1,140 | ソースシステムに終了日がなかった箇所に移行ツールが注入した2099-12-31のような日付。 |
| **範囲外合計** | **約3,480** | **クレンジング範囲** |

**Average Age（285日）がレガシーデータによる引きずりを確認します。**すべての終了日にわたる平均経過期間は285日で、180日の鮮度期間の大きく外です。この高い平均は、数字を引き上げる大量の古い移行日付を反映しています。レガシーレコードをクレンジングした後、この数字は大幅に下がることが予想されます。

**鮮度率（52%）がパイプライン健全性のベースラインを与えます。**終了日の約半分だけが過去6か月以内です。3,480件の範囲外レコードを削除した後、再計算します。クリーンな8,520件のレコードのデータセットははるかに高い鮮度率を持ち、パイプラインレポートはついに現在の商談を反映するようになります。

### 次に行うこと

3,480件の範囲外レコードをエクスポートします。2つのクレンジングトラックに分けます。

- **レガシー日付（2,340件）：**ステージ別にレビューします。古い終了日を持つClosed-WonとClosed-Lostのopportunityは履歴レコードです。そのままにしつつ、アクティブパイプラインビューから除外します。2015〜2024年の終了日を持つオープンopportunityは、旧システムで一度もクローズされなかった死んだ商談です。ステージをClosed-Lostに更新します。
- **プレースホルダ日付（1,140件）：**2099-12-31などのプレースホルダを、opportunityのステージと作成日に基づいて現実的な終了日に置き換えます。明確なクローズタイムラインのない商談については、終了日を当四半期末に設定し、営業レビュー用にフラグします。

クレンジング後、再スキャンします。目標はアクティブパイプラインでOperational Range Rate 95%以上、鮮度率75%以上です。

---

## 設定の選択

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

| 必要なこと | 開始モード | 主要設定 |
|--------------------|------------|--------------|
| 簡易衛生監査のための日付鮮度チェック | Data Freshness | Freshness Windowを設定、nullが欠損データを表す場合はNull As Stale ON |
| Leadまたは連絡先エンゲージメントの最近性測定 | Data Freshness | Freshness Window：30日、Null As Stale ON、鮮度率を看板として使用 |
| 期限と更新遵守の追跡 | Advanced Data Freshness | Overdue Tracking ON、ビジネスプロセスのバッファに合わせてGrace Periodを設定 |
| 移行後のレガシーまたはプレースホルダ日付の検出 | Advanced Data Freshness | Operational Range ON、現実的な日付境界を定義するMin/Maxを設定 |
| 重要フィールドの完全な日付品質の姿を得る | Advanced Data Freshness | すべての設定を構成：Freshness Window＋Null As Stale＋Overdue Tracking＋Operational Range |
| 率を超えた古さの深刻度を理解する | Advanced Data Freshness | 適切な対応努力を計画するため、鮮度率と並行してAverage Ageをレビュー |

6つの適時性指標と診断フローにどう収まるかの完全なリファレンスについては、メインの[適時性](/ja/resources/data-quality/timeliness/)記事に戻ってください。

自社のデータ品質を測定する準備ができましたか？[AI対応度診断](/ja/ai-readiness/)を受けて適時性スコアなどを確認しましょう。