Salesforce相対日付フィルターの検証｜月末・年度境界で集計対象を確かめる方法

月次の商談レポートを開いたら、昨日まで入っていた案件が消えている。担当者が同じ名前のレポートを実行したのに、件数が合わない。こうした差は、データの入力漏れだけでなく、相対日付フィルターの範囲、対象項目、実行条件の違いから生じます。「先月」「過去30日」「今会計年度」は、同じ期間を指す言葉ではありません。

Salesforceの相対日付フィルターは、条件を固定し、期間の境界に置いたテストデータを照合し、差分を記録する手順で検証します。件数だけで合否を決めず、含まれるべきレコードIDと除外されるべきIDを確認してください。月末・年度境界では、実行日が変わることと設定が変わることを分けて調べます。

---

本記事のポイント

1. 相対日付の検証では、対象項目・フィルターの種類・実行者・実行日時を揃え、期間の開始と終了を具体的な日付へ書き下す。
2. 「NEXT n DAYS」は標準日付フィルターとカスタム項目フィルターで当日の扱いが異なるため、同じ文字列でも同じ結果とは限らない。
3. 境界の前・一致・後に置いたレコードをID単位で照合し、件数・合計・変更前後の条件を保存すれば、月末や年度替わりの差を説明しやすい。

---

1. 検証前に、期間を決める条件を固定する

相対日付は、保存した時点の絶対日付に固定される条件ではありません。Salesforceの公式「Relative Date Filter Reference」では、THIS MONTHは現在の月の初日から末日、LAST MONTHは前月の初日から末日として定義されています。実行日が翌月へ移れば、同じ設定でも対象の月が変わります。2026年9月18日時点の公式資料に基づき、まずこの変化を正常な動作として切り分けます。

先に「何の数字を作るレポートか」を一文で決めます。たとえば「前月に作成した商談」なら作成日、「前月を完了予定日とする商談」なら完了予定日が対象です。完了予定日だけでは受注済みとは限らないため、受注額を集計したい場合は商談ステージなどの条件も別に必要です。CRM・SFA・MAの役割の違いを踏まえ、集計する業務上の出来事と項目を対応させてください。

固定するもの	記録する内容	省くと起こること
対象項目	表示名、API名、日付型か日時型か	作成日と完了予定日を比較してしまう
日付条件	標準日付フィルターか追加の項目フィルターか、演算子、入力値	同じ相対表現でも開始日がずれる
その他の絞り込み	表示範囲、所有者、ステージ、フィルターロジック	日付以外の除外を日付の不具合と誤認する
実行条件	実行日時、実行者、タイムゾーン、ロケール	日付の切り替わりや週の開始日の差を再現できない
会計期間	組織の会計年度設定、対象年度の開始日と終了日	暦年と会計年度を混同する

「設定を固定する」とは、検証のために本番組織の会計年度や利用者の設定を書き換えることではありません。現在の条件を控え、検証用レポートや利用可能なテスト環境で変える要素を一つに絞るという意味です。共有レポートを直接書き換える前に複製や変更管理を行い、元の条件へ戻せる状態を作ります。

日時項目では、保存されている瞬間と画面上の日付表示も分けます。SalesforceのSOQL公式資料は、日時値がUTCで保存され、オフセットを付けて別のタイムゾーンの値を指定できると説明しています。ただし、SOQLの日付リテラルとレポート画面の相対日付を同一の構文・同一の仕様として扱ってはいけません。CRM日時項目のタイムゾーン管理と併せて、日時データの保存・表示の問題とレポート条件の問題を分離します。

2. 相対日付を、開始日と終了日へ書き下す

検証票には「先月」とだけ書かず、今回の実行日に対する開始日と終了日を書きます。たとえば2026年4月1日にLAST MONTHを実行するなら、対象は2026年3月1日から3月31日です。日付型なら3月1日と3月31日を含み、2月28日と4月1日は含まない、という期待値を先に作れます。

