2026.10.26 業務システム

Salesforceのレポートとダッシュボード：レポートタイプ設計と相対日付、APIで集計を取り出す手順

Q: 相対日付で会計年度の四半期を指定するにはどうすればよいですか？

暦の四半期ではなく、会計系の範囲を選びます。SOQLの日付リテラルでいえば THIS_QUARTER ではなく THIS_FISCAL_QUARTER にあたるもので、範囲を決める基準は組織の会計年度設定です。期首が4月の会社で暦の四半期を使うと、区切りが1か月ずれた数字になります。APIで実行する場合は、レポートの describe が返す日付範囲の一覧から値を選ぶと、組織で有効な名前と開始日・終了日を確かめたうえで指定できます。

Q: ダッシュボードの数字を外部のシステムへ自動で送れますか？

送れます。Reports and Dashboards REST APIで保存済みのレポートを実行し、結果の factMap から集計値を取り出して外部システムへ渡す形が基本です。ダッシュボード自体の更新もAPIから依頼でき、 status でウィジェットごとの更新日時を確認できます。短い間隔で更新を繰り返すとエラーになるので、更新は定時に絞り、読み取りは更新済みの結果を使う設計にしてください。

Salesforceのレポートとダッシュボード：レポートタイプ設計と相対日付、APIで集計を取り出す手順

Salesforceのレポートは「どのオブジェクトの、どのレコードを、どう集計するか」を保存した定義で、ダッシュボードはその集計結果を1画面に並べたものです。作り始めて詰まる場所は、項目が選べない（レポートタイプ）、期間が毎月ずれる（相対日付）、人によって数字が違う（実行ユーザー）の3か所にほぼ集約されます。この記事では、レポートタイプと形式の選び方、検索条件と相対日付、動的ダッシュボードの権限設計、Reports and Dashboards REST APIで集計値を取り出すコード例、TableauやPower BIへ移す判断までを作業の順に示します。仕様の根拠は2026年10月時点の公式情報です。

まとめ：レポートタイプと日付条件と実行ユーザーを先に決めて作る

レポートで使える項目は、作成時に選ぶレポートタイプで決まり、後から列を足して補うことはできません。標準のレポートタイプで「活動があるリードだけ」のような条件が組めないときは、管理者がカスタムレポートタイプを用意します。期間は日付を直接入れず、「今月」「当会計年度」のような相対日付で書きます。

ダッシュボードは実行ユーザーの権限で集計するため、誰を実行ユーザーにするかで見える範囲が変わります。部下ごとに別の画面を作る前に、閲覧者自身の権限で集計する動的ダッシュボードで足りないかを確かめてください。Salesforce外のデータとの突き合わせや長期の推移が主目的になったら、標準レポートの作り込みをやめてBIツールへ移します。

レポートタイプと4つのレポート形式で集計できる項目と範囲を決める

レポート作成画面で最初に選ぶのがレポートタイプ、次に決めるのが形式です。前者が「使える項目とレコードの範囲」、後者が「行と列のまとめ方」を決めます。

主オブジェクトで決まるレポートタイプと標準タイプで足りない場面

TrailheadのLightning レポートおよびダッシュボードの概要単元では、レポートタイプをテンプレートにたとえています。各レポートタイプには主オブジェクトが1つあり、[Accounts (取引先)]や[Leads (リード)]のように単一オブジェクトのものと、[Opportunities with Products (商品が関連する商談)]のように関連オブジェクトを含むものがあります。

標準タイプでは足りない典型が「関連レコードを持つものだけを数えたい」場面です。同じ単元の例では、[Leads]タイプを選ぶと活動の有無に関係なく全リードが返るため、リードを主オブジェクト、活動を関連オブジェクトにした「Leads with Activities」というカスタムレポートタイプを作っています。

現場から「列が出てこない」と言われたら、まずレポートタイプの主オブジェクトと関連の向きを確認します。多くは主オブジェクトの選び違いです。

表形式・サマリー・マトリックス・結合の形式とダッシュボードでの扱い

形式は4種類あり、ダッシュボードに載せられるかどうかが選択の分かれ目になります。レポートの形式を設定する単元によると、ユーザーが作るレポートの大半はサマリー形式です。

形式	まとめ方	ダッシュボードのソース	API上の名前
表形式	行の一覧のみ	行制限を設定すれば可	`TABULAR`
サマリー	行をグループ化して小計	可（もっとも向く）	`SUMMARY`
マトリックス	行と列の両方でグループ化	可	`MATRIX`
結合	複数のレポートを並べて表示	不可	`MULTI_BLOCK`

