Salesforceレポートの行レベル数式検証｜型・空欄・集計結果を照合する方法
Salesforceのレポートに計算列を追加したのに、営業会議の数字と合わない。数式の検証は通ったのに、一部の行だけ空欄になる。こうしたときは、式を書き直す前に、参照項目の型、入力されていない値、集計対象の行を分けて確認します。
行レベル数式は、レポートの各レコードについて計算結果を得る仕組みです。構文エラーの解消を出発点に、期待値を決めた明細で計算を確認し、同じ対象範囲の集計と突き合わせることで、業務判断に使えるかを検証できます。構文チェックだけで完了にせず、型・空欄・集計の三段階で確認することが重要です。
CRMのデータは、項目の意味や入力時点が部署によって異なることがあります。
顧客情報と商談情報をどのように使い分けるかは、CRMの機能と選び方も確認してください。ここでは製品選定ではなく、既に作ったレポートの計算結果を検証する手順に絞ります。
本記事のポイント
- 行レベル数式は各レコードを計算する仕組みであり、構文検証の成功だけでは業務指標としての正しさは確認できません。
- 参照項目の型と意味、空欄と0の扱いを分け、期待値を先に決めた明細で計算結果を検証します。
- 保存・実行後の対象ID、平均の分母、丸めを揃えて集計を照合し、数式や項目変更の際に再現できる記録を残します。
最初に決めるのは数式ではなく、何を測るか
同じ「商談にかかった日数」でも、作成日から完了予定日までの日数、初回面談から実際の成約までの日数、現在までの滞留日数は別の指標です。列名だけを見て式を作ると、エラーのない計算で別の指標を測ることになります。対象レコード、開始項目、終了項目、単位、除外条件、集計の目的を先に一文で書きます。
例えば「完了した商談について、作成日の暦日から完了予定日までの差を日単位で確認する」と定義します。この定義なら、時刻単位の経過時間や営業時間だけを数える式とは区別できます。担当者が入力する完了予定日を使う場合、その値が実際の成約日を表しているとは限りません。SFA上の営業プロセスと、測りたい時点を合わせる必要があります。
| 先に決める項目 | 記録する内容 | 曖昧な場合に起きること |
|---|---|---|
| 対象 | 商談、完了状態、期間、担当範囲 | 未完了や失注を含めるかで値が変わる |
| 入力 | 開始・終了項目の意味と型 | 予定日を実績日と読み違える |
| 単位 | 日、時間、金額、割合 | 暦日の差を経過時間として報告する |
| 空欄・異常値 | 除外、確認待ち、別集計の扱い | 未入力をゼロとして平均を下げる |
| 集計 | 合計・平均の対象と分母 | 明細の平均と別範囲の総計を比較する |
日付に不自然な前後関係があった場合も、集計をきれいにするために元データを変更してはいけません。誤入力、項目の定義、移行データ、更新タイミングのどれが原因かを確認し、修正担当者と根拠を残します。レポートのテストは、データを都合のよい形に直す作業ではありません。
型を確認する：公式の日付差の例で数式を作る
Salesforceの公式Trailheadの行レベル数式演習では、商談レポートに次の数式を追加します。2026年10月2日時点で確認した演習は、完了予定日の範囲を「常時」、商談状況を「完了」に設定する例です。「完了」を自社の「受注のみ」と同じ意味で扱わず、必要な対象条件を別に確認してください。
CLOSE_DATE - DATEVALUE(CREATED_DATE)CLOSE_DATEは完了予定日、CREATED_DATEは作成日のAPI参照名です。公式演習では、前者は日付、後者は日時と説明されています。DATEVALUE()で日時を日付へ変換してから減算するため、出力種別は「数値」、小数点は「0」を指定します。この式は、時間や分まで含む経過時間そのものを測る式ではありません。
- 検証用のレポートを用意する。日常の意思決定に使うレポートを直接変更する前に、複製などで影響を分けます。対象期間、所有者、商談状況を記録します。
- アウトラインの「列」から行レベル数式を追加する。列名は単位と意味が分かるものにし、説明にも入力項目と対象を残します。
- 表示名を手で置き換えず、項目メニューから挿入する。公式演習は、数式には表示名ではなくAPI参照名を使い、項目を検索して挿入する方法を案内しています。似た名前のカスタム項目との取り違えも防ぎます。
- 入力の型と出力の型を別々に確認する。日付を入力する式でも、日数の差を返すなら出力は数値です。型を合わせる目的を説明できない変換は加えません。
- 「検証」で数式エラーを解消し、「適用」「保存 & 実行」へ進む。構文が通ったことと、期待する値が得られたことは、別の確認結果として記録します。
この操作例は、すべてのレポート種別や契約で同じ機能を利用できると保証するものではありません。追加メニューが見つからない場合は、対象レポートの種類、操作権限、現在の公式ヘルプを管理者と確認してください。ここで確認した公式演習だけから、利用上限や対応エディションの数値は断定できません。
作成日時が日付に変わる境界もテスト対象です。日付が変わる前後の記録について、元の日時、画面上の日付、計算に使われた日付を照合します。タイムゾーンや表示設定を含めて記録し、「画面で同じ日に見えるから同じ結果になる」と推測しないことが重要です。
空欄を検証する：正常な行だけで合格にしない
次の三段階は、公式演習の構文検証に加えて行う実務上の確認方法です。まず数値・日付・日時の型を確かめ、次に入力なしの行を試し、最後に明細と合計を突き合わせます。数式の構文チェックだけで検証を終えないための順序です。
最初に少数のレコードについて、元の値から手計算した期待値を用意します。同日、通常の期間差、月をまたぐ日付、終了が開始より前の行などを選びます。期待値はレポートの計算結果を見る前に決めます。結果を見てから期待値を書き換えると、誤った式でも合格にしてしまいます。
| テストする行 | 期待値の決め方 | 不一致時の確認 |
|---|---|---|
| 開始日と終了日が同日 | 日付差の指標なら0日 | 型変換と時刻の混入 |
| 2026年9月30日から10月2日 | 単純な暦日の差なら2日 | 営業日計算との混同 |
| 終了日が開始日より前 | 負の値になる理由を説明できること | 入力誤り、指標の定義、移行履歴 |
| 任意の参照項目が空欄 | 業務で決めた空欄の扱いと一致すること | 空欄をゼロと同一視していないか |
| 数値0が明示入力された行 | 入力済みの0として区別できること | 未入力との混同 |
| 日付変更の前後の日時 | 採用する日付の基準に一致すること | 時刻、タイムゾーン、表示設定 |
空欄の試験は、実際に空欄が許される参照項目で行います。必須の日付を無理に空にしたり、本番データを壊したりする必要はありません。例えば任意の数値項目を参照する計算では、未入力、明示的な0、正の値を分けます。式や設定による実際の結果を確認し、空欄が常に0になる、常に計算対象外になるとは決めつけません。
空欄を0に置き換えると、計算エラーを避けられても意味が変わる場合があります。「未入力の見積額」と「見積額0円」は同じ情報ではありません。置き換えが必要なら、業務責任者がその意味を承認し、未入力件数を別に確認できるようにします。補正前後の値を比較できないまま数式だけを修正することは避けます。
公式演習にも、サンプルデータの性質によって日数がマイナスになる場合があるという注意があります。これは演習用データの説明です。本番で負の値を見つけたときに、演習の手順にならって日付を変更する根拠にはなりません。期待値と実測値の不一致が解消するまで、その指標の利用範囲を制限する方が適切です。
計算の検証と対象行の選定は切り分けます。関連レコードの有無で対象を絞っている場合は、Salesforceクロス条件の検証で対象集合を先に確認してください。対象外の行が消えている問題を、数式の修正だけで解決することはできません。
集計を照合する：同じ明細・同じ条件で再計算する
個別の行が合っていても、集計結果が別の問いに答えていることがあります。日数の合計が必要なのか、商談ごとの平均が必要なのか、部署別の傾向が必要なのかを確認します。Salesforceの公式のレポート集計演習は、金額と期待収益をフェーズでグループ化し、合計と平均を表示する例を示しています。この例と、任意の行レベル数式列で利用できる集計操作は分けて確認してください。
実務での照合は、次の順序で行います。画面で利用できる集計機能と出力種別を確認し、必要なら権限のある明細出力を使って再計算します。顧客情報を含む出力はアクセスできる担当者を限定し、不要になった検証ファイルは組織の保存ルールに従って処理します。
- 条件と時点を固定する。レポート名、検索条件、実行日時、実行ユーザー、グループ化、出力の単位を記録します。相対日付を使っているなら、Salesforceの相対日付条件の境界テストも参考に対象期間を確かめます。
- プレビューだけで判断しない。公式の集計演習は、編集時のプレビューにサンプルレコードを表示することを説明しています。保存・実行したレポートの対象行と件数で照合します。
- 明細の単位を確認する。同じ商談が複数行に現れていないか、比較用の一覧と対象IDが一致するかを確認します。合計だけが偶然一致しても合格にしません。
- 採用した行から再計算する。合計、平均、空欄の件数、異常値の件数を分けます。平均では、分母となる件数と除外条件を必ず残します。
- 丸めの位置を合わせる。表示された小数桁と元の精度は別の確認項目です。丸めた明細を足す方法と、計算後の合計を丸める方法を混同しないようにします。
例えば、検証用の値が10、20、空欄の3行だった場合、入力済み2行だけの平均は15、空欄を0とした3行の平均は10です。どちらを採るかは指標の定義次第で、Salesforceがこの例で自動的にどちらかを採用すると述べているわけではありません。平均値に差が出たら、式より先に分母と空欄処理を照合します。
合格条件は「エラーが出ない」ではなく、「選んだテスト行の期待値が一致し、対象ID・分母・丸めを説明できる」ことにします。数式、参照項目、入力値、期待値、実測値、実行条件、確認者を一組で保存すれば、次回の項目変更やレポート修正でも同じ検証を再現できます。入力項目、対象条件、グループ化、出力種別を変更したときは、この組を使って再確認します。
数式の追加本数、利用できるレポート種別、関数の対応範囲などは、実際の組織と現行仕様で確認します。使えない機能を前提に運用を組まず、必要な指標が現在のレポートで表現できない場合は、管理者と計算場所やデータ設計を見直してください。
よくある質問
行レベル数式の検証が通れば、計算結果も正しいと判断できますか？
判断できません。構文エラーを確認した後に、項目の意味、型、空欄、対象レコードを確認します。少数の行で期待値を先に決め、保存・実行後の結果と照合してください。
日付の差を求めるのに、出力種別を数値にするのはなぜですか？
入力は日付でも、減算で得たい結果が日数という数値だからです。公式例のCLOSE_DATE - DATEVALUE(CREATED_DATE)は、作成日時を日付に変換して日付同士を減算します。時間や分を含む経過時間とは区別します。
空欄は0に置き換えてよいですか？
未入力と0が業務上同じ意味かを先に確認します。式や設定による実際の結果を試し、空欄を常に0として扱うとは決めつけません。置換が必要なら意味を承認し、未入力件数も把握できるようにします。
日数がマイナスになったら、絶対値に直してよいですか？
原因を調べずに直さないでください。日付の前後関係、入力誤り、移行履歴、指標の定義を確認します。絶対値にすると異常の存在が見えなくなり、別の意味の指標になるおそれがあります。
明細の平均とレポートの平均が合わないときは何を見ますか？
対象ID、実行時点、検索条件、空欄を含めるか、分母、丸めの位置を照合します。サンプルのプレビューと実行後の全対象を混同せず、同じ条件と明細単位で再計算します。
関連ページと関連記事
行レベル数式は、各行の値を計算するための方法です。値を範囲別に分類して比較したい場合は、Salesforceレポートのバケット境界検証で分類条件を確認してください。計算と分類を分けると、不一致の原因を見つけやすくなります。
営業データの入力項目や指標の定義を整理し、日々の顧客管理につなげたい場合は、ファネルAiの営業・顧客管理の概要をご確認ください。
