適時性

適時性とは

適時性は、日付の値が用途に対して十分に新しいかどうかを測定します。日付フィールドは、許容される鮮度の範囲内にあるときに適時です。その範囲を超えると古くなり、データが現在の現実を反映していないことになります。

CRMのすべての日付フィールドには時間に基づく期待があります。18か月前のLastActivityDateは死んだLeadを示します。2099年に設定されたContract_End_Date__cは実際の期限ではなくプレースホルダです。未来のDate_of_Birth__cはデータ入力エラーです。適時性分析はこれらすべてを捕捉します。

古くなるのは、ほとんどのチームが予想するより早く蓄積されます。B2Bコンタクトデータは、月あたり約2.1%、年あたり約22.5%の割合で劣化します。これは、人々が職を変え、企業が合併し、連絡先が有効期限切れになるためです。ZoomInfoが編集した業界研究によると。インポート時にクリーンなデータセットは、単独でも古くなっていく傾向があります。これが、適時性が一度きりのクリーンアップではなく継続的な測定を必要とする理由です。

鮮度率 =（鮮度期間内の日付を持つレコード / 全レコード）× 100

1,000件のレコードのうち659件が過去90日以内のLast_Certification_Date__cを持っていれば、鮮度率は65.9%です。残りの34.1%は古い、null、または未来の日付です。この1つの数字で、データセット全体でフィールドがどれほど最新かがわかります。

適時性が重要な理由

レポート

古い日付は分析を歪めます。Open OpportunityのうちOpportunity CloseDate値の30%が過去のものであれば、パイプラインレポートは放置された、忘れられた、またはすでに失注しているのに更新されていない商談を表示します。これらの日付に基づく予測は経営層をミスリードします。

自動化

Salesforceの自動化は日付の値に依存します。Contract_End_Date__cの30日前にトリガーする更新ワークフローは、日付が5年前だと失敗します。Due_Date__cで起動するSLAエスカレーションは、解決後に日付が更新されていないと誤通報を生みます。

AIとAgentforce

AIモデルは日付の値を現在の真実として扱います。Agentforceは日付を使ってアクションの優先順位付け、フォローアップの予定、緊急性の評価を行います。日付が古いと、モデルは2年前に退職した人に連絡することを推奨したり、数か月前に更新された契約をフラグしたり、本当に注意が必要なものを見逃したりします。

DQSによる適時性の測定方法

DQSは次の診断的な問いを軸として6つの適時性指標を算出します。「データは最新か、どれほど古いか、意味をなさない日付はないか」

これらの指標は診断フローのようなものです。各ステップは前のステップの上に積み上がります。

ステップ1：データは最新か

鮮度率は看板となる指標です。日付フィールドの値が設定した鮮度期間（たとえば過去90日）内にあるレコードの割合を計算します。ダッシュボードに掲載する数字がこれです。

OpportunityのLastActivityDateフィールドを30日の鮮度期間でスキャンします。鮮度率は41%と返ります。つまりOpen Opportunityの59%が過去1か月間活動していないということです。パイプラインレビュー、予測精度、営業コーチングのすべてが古いシグナルで動作していることになります。

古さ率は問題の側面を定量化します。日付フィールドがnullまたは鮮度期間より古いレコードの割合を測定します。未来の日付のレコードは、異なるタイプの問題（Future Rateが捕捉）なので古さからは除外されます。

**例：**AccountのContract_End_Date__cは365日の期間で古さ率28%を示します。契約のほぼ3分の1が1年以上前の終了日を示しています。これらは期限切れなのにアクティブのまま残っている契約か、更新されたのに更新されていない契約かのどちらかです。いずれにせよ、更新パイプラインは不正確です。

3方向の分解

すべてのレコードは3つのカテゴリのいずれかに該当します。率の合計は常に100%になります。

この分解により各カテゴリに明確な意味が与えられます。「何%が古いか」と尋ねるステークホルダーは、「古いか欠落か」を意味する数字を得ます。「古い、欠落、または不可能な未来日付」の合計ではありません。

ステップ2：どれほど古いか

鮮度率は二値的です。レコードは新鮮か古いかのどちらかです。Average Ageはニュアンスを加えます。

Average Ageは、各過去日付のレコードの値と今日との間の日数の合計を全レコード数で割った平均を計算します。nullと未来の日付は合計には0を寄与しますが、分母にはカウントされます。

2つのフィールドが両方とも60%の鮮度を示していても、一方はAverage Age 15日（ほとんど最近、少数の外れ値）で、もう一方は90日（古さが均等に広がっている）であることがあります。対応戦略は異なります。Average Ageが低いフィールドは、少数の古いレコードに対象を絞ったクレンジングが必要です。Average Ageが高いフィールドは、より広範なリフレッシュの取り組みが必要です。