API上の名前は、Salesforce向けJavaScriptライブラリjsforceのAnalytics APIの型定義にあるreportFormatの値です。結合レポートは画面上の比較には向きますが、ダッシュボードの部品にはできません。経営会議の画面に載せたい集計を結合レポートで作り込むのは避け、サマリーかマトリックスに分けて作ります。

レポートビルダーで検索条件と相対日付を設定して商談を集計する手順

形式を決めたら、レコードの絞り込みに移ります。検索条件は種類ごとに効く範囲が違うため、順番を間違えると意図しない件数になります。

標準の検索条件・項目検索条件・検索条件ロジックの効く範囲の違い

レポートを絞り込む単元では、検索条件を次の5つに分けています。

標準の検索条件：[Show Me (表示)]で「私の取引先」「すべての取引先」を切り替え、日付項目と範囲で期間を絞る
項目の絞り込み：項目・演算子・値の組で条件を作る
検索条件ロジック：「(1 OR 2) AND 3 AND NOT 4」のように項目の絞り込み同士を組み合わせる
クロス条件：「関連する」「関連しない」で子オブジェクトの有無を条件にする
行制限：グループ化しない表形式で、上位n件だけを返す

見落としやすいのは、検索条件ロジックが項目の絞り込みにしか効かない点です。同じ単元の例では、確度は標準の検索条件にもありますが、「金額 > 100000 OR 確度 > 50%」を組むために確度を項目の絞り込みとして追加し直しています。クロス条件は「過去90日に活動のない商談」のような例外を拾うレポートで使い、カスタムレポートタイプを増やさずに済む場面があります。

相対日付で今月・直近90日・当会計四半期を自動で追従させる設定

日付の範囲は、標準の日付検索条件で「Last Month (先月)」「Current FY (当会計年度)」のような範囲を選ぶか、日付項目の絞り込みで相対日付を値に入れて指定します。相対日付は実行した日を基準に範囲を計算するため、月が変わっても定義を書き換える必要がありません。

どの相対日付が使えるかは、SOQLの日付リテラルと対応させて覚えると整理しやすくなります。Salesforce公式のSOQL編集ツールの日付リテラルの検証コードには、受け付ける範囲名が列挙されています。

集計したい期間	SOQLの日付リテラル	使いどころ
昨日・今日	`YESTERDAY`・`TODAY`	日次の活動件数
先月・来月	`LAST_MONTH`・`NEXT_MONTH`	月次の締め
直近90日	`LAST_90_DAYS`	停滞商談の洗い出し
任意の日数	`LAST_N_DAYS:n`	直近30日の新規リード
当会計四半期	`THIS_FISCAL_QUARTER`	四半期の受注見込み
過去n会計年度	`LAST_N_FISCAL_YEARS:n`	年度比較

四半期はTHIS_QUARTERとTHIS_FISCAL_QUARTERの2系統あります。前者は暦の四半期、後者は組織の会計年度設定に従う四半期です。4月始まりの会社がTHIS_QUARTERで四半期報告を作ると、期の区切りが1か月ずれるので、会計期間で集計するレポートは会計系を選びます。

日付範囲を狭く取る理由と「次の文字列と一致しない」の速度リスク

レポートが遅い、あるいはタイムアウトするときに最初に疑うのは、日付範囲と否定条件です。形式の単元は、本番環境で結果を短時間で表示するには日付範囲をできるだけ狭くするよう勧めています。演習では「All Time (常時)」を使いますが、件数の多い本番組織で同じ設定にすると表示まで待たされます。

否定の演算子も同様です。絞り込みの単元は、[Not equals (次の文字列と一致しない)]がレポートの実行を遅くしたり、タイムアウトさせたりすることがあると注意しています。除外したい値が少数なら、残したい値を「次の文字列と一致する」で列挙するほうが安全です。

ダッシュボードの実行ユーザーと動的ダッシュボードで見える範囲を設計

ダッシュボードの作業そのものは、[Dashboards]タブで新規作成し、[+ Widget]でソースレポートを選ぶだけです。手間がかかるのは画面の配置より、誰の権限で集計するかの設計です。

1ウィジェット1ソースレポートの原則と載せられないレポートの種類

