背景と応用シナリオ
Salesforceコンサルタントとして、私は日々、お客様がデータから価値ある洞察を引き出すお手伝いをしています。多くのお客様が直面する共通の課題は、「複数の異なるビジネスプロセスやオブジェクトにまたがるデータを、どのようにして一つのビューで俯瞰的に把握するか」という点です。例えば、営業マネージャーは「現在進行中の商談」と、その同じ取引先に関連する「未解決のサポートケース」を同時に見たいと考えるかもしれません。また、マーケティングチームは、特定のキャンペーンから創出された「リード」と、そのリードが転換した後の「成立した商談」を並べて比較したいでしょう。
標準のSalesforceレポートは非常に強力ですが、基本的には一つのReport Type (レポートタイプ) に基づいて作成されます。これは、一つのオブジェクト、または主従関係や参照関係で密接に結びついたオブジェクト群のデータを分析するのには最適です。しかし、前述のような「商談」と「ケース」のように、直接的な親子関係ではないが同じ取引先に関連するデータを横断的に表示したい場合、標準レポートだけでは限界があります。
ここで登場するのが Joined Reports (結合レポート) です。Joined Reportsは、異なるレポートタイプを「ブロック」として一つのレポート画面に結合し、共通の項目（例えば取引先名）でデータを横並びに表示する機能です。これにより、これまで別々のレポートで確認し、手作業でExcelにまとめていたような複雑な分析が、Salesforce内で完結できるようになります。
具体的な応用シナリオ：
- 営業部門： 特定の取引先グループにおける「進行中の商談」、「成立した商談」、そして「失注した商談」を3つのブロックで表示し、パイプラインの健全性と営業活動の成果を一枚のレポートで評価する。
- カスタマーサービス部門： 大口顧客（年間契約額が高い取引先）に紐づく「オープンケースの数」と「クローズケースの数」を並べて表示し、重要顧客へのサポートリソース配分を最適化する。
- 経営層： 「当四半期の売上（成立商談）」、「次四半期のパイプライン（進行中商談）」、「そして過去の顧客満足度（ケース解決時間）」を結合し、事業全体の健全性を多角的にモニタリングする。
このように、Joined Reportsはサイロ化されたデータを繋ぎ合わせ、ビジネスの全体像を捉えるための強力な分析ツールとして機能します。
原理説明
Joined Reportsの仕組みを理解する上で最も重要な概念は、「ブロック (Block)」と「共通項目 (Common Field)」です。
ブロック (Block)
Joined Reportsは、最大5つまでの個別のレポート「ブロック」で構成されます。各ブロックは、それぞれが独立したレポートタイプに基づいています。例えば、以下のような構成が可能です。
- ブロック1： レポートタイプ「商談」
- ブロック2： レポートタイプ「ケース」
- ブロック3： レポートタイプ「活動」
レポートビルダーの画面で、レポートタイプを「結合」フォーマットに変更すると、これらのブロックを追加できるようになります。各ブロック内では、通常のレポートと同様に項目を追加したり、条件で絞り込んだり、グルーピングしたりすることが可能です。
共通項目 (Common Field)
複数のブロックを意味のある形で結合するためには、それらのブロックが共有する「共通項目」が必要です。Salesforceは、レポートに追加されたレポートタイプが共通して持つ標準項目またはカスタム項目を自動的に検出し、それらをグルーピングの基準として使用します。
最も一般的な共通項目は「Account Name (取引先名)」です。商談、ケース、活動、カスタムオブジェクトの多くは取引先に関連付けられているため、「取引先名」でグルーピングすることで、各取引先に関する異なる側面（営業活動、サポート状況など）を横断的に表示できます。
例えば、「取引先と商談」レポートと「取引先とケース」レポートを結合する場合、両方のレポートタイプに「取引先」オブジェクトが含まれているため、「取引先名」や「取引先ID」が共通項目となります。レポートを実行すると、データは以下のように表示されます：
取引先名：株式会社ABC
- 商談ブロック： 商談A (進行中)、商談B (成立)
- ケースブロック： ケースX (クローズ)、ケースY (オープン)
取引先名：XYZ株式会社
- 商談ブロック： 商談C (進行中)
- ケースブロック： データなし (この取引先にはケースが存在しない)
このように、Joined Reportsは各ブロックのデータを独立して取得し、共通項目を軸にしてそれらを並べて表示します。これにより、ある取引先に商談はあるがケースはない、といった情報の「有無」も含めて一目で把握することが可能になります。
サンプルコード
Joined Reportsは主にレポートビルダーを使用して宣言的に作成される機能ですが、Analytics REST API を使用することで、既存のJoined Reportsを実行し、その結果をプログラムで取得することが可能です。これは、カスタムUIや外部システムにレポートデータを統合する際に非常に役立ちます。
以下は、特定のJoined ReportのIDを指定して、その実行結果をJSON形式で取得するためのHTTPリクエストの例です。
注： このAPIはレポートを「実行」するものであり、レポート自体をコードで「作成・変更」するものではありません。
Analytics REST API を使用した結合レポートの実行
まず、Workbenchや任意のAPIクライアントツールを使用して、以下のエンドポイントにGETリクエストを送信します。00O_REPORT_ID_ の部分は、対象となるJoined ReportのIDに置き換えてください。
// HTTP GET Request // 既存の結合レポートのデータを取得する // vXX.0 は、お使いの組織のAPIバージョンに合わせてください GET /services/data/v58.0/analytics/reports/00O_REPORT_ID_
APIレスポンスの構造 (JSON)
APIからのレスポンスは、Joined Reportの複雑な構造を反映したJSON形式になります。特に重要なのは factMap と reportExtendedMetadata の部分です。factMap には実際のデータが格納されており、キーはブロックIDと行IDを組み合わせたものになります。
{
"reportMetadata": {
"id": "00O_REPORT_ID_",
"name": "Opportunities and Cases by Account",
"reportFormat": "JOINED",
// ...その他のメタデータ
},
"factMap": {
"T!T": { // "T!T"は集計行を示すキー
"aggregates": [
{ "label": "Grand Total", "value": 5 },
{ "label": "Sum of Amount", "value": 150000.00 }
]
},
// --- ブロック1のデータ ---
"0!0_0": { // キーの形式は「ブロックID!行ID」
"rows": [
{
"dataCells": [
{ "label": "Opportunity A", "value": "Opportunity A" },
{ "label": "100000", "value": 100000.00 }
]
}
]
},
// --- ブロック2のデータ ---
"1!0_0": { // ブロックIDが'1'に変わる
"rows": [
{
"dataCells": [
{ "label": "Case 001", "value": "Case 001" },
{ "label": "High", "value": "High" }
]
}
]
}
// ...以降のデータが続く
},
"reportExtendedMetadata": {
"groupingColumnInfo": {
// ...グルーピング情報
},
"detailColumnInfo": {
// ...列情報
},
"joinedReportMetadata": {
"joinBlocks": [
{
"blockId": 0, // ブロック0 (最初のブロック)
"reportType": "Opportunity",
"joinObjects": [
{ "object": "Account", "joinType": "INNER_JOIN" }
]
},
{
"blockId": 1, // ブロック1 (2番目のブロック)
"reportType": "Case",
"joinObjects": [
{ "object": "Account", "joinType": "INNER_JOIN" }
]
}
]
}
}
}
このJSONレスポンスを解析することで、各ブロックのデータを個別に抽出し、アプリケーションで利用することができます。joinedReportMetadata を見れば、どのブロックがどのレポートタイプに対応しているかを確認できます。
注意事項
Joined Reportsは非常に便利ですが、コンサルタントとしてお客様に提案・実装する際には、いくつかの制限と注意点を理解しておく必要があります。
- ブロック数の制限： 1つのJoined Reportに含めることができるブロックは最大5つまでです。
- 項目数の制限： レポート全体で表示できる項目（列）の数は最大100個までです。多くのブロックで多数の項目を追加すると、この上限に達する可能性があります。
- ダッシュボードコンポーネントの制限： Joined Reportを元にダッシュボードコンポーネント（グラフなど）を作成する場合、そのコンポーネントは最初のブロックのデータのみを表示します。全てのブロックのデータを統合したグラフを作成することはできません。これはお客様の期待とのギャップが生まれやすい重要なポイントです。
- レポートの登録（購読）： Joined Reportsはレポートの購読機能に対応していますが、設定が複雑になる場合があります。
- エクスポート： 「フォーマットされたレポート」としてExcelにエクスポートすることは可能ですが、「詳細のみ」のエクスポートでは、各ブロックのデータが別々のシートに出力されるのではなく、一つのシートにまとめられてしまい、意図した形式にならないことがあります。
- パフォーマンス： 非常に多くのデータを含む複数のブロックを結合すると、レポートの実行に時間がかかることがあります。特に複雑な条件や多くの数式項目を含む場合は注意が必要です。
- クロスフィルター： Joined Reportsではクロスフィルター（例：「商談のある取引先」）を使用することはできません。ブロックと共通項目によるグルーピングがその代替手段となります。
- 権限： レポートを実行するユーザーは、レポートが格納されているフォルダへのアクセス権限と、レポートに含まれるすべてのオブジェクトおよび項目への参照権限を持っている必要があります。
まとめとベストプラクティス
Joined Reportsは、Salesforceの標準機能の中でも、特にビジネスユーザーに高い価値を提供できる強力なツールです。サイロ化されたデータを連結し、これまで見えなかった関係性を可視化することで、より質の高いデータ駆動型の意思決定を支援します。
Salesforceコンサルタントとして、Joined Reportsを効果的に活用するためには、以下のベストプラクティスを推奨します。
- 明確なビジネス課題から始める： まず「このレポートで何を明らかにしたいのか？」というビジネス上の問いを定義します。例えば、「優良顧客は、サポートへの問い合わせが多いのか、少ないのか？」といった具体的な問いが、レポート設計の出発点となります。
- シンプルに始める： 最大5ブロックまで可能ですが、最初は2〜3ブロックから始めることをお勧めします。レポートが複雑になりすぎると、かえって洞察が得にくくなることがあります。 - ブロックに分かりやすい名前を付ける： 各ブロックにはデフォルトでレポートタイプ名が付きますが、「当四半期の成立商談」や「優先度『高』のオープンケース」など、内容が明確にわかる名前に変更しましょう。これにより、レポートの可読性が大幅に向上します。
- ダッシュボードの制約を事前に説明する： お客様がダッシュボードでの可視化を期待している場合、グラフには最初のブロックのデータしか利用できないという制限を設計の初期段階で明確に伝え、代替案（複数のコンポーネントを並べるなど）を検討することが重要です。
- 代替ソリューションを検討する： Joined Reportsが要件に合わない場合もあります。例えば、オブジェクト間のより複雑な関係性を分析したい場合はカスタムレポートタイプの作成が適しているかもしれません。また、より高度なデータ統合や視覚化、時系列分析が必要な場合は、Tableau CRM (旧 Einstein Analytics) や外部BIツールの活用を視野に入れるべきです。
最終的に、Joined Reportsはツールの一つです。その特性と限界を正しく理解し、お客様のビジネス課題に最も適した方法で適用することが、私たちコンサルタントの重要な役割です。この機能をマスターすることで、お客様のデータ活用を次のレベルへと引き上げることができるでしょう。