**例：**LeadのLast_Contacted_Date__cは鮮度55%（30日期間）、Average Age 45日です。古さは深刻ではなく、ほとんどの古いレコードは期間の少し外にあります。短いアウトリーチキャンペーンで鮮度率を大幅に動かせます。

ステップ3：異常はないか

2つの指標が本来あるべきでない日付を捕捉します。

Future Rateは、日付の値が未来にあるレコードの割合を測定します。Created Date、Last Modified Date、Date_of_Birth__cといった過去の日付フィールドにとって、未来の日付はほぼ常にエラーです。タイムゾーンの問題、データ入力ミス、または2099-12-31のようなプレースホルダ値です。

**例：**ContactのDate_of_Birth__cはFuture Rate 0.8%を示します。50,000件のうち400件のレコードに未来の生年月日があります。これらは年齢ベースのセグメンテーション、コンプライアンスチェック、年齢グループでフィルタするマーケティングキャンペーンを破綻させます。

Operational Range Rateは、日付の値が定義された業務上の境界（設定する最小日付と最大日付）内にあるレコードの割合を測定します。この範囲外の日付は異常としてフラグされます。

一部の日付フィールドには自然な境界があります。1950年より前のHire_Date__cは誤りです。2099年に設定されたProject_Deadline__cはプレースホルダです。Operational Range Rateは、フィールドが入力されているため基本的な鮮度チェックを通過するが、非現実的な値を持つこうした外れ値を捕捉します。

**例：**OpportunityのClose_Date__cに対して過去365日から未来0日の業務範囲を設定します。Operational Range Rateは84%です。調査すると、2005年のクローズ日付を持つ200件のレコード（レガシーシステムから移行）と、2099年のクローズ日付を持つ50件のレコード（インテグレーションからのプレースホルダ）が見つかります。両方のグループがパイプライン分析を歪めています。

**注：**業務範囲の最大値が0（今日）に設定されている場合、すべての未来の日付も範囲外となります。Future RateとOperational Range Rateは未来日付のレコードで重なります。加算的ではなく補完的なビューです。

ステップ4：期限は守られているか

Overdue Rateは、日付フィールドが今日より過去にあるレコードの割合を、オプションの猶予期間付きで測定します。「期限超過」がビジネス上の意味を持つ期限タイプのフィールドのために用途別に設計されています。

Overdue Rateは古さ率と2つの点で異なります。1つ目は、設定可能な猶予期間のバッファ（たとえば14日）を追加し、期限の翌日にレコードが期限超過としてフラグされるのを防ぎます。2つ目は、更新日、認証日、契約終了日など、過去の日付がアクション必要を意味するフィールドを対象とします。

**例：**30日の猶予期間付きで契約のRenewal_Date__cを見ると、Overdue Rateは12%です。つまり契約の12%が更新またはクローズされずに更新日から30日以上経過しているということです。これらは収益漏れのリスクです。

「最終イベント」対「期限」フィールド

すべての適時性指標がすべてのフィールドに適合するわけではありません。Overdue Rateは「最終イベント」フィールドではほとんどのイベントが定義上過去にあるため、循環論法的に高い値を示します。フィールドのタイプに基づいて看板指標を選びましょう。

すべての指標が総レコード数を使う理由

6つの適時性指標はすべて同じ分母を使います。nullを含めた総レコード数です。これにより、同じスキャン内のすべての指標を比較可能に保てます。1つの指標がnullを除外し、別の指標がnullを含めると、「鮮度66%対未来1.6%」を比較するステークホルダーは、知らずに2つの異なる母集団を比較することになります。

Null As Staleが有効な場合、nullレコードは鮮度にマイナスに寄与します（分母には含まれますが、鮮度の分子には含まれません）。無効な場合、nullは分子と分母の両方から除外され、鮮度は入力済みレコードに対してのみ計算されます。

指標リファレンス

基礎指標

次の2つの指標は、適時性分析の基盤を成します。中核的な問いに答えます。「このデータは最新か」

高度指標

次の4つの指標は「最新か」を超えて、年齢分布、日付の異常、期限遵守を分析します。Advanced Data Freshness分析モードが必要です。

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

DQSはDateおよびDateTimeフィールドでのみ適時性を測定します。適時性は本質的に時間的なものです。完全性（20以上のフィールドタイプで機能する）と異なり、適時性は時点を表すフィールドにのみ適用されます。

2つの分析モード

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

Data Freshnessは「データは最新か古いか」という問いに答えます。2つの基礎指標を生成し、日付に敏感なプロセスを持つあらゆる組織に必要な要素をカバーします。簡易衛生チェックやベースライン監査にこのモードを使います。

Advanced Data Freshnessはさらに深く掘り下げます。平均経過期間、未来日付の異常、期限超過追跡、業務範囲遵守を含む6指標すべてを生成します。鮮度スコアだけでなく、日付品質の全体像を理解する必要がある場合にこのモードを使います。

適時性の設定

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

