Data Cloud新機能: リアルタイム／計算済みインサイトの相対日時対応

TS-DCSP
2025/10/29に公開
 TL;DRSalesforce Data Cloudのリアルタイムインサイトと計算済みインサイトに「相対日時（Relative Time Windows）」指定が可能になりました。

これにより「過去24時間」「直近10分間」など いま を基準にした動的分析が可能になり、常に最新の指標を自動で維持できます。

運用負荷を減らしつつ、データ鮮度とリアルタイム施策の精度を両立する革新的アップデートです。
この機能は 2025年9月（Summer’25）の月次リリースで追加されたものです。
リリースノートの説明では以下のように記述されています。
“Calculated and Real-Time Insights now support relative time windows to define time-based metrics dynamically.”
つまり、計算済みインサイトやリアルタイムインサイトで「過去24時間」「直近10分間」など “いま” を基準とした動的な時間指定が可能になったということです。

日付を手動で更新したり、定期ジョブで条件を差し替える必要がなくなりました。

ジョブ実行やクエリのたびに、Data Cloudが自動的に「現在」を基準に評価し、常に最新のインサイトを維持します。

運用の手間を減らしながら、データ鮮度の自動維持とリアルタイム施策の精度向上を両立する革新的アップデートです。
それだけでも十分に大きな進化ですが、実際にどんな価値をもたらすのかを理解するために、少し掘り下げてみたいと思います。
この記事では、このアップデートの背景と仕組み、実際の使い方、そして運用上のポイントをわかりやすく解説します。

 背景: データ鮮度という課題これまでのData Cloudでは、インサイトを定義するときに「2025年9月1日〜9月30日」といった 絶対日付 を指定するしかありませんでした。

時間が経てば、その期間はすぐに古くなり、ジョブを動かして新しい期間にその絶対日付を置き換える必要がありました。
「過去24時間の売上」や「直近10分のクリック数」といった“いま基準”の集計を保つには、

スクリプトで日付を更新したり、毎朝ジョブを再実行したりといった運用的な工夫が必要でした。

この仕組みでは、リアルタイム施策や即時レコメンドなどのシナリオでは鮮度の維持がボトルネックになっていました。

 新機能の概要：検索条件と変換の両面で“相対日時”が使えるように今回のアップデートでは、 計算済みインサイトとリアルタイムインサイトの両方で、以下の2つの箇所で「相対日時」を利用できるようになりました。
検索条件
変換
これにより、固定期間指定の時代は終わり、「動的に動く時間窓」 での集計が可能になります。

 1. 検索条件（フィルタ）での利用これまでは、分析対象期間を「2025年9月1日〜10月2日」などの絶対日付で固定指定するしかありませんでした。期間をずらすたびに値を更新してジョブを再実行する必要がありましたが、今回のアップデートにより、現在を基準とした日時期間を動的に指定できるようになりました。
過去 N 日間
過去 N 時間
過去 N 分
過去 N 秒
翌 N 日間
翌 N 時間
翌 N 分
翌 N 秒
実際にビジュアルインサイトビルダーで設定していくイメージはこちらです。
まず検索条件を選びます。

条件の設定では基準となるDateTime型のデータ項目を選びます。例ではPurchase Order Dateを選択し、購入されたのが直近14日の範囲を設定していこうと思います。

相対日時を選びます。これが今回のアップデートで増えた項目です。

過去なのか翌なのか期間を選びます。今回は直近14日の購入データに絞りたいので 過去N日間を選択します。

Nの値も直近14日なので、14を設定します。

これで動的にNowを基準に14日間のデータを選べるようになってます。

 2. 変換での利用これまでの変換処理では、日付加算／減算などの演算はできましたが、「現在時刻を基準とした動的な時間変換」はサポートされていませんでした。

今回、変換関数に以下の3つが追加されました。
今すぐ Now()　・・・ 現在の時刻を返す
秒追加 second_add　・・・ 指定の秒数を加算する（時刻を未来へ)
秒減算 second_sub　・・・ 指定の秒数を減算する（時刻を過去へ)
実際にビジュアルインサイトビルダーで変換関数を使っていくイメージはこちらです。
変換を追加していきます。

ここでは例として、「購入日付を1時間後（3600秒後）」に変換する設定を作ってみます。

3600を入力します。

あとは変換名と変換API名を設定します。

 よくある質問相対日時（Relative Time Windows）を理解するうえで、よく質問を受けるポイントをここで整理しておきます。

 Q1. SQLでも利用できますか？はい。相対日時ウィンドウは、ビジュアルインサイトビルダーだけでなくSQLクエリでも使用可能です。

計算済みインサイトの背後ではすべてSQL変換されており、以下のような構文でも同様に動作します。
SELECT COUNT(*) AS recent_orders
FROM sales_order
WHERE order_date >= SECOND_SUB(NOW(), 14*24*3600)
このクエリは「現在時刻から14日前以降の注文」を動的に抽出する例です。

 Q2. 現在時刻(NOW)とはいつ？NOW() は、Data Cloudジョブやクエリの実行時点のシステム時刻を指します。

固定値ではなく、毎回の実行タイミングで再評価される動的な現在時刻です。

計算済みインサイトの場合は、バッチジョブの実行時刻が基準になります。

リアルタイムインサイトの場合は、ユーザーまたはアプリケーションによるクエリ実行時点が基準になります。
たとえば「過去24時間の売上」という条件を設定した場合、朝9時に実行すれば「前日9時〜今朝9時」、夜10時に実行すれば「前日10時〜今夜10時」と、常にその瞬間を起点に自動的に評価されます。

 Q3. タイムゾーンはどこ基準？NOW() が返す時刻は、Salesforce本体（CRM）の組織設定ではなく、Data Cloudの実行環境（Prod）側のシステム時刻を基準にしています。

このProd環境はHyperforce上で動いており、基本的に UTC（協定世界時） で運用されています。
つまり、日本の組織であっても NOW() はUTC時刻を返します。

日本時間の夜9時は、UTCではお昼の12時――この9時間の差は「UTC基準で動いている」ことによるものです。
ただし、ここで大事なのは「過去7日」「過去24時間」といった相対期間の指定は、UTCでもJSTでも結果が変わらないということです。「過去7日」とは“いまから7日前”という時間幅であり、どのタイムゾーンでも7日間の長さは同じだからです。そのため「過去7日間の日本の売上」などを集計しても、UTC基準のままで問題ありません。
注意が必要なのは、NOW() の値そのものを出力したり、SECOND_ADD() や SECOND_SUB() で時刻の演算を行うケースです。この場合はUTC基準になるため、日本時間と9時間のズレが生じます。

もし「日本時間（JST）」で扱いたい場合は、以下のように9時間（9 × 3600秒）を加算して補正します。
SELECT SECOND_ADD(NOW(), 9 * 3600) AS current_time_jst 
まとめると、「相対期間」はNOWがどの時刻を返すかを意識せず安心して使えます。

ただし“時刻そのもの”を扱うときだけ、UTCと日本時間のズレを意識しておけばOKです。それ以外は気にせず「過去◯日」指定を使って大丈夫です。
※本記事は、私が所属する会社とは一切関係のない事柄です。