Salesforce Reference Diagramsとは？構成図の種類、使い分け、AI時代の設計実務を解説
Salesforceの導入や再設計で揉めやすいのは、機能比較より前の「何をどこまで共通理解できているか」です。経営層は投資対効果を見たいのに、実装チームは連携方式やデータ責務を詰めたい。ここで同じ資料を流用すると、認識ずれが長引きやすくなります。
2026年6月にSalesforceが刷新した Reference Diagrams は、この問題に対する実務的な標準資産です。Agentforce や Data 360 を含む現行の製品体系に合わせて図のテンプレートと表現が更新され、どの相手にどの粒度の図を見せるべきかを整理しやすくなりました。
結論から言うと、Salesforce Reference Diagrams は「構成図をきれいに描くための素材」ではなく、経営層、業務部門、実装チームの認識をそろえるための共通言語です。Capability Map、Roadmap、System Landscape、Solution Architecture、Interaction Process Flow の5種類を、対象読者ごとに使い分けると、Salesforce導入やCRM再設計で起きる説明の空振りを減らせます。
本記事のポイント
- Salesforce Reference Diagramsは、構成図を描く作業そのものより、経営層、業務部門、実装チームの認識合わせを早めるための標準資産です。
- 2026年の刷新では、AgentforceやData 360を前提に、5種類の図を読者別に使い分ける重要性が増しました。
- 図を作る順番を誤ると要件整理や連携設計が曖昧になるため、対象読者ごとに図の種類を切り替える運用が必要です。
この記事で扱うテーマ
このページで答える質問
- Salesforce Reference Diagramsとは何ですか？
- Salesforceの構成図はどの種類を使い分ければよいですか？
- Agentforce時代にSalesforceの設計図を見直す理由は何ですか？
- Salesforce導入や再設計で図をどう使うと社内合意が進みますか？
Salesforce Reference Diagramsとは何か
Salesforce Reference Diagrams は、Salesforce Architecture Center が提供する構成図テンプレート群です。目的は「Salesforceの全機能を網羅する図鑑」を作ることではありません。誰に何を説明するのかを先に切り分け、その場に合った図を最短で作る ための起点を提供することにあります。
実務では、営業部門や管理部門に対しては「どの機能をいつ導入するか」を伝えたい一方、実装担当には「どのシステムとどうつなぐか」を見せる必要があります。1枚の図に全部詰め込むと、説明される側も判断できません。Reference Diagrams は、その混線を避けるために図の種類を分けています。
この考え方は、Salesforceだけの話ではありません。AI時代の業務基盤をどう分類するかを整理した SoR・SoE・SoI・SoAの違い と同じく、見る相手と意思決定単位が違えば、必要な図も変わります。
| 観点 | Reference Diagramsが担うこと | Reference Diagramsだけでは足りないこと |
|---|---|---|
| 経営層説明 | 導入範囲、優先順位、段階展開を見せる | 投資判断の詳細な数値根拠 |
| 業務部門整理 | 誰のどの業務が変わるかを俯瞰する | 画面運用や入力ルールの細部 |
| 実装チーム連携 | 連携先、データ責務、フローを整理する | 個別設定値や例外処理の全件定義 |
5種類の図を誰に何のために使うか
Salesforce公式が整理する5種類の図は、図の見た目の違いではなく、判断してほしい相手と論点の違い で分けると理解しやすくなります。
| 図の種類 | 主な対象読者 | 向いている場面 | ここで詰めすぎないこと |
|---|---|---|---|
| Capability Map | 経営層、事業責任者 | Salesforceでどの業務能力を強化するか整理するとき | APIやオブジェクトの詳細 |
| Roadmap | 経営層、PM、導入責任者 | フェーズ分割、段階導入、投資順を話すとき | 単一フェーズの実装詳細 |
| System Landscape | 情報システム、アーキテクト | Salesforceと周辺SaaS、基幹、データ基盤の全体像を見せるとき | ユーザー操作順の説明 |
| Solution Architecture | 実装チーム、開発ベンダー | 連携方式、責務分担、技術レイヤーを詰めるとき | 経営会議向けの優先順位説明 |
| Interaction Process Flow | 業務部門、実装チーム | 業務フロー、順序、例外処理を確認するとき | 経営向けの俯瞰説明 |
たとえば、CRM再設計の初期段階で Solution Architecture から描き始めると、業務部門が議論に入れず、要件の合意が遅れやすくなります。逆に Capability Map だけで終えると、連携設計の責任者が動けません。導入順を整理したいなら Roadmap、データや接続先を整理したいなら System Landscape というように、読む相手に合わせて図の種類を切り替える必要があります。
2026年の刷新で何が重要になったのか
2026年6月の公式記事では、Reference Diagrams の刷新点として、Agentforce、Data 360、イベント駆動の連携、AI判断レイヤーを反映したテンプレート更新が示されました。ここで重要なのは、新しい図形が増えたことではなく、AI前提の設計を既存のSalesforce導入図に載せやすくなった ことです。
これまでの図では、AIエージェントをどこに置くのか、どこに人間レビューを残すのか、どのトリガーで他システムを呼ぶのかが曖昧になりがちでした。Agentforce を含む構成では、従来の画面中心のCRM説明だけでは足りません。Agentforce 360 や Headless 360 のように、実行レイヤーやAPI連携まで含めて考える必要があります。
| 刷新で効く論点 | 前提が古い図で起きやすいこと | 更新後に整理しやすいこと |
|---|---|---|
| Agentforceの位置づけ | AIが補助機能なのか実行主体なのか曖昧になる | 人間承認を含むオーケストレーション設計 |
| Data 360の反映 | 顧客データ責務が旧名称のまま混線する | 顧客データ統合と参照経路の整理 |
| イベント駆動の連携 | リアルタイム処理とバッチ処理の差が見えない | トリガー、通知、再実行の境界設定 |
| 視認性と標準化 | 案件ごとに図の書き方が変わり再利用しにくい | 関係者が読み慣れる共通表現の蓄積 |
この差は、コンタクトセンターや営業支援の刷新でも効きます。たとえば Salesforce Open CTI終了の移行 では、電話基盤の置き換えだけでなく、VoiceCall、Omni-Channel、Flow、AI支援をどう同じ図に載せるかが重要になります。
Salesforce導入や再設計で図をどう使うと合意が進むか
図を描く順番は、一般に「Capability Map → Roadmap → System Landscape → Solution Architecture → Interaction Process Flow」の順で深くすると進めやすくなります。最初に全部を精緻化するのではなく、合意したい論点だけ先に図にする方が、会議の往復が減ります。
- 業務能力の範囲を決める
営業、カスタマーサクセス、サポートのどこを対象にするかを Capability Map で切ります。 - 段階導入の順番を決める
Roadmap でフェーズを切り、全部門同時導入を避けます。これは CRMリプレイスの進め方 と同じです。 - 連携先と責務を固定する
System Landscape で ERP、MA、CTI、データ基盤との関係を整理します。 - 実装責任を落とし込む
Solution Architecture でAPI、イベント、承認、AI判断の位置を明文化します。 - 現場の処理順を確認する
Interaction Process Flow で例外時の流れまで確認し、運用説明へ接続します。
図があると、CRM管理者、部門責任者、外部ベンダーが同じ前提を持ちやすくなります。逆に、図がないまま議事録と口頭説明だけで進めると、CRM管理者の業務一覧 のような日常運用の責任分界も曖昧になります。
よくある質問
Salesforce Reference Diagramsはアーキテクトだけのものですか？
いいえ。実装チーム向けの図だけでなく、経営層や業務部門向けの Capability Map や Roadmap も含まれます。むしろ、技術者だけで閉じずに合意形成へ使う方が価値が出ます。
5種類すべてを毎回作る必要がありますか？
必要ありません。投資順を話すなら Roadmap、連携責務を詰めるなら System Landscape や Solution Architecture のように、今回決めたい論点に合う図から使う方が現実的です。
Agentforce時代に見直すべき図はどれですか？
まず Solution Architecture と Interaction Process Flow を見直すと効果が出やすくなります。AIエージェント、人間レビュー、イベント駆動のトリガーをどこに置くかが変わるからです。
Lucidchartなどの図ツールがないと使えませんか？
ツール自体は必須ではありません。重要なのは図の見た目より、対象読者に合う粒度で論点を切り分けることです。既存ツールでも同じ考え方で運用できます。
関連ページと関連記事
Salesforceの設計図は単独で読むより、AI CRMや運用設計の記事と一緒に見ると判断しやすくなります。
- Agentforce 360とは？：AI前提のSalesforce基盤をどう捉えるか確認できます。
- Salesforce Headless 360とは？：APIや外部エージェントから見たCRM設計を確認できます。
- Salesforce Open CTI終了とは？：連携設計を図で整理したくなる典型テーマです。
- CRMリプレイスの進め方とは？：段階導入と社内合意の進め方を補強できます。
- AI CRM完全ガイド：CRM再設計の全体像を広く見たい場合に向いています。
Salesforce構成図を使った導入整理を進めたい場合
Salesforce導入や再設計では、図があること自体より、誰に何を判断してもらう図なのかが揃っていることが重要です。ファネルAiでは、営業、サポート、管理部門、外部ベンダーの認識をそろえるための構成図整理や、AI前提の業務フロー設計まで含めて支援できます。
