Salesforceバケット項目の検証｜数値境界・未分類・条件変更で分類漏れを防ぐ方法

Salesforceのレポートで金額や件数を区間に分けると、営業会議や予実管理で数字の分布を読みやすくできます。一方で、境界にある値、空欄、未割当の選択リスト値やテキスト値を確認しないまま運用すると、集計値は表示されても分類の意味を説明できなくなります。条件を変えた後に、元のレコードが変わっていないのに結果の内訳だけが変わることもあります。

検証の単位はレポートの行数ではなく、元レコードIDです。対象項目の値、期待するバケット、実際に表示されたバケットを同じIDで記録し、レポートタイプ、フィルター、対象期間、実行ユーザー、可視性を固定して比較します。分類を変える前後で件数や合計だけが一致していても、別のレコードが入れ替わっていれば分類は同じとはいえません。

Salesforceのバケット項目は、境界の直前・境界値・境界の直後を用意して、同じレコードIDの分類先を変更前後で照合します。数値バケットでは空欄・nullを0として扱う設定と、そうしない場合のダッシュ（-）表示を確認します。選択リストやテキストでは、未割当値を通常の列として扱う場合と、残りをOtherへまとめる場合を分けて記録します。公式Helpは数値バケットの最初の境界をその数値以下、続く境界を直前の数値より大きく次の数値以下、最後の境界より大きい値を最後のバケットに入れると説明しています。バケット変更後に、そのバケット列を参照するフィルターが外れていないかも確認します。

この点検は、レコードの元項目を更新する作業ではありません。バケットはレポート内で生成される分類列なので、まずレポート定義と結果の対応を保存し、必要なテストは承認済みの検証環境または内容を把握した既存レコードで実施します。

---

本記事のポイント

1. 数値バケットは境界の直前・一致・直後をレコードID単位で照合し、境界値がどこへ入るかを期待値として固定します。
2. 数値バケットの空欄・null、選択リストやテキストの未分類値、残りをまとめたOtherを別の状態として扱い、表示記号と分類先を同じ表に残します。
3. バケットの変更前後は同じフィルター・期間・実行条件で比較し、フィルターの消失や元レコードの変更を設定差分とデータ差分に分けます。

---

バケット項目の仕様を検証条件へ置き換える

Salesforce公式Helpの「Add a Bucket Column」では、バケットに使えるデータ型として数値、選択リスト、テキストの3種類が示されています。バケット項目は元の項目値を別のラベルへまとめるレポート上の列であり、同じ分類列を別のレポートでそのまま使うものではありません。公式説明でも、バケット列は生成したレポートでのみ利用できるとされています。

このHelpの対象はSalesforce ClassicとLightning Experienceで、利用可能なEditionはEnterprise、Performance、Unlimited、Developerです。また、フォルダ共有方式としてEnhanced Folder Sharingを前提としています。編集にはレポート作成・カスタマイズやReport Builderなど、操作対象に応じた権限も必要です。対象Editionやフォルダ共有の前提が異なる環境では、同じ表示や設定項目になるかを先に確認してください。

数値を区間に分ける場合は、境界の扱いを推測せず、公式の規則を期待値へ書きます。たとえば境界を100と200にした場合、最初の数値に対して100以下、次の範囲に100より大きく200以下、最後の範囲に200より大きい数値を割り当てる、という関係です。実際のレポートで入力する境界値や項目名は組織の設計に合わせますが、検証表には「境界の比較演算」を省略せず残します。

公式の数値バケット規則をテスト観点にした例

境界の設定例	テスト値	期待する判定	確認する理由
100、200	99	最初の境界以下	境界の直前が最初の区間へ入るか
100、200	100	最初の数値以下	一致値が最初の区間に含まれるか
100、200	101	直前の数値より大きく次の数値以下の区間	境界をまたいだ直後の値を確認する
100、200	199	中間区間	中間区間の内側を確認する
100、200	200	次の数値以下の区間	次の境界の一致値を確認する
100、200	201	最後の数値より大きい区間	最後の区間へ送られるかを確認する

