Salesforce 結合レポート: 複数ブロックにまたがるデータ分析のための包括的ガイド

Salesforce コンサルタントとして、クライアントが直面する最も一般的な課題の一つは、サイロ化されたデータを統合し、包括的なインサイトを導き出すことです。営業、サービス、マーケティングなど、異なる部門のデータが別々のオブジェクトに格納されている場合、それらを一つのビューで横断的に分析することは容易ではありません。本日は、この課題を解決する強力なネイティブツール、Joined Reports (結合レポート) について、その概念からベストプラクティスまでを詳しく解説します。

背景と適用シナリオ

標準の Salesforce レポートは、単一の Report Type (レポートタイプ) に基づいて作成されます。これは、例えば「商談」レポートや「ケース」レポートなど、特定のオブジェクトとその関連オブジェクトのデータを分析するのには非常に効果的です。しかし、ビジネス上の意思決定には、異なるプロセスやオブジェクトにまたがるデータの比較が必要になる場面が数多く存在します。

ここで Joined Reports が登場します。Joined Reports は、最大5つの異なるレポートブロックを一つのレポート画面に表示できる機能です。各ブロックはそれぞれ独自の Report Type、項目、条件を持つことができます。

具体的な適用シナリオ：

360度顧客ビュー: ある特定のアカウントに対して、現在進行中の商談 (Opportunities)、過去のサポートケース (Cases)、そして最近のマーケティング活動へのエンゲージメント (Campaigns) を一覧で表示したい場合。
パイプライン分析: 同じ営業担当者グループが担当する、「今四半期に作成された商談」、「今四半期にクローズした商談」、そして「今四半期に失注した商談」を並べて比較し、パイプラインの健全性を評価したい場合。
営業とサービスの効果測定: 特定の製品ラインについて、その製品を含む成立した商談の総額と、同じ製品に関連するオープンケースの件数を比較し、製品の収益性とサポート負荷を同時に把握したい場合。

これらのシナリオでは、関連性のない、あるいは間接的にしか関連していないオブジェクトのデータを同じビューで分析する必要があります。Joined Reports は、このような複雑な問いに答えるための、標準機能で完結するエレガントなソリューションを提供します。

原理说明

Joined Reports の中核となる概念は「Block (ブロック)」と「Common Field (共通項目)」です。

Block (ブロック)

各 Joined Report は、複数のブロックで構成されます。それぞれのブロックは、実質的に独立した標準レポートと考えることができます。各ブロックは以下の要素を持ちます：

Report Type (レポートタイプ): ブロックごとに異なるレポートタイプを選択できます。例えば、ブロック1は「商談」、ブロック2は「ケース」、ブロック3は「リード」といった構成が可能です。
項目 (Fields): 各ブロックに表示する列（項目）を個別に選択できます。
検索条件 (Filters): 各ブロックに適用する検索条件を個別に設定できます。「私の商談」や「今月のクローズ予定」など、ブロックごとに異なるデータセットを抽出できます。

Common Field (共通項目)

複数のブロックにまたがってデータをグループ化するためには、共通の項目が必要です。Salesforce は、レポートに追加されたブロック間で共通して存在する項目を自動的に識別します。例えば、「取引先名」や「所有者」といった項目は、多くのオブジェクトに共通して存在するため、グループ化のキーとして利用できます。

レポート実行時、データはこれらの共通項目によって行レベルでグルーピングされます。これにより、例えば「株式会社ABC」という取引先に対して、ブロック1（商談）のデータ、ブロック2（ケース）のデータが同じ行グループにまとめて表示され、横断的な分析が可能になります。

重要な点として、ブロック間のリレーションは必須ではありません。共通項目でグループ化しない場合でも、各ブロックのデータを並べて表示することができます。これにより、全く関連性のない指標（例：地域別のリード数と製品別のケース数）を一つの画面で概観することも可能です。

示例代码

Joined Reports は主に宣言的なUI操作で作成されるため、Apex や LWC のようなコードで直接的に構築するものではありません。しかし、Analytics REST API を使用することで、作成済みの Joined Report のメタデータや実行結果をプログラムで取得し、外部システム連携やカスタムUIでの表示に活用することができます。

以下は、Analytics REST API を使用して Joined Report のメタデータを取得した際のレスポンス JSON の一例です。この構造を理解することで、Joined Report が内部的にどのように構成されているかを把握できます。

この例は、Salesforce Developer ドキュメントに記載されている、結合レポートのメタデータを説明するものです。

Joined Report Metadata via Analytics REST API:

