# architect 参照図 (reference-diagrams) - Full Documentation
# Agentforce システム ランドスケープ
## 説明
Agentforce で使用可能な Salesforce 製品とその他のテクノロジー システムの混在を示すシステム ランドスケープ。Einstein Trustレイヤーと生成AIスタック(プロンプト テンプレート、LLMゲートウェイ、外部モデル、BYOM)がData 360とどのように連携し、強力なエージェント アプリケーションを構築するための強力な基盤を提供するかを示しています。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/28e332b9-b4d5-4780-8220-12e097f0dc58)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/einstein-system-landscape.webp)
# Agentforce リリース計画
## 説明
Agentforce プロジェクトの初期リリースの成果物の詳細を説明したロードマップ図。これには、プロジェクト定義、設定とテスト、パイロットリリース、ベータリリースなどのフェーズが含まれます。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/241905d5-9a36-451d-952a-e43390349502)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/generative-ai-release-plan.webp)
# Agentforce ロードマップ
## 説明
Salesforce Customer 360 実装全体に Agentforce 機能をロールアウトするためのフェーズを示すロードマップ図。これには、\[_Create Standards]_、\[Model Governance]、\[Prep Data]、\[Establish Team]、\[_Release & Monitor_]などのフェーズが含まれます。スイムレーンには、Center of Excellence、営業担当、サービス担当、および開発者が含まれます。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/1d9723f0-0835-4dc2-9cbb-01b2e97c91e8)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/generative-ai-roadmap.webp)
# Center of Excellence
## 説明
Center of Excellence (CoE) がエグゼクティブ関係者と IT の橋渡しをどのように行うかを示す図。
CoE にとって機能的および技術的なリーダーシップ能力がいかに重要かを強調します。
Center of Excellence は、企業全体の専門知識とガイダンスを提供します。
次のような活動に価値を提供します。
- ソリューション実装のベストプラクティスの確立
- 企業標準および業界標準の慣行の遵守を徹底する
- 商品エキスパートとして、プロジェクトチームに商品の教育とトレーニングを行う
- 実装中に発生するハード面の問題を解決する
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/59956c3b-3c73-469b-87a4-44c6dad948e5)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/center-of-excellence.webp)
# Customer 360 マーケティング システムランドスケープ
## 説明
この図は、Agentforce Sales、Agentforce Service、Agentforce Commerce、Tableau、Data 360 を含む Customer 360 実装のシステムランドスケープ図です。 統合された Salesforce ソリューション内のさまざまなコンポーネントがネイティブコネクタとカスタムコネクタを使用して相互に通信する方法を示します。これには、データ入力、ID 解決、セグメンテーション、有効化などの機能が含まれます。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/e83190b9-5d7d-4468-aff9-882c9086e73f)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/data-360-marketing.webp)
# Data 360 Customer Zero 実装アーキテクチャ
## 説明
Customer Zero プログラムとして Salesforce 内に実装された Salesforce Data 360 を示すエンドツーエンドの図。Salesforce Data 360は、中央のインテリジェンスおよびガバナンス レイヤーとして機能し、Trustとセマンティックを維持しながら、外部システムSnowflakeおよびAWSとのゼロ コピー統合によってエンタープライズ データを統合します。この統合されたAI対応データ基盤により、Agentforce 360の有効化が強化されます。これにより、推論豊富なエージェント、CRM強化、すべてのビジネス機能にわたる安全なポリシー対応データ フローによるクロスクラウド自動化が可能になり、組織は最終的にエージェント型のエンタープライズに変わります。
## ダウンロード可能なリンク
- [Lucid](https://lucid.app/lucidchart/editNew/af215946-127b-4b47-95b9-a7c158be351b)
- [画像](https://architect.salesforce.com/ns-assets/data360_ref_arch/sfdc_customer_zero_implementation.png)
# Data 361 テクニカルケイパビリティマップ
## 説明
Data 360 の技術力と、そのサポートに関連する製品の組み合わせを示す機能マップ。Data Lakehouse、Big Data 処理、コネクタ、変換、モデル、単一情報源などの機能が含まれています。次の図は、Tableau と MuleSoft が完全なソリューションにどのように適合するかも示しています。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/9b36e287-525d-472c-92ec-729bca136540)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/data-360-technical-capability-map.webp)
# Data 361 を使用したゼロコピーデータ統合アーキテクチャ
## 説明
さまざまな AWS Data Services と統合するための標準コネクタと、AWS Redshift および S3 との強力なゼロコピー相互運用性を使用する Salesforce Data 360 の図。 このアーキテクチャにより、組織は統合プラットフォーム間でデータをシームレスに統合および統合でき、真のエージェント型エンタープライズへの変革に不可欠な中央の統合および有効化レイヤーが提供されます。Agentforce 360、Tableau Next、Marketing Cloud、Data 360、Agentforce SalesなどのSalesforce製品が含まれます。
## ダウンロード可能なリンク:
**バックエンド: Amazon Web Services**
- [Lucid](https://lucid.app/lucidchart/editNew/04991364-85c0-45e6-b5de-553367fbb473)
- [画像](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-aws.webp)
**バックエンド: Google Cloud Platform**
- [ルシッド](https://lucid.app/lucidchart/editNew/4661f0e4-e86a-409b-9a98-8301cbbca74f)
- [画像](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-gcp.webp)
**バックエンド: Databricks**
- [ルシッド](https://lucid.app/lucidchart/editNew/e74f6e22-ce6d-4b6d-a258-76ddb8f73f4e)
- [画像](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-databricks.webp)
**バックエンド: Snowflake**
- [ルシッド](https://lucid.app/lucidchart/editNew/b02236c2-f3f4-4de8-b13b-35f67fd5390d)
- [画像](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-snf.webp)
# Data 361 一括処理のアクティベーションとイベント駆動型アクションのアーキテクチャ
## 説明
次の図は、マーケティングの有効化のためのエンドツーエンドソリューションでの Salesforce Data 360 を示しています。Home Orgs、Companion Orgs、Data Cloud One、Agentforce 360、Agentforce Sales、Marketing Cloud、Tableau Nextなどの製品を使用して完全なソリューションを構築する方法を示しています。
## ダウンロード可能なリンク
- [Lucid](https://lucid.app/lucidchart/editNew/620837ec-bb08-4f1e-af26-1164fc5f789c)
- [画像](https://architect.salesforce.com/ns-assets/data360_ref_arch/data360-actions-activations.webp)
# HTTP を介した外部統合
## 説明
次の図は、『Building Forms Decision Guide (フォーム作成決定ガイド)』のソリューションアーキテクチャ図の例で、フローの HTTP コールアウトと OmniStudio の HTTP アクションを介した外部データソースへの接続を示しています。HTTP の一般的な要求と応答のパターンが表示されます。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/161cc130-341d-4c6d-84dc-00ca6aa00462)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/external-integrations-via-http.webp)
## はじめに
図は建築作業に不可欠なツールであり、重要な部分です。図によって、さまざまなアイデアをさまざまな種類の関係者に伝えることができます。
図は、実装と製品の実態に関する 1 つの情報源として機能するため、デリバリチームの連携を保つのに役立ちます。図は、ビジネスの関係者が購入や技術に関する適切な意思決定を行えるようにする重要な方法です。
**図は常に以下のようにすべきです:**
- できるだけ左から右、上から下の順に読む
- 読みやすいように適切な情報範囲を指定してメッセージを簡潔に伝える
- [Salesforce 図の標準コンポーネント](/docs/architect/ja-jp/reference-diagrams/guide/kit-of-parts) (図の内容、範囲、目的を明確に記述したカードやヘッダーなど) の活用
## 図の範囲
図の範囲は、特定のトピックについて伝える重要な情報のみに制限する必要があります。コミュニケーションするメッセージを取得するために不要なものは除外する必要があります。図の内容をより明確に伝え、焦点を絞るために、さまざまな概念を表現する複数の図を作成することが可能(かつ推奨されます)。
- 利用者に伝える必要がある重要な情報/メッセージを定義する
- メッセージを取得する情報に焦点を絞るために論理範囲を分類する
- テンプレートとして使用する最も適切なダイアグラムの種類を特定する
## 図の種類
Salesforce Diagrams では、テンプレートを簡単に活用し、図の表記法を理解するのに役立つ、最も有用/人気のある種類の図が定義されています。現在のリソースは次のように分類されます。
### 機能マップ
- ソリューションに含まれるプロパティの組み合わせと関連する主要な機能を取得する
- 機能、ビジネスの推進要因、価値に重点を置く
✨ [リファレンスアーキテクチャギャラリー](/docs/architect/ja-jp/reference-diagrams/guide/section-capability-map)での機能マップの検索
### システムランドスケープ
- 特定の実装に関連する製品や技術システムを取得する
- プロパティ、特定のプロパティの側面、プロパティ間のつながりに焦点を絞る
✨ [リファレンスアーキテクチャギャラリー](/docs/architect/ja-jp/reference-diagrams/guide/section-system-landscape)でシステムランドスケープの例とテンプレートを見つける
### ソリューションアーキテクチャ
- インテグレーション、動作、機能を備えた製品またはテクノロジーを含める
- プロパティ全体の詳細な接続やコミュニケーションの側面に焦点を絞る
✨ [リファレンスアーキテクチャギャラリー](/docs/architect/ja-jp/reference-diagrams/guide/section-solution-architecture)でソリューションアーキテクチャの例とテンプレートを見つける
### ロードマップ
- 組織が機能、コンポーネント、機能、システムの戦略的な実装を計画し、経時的に視覚化できるようにする
- 実装の順序、依存関係、優先度を明確に表示する
✨ [リファレンスアーキテクチャギャラリー](/docs/architect/ja-jp/reference-diagrams/guide/section-roadmap)でのロードマップの例とテンプレートの検索
### インタラクション/プロセス/フロー
- プロセスをサポートするために必要な時間ベースのステップ、データフロー、またはインタラクションを取得する
- アスペクト/プロパティの順序を連番で明確化する
✨ [リファレンスアーキテクチャギャラリー](/docs/architect/ja-jp/reference-diagrams/guide/section-interaction-process-flow)でインタラクション、プロセス、フローの図の例とテンプレートを見つける
### データモデル/ERD
- メタデータ実装のエンティティ (オブジェクト)、リレーション、概念を取得する
✨ [データモデルギャラリー](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html)でデータモデルの例とテンプレートを見つける
[リファレンスアーキテクチャギャラリー](/diagrams)または専用の[データモデルギャラリー](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html)で図の種類の例を参照してください。テンプレートを使用して、使用事例の図をすばやく簡単に作成します。
## 図を作成するステップ:
- 伝える必要があるメッセージの**範囲**を定義します。
- _利用者、記述する必要があるプロパティ/側面、メッセージを取得するために必要な情報、除外できるものについて検討する_
- 明確な**タイトル**と、図の目的、範囲、メッセージを表す簡潔で慎重に記述された**説明**が**あるヘッダー**があることを確認します。
- **カード**を使用してプロパティ(システム、概念、エンティティなど)を取得する
- 必要に応じて、プロパティの詳細や主要な側面/機能を**カード属性**に取り込む
- カードのプロパティ間を**コネクタ**でつなぎ、必要に応じてリレーションを描写する
- 有用、入手可能、または適切な場合に**カードアイコン**を組み込む。
- **フッター**と**フッターアイコン**を使用して、その他の主要なプロパティの側面を取得する
**警告:**ルシッドチャートの現在の制限により、テンプレートから作成された図のフッターアイコンはカードからドッキング解除されます。フッターの中央にドラッグして、アイコンをドッキングし直す必要があります。
詳細とベストプラクティスについては、「[標準コンポーネント」ページ](/docs/architect/ja-jp/reference-diagrams/guide/kit-of-parts)を参照してください。
**Salesforce Diagramsへのご意見や質問はありますか?**[こちら](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link)でご意見をお聞かせください。
## はじめに
このドキュメントでは、[データモデルギャラリー](https://developer.salesforce.com/docs/platform/data-models/guide/get-started.html)で使用可能な商品データモデルを明確に解釈できるように、Salesforce ERD (エンティティリレーションダイアグラム) の表記法と規則の概要について説明します。
ERD は、データモデルとも呼ばれ、情報システムを視覚的に表現したものです。そのシステム内の人、オブジェクト、場所、概念、行動間のリレーションが表示されます。データの機能構造を伝える論理モデルです。Salesforce ERD では、エンティティは通常、Salesforce データベースのオブジェクトに対応付けられます。
## エンティティ
エンティティとは、情報を把握または保持する必要がある、実際のものや概念的なものを指します。
図では、エンティティは角が丸みを帯びたボックスとして表されます。通常、各エンティティボックスには 2 つの表示ラベル (該当する場合) があります。
- エンティティの論理名 (例: ここに示す例では「Salesforce エンティティ」)。これは、表される Salesforce オブジェクトの単一表示ラベルに対応する場合がありますが、常に対応するとは限りません。
- Salesforce 組織内のオブジェクトの「物理」API 参照名または開発者名 (この例では「_API 参照名_」など)。管理パッケージオブジェクトの場合、Salesforce または Industry Cloud で複数の管理パッケージが使用されていない限り、通常、図にリストされている API 参照名には管理パッケージ名前空間 (「vlocity_ins\*\*」など) は含まれません。管理パッケージオブジェクトの API 参照名の末尾は、使用されるカスタムオブジェクトの種別を示します (通常のカスタムオブジェクトとカスタム設定の場合は「\*\*c」、カスタムメタデータの場合は「\*\*mdt」、外部オブジェクトの場合は「\*\*x」)。
エンティティボックスには、そのエンティティの属性を表す 1 つ以上の属性もリストされます。属性の先頭には「#」または「-」文字があります。
- 「#」は、エンティティの論理一意キーに含まれる属性を示します。図の例では、「ユーザーキー属性」がエンティティのユーザープライマリキーとみなされます。
- 「•」はキー値以外の属性を示します。
### エンティティの書式設定
各エンティティリレーションダイアグラムは、Sales Cloud、Service Cloud、Marketing Cloud など、指定されたクラウドの観点から Salesforce データモデルを示しています。図の配色は、注力クラウドを反映しています。Financial Service Cloud、Health Cloud、Media Cloud など、すべての業種クラウドで同じ業種の配色が使用されます。
図の特定のエンティティの色にも特定の意味があります。注力クラウドの色は、Salesforce のブランド色を使用して示されます。次に例を示します。
次のセクションでは、以下の Sales Cloud の例の凡例を参照して、さまざまなエンティティ形式を確認します。
### クラウドエンティティ
フォーカスクラウドの色のエンティティは、そのクラウドのライセンスに付属するオブジェクトを表します。
### 関連エンティティ
白い塗りつぶしと黒い境界線があるエンティティは、Focus Cloud とは異なるライセンスが付属し、Focus Cloud ライセンスで拡張されていないオブジェクトを表します。たとえば、Sales Cloud ERD または Service Cloud ERD に表示される取引先および取引先責任者エンティティは、プラットフォームライセンスで使用可能なため、白と黒の境界線で表示されます。
### 拡張関連エンティティ
薄いグレーの塗りつぶしと黒の境界線があるエンティティは、フォーカスクラウドとは異なるライセンスが付属するオブジェクトを表しますが、フォーカスクラウドはそのオブジェクトを拡張します。たとえば、Commerce Cloud では、基本の Product2 オブジェクトに追加の項目が拡張されています。拡張には、追加の項目、リレーション、レコードタイプが含まれます。
### 外部エンティティ
境界のないエンティティは仮想です。これらのボックスをダイアグラムで使用すると、ドメインの論理モデルにエンティティが存在することが認識されますが、エンティティは Salesforce で物理オブジェクトとして実装されません。このエンティティのデータは、外部APIコールまたはリリース済みソリューションのSalesforce Connectを介してアクセスすることが期待されます。
### レコードタイプエンティティ
破線で囲まれたエンティティは、Salesforce でレコードタイプとしてモデル化されます。次の例では、\[法人取引先]、\[請求取引先]、\[個人取引先]、\[サービス取引先] サブタイプは Communications Cloud 管理パッケージで提供されるレコードタイプに対応付けられるため、破線で囲まれています。
### 概念エンティティ
点線で囲まれたエンティティは仮想です。Salesforce ソリューションでは、レコードタイプも個別のオブジェクトもこれらのサブタイプを区別するために使用されません。これらのサブタイプは、データモデルの機能を説明するのに役立つドメインの概念を論理的に表します。
### スーパータイプエンティティとサブタイプエンティティ
エンティティのサブ種別は、出現数のサブセットの定義です。サブ種別のセットがスーパー種別エンティティ内に追加されると、スーパー種別エンティティには共通の属性とリレーションが表示され、サブ種別エンティティにはサブ種別に固有の属性とリレーションが表示されます。図の表記では、サブタイプは相互に排他的です。つまり、1 つのレコードは 1 つのサブタイプである必要があります。
サブ種別には、出現をさらに区別するネストされたサブ種別を含めることができます。図のサブタイプは論理的ですが、3 つの方法のいずれかで物理的な表現に対応付けることができます。サブ種別エンティティの境界線の固さによって、Salesforce データモデルでサブ種別を実装する方法が定義されます。
実線で囲まれたサブ種別エンティティには、そのサブ種別の出現を追跡する実際のオブジェクトがあります。ここに示す例では、外部ユーザーとして登録されている取引先責任者は User オブジェクトのレコードで追跡されるため、取引先責任者の \[外部ユーザー] サブ種別は実線で表示されます。
## リレーション
リレーションは、2 つのエンティティ間の名前付き重要な関連付けです。
線上またはその周囲に記されたマーキングやテキストは、カーディナリティ、省略可能性、およびリレーションの意味を示します。
### リレーションカーディナリティ
カーディナリティは、リレーションの両側の出現数の相対値を示します。この表記では、リレーションの端は、その端のカーディナリティを示します。端のカラスの足は、その端の多数のエンティティ出現が反対側の各出現に関連していることを示します。端にカラスの足がないということは、その端のエンティティ出現数が最大 1 つで、反対側の特定の出現数に関連付けられるということです。
### 親子リレーション
Salesforce では、参照フィールドと親子 (主従関係) フィールドの 2 種類の[リレーションフィールド](https://developer.salesforce.com/docs/atlas.en-us.object_reference.meta/object_reference/field_types.htm#i1435823)がサポートされています。親子項目は必須の参照項目と似ていますが、関連エンティティ間の結合が追加されます。親レコードが削除されると、リレーションの多側にあるレコードはカスケード削除されます。また、詳細レコードの表示は親レコードの表示に従って制御されます。
親子リレーションと参照リレーションの違いを説明するために、Salesforce ERDではUMLからダイヤモンド表記を借りています。リレーションの 1 つの側にあるひし形とは、その側のエンティティがリレーションの主役割を果たすことを意味します。リレーションの多側のエンティティは詳細エンティティまたは子エンティティであり、親エンティティ内に含まれると考えることができます。
### リレーションの省略可能性
省略可能は、両端の出現にリレーションが必須かどうかを示します。概念として、省略可能性はカーディナリティと密接に関連しており、その表記にはその関連性が反映されています。省略可能かどうかは、リレーションの各端に対して、反対側の線上の円または棒で示されます。なぜリレーションのもう一方の端なのですか?カーディナリティと同じ側の線に省略可能性のマークアップを含めるためです。
リレーションの多くの側 (つまり、カラスの足) では、ほとんどの場合、線上に円があります。つまり、リレーションの多側では、リレーションの単数側の各出現数に対して 0 対多が発生する可能性があります。
リレーションの単数側では、円と棒は、そのリレーションの多側(カラスの足側)のエンティティの省略可能なリレーションを示します。円と棒は、多角形の各リレーションの単数側で 0 または 1 回出現する可能性があることを意味します。
または、リレーションの単数側に二重棒がある場合は、リレーションの多側のエンティティに必須のリレーションを示します。二重棒は、多側の各出現に対して、単数側には必ず 1 つだけ出現しなければならないことを意味します。
Salesforce の基盤となる物理的なリレーションは省略可能ですが、リレーションの省略可能は必須として表示される場合があります。たとえば、取引先責任者の AccountId 項目は物理的には省略可能なリレーションですが、非公開の取引先責任者を無視すると、取引先責任者と取引先の直接リレーションが論理的に必要になります。省略可能性インジケーターは慎重に使用されます。ほとんどの場合、ERD に表示される省略可能性は、リレーションの基盤となる省略可能性を反映します。
### リレーションの意味
カーディナリティと省略可能性に加えて、2 つのエンティティ間の各リレーションは、同じ 2 つのエンティティ間の他のリレーションと区別する特定の意味を表します。上記の図の「part of」や「made of」などのリレーションの終了名によって、リレーションの性質が定義されます。
リレーションのカーディナリティ、省略可能名、終了名を組み合わせると、リレーションを説明する文を形成するために使用できます。
左から右へ: 各は(必須か任意かに応じて)(ただ一つ、または一つ以上)のとなります。
右から左へ: 各は にすることができます (必須にすることもできます)。
次に例を示します。
左から右へ: 「各取引先責任者は、主たる連絡先として、一つだけの取引先に紐づけられなければなりません。」右から左へ: 「各取引先は、主たる連絡先として、一人以上の取引先責任者によって表され得ます。」
### リレーションの色分け
リレーション線は色分けされています。図上でフォーカスとなっているクラウドによって追加されたリレーションは、特定の色で描画されます。黒い線は、フォーカスクラウドとは異なるライセンスで提供されるリレーションを表します。
### 再帰リレーション
リレーションは、同じエンティティの 2 つの出現の間にあります。これを再帰関係といいます。曲線リレーション線は、再帰的なリレーションを示すために使用されます。
### 相互排他的なリレーションシップ
通常、Salesforce ERD では、データモデルの構造に焦点を絞るためにほとんどのビジネスルールが除外されますが、相互排他的なリレーションは、構造に情報を与えるビジネスルールの 1 つです。相互排他的なリレーションシップは、円弧に含まれる複数のリレーションシップのうち 1 つだけが特定の出現に使用されることを示します。2 つ、3 つ以上のリレーションが同じ相互排他的なリレーションに含まれる場合があります。ここに示されている相互排他的なリレーションを説明する文は、「各エンティティは、1 つだけの最初の他のエンティティのインスタンスである場合もあれば、1 つだけの 2 番目の他のエンティティのインスタンスである場合もあります」などです。
Salesforce ERD では、円弧を通過する切断されたリレーション線は相互排他的なリレーションに含まれません。
## レイアウト規則
Salesforce の公式製品 ERD は、読みやすさを改善するためにレイアウト規則に従います。これらのレイアウト規則には、以下の内容が含まれます。
- リレーション線は常に直線である必要があります。
- リレーションシップ線は縦方向または横方向に描画する必要があります。まれに、これができない場合、対角線上の直線を使用します。
- リレーションの直線を維持するには、エンティティボックスのサイズを変更して (より長く)、2 つのエンティティ間のリレーションのランディング プレイスを提供できます。より重要なエンティティ (リレーションが多いエンティティ) は、その重要性を強化するダイアグラムで大きく表示されます。
- 1つのERDを通して、リレーションのカーディナリティ記号(カラスの足)は、一貫してリレーション線の左側または上側(上下逆レイアウト)、または一貫してリレーション線の右側または下側(正位置レイアウト)に配置する必要があります。この規則により、類似するエンティティが図の同じ領域に集められるため、エンティティを理解するのに役立ちます。上下反転レイアウトを使用すると、図が上下逆に表示され、子エンティティが親エンティティの上または左に配置されます。ただし、これにより、図の最も具体的なエンティティが図の左上隅に配置され、図が互いに区別され、認識しやすくなります。右側のレイアウト規則を使用すると、すべての図の左上に同じ共通エンティティが表示されますが、子エンティティは親エンティティの下または右側に配置されます。
これらのレイアウト規則に厳密に準拠することで、すっきりと読みやすい図が作成されます。
[データモデルギャラリー](https://developer.salesforce.com/docs/platform/data-models/guide)で、この標準に準拠する最新の Salesforce データモデルを確認してください。
# Salesforce 役割階層
## 説明
特定の使用事例のビジネス構造、人格、権限を明確にするためにロールのサブセットを取得する組織階層の例を示す図。
これは一般的な横長の図ではありませんが、ロールがどのように関連し、ビジネスドメインをモデル化するかの概念計画を示しているという点で似ています。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/4fe3cd5e-0ccf-4ffd-9f7c-a418ce615c67)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/salesforce-role-hierarchy.webp)
# インタラクションプロセスフロー
インタラクションプロセスフロー図は、システムコンポーネント、サービス、ユーザー間のインタラクション、データフロー、プロセスステップの順序を示しています。これらの図は、アーキテクトと開発者が、システムのさまざまな部分でどのように通信し、イベントがアーキテクチャをどのように伝播し、非同期プロセスと同期プロセスがどのようにオーケストレーションされるかを理解するのに役立ちます。システムの動作の把握、ボトルネックの特定、プロセスフローの最適化に不可欠なドキュメントが提供されます。
このセクションには、インタラクションプロセスフローに関連する 6 つの参照図が含まれています。
| 図の名前 | 説明 |
| ----------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [プラットフォームイベントを介した非同期処理](/docs/architect/ja-jp/reference-diagrams/guide/asynchronous-processing-via-platform-events) | プラットフォームイベントでの非同期処理のしくみを示します。バスに公開されたイベントは、購読者によって処理のためにコンシュームされます。 |
| [Claim Check](/docs/architect/ja-jp/reference-diagrams/guide/claim-check) | レコードが変更されたときに公開されるイベントを表示します。イベントのメッセージボディはデータベースに保存され、参照のみがメッセージバスを介して渡されます。 |
| [本顧客パーソナライズフロー](/docs/architect/ja-jp/reference-diagrams/guide/customer-personalization-flow) | パーソナライズエンジンから配送システムまでのエンドツーエンドの情報フローに関連する時間ベースのやりとりが表示されます。 |
| [Http を介した外部インテグレーション](/docs/architect/ja-jp/reference-diagrams/guide/external-integrations-via-http) | HTTP プロトコルを使用した外部インテグレーションを示す『Building Forms Decision Guide (フォーム作成決定ガイド)』のソリューションアーキテクチャ図の例。 |
| [ホスピタリティロイヤルティ管理プロセス](/docs/architect/ja-jp/reference-diagrams/guide/hospitality-loyalty-management-process) | ホスピタリティロイヤルティ管理プロセスにおけるシステムの時間ベースのインタラクションを表示します。 |
| [キューイング](/docs/architect/ja-jp/reference-diagrams/guide/queuing) | キューに公開および書き込まれるイベントと、登録者がイベントを順番に処理する様子を表すキューパターンの例を示しています。 |
# キューイング
## 説明
レコードが変更されたときにイベントがキューに公開および書き込まれる様子を表すキューパターンの例を示しています。購読者は、関連付けられたキューからイベントのコピーを受信し、自分のレコードに適切な更新を行います。
## ダウンロード可能なリンク
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0cef151e-5b48-4237-bbe4-a774eee152ab)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/queuing.webp)
# コンポーネントのロードマップ
## 説明
次の図は、システム機能、関連機能、実装順序、期間、関係者の連動関係を特定することで、リソース計画と予算配分を最適化する視覚的なロードマップを示しています。
通常、この図は[機能ロードマップ](/docs/architect/ja-jp/reference-diagrams/guide/capability-roadmap)の 1 つのボックスの詳細ビューとして使用されます。
この図のコンポーネントごとに、機能提供の詳細にドリルダウンするための専用の[機能ロードマップ](/docs/architect/ja-jp/reference-diagrams/guide/feature-roadmap)を用意するのが一般的です。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/2ca75fbd-af2e-45fd-a636-01255f1fb0cf)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/component-roadmap.webp)
# システムランドスケープ
システムランドスケープダイアグラムは、Salesforce 製品、外部システム、インテグレーションポイント間のリレーションを示す、組織のテクノロジーエコシステムの包括的なビューを提供します。これらの視覚的な表現は、アーキテクトが完全なシステムトポロジを理解し、連動関係を特定し、戦略的な実装を計画するのに役立ちます。これらは、関係者が Customer 360 アーキテクチャ内でさまざまなコンポーネントをどのようにやりとりしているかを視覚化し、ビジネス目標をサポートするために不可欠なドキュメントとして機能します。
このセクションには、システムランドスケープに関連する 5 つの参照図が含まれています。
| 図の名前 | 説明 |
| ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [Customer 360 Marketing システムランドスケープ](/docs/architect/ja-jp/reference-diagrams/guide/data-360-marketing) | Customer 360アーキテクチャの実装におけるシステムランドスケープ。 |
| [Agentforce システムランドスケープ](/docs/architect/ja-jp/reference-diagrams/guide/einstein-system-landscape) | Agentforceで利用可能なSalesforce製品とその他のテクノロジーシステムの組み合わせを示すシステムランドスケープ。 |
| [リテール システムランドスケープ](/docs/architect/ja-jp/reference-diagrams/guide/retail-system-landscape) | B2C Commerce and Marketing ソリューションの実装に関わるSalesforce製品およびその他のテクノロジーの組み合わせを示すシステムランドスケープ。 |
| [Salesforce ロール階層](/docs/architect/ja-jp/reference-diagrams/guide/salesforce-role-hierarchy) | ビジネス構造、人事リレーション、アクセスパターンを明確にするためにロールのサブセットを取得する組織階層の例。 |
| [単一組織のアーキテクチャ](/docs/architect/ja-jp/reference-diagrams/guide/single-org-architecture) | 複数のビジネスユニットをサポートする 1 つの組織戦略の詳細を示す図。 |
# システムロードマップ
## 説明
システムの実装順序、連動関係、機能領域、および関係者に関連する機能を特定することで、リソースの計画と予算編成を簡略化するロードマップ図。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/ead3af9a-ddc2-492a-a8c9-7ab3943fabd7)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/system-roadmap.webp)
# ソリューションアーキテクチャ
ソリューションアーキテクチャ図は、特定のソリューションの技術的な設計と実装の詳細を示し、コンポーネント、サービス、インテグレーションがどのように連携してビジネス要件に対処するかを示します。これらの図は、アーキテクトと開発者に、システムインタラクション、データフロー、アーキテクチャパターンの詳細を示します。これらは実装のブループリントとして機能し、チームがソリューション内でコンポーネント間の関係、インテグレーションポイント、技術的な依存関係を理解するのに役立ちます。
このセクションには、ソリューションアーキテクチャに関連する 4 つの参照図が含まれています。
| 図の名前 | 説明 |
| -------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| [Data 360を使用したゼロコピー データインテグレーションアーキテクチャ](/docs/architect/ja-jp/reference-diagrams/guide/aws-data-360) | さまざまなバックエンドデータサービスと統合するための標準コネクタを使用した Salesforce Data 360 の図。 |
| [Data 360 Customer Zero 実装アーキテクチャ](/docs/architect/ja-jp/reference-diagrams/guide/sfdc-customer-zero-implementation) | Customer Zero プログラムとして Salesforce 内に実装された Salesforce Data 360 を示すエンドツーエンドの図。 |
| [Data 360 一括有効化およびイベント駆動型アクションのアーキテクチャ](/docs/architect/ja-jp/reference-diagrams/guide/data360-actions-activations) | マーケティング有効化のエンドツーエンドソリューションでの Salesforce Data 360 を示す図。 |
| [ロイヤルティ管理ソリューションアーキテクチャ](/docs/architect/ja-jp/reference-diagrams/guide/loyalty-management-solution-architecture) | ロイヤルティ管理ソリューションに直接関連する製品と機能を示すアーキテクチャ図。 |
# ビジネスケイパビリティマップ
## 説明
ビジネスの推進要因とケイパビリティを商品の概要レベルで表現するためのテンプレートマップ。
ビジネスの推進要因とは、組織の運営方法を変更するように強いる、概要レベルの戦略的目標または外部からの圧力です。
ビジネスの推進要因の例を次に示します。
- 収益増加
- 運用コストの削減
- 顧客保持
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/fe6ccc24-6a13-4e0f-8076-1e5af8b08466)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/business-capability-map.webp)
# プラットフォームイベントによる非同期処理
## 説明
次の図は、プラットフォームイベントを使用した非同期処理のインタラクションプロセスフローを示しており、広範なアーキテクチャパターンの一部としてイベントがイベントバスに公開される方法を示しています。このパターンは、メイントランザクションをブロックせずにプロセスが下流作業をトリガーし、Salesforce が面倒な作業を非同期で処理する必要がある場合に設計されています。
## ダウンロード可能なリンク:
- [Lucid](https://lucid.app/lucidchart/editNew/73e12d46-2c45-4d7c-bcf4-a2ca7596ed4c)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/asynchronous-processing-via-platform-events.webp)
# ホスピタリティロイヤルティ管理プロセス
## 説明
ホスピタリティロイヤルティ管理プロセスにおけるシステムの時間ベースのインタラクション。このフローは、Agentforce Commerce、Agentforce Sales、Agentforce Platform、Data 360、Marketing Cloud Engagement、MuleSoft、外部データソースを使用してプロセスをトレースします。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/899f5366-4dea-4da7-81af-dc3939aece42)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/hospitality-loyalty-management-process.webp)
# リテールシステムランドスケープ
## 説明
B2C Commerce and Marketing ソリューションを示すシステム ランドスケープ。Salesforce 製品と、MuleSoft、Data 360、Agentforce Sales、Agentforce Marketing、Agentforce Commerce、Agentforce Service などの実装に関連するその他のテクノロジーの組み合わせを示します。これには、マーケティングオートメーション、インタラクション管理、商品カタログ、セグメンテーションなどの機能が含まれます。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/4d6b109a-ea3e-46c2-bab6-84a07efd9ac5)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/retail-system-landscape.webp)
# ロードマップ
ロードマップ図は、組織が機能、コンポーネント、機能、システムの戦略的な実装を計画し、経時的に視覚化するのに役立ちます。これらの図を使用すると、アーキテクトとプロジェクトマネージャーはリソース計画を合理化し、予算を最適化し、ビジネスチームと技術チーム間のコラボレーションを強化できます。実装順序、依存関係、優先度が明確になるため、関係者は複雑な Salesforce ソリューションを提供するための段階的なアプローチを理解することができます。
このセクションには、ロードマップに関連する 6 つの参照図が含まれています。
| 図の名前 | 説明 |
| ---------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| [ケイパビリティロードマップ](/docs/architect/ja-jp/reference-diagrams/guide/capability-roadmap) | 機能をグループ化し、実装の順序、連動関係、価値を特定することで、リソースの計画と予算編成を合理化する視覚的なロードマップ。 |
| [コンポーネントロードマップ](/docs/architect/ja-jp/reference-diagrams/guide/component-roadmap) | システム機能、関連機能、実装順序、期間、関係者の連動関係を特定することで、リソース計画と予算配分を最適化する視覚的なロードマップ。 |
| [機能ロードマップ](/docs/architect/ja-jp/reference-diagrams/guide/feature-roadmap) | 計画の目的で機能の実装順序、連動関係、追加機能を特定することで、ビジネスチームと技術チームのコラボレーションを強化する視覚的なロードマップ。 |
| [Agentforce リリース計画](/docs/architect/ja-jp/reference-diagrams/guide/generative-ai-release-plan) | 最初の生成 AI プロジェクトリリースの成果物の詳細を示す図。 |
| [Agentforce ロードマップ](/docs/architect/ja-jp/reference-diagrams/guide/generative-ai-roadmap) | Salesforce Customer 360実装全体にAIをロールアウトするためのコンポーネントのロードマップの例。 |
| [システムロードマップ](/docs/architect/ja-jp/reference-diagrams/guide/system-roadmap) | システムの実装順序、連動関係、機能の優先度を特定することで、リソースの計画と予算編成を簡素化します。 |
# ロイヤルティ管理ソリューションアーキテクチャ
## 説明
ロイヤルティ管理ソリューションに直接関連する製品と機能を示すアーキテクチャ図。これには、分析用のAgentforce Commerce、Agentforce Sales、Agentforce Service、Marketing Cloud Engagement、MuleSoft、Data 360、Tableauが含まれます。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/217c76c7-b8c4-44ed-aade-a7ae3fb8df0a)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/loyalty-management-solution-architecture.webp)
# ロイヤルティ管理機能マップ
## 説明
次の機能マップの図は、商品の概要レベルの位置付けを示すロイヤルティ管理サービスを示しています。ロイヤルティ管理、処理、分析などの機能が含まれます。このソリューションでは、Marketing Cloud Engagement、Agentforce Service、MuleSoftなどのSalesforce製品を使用します。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/d41ccba2-71ea-449a-8497-ea95396102b4)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/loyalty-management-capability-map.webp)
# 単一組織のアーキテクチャ
## 説明
複数のビジネスユニットをサポートする 1 つの組織戦略の詳細を示す図。
下のボックスには、使用中の商品のリスト (上記参照) や、ショッピングカート、リード管理、ケース管理などのビジネスユニットに必要な機能が表示されます。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/92edbe8d-18b8-4998-a851-7d1e815ea7d5)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/single-org-architecture.webp)
## 標準コンポーネント
標準コンポーネントを使用すると、高品質で一貫性のある図を簡単に作成、カスタマイズ、再利用できます。
Salesforce では、アーキテクチャ図に Lucid をお勧めします。
プロフェッショナルなスタイルは、すべての Salesforce ダイアグラムの図形とテンプレートで使用されます。
Lucidchart の Salesforce 図形ライブラリとテンプレート
コンポーネントの使用方法の例については、[リファレンスアーキテクチャギャラリー](https://architect.salesforce.com/diagrams#reference-architecture-gallery)を参照してください。
## ベストプラクティス
次のセクションでは、標準コンポーネントに含ま[れるヘッダー](#ヘッダー)、[カード](#カード)、[アイコン](#アイコン)、および[コネクタ](#コネクタ)の詳細なベストプラクティスについて説明します。
## ヘッダー
ヘッダーはすべての図に表示され、次の内容が含まれている必要があります。
- 利用者にとってすぐに理解できるタイトル
- ダイアグラムがカバーする内容、目的、およびインテントを明確に説明する
- (省略可能) 著者を伝えるロゴまたは会社名
- (省略可能) 分類として使用されるアイコン、デザイン、記号を明確にするキー
サイズは、図の高さの 10% 以上、幅の 100% 以上を占める必要があります。
説明のフォントサイズは、タイトルの半分以上である必要があります。
アイコン、コネクタ、色など、図自体のタイトルで指定されていないものを使用する場合は、キーを含める必要があります。可能な場合は、キーを偶数行にグループ化する必要があります。
## カード
図のすべてのプロパティはカードで表されます。カードのサイズを変更したり、透明または色付きの塗りつぶしにしたりできます。カードには複数のセクションがあり、さまざまな概念を図で表すために使用できます。
### **カードの構造**
カードの例を次に示します。さまざまなセクションが説明されています。必須のカードコンテンツは \[タイトル] のみです。その他のセクションは、特定のユースケースで必要に応じて利用できます。
**カードアイコン**
カードアイコンは、カードのプロパティを表すビジュアルアセットです。
**カードタイトル**
カードタイトルは、カードが表すプロパティ、エリア、または概念を把握してすばやく理解できるカードの名前です。
**カード属性**
カード属性は、プロパティに関するテキストベースの詳細で、リストとして表され、複数のデータポイントを取得して伝達する必要がある場合に使用されます。
**カードフッター**
カードフッターには、プロパティの追加の特性が表示されます。例: パッケージ/オブジェクト/API 参照名、所有権、機能など。
**カードフッターアイコン**
フッターアイコンセクションは、プロパティに関する追加情報をビジュアルアセットに表示するためのものです。例として、チャネル、共有サービス、機能などがあります。フッターアイコンは、ダイアグラムのキー値に含める / 説明する必要があります。
警告: ルシッドチャートの現在の制限により、テンプレートから作成された図のフッターアイコンはカードからドッキングが解除されます。フッターの中央にドラッグして、アイコンをドッキングし直す必要があります。
### **カードバリエーション**
異なるセクションを使用すると、用途に応じて異なるカードのバリエーションが提供されます。必要に応じてカードの構造を組み合わせて、図に次のバリエーションを作成できます。以下の例を参照してください。
これらのバリエーションの使用方法のアイデアについては、[リファレンスアーキテクチャギャラリー](https://architect.salesforce.com/diagrams#reference-architecture-gallery)を参照してください。
必要に応じてカードのサイズと色を調整する機能を利用して、種別を区別し、わかりやすくわかりやすい図を作成します。
## **コンテナ**
カードは、複数のプロパティのグルーピングなどのコンテナとしても機能します。必要に応じて、カードを別のカード内にネストして階層関係を示したり、関連プロパティを分類したりできます。
## **アイコン**
Salesforce ダイアグラムには、Salesforce 商品ロゴの基本セットと、プロパティや図の他の領域を表す追加アイコンが用意されています。
アイコンの使用方法の例については、[リファレンスアーキテクチャギャラリー](https://architect.salesforce.com/diagrams#reference-architecture-gallery)を参照してください。
_その他のアイコンについては、[Lightning Design システムアイコンを参照してください。](https://www.lightningdesignsystem.com/icons/)_
## コネクタ
コネクタは、常に肘の接続線を使用し、可読性を高めるために可能な限りまっすぐにします。
**コネクタ**は、2 つのカード間のリレーション、インテグレーション、またはプロセスステップを表します。線スタイルは、異なる種類の接続を示すため、キー値で表現する必要があります。エンドポイントは、インテグレーションコネクタまたはプロセスコネクタの方向を示します。エンドポイントは、リレーションコネクタのカーディナリティと順序も示します。
**ピル**は、接続に関する詳細を提供するために使用されます。ピルの使用例については、[ソリューションアーキテクチャ](/docs/architect/ja-jp/reference-diagrams/guide/section-solution-architecture)と[インタラクションプロセスフロー](/docs/architect/ja-jp/reference-diagrams/guide/section-interaction-process-flow)の図を参照してください。
## アクセシビリティ
世界では、約[13億](https://www.salesforce.com/company/legal/508_accessibility/#:~:text=Product%20Accessibility%20Status&text=Around%20the%20world%2C%20approximately%201.3,global%20economy%20that%20includes%20everyone.)人が何らかの障害を抱えて生活しており、これは世界人口の15%を占めています。アクセシビリティとは、すべての閲覧者が理解しやすい図にすることです。スクリーンリーダー用に最適化することと、色のコントラストを適切に使用することの 2 つの重点領域があります。
アクセシビリティの設計に関するその他のリソースは、[Salesforce Design ブログ](https://medium.com/salesforce-ux/tagged/accessibility)を参照してください。
**スクリーンリーダー**
スクリーンリーダーは、ファイル、アプリケーション、または Web サイトの単語を読み上げるソフトウェアアプリケーションです。スクリーンリーダーは、図をはっきりと確認できない個人にも図を表示できます。スクリーンリーダーの互換性のための最適な形式は PDF (Portable Document Format) です。画像やアクセスできないアプリケーションとは異なり、PDF はスクリーンリーダーでアクセスして単語、図形、色を読むことができます。他のユーザーと共有するときに図を PDF 形式にエクスポートすると、アクセシビリティが向上します。
**色のコントラスト**
色のコントラストを上げると、図がわかりやすくなります。
テキストの背景色とテキスト自体の色の比率を 4.5:1 にするという [Web Content Accessibility Guidelines](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-contrast.html) (WCAG) の最小色のコントラストを満たすと、ユーザーは図をより適切に認識して読むことができます。
[Salesforce カラーシステム](https://medium.com/salesforce-ux/the-salesforce-color-system-c7c6b5b9c577)の各色には、0 ~ 100 の数値が関連付けられています。図の色を選択するときは、テキストの背景色がテキストの色より 50 ポイント以上大きいか小さいことを確認してください。たとえば、背景色が 80 の場合、テキストの色は 30 以下にする必要があります。 必要に応じて、境界線やアウトラインにも 50 ポイントルールを使用することを検討してください。
**Salesforce Diagramsに関するご意見やご質問はありますか?**[こちら](https://docs.google.com/forms/d/e/1FAIpQLSe5RmVA2ZtpfGlR2u436FA4QN6QmJGdAWxtZ_AcRLMAH_US9Q/viewform?usp=sf_link)でご意見をお聞かせください。
# 機能のロードマップ
## 説明
計画の目的で機能の実装順序、連動関係、追加機能を特定することで、ビジネスチームと技術チームのコラボレーションを強化する視覚的なロードマップ図。
通常、この図は[コンポーネントロードマップ](/docs/architect/ja-jp/reference-diagrams/guide/component-roadmap)の 1 つのボックスの詳細ビューとして使用されます。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/8e43258e-b21b-4525-87bf-8e5ba96f4032)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/feature-roadmap.webp)
# 機能マップ
機能マップでは、ビジネス能力と技術能力が視覚的に表現され、さまざまな製品とサービスで組織の目的がどのようにサポートされるかが示されます。これらの図は、アーキテクトと関係者がビジネスの推進要因、機能、および基盤となるテクノロジースタックの関係を理解するのに役立ちます。これらは、ビジネス目標と技術的な実装をより適切に調整できる戦略的計画ツールです。
このセクションには、機能マップに関連する 4 つの参照図が含まれています。
| 図の名前 | 説明 |
| --------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| [ビジネス能力マップ](/docs/architect/ja-jp/reference-diagrams/guide/business-capability-map) | ビジネスの推進要因と能力、及び商品の概要レベルの位置付けを表現するためのテンプレート能力マップ。 |
| [Data 360 テクニカル機能マップ](/docs/architect/ja-jp/reference-diagrams/guide/data-360-technical-capability-map) | Data 360 の技術力と、そのサポートに関連する製品の組み合わせを示す機能マップ。 |
| [ロイヤルティ管理能力マップ](/docs/architect/ja-jp/reference-diagrams/guide/loyalty-management-capability-map) | 商品の概要レベルの位置付けを含むロイヤルティ管理サービスを示す機能マップ。 |
| [Center of Excellence](/docs/architect/ja-jp/reference-diagrams/guide/center-of-excellence) | Center of Excellence (CoE) がエグゼクティブ関係者と IT の橋渡しをどのように行うかを説明する図。 |
# 機能ロードマップ
## 説明
機能をグループ化し、実装の順序、連動関係、価値を特定することで、リソースの計画と予算編成を合理化する視覚的なロードマップ。
この図の機能ごとに、デリバリの詳細にドリル インするための専用[コンポーネント ロードマップ](/docs/architect/ja-jp/reference-diagrams/guide/component-roadmap)を用意するのが一般的です。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/12103374-8b95-49bb-b7ad-b0f8154ccec6)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/capability-roadmap.webp)
# 請求チェック
## 説明
次の図は、請求チェックパターンを示しています。このパターンでは、レコードが変更されたときにイベントバスにイベントを公開します。イベントのメッセージボディは別のデータストアに保存され、請求チェックが含まれるヘッダーは登録者に渡されます。その後、登録者は請求チェックを使用して、情報を処理する準備が整ったらメッセージ本文を取得します。
## ダウンロード可能なリンク
- [Lucid](https://lucid.app/lucidchart/editNewOrRegister/0699a470-11ca-4291-88d6-a6399142a1ca)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/claim-check.webp)
# 顧客パーソナライズフロー
## 説明
次の図は、Experience Cloud サイトでの顧客とのやりとりから Marketing Cloud および Slack のバックエンドの自動化までのエンドツーエンドの情報フローに関連する時間ベースのやりとりを示しています。MuleSoft はバックエンドシステムへのインテグレーションを調整し、Slack はチームの全員を接続し、Marketing Cloud はカスタマージャーニーのループを閉じます。このアーキテクチャでは、Headless 360 および Data 361 の商品も利用されます。
## ダウンロード可能なリンク
- [ルシッド](https://lucid.app/lucidchart/editNewOrRegister/b13e3166-d3a1-4621-b275-242638f3f9af)
- [画像](https://architect.salesforce.com/ns-assets/reference-architectures/customer-personalization-flow.webp)