**ヒント：**異なる日付フィールドには異なる鮮度期待があります。Open OpportunityのLastActivityDateは30日期間が必要です。AccountのContract_End_Date__cは365日が必要です。フィールドレベルのオーバーライドを使って各フィールドに適切な期間を設定しましょう。

鮮度期間の選択

鮮度期間は適時性にとって最も重要な設定決定です。フィールドタイプ別の出発点は次の通りです。

業務範囲の設定

業務範囲は絶対日付ではなく「過去の日数」と「未来の日数」を使います。DQSはスキャン時に今日の日付を使ってこれらを絶対日付に変換します。

**例：**過去365日と未来0日を設定します。2026年2月22日に、DQSはこれを2025年2月22日から2026年2月22日の範囲に変換します。2025年2月22日より前の日付や今日より後の日付はすべて範囲外です。

つまり範囲は毎日前進します。今日範囲内にあるレコードが、期間が移動するにつれて明日範囲外になる可能性があります。

よくある適時性の問題

Open Opportunityの古い活動日付

営業担当者がOpportunityの更新をやめ、「Open」フェーズのままにします。LastActivityDateは静かに古くなります。パイプラインレポートはアクティブな商談を表示しますが、日付は数か月間誰も触れていないことを明らかにします。

**対処法：**Open OpportunityのLastActivityDateに30日の鮮度期間を設定します。古さ率を使って、フォローアップやフェーズ修正が必要な商談の規模を把握します。

プレースホルダの未来日付

インテグレーションや一括インポートでは、値が必要なフィールドに対して2099-12-31のようなプレースホルダ日付がよく使われます。これらのプレースホルダは入力済みのデータに見えますが、時間ベースの分析を歪めます。

**対処法：**Future Rateを使って今日より後の日付を持つレコードを特定します。Operational Range Rateを使って、遠い未来のプレースホルダと古いレガシー日付の両方を1つの指標で捕捉します。

更新されない期限切れ契約

契約は更新されますが、Contract_End_Date__cは新しい期限に更新されません。システムは期限切れ契約とアクティブ契約を並べて表示し、日付を確認しないと区別する方法がありません。

**対処法：**更新サイクルに合わせた猶予期間（たとえば30日）でOverdue Trackingを有効にします。Overdue Rateは、期限を過ぎて更新されていない契約の正確な数を示します。

古さを隠すnull日付

Null As Staleが無効（デフォルト）の場合、null日付は評価から完全に除外されます。レコードの20%がnull日付を持つ場合、鮮度率は残りの80%に対してのみ計算されます。これにより、数字が実際よりも健全に見えることがあります。

**対処法：**null日付が注意を必要とする欠損データを表す場合、Null As Staleを有効にしましょう。これには活動が一度も発生していないレコードや、移行中に入力されなかったフィールドが含まれます。

ベストプラクティス

適切な看板指標を選ぶ

鮮度率は「最終イベント」フィールド（最後の更新はいつか）にとって適切な看板指標です。Overdue Rateは期限フィールド（期限を過ぎているか）にとって適切な看板指標です。LastActivityDateにOverdue Rateを表示すると、ほとんどの活動が本質的に過去にあるため、誤解を招く高い数字が生成されます。

フィールド固有の期間を設定する

すべての日付フィールドに単一の鮮度期間を使うのは本質を外しています。活動日付にはタイトな期間（30日）が必要です。契約日付にはより広い期間（365日）が必要です。認証日付は業界の更新サイクルに依存します。各フィールドのビジネスコンテキストに合わせるためにフィールドレベルのオーバーライドを使いましょう。

対応計画にAverage Ageを使う

鮮度率は問題の大きさを示します。Average Ageは深刻度を示します。40%の古さとAverage Age 45日のフィールドには、短いアウトリーチキャンペーンが必要です。40%の古さとAverage Age 400日のフィールドには、データエンリッチメントプロジェクトが必要です。同じ割合、異なる対処法です。

スキャンをまたいでトレンドを追跡する

単一のスキャンは現状を示します。定期的にスキャンを実行し、鮮度の劣化を検出し、クレンジング施策の影響を測定し、古いレコードを生み出すデータソースを特定しましょう。スキャンの間に80%から60%へ鮮度が下がるフィールドには、新しい問題源があります。

適時性と完全性を組み合わせる

日付フィールドは完全性95%でも鮮度50%であることがあります。完全性はフィールドに値があることを示します。適時性はその値が最新かどうかを示します。全体像を得るには、日付フィールドに対して両方の次元を実行しましょう。

次のステップ

日付の鮮度問題を測定し診断する方法を理解しました。次の次元について学び続けましょう。

• 次へ：一貫性 - 均一なデータ標準化を確保する
• 前へ：一意性 - 重複を検出し防ぐ
• 関連：5つの次元 - すべての次元の概要
• アクション：AI対応度診断 - 現在の適時性スコアを確認する