{
  "attributes": {
    "type": "Report",
    "url": "/services/data/v58.0/analytics/reports/00Oxx00000A0aBcDEJ"
  },
  "reportMetadata": {
    "id": "00Oxx00000A0aBcDEJ",
    "name": "Opportunities, Cases, and Accounts Report",
    "developerName": "Opportunities_Cases_and_Accounts_Report",
    "reportFormat": "JOINED",
    // ... other metadata
  },
  "reportExtendedMetadata": {
    "aggregateMetadata": {
      // ... aggregate info
    },
    "joinMetadata": {
      "leftBlock": {
        "blockId": "B0",
        "reportType": { "label": "Opportunities", "type": "Opportunity" }
      },
      "rightBlock": {
        "leftBlock": {
          "blockId": "B1",
          "reportType": { "label": "Cases", "type": "Case" }
        },
        "rightBlock": {
          "blockId": "B2",
          "reportType": { "label": "Accounts", "type": "Account" }
        },
        "joinType": "INNER"
      },
      "joinType": "INNER"
    }
  },
  "factMap": {
    // ... data will be here
  }
}

コードの解説：

reportFormat: "JOINED": このレポートが Joined Report であることを示します。
joinMetadata: Joined Report の構造を定義する最も重要な部分です。ネストされた構造で各ブロックとその関係性を示しています。
leftBlock / rightBlock: Joined Report が内部的に二分木のような構造でブロックを連結していることを示唆しています。
blockId: 各ブロックには "B0", "B1", "B2" のような一意のIDが割り当てられます。
reportType: 各ブロックがどのレポートタイプに基づいているかを示しています。（例: "Opportunity", "Case"）

この API レスポンスを解析することで、カスタムの分析ツールやデータ連携バッチで Joined Report の構造とデータを動的に扱うことが可能になります。

注意事項

Joined Reports は非常に強力ですが、いくつかの制約と注意点を理解しておくことが重要です。

ブロック数の上限: 1つのレポートに含めることができるブロックは最大5つまでです。
グラフの制限: Joined Report に追加できるグラフは1つだけであり、そのグラフは最初のブロック（プライマリブロック）のデータにのみ基づいて作成されます。複数のブロックのデータを統合したグラフを作成することはできません。
エクスポート形式: 「印刷用に表示」でエクスポートする場合、表示されている通りのレイアウトで出力されます。しかし、「詳細のみ」でエクスポートする場合、各ブロックのデータが個別のシートやセクションに分かれて出力されるため、Excel などでの後処理が必要になる場合があります。
登録 (Subscription): Joined Report をスケジュールしてメールで受信することは可能ですが、一部の古いUIではサポートされていない場合があります。Lightning Experience では通常通りサポートされています。
ダッシュボードコンポーネント: Joined Report をダッシュボードコンポーネントのソースとして使用できますが、グラフと同様に、コンポーネントに表示されるデータは最初のブロックに基づきます。
数式項目: クロスブロックの集計数式（`BLOCK0.FIELD:SUM + BLOCK1.FIELD:SUM` のような形式）はサポートされていますが、行レベルの数式はブロック内でのみ完結します。
権限: レポートを閲覧・編集するためには、レポートが保存されているフォルダへのアクセス権限に加え、レポートに含まれるすべてのオブジェクトと項目に対する適切な参照・編集権限が必要です。

まとめとベストプラクティス

Joined Reports は、異なるビジネスプロセスにまたがるデータを統合し、単一のビューで分析するための Salesforce の強力な標準機能です。コンサルタントとして、クライアントの複雑なレポーティング要件に応えるための重要なツールの一つと位置づけています。

ベストプラクティス：

ビジネスの問いから始める: テクノロジーありきではなく、「どの指標とどの指標を比較したいのか？」という明確なビジネス上の問いを最初に定義します。これにより、必要なブロックと項目を効率的に選択できます。
シンプルに保つ: 最大5つのブロックが可能ですが、不必要に多くのブロックを追加するとレポートが複雑になり、パフォーマンスが低下する可能性があります。本当に必要なデータのみに絞り込みましょう。

明確な命名規則:

共通項目を意識する: データを横並びで比較したい場合は、どの共通項目でグループ化するかが鍵となります。「取引先名」や「所有者名」など、分析の軸となる項目を意識してレポートを設計します。
限界を理解する: グラフやダッシュボードの制約を事前に理解し、クライアントに説明しておくことが重要です。もし複数のグラフが必要な場合は、Joined Report ではなく、複数のコンポーネントを配置したダッシュボードの方が適切なソリューションとなる場合があります。

Joined Reports を使いこなすことで、これまで見えなかったデータ間の相関関係やインサイトを発見し、よりデータドリブンな意思決定を支援することができます。ぜひ、次の分析要件で活用を検討してみてください。

にゃんこのSalesforce日記

このブログを検索