背景と応用シーン
現代のビジネス環境において、企業は日々膨大な量のデータを生成し、蓄積しています。これらのデータを効果的に分析し、意思決定に役立てることは、競争優位性を確立するために不可欠です。SalesforceのようなCRM（Customer Relationship Management：顧客関係管理）システムは、顧客、商談、ケース、活動など、多種多様な情報を一元的に管理しますが、これらのデータは互いに複雑なリレーション（関連性）を持っています。
従来のSalesforceレポートでは、通常、単一のレポートタイプ（Report Type：レポートタイプ）に基づき、特定のオブジェクト（Object：オブジェクト）とその直接関連するオブジェクトのデータしか分析できませんでした。例えば、「商談（Opportunity）とその商品（Opportunity Product）」や「取引先（Account）とその関連取引先責任者（Contact）」といった分析は容易です。しかし、ビジネスの現場では、より複雑なデータ連携を必要とする要求が頻繁に発生します。
例えば、以下のようなビジネス課題に直面することがあります。
- 「特定の製品を購入した顧客の、過去のサポートケース履歴をすべて見たい」
- 「オープンな商談を持つすべてのリード（Lead）の、関連する活動（Activity）を、商談ステージ（Stage）とリードソース（Lead Source）の両方で分析したい」
- 「異なるマーケティングキャンペーン（Campaign）から発生した商談の成果を、単一のレポートで比較分析したい」
- 「過去に購入した顧客と、現在商談中の顧客の活動状況を並べて比較し、顧客ライフサイクルの全体像を把握したい」
これらの課題は、単一のリレーションパスやレポートタイプでは解決が困難です。ここでSalesforceのJoined Reports（結合レポート）が登場します。Joined Reportsは、複数のレポートタイプから取得したデータを単一のレポートに結合し、異なる視点からの分析を可能にする強力な機能です。これにより、データ間の隠れた関連性を発見し、より包括的なビジネスインサイト（Business Insight：ビジネス洞察）を得ることができます。
原理説明
Joined Reportsの核となる概念は、「ブロック（Block）」です。Joined Reportsでは、最大5つの異なるレポートタイプを選択し、それぞれを独立したブロックとしてレポートに追加します。各ブロックは、独自のフィールド（Field：項目）、フィルター、グループ化（Grouping）、集計（Summary）設定を持つことができ、あたかも個別のレポートであるかのように機能します。
Joined Reportsの主要な構成要素：
1. ブロック（Block）
Joined Reportsの各セクションはブロックと呼ばれ、それぞれが独自のレポートタイプに基づいています。例えば、1つのブロックで「商談」レポートタイプ、別のブロックで「ケース（Case）」レポートタイプを使用できます。これにより、異なるオブジェクトセットからデータを収集できます。各ブロックには、表示する項目、適用するフィルター、データのグループ化方法（行と列）、および集計方法を個別に定義できます。
2. 共通項目（Common Fields）
複数のブロックのデータを結合し、横断的に分析するために、共通項目（Common Fields）を使用します。これは、異なるブロック間で共有される項目であり、主にルックアップリレーション（Lookup Relationship）やマスター・ディテールリレーション（Master-Detail Relationship）によって関連付けられたオブジェクトのID項目（例：取引先ID、商談ID）が該当します。例えば、「取引先」ブロックと「商談」ブロックがある場合、「取引先ID」は共通項目となり、このIDに基づいて両ブロックのデータを並べて表示したり、クロスブロックフィルターを適用したりできます。
3. グループ化（Grouping）
Joined Reportsでは、レポート全体を横断する共通のグループ化を行うことができます。これは、各ブロック内で個別にグループ化するだけでなく、共通項目に基づいて複数のブロックにまたがるデータを集約するために非常に重要です。例えば、「取引先名」でグループ化することで、その取引先に関連するすべての商談、ケース、活動などの情報を一箇所に集約して表示できます。この共通のグループ化は、Joined Reportsの強力な分析能力を最大限に引き出す鍵となります。
4. フィルター（Filters）
Joined Reportsには、いくつかの種類のフィルターがあります。
- 標準フィルター（Standard Filters）: 各ブロックに個別に適用されるフィルターです。従来のレポートと同様に、レポートタイプが提供する標準的なフィルターオプション（例：日付範囲、所有者）を使用します。
- ブロックフィルター（Block Filters）: 各ブロックに特定の条件を適用するフィルターです。これにより、各ブロックが表示するデータを細かく制御できます。
- クロスブロックフィルター（Cross-Block Filters）: レポート全体に適用され、すべてのブロックに影響を与える共通のフィルターです。共通項目に基づいて、複数のブロックからデータをフィルタリングできます。例えば、「商談が成立した取引先」のみに絞り込む場合、商談ブロックで「完了（Closed Won）」の条件を設定し、その結果に連動して他のブロックのデータも絞り込まれるように設定できます。
5. カスタム集計項目（Custom Summary Formulas）
Joined Reportsでは、カスタム集計項目（Custom Summary Formulas）を定義して、レポートの数値データをさらに分析できます。これらの項目は、各ブロック内で個別に定義できるほか、複数のブロックにまたがるデータを参照して集計することも可能です。例えば、「完了した商談の合計金額」と「未完了の商談の合計金額」を比較するカスタム集計項目を作成し、その比率を算出するといったことが可能です。これにより、より高度なKPI（Key Performance Indicator：重要業績評価指標）の算出や、複雑なビジネスロジックに基づく分析が実現します。
Joined Reportsの作成は、Salesforceのレポートビルダー（Report Builder）というユーザーインターフェース（User Interface：ユーザーインターフェース）を通じて行われます。ドラッグ＆ドロップ操作でブロックを追加し、項目を選択し、フィルターを設定する直感的な手順で、複雑なレポートを構築できます。
示例コード
SalesforceのJoined Reportsは、主にSalesforceのレポートビルダーのUI（ユーザーインターフェース）を通じて構成および管理される機能です。そのため、Joined Reportsをプログラム的に直接作成、編集、または実行するための特定のApexコード（Apex Code）や、Joined Reportsに特化した専用のREST API（REST API）は、公式ドキュメント（developer.salesforce.com）には提供されていません。
Joined Reportsの定義自体は、SalesforceのMetadata API（メタデータAPI）を通じてXML形式で取得およびデプロイ（Deploy：配置）することが可能です。これにより、Joined Reportsの構造（ブロック、フィルター、グループ化、カスタム集計項目など）をコードとしてバージョン管理し、組織間で移行することができます。しかし、これはApexコードではなく、レポート定義のメタデータを表現するXMLファイルとなります。
また、作成されたJoined Reportは、標準のSalesforceレポートとして、Analytics API（Analytics API）バージョン2.0（またはReport API）を通じて実行結果を取得することは可能です。このAPIは、レポートIDを指定してレポートを実行し、そのデータをJSON形式などで返します。Joined Reportsも一般的なレポートと同様にこのAPIの対象となりますが、Joined Reportsに特有のAPIコールやパラメータが存在するわけではありません。
このセクションでは、Joined Reportsの機能がUIベースであるという性質を鑑み、直接的なApexコードの例は提供いたしません。代わりに、Metadata APIがJoined ReportのXML定義をどのように扱うか、一般的なReport API v2.0の利用例を以下に示します。これはJoined Reportに特化したコードではありませんが、作成済みのJoined Reportを実行する際の一般的なアプローチを示すものです。
// Metadata APIを利用してレポート定義を取得する場合のSOAP APIコール例（Apexではなく、外部ツールからの利用を想定）
// この例はXML定義であり、Apexコードではありません。
// 通常はDeveloper ConsoleやAnt Migration Tool、VS Code with Salesforce Extension Packなどを使用します。
// Ant Migration Toolの場合のpackage.xmlの例:
// <?xml version="1.0" encoding="UTF-8"?>
// <Package xmlns="http://soap.sforce.com/2006/04/metadata">
// <types>
// <members>MyReports/MyJoinedReportName</members> <!-- MyJoinedReportNameはレポートの一意の名前またはフォルダパス/レポート名 -->
// <name>Report</name>
// </types>
// <version>58.0</version> <!-- APIバージョンはSalesforceのバージョンに合わせる -->
// </Package>
// Report API v2.0を利用してレポートを実行する一般的なHTTPリクエストの例 (Apexではない)
// 外部システムやLightning Web ComponentsからFetch APIなどを使って呼び出す場合のイメージ
/*
Method: GET
URL: /services/data/vXX.0/analytics/reports/reportId
Headers:
Authorization: Bearer YOUR_ACCESS_TOKEN
Accept: application/json
例:
GET /services/data/v58.0/analytics/reports/00Oxxxxxxxxxxxxxxx
*/
// 結果のJSON構造例:
/*
{
"reportMetadata": { ... }, // レポートのメタデータ（レポートタイプ、フィルター、グループ化など）
"reportExtendedMetadata": { ... }, // 項目定義など
"factMap": {
"T!T": { // 全体の集計結果
"aggregates": [
{ "label": "合計金額", "value": 123456.78 }
]
},
"0!0": { // ブロック1の集計結果
"aggregates": [
{ "label": "ブロック1の集計", "value": 50000.00 }
]
},
"1!0": { // ブロック2の集計結果
"aggregates": [
{ "label": "ブロック2の集計", "value": 73456.78 }
]
},
"T!0": { ... } // 全体の行データ
},
"groupingsDown": { ... }, // 行グループ化データ
"groupingsAcross": { ... }, // 列グループ化データ
"rows": [ ... ] // 詳細行データ
}
*/
// 上記のJSON構造には、Joined Reportのブロックごとの集計やデータが反映されます。
// '0!0', '1!0'などのキーは、ブロックインデックスとグループインデックスを示します。
上記の例は、Joined Reportを含むSalesforceレポートを外部から操作する場合のアプローチを示しています。直接的なApexコードによるJoined Reportsの動的な作成や変更はサポートされていないため、UIまたはMetadata APIによる定義管理が主要な手段となります。
注意事項
Joined Reportsは強力な機能ですが、その利用にはいくつかの注意点があります。これらを理解しておくことで、最適なレポート設計とパフォーマンス（Performance：性能）の維持に役立ちます。
1. パフォーマンスへの影響
複数のレポートタイプを結合し、複雑なフィルターや集計を適用すると、レポートの実行に時間がかかることがあります。特に大量のデータを持つ組織の場合、Joined Reportsは従来のレポートよりもパフォーマンスに影響を与えやすい傾向があります。レポートの設計時には、不要な項目を含めない、フィルターを適切に設定してデータ量を減らす、複雑なカスタム集計項目を避けるなどの工夫が必要です。
2. レポートタイプ選択の重要性
各ブロックで使用するレポートタイプの選択は非常に重要です。レポートタイプは、どのオブジェクトのデータにアクセスできるか、どのようなリレーションパスを辿れるかを決定します。Joined Reportsを作成する際は、必要なデータがすべてのブロックで利用可能であることを確認し、適切なレポートタイプを選択してください。異なるレポートタイプ間の共通項目も、データの結合に不可欠です。
3. 共通項目の制約
異なるブロックのデータを効率的に結合するには、共通項目が不可欠です。Joined Reportsのグループ化やクロスブロックフィルターは、共通項目に依存します。共通項目として利用できるのは、通常、オブジェクト間のリレーションを定義するID項目（例：取引先ID、所有者ID）や、ユニークな識別子となる項目です。レポート設計時には、目的の分析に必要な共通項目が存在し、それらが適切にマッピングされていることを確認する必要があります。
4. 行数制限と集計制限
Salesforceのレポートには、表示される行数や集計できる項目の数に制限があります。
- 表示行数: 通常、レポートの詳細行は2,000行までしか表示されません。Joined Reportsもこの制限の対象となります。より多くの行をエクスポートする場合は、レポートのエクスポート機能を使用する必要がありますが、UI上でのプレビューや表示には制限があります。
- 集計項目の数: Joined Reportsでは、各ブロックおよびレポート全体で最大50個のカスタム集計項目を作成できます。この制限を超える複雑な計算が必要な場合は、他の分析ツールやデータウェアハウスの利用を検討する必要があります。
- ブロック数: 最大5つのブロックまで追加可能です。
5. セキュリティと共有設定
Joined Reportsのデータ表示は、閲覧ユーザーの権限（Permission：権限）と共有設定（Sharing Settings：共有設定）に基づきます。ユーザーがアクセス権限を持たないレコードや項目は、レポートに表示されません。これにより、データのセキュリティが維持されますが、レポート作成者は、レポートの意図する対象ユーザーが適切なデータにアクセスできるかを確認する必要があります。
6. ダッシュボードでの利用制限
Joined Reportsは、Salesforceのダッシュボード（Dashboard：ダッシュボード）のソースレポート（Source Report：ソースレポート）として直接使用することはできません。ダッシュボードは、単一のレポートタイプに基づいたサマリーレポート（Summary Report）またはマトリックスレポート（Matrix Report）を必要とします。Joined Reportsのデータをダッシュボードに表示したい場合は、そのJoined Reportの集計結果を別途サマリーレポートとして作成し、そのサマリーレポートをダッシュボードのソースとして利用するといった間接的なアプローチが必要です。
7. Lightning ExperienceとClassicの違い
Joined Reportsの機能は、Salesforce ClassicとLightning Experienceの両方で利用可能ですが、UIの操作性や一部の表示が異なる場合があります。特にLightning Experienceでは、より視覚的で直感的なレポートビルダーが提供されており、機能強化が進められています。
まとめとベストプラクティス
Joined Reportsは、Salesforceにおける複雑なデータ分析のニーズに応える非常に強力なツールです。複数のオブジェクトやリレーションパスを横断してデータを結合し、単一のレポートで多角的なビジネスインサイトを提供します。これにより、従来の単一レポートでは不可能だった、より包括的で戦略的な意思決定を支援します。
ベストプラクティス：
1. データモデルの深い理解
Joined Reportsを効果的に利用するには、Salesforceのデータモデル（Data Model：データモデル）を深く理解することが不可欠です。どのオブジェクトがどのように関連しているか、どの項目が共通項目として機能するかを把握することで、適切なレポートタイプとグループ化の選択が可能になります。
2. ユーザー要件の明確化
レポートを作成する前に、誰が、どのような目的で、どのような情報を必要としているのかを明確にしてください。これにより、レポートのスコープが定義され、不要な項目やブロックを含めることを避け、パフォーマンスを最適化できます。
3. シンプルに開始し、段階的に複雑化
まず、必要なコアデータを含む最小限のブロックでJoined Reportを作成し、それが意図したとおりに機能するかを確認します。その後、必要に応じてブロックを追加したり、フィルターやカスタム集計項目を複雑化させたりと、段階的にレポートを構築していくのが良いアプローチです。
4. 適切なレポートタイプの選択
各ブロックに対して、最適なレポートタイプを選択してください。レポートタイプは、アクセスできるデータとリレーションを定義します。結合したいデータのすべてをカバーできるレポートタイプを慎重に選ぶことが成功の鍵です。
5. 共通項目の効果的な利用
複数のブロックを横断するグループ化やフィルターには、共通項目を効果的に利用してください。これにより、データの一貫性が保たれ、意味のある集計が可能になります。共通項目が存在しない場合は、代替手段（例：カスタムレポートタイプ、SOQLクエリ）を検討する必要があります。
6. パフォーマンスの監視と最適化
特に大規模なデータセットでJoined Reportsを使用する場合、レポートの実行時間を定期的に監視してください。パフォーマンスが低下する場合は、フィルターの追加、表示項目の削減、グループ化レベルの見直しなどを行い、最適化を図ります。
7. 代替手段の検討
Joined Reportsがすべての要件を満たせない場合や、特定の制約（例：ダッシュボードへの直接的な組み込み）がある場合は、他のSalesforce分析ツールも検討してください。例えば、カスタムレポートタイプ（Custom Report Type）を作成して複雑なリレーションを定義する、より複雑なデータ統合や分析にはSalesforce Analytics Cloud（現Tableau CRM）や外部のBI（Business Intelligence：ビジネスインテリジェンス）ツールを利用する、ApexやSOQL（Salesforce Object Query Language：Salesforceオブジェクトクエリ言語）でプログラム的にデータを集計するといった選択肢があります。
Joined Reportsは、Salesforce内のデータを最大限に活用し、ビジネス上の複雑な問いに答えるための強力な資産です。これらのベストプラクティスを適用することで、組織はより効果的にデータを分析し、データドリブンな意思決定を推進できるでしょう。
コメント
コメントを投稿