ダッシュボードビルダーの単元では、ウィジェットの種類を4つに分けています。推移や構成比はグラフ、目標に対する到達度のように範囲の中で1つの値を見せるならゲージ、キー値が1つならメトリクス、レポートの行を見せるならテーブルです。

どのウィジェットも元になるソースレポートは1つで、同じレポートを棒グラフと円グラフの両方に使うこともできます。ただし、結合レポートと履歴トレンドレポートはソースに選べません。ダッシュボードに載せる集計は、最初からサマリーかマトリックス、または行制限付きの表形式で作っておく必要があります。

ダッシュボードビルダーでは、ウィジェットとは別に[+ Filter (+ 検索条件)]で項目と条件を選んだ検索条件を追加できます。似たレポートをチームの数だけ複製する前に、ダッシュボードの検索条件で絞り分けられないかを検討してください。

実行ユーザーの選び方で起きる過剰開示と動的ダッシュボードの設定手順

ダッシュボードには実行ユーザーがいて、その人のセキュリティ設定で表示データが決まります。実行ユーザーを特定の1人に固定すると、閲覧者は自分の権限に関係なく、その実行ユーザーが見られるデータを閲覧できる仕組みです。全社の商談を見られる管理者を実行ユーザーにした営業ダッシュボードを全員に共有すると、担当外の金額まで見えてしまいます。

これを避けるのが動的ダッシュボードです。実行ユーザーが常にログインユーザーになるため、各自の権限の範囲だけが集計されます。Trailheadの例では、副社長1人・営業マネージャー4人・営業担当40人の組織で、45個必要だったダッシュボードを担当者用とマネージャー用の2個に減らしています。

ダッシュボード用とソースレポート用のフォルダーを作り、対象の利用者と共有する（動的ダッシュボードは非公開フォルダーに保存できない）
ダッシュボードの編集画面で歯車アイコンからプロパティを開く
[次のユーザーとしてダッシュボードを参照]で[The dashboard viewer (ダッシュボード閲覧者)]を選ぶ
マネージャーに部下の視点で見せたい場合は、閲覧者が表示ユーザーを選べるオプションもオンにする
プロパティを保存し、ダッシュボードビルダーでもう一度保存する

手順4の切り替えができるのは「私のチームのダッシュボードの参照」または「すべてのデータの参照」の権限を持つユーザーで、ロール階層で自分より下のユーザーとして表示を確かめられます。ロール階層と共有設定が整っていない組織では、動的ダッシュボードにしても数字が合いません。先に共有設定を見直す必要があります。

Reports and Dashboards REST APIでレポートを実行する手順

レポートの結果を基幹システムやチャットへの通知に回したいときは、画面からのエクスポートより、保存済みのレポートをAPIで実行するほうが定義を二重管理せずに済みます。認証とアクセストークンの取り方はSalesforce APIの種類と認証からRESTで最初の1件を取得する手順を前提にします。

describeで相対日付の候補を取得し同期実行で総計を読むコード例

次のPythonは、保存済みレポートの定義を取得して日付条件に指定できる値を一覧にし、日付範囲だけを差し替えて同期実行するものです。標準ライブラリだけで動き、環境変数に組織のURL、アクセストークン、レポートIDを入れて実行します。例のAPIの版は2026年10月時点のv67.0です。

import json, os, urllib.request

BASE = os.environ["SF_URL"] + "/services/data/v67.0/analytics"
HDR = {"Authorization": "Bearer " + os.environ["SF_TOKEN"], "Content-Type": "application/json"}
REPORT_ID = os.environ["REPORT_ID"]


def call(path, body=None):
    req = urllib.request.Request(
        BASE + path, headers=HDR, method="POST" if body else "GET",
        data=json.dumps(body).encode() if body else None)
    with urllib.request.urlopen(req, timeout=120) as r:
        return json.load(r)


# 1) 定義を取得し、日付条件に指定できる値（相対日付の候補）を一覧にする
desc = call(f"/reports/{REPORT_ID}/describe")
durations = {}
for group in desc["reportTypeMetadata"]["standardDateFilterDurationGroups"]:
    for d in group["standardDateFilterDurations"]:
        durations[d["value"]] = d
        print(group["label"], "|", d["label"], "|", d["value"])