条件の例	確認する範囲	特に見る境界
LAST MONTH	前月の初日から末日	月初、月末、翌月初日。28・29・30・31日の違い
LAST n DAYS	n日前の午前0時から現在の秒まで。当日を含む	開始日の直前、当日の対象値、実行時刻より後の値
THIS YEAR	暦年の1月1日から12月31日	前年末と翌年初日
THIS FISCAL YEAR	組織で定義した現在の会計年度の初日から末日	会計年度初日と前年度末。暦年との差
THIS WEEK	ロケールに応じた今週の開始日から7日間	日曜・月曜付近と実行者のロケール

特に注意したいのは「NEXT n DAYS」です。レポートの公式ヘルプでは、標準日付フィルターは実行当日からn日間、カスタム項目フィルターは翌日からn日間とされています。ここでいうカスタム項目フィルターは、標準日付フィルターとは別に追加する項目条件を指します。「カスタム項目を作った場合だけ起きる差」と解釈しないでください。公式例でも、どちらも同じClose Dateを対象に比較しています。

たとえば10月24日にNEXT 7 DAYSを使うなら、標準日付フィルターの期待範囲は10月24〜30日、カスタム項目フィルターでは10月25〜31日です。両方とも7日分ですが、24日と31日の扱いが逆になります。標準フィルターで使えるnは公式資料に7・30・60・90・120と示されています。自由入力できる値や選択肢は、実際に使う画面で確認してください。

「過去30日」を「前月」と読み替えるのも避けます。LAST n DAYSは当日を含んで現在の秒まで続く一方、LAST MONTHは完了した前月全体です。月次の確定報告なのか、直近の動きを追うローリング集計なのかを業務側で決めれば、どちらを使うべきか判断できます。締め済みの数字を再現したい場合は、固定期間での再実行や当時の結果保存も検討します。相対条件を保存するだけでは、将来も同じ期間を再現できません。

3. 境界の前・一致・後を、レコードIDで照合する

相対日付フィルターの検証は「条件を固定→境界データで照合→差分を記録」の3段階で行います。テストデータには、含まれることが明らかな期間中央のレコードだけでなく、開始と終了の境界にあるレコードを入れます。検証用の商談を作る場合は、通知・外部連携・営業集計へ混入しない環境と権限を選び、検証後の処理も決めておきます。

日付型の完了予定日を対象に、4月1日にLAST MONTHを検証する例を示します。レポートの他の条件には全件が適合し、実行者から全件を参照できるものとします。表のA〜Eは説明用の識別子であり、検証票には実際のレコードIDを記録してください。

識別子	完了予定日	期待する結果	確かめること
A	2026年2月28日	除外	開始日の前が入らない
B	2026年3月1日	対象	開始日そのものが入る
C	2026年3月15日	対象	期間中央の基準データが入る
D	2026年3月31日	対象	終了日そのものが入る
E	2026年4月1日	除外	次の期間が混ざらない

この例の合格条件は「3件になった」だけではなく、「B・C・Dだけが含まれる」です。Aが混ざりBが抜けても件数は3件のままなので、件数だけの検証では誤りを見逃します。金額の合計も同様です。まずID集合を比較し、その後に件数と合計を照合します。レポート形式や関連レコードによって複数行になる場合は、明細行数と商談の一意なID数も分けて数えます。

日時型では、期待する境界の1秒前、境界の時刻、1秒後などを追加します。たとえば日本時間の4月1日午前0時はUTCでは3月31日15時です。画面が日本時間で表示される前提なら、この同じ瞬間の前後を準備し、対象レポートがどの値を含むかを確認します。日付型のデータへ無理にUTC変換を加えず、日時型の保存値、表示値、実行条件を検証票の別欄に置いてください。

テストでは未来や過去の実行日を任意に指定できると決めつけないことも大切です。今日のLAST MONTHは今日を基準に評価されます。4月1日の例を別の日に試すなら、実際の当日から求めた前月へテスト値を置き換えます。固定日付のフィルターで期待値を作ることはできますが、それだけで将来の相対日付の動作を検証したことにはなりません。重要な月替わりは、事前の境界テストに加えて当日の再確認を予定します。

4. 月末・会計年度・実行者の差を分けて記録する

