背景と応用シナリオ
Salesforce を活用している多くの企業にとって、レポートとダッシュボードは日々の業務状況を把握し、意思決定を行うための重要なツールです。しかし、標準の Salesforce レポートには一つの大きな制約があります。それは、「今、この瞬間」のデータを表示することに特化しているという点です。例えば、今日の商談パイプラインの合計金額や、現在オープンになっているケースの数を確認することは容易ですが、「先週の月曜日の時点でのパイプラインはどうだったか？」「先月末のオープンケース数はいくつだったか？」といった過去の特定時点の状況を振り返ることは、標準機能だけでは非常に困難です。
このような「点」ではなく「線」でデータの推移を追跡したいというニーズに応えるための強力な機能が Analytic Snapshots (分析スナップショット) です。Analytic Snapshots は、特定の時点でのレポート結果をカスタムオブジェクトのレコードとして保存する機能です。これにより、データの履歴を蓄積し、時間経過に伴う変化や傾向を分析することが可能になります。
応用シナリオの例
営業部門:
毎週月曜日の朝に、フェーズごとの商談の件数と合計金額をスナップショットとして保存します。これにより、「今四半期でパイプラインはどのように成長したか」「特定のフェーズで停滞している商談の傾向はどうか」といった、パイプラインの健全性を時系列で分析できます。
サービス部門:
毎日業務終了時に、ステータスが「新規」または「処理中」のケース数をスナップショットとして保存します。これにより、サポートチームの未対応案件（バックログ）がどのように増減しているかを可視化し、リソースの適切な配分や問題の早期発見に繋げることができます。
マーケティング部門:
毎月末に、リードソースごとのリード数を記録します。これにより、どのマーケティングキャンペーンが継続的にリード獲得に貢献しているかを月単位で比較・評価できます。
このように、Analytic Snapshots は、Salesforce 内のあらゆるオブジェクトのデータを定点観測し、ビジネスの動向をより深く、長期的な視点で理解するための基盤を Salesforce 管理者に提供します。
原理説明
Analytic Snapshots の仕組みは、3つの主要なコンポーネントの連携によって成り立っています。Salesforce 管理者は、これらのコンポーネントを宣言的（コード不要）に設定することで、データの履歴追跡を実現します。
1. Source Report (ソースレポート)
スナップショットのデータ元となるレポートです。これは、履歴として保存したいデータ列を含むレポートでなければなりません。重要な制約として、Source Report として使用できるレポート形式は「表形式 (Tabular)」または「サマリー形式 (Summary)」のみです。「マトリックス形式 (Matrix)」や「結合レポート (Joined Report)」はサポートされていません。レポートには、後で分析したい項目（例：商談の金額、フェーズ、完了予定日など）を列として含めておく必要があります。
2. Target Object (ターゲットオブジェクト)
Source Report の実行結果を保存するための「受け皿」となるカスタムオブジェクトです。このオブジェクトには、Source Report の各列に対応するカスタム項目を作成する必要があります。例えば、レポートに「商談名」「金額」「フェーズ」という3つの列がある場合、Target Object にはそれに対応するテキスト型、通貨型、選択リスト型の項目を作成します。データ型が一致していることが非常に重要です。通常、スナップショットが実行された日時を記録するために、「実行日」のような日付/時間型の項目も追加します。
3. Analytic Snapshot の定義
これが設定の中核部分です。Salesforce の [設定] メニューから「分析スナップショット」へ進み、新しいスナップショットを作成します。この定義画面では、以下の3つを関連付けます。
・実行ユーザー (Running User): スナップショットが実行される際のコンテキストとなるユーザーを定義します。このユーザーのアクセス権限（プロファイルや共有ルール）に基づいて Source Report が実行され、そのユーザーが見えるデータのみがスナップショットとして保存されます。そのため、必要なデータをすべて閲覧できる権限を持つ専用のインテグレーションユーザーなどを指定することが推奨されます。
・ソースレポートとターゲットオブジェクトの選択: 上記で準備した Source Report と Target Object を指定します。
・項目マッピング (Field Mapping): Source Report の列と Target Object の項目を一つずつ対応付けます。「レポートのこの列の値を、オブジェクトのこの項目に保存する」というマッピングを画面上で設定します。このマッピングが正しく行われていないと、データが期待通りに保存されません。
最後に、このスナップショットをどのくらいの頻度で（毎日、毎週、毎月）、何時に実行するかというスケジュールを設定します。スケジュールが保存されると、指定された日時にシステムが自動的にレポートを実行し、その結果をターゲットオブジェクトに新しいレコードとして追加していきます。
サンプルコード
Analytic Snapshots の設定自体はコードを必要としませんが、スナップショットによって Target Object に蓄積されたデータを利用する際には、SOQL (Salesforce Object Query Language) を使用してデータを抽出・分析することが一般的です。例えば、開発者コンソールや API を通じて、特定の期間のデータを取得する場合などが該当します。
以下は、「PipelineHistory__c」というターゲットオブジェクトに保存された商談パイプラインの履歴データから、特定の期間における合計予測金額の推移を取得するための SOQL クエリの例です。
// このクエリは、Analytic Snapshot によって作成された PipelineHistory__c オブジェクトからデータを取得します。
// PipelineHistory__c には、各スナップショット実行時点での商談データがレコードとして格納されています。
SELECT
// スナップショットが実行された日付。GROUP BY句で日付ごとに集計するために使用します。
SnapshotDate__c,
// 商談フェーズ。どのフェーズにどれくらいの金額があったかを見るために使用します。
StageName__c,
// 金額の合計を計算します。SUM()集計関数を使い、エイリアス(別名)として TotalAmount を指定しています。
SUM(Amount__c) TotalAmount
FROM
// データの取得元となるターゲットオブジェクト API名
PipelineHistory__c
WHERE
// 今四半期のデータのみを対象とするための絞り込み条件です。
// 日付リテラル 'THIS_QUARTER' を使用することで、動的に現在の四半期を判定します。
SnapshotDate__c = THIS_QUARTER
GROUP BY
// 日付ごと、さらにフェーズごとにデータをグループ化します。
// これにより、特定の日における各フェーズの合計金額を算出できます。
SnapshotDate__c, StageName__c
ORDER BY
// 結果を日付の昇順、次にフェーズ名で並び替えます。
// これにより、時系列でデータを追いやすくなります。
SnapshotDate__c ASC, StageName__c ASC
このクエリを実行することで、今四半期における各営業フェーズの金額が日を追ってどのように変化したかという貴重な洞察を得ることができます。この結果を元に、さらに Salesforce のレポートやダッシュボードを作成したり、外部の BI ツールで可視化したりすることが可能です。
注意事項
Analytic Snapshots は非常に便利な機能ですが、効果的に利用するためにはいくつかの注意点を理解しておく必要があります。
権限と可視性
前述の通り、スナップショットは指定された Running User (実行ユーザー) の権限で実行されます。このユーザーがアクセスできないレコードは、レポートに含まれず、スナップショットにも記録されません。全社的なデータを取得したい場合は、システム管理者プロファイルを持つユーザーや、「すべてのデータの参照」権限を持つインテグレーションユーザーを指定する必要があります。実行ユーザーが無効化されたり、権限が変更されたりするとスナップショットが失敗するため、ユーザーのライフサイクル管理には注意が必要です。
ガバナ制限
Salesforce Platform の他の機能と同様に、Analytic Snapshots にもいくつかの制限が存在します。
・レコード数の上限: Source Report が返すことができるレコードの上限は 2,000件 です。レポートの実行結果が 2,001件以上になる場合、スナップショットは失敗します。大量のデータを扱う場合は、レポートの検索条件を工夫して、一度に処理するレコード数を 2,000件以内に収める必要があります。
・項目数の上限: 1つの Analytic Snapshot でマッピングできる項目数は最大 100個 です。
・実行頻度: スケジュール実行は、最短でも1時間ごとです。より高頻度なデータ取得が必要な場合は、API を利用したカスタム実装などを検討する必要があります。
データストレージへの影響
スナップショットは、実行されるたびに Target Object に新しいレコードを追加します。例えば、1,000件のレコードを返すレポートを毎日実行すると、1年間で約365,000件のレコードが生成されます。これは Salesforce のデータストレージを消費するため、長期的に運用する場合はデータ量の増加を考慮しなければなりません。定期的に古いデータをアーカイブまたは削除するデータ管理戦略を立てることが重要です。
エラー処理と監視
スナップショットが失敗した場合（例：レコード数上限超過、実行ユーザーの権限不足、項目マッピングの不整合など）、スケジュールを設定したユーザーにエラー通知メールが送信されます。また、[設定] > [ジョブ] > [スケジュール済みジョブ] から実行履歴とステータスを確認できます。定期的にこれらのログを監視し、スナップショットが正常に動作していることを確認する運用が不可欠です。
まとめとベストプラクティス
Analytic Snapshots は、Salesforce 管理者がコードを書くことなく、重要なビジネス指標の時系列分析を可能にするための強力な宣言的ツールです。商談パイプラインの推移、ケースバックログの増減、リード獲得数の変化など、過去の特定時点のデータを記録・分析することで、より戦略的な意思決定を支援します。
この機能を最大限に活用するためのベストプラクティスを以下に示します。
1. 目的の明確化: スナップショットを設定する前に、「どのような問いに答えたいのか」「最終的にどのようなレポートやグラフを作りたいのか」を明確に定義します。これにより、必要な項目を含む適切な Source Report と Target Object を設計できます。
2. 専用の実行ユーザーの利用: 個人のユーザーアカウントを Running User に設定すると、そのユーザーが退職したり部署移動したりした場合にスナップショットが停止するリスクがあります。API 専用のプロファイルを持つ、パスワードが失効しないインテグレーションユーザーを作成し、それを実行ユーザーとして指定することを強く推奨します。
3. 一貫した命名規則: 複数のスナップショットを管理する場合、関連するコンポーネントの名称を統一すると管理が容易になります。例：
・ソースレポート: 「[Snapshot] Pipeline History Source」
・ターゲットオブジェクト: 「Pipeline_History__c」
・スナップショット定義: 「Weekly Pipeline History Snapshot」
4. テストの実施: スケジュールを設定する前に、必ず「今すぐ実行」オプションを使用して手動でスナップショットを実行し、データが意図した通りに Target Object に保存されるかを確認します。少量のデータでテストを行い、項目マッピングやデータ型に問題がないことを検証してください。
5. 定期的な監視とメンテナンス: スケジュール済みジョブの実行状況を定期的に確認し、エラーが発生していないかを監視します。また、ビジネス要件の変更に伴いレポートの列が変更された場合は、スナップショットの項目マッピングも忘れずに更新する必要があります。
これらのプラクティスに従うことで、Analytic Snapshots を安定して運用し、Salesforce に蓄積されたデータからより深いビジネスインサイトを引き出すことができるでしょう。
コメント
コメントを投稿