# 2) 日付範囲だけ差し替えて同期実行し、総計（T!T）を読む
saved = desc["reportMetadata"]["standardDateFilter"]
wanted = durations[os.environ.get("DURATION", saved["durationValue"])]
body = {"reportMetadata": {"standardDateFilter": {
    "column": saved["column"], "durationValue": wanted["value"],
    "startDate": wanted["startDate"], "endDate": wanted["endDate"]}}}
result = call(f"/reports/{REPORT_ID}?includeDetails=false", body)
print(result["factMap"]["T!T"]["aggregates"])

エンドポイントの組み立て方は、jsforceのAnalytics API実装と同じです。analytics/reports/{id}へのGETは保存済みの条件のまま実行し、本文にreportMetadataを付けたPOSTは条件を差し替えて実行します。describeの応答にあるstandardDateFilterDurationGroupsは、レポートタイプで選べる日付範囲ごとに値・表示名・開始日・終了日を返すため、相対日付の値を推測で書かずに済みます。

結果のfactMapは、グループの組み合わせごとの集計を持つ辞書です。jsforceの結合テストは、総計をキーT!Tで読み、includeDetails=trueを付けない実行では明細のrowsが返らないことを確かめています。集計値だけが欲しい連携では明細を付けずに実行し、応答を小さく保ちます。

非同期実行への切り替えとダッシュボード更新をAPIで呼ぶときの注意

件数が多く同期実行で待ちきれないレポートは、非同期実行に切り替えます。analytics/reports/{id}/instancesへPOSTすると実行インスタンスが作られ、そのIDで結果を取りに行く流れです。

API="$SF_URL/services/data/v67.0/analytics"
# 非同期実行を依頼し、インスタンスIDを控える
curl -s -X POST "$API/reports/$REPORT_ID/instances" -H "Authorization: Bearer $SF_TOKEN" | jq -r '.id, .status'
# status が Success になってから結果を取得する
curl -s "$API/reports/$REPORT_ID/instances/$INSTANCE_ID" -H "Authorization: Bearer $SF_TOKEN" | jq '.attributes.status, .factMap["T!T"].aggregates'
# ダッシュボードの更新を依頼し、ウィジェットごとの更新状況を確認する
curl -s -X PUT "$API/dashboards/$DASHBOARD_ID" -H "Authorization: Bearer $SF_TOKEN"
curl -s "$API/dashboards/$DASHBOARD_ID/status" -H "Authorization: Bearer $SF_TOKEN" | jq '.componentStatus'

インスタンスの状態は型定義上New・Running・Success・Errorの4つで、Successになるまでは集計が入っていません。ポーリングの間隔は数十秒単位にし、Errorのときは再実行の前に検索条件と日付範囲を狭められないかを見直します。

ダッシュボードの更新は短い間隔で繰り返すとエラーになります。jsforceのテストでも、頻繁な更新によるエラーを避けるために更新を試す対象は、複製したダッシュボードです。通知のたびに更新を呼ぶ設計にせず、更新は定時に1回、読み取りはstatusのrefreshDateを見て新しい結果だけを使う形にします。API呼び出しの回数の数え方と上限の設計はSalesforceのシステム連携におけるAPI方式の選定とコール上限の設計で扱っています。

標準レポートの集計限界とTableau・Power BIへ移す判断の分かれ目

標準レポートとダッシュボードで営業管理の大半はまかなえます。ただ、作り込む線を決めずに列や数式を足し続けると、誰も定義を説明できないレポートが増えます。

標準レポートとダッシュボードで足りる条件と作り込みを止める線

次の条件をすべて満たすなら、標準機能のまま運用して問題ありません。集計対象がSalesforce内のオブジェクトに閉じていること、必要な期間が相対日付で表せること、見せる相手の範囲がロール階層と共有設定で切れることの3点です。パイプラインの確認、担当者別の活動件数、四半期の受注見込みは、この範囲に収まる典型です。

反対に、次の兆候が出たら標準レポートの作り込みを止めます。

Salesforceにない請求額や在庫を突き合わせるため、毎月CSVを書き出してExcelで結合している
数年分の月次推移を並べたいが、履歴トレンドレポートはダッシュボードに載らない
同じ指標を表す数式項目やレポートが部署ごとに複製され、数字が一致しない
結合レポートで作った比較を経営会議の画面に載せられず、画面の外で説明している

1つ目と2つ目は標準機能の延長では解けません。3つ目は定義を1か所に寄せれば標準のままでも直るため、BIへ移す理由にはなりにくい兆候です。