この表の数値とラベルは検証方法を示す例です。Salesforce組織で実際に作成したバケットの結果を示す実測値ではありません。整数として扱う項目では、境界100に対して99・100・101のように整数刻みで確認します。金額など最小単位が0.01の項目では、境界100.00に対して99.99・100.00・100.01を用意するなど、実際の精度に合わせて境界の直前・一致・直後を作ります。テストでは、各値を持つレコードIDを先に決め、元の数値、期待ラベル、実際のラベルを同じ行へ記録します。レコードが関連明細ごとに複数行へ展開される場合は、分類元項目を持つレコードのIDを使います。明細ごとに元値が違うときは親IDだけで重複を除かず、明細IDまたは親IDと明細IDの組で照合します。集計はレポートの粒度に合わせて別に確認します。

公式Helpには、1レポートあたりのバケットフィールドは5個まで、1バケットフィールドあたりのバケットは20個まで、個別の値を割り当てるバケットでは1バケットあたり20値までという制限も記載されています。制限に近い設計では、分類を増やす前にテスト表の行数、未分類の候補、利用者が読むラベルを確認します。上限に到達したことと、分類ロジックが正しいことは別の判定として扱います。

対象期間の変化を分類条件の変化と取り違えないため、Salesforce相対日付フィルターの境界検証と同様に、期間の基準と実行時点を記録します。

空欄・未分類・Otherを別々に確かめる

分類漏れの原因になりやすいのが、元項目が空欄またはnullである状態と、値は入っているがどのバケットにも割り当てていない状態の混同です。さらに、残りの値をまとめる「Other」を有効にした場合は、未分類の値が表示上ひとつのラベルへ集約されます。これらは、同じ「その他」と呼ばれていても、点検表では別の列で記録します。

分類されない値を切り分ける検証表

元項目の状態	設定した確認	確認する表示・分類	記録すること
数値バケットの空欄またはnull	「空欄を0として扱う」を有効にする	0を含むバケットへ移るか	元値が空欄であること、対象バケット、レコードID
数値バケットの空欄またはnull	「空欄を0として扱う」を無効にする	未分類値がダッシュ（-）として表示されるか	表示記号と、未分類のままかどうか
選択リストやテキストの未割当値	「残りの値をOtherへまとめる」を無効にする	通常のレポート列の値として現れるか	元値、未割当の理由、表示された値
選択リストやテキストの未割当値	「残りの値をOtherへまとめる」を有効にする	Otherへ集約されるか	Otherへ入った元値の一覧と件数

空欄を0として扱う設定は、空欄を本当に0として登録し直すこととは違います。レコードの元項目を空欄から0へ書き換えたわけではなく、レポート上の分類時の扱いを変えています。したがって、元データの値を確認できる一覧と、バケット列の表示を同時に保存してください。空欄が0の区間に入ったからといって、元項目の入力漏れが解消されたとは判定しません。

選択リストやテキストでは、設定した値以外が通常のレポート列として残る場合があります。公式Helpは、残りの値をOtherというバケットへ移す選択肢も示しています。Otherを使う場合も、Otherというひとつの集計だけで完了にせず、内部にどの元値が含まれているかをサンプルまたは全件のIDで追跡します。Otherは原因ではなく、複数の元値をまとめた表示上の分類です。

次のような判定欄を検証表へ持つと、「未分類がない」と「Otherがない」を混同しにくくなります。

• rawValue：元レコードの項目値。空欄・nullは文字列の「0」へ変換せず、空欄として記録する。
• expectedBucket：境界と設定から決めた期待分類。空欄を0として扱うか、Otherを有効にしたかを含める。
• actualBucket：同じレコードIDをレポートで確認した実際の分類ラベルまたは表示記号。
• classificationState：通常のバケット、空欄の0扱い、ダッシュ、Other、未割当などの状態。

元レコードを変えずに境界テストを進める7手順

テストの目的は、レポートがどの値をどの分類先へ表示するかを確かめることです。営業データや顧客データを直接書き換えて期待値を作ると、分類の問題とデータ変更の問題を区別できません。次の手順では、作成したテスト値を使う場合も、元レコードを変更せずに再現できるよう承認範囲と証跡を先に決めます。