月末の検証は、30日ある月だけで終わらせず、2月や31日ある月を含めて設計します。うるう年の2月29日も業務上の対象になり得ます。日付計算を外部ツールで補助する場合は、そのツールが作った期待値とSalesforceの定義を別々に確認してください。同じ誤った式を期待値と集計の両方へ使うと、両者が一致しても正しさを証明できません。

会計年度では、組織の会計年度設定を基準に境界日を書きます。4月開始と定義している場合の例なら、2026年4月1日のTHIS FISCAL YEARに対し、2026年3月31日は前年度、2026年4月1日から2027年3月31日は当年度です。これは4月開始という前提を置いた例で、すべてのSalesforce組織に適用される日程ではありません。カスタム会計年度などを使う組織は、定義済みの期間を確認して期待値を作ります。

週次レポートはロケールも確認対象です。公式ヘルプは、Enterpriseなどのエディションでは個人情報のロケール、Contact Manager・Group・Personalでは会社プロファイルのロケールで週が決まると説明しています。米国英語では日曜〜土曜、英国英語では月曜〜日曜という例が示されています。「週次だから必ず月曜始まり」と判断せず、利用環境に対応する設定を確認します。

実行者を変えて件数が違うときは、すぐ日付条件を修正しないでください。レポートの共有範囲と、レコード・項目を参照できる権限は別の問題です。Salesforceレポートフォルダの共有設定を確認し、同じIDが両者に見えるかを先に比較します。日付条件以外を固定した検証が通った後で、利用者別の確認へ進むと原因が混ざりにくくなります。

変更記録には、レポートID、変更前後の対象項目と条件、検証日時、実行者の設定、期待したID、実際のID、件数、合計、差が出た理由を残します。検証用データの識別子と実データの識別子は分け、エクスポートする場合も必要最小限の項目に絞ります。結果が期待値と違えば、設定の変更を止め、元の条件と比較して原因を説明できるまで対象を広げません。

月次会議などで使う重要なレポートは、作成者以外の確認者を置きます。「件数が前月に近いから合格」ではなく、境界のIDが期待どおりで、その他のフィルターや閲覧権限も説明できることを合格条件にしてください。購読メールやダッシュボード経由で見る場合は、直接実行したレポートとは別に、表示されている更新日時と実行条件も確認します。

よくある質問

LAST MONTHとLAST 30 DAYSは同じですか？

同じではありません。LAST MONTHは前月の初日から末日です。LAST 30 DAYSは30日前の午前0時から現在の秒までで、当日も含みます。月次の確定報告と直近推移の確認では、目的に合わせて使い分けます。

NEXT n DAYSで同じ項目なのに対象がずれるのはなぜですか？

レポートの標準日付フィルターでは当日から、カスタム項目フィルターでは翌日からn日間を対象にするためです。対象項目の名前だけでなく、どこへ条件を設定したかも確認してください。

当日以外の日付で、相対条件を検証できますか？

相対条件は実行日を基準に評価されます。固定期間で期待値を作る方法と、実際の相対条件を実行する確認は分けます。当日から求めた境界にテスト値を置き、重要な月替わりや年度替わりにはその時点で再確認します。

会計年度は1月から12月として確認すればよいですか？

THIS YEARは暦年ですが、THIS FISCAL YEARは組織で定義した会計年度に従います。会計年度の設定画面にある開始日・終了日を使って期待値を作り、年度末の前後を確認します。

件数と合計金額が一致すれば検証完了ですか？

それだけでは不十分です。含まれるレコードが入れ替わっても、件数や合計が偶然一致する場合があります。対象となるレコードIDを先に照合し、その後で件数と合計を比較します。

SOQLの日付リテラルをレポートへそのまま入力できますか？

同じものとして扱わないでください。レポートの相対日付表現とSOQLの日付リテラルは、参照する仕様と構文を分けて確認します。外部抽出結果を比較する場合も、対象期間・項目・実行条件を揃えたうえで照合します。

参考情報

• Salesforce Help：Relative Date Filter Reference
• Salesforce Developers：Date Formats and Date Literals in WHERE