Salesforce外のデータを混ぜて履歴を追うならBIへ移すという判断

移行先の候補は、Salesforceと同じ製品群のTableauとCRM Analytics、Microsoft 365と組み合わせるPower BIです。Trailheadのダッシュボード単元も、より高度な視覚化とビジネス分析はCRM Analyticsの学習コースへ案内しています。Tableauの製品構成と権限設計はTableauの製品の種類とデータ接続・権限設計の解説に、Power BIとの比較はPower BIのできることと料金、Tableauとの違いにまとめています。

判断を分けるのは、Salesforceのデータが分析の主役かどうかです。商談・取引先が分析の中心で、外部データは補助にとどまるなら、Salesforceとの接続が標準で用意された製品を選ぶと権限の引き継ぎが楽になります。基幹システムの会計・在庫が主役でSalesforceは入力元の1つにすぎないなら、データ基盤側に寄せるべきです。ERP全般で同じ線をどう引くかはERPとBIツールの違いと標準レポートで足りる範囲で、移行後の画面の指標と更新頻度の決め方はBIツールのダッシュボード設計の解説で扱っています。

見送るべき場面もはっきりしています。ダッシュボードの閲覧者が数人で、指標がパイプラインと活動件数だけなら、BIツールのライセンスと接続の保守費用に見合いません。標準レポートのレポートタイプとフォルダー構成を整理し直すほうが早く効きます。レポートタイプの再設計から外部データとの連携までを一続きで進めたい場合は、Salesforce導入支援サービス・Apex開発で現在の組織の構成を見たうえで切り分けを相談できます。

Salesforceのレポートとダッシュボードについてよくある質問

レポートとダッシュボードの作成・設定で寄せられやすい質問に、仕様の根拠とあわせて答えます。

Salesforceのレポートとダッシュボードは何が違うのですか？

レポートは、条件に合うレコードを絞り込み、グループ化して集計した結果の一覧です。ダッシュボードは、その結果をグラフ・ゲージ・メトリクス・テーブルのウィジェットとして1画面に並べたものです。各ウィジェットは必ず1つのソースレポートに基づくため、先にレポートを作ってからダッシュボードに載せます。どちらもフォルダーに保存され、フォルダーの共有設定で閲覧できる人が決まります。

相対日付で会計年度の四半期を指定するにはどうすればよいですか？

暦の四半期ではなく、会計系の範囲を選びます。SOQLの日付リテラルでいえばTHIS_QUARTERではなくTHIS_FISCAL_QUARTERにあたるもので、範囲を決める基準は組織の会計年度設定です。期首が4月の会社で暦の四半期を使うと、区切りが1か月ずれた数字になります。APIで実行する場合は、レポートのdescribeが返す日付範囲の一覧から値を選ぶと、組織で有効な名前と開始日・終了日を確かめたうえで指定できます。

同じダッシュボードなのに人によって表示される数字が違うのはなぜですか？

動的ダッシュボードになっている可能性が高いです。動的ダッシュボードは閲覧しているログインユーザーの権限で集計するため、担当者には自分のデータ、マネージャーには部下の分を含むデータが表示されます。全員に同じ数字を見せたいなら、実行ユーザーを特定の1人に固定します。その場合は、閲覧者全員がその実行ユーザーと同じ範囲のデータを見ることになるので、見せてよい範囲の権限を持つユーザーを選んでください。

レポートに使いたい項目が一覧に出てこないときはどうしますか？

まず、選んだレポートタイプの主オブジェクトと関連オブジェクトを確認します。項目はレポートタイプに含まれるオブジェクトからしか選べないため、商談の項目が欲しいのに取引先のレポートタイプを選んでいる、といった選び違いがよくある原因です。標準のレポートタイプに必要な組み合わせが無い場合は、管理者にカスタムレポートタイプを作ってもらいます。項目レベルセキュリティで項目自体が見えていないこともあるので、オブジェクトの項目権限もあわせて確認してください。

ダッシュボードの数字を外部のシステムへ自動で送れますか？

送れます。Reports and Dashboards REST APIで保存済みのレポートを実行し、結果のfactMapから集計値を取り出して外部システムへ渡す形が基本です。ダッシュボード自体の更新もAPIから依頼でき、statusでウィジェットごとの更新日時を確認できます。短い間隔で更新を繰り返すとエラーになるので、更新は定時に絞り、読み取りは更新済みの結果を使う設計にしてください。