1. 対象レポートと範囲を固定する。レポート名だけでなく、レポートタイプ、元項目、バケット列のラベル、利用するバケットの境界を記録します。対象期間、標準フィルター、項目フィルター、所有者や担当範囲などのスコープも同じ検証票へ書きます。
2. 実行条件を固定する。実行日時、実行ユーザー、レコードの可視性、共有条件、タイムゾーンや期間の解釈を残します。同じ設定でも誰の視点で実行したかによって表示対象が変わり得るため、管理者で見た結果を一般利用者の結果として流用しません。
3. テスト値と元レコードIDを用意する。境界の直前・一致・直後、区間の内側、空欄またはnull、値はあるが割り当てないケースを揃えます。検証環境で専用データを用意するか、内容を確認した既存レコードを選び、ID・元値・取得時刻を記録します。本番の元レコードをテストのためだけに書き換えません。
4. 変更前の分類を保存する。同じレコードIDについて、元値、期待バケット、実際のバケット、件数、合計、未分類の表示を保存します。集計値だけでなくIDの集合を残し、表示行数と一意のID数を分けて数え、合計は元のレポート粒度に合わせます。
5. バケットの条件を変更する。検証対象の境界や割り当てを変更した場合は、変更者、時刻、変更前後の値、承認番号を残します。変更はレポート定義に対して行い、元項目の値やレコードの状態を変更しないことを確認します。
6. バケット列を参照するフィルターを確認する。公式Helpは、バケットの値を変更すると、そのバケット列を参照するフィルターが削除されると説明しています。条件を変えた後は、フィルターの有無・項目・演算子・値を変更前と比較し、必要なら承認を得て再設定します。フィルターが消えたままの結果を分類変更の結果として扱いません。
7. 同じ条件で再実行し差分を判定する。対象期間、標準・項目フィルター、実行ユーザー、可視性、元レコードIDの集合を揃えて、変更後の分類を保存します。ID追加・削除、分類先変更、件数・合計の変化を分け、元レコードの作成・更新・削除があった場合は設定変更とは別の差分にします。

7手順のうち、3番目と4番目を省くと、値の境界を確認したつもりでも「どのレコードを見たのか」が残りません。5番目と6番目を省くと、分類条件を直したことでフィルターが消えた結果を、正常な再分類と誤認します。変更前後で同じ対象を確保できないときは、件数を比較する前に検証を保留し、差分の理由を記録してください。

関連レコードの有無によって対象が絞られている場合は、Salesforceクロス条件の検証で対象のID集合も確認します。分類先の点検と、レポートに含まれる対象の点検を分けることが大切です。

変更前後の分類をレコードID・集計・設定で照合する

検証ログは、次の三つの層に分けると原因を切り分けやすくなります。第一は同じ元レコードIDの分類先、第二はその集合に対する件数・合計、第三はレポートの設定です。第一が変わっていないのに第二だけ変わった場合は、表示粒度や集計設定を疑います。第一も第二も変わった場合は、境界や空欄の扱い、元データ、可視性を順番に確認します。

変更前後の差分ログに残す項目

層	変更前	変更後	判定
対象範囲	レポートタイプ、標準フィルター、項目フィルター、期間	同じ設定か、変更理由が記録されているか	母集団の一致・不一致
実行条件	実行ユーザー、可視性、実行日時、時刻条件	同じ条件か、反映待ちを含むか	比較可能・比較不可
元レコード	レコードID、元項目値、取得時刻	同じIDの値か、追加・削除・更新があるか	データ差分・設定差分
分類	期待バケット、実際のバケット、空欄・未分類状態	同じIDの分類先、Otherやダッシュの状態	分類変更・分類漏れ
集計	件数、合計、表示行数、重複排除後のID数	同じ指標を再計算	集計だけの変化か
レポート定義	バケット境界、割当値、空欄・Otherの設定、参照フィルター	変更内容と、削除されたフィルターの有無	設定変更の影響

検証の完了条件は、件数が合うことではなく、固定した同じレコードIDについて期待分類と実分類が説明できることです。件数と合計が同じでも、100以下のレコードと101以上のレコードが入れ替わる可能性があります。境界値のID、空欄のID、Otherに含まれた元値のIDをサンプルとして保存し、再実行時にも同じIDを追います。

前回の結果と違うときは、まず設定の差分を確認し、その次に元レコードの差分を調べます。条件を変更していないのに分類が変わった場合は、元項目の更新、レコードの可視性、対象期間、実行ユーザー、レポートタイプの差を疑います。反対に、元レコードが同じなのに分類だけ変わった場合は、バケット境界、空欄を0として扱う設定、Otherへの集約、参照フィルターの消失を確認します。

バケットの変更を営業運用へ戻す前に確認すること

バケットは分析者が読みやすいラベルを作るための機能ですが、会議資料やアラートの条件に使われると、分類ラベルの変更が運用の対象範囲へ影響します。特に、変更前のバケット列を参照するフィルターが存在していた場合、公式ヘルプが説明する通り、バケット値の変更に伴ってそのフィルターが削除されることがあります。

設定を変更した人が「フィルターも戻した」と思っていても、同じ項目・演算子・値が復元されたとは限りません。変更前のレポート定義、変更後の定義、フィルターの差分、再実行結果を同じ記録へ保存し、会議用の出力や連携先が参照しているレポートを確認します。バケット列は生成したレポート内でのみ使えるため、別レポートの分類が自動的に追随するとも考えません。

作業後に営業担当が読むラベルを変えるときは、ラベルの意味を説明する短い定義も残します。たとえば「100以下」「100超200以下」のように境界を明記し、Otherの中身を追跡できる保管先と確認者を決めます。名称を「小口」「中口」とだけ書くと、将来境界を変更したときに過去の集計と比較できなくなります。

レポートの公開範囲を点検する際は、Salesforceレポートのフォルダ・アクセス権点検も参照してください。フォルダの閲覧権限と元レコードの可視性は分けて扱います。営業会議でレポートを利用する場合も、表示された数字を意思決定へ結び付ける確認項目を分けておきます。会議の判断を変えるのはバケットの見た目だけではなく、元レコードの対象、集計期間、担当範囲、変更後のフィルターだからです。

よくある質問

境界値は、どちらのバケットに入るか推測してよいですか？

推測せず、公式に示された規則を期待値へ書き、境界の直前・一致・直後を同じレコードIDで確認します。数値バケットでは、最初の数値はその数値以下、続く数値は直前の数値より大きく次の数値以下、最後の数値より大きい値は最後の区間です。実際のレポートでは、設定した境界と表示結果を保存してください。

空欄とOtherは同じ「分類なし」ですか？

同じではありません。Salesforce公式Helpの「空欄を0として扱う」「ダッシュ（-）」は数値バケットの設定です。選択リストやテキストの未割当値は通常のレポート列として残り、「残りの値をOtherへまとめる」を有効にしたときだけOtherへ集約されます。元値と状態を別々に記録します。

Otherへまとめた値は、元レコードの項目も変わりますか？

変わりません。Otherは選択リストやテキストの未割当値をレポート上でまとめる表示です。バケットはレポート内で生成される分類列であり、元レコードの項目値やレコードIDを変更する作業ではありません。元値の一覧とOtherの実分類をID単位で照合してください。

バケットの境界を変更した後、元のレコードをもう一度保存する必要がありますか？

バケット条件の検証だけなら、元の項目値を変更して保存する必要はありません。変更前後のレポート定義と、同じ元レコードIDの分類結果を比較します。テスト値が必要な場合は、承認済みの検証環境または既存レコードを使い、本番の元データをテストのために書き換えない方法を選びます。

バケットを変更したらレポートのフィルターも確認する必要がありますか？

必要です。Salesforce公式Helpは、バケット値を変更すると、そのバケット列を参照するフィルターが削除されると説明しています。変更前のフィルターを保存し、変更後に項目・演算子・値が残っているかを確認します。フィルターが外れた状態の件数を、分類条件だけの影響と判断しないでください。

件数と合計が変更前後で一致すれば合格ですか？

それだけでは不十分です。異なるレコードが入れ替わっても、件数や合計が同じになる場合があります。元レコードID、元項目値、期待バケット、実際のバケットを照合した後、件数・合計・表示行数を比較します。ID追加・削除、分類変更、設定差分、元データ変更を分けて記録してください。

作成したバケットを別のレポートでも使えますか？

公式Helpでは、バケット列は生成したレポートでのみ利用できると説明されています。別のレポートで同じ分類を使いたい場合も、同じ定義が作られていると仮定せず、対象項目、境界、空欄とOtherの扱いを別途確認します。複数レポートで同じ分類を維持するなら、定義の版と検証IDを管理すると差分を追いやすくなります。

Salesforceのレポート分類を営業管理へ定着させるには、境界の意味、未分類の内訳、変更後に残るフィルター、元レコードの範囲を一つの検証記録へつなぎます。CRM・Salesforceのレポート設計、対象データ、変更後の確認方法を整理したい場合は、ファネルAiへ現在の運用と困っている差分をご相談ください。

CRM・Salesforceのレポート設計を相談する