# architect 決定ガイド (decision-guides) - Full Documentation ## 概要 多くの場合、企業は Salesforce と、Snowflake、Google BigQuery、Databricks、Redshift、Amazon S3 などのクラウドストレージなどの他の外部データレイクの両方にデータを保存します。このように異なるソースシステムでデータがサイロ化されているため、データを最大限に活用したいと考えている企業にとって課題となっています。 複数のデータレークのデータを統合しようとするアーキテクトは、そのデータを統合する最適な方法に関する主要なアーキテクチャ上の決定に直面します。Data 360 では、データインテグレーションに複数のオプションがあり、それぞれに長所と短所があります。 このガイドでは、データ統合時の遅延、コスト、拡張性、ガバナンス、複雑さの要件にどのパターンが最適かを評価するフレームワークを提供し、データ取り込み、ゼロコピーデータ統合、またはハイブリッドアプローチを使用するタイミングを選択するのに役立ちます。また、このガイドは、さまざまなニーズに対応するさまざまなデータ取り込み方法とデータ統合方法の選択にも役立ちます。 外部データレイクハウスを Data 360 と統合するには、データの新鮮さ、ガバナンス、パイプラインの効率性のトレードオフを慎重に検討する必要があります。たとえば、Zero Copy データ統合ライブクエリを使用すると、データの新鮮度が最大限に高まりますが、ネットワークを介して移動するデータが多くなるとパイプラインの効率が低下する可能性があります。そのため、ほとんどの実際の実装では、マルチクラウド Lakehouse エコシステム内で取り込みと統合を組み合わせることが最適なパスです。このハイブリッド アプローチにより、リアルタイムのパーソナライズや不正行為の検出などの低レイテンシの運用ワークロードと、規制レポートや履歴トレンド分析などの分析ワークロードの両方をシームレスにサポートする、拡張性の高い管理された相互運用性のあるアーキテクチャが実現します。この意思決定ガイドは、これらのトレードオフをどのように操作し、適切な戦略を選択するかを理解するのに役立ちます。 ## ポイント - **データ取り込み:**データを Salesforce Data 360 にコピーし、管理された正規データモデルを作成します。次のような場合に最適です。 - **包括的なCustomer 360の構築:**異種ソースを統合し、1 つの信頼できるプロファイルに変換します。 - **厳格な規制コンプライアンスへの対応:**データアクセスと系統を厳密に制御できる監査可能な一元化されたコピーを作成します。 - **ゼロコピー統合：**重複のないリアルタイムで外部ソースを照会し、リアルタイムのパーソナライズ、ライブダッシュボード、迅速なソースオンボーディングを可能にします。バランスを取る必要があるトレードオフの 2 つの主なオプション: - **ライブおよびキャッシュ (クエリの高速化):**Snowflake、Google BigQuery、Redshift、Databricks などの外部データプラットフォームに存在するデータの対話型分析やリアルタイムダッシュボードに最適です。処理をソース・システムに転送して、低速でコストのかかるデータの重複を回避します。 - **ファイルフェデレーション:**クラウドデータレイク (S3、ADLS) のデータに関する大規模なバッチ処理や AI モデルのトレーニングに最適です。開いているテーブル形式でファイルを直接照会し、ETL およびデータサイエンスのワークロードの膨大なデータセットを解放することで、コストと時間のかかる取り込みを回避します。 - **ハイブリッド モデル:**統合プロファイルの取り込みと新鮮さのための統合がブレンドされ、オムニチャネル エンゲージメント、Agentforce駆動型アクション、AI/MLトレーニングがサポートされます。 ### 重要な考慮事項 - **ハイブリッド アーキテクチャ:**多くの場合、データ取り込みとデータ統合を組み合わせる必要があります。 - 正規データモデルとコアガバナンスの重要なデータでデータ取り込みを使用します。 - Zero Copy を使用して他のすべてのデータを統合することで、取り込みデータパイプラインの作成と管理にかかる運用オーバーヘッドを最小限に抑えます。 - **データ取り込み頻度が重要:**ビジネス価値、遅延のニーズ、運用の複雑さに基づいて頻度を選択します。 - 時間的制約のあるワークフロー(パーソナライズ、ライブ ダッシュボード、Agentforceアクション)にはリアルタイムを使用します。 - 緊急度が中程度のプロセス (キャンペーン、運用レポート) の場合はほぼリアルタイム。 - 履歴データセットまたは低速データセットのバッチ。 - **\[統合パターン] を \[レイテンシとパフォーマンス] に一致させます。**アクセスパターンと、最新性、パフォーマンス、コストの要件に最も適したアクセスパターンを選択します。 - ライブクエリは、低遅延が重要な運用ダッシュボードやリアルタイムのパーソナライズに使用します。 - キャッシュ (高速化されたクエリ) は、クエリが頻繁に発生するが、パフォーマンスとコストのバランスを取るために若干古い結果でも問題ない場合は使用します。 - ファイルフェデレーションは、履歴データセットや時間的制約の少ないデータセットに最適な、スループット負荷の高い大規模な分析またはバッチ ワークロードに使用します。 - **ガバナンスとデータ レジデンシー要件の整合性:** - 取り込みは、一元化されたガバナンスが重要な場合に使用します。 - 分散ガバナンスが許容される場合には統合を使用し、外部ソースでは厳格なガバナンスを適用します。Zero Copy では、行レベルセキュリティ (RLS) やデータマスキングなどのソースレベルのポリシーが適用されます。 - **価値の高いワークフローの取り込みに優先順位を付ける:**ID 解決、規制レポート、業務の有効化などの重要なプロセスに取り込みを選択的に適用します。 - **コストと複雑さが意思決定を促進:**リアルタイム取り込みは、コストがかかり複雑になる可能性があります。アーキテクトは、データのオンボーディング、保存、変換のコストと、ゼロコピーでデータを直接照会するコストを比較する必要があります。 適切なインテグレーションパターン (データ取り込み、ゼロコピー、ハイブリッドアプローチ) を選択することは、マルチクラウドプラットフォーム全体のレイテンシ、ガバナンス、運用効率、コストに直接影響します。この決定により、リアルタイムのインサイト、AI 主導の有効化、パーソナライズされたエンゲージメントを信頼性高く大規模に提供する方法が決まります。 ## 商品比較 次の表に、Salesforce Data 360 のデータ取り込みパターンとゼロコピーパターンの技術的な比較を示します。機能、トレードオフ、メリットに焦点を当て、エンタープライズの使用事例と結果を示します。アーキテクトは、パフォーマンス、コスト、コンプライアンスのバランスを取るハイブリッド マルチクラウド データ プラットフォームを設計する際の参考にできます。
パターン種別 モード/ツール 利点 考慮事項 結果
データ取り込み リアルタイム:CDC サポートの取り込み API を介した 1 秒未満の遅延の取り込み。継続的なストリーミングパイプライン。 - 即時インサイト
-低レイテンシの運用およびパーソナライズの使用事例に最適
-イベント駆動型ワークフローをサポート		 - 高いコスト
- 複雑なアーキテクチャ
- 低レイテンシのソースシステムが必要
- 大量のソースにより過剰なストリーミングが発生し、パイプラインが飽和状態になる可能性がある
- I/O集中型
オーバーヘッドを削減するための選択項目と絞り込みを考慮する		 Agentforce:
リアルタイムの不正行為アラート、小売のパーソナライズ、運用アラート
分析:
- 1 秒未満のダッシュボード、KPI 監視
コンプライアンス：
- 規制対象のワークフローの顧客レコードの継続的な更新
ストリーミング:ネイティブコネクタを使用して 1 ～ 3 分ごとにマイクロバッチを取り込み - コストと新鮮さのバランス
-リアルタイムよりもシンプルなアーキテクチャ
-増分更新をサポート		 - 若干の遅延
- 重要な1秒未満の意思決定には適していない可能性がある
-バッチサイズがメモリ/コンピューティングに影響する
- I/O が中程度
-予測可能で反復的な更新パターンに最適
-処理負荷を軽減するためにウィンドウ集計を考慮する		 Agentforce:
- タイムリーなキャンペーントリガー、ほぼ稼働中のエンゲージメント
分析:
- レコメンデーションエンジン、ほぼ稼働中のダッシュボード
コンプライアンス：
- 監査機能を備えた頻繁な更新
バッチ:コネクタまたは API を介してスケジュールされた大量の読み込み。オブジェクトストレージと ETL/ELT パイプラインをサポートします。 -大規模なデータセットのコスト効率
- 実装が容易
- 履歴分析の信頼性		 - データ遅延
- 時間的制約のある操作には不向き
- 読み込みウィンドウ中にI/Oを集中
-大きなファイルでは、ネットワークのスループットがボトルネックになる可能性がある
-履歴集計や規制対象のレポートワークフローに最適		 Agentforce:
- IT サポートチケット (Jira/ServiceNow)、集計されたワークフロー
分析:
・履歴分析、トレンド評価
苦情:
- 規制レポート、患者/請求データの集計
Zero Copy Live Query：外部システムでの直接クエリ、読み取り時のスキーマ、データの重複なし - 最大限の新鮮度
-最小限のストレージオーバーヘッド、リアルタイムの運用インサイトのサポート		 -ソースのパフォーマンスによる
- クエリ量が多いと遅延に影響する可能性がある
-述語プッシュダウンと集計を使用して I/O を最小限に抑えるクエリに最適
-大量のデータセットに対する絞り込まれていないクエリを回避する		 Agentforce:
- ライブ活動に適応する動的ワークフロー
分析:
- 運用ダッシュボード、ライブレポート
コンプライアンス：
- ソースでの行レベルセキュリティとマスキングを遵守
Accelerated Query (Caching):統合クエリ用のキャッシュされたローカルコピー。15 分から 7 日の間で設定できます。最適化されたクエリ実行 - 遅延を削減
- 繰り返しのライブクエリよりも低コスト
- 頻繁なアクセスパターンのパフォーマンスを向上		 キャッシュ管理が必要
-キャッシュ間隔によって停滞
- 頻度の高いクエリに最適
- 秒未満の判断には適していません。		 Agentforce:
- 迅速な意思決定のための事前集計されたエンゲージメント評価指標
分析:
- BI ダッシュボード、セグメンテーション、分析レポート
コンプライアンス：
-監査ログを含む一貫した規制対象ダッシュボード
ファイルフェデレーション:オブジェクト ストアまたはレーク(S3、Iceberg、Google BigQuery、Redshift)内の大規模な履歴データセットへの直接アクセス。 - 大規模なデータセットを処理する
Data 360 の最小ストレージ
-AI/MLワークロードをサポート		 - 参照のみ
-クエリのパフォーマンスは外部システムのスループットによって異なる
-バッチ処理が多く、スループット要件の厳しいジョブに最適化
- リアルタイムダッシュボードには適していません。		 Agentforce:
- (一般的ではない — バッチ処理が多い)
分析:
-ML/AIトレーニング、履歴分析、ペタバイト規模のレポート
コンプライアンス：
-重複のない外部データセットへのアクセスを管理
## Data 360 インテグレーションパターン ### データ取り込み データの取り込みでは、ソースにデータが残る Zero Copy とは異なり、データは物理的に Data 360 にコピーされ、完全に管理されます。Compute for Transformations は Data 360 内で実行されるため、ガバナンスと監査を一元化できます。 #### データ取り込みの使用事例 データの取り込みを使用して、正規の管理データセットを Salesforce Data 360 に保存することで、コンプライアンスと業務管理を実現します。取り込みは、完全な制御、監査、トレーサビリティが必要な場合に使用します。一元的なコンピューティングとガバナンスが重要な規制対象のワークフローや価値の高いワークフローに最適です。 取り込みは、ID 解決、規制レポート、ミッションクリティカルな AI 駆動型ワークフロー、顧客エンゲージメントのための信頼できる基盤を構築するのに最適です。 データ取り込みの概要 #### データ取り込み方法 データの取り込み方法は、データの取り込みに使用するコネクタによって異なります。さまざまな取り込み方法を提供するコネクタもあれば、バッチモードまたはストリーミングモードでのみ動作するコネクタもあります。「[Data 360:Data 360 コネクタとその使用可能な方法の完全なリストについては、Integrations and Connectors](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5) (インテグレーションとコネクタ) を参照してください。 - **リアルタイム** - ストリーミングパイプラインまたは Change データキャプチャ (CDC) を使用した 1 秒未満の取り込み。 - 時間的制約のあるワークフロー (不正検出、パーソナライズ、運用ダッシュボード) に最適です。 - Data 360 内の変換と集計をプッシュして、下流の I/O を削減し、コンピューティングの使用状況を最適化します。増分 CDC を使用して、データの入れ替えを最小限に抑えます。 - **ストリーミング** - 1 ～ 3 分おきに少しずつ取り込みます。 - キャンペーンオーケストレーション、ニアライブエンゲージメント、運用レポートに適した、新鮮さとコストのバランスの取れたソリューション。 - マイクロバッチを使用して、I/O スパイクを制御します。可能な場合はソースでデータを集計して、転送量を削減し、ストレージを最適化します。 - **バッチ (スケジュール済み負荷)** - 大規模なデータセットの定期的な取り込み (毎時、毎日、毎週)。 - 履歴データセット、規制レポート、コンプライアンスの使用事例のコスト効率と信頼性。 - パフォーマンスとコストを最適化するために、ソースストレージと同じ領域でコンピューティングの局所性を確保します。 #### Architect Playbook (アーキテクトプレイブック) - **データ取り込みの使用事例** - **Customer 360統合プロファイルの生成:**顧客の ID と属性の一元化された情報源を構築します。 - **規制コンプライアンスデータセットの管理:**機密データのガバナンス、系統、監査可能性を適用します。 - **キャンペーンのオーケストレーションを一元化:**マーケティング、営業、サービスのすべてが一貫性のある信頼できるデータセットから実行されるようにします。 - **設計プラクティス** - アーカイブレポートや定期的なスナップショットなど、履歴や低レイテンシーを必要とする場合にバッチ取り込みを推奨します。 - CDC またはストリーミング API を使用して、業務およびパーソナライズワークフローの新鮮さを維持し、ほぼリアルタイムの更新を保証します。 - データセット全体を再読み込みするのではなく、増分負荷を適用してコストと効率を最適化し、ストレージとコンピューティングの増加を制御します。 - 取り込みパイプラインをコンピューティングの局所性および増分処理に合わせて、ネットワーク I/O を削減します。Data 360 内で変換を適用して、未加工データを不必要に移動しないようにします。 - **コストに関する考慮事項** - **リアルタイム取り込み：**コンピューティングとパイプラインのコストが最も高い。パーソナライズ、運用ダッシュボード、Agentforce駆動型アクションなど、価値が高く時間的制約のあるワークフローが妥当。 - **ストリーミング取り込み:**コンピューティングコストとストレージコストを中程度に抑えます。キャンペーンオーケストレーションや運用レポートなど、わずかな遅延を許容できる頻繁な更新に適しています。 - **バッチ取り込み：**コンピューティング コストの削減と予測可能なストレージ。履歴データセットや頻度の低い更新に最適です。特定のコネクタを使用して Salesforce 組織から一括処理データを取り込むことは無料です。 - **更新モード:**増分更新モードを選択すると、取り込みと計算の合計コストを削減できます。すべての取り込み種別で効率を最適化するために、可能な限り増分更新を使用することをお勧めします。 - コストは、ソースから Data 360 への I/O 量にも影響されます。バッチサイズ、パーティション、地域調整を最適化すると、転送コストが削減され、パフォーマンスが向上します。 - **業種シナリオ** - **財務:**顧客 (KYC)、アンチマネーロンダリング (AML)、不正検出 (監査可能性とコンプライアンスが譲れない場合) を知るために必要なデータセットを取得します。 - **医療:**患者の ID 解決と HIPAA 準拠レコードの取り込みを使用して、安全で統合されたビューを実現します。 - **小売:**セグメンテーションとパーソナライズのために、POS、eコマース、ロイヤルティプログラムデータを統合プロファイルに統合 - **通信:**正規管理された登録者データを使用して、離脱防止と利用状況の分析をサポートします。 #### データ取り込み方法の決定条件
機能 リアルタイム取り込み ストリーミング取り込み 一括取り込み
レイテンシと新鮮さ 変更データキャプチャ (CDC) をサポートする取り込み API を介した 1 秒未満の遅延の取り込み。継続的なストリーミングパイプラインを提供します。低レイテンシの運用使用事例に最適です。 ネイティブコネクタを使用して 1 ～ 3 分ごとにマイクロバッチを取り込みます。増分更新をサポートします。若干の遅延が予想されます。 データ遅延が予想されます。スケジュールされた大量の読み込み。定期的な取り込み (毎時、毎日、毎週)。時間的制約のある操作には適していません。
主な使用事例 低レイテンシの運用およびパーソナライズの使用事例に最適です。時間的制約のあるワークフローに使用されます。イベント駆動型ワークフローをサポートします。リアルタイムの不正行為アラートと業務アラートに使用されます。 緊急度が中程度のプロセスに適しています。キャンペーンオーケストレーション、ニアライブエンゲージメント、運用レポートに使用されます。タイムリーなキャンペーントリガーに使用されます。 大規模なデータセットのコスト効率が高い。履歴分析の信頼性。履歴集計または規制対象のレポートワークフローに使用されます。履歴データセットや低速データセットに最適です。
アーキテクチャの複雑さと I/O 高コストで複雑なアーキテクチャ。低レイテンシのソースシステムが必要。I/O 集約型。大量のソースがあると、パイプラインが飽和する可能性があります。 リアルタイムよりもシンプルなアーキテクチャ。I/O は中程度です。予測可能で反復的な更新パターンに最適です。バッチサイズはメモリ/コンピューティングに影響します。 実装が容易。読み込みウィンドウ中は I/O 集中型。大規模なバッチでは、ネットワークのスループットがボトルネックになる可能性があります。
コストに関する考慮事項 最も高いコンピューティングコストとパイプラインコスト。価値が高く、時間的制約のあるワークフローでのみ有効です。 コンピューティングコストとストレージコストを節減します。コストと新鮮さのバランスの取れたアプローチを提供します。わずかな遅延を許容できる頻繁な更新に適しています。 コンピューティングコストの削減と予測可能なストレージ。履歴データセットや頻度の低い更新にお勧めします。Salesforce 内部パイプラインを介した取り込みは無料です。
設計プラクティス 増分 CDC を使用して、データの入れ替えを最小限に抑えます。選択項目を絞り込んで使用し、オーバーヘッドを削減します。 マイクロバッチを使用して、I/O スパイクを制御します。処理の負荷を軽減するために、ウィンドウ集計を検討します。 これは、アーカイブレポートや定期的なスナップショットに使用します。コストを最適化するために、ソースストレージと同じ領域でコンピューティングの局所性を確保します。
### Zero Copy Data Federation (ゼロコピーデータ統合) #### Zero Copy の使用事例 Zero Copy を使用して、データの重複のない外部システムのリアルタイムクエリを実行し、大規模または一時的なデータセットへの機敏性、新鮮さ、拡張性のあるアクセスを実現します。ライブダッシュボード、探索分析、AI/ML モデルのトレーニング、Salesforce Data 360 を介したリアルタイムの顧客エンゲージメントに最適です。 ゼロ コピー データ統合の概要 #### ゼロコピー方法 Zero Copy を使用する場合、アーキテクトは使用可能な 3 つのデータ統合方法のいずれかをさらに決定する必要があります。各方法には、新鮮さ、パフォーマンス、コストのトレードオフがあります。 - **Live Query** - 外部システム (Snowflake、Google BigQuery、Redshift、Databricks など) に対してデータの重複なしで直接クエリを実行します。 - 述語と集計を押し下げられる場合に最適で、ネットワーク上のデータ移動を最小限に抑え、Salesforce Data 360 コンピューティングの I/O を削減します。 - リアルタイムのインサイトと低レイテンシの運用ダッシュボードに最適です。外部システムのパフォーマンスによって異なります。 - **キャッシュ (高速化されたクエリ)** - Salesforce Data 360 に統合データのキャッシュコピーを一時的に保存します。 - 頻繁にアクセスされるデータセットの反復クエリコストと遅延を削減し、期間 (分～日) を設定可能。 - データが完全にコピーされたり、完全に管理されたりすることはありません。更新はソースからのスケジュールされた更新で管理されます。 - **ファイルフェデレーション** - オブジェクトストアの大規模なデータセット (S3、Iceberg を使用する GCS など) への参照のみの直接アクセスを提供します。 - データを移動することなく、AI/ML ワークロード、履歴分析、ペタバイト規模のレポートに最適です。 - クエリのパフォーマンスは、オブジェクト形式、パーティショニング、ネットワーク I/O に大きく依存します。大規模なスキャンでは、最適化されていない場合、大量の I/O が生成される可能性があります。 #### Architect Playbook (アーキテクトプレイブック) - **使用事例** - **リアルタイムのパーソナライズと適応型ワークフロー:**顧客の行動の変化に応じて、動的な提案、おすすめ、Next Best Action を提供します。 - **ライブ ダッシュボードと運用分析:**ビジネスクリティカルなダッシュボードと KPI を外部倉庫から直接強化します。 - **大規模な外部データセットを使用したAI/MLモデルのトレーニング:**ファイルフェデレーションを使用して、データレークやデータウェアハウスからペタバイト規模のデータを移動せずに活用します。 - **業種シナリオ** - **小売/メディア:**クリックストリームまたはコンテンツインタラクションデータを統合することで、パーソナライズされたおすすめとリアルタイムの顧客エンゲージメントを実現します。 - **財務:**機密データを重複させることなく外部倉庫を照会することで、ほぼリアルタイムで不正行為の検出とリスクスコアリングを実行します。 - **テクノロジー/エンタープライズ:**データセットが複数のシステムに存在するクロスクラウドレポート、IT サービスダッシュボード、運用分析をサポートします。 - **設計プラクティス** - **Live Query** - 新鮮さが重要な場合に、高 QPS で低遅延のクエリに使用します。 - 述語と集計を外部システムに転送して、ネットワーク上のデータの入れ替えを減らします。 - 大量のデータを不必要にスキャンするクエリは避け、パーティションプルーニングとフィルターを検討します。 - **ファイルフェデレーション** - 取り込みなしでオブジェクトストアのペタバイト規模のデータセットにアクセスできます。 - オブジェクトストレージを Salesforce コンピューティングと同じクラウド領域に保持して、遅延と出力コストを最小限に抑えます。 - パーティション分割された列形式 (Parquet/ORC) とプッシュダウン検索条件を使用して、I/O とネットワーク転送を削減します。 - クエリと述語のプッシュダウンを活用して、ソースでデータを絞り込んで集計し、データの移動を減らします。 - I/O、遅延、コストが増加するため、必要時以外は地域間のデータアクセスは避けてください。 - **キャッシュ (高速化されたクエリ)** - コストとパフォーマンスのバランスを取るために、頻繁にアクセスするデータセットをキャッシュします。 - 更新間隔を設定して、新鮮度とクエリコストのバランスを取ります。 - **コンプライアンス：**行レベルセキュリティ (RLS) を活用し、統合システム内でポリシーを直接マスキングすることで、ソースでガバナンスを適用します。以下は、プラットフォーム全体で統一的な RLS とマスキングを行うためのベストプラクティスです。 - **一元化されたエンタープライズ ID を使用します。**Salesforce Data 360 のユーザーとエンティティを、外部システムの ID に対応する一意の一元化されたエンタープライズ識別子に対応付けます。 - **セキュリティポリシーの調整:**対応付けられた ID に基づいて、統合システムの行レベルセキュリティとマスキングポリシーが適用されるようにします。これにより、外部データを照会するときのコンプライアンスが保持されます。 - **ID スキーマの標準化：**すべてのデータソースで ID 属性 (メール、ユーザー ID、顧客 ID など) の一貫性を維持し、不一致やアクセス違反を回避します。 - **コストに関する考慮事項** - **ライブクエリ：**クエリごとの支払モデル — 外部 Lakehouse コンピューティングでコストが発生し、高い QPS で急増する可能性があります。コストの変動よりも価値の方が大きい、新鮮さを重視する使用事例に最適です。 - **高速化されたクエリ (キャッシュ):**ソースシステムへのヒットを減らすことで Live Query よりもクエリコストを削減しますが、キャッシュへの入力と更新のための一括処理データ取り込みのコストが増加します。頻繁にアクセスされるデータセットに最適です。 - **ファイルフェデレーション:**オブジェクトストアのデータとして最も安価なストレージオプション。ただし、クエリコストはファイルサイズ、パーティション分割、およびプルーニングによって異なります。ペタバイト規模の履歴データや一括データに最適です。 #### ゼロコピー方法の決定条件
決定ポイント ライブクエリ キャッシュ (高速化されたクエリ) ファイルフェデレーション
データソースの場所 外部データレイクハウス (Snowflake、Google BigQuery、Redshift、Databricks)。 外部データレイクハウス (Snowflake、Google BigQuery、Redshift、Databricks) オブジェクトストアまたはクラウドデータレイク (S3、ADLS、GCS)。多くの場合、Iceberg などのオープンテーブル形式が使用されます。
目的/使用事例 対話型の分析やリアルタイムダッシュボードに最適です。リアルタイムのパーソナライズと動的なワークフローに最適です。 クエリが頻繁に発生するが、若干古い結果が許容される場合に最適です。BI ダッシュボードおよびセグメンテーションに適しています。 大規模なバッチ処理や AI/ML モデルのトレーニングに最適です。履歴分析やペタバイト規模のレポートに最適です。
新鮮さ/レイテンシ 最大限の新鮮さ。クエリはリアルタイムで直接実行されます。1 秒未満の決定をサポートします。 若干古い結果でも問題ありません。新鮮度はキャッシュ間隔によって異なり、15 分から 7 日間の範囲で設定できます。 バッチ負荷が高く、スループット要件の厳しいジョブに最適化されています。リアルタイムダッシュボードには適していません。
アクセスパターン 頻度の低いクエリやアドホッククエリに最適です。新鮮さが重要な高 QPS (1 秒あたりのクエリ数) で低遅延のクエリに使用します。 高頻度の読み取りシナリオに最適です。頻繁なアクセスパターンのパフォーマンスが向上します。 参照のみアクセス権。取り込みなしのペタバイト規模のデータセットに適しています。
パフォーマンスの促進要因 外部ソースシステムのパフォーマンスに大きく依存します。述語と集計をソースにプッシュできる場合に最適化されます。 繰り返されるライブクエリよりも遅延が短縮されます。パフォーマンスは、キャッシュ管理と間隔によって異なります。 パフォーマンスは、オブジェクト形式、パーティショニング、外部システムのスループットに大きく依存します。パーティション分割された列形式 (Parquet/ORC) を使用します。
コストへの影響 クエリ単位の支払モデル。外部 Lakehouse コンピューティングで発生するコスト。クエリ頻度が低い場合はコスト効率が高くなりますが、1 秒あたりのクエリ (QPS) 量が多いと経費が急増する可能性があります。 繰り返しのライブクエリよりも低コスト。外部ソースを繰り返し照会する必要がなくなります。キャッシュストレージと更新オーバーヘッドが追加されます。 最も安価なストレージオプション。クエリコストは、ファイルサイズとパーティション化によって異なります。
主な考慮事項 大量のデータを不必要にスキャンする絞り込まれていないクエリは避けてください。 キャッシュ管理が必要です。秒未満の判断には適していません。 クエリのパフォーマンスは、パーティショニングと述語プッシュダウンによる最適化に大きく依存します。
### ハイブリッドアプローチ ハイブリッドアーキテクチャにより、アーキテクトは、統合クエリを活用して新しさ、重複の削減、大規模な外部データセットへのスケーラブルなアクセスを実現しながら、重要なデータセットを Data 360 に固定して一元管理できます。このアプローチでは、I/O、計算の局所性、コスト、コンプライアンスの要件のバランスを取ります。 #### ハイブリッドの使用事例 ハイブリッドアプローチを使用して、データの取り込みとゼロコピーを組み合わせることで、バランスの取れたガバナンス、新鮮さ、運用効率を実現し、リアルタイムでアクション可能なインサイトを提供します。トレーサビリティ、RLS、マスキングが必要な価値の高い規制対象のデータセットには取り込みを使用し、新鮮さとパフォーマンスが重要な一時的または大量のデータセットには統合を使用します。 ハイブリッド アプローチの概要 #### Architect Playbook (アーキテクトプレイブック) - **使用事例** - **オムニチャネルエンゲージメント:**過去の顧客データとリアルタイムの行動を組み合わせて、一貫性のあるコンテキスト対応環境を提供します。 - **AI/MLパイプライン:**選定された正規データセットでモデルをトレーニングしながら、外部ソースからの未加工またはリアルタイムのシグナルで強化します。 - **混在するコンプライアンスと俊敏性のニーズ:**機密データには厳格なガバナンスを適用し、運用の俊敏性については統合します。 - **業種シナリオ** - **小売:**ID 解決とプロファイル統合には取り込みを使用し、リアルタイムの提案とパーソナライズには統合を使用します。 - **医療:**IoT デバイスストリームとセンサーデータを統合することでコンテキストをすぐに把握しながら、取り込みによってゴールデンの患者レコードを維持します。 - **金融サービス:**不正行為の検出とリスク監視のための外部クエリを統合しながら、規制対象データをコンプライアンスが管理されるレイクに取り込みます。 - **設計プラクティス** - **取り込みを使用したアンカー ガバナンス:**価値の高いデータや規制対象のデータを正規モデルに取り込み、Trustとコンプライアンスを確保します。 - **新鮮さのための統合の使用:**外部レイクハウスで、重複のないリアルタイムまたは大規模なデータアクセスができるようにします。 - **バランスコストとパフォーマンス:**ワークロードをプロファイルして、取り込むものと統合するものを決定し、不要なストレージやクエリのコストを最小限に抑えます。 - **階層化されたガバナンスの適用:**統合システム独自のセキュリティ制御 (RLS、マスキングなど) を活用しながら、取り込まれたデータの一元的なガバナンスを適用します。 - ハイブリッドパイプラインを設計する場合、履歴データセットの増分取り込みを確認し、統合ソースに集計または絞り込みを転送して、I/O と計算の使用量を最適化します。 - **コストに関する考慮事項** - コンプライアンスや重要なデータの取り込みと、新鮮さが必要な場合の統合を組み合わせて、総コストとパフォーマンスを最適化します。 - 取り込みと統合を混在させるときに、I/O とコンピューティングの配分を考慮します。クエリが繰り返されるソースシステムでの計算コストを削減するには、読み取り頻度が高く、頻繁にアクセスされる統合データセットのキャッシュ (Accelerated Query) を使用します。 ## 使用事例決定ガイド このロジックを適用する方法を示す一般的なアーキタイプを次に示します。 1. **「単一の情報源」のアーキタイプ:一元化と管理** - **シナリオ:**グローバル企業全体に対して、コンプライアンスに準拠した統合 Customer 360 プロファイルを作成する必要があります。データはさまざまなシステムから取得され、GDPR と CCPA の厳格な規制に準拠する必要があり、すべてのマーケティングおよびサービスインタラクションの信頼できるソースとして機能します。 - **推奨パターン:****データ取り込み。**優先度は、Governance、Trust、Control です。Data 360 にデータを取り込むことが、ソースシステムから隔離された、完全に監査可能な正規プロファイルを作成する唯一の方法です。 2. **「リアルタイム インサイト」のアーキタイプ:移動せずに分析** - **シナリオ:**データサイエンスチームは、Snowflake で絶えず更新される大量のトランザクションテーブルに対して探索クエリを実行する必要があります。同時に、エグゼクティブチームは、同じデータに基づいたライブ BI ダッシュボードを必要としています。毎日数ペタバイトのデータを移動すると、時間がかかりすぎる上にコストがかかります。 - **推奨パターン:****ゼロコピー統合。**優先事項は、スピード、俊敏性、大規模なコスト効率です。Zero Copy では、既存のデータウェアハウスの膨大な機能を活用して、データの重複によるオーバーヘッドや遅延を発生させることなくリアルタイムクエリを実行できます。 3. **「ハイブリッド インテリジェンス」のアーキタイプ:コアの管理、エッジの統合** - **シナリオ:**データレイクからのリアルタイムの行動シグナル (Web サイトのクリックなど) を使用して、管理され、取り込まれた顧客プロファイルを強化したいと考えています。コアプロファイルの安定性は必要ですが、ライブデータの即時性は、その場のパーソナライズを強化するために必要です。 - **推奨パターン:****ハイブリッド アプローチ。**データ取り込みを使用して、顧客データの安定した管理されたコアを作成します。次に、ゼロコピーを使用して、揮発性のリアルタイムの「エッジ」データを統合し、クエリ時に結合して、最新の完全なビューを表示します。 ## 進むべき道 エンタープライズデータ戦略は、もはや 1 つのインテグレーションパターンを選択することではなく、相互運用可能なデータエコシステム内で制御された柔軟性を構築することです。多くの場合、ビジネスニーズに基づいて各ソースデータシステムに適切なデータインテグレーション方法を選択することで、データ取り込みとデータ統合の両方の長所をブレンドしたハイブリッドアプローチが可能になります。 - コンプライアンス、ID 解決、運用ワークフローのために、ミッションクリティカルな管理データセットを Salesforce Data 360 に取り込みます。 - Zero Copy を使用してデータを統合することで、ストレージを重複させることなくライブ、探索、AI 駆動の分析を行うことができます。 Hyperforce上のSalesforce Data 360は、複数リージョンの復元性と拡張性を実現します。Icebergテーブルを備えたオープンな Lakehouse により、Snowflake、Databricks、S3 Icebergなどのプラットフォームとのコンピューティングの分離と相互運用性が実現し、真に相互運用性のあるマルチクラウドデータエコシステムのバックボーンが形成されます。 データエコシステムの進化に合わせて、新鮮さ、コスト、パフォーマンス、コンプライアンスを継続的にバランスさせ、アーキテクチャの俊敏性を維持します。取り込まれた管理データを統合アクセスで統合することで、プラットフォームを将来にわたって使用できます。これにより、クラウド、地域、ビジネスドメイン全体でリアルタイムインテリジェンス、AI の有効化、エンタープライズ規模のパーソナライズが可能になります。 汎用的なソリューションは、ほとんどのビジネスには適していません。最適な戦略では、適切なパターンを適切なビジネスドライバーに対応付けます。 ## 著者について Yugandhar Bora は、Salesforce のソフトウェアエンジニアリングアーキテクトで、Data & Intelligence アプリケーションプラットフォーム内のデータアーキテクチャを専門としています。データガバナンスと統合データモデルに焦点を絞ったエンタープライズアーキテクチャレビューボード (EARB) イニシアチブを主導しながら、自動化プラットフォームプロビジョニングソリューションに貢献しています。 Jan Fernando は、Salesforce のチーフアーキテクトオフィスのプリンシパルアーキテクトです。2012 年に Salesforce に入社し、スタートアップエコシステム時代から豊富な経験を積んできました。Office of the Chief Architect に入社する前は、プラットフォーム組織で 10 年以上にわたり、いくつかの主要なテクノロジー変革を率いていました。 ## 概要 Salesforce Data 360は、Hyperforce上に構築されたデータ プラットフォームで、Salesforceと外部データを、すべての顧客またはアカウントの明確で完全、かつ信頼できる全方位的なビューに統合します。 合併や買収、地域の業務、職務の分離、または歴史的な理由により、多くの場合、企業は複数の Salesforce 組織を運営しています。アーキテクトは、1 つの自宅組織と複数組織のどちらを設定するかだけでなく、複数の独立した Data 360 インスタンスをプロビジョニングするか、Data Cloud One を使用して 1 つのインスタンスで組織を統合するか、Data 360 間のデータ共有 (Data 360 と Data 360 のデータ共有) を使用して独立した Data 360 インスタンス間でコラボレーションするかも決定する必要があります。これらの選択は、ガバナンス、コンプライアンス、コスト、レイテンシ、および組織の AI および組織間プラットフォーム機能の拡張能力に影響します。 Data 360 は、Data 360 ライセンスを受け取る本番組織で自動的にプロビジョニングされます。Data Cloud One は、1 つの自宅組織で Data 360 インスタンスをホストし、他の Salesforce 組織はコンパニオン組織として接続できるようにする Salesforce の複数組織の接続アーキテクチャです。Data 360 ライセンスを保持し、Data 360 ホーム組織となる組織の選択は、長期的な影響を伴う重要なアーキテクチャ上の決定です。 Salesforce Data 360のプロビジョニング方法は、アーキテクチャに関する基本的な決定事項です。これは、企業がどのように顧客データを統合し、ガバナンスを適用し、重要なプラットフォーム機能(特にAI、Agentforce、分析)を組織全体で有効にするかを決定するためです。組織のクラスターを 1 つの Data 360 に固定することで、統合されたデータモデル、一元化されたガバナンス、全社的な AI 準備が実現します。また、コンパニオン組織はデータがローカルにあるかのように共有メタデータと機能にアクセスできます。一方、規制、コンプライアンス、または自律性の要件によって一元化できない場合、Data 360 組織間のデータ共有により、これらのインスタンス間でゼロコピーで選択的なコラボレーションが可能になるため、複数の独立した Data 360 インスタンスが適しています。 建築家にとって、この決定は非常に重要です。データガバナンスを制御するユーザー、データが存在する場所、プラットフォーム機能の有効化方法、将来のインテグレーションと AI イニシアチブの拡張性を定義します。現在 Data 360 を使用していない組織でも、今後 Data 360 アクセスを追加する戦略を立てることで、アーキテクチャを将来に備えることが重要になる場合があります。Sales、Service、Marketing、Commerce、Industries、AgentforceにわたるSalesforceの機能は、Data 360上に構築されることが増えています。これらのプラットフォーム機能を使用する組織は、独自の Data 360 をプロビジョニングするか、共有の Data 360 にコンパニオン組織として接続する必要があります。 このガイドは、アーキテクトがシンプルさ、エンタープライズ全体の一貫性、コンプライアンス、拡張性のバランスを取るプロビジョニング戦略を設計するのに役立ちます。これにより、組織は自信を持ってData 360をCustomer 360、AI、クロス プラットフォームのイノベーションに活用できます。Data 360 をプロビジョニングする組織の選択方法、および Data Cloud One と Data 360 組織間のデータ共有の選択方法を決定し、Data 360 中心の未来にビジネスを進めるための強固な基盤を築くのに役立ちます。 --- ## プロビジョニングに関する考慮事項 Data Cloud One と Data 360 組織間のデータ共有のどちらを選択するか、またはどの組織をホーム組織として指定するかなど、すべてのプロビジョニングの選択は、次の横断的な考慮事項に照らして評価する必要があります。
考慮事項 重要な理由 シナリオの例
データレジデンシーとコンプライアンス データを保存および処理する場所を決定します。規制ルールでは、特定の地域または複数のインスタンスが必要になる場合があります。 あるグローバル銀行は、GDPR に準拠するためにフランクフルトに地理的に配置された Salesforce 組織に Data 360 テナントをプロビジョニングし、米国部門用にバージニア州の組織に Data 360 テナントをプロビジョニングしました。
ガバナンスとセキュリティ Data 360 を所有および管理するのは誰ですか?ポリシーはビジネスユニットごとに一元管理するか、委任するか? 強力な中央 IT を持つ多国籍企業が、Center of Excellence によって管理される専用の自宅組織を作成します。
Autonomy vs.一元化 リーダーによって、データの所有権が異なる場合があります。自律性では複数の Data 360 が、一元化では Data Cloud One が適しています。 独立した子会社を持つ持株会社では、各 BU が独自の Data 360 を実行できます。
レイテンシとパフォーマンス 特に、リージョン全体の Data 360 テナントに接続されているコンパニオン組織の場合、クエリ速度とエクスペリエンスに影響します。 ロンドンの営業チームが米国の Data 360 テナントからデータを照会すると、遅延が大きくなる場合があります。
インテグレーションの複雑さ Data 360 テナントが増えると、パイプライン、API、ミドルウェアが増えます。統合により、統合が簡素化されます。 ある小売業者は、Data Cloud One 設定に統合することで、10 個の ETL パイプラインを構築する必要がなくなります。
ゼロコピーデータソース領域 Zero Copy コネクタには、Data 360 を配置できるリージョンを制限するクロスリージョンアクセス要件がある場合があります。 ある会社に AWS eu-west-1 リージョンの Snowflake インスタンスがあります。Zero Copy を使用して自分の地域の Data 360 にデータを統合できますが、Zero Copy を使用して米国地域の Data 360 に統合することはできません。
プライベートコネクトのリージョン間の互換性 場合によっては、データソースが Data 360 テナントと同じリージョンにあるかどうかによってプライベートコネクトのサポートが異なる場合があります。 aws-east-1 リージョンに、ゼロコピーで接続する Snowflake インスタンスがあります。Data 360 ホーム組織が同じリージョンにある場合のみ、プライベートコネクトネットワーク接続を確立できます。
コストとライセンス 各 Data 360 テナントのコストが増加します。より少ないインスタンスに統合することで、支出が最適化されます。 あるヘルスケア事業者は、複数の独立した Data 360 インスタンスではなく Data Cloud One を採用してライセンスコストを削減します。
将来の拡張性 今日のプロビジョニングの選択肢は、成長の基盤となります。 ある SaaS 会社は、1 つの Data 360 インスタンスから開始し、Salesforce 組織の子会社を買収して Data Cloud One に拡張する予定です。
エンタープライズ全体のAI対応 AI機能とAgentforceでは、すべての組織に接続されたData 360テナントが必要です。プロビジョニングの決定は、AI モデルが企業全体でどのようにトレーニングおよび有効化されるかに影響します。 ある金融サービス会社は、データをData Cloud Oneに統合し、Einstein AIモデルがエンタープライズ全体の顧客データにアクセスできるようにします。
### 重要な考慮事項 --- ## セクション 1:Provisioning Data 360 – Choosing the Home Org (Data 360 のプロビジョニング – ホーム組織の選択) ### 1.1 Data 360 ホーム組織とは? Data 360 ライセンスを購入すると、そのライセンスに関連付けられた Salesforce 組織に Data 360 インスタンスがプロビジョニングされます。この組織は Data 360 ホーム組織と呼ばれます。 Data 360 ホーム組織を示す決定図 ホーム組織は、Data 360 インスタンスのアンカーです。ここで、 - Data 360 のストレージとコンピューティングは (プロビジョニング時に選択した地域で) 管理されます。 - 管理、ガバナンス、セキュリティポリシーが適用されます。 - データの取り込み、ハーモナイゼーション、ID解決、セグメンテーション、有効化が実行されます。 マルチ組織のシナリオでは、ホーム組織で他の Salesforce 「コンパニオン」組織の中央 Data 360 インスタンスを管理します。 ホーム組織が重要な理由: - Data 360 インスタンスの地理的位置を決定します。 - Data 360 インスタンスの所有者と管理者を決定します。Data 360 ホーム組織の管理者は、Data 360 に取り込まれたすべてのデータにアクセスできます。 - Data Cloud One 設定でコンパニオン組織の接続を制御します。 - これにより、エンタープライズデータ戦略の基盤が確立されます。後で変更するのは困難で、中断を伴います。 ### 1.2 決定:ホーム組織として既存の組織または新規組織 最初の大きな決定は、既存の本番組織で Data 360 をプロビジョニングするか、新しい専用組織を作成してホーム組織として機能させるかです。 既存の組織と新しい組織をホーム組織として示した決定図 #### オプション A:既存の組織での Data 360 のプロビジョニング **最適な用途:**1 つの Salesforce 組織を使用しているお客様、またはほとんどのビジネスが実行されている主要な一元化された組織をすでに使用している複数組織のお客様。 既存の組織での Data 360 プロビジョニングを示す図 - **長所**: - 最もシンプルなパス:Data 360 は、CRM データがすでに存在する場所でプロビジョニングされます。 - ローカルの営業、サービス、マーケティングデータにすぐにアクセスできます。 - 追加のインテグレーションは必要ありません。 - 管理するライセンスと環境が少ない。 - 早期導入、パイロット、本番での使用事例を加速します。 - **短所**: - 既存の組織のガバナンスまたは技術的負債を継承する可能性がある。 - 「メイン組織」が 1 つも存在しない場合、1 つを選択すると所有権に関する議論が生じる可能性があります。 - 組織の場所に関連するパフォーマンス。企業全体のレジデンシーのニーズと一致しない場合があります。 - 複数のビジネスユニットで異なる組織を使用している場合、ローカルプロビジョニングを Data Cloud One と組み合わせないと断片化が発生する可能性があります。 **例:** 1 つの Salesforce 組織を持つ SaaS 会社は、顧客のサブスクリプションデータとサポートデータを統合するために、その組織に Data 360 をプロビジョニングします。 #### オプション B:新しい専用組織での Data 360 のプロビジョニング **最適な用途:**複数の Salesforce 組織があり、1 つの主要組織で連携できないお客様、または強力な Center of Excellence (CoE) モデルを使用する企業。 新しい専用組織での Data 360 プロビジョニングを示す図 - **長所**: - 継承された組織の複雑さがなく、ガバナンスを一から構築できます。 - 複数の基幹業務の一元管理。 - コンプライアンスのニーズに基づいて地域を柔軟に選択できます。 - 1 つのビジネスユニットに縛られず、中立的な「共有サービス」組織として機能します。 - 将来の Data Cloud One アーキテクチャ (複数のコンパニオン組織がある自宅組織) に合わせて設定します。 - **短所**: - 顧客は、Data 360 をプロビジョニングする新しい Salesforce 組織のライセンスを取得する必要があります。 - Data Cloud One コンパニオン接続を介して組織を Data 360 に接続するには、追加のインテグレーションが必要です。 - 管理オーバーヘッド (ユーザー管理、セキュリティ、ID) を追加する場合があります。 - 既存の本番組織のプロビジョニングと比較して、タイム トゥ バリューが遅い。 **例:** ある多国籍金融サービス会社は、Data 360 をプロビジョニングするための専用の自宅組織を作成します。すべてのビジネスユニット組織 (リテール、ウェルス、コマーシャルバンキング) は、Data Cloud One を介してコンパニオン組織として接続します。 #### 決定条件
考慮事項 在宅組織としての既存の組織 (優先デフォルト) ホーム組織としての新規組織 (代替)
シンプルさ 既存のユーザーとデータ構造に基づいて構築されているため、設定を迅速化できます。Data 360 はデフォルトでホーム組織と統合されています。 新しい Salesforce 組織のライセンスと設定、およびそれを管理するための追加の管理オーバーヘッドが必要です。
Time-to-Value ローカル CRM データの迅速な使用。 傾斜が遅い。インテグレーションが必要。
ガバナンス 既存の組織の基本ガバナンスモデル (既存のユーザーと権限セット) を継承します。組織がすでに中央にある場合は、これで問題ありません。 ガバナンスのための白紙の状態。CoE 主導のモデルに最適です。
コンプライアンス 既存の組織の地域に関連付けられたレジデンシー。 既存の組織から独立した地域を柔軟に選択できます。
Performance ローカル CRM クエリで最高のパフォーマンス。 コンパニオン組織の接続性 (他の組織と同じリージョンかクロスリージョンか) によって異なります。
将来の拡張性 Data Cloud One と組み合わせると適切に機能します。間違った組織が選択されている場合、後で移行するのが困難です。 中立性を考慮して設計された Data Cloud One を使用して簡単に拡張できます。
Cost (コスト) 増分コストを削減。 環境の追加によるオーバーヘッドの増加。
### 1.3 推奨事項 原則として、既存のメジャー組織をホーム組織として使用し、初期作業を最小限に抑えて導入を加速します。長期的なガバナンスまたはコンプライアンス戦略で必要な場合にのみ、新しい専用のホーム組織を作成します。新しい専用の在宅組織を作成することは、Center of Excellence (COE) を使用する大規模企業にとって一般的な選択肢です。 **単一組織環境** 既存の本番組織で Data 360 をプロビジョニングします。これにより、シンプルさと即座の価値が最大限に高まります。不要なインテグレーションのオーバーヘッドを回避できます。 **複数組織環境** ホーム組織として機能させるには、主要な組織 (通常はビジネスの大部分を実行する組織、またはすでに一元化された CRM として機能する組織) のいずれかを選択します。これにより、複雑さが軽減され、設定作業を最小限に抑え、Data 360 の価値をすばやく実感できます。既存の主要組織を使用すると、新しい環境の管理にかかるコストと統合作業も回避できます。 **新しい専用の自宅組織を検討するケース** 組織に強力な Center of Excellence (CoE) があり、ビジネスユニット組織から独立したガバナンスが必要な場合。コンプライアンスや組織の制約のために適切な既存の組織が 1 つもない場合。このような場合、新しい自宅組織を作成すると、柔軟性と中立性が確保されますが、タイム トゥ バリューは遅くなります。 --- ## セクション 2:複数組織戦略と Data Cloud One ### 2.1 複数組織の課題 多くの場合、企業は複数の Salesforce 組織を運用していますが、これはエッジケースではなく、通常のケースです。2024 年 2 月の時点で、約 19,000 人の Salesforce ユーザーがすでに複数の Salesforce 組織を運用しています。 なぜこのようなことが起こるのでしょうか? - **買収と合併：**新しく買収した会社は、独自の Salesforce インスタンスを持ち込みます。 - **地域のオペレーション：**多くの場合、データレジデンシー法を満たすために、EU、北米、アジア太平洋などの組織を分離します。 - **機能の分離：**さまざまなビジネスユニット (Retail Banking、Wealth Management、Insurance など) が、自律性を確保するために独自の組織を維持しています。 - **規制またはセキュリティの分離：**特定の業界では、コンプライアンス上の理由で論理的に区別された組織が義務付けられています。 - **歴史的/技術的な理由:**時間の経過とともに、顧客は複数の組織を有機的に蓄積します。 それぞれの理由は個別に意味を持ちますが、それらが組み合わさってデータが断片化します。統合レイヤーを使用しない場合、各組織には顧客の部分的なビューのみが表示されます。 アーキテクチャの課題:コンプライアンス、ガバナンス、自律性の要件を尊重しながら、組織全体のデータを 1 つの情報源に統合する方法は? --- ### 2.2 Data Cloud One とは? Data Cloud One は、複数の Salesforce 組織で 1 つの Data 360 インスタンスを共有できる Salesforce の複数組織接続アーキテクチャです。これは、複数の Salesforce 組織を使用する企業に推奨されるパターンです。 Data Cloud One クラスターでは、1 つの Salesforce 組織が Data 360 インスタンスをホストするホーム組織として指定されます。他の Salesforce 組織はコンパニオン組織として接続し、ホーム組織の Data 360 の統合データとメタデータを使用します。 Data Cloud One アーキテクチャを示す図 #### Data Cloud One のしくみ
  1. データ取り込みと統合 (自宅組織)
  2. データスペースアーキテクチャ
  3. メタデータ共有
    コンパニオン組織は、DMO(データ モデル オブジェクト)、統合プロファイル スキーマ、計算済みインサイト、セグメントなどのメタデータ定義をホーム組織から受け取ります。これらは、コンパニオン組織内ではローカルアセットのようにネイティブに表示されますが、実際にはホーム組織にリンクされています。
  4. Jobs to Be Done in Home Orgg vs.コンパニオン組織
    5. 機能へのアクセスは、ホーム組織とコンパニオン組織で異なります。コンパニオン組織では、データの取り込みや統合ができず、取り込み、モデリング、統合はホーム組織に依存します。コンパニオン組織は Data 360 データにアクセスして Data 360 プラットフォーム機能を強化し、共有された信頼できるデータの上にローカルインサイト、セグメント、フローを作成できます。将来のビジョンでは、有効化機能にもアクセスできます。
    機能 ホーム組織 コンパニオン組織
    Connect 設定コネクタ、データストリームの作成、データの取り込みまたは統合 ✅ ❌
    調和と統合 データ変換と ID 解決の構築および実行 ✅ ❌
    データスペースと権限によるデータの保護のガバナンス ✅ ✅
    セグメントと予測 セグメント、インサイト、Einstein Studioモデルの構築 ✅ ✅
    Activate Everywhere Activations、データアクション ✅ ✅
    プラットフォーム機能プロンプトビルダー、フロー、レポート、強化など ✅ ✅
    Data 360対応機能 Prospecting Center、Sales CloudおよびService Cloudの機能、Agentforceなど ✅ ✅
  5. プラットフォーム機能パリティ
    ユーザーとビルダーの観点では、メタデータが共有されると、Salesforce Platform 機能の使用に関してホーム組織とコンパニオン組織でいくつかの機能の違いが生じます。サポートされる機能のリストは、「Data 360 Features on Companion Orgs (コンパニオン組織の Data 360 機能)」を参照してください。
  6. 消費モデル
    すべてのコンパニオン組織のアクティビティ(クエリ、セグメントの実行、Data 360トリガー フロー、AIの使用状況、Einstein Trust Layerのログ記録など)では、ホーム組織のData 360クレジットが使用されます。消費は一方向に流れます。クレジットは一元化され、請求され、自宅組織のクレジット割り当てに対して追跡されます。ただし、ドリル ダウンすると、各個人組織が Digital Wallet で使用したクレジット数を確認できます。
  7. 設計原則:横方向の構築
    Data Cloud One は、Sandbox によく似た Salesforce Platform の水平構造として設計されています。目標は、Salesforce がリリースするすべての新機能が、追加の設定なしで自宅組織とコンパニオン組織の両方で機能することです。これにより、Data Cloud One は単なるデータアーキテクチャの選択肢ではなく、今後の Salesforce Platform の基盤要素となります。
--- ### 2.3 決定:複数の独立した Data 360 と1 つの共有データ 360 (Data Cloud One) 複数の組織を持つ企業は、エコシステム内で Data 360 を配置する方法と場所を選択する必要があります。各組織で独立した Data 360 をプロビジョニングするか、Data Cloud One を使用して 1 つの自宅組織で組織を統合しますか? #### オプション A:複数の独立した Data 360 各 Salesforce 組織は、独自の Data 360 インスタンスをプロビジョニングします。 **長所**: - **自治**:各ビジネスユニットまたは地域が独自の Data 360 を制御します。 - 各組織内**のシンプルさ**:ガバナンス、セキュリティ、カスタマイズはローカライズされています。 - **法令順守**:厳格な規制の分離が必要な場合 (データが国境を越えてはならない場合など) に便利です。 **短所**: - **データ サイロ:**Customer 360 は組織全体で実現できません。 - **コストの増加**:各インスタンスには、ライセンス、管理、インテグレーションが必要です。顧客は、複数の異なる組織で完全な C360 ビューを実現するために、同じソースデータを複数回取り込むことになります。 - **重複作業:**各 Data 360 で ID 解決、セグメンテーション、強化を繰り返す必要があります。 #### オプション B:1 つの共有データ 360 (Data Cloud One クラスター) 1 つの Data 360 がホーム組織にプロビジョニングされ、他の Salesforce 組織がコンパニオン組織として接続されます。 **長所**: - **SSOT(Single Source of Truth):**すべての組織で同じ統合データモデルを共有します。 - **コスト効率：**管理する Data 360 ライセンスとインフラストラクチャは 1 つのみです。 - **統合ガバナンス:**ポリシー、セキュリティ、およびコンプライアンス管理が一元的に適用されます。 - **組織間強化：**コンパニオン組織は、ハーモナイズプロファイル、インサイト、セグメントにアクセスできます。 - **AIの準備状況:**企業全体のデータセットにより、AI モデルのトレーニングと有効化を改善できます。 - **将来への対応:**新しいコンパニオン組織の追加は簡単で、新しい Data 360 は必要ありません。 **短所**: - **追加の準備:**組織間接続の計画が必要です。 - **レイテンシに関する考慮事項:**異なる地域のコンパニオン組織では、クエリに時間がかかる場合があります。 - **複雑なガバナンス：**組織ごとにカスタマイズのニーズが大きく異なる場合、きめ細かなガバナンスが複雑になる可能性があります。 #### オプション C:複数の Data Cloud One クラスター 場合によっては、ガバナンス、コンプライアンス、その他のビジネス要件により、すべての組織をクラスター化することが現実的でない場合があります。そのため、企業が複数の Data 360 を運用し、それぞれがコンパニオン組織の異なるクラスターのホーム組織であるハイブリッドソリューションを実装する必要が生じる可能性があります。 #### 例: ある多国籍企業では、ヨーロッパ、米国、アジアなど、さまざまな地域に Salesforce 組織があります。地域のデータレジデンシー規制に準拠するために、地域ごとに 1 つの Data 360 をプロビジョニングします。 #### 決定条件
考慮事項 複数の独立した Data 360 1 つの共有データ 360 (Data Cloud One)
自律 各組織またはビジネスユニットの高い自律性。 一元化されたガバナンス、組織ごとの自律性の低下。
コンプライアンス 厳格な分離が必要な場合 (地域の法律など) に便利です。 レジデンシーで集中管理が許可されている場合に最適です。
Cost (コスト) ライセンスコストと管理コストの増加。 コスト効率が向上。多くの組織で 1 つのライセンスを使用できます。
ガバナンス 断片化。ポリシーは組織によって異なります。 組織全体で一元化された一貫したポリシー。
データサイロ 各組織には独自のビューがあり、Enterprise 360 はありません。 統合されたデータセット (重複なし)。
AI/Analytics 各組織のデータに制限されます。 精度が向上したエンタープライズ規模のモデル。
複雑さ 管理するインスタンスが増え、インテグレーションも増えました。 シンプルなアーキテクチャ、可動部品の削減。
Performance 組織内の使用事例に最適です。 コンパニオン組織へのアクセスで遅延が発生する場合があります。
--- ### 2.4 おすすめ **優先パターン:****Data Cloud One** デフォルトでは、複数組織企業の接続されたコンパニオン組織を含む 1 つの自宅組織になります。 これにより、企業全体のCustomer 360が作成され、ガバナンスがシンプルになり、コストが最適化されます。 **複数の Data 360 を使用する場合:** コンプライアンス、レジデンシー、または組織の自主性によって厳密に要求される場合のみ。たとえば、規制のためにヨーロッパの業務を米国の業務から完全に分離する必要がある場合などです。 **Data Cloud One でホーム組織を選択する方法:** まず、主要な組織 (通常はほとんどのビジネスが実行されている組織) のいずれかを検討します。Data 360 をプロビジョニングすることで、複雑さを最小限に抑え、早期の価値を最大化できます。 適切な既存の組織がない場合のみ、Center of Excellence チームが管理する専用の自宅組織を作成することを検討してください。 **一般原則:** マルチ組織環境では、Data 360 の数を最小限に抑えます。Data Cloud One をデフォルトパターンとして選択すると、重複が減り、AI の準備が有効になり、ガバナンスが簡素化されます。 --- ## セクション 3:複数の Data 360 および Data 360 組織間のデータ共有 ### 3.1 Data 360 組織間のデータ共有とは? Data Cloud One はほとんどの企業にとって推奨される方法ですが、複数の Data 360 インスタンスのプロビジョニングが必要なシナリオもあります。複数の Data 360 が存在すると、それらの統合は自動的に行われません。 Data 360 to Data 360 データ共有により、重複やカスタムパイプラインなしで Data 360 インスタンス間で特定のオブジェクトを共有できます。これは、Data 360 全体でのコラボレーションのために設計されたゼロコピーメタデータ共有メカニズムです。 #### 操作手順 - 各 Data 360 は、独自のホーム組織でプロビジョニングされます。 - 管理者は、共有する特定のオブジェクトのグループであるデータ共有を作成できます。 - 選択したデータへのアクセスは対象組織の Data 360 と共有され、オブジェクトはローカルで定義されたかのように表示されます。基盤となるデータはソース Data 360 に残り、アクセス権のみが共有されます。 - タグは共有されません。使用できるのは未加工オブジェクトのみです。対象組織は、必要に応じてガバナンス、運用、AI タグを再適用する必要があります。 #### Data Cloud One との主な違い - Data Cloud One では、複数のコンパニオン組織が 1 つの Data 360 インスタンスを共有します。プラットフォーム機能(Agentforce、Prospecting Center、Tableau Nextなど)はすべて同じ基礎データで実行され、一貫性が確保されます。 - Data 360 組織間のデータ共有を使用する場合、各組織に独自の Data 360 があります。組織 A と組織 B の Agentforce などの機能は、それぞれローカル インスタンスで独立して動作します。共有は自動的に行われません。特定のオブジェクトに対してのみコラボレーションするには、意図的なデータ共有を作成する必要があります。 --- ### 3.2 Data 360 組織間でのデータ共有の使用事例 **地域のコンプライアンス：** ある多国籍小売業者は、EU と米国の 1 つの Data 360 をプロビジョニングしています。Data 360-to-Data 360 データ共有では、未加工データをローカルに残したまま、米国本社と共有するためのインサイト (ロイヤルティ KPI など) を集計できます。 **ビジネス・ユニットのコラボレーション：** ある複合企業が小売と保険で別々の Data 360 を実行しているとします。Data 360 間のデータ共有により、ユーザーは移動やコピーを行うことなく、1 つの信頼できるデータソースにアクセスできます。Data 360 組織間のデータ共有により、保険組織は対象を絞ったクロスセルキャンペーンで小売の「High Value Customer」セグメントを受け取ります。 **M&A:** 親会社が独自の Data 360 を持つ子会社を買収します。2 つのインスタンスを管理する場合、短期のデータサイロを保持することで、データセキュリティと SSOT の整合性が維持されます。同時に、2 つの Data 360 インスタンス間でデータを共有することで、移行中に必要なコラボレーションが可能になります。 **統合エグゼクティブ・ダッシュボード：** 大陸にまたがる多国籍の広がりでは、地域ごとに個々の Data 360 がプロビジョニングされます。エグゼクティブは、四半期パフォーマンスの統合ビューを求めています。各地域の Data 360 は、集計された計算済みインサイトを「エグゼクティブ組織」と共有し、企業全体のレポートを可能にします。 #### Data 360 組織間でのデータ共有の長所と短所
要素 プラス面 マイナス面
データレジデンシー コラボレーションを可能にしながら、地域の分離をサポートします。 複数の Data 360 を管理する必要はありません。
データの複製 ゼロコピー、オブジェクトの重複なし。 各データ共有に含めるオブジェクトを慎重に選択する必要があります。
ガバナンス 共有は明示的かつ慎重に行われます (オブジェクトレベル)。 タグまたはポリシーフローはありません。対象組織はガバナンスを再適用する必要があります。
複雑さ 一元化なしで選択的なコラボレーションを可能にします。 複数の Data 360 とデータ共有の管理が必要です。
AI/Analytics 地域の AI/分析が可能。インサイトを組織間で共有できます。 データを意図的に共有しない限り、全社的な AI は使用されません。
プラットフォーム機能 各組織の Data 360 対応機能は独立して実行されます。 自動共有なし — 慎重に設計しないと重複のリスクがあります。
Cost (コスト) ETL パイプラインの必要性を減らすことができる。 ただし、複数の Data 360 のコストが発生します。データクエリとデータ共有のクレジットを消費します。
#### 決定条件
考慮事項 Data Cloud One (マルチ組織に推奨) Data 360 組織間でのデータ共有
一元化された情報源 ✅ はい — すべての組織で同じ DC を共有します。 ❌ いいえ — 各 Data 360 には独自のデータモデルがあります。
コンプライアンス レジデンシーで一元化が許可されている場合にのみ機能します。 居住法によって一元化が妨げられている場合に必要です。
ガバナンス 一元化された一貫性。 統合。オブジェクトレベルの共有を意図します。
複雑さ 可動部品が少なく、シンプル。 または複雑 — 設定データ共有と複数の Data 360 が必要です。
AI/Analytics エンタープライズ全体の AI モデル。 地域 AI。インサイトは選択的に共有できます。
プラットフォーム機能 Shared Data 360 では、すべての機能がホームとコンパニオンで一貫して動作します。 機能は Data 360 ごとに独立して実行されます。共有は明示的に行う必要があります。
### 3.3 ベストプラクティス **エンタープライズに複数の Data 360 がある場合:** - カスタムパイプラインを作成したりデータを複製したりするのではなく、Data 360 組織間でデータ共有を使用してコラボレーションします。 - データ共有を作成して対象組織に付与することで、特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。 - タグは共有されないことに注意してください。受け取り側組織はタグ (ガバナンス、分類、AI 強化など) を再適用する必要があります。 **Data 360 組織間のデータ共有を使用する場合:** - 一元化を妨げる規制要件を満たす。 - ビジネスユニットの自律性を維持しながら、選択的なコラボレーションを実現する。 - 複数の地域で統合エグゼクティブダッシュボードを提供する。 - 統合がすぐには実現できない M&A シナリオの橋渡しをします。 **慎重に設計** 共有は意図的でオブジェクト固有である必要があります。「過剰な共有」を避ける — データ共有をビジネスとコンプライアンスのニーズに合わせます。Data 360-to-Data 360 データ共有は、 Data Cloud One の代替戦略としてではなく、統合戦略として扱います。 --- ## サマリー
  1. すべての組織が Data 360 へのアクセスを計画する必要がある
  2. 組織ごとではなく、企業全体で考える
  3. データサイロの最小化
  4. 複数の Data 360 を実行する必要がある場合は慎重に設計してください
  5. ガバナンスと所有権を早期に計画する
  6. 短期的なショートカットの回避
Salesforce Platform は、顧客セグメンテーションから AI エージェントのグラウンディングまで、すべての機能がデータ 360 ファーストモデルに依存するように進化しているため、これらのプロビジョニングの選択は非常に重要です。今日の意思決定により、企業が顧客データをどの程度効果的に統合できるか、新しい Salesforce 機能をどの程度迅速に採用できるか、ビジネス全体で AI をどの程度自信を持って拡張できるかの基盤が構築されます。成功するためには、慎重にプロビジョニングし、重複を最小限に抑え、コンプライアンス要件に準拠し、慎重に管理し、長期的な視点で考える必要があります。最終的に、Data 360 のプロビジョニングは、データ、AI、CRM を 1 つの統合されたプラットフォームとして連携させるための最初のステップです。 # ## 著者について Kunal Goyal は Salesforce の製品管理ディレクターで、Data 360 内のマルチ組織アーキテクチャと拡張性の向上に取り組んでいます。2017年より、組織間コラボレーションとマルチテナントシステム設計を中心に複数のイニシアチブと製品を率いている。Kunal は、Data 360 のベストプラクティスアーキテクチャリードの 1 人で、Data Cloud One、設定、プロビジョニング、管理エクスペリエンスのプロダクト所有者です。 Erin Wagner Tidwell は、Data 360 のプリンシパルテクニカルライターおよびコンテンツデザイナーです。2013 年から Salesforce に勤務。明確で一貫性のある正確な技術ドキュメントとアプリケーション内コミュニケーションを通じて、Data 360 をよりわかりやすく、使いやすくすることに専念しています。 Yugandhar Bora は、Salesforce のソフトウェアエンジニアリングアーキテクトで、Data & Intelligence アプリケーションプラットフォーム内のデータアーキテクチャを専門としています。データガバナンスと統合データモデルに焦点を絞ったエンタープライズアーキテクチャレビューボード (EARB) イニシアチブを主導しながら、自動化プラットフォームプロビジョニングソリューションに貢献しています。 Samarpan Jain は、Commerce Cloud、プラットフォームインテグレーション、組織間アーキテクチャを専門とする Salesforce のプリンシパルアーキテクトです。Salesforce で最も勤続年数が長い従業員の 1 人で、政府機関の顧客向けのデータレジデンシーコンプライアンスや Data 360 利用状況属性システムなどの重要なイニシアチブを主導しています。 # Data 360 決定ガイドの使用開始 このセクションでは、プロビジョニング戦略、複数組織の接続、インテグレーションパターンなど、Salesforce Data 360 に関する重要なアーキテクチャ上の意思決定を行うための実践的な指針を提供します。これらのガイドを使用して、顧客データを統合し、AI を駆使した機能を実現する効果的なデータアーキテクチャを設計および実装します。 --- ## Data 360 プロビジョニング [Data 360 Provisioning](/docs/architect/ja-jp/decision-guides/guide/data-360-provisioning)は、Salesforce Data 360 をプロビジョニングするときの基本的な意思決定を対象とします。 - **Home Org Selection**:ガバナンス、コンプライアンス、タイムトゥバリューを考慮して、既存の本番組織で Data 360 をプロビジョニングするか、専用組織を作成するかを決定します。 - **複数組織戦略**:複数の独立した Data 360 インスタンスを選択するか、Data Cloud One を使用して複数の Salesforce 組織を統合し、自律性、コンプライアンス、コストのバランスを取ります。 - **Data Cloud One アーキテクチャ**:複数のコンパニオン組織で、一元化されたガバナンス、メタデータ共有、および機能パリティを備えた 1 つの Data 360 インスタンスを組織間で共有できるようにします。 - **Data 360 組織間のデータ共有**:地域のコンプライアンス、ビジネスユニットのコラボレーション、統合エグゼクティブダッシュボードのために、独立したインスタンス間でゼロコピーデータ共有を使用します。 - **プロビジョニングに関する考慮事項**:データレジデンシー、ガバナンスモデル、レイテンシ、インテグレーションの複雑さ、コスト、エンタープライズ規模の導入に対する AI の準備状況を考慮します。 Customer 360、AI、クロス プラットフォームのイノベーションのためのシンプルさ、エンタープライズの整合性、コンプライアンス、拡張性を確保するプロビジョニング戦略の設計を支援します。 --- ## Data 360 の相互運用性 [Data 360 Interoperability](/docs/architect/ja-jp/decision-guides/guide/data-360-interoperability) は、Data 360 を外部プラットフォームおよびデータレイクと統合するためのフレームワークを提供します。 - **データ取り込みパターン**:Customer 360、コンプライアンス、一元化されたガバナンスに最適な管理された正規データセットを作成するためのリアルタイム、ストリーミング、一括取り込み。 - **ゼロコピー データ統合**:ライブ クエリ、高速化されたクエリ(キャッシュ)、ファイルフェデレーションの手法により、重複なしで外部システムにリアルタイムでアクセスでき、パーソナライズ、ダッシュボード、AI/ML ワークロードが可能になります。 - **ハイブリッド アプローチ**:コア データセットの管理された取り込みとゼロ コピー統合を組み合わせて、新鮮さと拡張性を実現し、オムニチャネル エンゲージメント、Agentforce 駆動型アクション、エンタープライズ分析をサポートします。 - **決定フレームワーク**:レイテンシ、コスト、拡張性、ガバナンス、複雑さのトレードオフを評価し、データソースごとに適切なインテグレーションパターンを選択します。 - **アーキテクトプレイブック**:金融、医療、小売、通信のシナリオに関する業界固有のガイダンス、設計手法、コストに関する考慮事項。 アーキテクトは、データの新鮮さ、ガバナンス、パイプラインの効率性のバランスを取り、運用ワークロードと分析ワークロードの両方をサポートする、拡張性と相互運用性を備えた AI 対応のデータアーキテクチャを構築できます。 # Integration Decision Guides の使用開始 このセクションでは、Salesforce に適したデータインテグレーションツールとアプローチを選択するための実践的な指針を提供します。アウトバウンドインテグレーション、インバウンドインテグレーション、組織間シナリオを対象としており、アーキテクトはパフォーマンス、メンテナンス性、コストのバランスの取れたデータレイヤーインテグレーションの設計と実装を行うことができます。 --- ## Salesforce とのデータインテグレーション [Salesforce とのデータインテグレーション](/docs/architect/ja-jp/decision-guides/guide/data-integration)では、Salesforce データインテグレーションツールとベストプラクティスの概要を包括的に説明します。 - **インテグレーションツールの状況**:ローコード、ハイブリッド、プロコードのオプションを含む Salesforce データインテグレーションツールの概要と、特定の使用事例に適したツールの選択に関する指針。 - **送信インテグレーション**:Salesforce から外部システムにデータを送信する方法 (変更データキャプチャ、外部サービス、Heroku Connect、OmniStudio Integration Procedure、Salesforce Connect、MuleSoft Anypoint、カスタム Apex ソリューションなど)。 - **受信インテグレーション**:外部データを Salesforce に取り込むためのアプローチ。データレプリケーションと仮想化の比較、および各ツールを使用するタイミングに関するガイダンスがあります。 - **組織間インテグレーション**:MuleSoft Anypoint、Heroku Connect、ネイティブ Salesforce API、変更データキャプチャを使用した Salesforce Connect など、Salesforce 組織間でデータを共有するための推奨方法 (従来の Salesforce-to-Salesforce 実装を置き換えるためのガイダンスを含む)。 - **決定フレームワーク**:既存のツールやランドスケープ、データフローの要件 (タイミング、方向性、予想されるユーザーエクスペリエンス)、実装の複雑さ、メンテナンス性、データ量、プラットフォームの制限など、インテグレーションツールを選択する場合の主要な考慮事項。 アーキテクトはシナリオごとに適切なインテグレーションツールとパターンを選択でき、不要なデータレプリケーションを最小限に抑え、既存の ESB/ETL ソリューションを活用し、エンタープライズアーキテクチャの原則に準拠した拡張性とメンテナンス性に優れたインテグレーションを実現できます。 ## ガイドの概要 このガイドは、Salesforce Platform での非同期処理の要件に適したアプローチを評価するのに役立ちます。各アプローチについて説明し、それぞれの長所と制限事項を詳しく説明します。ほとんどのアプローチは商品機能に沿っていますが、一部のアプローチでは複数の機能を連携して使用します。このガイドには、各アプローチを使用するケースが強調表示されています。 非同期処理には、アーキテクチャにとって 2 つの大きな利点があります。まず、非同期プロセスのガバナ制限が高くなるため、拡張性が向上します。次に、非同期要求は独自のスレッドで実行されるため、ユーザーはバックグラウンドで非同期 ToDo を実行しながら他の作業を実行できます。 このガイドでは、Salesforce Platform 内の非同期処理テクノロジーの選択のみに焦点を当てています。意思決定プロセスに役立つその他のリソースは、\[[リソース] セクション](#リソース)に表示されます。 ## このガイドの対象商品
Salesforce Platform Salesforce Lightning Platformは、従業員、自律型AIエージェント、会社のデータ、アプリケーションを単一の信頼できるシステムに統合し、生産性とカスタマー エクスペリエンスを向上させる包括的なAI駆動型プラットフォームです。Customer 360アプリケーション、Data Cloud、Slackを接続してエンドツーエンドの自動化を実現することで、「エージェント エンタープライズ」の作成を可能にします。
このドキュメントでは、MuleSoft、Informatica、Commerce Cloud、Tableau、Marketing Cloud など、他のエコシステムのテクノロジーは扱っていません。 ## ポイント - **非同期処理を使用する前に、使用事例がパターンに適合していることを確認してください。**非同期パターンには SLA がなく、複数のガバナメカニズムが適用され、ライセンスに基づいて業務量制限が定義されている可能性があります。また、Salesforce Platform 内の非同期インフラストラクチャに割り当てられるリソースの有限性が原因で処理遅延が発生する可能性があります。ユーザーが作業を続行する前にシステムからの応答を必要とするシナリオで非同期処理を使用する場合は、次の制限事項を考慮してください。 - **Salesforce による非同期処理は、無限の拡張ニーズに対応するソリューションではありません。**Salesforce Platform は無限に拡張されず、非同期パターンには制限があります。非同期処理では、CPU が命令ストリームを実行するために必要なコンテキスト情報が含まれるスレッドが使用されます。スレッドは並列で実行できます。どの CPU でも使用可能なスレッド数は限られているため、プラットフォームには使用可能なスレッドをできるだけ効率的に使用するメカニズムがあります。プラットフォームの[フロー制御メカニズム](/docs/architect/ja-jp/fundamentals/guide/async-fundamentals#フロー制御)により、組織が大量のスレッドを消費して他の組織に悪影響が及ぶことを防ぎます。プラットフォームの[適正使用アルゴリズム](/docs/architect/ja-jp/fundamentals/guide/async-fundamentals#公正な使用量)は、組織が特定のメッセージ種別ごとに使用できるスレッドの数も制御します。 - **極端な負荷を引き起こす可能性のあるイベントを考慮します。**非同期プロセスを設計する場合、ワークロードの急増と停滞を予測どおりに管理できることを確認します。実装で停電などの予期しないイベントをどのように処理するかを検討し、データの損失や機能の損失を軽減する保護策を設計します。 ## 商品比較 次の表に、Salesforce での非同期処理に使用できるツールの概要を示します。次の表を参照して、意思決定プロセス中に各ツールの主要な特性を確認してください。アーキテクチャに適したツールの選択については、「[使用事例](#使用事例)と[判断ポイント](#決定ポイント)」を参照してください。
アプローチ 説明 必要なスキル ライセンスと制限
Queueable Apex 実行時間の長いデータベース操作や外部 Web サービスのコールアウトが含まれるプロセスに使用します。Queueable Apex には、ジョブ ID、プリミティブ型以外の種別のサポート、ジョブのチェーンなどの機能があります。 プロコード ライセンス数によって制限が増加する可能性があります。
Apex の一括処理 レコードセットを分割して管理可能なチャンクで処理することで、数百万件のレコードが含まれる複雑で実行時間の長いプロセスを構築します。 プロコード ライセンス数によって制限が増加する可能性があります。
スケジュール済み Apex cron 式で定義されたスケジュールされた時間に Apex を実行します。cron 式を使用して Apex をスケジュールする動作は非同期プロセスですが、基盤となるコードはジョブの開始時に同期して実行されます。 プロコード ライセンス数によって制限が増加する可能性があります。
Apex 継続コールアウト 同期トランザクション コンテキストで実行されている Apex メソッドからコールアウトを実行します。 プロコード いいえ
非同期パス (レコードトリガーフロー) 独自の時間に実行する操作を実行します。フローをトリガーしたレコードに含まれていない関連レコードの値を更新したときに発生する混在 DML エラーを回避します。 ローコード ライセンスの数と種類によって制限が増加する可能性があります。
スケジュール済みパス (確定後フロー) トリガーイベント (レコードの作成、更新、削除など) 後の動的にスケジュールされた時間に実行します。 ローコード ライセンスの数と種類によって制限が増加する可能性があります。
スケジュール済みフロー 指定した時刻と繰り返し頻度 (毎日、毎週、または 1 回) でフローをバックグラウンドで実行し、レコードのバッチに対してアクションを実行します。 ローコード ライセンスの数と種類によって制限が増加する可能性があります。
プラットフォームイベントトリガー Salesforce を外部システムと疎結合し、Salesforce Platform 内の非同期コンポーネント間で通信します。 ローコード + プロコード 大規模プラットフォームイベントの使用事例にはアドオンライセンスが必要
変更データキャプチャ データベーストランザクションがコミットされた後に、変更イベントを非同期で取得して処理します。 プロコード ベースラインの割り当てを超える拡張を行うには、アドオン ライセンスが必要です。
Bulk API 多数のレコードを非同期で挿入、更新、更新/挿入、クエリ、削除し、後で結果を処理します。 プロコード 制限があります。
Lightning アクション Lightning ページで、ユーザーにページの完全な更新を強制せずにサーバーとやりとりできるようにします。 ローコード いいえ
## 決定ポイント 次の表に、使用する非同期ツールを決定するときの考慮事項の概要を示します。
必要なスキル このガイドで説明されているツールには、コードが必要なものと、宣言的に設定できるものがあります。選択肢を検討するときに、チームメンバーのスキルセットについて考えます。最初の実装で (実装パートナーを介して) 開発者が対応可能であっても、将来ソリューションの変更が必要になる場合があります。メンテナンスチームに開発者がいない場合は、ローコードオプションが適しています。
適用されるプラットフォーム制限の種別 実行に適用される制限の種類を決定します。ソリューションを設計するときに、選択したアプローチのガバナ制限にトランザクションの量と頻度がどのように反映されるかを慎重に検討します。毎日実行される実行数を計算します。選択したツールに関連付けられた制限内に計算値が含まれていることを確認します。
遅延 処理の結果をプラットフォームでどの程度迅速に使用できるかを決定します。一部のアプローチでは、変更はほぼ即座に行われますが、別のアプローチでは数分から数時間かかる場合があります。
## 使用事例 非同期処理のツールを選択する場合、まず組織の要件と使用可能なリソースを評価します。目標は、実装コストとメンテナンスコストを最小限に抑えながら、拡張性を確保し、制限違反の可能性を最小限に抑えるツールを選択することです。この目標は、以前に説明した技術的な考慮事項と、チームの構成によって異なります。 Salesforce の非同期注文プロセスについて考えてみます。注文が保存されると、品目の梱包および配送方法に関する特別な指示を含むメッセージが外部倉庫管理システムにトリガーされます。注文を行ったユーザーは、倉庫管理システムからすぐに応答する必要がないため、要求を非同期で送信できます。非同期処理により、ユーザーは応答を待たずに作業を続行できます。 この使用事例では、Apex を使用して実装することを検討してください。この方法は、プロコード・ソリューションを保守できる Apex 開発者がチーム内にいる場合にのみ機能します。それ以外の場合は、宣言型のアプローチがより理にかなっています。また、ツールごとに異なる[制限](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)が適用されます。 次の表は、一般的な使用事例を左端の列にリストし、その後に説明を示します。\[*First Choice (*最初の選択肢)] 列には、このような使用事例を満たすために使用される最も典型的なアプローチと、最初の選択肢アプローチの根拠が表示されます。これを分析の開始点として使用します。最初の選択肢のアプローチでは、使用事例で使用できない制限がある場合があります。
使用事例 説明 First Choice Approach (第一選択肢アプローチ) 根拠
高パフォーマンスのバッチ処理 何千、何百万ものレコードを効率的に処理する必要がある自動化 Batch Apex Batch Apex は、プラットフォームとのインタフェースと未フォーマット時の処理速度を実現する豊富な API を提供します。
データ消去ジョブ データをクリーンアップするために定期的またはオンデマンドで実行されるジョブ。たとえば、重複除外、住所検証、データ統合などがあります。 Batch Apex Batch Apex は、プラットフォームとのインタフェースと未フォーマット時の処理速度を実現する豊富な API を提供します。
夜間積み上げ集計ジョブ 営業日の終わりに積み上げ集計データを計算するジョブ。 Batch Apex Batch Apex は、プラットフォームとのインタフェースと未フォーマット時の処理速度を実現する豊富な API を提供します。
レコードトリガーロジック レコードの更新に応じてロジックを実行します。 不特定 コンパニオン決定ガイド「Record Triggered Events Automation」を参照してください。これには、キュー可能 Apex、バッチ Apex、スケジュール済み Apex、スケジュール済みフロー、非同期パスフロー、変更データキャプチャなどの非同期使用事例のディシジョンツリーが含まれます。
オブジェクトグラフを使用した更新のカスケード ユーザーの保存アクションをすばやく完了し、他のオブジェクトのカスケード更新を非同期で実行できるようにします。 Queueable Apex Queueable Apex には、更新のチェーンを一連の非同期トランザクションに分割するロジックを可能にする強力なチェーン機能があります。
レコード固有のスケジュール済み処理 レコードに固有の将来の動的な日付 (完了予定日の 3 日前など) での自動化。 スケジュール済みパスを使用するフロー スケジュール済みパスは、レコードのデータが変更された場合にプラットフォームが自動的にこれらのパスのスケジュール、キャンセル、再スケジュールを処理するため、フローに独自の強みを提供します。
複数の低速外部サービスの並列呼び出し 同期実行中は、全体的な実行時間を最適化するために複数の外部サービスが並列で呼び出されます。 Apex 継続コールアウト 実行に時間がかかる複数のコールアウトを並列で実行できるようにすることで、作業の完了までの全体的な時間を最小限に抑えます。
外部システムからのレコードのデータ移行 外部システムから大量のレコードを Salesforce Platform に移動します。1 回限りのプロセスまたは定期的なスケジュールプロセス。 Bulk API これは、データ移行の最も効率的で制限の少ない方法です。
外部システムでの追加ロジックの実行 プラットフォームのイベントを外部システムに通知し、そのシステムでイベントを非同期で処理できるようにする、ファイアーアンドフォーゲットパターン。 プラットフォームイベントまたは変更データキャプチャ pub-sub モデルはここで最適に機能し、準備が整ったら外部システムでイベントを処理できます。このパターンについての詳細は、「イベント駆動型アーキテクチャ」を参照してください。
使用事例の表は、各使用事例に最適なアプローチのガイドです。ただし、First Choice テクノロジーが使用事例の特定のニーズにどの程度適合しているかを検証する必要があります。特に、選択したアプローチが組織のガバナ制限に準拠することができるかどうかを判断します。 使用事例のアプローチの候補が特定されたら、『[Asynchronous Processing Fundamentals Guide](/docs/architect/ja-jp/fundamentals/guide/async-fundamentals) (非同期処理の基礎ガイド)』でソリューションを完全に検証できます。 ## リソース 決定プロセスに役立つその他のリソースは次のとおりです。 - 各プラットフォームの非同期テクノロジーについて詳しく説明します。[非同期処理の基礎](/docs/architect/ja-jp/fundamentals/guide/async-fundamentals) - レコード トリガーの Apex またはフローの選択:[レコードトリガーイベントの自動化](/docs/architect/ja-jp/decision-guides/guide/record-triggered) - 非同期インテグレーションパターンに関する情報:[イベント駆動型アーキテクチャ](/docs/architect/ja-jp/decision-guides/guide/event-driven) ## ガイドの概要 Salesforce と外部システム間でデータへのアクセス、同期、共有を行うには、さまざまな方法があります。ただし、すべてのツールが特定のプロジェクトに適しているわけではありません。このガイドでは、Salesforce から入手できるデータインテグレーションツールの概要について説明します。また、特定の使用事例に最も適したツール (またはツールの組み合わせ) の推奨事項や、特定のシナリオで避けるべきツールのガイダンスも提供されます。 この決定ガイドでは、Salesforce に関連するデータレベルのインテグレーションに焦点を当てています。具体的には、次のデータインテグレーションの使用事例について説明します。 - Salesforce から外部システム - Salesforce への外部システム - Salesforce 組織から Salesforce 組織 これらは Salesforce アーキテクトが直面するインテグレーションの課題の一部にすぎません。そのため、イベント駆動型インテグレーションに焦点を絞った意思決定ガイドの追加や、プロセスインテグレーションを使用した効果的な顧客または従業員向けワークフローの構築などを予定しています。最後に、ここで説明するツールやアプローチの多くは、より広範な企業全体のインテグレーションの課題を解決するために使用できますが、そのような使用方法はこのガイドの範囲外です。 ### ポイント - **不要なデータ複製を回避します。**データが Salesforce に絶対的に存在する必要がない限り、代わりに Salesforce Connect を使用したデータの仮想化を検討してください。組織のデータが増加すると、最終的にデータ量が増加し、[パフォーマンス](/docs/architect/ja-jp/well-architected/guide/reliable#performance)に悪影響を及ぼし、技術的な負債が増加する可能性があります。データがすでに Salesforce に存在し、外部システムにある必要がある場合は、絶対に必要でない限り、外部システムにコピーしないでください。代わりに、Salesforce API を使用して外部システムがデータにアクセスできるようにします。 - **MuleSoft またはその他のエンタープライズサービスバス (ESB) または抽出-変換-読み込み (ETL) ソリューション (使用可能な場合) を使用し、既存のランドスケープの一部にします。**これらのツールは、データの移行と変換をサポートするために構築されているため、多くの場合、強力な機能を備えており、企業全体でインテグレーションを再利用し、ガバナンスを強化し、インテグレーションの管理を一元化できます。このガイドでは、MuleSoft Anypoint が推奨されるすべての場所で、既存の ESB/ETL ソリューションで十分かどうかを検討します。 - **Data 360 と Data Cloud One を使用して、さまざまなソースのデータをハーモナイズします。**Customer 360 データ モデル、ID 解決、データ統合、その他の機能によって、Data 360 は Salesforce やその他の外部システムのデータを顧客の統合ビューに統合します。また、[Data Cloud One を](/docs/architect/ja-jp/fundamentals/guide/data360_integration_patterns_and_practices.html#unified-multi-org-data-platform-with-data-cloud-one)使用すると、他の Salesforce 組織のユーザーは、データスペースを介して Data 360 から仮想的に共有されたデータに安全にアクセスできます。 - **Data 360 アクション**と有効化を使用して、組織間でデータを移動します異なる組織から Data 360 にデータが取り込まれたら、データ [アクションとアクティブ](/docs/architect/ja-jp/fundamentals/guide/data360_integration_patterns_and_practices.html#data-activation-patterns--data-outbound)化でデータを別の組織に同期できます。この方法は、Marketing Cloud 組織とのインテグレーションに非常に役立ちます。 - **MuleSoft Anypoint を**使用してデータを抽出および移動します MuleSoft Anypoint を使用して、Connect API とデータグラフ API を使用して Data 360 からデータを抽出し、別の Salesforce 組織に移動できます。Data 360 を使用しない場合、データを Data 360 で複製せずに組織間で移動する必要がある場合にも MuleSoft Anypoint を使用できます。 - **アウトバウンドメッセージングを使用して構築する場合は注意が必要です。**Salesforce は、現在の業務量の範囲内でアウトバウンドメッセージングを引き続きサポートしますが、この技術にさらに投資する予定はありません。 - **「API 限定」プロファイルを使用するインテグレーションユーザーライセンスは、すべてのインテグレーションで常に推奨されます。**また、Salesforce では、すべてのインテグレーションで適切に許可された AuthN および AuthZ パターンとして外部クライアントアプリケーションを使用することをお勧めします (接続アプリケーションまたは SOAP ログインを使用)。 ## データインテグレーションツールの選択に関する一般的な考慮事項 使用可能なデータインテグレーションツールについて説明する前に、ツールを選択するときにいくつかの一般的な考慮事項に留意してください。アーキテクチャによくあることですが、すべてのビジネス課題に明確な答えがあるわけではありません。インテグレーションの選択時に「状況によって異なります」という言葉を口にしている場合は、正しい場所にいます。
考慮すべき領域 よくある質問
既存のツールとランドスケープ 既存の ESB または ETL ソリューションはありますか?関連するデータに規制要件またはコンプライアンス要件がありますか?統合しようとしているシステムはどこにありますか (クラウドまたは社内)?
データフロー (タイミング、予想されるユーザーエクスペリエンス、方向性) データを同期または非同期で移動する必要がありますか? または一括処理/スケジュールできますか?データレプリケーションは必要か?どのようなシステムを情報源とすべきか?データソースは?対象目的地は?ユーザー操作は必要か?ユーザーはインテグレーションの結果を確認する必要がありますか?例外処理 (再試行、通知、失敗) に関するニーズは?システムはどの程度緊密に結合する必要がありますか?
実装 Salesforce 以外のシステムの作業レベルは?インテグレーションの提供を担当するチームは?顧客が好んで使用するツールは?
メンテナンス性 インテグレーションを維持する必要があるチームは?現在どのようなスキルを持っているか?将来どのようなスキルが必要か?経時的な総所有コストは?ローコードツールまたはプロコードツールを使用してテスト、デバッグ、トラブルシューティングを行う能力はどの程度重要ですか?
データ量 インテグレーションに含まれるデータ量は?大規模データボリューム(LDV)を使用する予定がありますか?一括変更の頻度は?シングルトン更新はどのような影響がありますか?発生する頻度は?
制限 データは複雑な変換を行う必要がありますか?複数のソースシステムのデータを結合する必要がありますか?インテグレーションはユーザーごとにどの程度の頻度で行われますか?合計ユーザー数は?一括データ読み込み (新規インスタンスの初期データ読み込みなど) を事前に計画していますか?
## 商品比較 データインテグレーションに使用できるツールの概要と、各オプションの評価を開始する際の考慮事項を次に示します。次のセクションでは、これらのツールの詳細な使用事例と機能の詳細について説明します。
Salesforce から外部システムへ 外部システムから Salesforce へ 実行 必要な追加ライセンス
Apex アクション 利用可 利用可 サーバー側 いいえ
変更データキャプチャ 利用可 利用不可 サーバー側 いいえ*
カスタム Apex (REST および SOAP Web サービス) 利用可 利用可 サーバー側 いいえ
外部サービス 利用可 利用不可 サーバー側 いいえ
Heroku Connect 利用可 利用可 サーバー側 はい
Data 360 利用可 利用可 サーバー側 はい
MuleSoft Anypoint 利用可 利用可 サーバー側 はい
ネイティブSalesforce API 使用不可 利用可 サーバー側 いいえ
OmniScript 利用可 利用可 Client-Side*** はい
OmniStudio インテグレーション手順 利用可 利用可 サーバー側 はい
アウトバウンドメッセージング 理想的ではない 使用不可 サーバー側 いいえ
プラットフォームイベント 利用可 利用可 サーバー側 いいえ**
Salesforce Connect/外部オブジェクト 利用可 利用可 サーバー側 はい
[\*大規模変更データキャプチャイベントの使用事例にはアドオンが必要](https://developer.salesforce.com/docs/atlas.en-us.change_data_capture.meta/change_data_capture/cdc_allocations.htm) [\*\*大規模プラットフォームイベントの使用事例に必要なアドオン](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm) \*\*\*ビジネスロジックを Web ブラウザー内で実行しても問題のない状況に適しています。 列の凡例: - **使用可能**: ほとんどの使用事例で適切に機能 - **理想的でない**: 可能であるが、代替ツールを検討する - **利用不可**: 今後 12 か月以内にサポートする予定はありません ### Salesforce へのデータの出し入れに関与する可能性があるその他のツール: データレイヤーインテグレーションの一部の側面をサポートしているが、インテグレーションの問題を解決する主要な手段であると考えてはならないツールは他にもあります。では、これらのツールを簡単に見てみましょう。 **Lightning Web コンポーネント**は通常、プロセスの統合に使用されますが、JavaScript 機能を使用してコールアウトを行うことができるため、これらのトランザクションにデータが関与する可能性があります。 **Salesforce フロー**を使用して、外部サービスまたは Apex アクションで外部コールアウトを調整できます。Salesforce フロー自体は、スタンドアロンのデータインテグレーションツールとはみなされません。 **データインポートウィザードとデータローダー**を使用して、データを同期、インポート、移行できます。データローダーコマンドは、データのインポートとエクスポートを自動化するためにスクリプトを作成することもできますが、[コマンドラインインターフェース](https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/command_line_intro.htm)は Windows 専用であり、どちらのツールもデータ統合戦略のベースとして推奨されません。代わりに、データスチュワードシップとメンテナンス戦略を補完するために使用します。 [**Salesforce CLI**](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_data.htm) データ コマンドを使用して、組織のレコードを操作できます。Bulk API と SObject Tree Save API を使用してデータをインポートおよびエクスポートし、REST API を使用して個々のレコードに対して簡単な CRUD 操作を実行するのに役立つコマンドを使用できます。Salesforce CLI 自体は、スタンドアロンのデータ統合ツールとはみなされません。 **OmniStudio データマッパー**は、Salesforce オブジェクトと JSON データ構造間でデータを移動するための宣言型 ETL ツールとして使用できます。REST インターフェースはデータマッパーインターフェースごとに自動的に作成され、外部システムから Salesforce オブジェクトにデータを宣言的に移動できますが、データマッパースタンドアロンはデータインテグレーション戦略のベースとして推奨されません。データマッパーアクションは、OmniStudio Integration Procedure で使用できます。 [**Dataloader.io**](http://dataloader.io/) は、MuleSoft の Anypoint Platform を搭載した Salesforce 用のもう 1 つのデータローダーツールであり、企業のデータを無制限にすばやく安全にインポート、エクスポート、削除できます。Dataloader.io は、データインテグレーション戦略のベースとしてはお勧めしません。 ## Salesforce から外部システム (送信インテグレーション) Salesforce からの送信インテグレーションでは、さまざまな種類のツール (ローコード、プロコード、ハイブリッド) を検討できます。次のセクションでは、これらの各ツール種別のガイダンスとサンプルソリューションについて説明します。 - [送信インテグレーション用のローコードツール](#salesforce-からの送信インテグレーション用のローコードツール) - [アウトバウンドインテグレーション用のハイブリッドツール](#salesforce-からの送信インテグレーション用のハイブリッドツール) - [アウトバウンドインテグレーション用の Pro-Code ツール](#salesforce-からの送信インテグレーション用の-pro-code-ツール) ### Salesforce からの送信インテグレーション用のローコードツール
ガイダンス ライセンス タイミング ボリューム & スケール 配送およびメンテナンス プライバシーとセキュリティ
使用するケース 追加ライセンス 同期 (要求/応答) または非同期 (起動/忘れ) 複数オブジェクトのサポート LDV/Bulk テストと導入** デバッグ 組み込みエラー処理/再試行動作 保存データを暗号化して使用 認証プロトコル
変更データキャプチャ Salesforce で行われたレコードレベルの変更を外部システムに公開する必要があり、カスタムペイロードが不要な場合。 必須 非同期 なし なし はい プロコードツールの使用 はい あり OAuth
外部サービス フロー、Apex、Einsteinボット、OmniStudioを使用してプロセスを調整する場合、外部システムAPIはOpenAPI仕様を使用して記述されます。 不要 同期 あり いいえ あり プロコードツールの使用 いいえ なし 指定ログイン情報
Heroku Connect 双方向同期を使用してデータを拡張して Heroku のモバイルアプリケーションや他のアプリケーションを有効にし、データを Salesforce にも複製する場合。 必須 非同期 はい はい 不可 プロコードツールの使用 はい はい、Shield Connect を使用 OAuth
OmniStudio インテグレーション手順 ユーザー操作なしでデータを変換し、ブラウザーではなくサーバーで処理することでパフォーマンスを向上させる必要がある場合。 必須 両方 はい はい はい 宣言型サポート はい はい 指定ログイン情報
Salesforce Connect/外部オブジェクト Salesforce UI にデータを表示し、データを外部システムに保存する場合。データは Salesforce に複製されません。 必須 同期 いいえ はい* はい プロコードツールと宣言型トレーサーを使用 いいえ なし 指定ログイン情報
*バージョン4.01より古いOdataアダプタには、コールアウト制限が適用されます。詳細については、「Odata Callout Rate Limit Considerations(Odataコールアウト レート制限に関する考慮事項)」を参照してください。**テストおよびリリースとは、より低い環境で構築し、メタデータAPI、パッケージ、または変更セットを使用して本番にリリースする機能のことです。
### 使用事例:ローコードツールを使用した送信インテグレーション > 商談が成立したら、関連付けられた商品の注文を会社の ERP システムまたは注文管理システムで作成する必要があります。 **変更データキャプチャ** 商談レコードが更新されると、変更データキャプチャはオブジェクトへの更新を含む変更イベントを公開します。変更イベントは CometD 接続 (または MuleSoft コネクタ) を介して顧客側で消費され、顧客の ERP または注文管理システムの更新に使用されます。外部レコード ID や、インテグレーションに必要なオブジェクト (地域など) の他のデータを常に含めるように変更イベントを強化できます。複数のオブジェクトの変更イベントストリームを*チャネル*に結合することで、登録とストリーム処理を簡略化できます (多数のストリームではなく 1 つのストリームを登録および処理できます)。 **外部サービス** OpenAPI 2.0 または 3.0 仕様をサポートする Web サービスがある場合、Salesforce 内で操作とサービスを外部サービスとして公開できます。API 操作 (注文の作成など) は、商談のフェーズが「成立」に変更されたときに、Flow Builder で作成されたフローの呼び出し可能なアクションとしてコールできます。 **Heroku Connect** Heroku Connect は通常、Heroku Postgres データベースと Salesforce の同期を維持するために使用されます。顧客が Heroku Postgres をソースのトランザクションストアとして使用している場合、Heroku Connect を使用してレコードと変更を Salesforce から Heroku Postgres に同期できます。そこから Heroku ストリーミングコネクタを使用して、これらの変更を Apache Kafka に公開し、ERP や注文管理システムなどのダウンストリームアプリケーションにイベントとして送信できます。 **OmniStudio Integration Procedure** (OmniStudio インテグレーション手順) 注文が送信されると、プロセスを調整する OmniScript で注文の詳細を ERP または MuleSoft コネクタに投稿できます。投稿は、OmniScript (クライアント側) で直接実行することも、Integration Procedure (サーバー側) で間接的に実行することもできます。ERP システムで検証エラーがスローされた場合、OmniScript UI でユーザーに通知し、必要に応じてエラーを翻訳してコンテキスト化する必要があります。 **Salesforce Connect/外部オブジェクト** 商談のフェーズが「成立」に変更されたときに、関連する外部オブジェクトにレコードを挿入するレコードトリガーフローを Salesforce で作成できます。これは[混在トランザクション](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1)であるため、エラーを回避するために、商談の更新と関連外部オブジェクトの挿入の間にゼロ秒の一時停止要素を追加して、新しいトランザクションコンテキストを開始する前に 1 つのトランザクションコンテキストを閉じます。 ### Salesforce からの送信インテグレーション用のハイブリッドツール
ガイダンス ライセンス タイミング ボリューム & スケール 配送およびメンテナンス プライバシーとセキュリティ
使用するケース 追加ライセンス 同期 (要求/応答) または非同期 (起動/忘れ) 複数オブジェクトのサポート LDV/Bulk テストと導入** デバッグ 組み込みエラー処理/再試行動作 保存データを暗号化して使用 認証プロトコル
Apex アクション Salesforce フローを使用して別のシステムへのコールアウトを自動化する場合。開発者は、フローで呼び出すことができる Apex クラスを作成したり、AppExchange から事前作成済みソリューションをダウンロードしたりできます。 不要 両方 あり いいえ あり プロコードツールの使用 いいえ あり 複数
イベントリレー プラットフォームイベントと変更データキャプチャチャイベントを Salesforce から Amazon EventBridge に送信する必要がある場合。イベントリレーは AWS Eventbridge にのみ接続 いいえ 非同期 はい いいえ はい はい はい はい HTTP/1.1 with TLS
アウトバウンドメッセージング ワークフロールールによってトリガーされた受信が保証された、指定されたエンドポイントに HTTP(S) 経由で SOAP メッセージを送信する必要がある場合。 不要 非同期 なし なし はい 宣言型サポート はい あり 双方向 TLS
プラットフォームイベント Salesforce または外部システムでほぼリアルタイムの変更を行うために、カスタム定義の構造化されたペイロードが必要な場合。 必須ではありません* 非同期 はい いいえ はい プロコードツールの使用 はい はい OAuth
Salesforce Connect/外部オブジェクト(カスタムApexアダプタを使用) Salesforce UI にデータを表示するが、Odata や GraphQL などの標準プロトコルを使用できない外部システムにデータを保存する場合。 必須 両方 はい はい はい プロコードツールの使用 いいえ なし 複数
Data 360 1 つのデータストアで異なるソースのデータをハーモナイズする場合、または他の Salesforce 組織や他の外部システムにデータを複製する場合。 必須 両方 はい はい はい はい はい はい 複数
[\*アドオンは](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)、大規模な使用事例で必要です。 \*\*テストおよびリリースとは、より低い環境で構築し、[メタデータ API](https://developer.salesforce.com/docs/metadata-coverage/)、パッケージ、または変更セットを使用して本番環境にリリースする機能を指します。 ### 使用事例:ハイブリッドツールを使用した送信インテグレーション > 商談が成立したら、関連付けられた商品の注文を会社の ERP または注文管理システムで作成する必要があります。 **Apex アクション** 商談の状態に基づくレコードトリガーフローは、商談が成立したときに自動的にトリガーできます。フローは、外部コールアウトを使用して注文を注文管理システムまたは ERP ソリューションに送信する呼び出し可能なアクションを実行します。大量送信とマルチサイト注文は、Apex バッチおよびキュー・メカニズムによって処理されます。 **送信メッセージング** [送信メッセージングを設定](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_om_outboundmessaging_setting_up.htm)したら、リスナーをホストする指定されたエンドポイント URL に HTTP(S) で SOAP メッセージを送信するように、商談の更新によってトリガーされるワークフロールールを定義できます。メッセージには、アウトバウンドメッセージの作成時に指定した項目が含まれます。通知がキューに入れられた後、送信される前にオブジェクトの情報が変更された場合、更新された情報のみが配信され、メッセージは正常に送信されるまで、または 24 時間が経過するまでキューに残ります。24 時間を過ぎると、メッセージがキューから削除されます。ERP システムで追加データが必要な場合は、外部システムでコールバック要求を実行できるように、送信メッセージで sessionId を渡すことができます。 **プラットフォームイベント** 外部システムでレコードを作成するために必要なデータを含むカスタムペイロードを含むプラットフォームイベントを定義できます。プラットフォーム イベントはレコードの変更時に自動公開されないため、商談のフェーズが「成立」に変更された場合は、Apex、Salesforce Flow、または Process Builder を使用してイベントを公開する必要があります。外部サービスは CometD (または MuleSoft コネクタ) を使用してプラットフォームイベントチャネルをリスンし、外部システムに適切なレコードを作成します。 **Salesforce Connect/外部オブジェクト(カスタム Apex アダプタを使用)** Salesforce Connect/外部オブジェクトに基づくソリューションは、純粋にデータ同期を必要とする使用事例に完全には適していません。ただし、このソリューションは、Salesforce 内のユーザーが外部システムのデータを表示して操作する必要があり、Salesforce でデータを複製できない場合に適用できます。ERP または注文管理システムで Odata または GraphQL プロトコルがサポートされていない場合、開発チームは[Apex コネクタ・](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_connector_start.htm)フレームワークを使用して、サポートされているプロトコルを介した外部システムとの通信を処理する Apex クラスを記述できます。 **Data 360** Data 360 に基づくソリューションは、1 つのデータストアでさまざまなソースのハーモナイズデータを必要とする使用事例に最適です。また、Data 360 をデータハブとして使用して、1 つの Salesforce 組織から複数の Salesforce 組織または他の外部システムにデータを複製する必要がある場合にも使用できます。ソース組織で商談が成立して更新されると、商談データは Data 360 に同期され、アクション、有効化、API などの異なるメカニズムを使用して、Salesforce 組織を含む他のシステムに複製できます。同様に、Data Cloud One を使用して他の Salesforce 組織でデータを複製することなく商談を参照できます。ただし、Data Cloud One では Salesforce 以外のプラットフォームはサポートされていません。 ### Salesforce からの送信インテグレーション用の Pro-Code ツール
ガイダンス ライセンス タイミング ボリューム & スケール 配送およびメンテナンス プライバシーとセキュリティ
使用するケース 追加ライセンス 同期 (要求/応答) または非同期 (起動/忘れ) 複数オブジェクトのサポート LDV/Bulk テストと導入** デバッグ 組み込みエラー処理/再試行動作 保存データを暗号化して使用 認証プロトコル
カスタムApex ローコードツールで使用できない機能が必要な場合。 不要 両方 はい はい あり プロコードツールの使用 いいえ はい* 複数
外部サービス コードから外部システム API へのインテグレーションは、OpenAPI 仕様を使用して記述されます。 不要 同期 あり いいえ はい プロコードツールの使用 いいえ なし 複数
MuleSoft Anypoint インテグレーションを構築、オーケストレーション、管理するために単一のエンタープライズクラスの統合ソリューションが必要な場合、従来のポイントツーポイントアーキテクチャを置き換える必要がある場合、API 管理サポートが必要な場合。 必須 両方 はい はい はい プロコードツールの使用 いいえ はい* 複数
\*Shield Platform Encryption を有効にすると、特定の動作が変更されます。詳細については、「[General Shield Platform Encryption Considerations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)」を参照してください。 \*\*テストおよびリリースとは、より低い環境で構築し、[メタデータ API](https://developer.salesforce.com/docs/metadata-coverage/)、パッケージ、または変更セットを使用して本番環境にリリースする機能を指します。 ### 使用事例:プロコードツールを使用した送信インテグレーション > 商談が成立したら、関連付けられた商品の注文を会社の ERP または注文管理システムで作成する必要があります。 **カスタム Apex**商談のフェーズが「成立」に変更されたときに ERP または注文管理システムへのコールアウトを実行する商談の Apex トリガーとトリガー ハンドラを作成できます。トリガーから、または DML 操作の実行後にコールアウトを行う場合は、future または queueable というアノテーションが付けられたメソッドを使用する必要があります。トリガーのコールアウトでは、コールアウトの有効期間の間、データベース接続がオープンのままになります。すべての Apex コードは、[Apex ガバナおよび API 制限](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_overview.htm)に従っており、継続的に改訂されます。 **外部サービス** OpenAPI 仕様を使用して会社の外部 ERP または注文管理システムが定義されている場合、Future メソッドまたはキュー可能ジョブで実行されるこれらのサービスへのコールアウトが簡略化される可能性があります。登録済みの外部サービスは、ボイラープレートコードを記述することなく Apex から直接コールできます。この例では、注文を作成するためのコールアウトを外部サービスで処理できます。 **MuleSoft Anypoint** MuleSoft Anypoint は、エンタープライズクラスの API 管理を提供します。MuleSoft Anypoint では、Salesforce や他の多くのエンタープライズシステムのデータへの参照 (および/または更新) アクセスを可能にする API を作成できます。実装を簡略化するために[多数の事前](https://www.mulesoft.com/platform/cloud-connectors)作成済みコネクタが用意されています。また、会社は独自のコネクタを作成して公開することもできます。これらの API は、柔軟なセキュリティポリシーを使用して Anypoint にリリースでき、一元管理とガバナンスをサポートします。API がピーク利用率 (vCore で測定) に合わせて適切にサイジングされている限り、トランザクション量に制限はありません。 ## Salesforce への外部システムデータ (受信インテグレーション) Salesforce への受信インテグレーションでは、さまざまな種類のツール (ローコード、プロコード、ハイブリッド) を検討できます。次のセクションでは、これらの各ツール種別のガイダンスとサンプルソリューションについて説明します。 - [受信インテグレーション用のローコードツール](#salesforce-への受信インテグレーション用のローコードツール) - [受信インテグレーション用のハイブリッドツール](#salesforce-への受信インテグレーション用のハイブリッドツール) - [受信インテグレーション用の Pro-Code ツール](#salesforce-への受信インテグレーションのプロコードツール) ### Salesforce への受信インテグレーション用のローコードツール
ガイダンス ライセンス タイミング ボリューム & スケール 配送およびメンテナンス プライバシーとセキュリティ
使用するケース 追加ライセンス 同期 (要求/返信) または非同期 (起動/忘れ) 複数オブジェクトのサポート LDV/Bulk テストと導入* デバッグ 組み込みエラー処理/再試行動作 保存データを暗号化して使用可能 認証プロトコル
Heroku Connect 双方向同期を使用してデータを拡張して Heroku のモバイルアプリケーションや他のアプリケーションを有効にし、データを Salesforce にも複製する場合。 必須 非同期 はい はい 不可 プロコードツールの使用 はい はい、Shield Connect を使用 OAuth
OmniStudio インテグレーション手順 ユーザー操作なしでサードパーティソースからデータをインポートおよび変換する必要がある場合。 必須 両方 あり あり あり 宣言型サポート いいえ はい 指定ログイン情報
Salesforce Connect/外部オブジェクト Salesforce UI にデータを表示するが、データを Odata や GraphQL などの標準プロトコルを使用できる外部システムに保存する場合。 必須 同期 はい はい はい プロコードツールの使用 いいえ なし 複数
\*テストおよびリリースとは、より低い環境で構築し、[メタデータ API](https://developer.salesforce.com/docs/metadata-coverage/)、パッケージ、または変更セットを使用して本番環境にリリースする機能を指します。 ### 使用事例:ローコードツールを使用した受信インテグレーション > 組織の ERP システムで取引先責任者が更新されている。この連絡先情報は Salesforce で更新する必要があります。 **Heroku Connect** Heroku Connect は通常、Heroku Postgres データベースと Salesforce の同期を維持するために使用されます。ERP システムでトランザクションストアとして Heroku Postgres を使用していない限り、この使用事例は使用できません。Heroku Postgres を使用している場合、Postgres テーブルで行われた変更を Heroku Connect を使用して Salesforce のオブジェクトに同期できます。 **OmniStudio Integration Procedure** (OmniStudio インテグレーション手順) ERP システムで取引先責任者レコードが更新されたら、データマッパーで生成された REST API を使用して、データマッパーの読み込みアクションと応答アクションを含む OmniStudio Integration Procedure をコールできます。まず、データマッパーの読み込みアクションで JSON または XML ペイロードが送信されます。このペイロードは、外部 ID 項目に基づいて、または[更新/挿入キー](https://trailhead.salesforce.com/content/learn/modules/omnistudio-data-tools-and-internal-data/build-an-integration-procedure-with-conditional-dataraptor-loads?trail_id=build-guided-experiences-with-omnistudio)を介して取引先責任者レコードを更新/挿入するために使用されます。JSON での単純な応答のみが予想される場合、応答アクションは以前のアクションから関連情報を返し、成功または失敗を示すことができます。ERP システムで特定の応答が予期される場合、データマッパーの変換または抽出アクションを使用して、取引先責任者レコードの更新によってトリガーで生成されたデータを宣言的に含む追加機能を含む JSON または XML 応答を生成できます。このシナリオの主な課題は、同時実行です。API が Salesforce に直接存在するため、同じ取引先責任者レコードを同時に更新するために複数回コールすると、問題が発生します。 **Salesforce Connect/外部オブジェクト** Salesforce Connect および外部オブジェクトは、この使用事例ではお勧めしません。これは、このシナリオでは特に Salesforce でのデータ レプリケーションが必要になるためです。ERP に既存の Salesforce Connect インテグレーションが組み込まれている場合、ERP で変更データデータキャプチャをサポートできれば、外部変更データキャプチャをサポートするように Odata 4.0 コネクタを設定できます。さらに、Salesforce で Pub/Sub API を使用して ERP から変更ストリームを登録するように設定する必要があります。 ### Salesforce への受信インテグレーション用のハイブリッドツール
ガイダンス ライセンス タイミング ボリューム & スケール 配送およびメンテナンス プライバシーとセキュリティ
使用するケース 追加ライセンス 同期 (要求/返信) または非同期 (起動/忘れ) 複数オブジェクトのサポート LDV/Bulk テストと導入** デバッグ 組み込みエラー処理/再試行動作 保存データを暗号化して使用可能 認証プロトコル
プラットフォームイベント Salesforce または外部システムでほぼリアルタイムの変更を行うために、カスタム定義の構造化されたペイロードが必要な場合。 必須ではありません* 非同期 はい いいえ はい プロコードツールの使用 はい はい OAuth
Salesforce Connect/外部オブジェクト(カスタムApexアダプタを使用) Salesforce UI にデータを表示する必要があるが、Odata 2.0/4.0 プロトコルを使用できない外部システムにデータを保存する場合。 必須 両方 はい はい はい プロコードツールの使用 いいえ なし 複数
Data 360 1 つのデータストアで異なるソースのデータをハーモナイズする場合、または他の Salesforce 組織や他の外部システムにデータを複製する場合。Data 360 では、一部のプラットフォームで仮想化もサポートされています。 必須 両方 はい はい はい いいえ はい はい 複数
\*大規模な使用事例には[アドオンが](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)必要です。 \*\*テストおよびリリースとは、より低い環境で構築し、[メタデータ API](https://developer.salesforce.com/docs/metadata-coverage/)、パッケージ、または変更セットを使用して本番環境にリリースする機能を指します。 ### 使用事例:ハイブリッドツールを使用した受信インテグレーション > 組織の ERP システムで取引先責任者が更新されている。この連絡先情報は Salesforce で更新する必要があります。 **プラットフォームイベント** 外部システムのカスタムコードは、ERP で取引先責任者レコードが更新されたときにプラットフォームイベントを公開します。Salesforce のトリガー、プロセス、またはフローは、プラットフォームイベントに登録し、イベントが処理されたときに対応する Salesforce オブジェクトを更新できます。プラットフォームイベントは、データが含まれていない顧客の ERP システムに変更が発生したことを示す単なるシグナルとして機能する場合もあれば、Salesforce オブジェクトの更新に必要な実際のデータが含まれる場合もあります。 **Salesforce Connect/外部オブジェクト(カスタム Apex アダプタを使用)** このソリューションは、データ レプリケーションが必要な使用事例には適用されません。このソリューションは、Salesforce で複製できない、または複製できない外部システムの情報を Salesforce のユーザーが表示する必要があり、外部システムで Odata や GraphQL などの標準プロトコルをサポートできない場合に適用されます。「[使用事例:「ハイブリッド ツール](#使用事例ハイブリッドツールを使用した送信インテグレーション)を使用した送信インテグレーション」の Apex カスタム アダプタの使用事例を参照してください。 **Data 360** ERP などの外部システムで取引先責任者を更新する場合、すぐに使用できるコネクタを使用するか、MuleSoft などの API とプロコードツールを使用して、取引先責任者の更新を Data 360 に同期できます。取引先責任者は、ゼロコピーメカニズム (一部のプラットフォームで使用可能) を使用して Data 360 で参照することもできます。Data 360 でデータが使用できるようになると、データを他の Salesforce 組織に同期するためにさまざまな標準インテグレーションメカニズムを使用できます。データは、Data Cloud One を使用して参照でアクセスできます。有効化や他の API を使用して標準のコネクタを使用するか、MuleSoft Anypoint プラットフォームなどのプロコードツールを使用してデータを複製することもできます。 ### Salesforce への受信インテグレーションのプロコードツール
ガイダンス ライセンス タイミング ボリューム & スケール 配送およびメンテナンス プライバシーとセキュリティ
使用するケース 追加ライセンス 同期 (要求/返信) または非同期 (起動/忘れ) 複数オブジェクトのサポート LDV/Bulk テストと導入**** デバッグ 組み込みエラー処理/再試行動作 保存データを暗号化して使用可能 認証プロトコル
カスタム Apex REST および SOAP Web サービス クロスオブジェクト処理やその他の複雑なロジックなど、ネイティブ API エンドポイントで提供される以上の機能が必要な場合。 不要 両方 はい はい はい プロコードツールの使用 いいえ はい*** 複数
MuleSoft Anypoint インテグレーションを構築、オーケストレーション、管理するために単一のエンタープライズクラスの統合ソリューションが必要な場合、従来のポイントツーポイントアーキテクチャを置き換える必要がある場合、API 管理サポートが必要な場合。 必須 両方 はい はい はい プロコードツールの使用 いいえ はい*** 複数
ネイティブSalesforce API REST API、SOAP API、Bulk API、GraphQL API、または gRPC を使用してインテグレーションを構築するために、より詳細な制御が必要な場合や、プロコードスキルセットがある場合。 必須ではありません* 両方 はい***** はい はい プロコードツールの使用 はい** はい*** 複数
\*[API 要求制限](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_api.htm)および割り当てが適用されます。 \*\*Bulk API には再試行動作の側面があり、多くの API で allOrNone 設定による*ロールバック*保護が提供されています (たとえば、「複合要求およびコレクション要求の [allOrNone パラメーター](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/resources_composite_allornone.htm)」を参照)。 \*\*\*Shield Platform Encryption を有効にすると、特定の動作が変更されます。詳細については、「[General Shield Platform Encryption Considerations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)」を参照してください。 \*\*\*\*テストおよびリリースとは、より低い環境で構築し、[メタデータ API](https://developer.salesforce.com/docs/metadata-coverage/)、パッケージ、または変更セットを使用して本番環境にリリースする機能を指します。 \*\*\*\*\*複合 API では、複数オブジェクトがサポートされます。 ### 使用事例:プロコードツールを使用した受信インテグレーション > 組織の ERP システムで取引先責任者が更新されている。この連絡先情報は Salesforce で更新する必要があります。 **カスタム Apex REST および** SOAP Web サービス取引先責任者オブジェクトに対して CRUD (作成、参照、更新、削除) 操作を実行する Web サービスを Apex コードを使用して作成できます。このサービスは、外部システム (ERP) から SOAP または REST を介して呼び出されます。 **MuleSoft Anypoint** MuleSoft Anypoint の目的は、エンタープライズクラスの API 管理を提供することです。MuleSoft Anypoint には、SAP、Oracle EBS、Oracle ERP、NetSuite などの多くの ERP システムと統合するために使用できる[事前作成済みコネクタ](https://www.mulesoft.com/platform/cloud-connectors)が多数用意されています。これらの ERP システムでイベントをリスンするフローを作成できます (この場合は、新しい取引先責任者が作成されたとき)。フローが開始されると、Salesforce コネクタを使用して新しい取引先責任者レコードが作成されます (取引先責任者がすでに存在する場合は更新します)。また、レプリケーショントランザクションで取引先責任者を他のシステムにシンジケートする必要がある場合は、他のシステムと統合できます。必要に応じて、対応付けおよび変換言語 (DataWeave) を使用して、複数の異なるシステムの情報フローとして複雑なロジックと計算を実行できます。これらのシステムに対する認証は、基本認証や OAuth など、さまざまな認証メカニズムで実行できます。ピーク時の使用率 (vCores で測定) に合わせてフローが適切にサイジングされている限り、トランザクション量に制限はありません。 **ネイティブ Salesforce API** ERP システムでの更新トランザクションの完了時 (または完了直後) に、SOAP API を使用して取引先責任者オブジェクトに対して更新/挿入操作を実行したり、Salesforce 組織の取引先責任者 sObjects REST API に対して [PATCH](https://developer.salesforce.com/docs/atlas.en-us.api_rest.meta/api_rest/dome_update_fields.htm) を実行したりできます。 ## Salesforce to Salesforce インテグレーション Salesforce to Salesforce 製品のサポート終了。Salesforce to Salesforce により、パートナーが協力して共通の顧客に販売およびサポートすることが簡単になりましたが、Salesforce では他のツールにさらなる革新をもたらすために投資していきます。今後、Salesforce 組織間でデータを共有するには、次の方法をお勧めします。 ### Salesforce 組織全体のデータインテグレーション用ツール
ガイダンス Cost (コスト) タイミング ボリューム & スケール 配送およびメンテナンス プライバシーとセキュリティ 実装するツール
使用するケース 追加ライセンス 同期 (要求/応答) または非同期 (起動/忘れ) 複数オブジェクトのサポート LDV/Bulk テストと導入* デバッグ 組み込みエラー処理/再試行動作 保存データを暗号化して使用 認証プロトコル ローコード → プロコード
Heroku Connect Salesforce 組織間で双方向同期を使用してデータを拡張し、Heroku で実行されているモバイルアプリケーションやその他のアプリケーションからのデータへのアクセスも有効にする場合 必須 非同期 はい はい いいえ プロコードツールの使用 はい はい、Shield Connect を使用 OAuth ローコード
MuleSoft Anypoint インテグレーションを構築、オーケストレーション、管理するために単一のエンタープライズクラスの統合ソリューションが必要な場合、従来のポイントツーポイントアーキテクチャを置き換える必要がある場合、API 管理サポートが必要な場合 必須 両方 はい はい はい プロコードツールの使用 いいえ はい** 複数 プロコード
ネイティブSalesforce API Salesforce または Heroku Connect が使用できない場合や、より複雑な処理が必要な場合 不要 両方 いいえ あり あり プロコードツールの使用 なし はい** 複数 プロコード
変更データキャプチャ Salesforce で行われたレコードレベルの変更を外部システムに公開する必要があり、カスタムペイロードが不要な場合。 必須 非同期 なし なし はい プロコードツールの使用 はい はい OAuth
Salesforce Connect with Cross-Org Adapter (組織間アダプタを使用した Salesforce Connect) ある組織のユーザーがデータ複製を使用せずに別の組織のレコードを表示または編集できるようにする場合 必須 非同期 はい はい はい プロコードツールの使用 なし なし 複数 ローコード
Data 360 ある組織のユーザーが、Data 360 で複製されたデータを使用して別の組織のレコードを表示または編集できるようにする場合。 必須 両方 はい はい はい プロコードツールの使用 はい はい 複数 ハイブリッド
\*テストおよびリリースとは、より低い環境で構築し、[メタデータ API](https://developer.salesforce.com/docs/metadata-coverage/)、パッケージ、または変更セットを使用して本番環境にリリースする機能を指します。 \*\*Shield Platform Encryption を有効にすると、特定の動作が変更されます。詳細については、「[General Shield Platform Encryption Considerations](https://help.salesforce.com/articleView?id=sf.security_pe_considerations_general.htm&type=5)」を参照してください。 _プラットフォームイベントは、ある Salesforce 組織から別の組織へのデータの統合には最適ではありません。同じイベントを組織間で「リスン」できないためです。カスタム Apex も、このタイプのインテグレーションにはお勧めしません。_ ### 使用事例:複数の Salesforce 組織の接続 > 大企業は複数のビジネスユニット (BU) にまたがって事業を展開しています。各 BU には独自の Salesforce 組織があります。1 人の顧客が企業の複数のビジネスユニットを処理するため、取引先データと商談データが複数の組織に存在するとします。企業は、1 つの組織のすべての BU のすべての取引先および商談データの集計ビューにアクセスする必要があります。 _注:以下のすべてのソリューションは、[ポイント No.1](#ポイント)に従って、データ レプリケーションの量を最小限に抑えるように設計されています。_ さまざまな Salesforce 組織の**Data 360**取引先および商談データは、標準の Salesforce コネクタを使用して Data 360 に取り込むことができます。必要に応じて集計およびハーモナイズすることもできます。Data 360 でデータが集計されると、データレプリケーションなしで Data Cloud One を使用して他の Salesforce 組織からアクセスできます。 **Heroku Connect** 各 BU の個々の組織で、Heroku Connect を使用して Salesforce からの変更を 1 つの Heroku Postgres データベースに同期できます。このシナリオでは、双方向同期は有効になっておらず、Salesforce から Postgres への同期のみが有効になっています。次に、Heroku Connect で Odata プロバイダーを有効にし、集計ビューが必要な Salesforce 組織の外部オブジェクトとして公開するテーブルを選択できます。Salesforce 内から、Heroku の Odata プロバイダーを参照する外部データソースを定義します。 **MuleSoft Anypoint** MuleSoft Anypoint は、エンタープライズクラスの API 管理を提供します。MuleSoft Anypoint API は、組織への複数の接続がある Salesforce コネクタを使用して複数の関連する Salesforce 組織から情報を読み取るように設定できます。MuleSoft フローでは、さまざまな Salesforce 組織を照会し、必要に応じて他のサードパーティ情報で強化または強化した特定の構造を返すことができます。API が呼び出されると、すべての適切な Salesforce 組織のコールアウト (この例では取引先と商談の情報を照会) が実行され、コンシューマーがデータを処理できるようになります (UI の可能性が高い)。これらのシステムに対する認証は、基本認証や OAuth などのさまざまな認証メカニズムを介して行うことができます。ピーク時の使用率 (vCore またはコアで測定) に合わせてフローが適切にサイジングされている限り、トランザクション量に制限はありません。 **ネイティブの Salesforce API**クエリ操作は、特に数千件のレコードを効率的に抽出するのに適した Salesforce Bulk API 2.0 を使用して、関心のある各組織に発行できます。各組織からクエリ結果を個別に取得し、顧客の要件ごとにカスタムアプリケーションまたはミドルウェアで集計できます。 **Salesforce Connect with** Cross-Org Adapter Salesforce Connect Cross-Org Adapter は、リモート組織の取引先または商談がすべて*異なる*オブジェクトとして中央組織に表示されるため、このシナリオには適していません。たとえば、すべての組織のすべての商談の \[金額] の総計を合計する方法はありません。 **組織間の選択的な更新のシナリオ:**Salesforce 組織 A を使用する営業担当は、組織 A で作業している間に、Salesforce 組織 B のケースデータを表示および更新し、Salesforce 組織 B の親ケースにケースコメントを追加する必要があります。データを組織 A に複製することはできません。 **Heroku Connect** では、上記の「_データ集計シナリオ_」で説明した方法と同じ方法を使用できます。ただし、Odata コネクタを介して外部オブジェクトの CRUD を有効にし、変更を Heroku Postgres に書き戻す必要があります。 **MuleSoft Anypoint** MuleSoft Anypoint は、エンタープライズクラスの API 管理を提供します。上記の*データ集計シナリオ*で説明した方法と同じ方法を使用できます。 **ネイティブ Salesforce API**は指定ログイン情報を使用し、ネイティブ Salesforce API を呼び出して、関連する Salesforce 組織のデータを参照および更新します。コンポーネントは、データを表示するように設計する必要があります。 **Salesforce Connect with** Cross-Org Adapter 外部オブジェクトのデータを表示する (および外部オブジェクトで CRUD を有効にしている場合はデータを編集) 機能は、[Salesforce 組織間アダプタ](https://help.salesforce.com/articleView?id=sf.xorg_adapter_about.htm&type=5)を介してサポートされます。外部オブジェクト間のリレーションもサポートされるため、外部オブジェクトの親ケースにリンクできます。ただし、リレーションの作成は、既存のデータ型をリレーションデータ型に変換する手動プロセスです。さらに、ケースをより効果的に操作するために Service Cloud 内で行った最適化は、リモート組織にカスケードされません。Salesforce では、組織間アダプターをテストし、使用事例に応じて外部オブジェクトと標準オブジェクトの使用のトレードオフを評価することを強くお勧めします。 **データ同期の組織間**:組織のビジネスユニットの 1 つである Salesforce 組織で顧客の取引先を更新する場合、一貫した取引先情報を維持するために他の Salesforce 組織の取引先オブジェクトを更新する必要があります。 **Data 360** Data 360 は、ある組織から別の Salesforce 組織へのデータ レプリケーションに使用できます。1 つの Salesforce 組織の取引先データは、標準の Salesforce コネクタを使用して Data 360 に取り込むことができます。一括有効化、ほぼリアルタイムのデータアクション、API ベースの有効化などのデータ有効化メカニズムを使用して、データを Data 360 から Salesforce 組織に移行することもできます。 **Heroku Connect** では、上記の「_データ集計シナリオ_」で説明した方法と同じ方法を使用できます。ただし、双方向同期を有効にする必要があります。また、双方向同期により、Postgres テーブルが変更されたときにすべての組織を最新の状態に維持できるため、Salesforce Connect を有効にする必要はなくなりました。 **MuleSoft Anypoint** MuleSoft Anypoint は、エンタープライズクラスの API 管理を提供します。MuleSoft Anypoint のフローデザイナーを使用して、Salesforce で自動起動フローを起動する標準およびカスタムオブジェクトイベントをリスンするように Mule [アプリケーションを設定](https://docs.mulesoft.com/design-center/about-designing-a-mule-application)できます。Mule アプリケーションがトリガーされると、Salesforce の Anypoint Connector を呼び出して任意の数の Salesforce 組織と通信できます。この使用事例では、1 つの Salesforce 組織で取引先レコードが更新されると、Mule アプリケーションは関連する Salesforce 組織の取引先レコードを更新できます。関連する各 Salesforce 組織には、MuleSoft の全体的なアプリケーションフローに組み込まれた一意の更新ステップがあります。これらのシステムに対する認証は、基本認証や OAuth などのさまざまな認証メカニズムを介して実行できます。ピーク時の使用率 (vCore またはコアで測定) に合わせてフローが適切にサイジングされている限り、トランザクション量に制限はありません。 **ネイティブ Salesforce API** [レプリケーション API](https://developer.salesforce.com/docs/atlas.en-us.api.meta/api/sforce_api_guidelines_datareplication.htm)(getUpdated、getDeleted 操作)を使用して組織間でデータを同期できますが、この方法はお勧めしません。 **Salesforce Connect with** Cross-Org Adapter レコードトリガーフローと外部オブジェクトを使用して、Salesforce 組織間で一部のデータの同期を維持できます。たとえば、組織 A の取引先レコードを更新すると、取引先外部オブジェクトの一致するレコードを更新するフローがトリガーされ、取引先外部オブジェクトはそれらの更新を組織 B の取引先レコードに書き込みます。これには、[混合 DML トランザクション](https://help.salesforce.com/articleView?id=000328873&type=1&mode=1)を回避するためにフローセマンティクスを適切に使用する必要があります。また、組織 B の入力規則とフローは、REST/SOAP API によって変更が行われた場合と同じようにトリガーされます。 ## 完了の挨拶 このガイドは、Salesforce に関連する新しいデータインテグレーションを計画するときに参照してください。使用可能なオプションの全容と、特定の使用事例にどのように適合するかを把握することをお勧めします。 ### ご意見をお聞かせください お客様に最も関連性の高い記事が公開されるようにしてください。[アンケートに回答](https://sfdc.co/J0cWb)して、このコンテンツに関するフィードバックを提供し、次に何を表示するかお知らせください。 # イベント駆動型アーキテクチャに適したツールとパターンの使用 ## 概要 イベント駆動型アーキテクチャでは、システムまたはアプリケーションの状態の変更を伝えるイベントの効率的な生産と消費がサポートされます。これらのアーキテクチャにより、システム間の柔軟な接続が可能になり、システム全体で動作するプロセスとほぼリアルタイムの更新がサポートされます。イベント駆動型アーキテクチャの利点は簡単にわかりますが、実装の詳細は必ずしも明確ではありません。イベント駆動型アーキテクチャパターンで考慮する必要がある機能は?これらのパターンでは具体的にどのような問題を解決しますか?ソリューションに適用される特別な考慮事項と、その解決に最適なパターンは? このガイドでは、Salesforce テクノロジーを使用するときに、最適なイベント駆動型アーキテクチャを構築するために使用するパターンについて説明します。また、Salesforce で使用可能なイベントツールについて説明し、選択した使用事例のツールの推奨事項を示します。Salesforce に関連するデータレベルインテグレーションについての詳細は、『[Data Integration Decision Guide](/docs/architect/ja-jp/decision-guides/guide/data-integration) (データインテグレーション決定ガイド)』を参照してください。 ## ポイント - **要求への同期応答を必要としないプロセスには、イベント駆動型アーキテクチャを使用します。**このガイドで説明するパターンは、データの一貫性、拡張性、再利用を目的として設計されており、組織のアプリケーション環境が進化するにつれて技術的な負債を最小限に抑えるのに役立ちます。（詳細については、「[適切に設計](/docs/architect/ja-jp/well-architected/guide/reliable#スループット)されたスループット」を参照してください）。 - **MuleSoft または別のエンタープライズサービスバス (ESB) ソリューションが既存のランドスケープの一部である場合は、可能な限りそのソリューションを使用します。**これらのソリューションは、イベント駆動型アーキテクチャパターンをサポートすることを目的として設計されており、企業全体でインテグレーションを再利用できる強力な機能を備えています。 - **今後の公開/登録パターンには、ストリーミング API などの他の API を使用して独自のイベントハンドラを作成するのではなく、Pub/Sub API を使用します。**Pub/Sub API が正式リリースされたので、新しい公開/登録パターンに使用します。ストリーミング API やカスタム Apex サービスなど、他のプラットフォーム API を使用して既存のイベント通信を Pub/Sub API に移行できる場合は移行を計画します。 - **プラットフォームイベントと変更データキャプチャ （CDC） は、他のシステムで消費する必要があるレコードおよび項目の変更を公開するための推奨メカニズムです。**新しい実装では、PushTopic および Generic イベントを使用することはお勧めしません。Salesforce は、現在の機能の範囲内で引き続き PushTopic および汎用イベントをサポートしますが、この技術にさらに投資する予定はありません。 ## 範囲内の商品
Salesforce Platform Salesforce Platformは、従業員、自律型AIエージェント、会社のデータ、アプリケーションを単一の信頼できるシステムに統合し、生産性とカスタマー エクスペリエンスを向上させる包括的なAI駆動型プラットフォームです。Customer 360アプリケーション、Data Cloud、Slackを接続してエンドツーエンドの自動化を実現することで、「エージェント エンタープライズ」の作成を可能にします。
MuleSoft MuleSoftは、オン プレミス環境とクラウド環境でアプリケーション、データ、デバイスを接続できるSalesforceの主要な統合プラットフォームです。MuleSoft は、システム全体のデータをロック解除し、拡張性の高いインテグレーションおよび自動化フレームワークを開発し、差別化された接続された環境を迅速に作成するためのプラットフォームを IT 部門に提供するプラットフォームです。
## 決定ポイント イベント駆動型アーキテクチャ (EDA) は、ほぼリアルタイムの通知が必要なシナリオ、大量のメッセージや複雑なメッセージの処理負荷の分散、およびキューイングによる接続の復元性が必要な IoT やモバイルデバイスなどのシステムの統合にお勧めします。ただし、EDA は非同期実行を目的として設計されているため、即時の同期的な人間の応答を必要とするプロセスには実装しないでください。また、ソースデータがそれほど頻繁に変更されないため、一括処理などの単純なパターンで十分である場合にも適していません。 ### イベント駆動型アーキテクチャを使用するケース イベント駆動型アーキテクチャに適していることが多い一般的なシナリオを次に示します。
決定ポイントガイダンス
ほぼリアルタイムの通知公開/登録、ファンアウト、ストリーミングなどのイベント駆動型アーキテクチャパターンは、複数のアプリケーションに状況の変更やレコードの更新をほぼリアルタイムで通知する必要があるシナリオで適切に機能する傾向にあります。
並列処理公開/登録などのパターンは、大量のデータや非常に複雑なメッセージで処理の負荷を複数のシステムに分散する必要がある場合に適しています。
大量読み取り[合格メッセージ] および [キュー] パターンは、組織で急増が発生し、生成されるメッセージの量が登録者の即時処理能力を超える可能性があるシナリオでよく使用されます。
大量書き込みストリーミングとキューイングのパターンは、生成されるメッセージ数が急増する多くのシナリオで適切に機能します。
異なるシステムへの同じデータの送信公開/登録は、同じデータを複数のシステムに送信する必要がある組織にとってかなり一般的なソリューションですが、ここで説明するほとんどのパターンで対処できます。必ず詳細に確認して、最適な方法を見つけてください。
新しいシステムまたはデバイスの頻繁な導入公開/登録、ストリーミング、および順番待ちパターンは、新しいシステムやデバイスが定期的に追加され、全体的な状況が変動する傾向があるシナリオに適しています。このシナリオでは、新しいシステムまたはデバイスは、イベントバスの登録者になるか、キューに関連付けられているだけで、メッセージの受信を開始できます。カスタムのポイントツーポイントインテグレーションは必要ありません。
IoTデバイス通常、IoT デバイスは頻繁に更新を行い、一部のシナリオではメッセージの急増も発生するため、ストリーミングとキューイングのパターンは IT ランドスケープに統合すると適切に機能する傾向にあります。
オフラインモバイルデバイスおよびシステム品質が低い、または存在しないインターネットアクセスや、メッセージが配信された時点でオフラインになっている可能性があるシステムで作業する必要があるモバイルデバイスは、キューに接続して、オンラインに戻ったら関連するメッセージを取得できるようにするキューパターンを利用できます。
ほとんどの大規模組織では、さまざまな機能を備えた複数のシステムが混在した複雑な IT 環境があります。イベント駆動型インテグレーションをサポートしていないレガシーシステムが組織に存在している可能性があります。また、システムでサポートされる場合でも、イベント駆動型インテグレーションが役に立たない使用事例もあります (サードパーティからの SFTP ファイル転送など)。一歩下がって組織の IT ランドスケープ全体を見ると、他のアーキテクチャソリューションと同様に、さまざまなシナリオをサポートするためにさまざまなパターンを採用する可能性があります。イベント駆動型をインテグレーションの推奨アプローチにする場合は、ツールボックスの別のツールと考えてください。適切なシナリオで使用できますが、すべてのシステムに適用されるアプローチではありません。包括的なインテグレーション戦略を作成すると、このガイドで説明されているパターンが適切な場合と適さない場合を判断するのに役立ちます。 ### イベント駆動型アーキテクチャを使用しない場合 多くのシナリオではイベント駆動型アーキテクチャが必要です。一部のシナリオでは、イベント駆動型アーキテクチャが最適でなくても機能します。ただし、一部のシナリオでは、イベント駆動型アーキテクチャは使用すべきではありません。次のシナリオを特定するのに役立つ判断基準の質問をいくつか紹介します。
決定ポイントガイダンス/質問
ビジネス要件「イベント駆動型アーキテクチャを使用するケース」セクション(#イベント駆動型アーキテクチャを使用するケース)に記載されている機能のいずれかに、本当にビジネスニーズがありますか?
技術要件設計しているインテグレーションは、データ仮想化、バッチ、要求/応答など、明らかに異なるパターンに適していますか?つまり、丸い穴に四角い釘をはめ込もうとしているのでしょうか。
人間が応答を待機する必要があるプロセス対象システムからの応答を待機する人間が含まれるインテグレーションは、非同期実行を目的として設計されており、応答時間を保証できないため、イベント駆動型アーキテクチャには適していません。技術的なソリューションを実装する前に、このようなプロセスが組織にとって最適かどうかを検討します。詳細は、「適切に設計されたプロセス設計」を参照してください (/docs/architect/ja-jp/well-architected/guide/automated#プロセス設計)。
頻繁に変更されないソースデータソースシステムのデータの変更頻度が低すぎて定期的な更新で十分な場合は、イベント駆動型パターンではなく [バッチパターン] (https://developer.salesforce.com/docs/atlas.en-us.integration_patterns_and_practices.meta/integration_patterns_and_practices/integ_pat_batch_data_sync.htm) を使用してアーキテクチャを簡略化できます。
実装要件ソリューションに関与するシステムの大半はイベント駆動型アーキテクチャをサポートしていますか?イベント駆動型アーキテクチャをサポートしていないシステム (アップグレード、カスタマイズ、ミドルウェアなど) で使用するには何が必要ですか?これらの要件を満たすには、どの程度の努力が必要ですか?
メッセージ構造の安定性メッセージ構造の変更が必要になる頻度は?このような変更の影響を受けるシステムと、その修正プロセスは?
組織ガバナンスすべての関係者がメッセージ構造、トリガー、その他のアーキテクチャおよびプロセス関連の意思決定の変更について把握し、検討できるようにするためのガバナンス体制が確立されていますか?
必須スキルセットスタッフにイベント駆動型アーキテクチャの経験があり、サポート方法を理解しているか?
## 使用事例 イベント駆動型アーキテクチャにはさまざまなパターンがあります。イベント駆動型以外の特別な要件がない使用事例に適用できる汎用パターンもあります。たとえば、「[適切に設計](/docs/architect/ja-jp/well-architected/guide/composable#相互運用性)された相互運用性」を参照してください。他のパターンは、大量のデータが含まれるインテグレーションや、より長期間のメッセージ保持を必要とするシナリオなど、ここで説明する特定の使用事例に適用されます。 ### 一目でわかるパターン 次の表は、このドキュメントで説明されているパターンの属性を比較したものです。特定の使用事例の潜在的なパターンを特定する必要がある場合のクイックリファレンスとして使用します。
パターンほぼリアルタイム一意のメッセージコピー配送の保証メッセージサイズの削減データの変換
公開/登録✓✓✓
Fanout✓✓✓
合格メッセージ✓✓✓✓
ストリーミング✓✓✓
キューイング✓✓✓
### イベント駆動型アーキテクチャのツール Salesforce には、イベント駆動の使用事例に対処するのに役立つ複数のツールが用意されています。次の表に、使用可能なツールの概要を示します。
ツール説明必須スキル
MuleSoftAnypoint PlatformAPI レイヤーを使用してデータインテグレーションを可能にするプラットフォーム。プロコード
Salesforce Pub/Sub コネクタPub/Sub API のコネクタ。プラットフォームイベント、リアルタイムイベント監視イベント、変更データキャプチャを 1 つのインターフェースで公開および登録できます。プロコード
MuleSoft Anypoint JMS ConnectorJava Message Service (JMS) 仕様を実装するメッセージサービスのキューおよびトピックへのメッセージの送受信を可能にするコネクタ。プロコード
MuleSoft Anypoint Apache Kafka ConnectorApache Kafka とエンタープライズアプリケーションおよびサービス間でデータを移動するためのコネクタ。プロコード
MuleSoft Anypoint Solace ConnectorJCSMP Java SDK を使用したネイティブ API インテグレーションを備えた Solace PubSub+ イベントブローカーのコネクタプロコード
MuleSoft Anypoint MQ Connector顧客がアプリケーション間で高度な非同期メッセージングを実行できるようにするマルチテナントのクラウドメッセージングサービス。プロコード
MuleSoft Anypoint MQTT ConnectorMQTT (Message Queuing Telemetry Transport) v3.x プロトコルに準拠した MuleSoft 拡張機能。プロコード
MuleSoft Anypoint AMQP Connectorアプリケーションが AMQP 0.9.1 準拠のブローカーを使用してメッセージを公開および消費できるようにするコネクタ。プロコード
MuleSoft Anypoint Event-Driven (ASync) APIイベント駆動型 API をイベントレイヤー、チャネルレイヤー、トランスポートレイヤーに分割して公開をサポートする、業種に依存しない言語。プロコード
MuleSoft Anypoint MQ顧客がアプリケーション間で高度な非同期メッセージングを実行できるようにするマルチテナントクラウドメッセージングサービス。プロコード
MuleSoft Anypoint Data StreamsMuleSoft Anypoint 内で使用可能な、ストリーミングデータの公開および登録用のフレームワーク。プロコード
Salesforce PlatformHeroku での Apache KafkaHeroku プラットフォームに完全に統合された Apache Kafka をサービスとして提供する Heroku アドオン。プロコード
変更データキャプチャSalesforce レコードへの変更を公開する変更イベントログ。変更には、新規レコードの作成、既存のレコードの更新、レコードの削除、レコードの復元などがあります。ローコードからプロコード
送信メッセージSalesforce 内で項目値が更新されるときに XML メッセージを外部エンドポイントに送信するアクション。ローコード
プラットフォームイベントカスタムイベントデータを含む安全でスケーラブルなメッセージ。ローコードからプロコード
Pub/Sub APIプラットフォームイベント、変更データキャプチャチャイベント、リアルタイムイベントモニタリングイベントの登録を可能にする API。プロコード
イベントリレープラットフォームイベントと変更データキャプチャチャイベントを Salesforce から Amazon EventBridge に送信できるようにします。イベントリレーは AWS Eventbridge にのみ接続します。ローコード
### 公開/登録 コアアプリケーション内で重要なレコードの状態が変更された場合 (注文の状況が「処理中」から「出荷済み」に変更された場合など)、他の複数のシステムでそれぞれのタスクを実行するためにほぼリアルタイムの通知が必要になる可能性があります。このような変更の量が多く、メッセージが複雑な場合、特定のビジネスニーズが発生します。従来の 2 地点間インテグレーションは負担が大きく、メンテナンスが困難です。すべての連動アプリケーションに対して脆弱なカスタム接続を確立すると、技術的な負債が発生し、組織の迅速な拡張が妨げられます。これらの頻繁なデータ同期を管理するには、ソースシステムをすべての消費システムに直接結合せずに堅牢なインテグレーションアプローチが必要です。 #### 公開/登録パターン 次の図は、複数のパブリッシャーと登録者がイベントバスを介してデータを共有する一般的な公開/登録パターンを示しています。この基本パターンは、このガイドの残りの部分にあるより具体的なパターンの基礎となります。このパターンの主な特徴を次に示します。 - パブリッシャーと登録者の間に直接のつながりはありません。パブリッシャーは、イベントバスにメッセージを送信するだけで、イベントバスはメッセージをリッスンする他のシステムにブロードキャストします。 - 同じシステムが公開者と登録者の両方になる可能性があります。 - システムは、複数の種別のイベントを公開または登録できます。 - このガイドのすべてのパターンと同様に、公開/登録パターンは、リモートプロシージャ呼び出し (RPI) または単に[「起動](/docs/architect/ja-jp/fundamentals/guide/integration-patterns#リモートプロセスの呼び出し--fire-and-forget-起動と忘れ)後すぐに使用」と呼ばれる一般的なインテグレーションパターンカテゴリに分類されます 次のレベル 2 ダイアグラムは、複数のパブリッシャー、複数の登録者、およびイベントバスのチャネルを介して配信される複数のイベントを含む公開/登録パターンの例を示しています。 このパターンでは、同じシステムがパブリッシャーと登録者の両方になり、システムが複数のイベントを登録できます。 #### 公開/登録パターンに関連するツール
イベントフローと動作ペイロードに関する考慮事項
使用可能なツール必須スキル公開方法登録方法リプレイ期間ペイロード構造ペイロード制限
MuleSoftAnypoint PlatformプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce Pub/Sub コネクタプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint JMS ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint Apache Kafka ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint Solace ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint MQ ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint MQTT ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint AMQP ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint Event-Driven (ASync) APIプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint MQプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce PlatformHeroku での Apache KafkaプロコードAPI、Heroku Postgres のレコード変更なし1 ~ 6 週間ユーザー定義ユーザー定義
変更データキャプチャローコードからプロコードレコードの変更Apex、API、Lightning Webコンポーネント(LWC)3 日定義済み1 MB
アウトバウンドメッセージ*ローコードフローおよびワークフロールールなし24 時間ユーザー定義メッセージあたり 100 件の通知
プラットフォームイベントローコードからプロコードAPI、Apex、フローApex、API、フロー、LWC3 日ユーザー定義1 MB
Pub/Sub APIプロコードPub/Sub APIまたはAPI、Apex、フローPub/Sub API3 日ユーザー定義1 MB
イベントリレー**ローコードプラットフォームイベント、変更データキャプチャチャAPI3 日ユーザー定義1 MB
*Salesforce では、引き続き現在の機能の範囲内でアウトバウンドメッセージをサポートしますが、この技術への追加投資は予定していません。
### Fanout プッシュ通知やモバイルデバイスへの SMS メッセージなど、多数のクライアントアプリケーションに瞬時に更新を送信する必要がある場合、受信者ごとに一意の送信を作成する従来のプロセスは、すぐに拡張性のボトルネックになります。この場合のコアビジネスニーズは、1 つの情報 (取引先アラートや重要なサービス変更通知など) を多数のエンドポイントアプリケーションに同時に迅速かつハイパフォーマンスに配信することです。この要件を満たすための合理化されたアプローチでは、すべてのメッセージを 1 つのキューでルーティングします。このキューは、すべての消費システムのイベント情報の中心として機能します。この方法では、多数の個別のメッセージコピーを管理する必要がなくなるため、パフォーマンスが向上します。 #### Fanout パターン fanout パターンでは、メッセージは 1 つのメッセージキューを介して 1 つ以上の宛先 (リスン中のクライアントまたは登録者) に配信されます。登録者は、自分の一意のコピーではなく、キューから同じメッセージを取得します。(これによりパフォーマンスが向上しますが、特定のユーザがメッセージを受信したかどうかの確認がより困難になる可能性があります)。 次のレベル 3 のドキュメントと実装の図は、ファンアウトパターンの例を示しています。この図は、ユーザー操作、フロー、または一括処理ジョブによってレコードが変更されたときに、イベントが 1 つのキューに公開および書き込まれる様子を示しています。 登録者システムには、メッセージキューから同じイベントを受信する複数のサービスがあります。 #### Fanout パターンに関連するツール
イベントフローと動作ペイロードに関する考慮事項
使用可能なツール必須スキル公開方法登録方法リプレイ期間ペイロード構造ペイロード制限
MuleSoftMuleSoft Anypoint JMS ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce Pub/Sub コネクタプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint Apache Kafka ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint Solace ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint MQ ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint MQTT ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint AMQP ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint MQプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce PlatformHeroku での Apache KafkaプロコードAPI、Heroku Postgres のレコード変更なし1 ~ 6 週間ユーザー定義ユーザー定義
変更データキャプチャローコードからプロコードレコードの変更Apex、API、Lightning Webコンポーネント(LWC)3 日定義済み1 MB
プラットフォームイベントローコードからプロコードAPI、Apex、フローApex、API、フロー、LWC3 日ユーザー定義1 MB
Pub/Sub APIプロコードPub/Sub APIまたはApex、API、フローPub/Sub API3 日ユーザー定義1 MB
イベントリレー*ローコードプラットフォームイベント、変更データキャプチャチャAPI3 日ユーザー定義1 MB
*イベントリレーは AWS Eventbridge にのみデータを送信
### 合格メッセージ 一部のイベントシナリオは、同期および変換プロセスの容量を圧迫する恐れのある大量のメッセージや、イベントデータの処理と変換に必要な複雑な複数ステップのロジックによって特徴付けられます。 たとえば、次のようなものがあります。 - **季節的な量の急増：**オンライン小売業者は、商品の選択が「旬」になると、量が急増する可能性があります。多数の顧客が同時に購入する場合、生成されるイベント数が同期および変換プロセスの容量を一時的に超える可能性があります。詳細は、「[適切に設計](/docs/architect/ja-jp/well-architected/guide/automated#データ処理)されたデータ処理」を参照してください。 - **ケースまたは請求管理：**サービスベースの会社は、停止中にケース数や請求数が急増する可能性があります。 - **複雑なデータ変換：**メッセージを変換するために複雑なロジックを必要とする組織は、多くの場合、変換よりも早くイベントが生成されることを懸念します。 #### 合格メッセージパターン このパターンは、変換よりも早くメッセージが生成されるという問題に対処します。ストリーミングメッセージプラットフォームとセグメント化されたメッセージ処理ロジックを専用コンポーネントに組み込むことで、大量のメッセージと必要なデータ操作を確実に処理できます。 「合格メッセージ」パターンは、メッセージ処理ロジックを複数のコンポーネントに分割することで機能します。 - 1 つのコンポーネントでメッセージのルーティングを処理し、必要な変換と最終的な送信先を決定します。 - 個別のコンポーネントセットは、メッセージ変換の異なるレイヤー (項目の対応付け、オブジェクトリレーションなど) を処理します。 - 最後のコンポーネントは、最後に変更されたメッセージを書き込みます。 次のレベル 3 のドキュメントと実装図は、パブリッシャー、登録者、およびメッセージを含む、渡されるメッセージパターンのプロセスフローの例を示しています。 メッセージは複数の部分に分割され、個別に変換され、登録者に送信する前に再構成されます。 #### 合格メッセージパターンに関連するツール
イベントフローと動作ペイロードに関する考慮事項
使用可能なツール必須スキル公開方法登録方法リプレイ期間ペイロード構造ペイロード制限
MuleSoftMuleSoft Anypoint Apache Kafka ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce Pub/Sub コネクタプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce PlatformHeroku での Apache KafkaプロコードAPI、Heroku Postgres のレコード変更なし1 ~ 6 週間ユーザー定義ユーザー定義
変更データキャプチャローコードからプロコードレコードの変更Apex、API、Lightning Webコンポーネント(LWC)3 日定義済み1 MB
プラットフォームイベントローコードからプロコードAPI、Apex、フローApex、API、フロー、LWC3 日ユーザー定義1 MB
Pub/Sub APIプロコードPub/Sub APIまたはAPI、ApexフローPub/Sub API3 日ユーザー定義1 MB
イベントリレー*ローコードプラットフォームイベント、変更データキャプチャチャAPI3 日ユーザー定義1 MB
*イベントリレーは AWS Eventbridge にのみデータを送信
### ストリーミング 一部のプロデューサーは、イベントの連続ストリームを生成します。一般的な例として、メディアストリーミングがあります。メディアストリーミングには、個別のイベントとして自然に発生するユーザー操作が含まれます。コアストリーミング環境をブロックすることなく、複数のシステムで同じユーザー行動に同時に反応する必要があります。 音楽ストリーミングプラットフォームのイベントについて考えます。これには次のものが含まれます。 - 開始/一時停止/スキップされたイベントを追跡する - タイムスタンプ付きのリスニングセッションイベント - プレイリストの作成/変更イベント - ソーシャル共有イベント - オフラインリスニング用にダウンロード #### ストリーミングパターン ストリーミングパターンでは、登録者は各イベントストリームにアクセスし、イベントを受信した正確な順序で処理します。各メッセージストリームの一意のコピーが各登録者に送信されるため、登録者固有のコンテンツを配信し、どの登録者がどのストリームを受信するかを識別できます。 次のレベル 3 のドキュメントと実装図は、公開されるイベントのストリームを表すストリーミングパターンの例を示しています。ストリームをリスンしている登録者は、ストリームを受信してそれに応じて処理します。 #### ストリーミングパターンに関連するツール
イベントフローと動作ペイロードに関する考慮事項
使用可能なツール必須スキル公開方法登録方法リプレイ期間ペイロード構造ペイロード制限
MuleSoftMuleSoft Anypoint Data StreamsプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce Pub/Sub コネクタプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint Apache Kafka ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce PlatformHeroku での Apache KafkaプロコードAPI、Heroku Postgres のレコード変更なし1 ~ 6 週間ユーザー定義ユーザー定義
Pub/Sub APIプロコードPub/Sub APIまたはAPI、ApexフローPub/Sub API3 日ユーザー定義1 MB
#### ストリーミングイベント注文管理 ストリームが理にかなっているためには、そのすべてのイベントと関連するメッセージが正しい順序になっている必要があります。異なるシステムからストリームでデータを取得する場合、設計プロセスの一環として追加の注文ロジックを組み込む必要があります。 ### キューイング キューイングの使用事例は随所に存在します。例として、次のようなものがあります。 - **低品質のインターネット接続:**モバイルデバイスを使用するチームが品質が低く、インターネットアクセスが断続的な地域で作業する必要がある Field Service 組織やその他の組織では、接続が回復すると、これらのデバイスのアプリケーションがキューに接続して関連メッセージを取得できるため、キューが役立ちます。 - **メッセージバッファリング:**メッセージの量が登録者の処理能力を超えることがあり、遅延の増加によって追加の問題が発生しない場合、キューは過剰なメッセージを保存し、データの損失を防ぐためのバッファになります。 - **輸送管理:**法人車両を監視する必要がある物流組織は、このパターンを使用して、各車両が経由するルートをほぼリアルタイムで表示し、運転者の効率を最大限に高めることができます。 - **IoT デバイス:**メーカーは多くの場合、高速データストリームを生成するシステムを使用しており、これらのストリームが追加のシステムに下流の影響を及ぼす可能性があります。このパターンは、複数のシステムにまたがる重大な障害が発生する前に、人間の介入が必要な一連のイベントを識別するために使用できます。 #### 順番待ちパターン Queuing パターンでは、プロデューサーがキューにメッセージを送信し、登録者が取得するまでキューにメッセージが保持されます。ほとんどのメッセージキューは先入れ先出し (FIFO) 順序に従っており、取得後にすべてのメッセージが削除されます。各登録者には一意のキューがあり、追加の設定手順が必要ですが、配信を保証し、どの登録者がどのメッセージを受信したかを識別できます。 このレベル 3 のドキュメントと実装図は、レコードが変更されたときにイベントが公開されてキューに書き込まれるキューパターンの例を示しています。登録者は、関連付けられたキューからイベントのコピーを受信し、自分のレコードに適切な更新を行います。 #### キューイングパターンに関連するツール
イベントフローと動作ペイロードに関する考慮事項
使用可能なツール必須スキル公開方法登録方法リプレイ期間ペイロード構造ペイロード制限
MuleSoftMuleSoft Anypoint MQプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce Pub/Sub コネクタプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint Apache Kafka ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint MQ ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint MQTT ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
MuleSoft Anypoint AMQP ConnectorプロコードAPIAPIAs Configuredユーザー定義なし
Salesforce PlatformHeroku での Apache KafkaプロコードAPI、Heroku Postgres のレコード変更なし1 ~ 6 週間ユーザー定義ユーザー定義
変更データキャプチャローコードからプロコードレコードの変更Apex、API、Lightning Webコンポーネント(LWC)3 日定義済み1 MB
プラットフォームイベントローコードからプロコードAPI、Apex、フローApex、API、フロー、LWC3 日ユーザー定義1 MB
Pub/Sub APIプロコードPub/Sub APIまたはAPI、Apex、フローPub/Sub API3 日ユーザー定義1 MB
イベントリレー*ローコードプラットフォームイベント、変更データキャプチャチャAPI3 日ユーザー定義1 MB
*イベントリレーは AWS Eventbridge にのみデータを送信
#### メモリおよびストレージ管理 Queuing パターンの非同期の性質上、メッセージがキューに追加されてから取得されるまでに長い遅延が発生する可能性があります。キューにはメッセージを保持するためのメモリまたはストレージ容量が必要なため、無制限に拡張することはできません。つまり、無制限にオフラインになっている登録者は、キューに十分なメッセージが蓄積されると、障害が発生する可能性があります。メッセージのバッファリングは、登録者の処理時間が長くなりすぎて大量のメッセージがキューに蓄積された場合にも同じ影響を及ぼす可能性があります。これらのリスクを軽減するには、すべてのメッセージキューのストレージ要件を徹底的に分析し、必要に応じて、メッセージが設定された時間内に取得されなかった場合や、メッセージが事前に定義された量に達した場合にキューを消去および無効にするプロセスを設計します。 ## 機能以外の考慮事項 ### 2 地点間インテグレーションからの移行 イベント駆動型アーキテクチャが組織に適していると完全に確信していても、すでに多数のポイントツーポイントインテグレーションがある状況から開始している場合があります。すべてのインテグレーションを一度に置き換えるプロジェクトの資金を得ることは困難な場合があります。また、一部のレガシーシステムでイベント駆動型アーキテクチャを直接使用することさえできない場合もあります。これらのシナリオでは、最もビジネスクリティカルなアプリケーションを最初に変換してから、将来のプロジェクトで更新または置き換えられたときに他のシステムを変換することで、より疎結合なアーキテクチャに段階的に移行できます。このアプローチにより、イベントバスに新しいアプリケーションを簡単に追加でき、時間の経過と共にシステムが追加されても IT ランドスケープ全体の拡張性と耐障害性を維持できます。 ### 疎結合システム内のトレードオフ アーキテクトは、すべてのアーキテクチャにはトレードオフがあることを認識しています。イベント駆動型アーキテクチャも例外ではありません。疎結合のシステムでいっぱいのランドスケープは、拡張性と耐障害性に優れていますが、次のようなトレードオフも考慮する必要があります。 - **全体的な統合戦略:**使用するツールやパターンに関係なく、まず、組織内のさまざまなシステムでデータを共有する方法に関する戦略を作成することが重要です。この戦略には、データの目標、データの共有方法と使用パターン、データソース、対象、構造、所有権とアクセスの要件を含める必要があります。 - **レガシーシステムのサポート:**組織にイベント駆動型アーキテクチャパターンをサポートしていないレガシーシステムがある場合があります。回避策 (イベントに登録し、別のデータ転送手段を使用して出力をターゲットシステムに送信するパススルーとして機能するプロセスなど) を構築することは可能ですが、この場合は他のインテグレーション方法を検討することをお勧めします。 - **メッセージの構造の変更：**最初のメッセージ構造が定義され、公開者と登録者の間で合意されると、特に登録者が外部の場合、変更が困難になる可能性があります。この問題に対処する方法はいくつかあります。バージョン管理されたエンドポイントを使用できますが、開発者が同時に多くのバージョンを管理する必要がないように、各バージョンの明確なライフサイクルを定義して伝えてください。Heroku の Apache Kafka がランドスケープの一部である場合は、スキーマレジストリや同様のツールを検討することもできますが、ランドスケープ内の他のシステムでもサポートされている (および使用されている) ことを確認してください。 - **パブリッシャーと登録者間の可視性の欠如:**ほとんどのイベント駆動型アーキテクチャパターンでは、パブリッシャーは登録者の状況を認識しません。そのため、すべての登録者がオフライン中にパブリッシャーが重要なメッセージを送信すると、メッセージが配信されない場合があります。リプレイ機能を使用するか、すべての重要なメッセージに対して別々のサーバで実行される冗長なユーザを追加することで、この問題に対処できます。 - **パフォーマンスのボトルネック：**イベント駆動型アーキテクチャの拡張に伴い、イベントバスが大量の登録者に同時にメッセージを送信しようとするパブリッシャーに圧倒されると、メッセージ配信のボトルネックになる可能性があります。これに対処するには、イベントバスに割り当てられるメモリと処理リソースを増やすか、複数のイベントバスを使用して異なる種別のメッセージを並列処理します。 ## 関連するベストプラクティス ### イベント駆動型アーキテクチャの実装 イベント駆動型アーキテクチャを実装する前に、そもそも本当に使用する必要があるかどうかを検討します。前のセクションでは、各イベント駆動型アーキテクチャパターンに適した一般的なビジネスシナリオについて説明します。詳細は、「[適切に構築](/docs/architect/ja-jp/well-architected/guide/composable#相互運用性)された相互運用性」も参照してください。「イベント駆動型アーキテクチャを実装するときに考慮すべき課題」を確認して、想定しているパターンが特定の使用事例に最も適しているかどうかを判断します。 このガイドで扱うシナリオの大部分はインテグレーションに関連しますが、イベント駆動型アーキテクチャでは、プラットフォームイベントなどを使用して 1 つの Salesforce 組織内でメッセージを送信することもできます。プラットフォームイベントを内部メッセージングシステムとして使用するプロセスを設計するときは、該当する[イベント割り当て制限](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)に留意してください。 ### アンチパターンの回避 多くの場合、イベント駆動型アーキテクチャのアンチパターンは、Salesforce 組織の内部コミュニケーションの回避策としてイベントを使用することに起因します。一般的なアンチパターンは次のとおりです。 - **同じイベント オブジェクトに関連付けられた Apex トリガーからのイベントのパブリッシュ：**これにより、無限トリガーループが発生します。 - **DML トランザクションが完了する前に Apex からイベントを公開する：**トランザクションが失敗してロールバックされた場合、\[すぐに公開] 公開動作を持つ公開済みイベントはロールバック動作に含まれません。 - **後続の自動化を調整するためのフローでの公開イベント：**複数の自動化間でロジックを調整する最適な方法は、[サブフロー](https://developer.salesforce.com/docs/atlas.en-us.salesforce_vpm_implementation_guide.meta/salesforce_vpm_implementation_guide/vpm_designer_elements_subflow.htm)または[フローオーケストレーター](https://help.salesforce.com/s/articleView?id=sf.orchestrator_flow_orchestrator.htm)を使用することです。 - **実行時連動関係の作成:**実行時の連動関係を排除する適切な[手順](https://medium.com/salesforce-architects/5-anti-patterns-in-package-dependency-design-and-how-to-avoid-them-87bb50331cb8)を実行せずに、パッケージ間の通信を促進するイベントを公開しないでください。 - **不必要に大きいペイロード:**要求を実行するときは、ペイロードでできるだけ少ない量のデータを送受信することをお勧めします。ユーザーのすべてのアクションで複数の要求が発生する可能性があるため、これらを効率的に処理することが重要です。必要以上に多くのデータを送信すると、転送が遅くなり、処理時間が長くなる可能性があります。 - **アプリケーションイベントの選択解除処理：**アプリケーションイベントをリスンするコンポーネントが複数ある場合、開発者はイベントハンドラーが実際に必要で役に立つ場合にのみ実行されることを確認する必要があります。たとえば、Lightning コンソールでは、フォーカスされていないタブに含まれるコンポーネントは、表示されていなくても聞くことができます。開発者は、バックグラウンドユーティリティ項目を唯一のリスナーとして使用したり、getEnclosingTabId() をコールしてコンポーネントのこのインスタンスがフォーカスされたタブ内に含まれるかどうかを判断したりして、各イベントが意図した場合にのみ処理されるようにします。 - **プラットフォームイベントの公開動作を正しく使用しない**プラットフォームイベントには、\[すぐに公開] と \[コミット後に公開] の 2 つの公開動作があります。リアルタイムプラットフォームイベントは、トランザクションが成功して確定したかどうかに関係なくログイベントを公開する必要があるログ記録などの使用事例で使用できます。ただし、リアルタイムプラットフォームイベントでは、\[Publish Immediately (すぐに公開)] を慎重に使用してください。イベントは、登録者が同じトランザクション内で消費し、行ロックやその他の競合状態を引き起こす可能性があります。 ### 効果的なイベントの設計 イベント駆動型アーキテクチャを実装する場合、成功への鍵の 1 つはイベント自体の設計方法の標準を設定することです。詳細は組織の使用事例によって異なりますが、一般的なガイドラインを次に示します。 - **イベントペイロードの最適な構造を決定します。**メッセージサイズを小さくすると処理時間が短縮されますが、大量のメッセージを登録者に送信しようとすると、パフォーマンスのボトルネックが発生する可能性があります。適切なバランスを見つけるために、ペイロードのサイズと構造に対して反復処理が必要な場合があります。MuleSoft および同様の ESB ツールでは、イベントに関連付けられたメッセージでカスタムペイロードを設計できるため、登録者側のパフォーマンスを向上させるためにデータ構造を視覚化できます。(詳細については、「[適切な設計 - API](/docs/architect/ja-jp/well-architected/guide/composable#api-管理) 管理」を参照してください)。 - **プロセスをエンドツーエンドで検討します。**インテグレーションがロールアウトされると追跡が困難になる可能性がある「無限ループ」シナリオを作成していないことを確認します。たとえば、レコードが更新されたときにイベントを公開し、同時に相互のイベントをリスンする 2 つのシステムで、処理時に追加の公開イベントがトリガーされます。 この種別のアンチパターンを修正するには、消費されたイベントの結果として行われた変更によって新しいイベントが公開されないようにするロジックを両方のシステムに追加します。また、すべてのイベント、関連付けられたトリガー、および影響を受ける可能性のあるダウンストリームシステムを文書化する必要があります。このドキュメントは、無限ループや類似するシナリオをできるだけ早くキャッチするための設計セッション中の参照資料として使用します。(詳細については、「[適切な設計 - プロセス設計](/docs/architect/ja-jp/well-architected/guide/automated#プロセス設計)」を参照してください)。 - **システム全体で共通の命名規則を使用します。**イベント駆動型アーキテクチャを含め、すべてのソフトウェア開発で一貫した命名規則を使用することをお勧めします。イベント名、構造、関連付けられたオブジェクト、エラー処理プロセスに関する一連の標準を文書化して、システム全体で一貫性を確保します。(詳細については、「[適切に設計](/docs/architect/ja-jp/well-architected/guide/intentional#設計標準)された設計基準」を参照してください)。 ## リソース
パターンリソース
公開/登録Salesforce の適切なアーキテクチャ - スループット
Salesforce の適切なアーキテクチャ - データ処理
Salesforce の適切なアーキテクチャ - 相互運用性
ブログ投稿:イベントリレーを使用したアーキテクチャの効率化
ブログ投稿:Pub/Sub API正式リリースのお知らせ
ブログ投稿:RESTful から EVENTful への移行
ブログ投稿:イベント駆動型アーキテクチャと AsyncAPI 仕様
動画:パターンの公開/登録のウォークスルー
Fanoutブログ投稿:プラットフォームイベント配信制限内での作業方法
動画:Fanout Pattern Walkthrough (ファンアウトパターンウォークスルー)
合格メッセージ動画:Passed Messages Pattern Walkthrough (合格メッセージパターンウォークスルー)
ストリーミングブログ投稿:Salesforce での大量の書き込みに対応する設計
動画:ストリーミングパターンウォークスルー
ドキュメント:Mule アプリケーションでのストリーミング
キューイングブログ投稿:Salesforce での大量の書き込みに対応する設計
ブログ投稿:イベント API を使用した支払アーキテクチャの設計方法
動画:Queueing Pattern Walkthrough (キューイングパターンウォークスルー)
## 概要 最新の Salesforce アーキテクチャは、利便性ではなく、拡張性の戦略的な要件として非同期処理によって強化されつつあります。近年、データ量の急増、複数のタッチポイントを伴う複雑なインテグレーション、24 時間 365 日稼働する自律システムの台頭に取り組む企業が増えています。これらすべての要素により、アーキテクトは非同期ファーストのシステム設計に取り組むようになります。 Salesforce での非同期処理では、多くの場合、ガバナの制限と複雑さを考慮して設計する必要があります。これらの制限は、一括で安全で拡張可能なシステムを生成するのに役立つガードレールとアーキテクチャの制約として機能します。プラットフォームの制限は複雑さの管理に直接役立ちませんが、[設計パターンを](https://refactoring.guru/design-patterns)使用すると、リスクを軽減できます。Salesforce の内部では、新機能のフォワードテストや複雑なビジネスプロセスの自動化にプラットフォームの限界を押し広げています。任意のステップ数で非同期ジョブを実行するためのステップベースの非同期処理フレームワークを構築しました。各ステップは、共有ガバナンス制御と一元化されたログ記録による完全な操作の可視化により、個別に実行、再試行、再起動できます。このドキュメントでは、その主要なアーキテクチャコンポーネントの概要を説明します。キュー可能な Apex およびファイナライザー、スケジュール済みフロー、Apex カーソル、呼び出し可能なアクション、Slack とのインテグレーション。これらのコンポーネントを組み合わせることで、進化するエンタープライズニーズに適したモジュラー型で拡張性が高く、監視可能なアーキテクチャが提供されます。 ## 重要ポイント - 最新の Salesforce アーキテクチャでは、拡張性、耐障害性、運用の透明性を実現するために、非同期優先のアプローチを採用する必要があります。 - 複雑な作業を個々に実行可能なステップに分割することで、コアワークフローを再設計することなく、予測可能なパフォーマンス、より安全な再試行、チェックポイント、ロールバック、モジュールの進化を実現できます。 - このフレームワークは、モノリシックで経年劣化した一括処理ジョブ、チェーンされた非同期コール、深くネストされたフローに代わるスケーラブルな代替手段を提供し、プラットフォーム外でオーケストレーションすることなく Salesforce 内で水平に拡張する必要がある大規模ワークロード向けに構築されています。 - 確定的で観察可能な実行により、一元的なログとガバナンスを通じて、進行状況の追跡、SLA の監視、障害診断、監査レベルの透明性が確保されます。 - 長期にわたるビジネスプロセスの統合ガバナンス、コンプライアンス、分散状態制御など、エンタープライズ クラスの厳格さを実現するように設計されています。 ## プラットフォームのベストプラクティス 要件を確認する前に、次のようなフレームワークを使用する場合の推奨事項と推奨事項を次に示します。何よりも、どのシステムが唯一の情報源であるかを検討します。Salesforce 組織が外部データに最小限しか依存していないが、数百件から数百万件のレコードに拡張する必要がある場合は、ステップベースの非同期フレームワークを検討します。 このフレームワークは、次の場合に使用**します**。 - アクションを実行する情報のほとんど (またはすべて) が CRM にすでに存在します。 - 外部データをハーモナイズするための抽出変換負荷 (ETL) ジョブの維持にかかる先行コストまたは継続的なコストが高すぎる。 - 設定されたスケジュールで多数の Salesforce レコードの処理を延期する必要があります。 - 処理を個別のステップに分割できます。たとえば、階層またはツリーベースのレコードセットを作成できます。特に、データ量が階層またはツリーの下位にある場合に便利です。 次の場合は、このフレームワークを使用**しないで**ください。 - レコードを作成または更新するには、すぐに再計算する必要があります。 - 外部システムでレコード更新の主データがホストされているため、インテグレーションが困難です。(Bulk API を使用して更新されたデータを Salesforce に転送することを検討してください)。 これらのプラクティスを念頭に置いて、要件を確認して構築を開始しましょう。 ## 要件の内訳 問題ステートメントについて考えてみます。 > 毎日実行する必要があるジョブがある場合、特定のレコードが追加処理のために事前設定された条件を満たしているかどうかを確認します。その場合は、これらの処理ジョブを開始します。レコードの処理では、複数の外部システムからデータを取得して計算を実行する必要がある場合があります。ジョブのステップでは、処理済みのレコードを確認する準備が整ったことを Slack 経由でユーザーに通知する必要があります。また、最初の通知のラウンド後に設定可能な遅延に基づいて、ロール階層内のマネージャー以上のユーザーに通知をエスカレーションする必要があります。 この問題には複数の異なるステップが含まれ、それぞれ独立して発生する場合もあります。作業を分割する方法は多数あります。1 つのグルーピングを次に示します。 - スケジューラー。 - (処理の種別に関係なく) レコードを処理するステップインターフェースと具体的な実装。 - ステップを整理するプロセッサー。 - スケジューラによって呼び出される Apex 呼び出し可能。 - 通知部分。[Apex Slack SDK](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/guide/overview.html)を使用します。 - 「設定可能な遅延」という語句には複雑さが隠されています。この複雑さについては、この記事で後ほど説明します。 組み込みフレームワークの意見を示した図を次に示します。 フロースケジューラ、Apex 非同期処理、および考えられるさまざまなステップの実装を示すアーキテクチャ図 では、その図を分解して、ピースの作成を開始します。 ## スケジュール済みフローを使用したスケジュール スケジュール済みフローには、スケジュールメカニズムとして次のような利点があります。 - スケジュール済みフローは、メタデータとしてパッケージ化してリリースできます。これは、Apex (または \[スケジュール済みジョブ] ページ) でスケジュールされたジョブには適用されません。 - 待機要素は、コールアウトが必要なフレームワークにとって重要です。フローで使用すると、フレームワークの呼び出し可能部分でコールアウトが不要になります。 - スケジュールの粒度は要件を満たしています。スケジュール済みフローの最小間隔は毎日です。より高い頻度 (毎時など) が必要な場合は、この要件のスケジュール済みフローを再検討してください。 スケジュール済みフローを設定するときのもう 1 つの考慮事項は、環境管理です。Apex アクションを呼び出す前に、`{!$Api.Enterprise_Server_URL_100}`変数を評価する決定要素を追加します。これにより、UAT や本番など、意図した環境でのみジョブが実行されます。Sandbox は SDLC 中に頻繁に更新または新規作成されるため、このパターンは重要です。明示的な環境チェックを行わないと、フレームワークの実行が意図されていない環境でスケジュール済みフローが意図せずに実行される可能性があります。決定要素で `contains` 演算子を使用すると、今後の Sandbox の作成や URL の変更に対して設定が復元されます。 最後に、フレームワークで失敗をどのように捉えるかを検討します。フローでアクションをコールするときは、必ず障害パスを追加します。たとえば、[Nebula Logger の](https://www.nebulalogger.com/)「Add Log Entry」アクションに障害を配線できます。Nebula Logger はログをカスタムオブジェクトに書き込むため、ログデータは組織のストレージを消費します。デフォルトでは、ログは組織内で 14 日間保存され、その後クリーンアップされます。この保持期間は設定可能です。Nebula Logger はプラットフォームイベントを使用してログも公開するため、ログエントリはメインのデータ処理トランザクションから独立して保存されます。これにより、プライマリフローまたは Apex アクションがロールバックされた場合でも、障害を確実に捕捉できます。ログフレームワークの追加を検討する場合は、予想されるログ量と保持要件を評価する必要があります。 フローは次のようになります。 実行するかどうかの決定要素、コールアウトを許可する一時停止要素、および Nebula Logger 障害パスと共に呼び出される Apex 呼び出し可能アクションが含まれるスケジュール済みフロー スケジュール要件が満たされた最初のApexコードに進みましょう。 ## ステップインターフェースの作成 `Step` インターフェイスを定義します。 ```java public interface Step { void execute(); void finalize(); String getName(); Boolean shouldRestart(); } ``` この記事では、わかりやすくするために `step` インタフェースを外部クラスとして示します。フレームワーク自体は柔軟性が高く、すべてのステップ・クラスが同じインタフェースを参照していれば、チームは任意のApexパッケージ・パターンを使用してインタフェースとその実装を編成できます。 インターフェース内で定義されたメソッドについては、いくつかの注意事項があります。 - `execute`は、現時点では引数なしで済みますが、順序が重要な場合にステップ間でデータをオーケストレーションするために`State`クラス(またはインターフェイス)を渡すと改善されます。 - `getName` は、`System.Type` 値ではなく`String`値を返す可能性があります。目的は、オーケストレーションレイヤーで他のプロパティを公開せずにステップ名を記録する方法を提供することです。 これらの要素がどのように組み合わされるかを示す最初の具体的な実装を次に示します。後で 1 つの例外を除いて、キュー可能 Apex を使用して Apex 内に非同期処理を実装することをお勧めします。通常、バッチ Apex は不要です (`@future` メソッドは使用しない)。Queueable Apex はすばやく開始でき、Apex カーソルを使用すると、バッチ Apex よりも多くの利点があります。 ### Apex カーソルのような実装 [Apexカーソル](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_cursors.htm)は、従来のバッチApexモデルに代わる最新の機能を提供します。一括処理と同様に、カーソル実装ではレコードをチャンク (バッチあたり最大 2,000 件) で取得できます。ただし、カーソルでは 1 つのトランザクション内で複数の取得が許可されるため、大量の操作のスループットが大幅に向上します。 このフレームワークの一部としてカーソルを採用する場合、チームは現在のテストとモック可能性の制限を認識しておく必要があります。テストでのカーソルの動作は本番の動作とは異なる可能性があるため、カーソルの内部に依存しないようにテスト戦略を設計し、境界でオーケストレーションロジックを検証することが重要です。プラットフォームが進化するにつれて、次の領域は引き続き改善されますが、主要な指針は引き続き維持されます。カーソルを使用すると、多くの使用事例でバッチApexよりもパフォーマンスが向上し、オーケストレーションのオーバーヘッドが軽減されます。 システムが提供するカーソルと独自のコードの間に明確な境界を定義するには、`Step` インターフェースを実装するときにカーソルのような表現を作成することをお勧めします。次のコードについて考えてみます。 ```java public inherited sharing abstract class CursorStep implements Step { private static final Integer MAX_CHUNK_SIZE = 2000; protected Cursor cursor; private Integer chunkSize = System.Limits.getLimitDMLRows(); private Integer position = 0; protected abstract Cursor getCursor(); protected abstract void innerExecute(List records); public abstract String getName(); public virtual CursorStep withChunkSize(Integer chunkSize) { this.chunkSize = chunkSize; return this; } public void execute() { this.cursor = this.cursor ?? this.getCursor(); this.cursor.setFetchesPerTransaction(this.getFetchesPerTransaction()); List records = new List(); if (this.shouldAdvance()) { records = this.cursor.fetch(this.position, this.chunkSize); this.position += this.chunkSize; } this.innerExecute(records); } public virtual void finalize() { Logger.info('finished cursor step for ' + this.getName()); } public virtual Boolean shouldRestart() { return this.position < this.cursor.getNumRecords(); } protected virtual Integer getFetchesPerTransaction() { Integer maxRecordsPerFetchCall = 2000; if (this.chunkSize < maxRecordsPerFetchCall) { return this.chunkSize; } // Integer division rounds down // which is perfect for our use-case return this.chunkSize / maxRecordsPerFetchCall; } protected virtual Boolean shouldAdvance() { return true; } } ``` `Cursor` クラスに注目してください。Apex カーソルは`Database.Cursor`のインスタンスですが、`Cursor` の実装により、カーソルの欠点を柔軟に回避できます。実装は次のようになります。 ```java public virtual without sharing class Cursor { private static final Integer MAX_FETCHES_PER_TRANSACTION = Limits.getLimitFetchCallsOnApexCursor(); @TestVisible private static Integer maxRecordsPerFetchCall = 2000; private Integer cursorNumRecords; private Integer fetchesPerTransaction = MAX_FETCHES_PER_TRANSACTION; private final Database.Cursor cursor; public Cursor( String finalQuery, Map bindVars, System.AccessLevel accessLevel ) { try { this.cursor = Database.getCursorWithBinds(finalQuery, bindVars, accessLevel); } catch (FatalCursorException e) { Logger.newEntry( System.LoggingLevel.WARN, 'Error creating cursor. This can happen if there' + ' are no records returned by the query: ' + e.getMessage() ); } } public Cursor setFetchesPerTransaction(Integer possibleFetchesPerTransaction) { // Handle accidental round downs from Integer division if (possibleFetchesPerTransaction == 0) { return this; } if (possibleFetchesPerTransaction > MAX_FETCHES_PER_TRANSACTION) { Logger.newEntry( System.LoggingLevel.DEBUG, 'Fetches per transaction: ' + possibleFetchesPerTransaction + ' exceeded platform max fetches per transaction: ' + MAX_FETCHES_PER_TRANSACTION + ', defaulting to platform max' ); possibleFetchesPerTransaction = MAX_FETCHES_PER_TRANSACTION; } this.fetchesPerTransaction = possibleFetchesPerTransaction; return this; } @SuppressWarnings('PMD.EmptyStatementBlock') protected Cursor() { } public virtual List fetch(Integer start, Integer advanceBy) { if (this.getNumRecords() == 0) { Logger.newEntry( System.LoggingLevel.DEBUG, 'Bypassing fetch call, no records to fetch' ); return new List(); } Integer localStart = start; List results = new List(); while ( Limits.getFetchCallsOnApexCursor() < this.fetchesPerTransaction && results.size() < this.getNumRecords() && localStart < start + advanceBy ) { Integer actualAdvanceBy = this.getAdvanceBy(localStart, advanceBy); results.addAll(this.cursor?.fetch(localStart, actualAdvanceBy) ?? new List()); localStart += actualAdvanceBy; } return results; } public virtual Integer getNumRecords() { this.cursorNumRecords = this.cursorNumRecords ?? this.cursor?.getNumRecords() ?? 0; return this.cursorNumRecords; } protected Integer getAdvanceBy(Integer start, Integer advanceBy) { Integer possibleFetchSize = Math.min(advanceBy, this.getNumRecords() - start); if (possibleFetchSize > maxRecordsPerFetchCall) { Logger.newEntry( System.LoggingLevel.DEBUG, 'Fetch size: ' + possibleFetchSize + ' exceeded platform max fetch size of ' + maxRecordsPerFetchCall + ', defaulting to max fetch size' ); possibleFetchSize = maxRecordsPerFetchCall; } else if (possibleFetchSize < 0) { possibleFetchSize = 0; } return possibleFetchSize; } } ``` この記事では、Apex クラスを参照するときに `sharing` 宣言を省略します。実際には、オブジェクトモデルと権限に準拠するために、最上位クラスで共有の有無に関係なく明示的に使用してください。 また、`Cursor`の実装はプラットフォーム `Database.Cursor`に委任され、その他のメリットについては次に説明します。 まず、対応するテストを次に示します。 ```java @IsTest private class CursorTest { @IsTest static void itCapsAdvanceByArgument() { String accountName = 'helloWorld!'; insert new Account(Name = accountName); String query = 'SELECT Name FROM Account WHERE Name = :bindVar0'; Map bindVars = new Map{ 'bindVar0' => accountName }; Cursor instance = new Cursor(query, bindVars, System.AccessLevel.SYSTEM_MODE); Assert.areEqual(1, instance.getNumRecords()); Assert.areEqual(accountName, instance.fetch(0, 1000).get(0).get('Name')); Assert.areEqual(1, System.Limits.getApexCursorRows()); } @IsTest static void itCapsMaxRecordsPerFetchCall() { Cursor.maxRecordsPerFetchCall = 20; Integer oneMoreThanMaxFetch = Cursor.maxRecordsPerFetchCall + 1; List accounts = new List(); for (Integer i = 0; i < oneMoreThanMaxFetch; i++) { accounts.add(new Account(Name = 'Fetch ' + i)); } insert accounts; Exception ex; List results; Cursor instance = new Cursor( 'SELECT Id FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ); try { results = instance.fetch(0, oneMoreThanMaxFetch); } catch (System.InvalidParameterValueException e) { ex = e; } Assert.areEqual(null, ex?.getMessage()); Assert.areEqual(2, Limits.getFetchCallsOnApexCursor()); Assert.areEqual(oneMoreThanMaxFetch, results.size()); } @IsTest static void itFetchesMultipleTimesPerTransactionWhenMoreThanMaxFetch() { Cursor.maxRecordsPerFetchCall = 20; List accounts = new List(); Set expectedFetchNames = new Set(); for (Integer i = 0; i < Cursor.maxRecordsPerFetchCall + 1; i++) { String accountName = 'Fetch' + i; expectedFetchNames.add(accountName); accounts.add(new Account(Name = accountName)); } insert accounts; Integer oneMoreThanMaxFetch = Cursor.maxRecordsPerFetchCall + 1; Cursor instance = new Cursor( 'SELECT Name FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ); List results = instance.setFetchesPerTransaction(2).fetch(0, oneMoreThanMaxFetch); Assert.areEqual(Cursor.maxRecordsPerFetchCall + 1, results.size()); Assert.areEqual(2, Limits.getFetchCallsOnApexCursor()); Set actuallyFetchedNames = new Set(); for (Account account : (List) results) { actuallyFetchedNames.add(account.Name); } Assert.areEqual(expectedFetchNames, actuallyFetchedNames); } @IsTest static void itFetchesMultipleTimesPerTransaction() { Cursor.maxRecordsPerFetchCall = 1; insert new List{ new Account(Name = 'One'), new Account(Name = 'Two') }; Cursor instance = new Cursor( 'SELECT Id FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ) .setFetchesPerTransaction(2); List results = instance.fetch(0, 2); Assert.areEqual(2, instance.getNumRecords()); Assert.areEqual(2, results.size()); results = instance.fetch(2, 1); Assert.areEqual(0, results.size()); } @IsTest static void fetchesCorrectAmountOfRecords() { List accounts = new List(); for (Integer i = 0; i < 10; i++) { accounts.add(new Account(Name = 'Fetch ' + i)); } insert accounts; Cursor instance = new Cursor( 'SELECT Id FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ) .setFetchesPerTransaction(10); List results = instance.fetch(0, 2); Assert.areEqual(2, results.size(), '' + results); Assert.areEqual(1, Limits.getFetchCallsOnApexCursor()); } @IsTest static void doesNotExceedPlatformMaxFetch() { List accounts = new List(); for (Integer i = 0; i < 101; i++) { accounts.add(new Account(Name = 'Fetch ' + i)); } insert accounts; Test.startTest(); Cursor instance = new Cursor( 'SELECT Id FROM Account', new Map(), System.AccessLevel.SYSTEM_MODE ) .setFetchesPerTransaction(100); Integer counter = 0; List results; while (counter <= 100) { results = instance.fetch(counter, counter + 1); counter++; } Test.stopTest(); Assert.areEqual(101, counter); Assert.areEqual(0, results.size()); } } ``` `Cursor`を仮想化することで、大規模なレコード・セットを繰り返す必要がない場合でも、具体的な`CursorStep`の実装を`Database.Cursor`なしで実行できます。これは、バッチApexで`Database.QueryLocator`ではなく`System.Iterable`を返す場合と同様です。次に例を示します。 ```java public abstract class CursorLikeImplementation extends CursorStep { private final Cursor cursorLike; public CursorLikeImplementation(List previouslyRetrievedRecords) { this.cursorLike = new CursorLike(previouslyRetrievedRecords); } public override String getName() { return CursorLikeImplementation.class.getName(); } public override Cursor getCursor() { return this.cursorLike; } private class CursorLike extends Cursor { private final List records; public CursorLike(List records) { super(); this.records = records; } public override List fetch(Integer position, Integer chunkSize) { // clone, to keep the underlying list type List clonedRecords = this.records.clone(); clonedRecords.clear(); for (Integer i = position; i < this.getAdvanceBy(position, chunkSize); i++) { clonedRecords.add(this.records[i]); } return clonedRecords; } public override Integer getNumRecords() { return this.records.size(); } } } ``` このクラスも抽象クラスであるため、`innerExecute`の具体的な実装はサブクラスに任せます。 `CursorLike` の内部サブクラスの代替法もあります。このようなステップの具体的なバージョンが他のガバナ制限で焼き付けられないことがわかっている場合は、`CursorLike.fetch` から`this.records`を返し、親`CursorStep.shouldRestart()`を上書きして false を返すことができます。これにより、非同期トランザクションあたり12 MBのApexヒープ制限のみによって制限されたリストを反復処理できます。 ### その他の可能なステップベースの実装 カーソルベースの実装では、大量のデータをページングするときに十分な柔軟性が得られます。一方、`Step`インターフェイスでは、あらゆる種類のステップを記述してカプセル化できる柔軟性があります。 フローベースのステップを考えてみましょう。 ```java public virtual class FlowStep implements Step { private final Invocable.Action specificFlow; private Boolean shouldRestart = false; public FlowStep(String specificFlowName, Map inputs) { this.specificFlow = Invocable.Action.createCustomAction('flow', specificFlowName); this.specificFlow.setInvocations(new List>{ inputs }); } public void execute() { List results = this.specificFlow.invoke(); for (Invocable.Action.Result result : results) { if (result.isSuccess()) { Map outputParams = result.getOutputParameters(); Object potentialShouldRestartValue = outputParams.get('shouldRestart'); // Flow does not enforce Booleans being initialized // so a null check is sadly necessary here if (potentialShouldRestartValue != null) { this.shouldRestart = this.shouldRestart || Boolean.valueOf(potentialShouldRestartValue); } } else { List errorMessages = new List(); for (Invocable.Action.Error error : result.getErrors()) { errorMessages.add( 'Error code: ' + error.getCode() + ', error message: ' + error.getMessage() ); } Logger.error( 'An error occurred within your auto-launched flow:\n' + String.join(errorMessages, '\n\t') ); } } } public virtual void finalize() { Logger.info(this.getName() + ' finished processing'); } public String getName() { return FlowStep.class.getName() + ':' + this.specificFlow.getName(); } public Boolean shouldRestart() { return this.shouldRestart; } } ``` フローでは Apex で定義されたタイプに準拠する出力パラメータを返すことができないため、使用前に`shouldRestart`出力パラメータが確認されます。 一部のステップは機能フラグが付けられている場合があります。含めるステップを決定するロジックを実装したり、無効化された機能に no-op ステップを使用したりできます。[Null オブジェクトパターン](https://refactoring.guru/introduce-null-object)は、オーケストレーションレイヤー内の複雑さを軽減する一般的な方法です。 ```java @SuppressWarnings('PMD.EmptyStatementBlock') public class NoOpStep implements Step { // The null object pattern is commonly implemented // as a singleton to reduce memory consumption public static final NoOpStep SELF { get { SELF = SELF ?? new NoOpStep(); } private set; } public void execute() { } public void finalize() { } String getName() { return NoOpStep.class.getName(); } Boolean shouldRestart() { return false; } } ``` 今では、多くのビルディングブロックで作業できます。ステップの反復を担当するオーケストレーションレイヤーを見てみましょう。 ## ステッププロセッサーの作成 プロセッサーはアーキテクチャの転換点となります。誰がどのステップをどこで初期化するかを決定する必要があります。次のオプションがあります。 - ビジネスロジックに対応付けるステップをプロセッサーで定義します。このオプションはシンプルですが、読みやすく拡張性に欠けます。 - カスタムメタデータ (CMDT) を使用して対応付けを定義します。メタデータリレーションフィールドでは、クラス名のスペルをビジネスプロセス設定と疎結合にする `ApexClass` はサポートされません。項目を選択リストにしてその種別が存在することを検証 (`Type.forName()` または `ApexClass` を照会) することで、管理者のリスクを軽減できますが、CMDT レコードではトリガーがサポートされないため、検証は実行時に行われます。このルートはテスト可能ですが、システム管理者は本番でのみ CMDT レコードを作成できます。慎重に進めてください。 - レコードとの対応付けを定義します。システム管理者以外もステップを設定できますが、リリースが難しくなり、環境がドリフトする可能性があります。慎重に進め [Clean Code](https://www.oreilly.com/library/view/clean-code-a/9780136083238/) には、この特定の複雑さを処理する方法に関する有名な引用があります。 > この問題の解決方法は、(オブジェクトを作成するための) `switch`ステートメントを抽象工場の地下に埋めて、誰にも見せないことです。 この点を考慮して、現在のステップ数は明確に定義されており、大きくなりすぎることはないため、ステッププロセッサーをステップの工場にすることもできます。これは、switch ステートメントの実行に Enum を使用できます。 ```java public enum StepType { TYPE_ONE, TYPE_TWO, TYPE_THREE, TYPE_FOUR // etc ... } ``` そして、私たちの`StepProcessor`:のために ```java public StepProcessor implements System.Queueable, System.Finalizer, Database.AllowsCallouts { private final List steps = new List(); private Step currentStep; public StepProcessor setSteps(List stepTypes) { for (StepType type : stepTypes) { switch on type { WHEN TYPE_ONE { this.addTypeOneSteps(); } WHEN TYPE_TWO { this.addTypeTwoSteps(); } // ... etc } } this.cleanSteps(); return this; } public void execute(System.QueueableContext context) { this.currentStep = this.currentStep ?? this.steps.remove(0); if (context != null) { System.attachFinalizer(this); Logger.setAsyncContext(context); } Logger.info('Executing step ' + this.currentStep.getName()); try { this.currentStep.execute(); } catch (Exception e) { Logger.exception('Unexpected exception', e); } Logger.info('Finished executing step ' + this.currentStep.getName()); Logger.saveLog(); } public void execute(System.FinalizerContext context) { Logger.info('Executing finalizer for step ' + this.currentStep.getName()); Logger.setAsyncContext(context); switch on context?.getResult() { when UNHANDLED_EXCEPTION { // see the note below about this logging paradigm Logger.warn( 'Failed to run on step' + this.currentStep, context?.getException() ); } when else { this.currentStep.finalize(); if (this.currentStep.shouldRestart()) { this.kickoff(); } else if (this.steps.isEmpty() == false) { this.currentStep = this.steps.remove(0); this.kickoff(); } else { Logger.info('Finished executing steps'); } } } Logger.info( 'Finished executing finalizer for step ' + this.currentStep.getName() ); Logger.saveLog(); } public String kickoff() { return this.steps.isEmpty() ? null : System.enqueueJob(this); } private void cleanSteps() { for (Integer reverseIndex = this.steps.size() - 1; reverseIndex >= 0; reverseIndex--) { if (this.steps[reverseIndex] instanceof NoOpStep) { this.steps.remove(reverseIndex); } } } private void addTypeOneSteps() { this.steps.addAll( new List { new ExampleCursorStepOne(), new ExampleCursorStepTwo() } ); } private void addTypeTwoSteps() { this.steps.addAll( new List { new FlowStep(' ExampleInvocableName', new Map( 'exampleParameter' => true) ), new ExampleCursorStepThree() } ); } } ``` 表示されたファクトリメソッド (`addTypeOneSteps()` など) は、機能のフラグ設定などの懸念事項を委任できます。`cleanSteps()` は、収集されたステップに対して 1 回チェックを実行し、「空の」ステップがないことを確認してから、実際に非同期にします。これは次のようになります。 ```java private Step getStepOrDefault(String customPermissionName, Step defaultStep) { if (System.FeatureManagement.checkPermission(customPermissionName)) { return defaultStep; } return NoOpStep.SELF; } ``` \[スケジュール済みフロー] セクションで Nebula Logger に言及して以来、エラー処理については説明していません。これは、`System.Finalizer`を使用すると、各ステップで特定のエラー処理を追加することなく、すべてのエラー条件のログを包括的にカバーできるためです。各`Step`は実行に焦点を絞りますが、単体テストで問題のあるパスがあれば記録して再スローします。これにより、安全な反復と本番レベルのアラートがサポートされます(すべてのWARNログとERRORログで[Nebula用Slack Loggerプラグイン](https://github.com/jongpie/NebulaLogger/tree/main/nebula-logger/plugins/slack)を使用)。 エラーログに関する 1 つの注意事項: ログメッセージにステップインスタンスを渡すと、ログに表示される内容のTrust性が想定されます。Apexクラスのデフォルト `toString()`には、すべての静的プロパティとインスタンス レベル プロパティがメッセージに含まれます。これは望ましいことですが、機密情報が漏洩する可能性もあります。ここではロギングとセキュリティは重視しませんが、一部のシステムでは、`Step` などのインターフェイスに準拠するために、`toString()`の上書きを強制することもあります。 ```java public interface Step { void execute(); void finalize(); String getName(); Boolean shouldRestart(); String toString(); } ``` このような方法では、各オブジェクト作成者に責任を負わせて、印刷を許可する内容を決定します。 ログ レベル:`StepProcessor` レベルでは、エラーでない最も高いレベルである`INFO`が使用されます。アプリケーション内の詳細度が高くなると、それに応じてログレベルも低下します。個々のステップでは、概要レベルの情報に `DEBUG` を使用し、より詳細な出力用に `FINE`、`FINER`、`FINEST` を予約できます。ロギングは科学と同じくらい技術ですが、これらの原則に従うことでログの一貫性と有用性を保つことができます。 ### ステッププロセッサー内での追加の複雑さの処理 先に進む前に、ステッププロセッサーでステップを使用するロジックをホストするという決定について簡単に振り返ってみましょう。大規模なコードベースでは、`StepProcessor`を仮想または抽象にすることを検討し、サブクラスに特定のステップを特定させて、適切な懸念の分離を確立します。 ## Apex 呼び出し可能レイヤー スケジューラは最終的に Apex を呼び出します。残りの設定が完了したら、「呼び出し可能な Apex」セクションで実行するステップを決定し、`List`をプロセッサーに渡すことができます。 ```java public class DailyJobExecutor { @InvocableMethod(label='Execute Daily Job') public static void executeJob() { Logger.info('Executing daily Job'); List correspondingTypes = new List(); // based on [business logic], determine which step types // should be included for any daily invocation if (correspondingTypes.isEmpty() == false) { try { new StepProcessor().setSteps(correspondingTypes).kickoff(); } catch (Exception ex) { Logger.exception('Error starting job', ex); } } } Logger.saveLog(); } ``` これは、レコード、データ、またはロジックを使用して実行するステップ種別を決定するという、方程式の簡単な部分です。呼び出し可能なアクションは、他の場所で複雑さをカプセル化しているためシンプルです。また、予期しない例外から保護され、各ピースを個別に簡単にテストできるようになりました。 ## Slack への通話前の遅延の処理 [Apex Slack SDK](https://developer.salesforce.com/docs/platform/salesforce-slack-sdk/guide/overview.html) はこの記事の範囲外ですが、要件に関する潜在的な問題として、ロール階層の上位にあるユーザーへの設定可能な遅延に基づく通知を再確認する必要があります。書類上、これは単純であり、`StepProcessor`の`System.enqueueJob(this)`を(正しく)考慮する可能性があります。[System.AsyncOptions](https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_class_System_AsyncOptions.htm) では、この要件を満たすために`enqueueJob`オーバーロードを使用するのが最初の傾向でした。 ただし、現時点では、`System.AsyncOptions.MinimumQueueableDelayInMinutes` 経由の最大遅延は 10 分です。要件は 120 分であるため、いくつかのオプションが残っています。ナイーブなアプローチは次のようになります。 ```java public class ExampleDelayedNotifier implements Step { private final List notifications = new List(); private final Slack.BotClient botClient = Slack.App .getAppByKey('some-slack-app-key') .getBotClientForTeam('slack team id'); // account for the initial delay, // so 120 - 10 = 110 private Integer delayMinutes = 110; public void execute() { if ( this.delayInMinutes > 0) { return; } Integer maximumAllowedCallouts = 100; while (this.notifications.isEmpty() == false && maximumAllowedCallouts > 0) { this.botClient.chatPostMessage(this.notifications.remove(0)); maximumAllowedCallouts--; } } public void finalize() { this.delayInMinutes -= 10; } public String getName() { return ExampleDelayedNotifier.class.getName(); } public Boolean shouldRestart() { return this.delayInMinutes > 0 || this.notifications.isEmpty() == false; } } ``` 実際には、遅延は設定駆動であるため、このクラスに遅延が渡されます。 遅延通知種別が 1 つしかないことが確実な場合を除き、この方法はお勧めしません。開始前に 11 個の追加非同期ジョブが実行されます (遅延が増加した場合はそれ以上)。そのコストは、1 つの作業で十分かもしれませんが、多くの作業では必要ありません。また、`Step` インタフェースにメソッドを追加して、各ステップで再起動までの待機時間をプロセッサーに指示できるようにする必要があります。これにより、ノイズが増加します。 次の 2 つの興味深い可能性が考えられます。 - ポーリングジョブがすでに適切な間隔でスケジュールされている場合、既存のジョブフレームワークに遅延ステップを挿入できます。また、指定した遅延が最大 15 分経過しても問題ありません(15 分は Apex でスケジュールされた CRON 式の最小更新間隔)。これは、呼び出し可能な Apex の例にほぼ一致し、代わりに Apex を介してスケジュールが実行されます。つまり、同じ`Step` ベースのアーキテクチャを再利用して、[Start After]タイムスタンプに基づいてレコードを処理し、前に表示した`StepType`列挙値への選択リストまたは複数選択リストの対応付けに基づいて使用するステップを決定できます。 - または、追加の外部 Apex クラスを定義する場合は、`System.scheduleBatch()` を使用して一括 Apex にフォールバックします（内部クラスをサポートする Queueable Apex とは異なり、一括 Apex クラスは外部クラスである必要があります）。 Batch Apexの例を考えてみましょう。一般的に、柔軟性と制御性のために Queueable Apex をお勧めしますが、これはバッチ Apex が依然として優位なケースの 1 つです。 ```java public class DelayedNotifier implements Database.Batchable { private final StepProcessor processor = new StepProcessor(); public Iterable start(Database.BatchableContext bc) { return new List(); } @SuppressWarnings('PMD.EmptyStatementBlock') public void execute(Database.BatchableContext bc, Object scope) { // we don't need to actually do anything in execute, // we just need to start up the processor in finish } public void finish(Database.BatchableContext bc) { try { // you can imagine Notifier as an elided, // simpler version of the naive implementation // we showed above, now only focused on sending messages this.processor.setSteps(new List{ new Notifier() }).kickoff(); } catch (Exception ex) { Logger.exception('Unexpected error', ex); } finally { Logger.saveLog(); } } } ``` 次に、`StepProcessor` で、前に示した `addTypeOneSteps()` メソッドがこの遅延ステップで更新されたとします。 ```java public StepProcessor implements System.Queueable, System.Finalizer, Database.AllowsCallouts { // .... unchanged top of class elided private void addTypeOneSteps() { this.steps.addAll( new List { new ExampleCursorStepOne(), new ExampleCursorStepTwo(), new DelayedNotifierStep() } ); } // ... private class DelayedNotifierStep implements Step { private final DelayedNotifier delayedNotifier = new DelayedNotifier(); // again — in practice this value would also be passed in private final Integer delayInMinutes = 120; public void execute() { System.scheduleBatch( this.delayedNotifier, 'Delayed notifier: ' + System.now().getTime(), this.delayInMinutes ); } public void finalize() { Logger.debug('Nothing to finalize, batch scheduled'); } public String getName() { return DelayedNotifierStep.class.getName(); } public Boolean shouldRestart() { return false; } } } ``` 通常、この程度のフープジャンプはお勧めしませんが、このステップの遅延がもう 1 つの再利用可能なビルディングブロックになります。Queueable Apex で長い遅延が許可されるまでは、この方法は、この効果を生成する最も簡単な方法でもあります(ポーリング メカニズムを使用しない場合については後述)。 ## 結論 要件を満たすためにオブジェクト指向設計を使用し、長期的な構築コストとメンテナンスコストのバランスを取りながら拡張できるシステムを作成しました。ステップの宣言とインスタンス化は最終的に`StepProcessor`での位置を超える可能性がありますが、技術的な負債はほとんどありません。`FlowStep`を使用すると、システム管理者と開発者は、ノーコード ソリューションまたはプロコード ソリューションが最も合理的なタイミングを一緒に決定できます。 Apexのキュー可能フレームワーク内の`System.Finalizer`・インタフェースをNebula Loggerとともに使用することで、今後のステップで明示的なログ記録が欠落している場合でも、予期しない障害を警告する堅牢でテスト可能なシステムを構築しました。当社にとって、このシステムはコストと複雑さを軽減し、楽しく数字を計算できます。また、実際のワークロードでのApexカーソルの動作に関する貴重なインサイトが得られ、機能自体を改善しながらアプローチを改善できるようになりました。 ステップベースの非同期処理フレームワークフレームワークは、複雑で大量のワークロードをモジュール化された実行ステップに分解することで、プラットフォームの制約をエンジニアリング上のメリットに変換し、エンタープライズ規模の予測可能なパフォーマンス、可観測性、ガバナンスを実現します。ステップはシステム管理者と開発者の両方が設定でき、いずれの場合もステップ作成者は各ステップの拡張方法を心配することなく、プラットフォームの基本的なガバナ制限 (DML 行や取得されるクエリ行など) の遵守に集中できます。 ## Path Forward (パス転送) エンタープライズ実装全体でこのパターンを運用して採用するには、アーキテクトは次の要件を満たす必要があります。 - **既存の自動化**を評価して、非同期オーケストレーションがパフォーマンスの向上と可観測性の向上に役立つ領域を特定します。 - 明確な処理目標と個別の作成者ポイント（フロー、Apexなど）を使用して、大きな**プロセスを**個別に実行可能なステップに分割します。 - **ステップ種別を定義**してグループ化し、ビジネスユニット間でのステップの再利用と標準化を促進します。 - 新しいプロセスまたは既存の自動化を使用して**アプローチをパイロット**します。ステップ内で無料で見つけることができるエッジケースの数に驚くかもしれません。 ## 著者について James Simone は Salesforce のプリンシパルソフトウェアエンジニアであり、このプラットフォームで 10 年以上働いた経験があります。開発に移行する前はSalesforceのお客様であり、製品所有者でした。また、2019年から[The Joys Of Apex](https://www.joysofapex.com/)でSalesforceに関する技術的な詳細を執筆されています。以前には[Salesforce開発者ブログ](https://developer.salesforce.com/content-archive?authors=James%20Simone&content-type=Blogs&language=English)と[Salesforceエンジニアリングブログ](https://engineering.salesforce.com/author/james-simone/)でも記事を公開しています。 ## ガイドの概要 Salesforce Platform でのフォームの作成を検討していますか?ローコードからプロコードまで、連続する複数のオプションがあります。ローコードを表すのは、Lightning アプリケーションビルダーの動的フォームと Flow Builder の画面フローです。連続性の真ん中に位置するのは、LWC を使用して画面フローを拡張し、OmniStudio を使用して顧客向けフォームを作成する機能です。また、プロコードを表すものとして、LWC フレームワークとその成長を続けるベースコンポーネントのライブラリがあります。 オプションは優れていますが、どのオプション (またはどの組み合わせ) が適切なオプションかを判断する方法は?そこでこのガイドの出番です。 ## 重要ポイント - **ポイント#1:Lightning ページの作成/編集/表示レイアウトを作成する場合は、動的フォームを使用します。**このガイドの比較表にページレイアウトが含まれていないことに気付くかもしれません。今後、レコード詳細ページを設定するために推奨される方法は、Lightning アプリケーションビルダーで動的フォームを使用することです。[ページレイアウト](#ページレイアウト)をさらに強化する予定がない理由についての詳細は、「ページレイアウト」のセクションを参照してください。 - **ポイント#2:1 つのオブジェクトのみの作成フォームまたは編集フォームを作成する必要がある場合は、まず Lightning ページと動的フォームを作成します。**これは、Salesforce Platform でフォームを作成する最も簡単な方法です。また、項目の表示を制御する機能など、いくつかの追加機能も提供されます。要件がより高度な場合は、読み進めてください。画面フロー、OmniStudio、または Lightning Web Components(LWC)が適しています。 - **ポイント#3:複数ページのフォームまたはウィザードを作成し、厳格な UX 要件やブランド要件がない場合は、画面フローから開始します。**画面フローには、複数のフォームをまとめて調整するための線形ナビゲーションフレームワークが用意されています。LWC を使用して、フォーム間を移動する独自のフレームワークを構築できますが、[フォームの状態](/docs/architect/ja-jp/well-architected/guide/engaging#フォーム)を気にすることなくフォーム自体に集中できるように、難しい作業はフローに任せることをお勧めします。 - **ポイント#4:*フォームの背後*に追加のロジックまたはアクションが必要な場合は、画面フロー、OmniStudio、または LWC を使用します。**これら 3 つのツールはすべて、ソリューションで 1 つのレコードの作成や編集以上のことを行うための手段を提供します。この「さらに」は、分岐や反復などの高度なロジックの場合もあれば、外部システムとの統合、メールの送信、ユーザーのモバイルアプリケーションへの通知の転送などのアクションの場合もあります。 - **ポイント#5:高度な UX 要件がありますか?表示以外の機能を動的に処理する必要がある場合は、LWC または OmniScript を使用します。**シンプルなテーマ設定と列ベースのレイアウトで要件を満たせる場合は、ローコードビルダーで直接フォームを作成できます。フォームのスタイルをより詳細に制御するには、LWC の優れた柔軟性が必要です。Industries のお客様で、ピクセル単位の完璧なブランド設定が必要な場合や複雑な階層データがある場合、OmniStudio を使用すると、複雑なビジネスロジックとデータ変換を処理できるコンシューマーグレードのフォームを作成できます。 - **ポイント#6:テストの自動化が必要な場合は、Lightning Web コンポーネントから開始します。**どの LWC に組み込むかに関係なく、LWC の単体テストを作成できます。これにより、複数のレコードを使用した一括テストやネガティブテストなど、より堅牢なテスト戦略を作成できます。フォームが機能要件と非機能要件にどの程度適合しているかを確認するテストの作成についての詳細は、「[Salesforce Well-Architected - Testing Strategy](/docs/architect/ja-jp/well-architected/guide/resilient#テスト戦略) (Salesforce の適切な設計 - テスト戦略)」を参照してください。 選択肢は、どちらかまたは両方である必要はありません。複数のオプションを組み合わせることができます。たとえば、フローの組み込みナビゲーションシステムと、LWC が提供する完全なスタイル設定の柔軟性の両方が必要な場合は、これらを併用します。 ## Salesforce でフォームを作成するためのツール 次の表に、Salesforce でフォームを作成するために使用できるツールとその必須スキルおよびライセンスに関する考慮事項を示します。後で、各ツールでサポートされている特定の機能と、クリックベースのツールとコードベースのツールのどちらを選択するか (および組み合わせるタイミング) について詳しく説明します。
必要なスキル その他のライセンス要件
動的フォーム ローコード いいえ
画面フロー ローコード いいえ
OmniStudio ローコード + プロコード Industries パッケージが必要
画面フロー + Lightning Web コンポーネント ローコード + プロコード いいえ
Lightning Web コンポーネント プロコード いいえ
## 一目でわかる決定ポイント 次の表に、商品を選択するときに考慮すべき決定ポイントと、各決定ポイントについて自問すべき質問の概要を示します。このガイドの残りの部分では、これらの各トピックについて詳しく説明します。
オブジェクトへの影響 フォームを 1 つのオブジェクトに対して操作するのか、複数のオブジェクトに対して操作する必要があるのかを決定します。
フォームの範囲とナビゲーション フォームのすべての項目を 1 つの画面に論理的に収まるようにするか、ユーザーが複数の画面間を移動できるようにするかを決定します。
場所 フォームを埋め込む場所 (Salesforce アプリケーション内からモバイルアプリケーション、さらには外部 Web サイトまで) を特定します。
Controller データ変換や外部システムとのインテグレーションなど、ユーザーがフォームを操作しているときにバックグラウンドで実行する必要があるアクションやロジックを特定します。
入力規則 Salesforce が提供する標準システムレベル検証を超える追加の入力検証要件があるかどうかを確認します。
セキュリティ 特定の操作を実行する前にフォームでユーザーのアクセス権を確認する必要があるかどうか、フォームにアクセスできるユーザーを制御するかどうか、フォームを埋め込む場所を制御するかどうかを決定します。
インタラクション設計 フォーム内で動的応答をトリガーする必要があるインタラクションまたは条件の種別を特定します。
スタイル 目的のスタイルと CSS の洗練度を決定します。
レイアウト 必要な列数、タブ数、アコーディオン数、繰り返しデータブロックの表示機能の観点から、フォームのレイアウト要件を特定します。
トランスレーション フォームを他の言語にローカライズする必要があるかどうかを判断します。
UI テストの自動化 DevOps プロセスでフォームの自動単体テストと自動エンドツーエンドテストのどちらを実行する必要があるかを判断する
メトリクス ページビュー、フォームに費やした時間、完了率、成功率など、フォームの利用状況を追跡する方法を特定する
パッケージ化とリリース フォームの作成後に配布またはリリースする方法を決定します。
比較表で使用する用語とその定義を次に示します。 - **使用可能:**基本的な考慮事項で適切に機能します。 - **理想的ではない:**機能しますが、最適なツールではありません。 - **ロードマップ:**今後 12 か月 (2025 年 6 月) 以内のサポート予定。 - **将来**:今後 12 か月を超えるサポートの見積。 - **使用不可:**今後 12 か月以内にこの機能をサポートする予定はありません。 ## Decision Point ウォークスルー お約束のとおり、動的フォーム、画面フロー、OmniStudio、組み込み LWC を使用する画面フロー、および LWC フレームワーク自体のさまざまな比較ポイントと機能の違いについて詳しく見ていきましょう。 ### オブジェクトへの影響 フォームが 1 つの Salesforce オブジェクトに対して操作される場合、比較しているツールはどれも機能します。クロスオブジェクトフォームやオブジェクトに依存しないフォームでは、状況は少し複雑になります。オブジェクトに依存しないとは、どの Salesforce オブジェクトにも対応付けられない入力を意味します。フォームは、Stripe や DocuSign などの外部サービスに送信するデータ構造を表す場合があります。または、フォームで複数の入力を使用して値を計算して、その値をデータベースにコミットしている場合があります。 #### 質問する内容: - フォームの操作対象オブジェクトは? - 1 つのオブジェクトのみか、複数のオブジェクトか? - 特定のオブジェクト (取引先、取引先責任者、商談、リード、ケースなど) を使用しているか、フォームを他のオブジェクトでも使用する必要がありますか?
単一オブジェクト クロスオブジェクト オブジェクトに依存しない
動的フォーム 利用可 利用可 利用不可
画面フロー 利用可 利用可 利用可
OmniStudio 利用可 利用可 利用可
Screen Flow + LWC 利用可 利用可 利用可
LWC 利用可 利用可 利用可
クロスオブジェクトフォームとオブジェクトに依存しないフォームの両方で、Flow と OmniStudio はどちらも有効なオプションです。フロー画面で使用できるコンポーネントは本質的にすべてに対応しているため、バックグラウンドでそのデータをどのように処理するかを選択できます。たとえば、1 つのフォームに入力されたデータを使用してバックグラウンドで複数のレコードを作成したり、データを使用して Chatter 投稿の生成、Slack メッセージの送信、メールの送信、外部サービスへの接続などの他のアクションを実行したりできます。 単純なケースでは、Lightning-record-form などの既存の LWC コンポーネントを使用することで、堅牢なソリューションを提供するために必要なコードを削減できます。ただし、複数のオブジェクトが関連するシナリオでは、フローですべてのオブジェクトを包括的に制御できるため、開発者が複雑なリレーションや連動関係を移動する必要がなくなります。 OmniStudio は、さらに一歩先を行き、ユーザーに表示されるフォームを基盤となるデータモデルから分離し、完全にオブジェクトに依存しません。代わりに、OmniStudio は、[データ マッパー](https://help.salesforce.com/s/articleView?id=sf.os_dataraptors.htm&type=5)や[インテグレーション手順](https://help.salesforce.com/s/articleView?id=sf.os_omnistudio_integration_procedures_48334.htm&type=5)などのツールを使用して、Salesforce オブジェクト (または外部データ) にマッピングされた基礎となる JSON を操作します。データマッパーと Integration Procedure は、OmniStudio フォームを Salesforce の内部および外部のデータに接続するための 2 つの主要なコンポーネントです。ドラッグアンドドロップ要素を使用して、外部システムの複雑な階層データを操作してから、データの格納場所に応じてニーズに合わせてデータを変換できます。また、数式を使用して、Apex のように配列やデータのリストに対して計算やロジックを実行することもできます。 [OmniStudio Integrations_OmniStudio Integrations_](/docs/architect/ja-jp/reference-diagrams/guide/omnistudio-integrations) ### フォームの範囲とナビゲーション 1 つの画面フォームからすべてのユーザー入力を取得できる場合は、動的フォームから開始します。ただし、レコードページの動的フォームではパス機能を使用してビジネスプロセスのさまざまなフェーズを緩やかに表すことができますが、ほとんどの使用事例には適していない可能性があります。 #### 質問する内容: - 1 つの画面が必要ですか? それとも、ユーザーが ToDo を完了するために複数の画面間を移動する必要がありますか? - フォームへの入力プロセスの進行状況を視覚的にユーザーに表示しますか? - ユーザーは各画面の情報を特定の順序で入力する必要がありますか? それとも、必要に応じて画面を行き来できるようにする必要がありますか?
単一画面 マルチ画面フォーム 進行状況インジケーター ステップ/画面間のジャンプナビゲーション
動的フォーム 利用可 利用不可 利用可 利用不可
画面フロー 利用可 利用可 利用可 利用不可
OmniStudio 利用可 利用可 利用可 利用可
Screen Flow + LWC 利用可 利用可 利用可 利用可
LWC 利用可 理想的ではない 理想的ではない 理想的ではない
動的フォームで提供される機能よりも多くの機能が必要な場合は、フロー、OmniStudio、LWC のいずれかを選択するかどうかも、他のいくつかの質問に応じて異なります。 - チームにはどのようなスキルがありますか?管理者の作業負荷が高い組織では、フローから開始することをお勧めします。Industries ソリューションがある場合、チームはすでに OmniStudio に精通しており、プロジェクトの UX 要件が厳しいため、OmniStudio から開始します。 - フォームの下部にナビゲーションバーを表示しても問題ありませんか?画面フローと OmniScript ナビゲーション環境が望ましくない UX の場合、LWC に傾けます。 - フォームの背後で何を実行する必要があるか?システム管理者が設定できる動作が必要な場合は、フローを作成するか、項目の表示ラベルの変更などの基本的な変更については OmniScript を作成します。それ以外の場合、複雑な複数オブジェクトリレーションでは OmniScript または LWC を作成します。 - フローまたは OmniStudio を選択した場合は、適切な UX を実現するために LWC の構築が必要な場合があります。フォームのスタイルを正しく設定するために LWC をすでに作成している場合は、[そのコンポーネントを](https://developer.salesforce.com/docs/platform/lwc/guide/use-flow-embed-component.html)フローに埋め込むことが過剰ではないかどうかを検討してください。 一方、ユーザーが複数の画面間を移動するウィザードのようなソリューションの場合は、フローまたは OmniStudio を検討します。フローと OmniStudio には組み込みのナビゲーションモデルが付属しているため、複数の LWC を作成して管理する必要はありません。ナビゲーションは直線的で、前方に移動するアクション、後方に移動するアクション、後で使用するためにフォームを保存するメカニズムがあります。目的に応じて、非線形ナビゲーションを使用するフォームを作成することもできます。画面フローを使用した優れた例については、Salesforce Labs の [Digital Store Audit](https://appexchange.salesforce.com/appxListingDetail?listingId=a0N3A00000FMkOtUAL) パッケージを参照してください。 OmniStudio では、フォームの「ステップ」が表示される標準ナビゲーションから進行状況インジケーターが表示されるため、ナビゲーション上の重要な利点があります。このステップビューには、ユーザーが特定の複数ステップフォームのどこにいるかが自動的に表示されます。フローとは異なり、ユーザーはフォームのさまざまなステップをクリックして画面間を「ジャンプ」できます。 単一画面フォームを作成するか複数画面フォームを作成するかに関係なく、ユーザーが操作しやすいようにフォームが[合理化さ](/docs/architect/ja-jp/well-architected/guide/engaging#フォーム)れていることを確認してください。 ### 場所 フォームを標準の Lightning レコードページに埋め込む場合、動的フォームは現在デスクトップでのみ使用できるという警告付きで、比較対象のどのツールでも機能します。ただし、ユーザーが他の場所からフォームにアクセスできる環境を提供する場合、代替オプションを考慮する必要がある場合があります。 #### 質問する内容: - ユーザーはデスクトップ、モバイル、またはその両方からフォームにアクセスする必要がありますか? - ユーザーがユーティリティバーを使用してアプリケーションのどこからでもフォームにアクセスできる必要がありますか? - クイックアクションを使用して、ユーザーが現在表示しているページから移動せずにフォームに入力できるようにしますか? - フォームを外部 Web サイトで使用可能にする必要がありますか?
Lightning レコードページ Lightning ホームページまたはアプリケーションページ Aura Experience Cloud サイト LWR Experience Cloud サイト 組み込みSnap-In ユーティリティバー オブジェクト固有のアクション グローバルアクション Salesforce モバイルアプリケーション** Field Service Mobile Mobile SDK 外部サイトおよびアプリケーション カスタム LWC
動的フォーム 利用可 使用不可 使用不可 使用不可 使用不可 使用不可 使用不可 使用不可 利用可 使用不可 使用不可 使用不可 使用不可
画面フロー 利用可 利用可 利用可 利用可 利用可 利用可 利用可 ロードマップ 利用可 使用可能*** 使用不可 ロードマップ 利用可
OmniStudio 利用可 利用可 利用可 利用不可 利用不可 利用可 利用不可 利用不可 利用可 使用不可 使用不可 利用可 利用可
Screen Flow + LWC 利用可 利用可 利用可 利用可 利用可 利用可 利用可 ロードマップ 利用可 使用不可 使用不可 理想的ではない 利用可
LWC 利用可 利用可 利用可 利用可 利用可 利用可 ロードマップ ロードマップ 利用可 ロードマップ ロードマップ 利用可 利用可
*フローは LWR Experience Cloud サイトに組み込むことができますが、留意する必要がある考慮事項があります。
** フローと LWC は Salesforce モバイルアプリケーションでサポートされていますが、Salesforce モバイルアプリケーションではフローと LWC を埋め込む方法がすべてサポートされているわけではありません。たとえば、オブジェクト固有のアクションはモバイルでサポートされますが、ユーティリティバー項目はサポートされません。
***Field Service Mobile アプリケーションは、古いフローエンジンと画面フローランタイムから設計されているため、最新のフロー機能の多くをサポートしていません。オフラインで機能するように特別な変更が加えられています。
動的フォームにはレコードコンテキストが必要なため、Lightning レコードページでのみサポートされます。ただし、動的フォームは Experience Cloud ページではサポートされません。この制限は、Experience Cloud で動的フォームが依存する基礎となるフレームワークが使用されないためです。Lightning ページ。Experience Cloud の動的フォームの要求に基づいてこれを評価しています。 レコードコンテキストを必要とするフローやグローバルに機能するフローを作成できます。そのため、さまざまな場所にフローを埋め込むことができます。レコードコンテキストフローの場合、Lightning レコードページ、Experience Cloud レコードページ、オブジェクト固有のアクション、またはアクション & おすすめリリースを使用できます。グローバルフローの場合、ユーティリティバー、他の Lightning ページまたはエクスペリエンスビルダーページ、Snap、外部アプリケーションなどがあります。現在、フローはグローバルアクションとしてサポートされていませんが、回避策として Aura コンポーネントでフローをラップできます。 OmniStudio では、フローを配置できるほぼすべての場所に配置できる構成可能な FlexCard と OmniScript を作成できます。ただし、構成可能ですが、パッケージ化することはできません。 LWC では、Salesforce 全体、コミュニティ、さらにはオープンソースプロジェクトでもメタデータを使用して対象に関連付けることができるコンポーネントが作成されるため、高度な再利用がサポートされます。LWC コンポーネントは、[Lightning Out](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lightning_out) を使用して独自の Web サイト内に埋め込むこともできます。 [外部サイトでのLightning Out_外部サイトでの Lightning Out_](/docs/architect/ja-jp/reference-diagrams/guide/lightning-out-on-external-sites) Lightning Web コンポーネントは現在、クイック アクション （オブジェクト固有またはグローバル） としてサポートされていませんが、回避策として、フローの場合と同様に、LWC を Aura コンポーネントでラップできます。LWC コンポーネントは、[Lightning フロー](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation) コンポーネントを使用してフローを起動することもできます。 OmniStudio は、OmniOut 機能を使用してコンテンツを外部サイトに公開するのに適しています。OmniStudio と OmniOut を使用すると、OmniScript フォームと FlexCard コンポーネントを標準コンポーネントにコンパイルし、サードパーティサイトまたはアプリケーションでプラットフォーム外で実行できます。 このガイドで扱うフォーム技術は、現在 Mobile SDK テンプレートで正式にサポートされていません。Mobile SDK が使用事例に不可欠である場合は、Salesforce Well-Architected[フォーム要素](/docs/architect/ja-jp/well-architected/guide/engaging#フォーム要素)ガイダンスに留意しながら、モバイル アプリケーションでネイティブにフォームを作成するか、Visualforce ページを作成することをお勧めします。 **ロードマップメモ:**Mobile SDK チームは、Visualforce ページ内の LWC のサポートに積極的に取り組んでいます。 ### コントローラー 動的フォームは、フォームの値を使用してレコードを作成または更新する必要がある場合に最適です。それ以上の機能を使用するには、フロー、OmniStudio、または LWC を使用する必要があります。これらの機能には、判断や反復のレイヤー、フォームからの入力を使用した Slack 投稿やメールの生成などがあります。 #### 質問する内容: - バックグラウンドで実行するアクションまたはロジックは? - データモデルに階層データが含まれていますか? - フォームの操作は 1 つのトランザクション内で完了する必要があるか、複数のトランザクションで完了する必要があるか? - 外部システムと統合する必要がありますか? - 再利用性とモジュール性の要件は?
ログとアクション 階層データ管理 1 つのトランザクション内で操作 複数のトランザクションでの操作 Integration の制限と考慮事項」 モジュラー設計と再利用 パッケージ
動的フォーム 利用不可 利用不可 利用不可 利用不可 利用不可 利用不可 利用可
画面フロー 利用可 ロードマップ 利用可 利用可 利用可 利用可 利用可
OmniStudio 利用可 利用可 利用可 利用可 利用可 利用可 利用不可
Screen Flow + LWC 利用可 利用可 利用可 利用可 利用可 利用可 利用可
LWC 利用可 利用可 利用可 利用可 利用可 利用可 利用可
フローには、Slack への投稿、メールの送信、Quip 文書の操作を行うための標準アクションが用意されているため、これらの操作のコードを記述する必要はありません。LWC は、[ユーザーインターフェース API](https://developer.salesforce.com/docs/atlas.en-us.uiapi.meta/uiapi/ui_api_get_started.htm) とやりとりするワイヤーアダプターを使用して、1 つのレコードと関連オブジェクトとの豊富なやりとりを提供します。LWC は、[getListInfoByName](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/reference_get_list_info_by_name.html) 用の回線を使用する場合にも複数のレコードを操作できます。 [ワイヤ アダプタを介した LWC のインタラクション_Lightning Web Components Interaction via Wire Adapters_](/docs/architect/ja-jp/reference-diagrams/guide/lightning-web-components-interaction-via-wire-adapters) 前述のように、OmniStudio では Integration Procedure とデータマッパーを使用して、Salesforce の外部および内部のデータを簡単に取得して変換できます。使用できる多数のコードフリー関数により、さまざまなレベルのリレーションでデータセットをフラット化および拡張できます。 **ロードマップメモ:**フローでは、レコードコレクションの更新/挿入機能と階層データの管理機能がまもなくサポートされる予定です。 フロー、OmniStudio、LWC はすべて Apex と統合されるため、選択したソリューションのギャップを簡単に埋めることができます。たとえば、LWC からのレコードの絞り込みが必要な場合は、常に Apex のワイヤ アダプタを使用して複雑な SOQL クエリを作成できます。クリック ベースのストーリーに悩まされている場合は、サーバー側のニーズに合わせて、Apex コントローラーに代わる実行可能な方法としてフローまたは OmniStudio を検討してください。 ここでの副次的な質問は、アクションをすぐに確定するか、フォームの特定の部分に割り当てるかです。これは、複数ページのフォームを使用している場合に特に関連します。フローを使用すると、複数のフォーム (フロー画面) からの入力を簡単に組み合わせることができ、ウィザード (フロー) の後半でそれらを使用していくつかの操作を実行できます。実際には、ユーザーが画面を行ったり来たりして回答が変わったりした場合に備えて、フローはこの方法で設計することをお勧めします。 #### 操作の制御 Salesforce Platform では、トランザクションと [Virtustream の制限](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)が適しています。使用事例が非常に単純な場合、特定の操作が発生するトランザクションを制御することはさほど重要ではない可能性があります。ただし、複数の操作を複数の[トランザクション](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#トランザクション)で実行するのではなく、1 つのトランザクションに組み合わせる必要がある使用事例がいくつかあります。いくつかの例: - **ロールバックするかしないか**:それが問題だフォームでバックグラウンドで複数のレコードを作成するとします。3 番目のレコードの作成に失敗した場合、最初の 2 つのレコードをロールバックする必要がありますか?各アクションが互いに独立している場合は、自由に個別のトランザクションで実行できます。ただし、それらが連動していて、1 つの障害で他の障害もロールバックする必要がある場合は、1 つのトランザクションに実装します。フォームがフロー内にある場合、障害パスのロールバック要素を使用してトランザクションをロールバックし、データの整合性を確保できます。 - **ガバナ制限に対する下流への影響**:特に、フォームでレコードを作成または更新する場合は、その操作の下流への影響を考慮してください。このレコード変更に基づいて起動されるプロセス、ワークフロールール、フロートリガー、Apex トリガー、または保存順序の他の項目は?また、これらの一括変更は、そのトランザクションで消費されるガバナ制限にどのように影響しますか?特定のレコードの変更によってダウンストリームの変更が多数発生し、制限に影響する場合は、そのレコードの変更を独自のトランザクションに分離することを検討してください。 - **バッチ処理**:UI コンテキストでも、複数の更新を一括処理する必要がある場合があります。複数画面フォームで大量のレコードを反復処理するとします。各画面の後にレコードの更新を確定するのではなく、すべてのレコードの更新を収集してから、すべてのレコードを更新する要求を 1 回送信します。 動的フォームを使用してレコードを作成または編集する場合、1 つの操作のみを実行し、その操作は常に純新規トランザクションの開始になります。 画面フローを作成する場合、特定のトランザクションで何を実行するかを大幅に制御できます。画面とローカルアクションは、トランザクション間の境界として機能します。画面フローアーキテクチャでトランザクションを管理する方法の概要を次に示します。 1. エンドユーザーは画面を操作し、\[**次へ]** をクリックします。 2. クライアントは入力を使用して要求を API に投稿します。 3. API が要求を受信し、トランザクションとデータベース接続が開かれます。次に、API がフローエンジンをコールして要求を呼び出します。 4. フローエンジンはフロー定義の適切なパスを引き継ぎ、画面または \[ローカルアクション] ノードに到達するまで辿ります。その後、エンジンはそのノードに関する情報を API に返します。 5. API は、次に表示する画面の詳細を含む応答オブジェクトを作成し、そのオブジェクトをクライアントに返します。この時点で、データベースの変更がコミットされ ([保存注文実行](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#データベース操作)のキュー)、データベース接続とトランザクションが閉じられます。 6. クライアントは API 応答を使用して、ユーザーが操作する次の画面を表示します。 7. ステップ 1 から繰り返します。 つまり、画面では取引が「中断」されます。その場合、待機中のアクションまたは DML がコミットされ、前のトランザクションがクローズされ、新しいトランザクションが開始されます。
複数画面フロー 適切な設計 (特定のトランザクションにどの操作をグループ化するか) は、コールです。いくつかの例を見てみましょう。
個別のトランザクションを含む画面フロー
左側には、複数の画面で入力を収集し、1 つのトランザクションで複数のアクションを実行するフローが表示されています。
右側のフローは、各操作を個別のトランザクションで実行します。
フローチームは最近新しい要素を導入しました。[レコードをロールバック] 要素を使用すると、一連のデータベース操作で 1 つの操作が失敗した場合にトランザクション全体をロールバックできます。
複数の作成レコードを含む画面フロー

右側の次のフローに示すように、レコードを作成し、レコードを更新して、さらにレコードを作成するフローがあるとします。
このシナリオでは、最初の 2 つの要素が成功し、最後の 2 つの要素が失敗した場合でも、最初の 2 つの DML 操作でこれらのレコードが作成および更新され、3 つ目の要素は更新されません。
ロールバックを使用した画面フロー
レコードのロールバック要素を使用すると、3 つの操作をすべて連動して実行する必要がある場合にトランザクション全体をロールバックできます (左側の最終フローを参照)。 詳細は、「[Flows in Transactions](https://help.salesforce.com/articleView?id=flow_concepts_transaction.htm) (トランザクションのフロー)」および「[Flow Bulkification in Transactions](https://help.salesforce.com/articleView?id=flow_concepts_bulkification.htm) (トランザクションのフローの一括処理)」を参照してください。「Salesforce Well-Architected」の「Automated(自動化)」セクションでは、[データ処理](/docs/architect/ja-jp/well-architected/guide/automated#データ処理)についても詳しく説明します。 LWC からトランザクションを制御する機能は、LWC が操作を実行するために使用している基盤となるサービスに集約されます。Lightning レコードフォームベースコンポーネントを使用している場合、基礎となる操作 (レコードの作成または更新) は、フォームの送信直後にスタンドアロントランザクションで実行されます。 一般に、次のルールが適用されます。 - 各 UI API コールは独自のトランザクションに分離されます。 - 1 つのトランザクション内で複数の操作を実行する必要がある場合は、入力を Apex コントローラやフローなどのサーバ側テクノロジーに送信します。そのテクノロジーの通常のトランザクションルールが適用されます。 #### 外部インテグレーション フロー、OmniStudio、LWC はすべて、プラットフォームイベント ([イベント駆動型アーキテクチャ](/docs/architect/ja-jp/decision-guides/guide/event-driven)用) と API インテグレーションをサポートしています。カスタム Apex コードに加えて、フローと OmniStudio の両方で API を統合する宣言型メカニズムがサポートされています。 MuleSoft API または RPA ボットに接続する必要がある場合は、MuleSoft サービスを使用します。これにより、外部サービスが生成されます。 MuleSoft API と RPA ボットを使用した MuleSoft 外部インテグレーション [\_\_](/docs/architect/ja-jp/reference-diagrams/guide/external-integrations-via-mulesoft-apis-and-rpa-bots) API に OpenAPI スキーマがある場合は、外部サービスを作成します。 [OpenAPI を使用した外部インテグレーション_OpenAPI スキーマを使用した API への外部インテグレーション_](/docs/architect/ja-jp/reference-diagrams/guide/external-integrations-to-apis-with-openapi-schemas) それ以外の場合は、フローの HTTP コールアウト機能または OmniStudio の HTTP アクションを使用します。フローの HTTP コールアウトは外部サービスによって提供されます。 [HTTP による外部インテグレーション_HTTP による外部インテグレーション_](/docs/architect/ja-jp/reference-diagrams/guide/external-integrations-via-http) OmniStudio には、インテグレーション手順を使用して外部システムにコールアウトし、データマッパーを使用してデータを変換できる豊富なインテグレーション機能が備わっています。(詳細については、「[オブジェクトへの影響](#オブジェクトへの影響)」を参照してください) カスタム Apex または外部サービスのどちらを使用して実装しているかに関係なく、コールアウトはコールアウトです。必要な知識は次のとおりです。 1. コールアウトには時間がかかる場合があります。 2. コールアウトが同期的に実行される場合は、データベーストランザクションが開いている間に実行されます。 3. 待機中のデータベース操作がある場合、Salesforce ではデータベーストランザクションを開いたままにできません。 留意すべき主な制限は、作成、更新、削除操作を実行してから同じトランザクションでコールアウトを実行する、いわゆる**_ダーティ トランザクション_**の危険性です。このパターンは、上記の考慮事項 #3 のために許可されていません。もちろん、考慮事項 #1 と #2 のために存在します。 フローでは、トランザクションを破棄することでこの制限を回避できます。画面とローカルアクションの両方でブラウザーコンテキストが再導入され、トランザクションが中断されます。外部コールアウトを使用する場合は画面とローカルアクションを使用できますが、呼び出し可能な詳細設定でトランザクション制御を有効にすることをお勧めします。トランザクション制御は、コールアウトが行われる前にトランザクションを自動的に終了できる呼び出し可能なアクションの機能です。呼び出されたアクションの \[詳細] セクションで \[常に新しいトランザクションを開始] を選択すると、トランザクション制御を有効にできます。 コールアウトを使用した外部インテグレーション LWC では、コールアウトがトランザクションに与える影響はそれほど複雑ではありません。通常は、LDS(Lightning Data Service)を使用してデータ操作を実行し、Apexコントローラを使用して外部コールアウトを実行します。この設計により、LDS コールが Apex コールアウトとは別の独自のトランザクションで分離されるため、ダーティなトランザクションから保護されます。 _Apex コールアウト、外部サービス、およびデータ統合機能全般についての詳細は、『[Architect's Guide](/docs/architect/ja-jp/decision-guides/guide/data-integration) to Data Integration with Salesforce (Salesforce とのデータ統合に関するアーキテクトガイド)』を参照してください。_ #### 再利用性とモジュール性 動的フォームでは再利用はサポートされません。各動的フォームは、特定のオブジェクトの特定の Lightning レコード ページに関連付けられています（ただし、その Lightning レコード ページを複数のアプリケーションやプロファイルなどに割り当てることができます）。 ほかの複数のコンポーネントで使用するライブラリ、ユーティリティー、およびコンポーネントを記述する場合と同様に、**_サブフロー_**の機能を使用してフローを作成するときに同様のデザインパターンを適用できます。フローをより小さくモジュール化されたバケットに保存し、サブフロー要素を使用して他のフローからコールします。設計で必要な場合は、両方独立して別のフローのサブフローとして役立つフローを作成できます。 OmniStudio は、本質的にモジュール化を目的として構築されています。データマッパー、OmniScript、FlexCard、Integration Procedure はすべて独立して構築され、相互に連動できます。さらに、FlexCard は他の LWC、OmniScript、レコードページ、Experience Cloud サイトに組み込むことができる LWC コンポーネントとして構築できます。 画面フロー、OmniScript、LWC はすべて再利用できるように構築でき、外部サイトや Lightning Out アプリケーションなどのさまざまな場所に組み込むことができます。ソリューションを[構成可能](/docs/architect/ja-jp/well-architected/guide/composable)に設計すると、適応性や安定性などの追加のメリットが得られます。 ### 入力規則 レコードの作成または更新に使用されるすべてのテクノロジーは、従来の入力規則であるか、Apex トリガーに組み込まれたカスタム入力規則であるかに関係なく、システム・レベルの入力規則に準拠します。レコードの変更の実行に使用しているテクノロジーに関係なく、すべての変更は保存順序に従います。つまり、入力規則に加えて、レコードの変更は保存前または保存後フロー、トリガーの前または後、エスカレーションルール、割り当てルールなど、任意の数で処理されます。ブックマークしていない場合は、必ずブックマークして、Apex [の実行順序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)に慣れてください。 #### 質問する内容: - フォームにシステムレベルの検証以外の追加要件はありますか? - 項目をフォーム内で動的に必須または参照のみに設定する必要はありますか?
システムレベルの検証の尊重 このフォームに固有のカスタム項目レベル検証 カスタム項目レベル検証
動的フォーム 利用可 利用不可 利用不可
画面フロー 利用可 利用不可 ロードマップ
OmniStudio 利用可 利用可 利用可
Screen Flow + LWC 利用可 利用可 利用可
LWC 利用可 利用可 利用可
フロー画面または OmniScript ステップの入力は本質的にバインドされていないため、フォーム自体は特定のオブジェクトに関連付けられたシステムレベルの検証にネイティブに準拠しません。ただし、レコードを作成または更新するために使用する値は保存順序で処理されます。つまり、オブジェクトのシステムレベルの検証を通過します。ただし、すべての画面フローコンポーネントで入力検証がサポートされるわけではありません。Summer '24 の時点で、入力検証をサポートしていない残りの画面コンポーネントは、ラジオボタン、選択リスト、複数選択リスト、チェックボックスグループ、選択肢ルックアップです。 動的フォームでは、ページレイアウトと同様に、必須性と参照のみの状態をページレベルで設定できます。ただし、システムレベルの設定を上書きすることはできません。 フローでは、フォームの入力の検証を柔軟にカスタマイズできます。クライアントでいくつかのチェック (必須項目の欠落や互換性のない値へのフラグ付けなど) が実行されますが、クライアント側の検証でユーザーの移動がブロックされることはありません。実際の検証はサーバーで行われます。ユーザーが \[**次へ]** をクリックすると、フローによって入力が検証のためにサーバーに送信されます。入力が無効として返された場合、ナビゲーションがブロックされ、適切なエラーが表示されます。サーバーは次のチェックを行って入力を検証します。 1. 入力の必須設定、または入力された値が基礎となるデータ型と互換性があるかどうか。 2. その入力に対するカスタム検証:いくつかの標準コンポーネント (チェックボックス、通貨、日付、日付/時間、ロングテキストエリア、数値、パスワード、テキスト) では、画面ごとのカスタム検証がサポートされています。Boolean 型の数式と、数式が満たされない場合に表示するエラーメッセージを指定します。 3. 基盤となるコンポーネントに対するカスタム検証:フローのカスタム LWC を作成する場合は、独自の検証コードを validate() メソッドに追加します。 OmniStudio は、[条件ビュー](https://help.salesforce.com/s/articleView?id=sf.os_conditionally_display_elements_using_the_conditional_view_property.htm&type=5)および[メッセージング](https://help.salesforce.com/s/articleView?id=sf.os_display_messages_in_omniscripts_19551.htm&type=5)コンポーネントと組み合わせて \[[エラーを設定](https://help.salesforce.com/s/articleView?id=sf.os_set_errors_in_an_omniscript.htm&type=5)] アクションを使用することで、豊富なエラーおよび検証処理を実現します。 LWC 側では、ほとんどのベースコンポーネントが独自のクライアント側検証を実行します。たとえば、Lightning-record-form では、システム レベルの要件は考慮されますが、ページ レベルの要件は考慮されません。カスタムコンポーネントの場合は、Build Your Own 検証メカニズムを作成できます。 ユーザーがデータを入力する必要がある項目は、フォームの早い段階で表示する必要があります。可能な限り、フォームを送信する前にクライアント側でユーザー入力を検証します。フォームの合理化に関するその他のベスト プラクティスについては、「Salesforce Well-Architected - Engaging」の[フォーム](/docs/architect/ja-jp/well-architected/guide/engaging#フォーム) ガイダンスを参照してください。 ### セキュリティ セキュリティは一般に複雑なトピックであり、フォームの作成に関しては、思いもよらなかった考慮事項がいくつかあります。基礎レベルでは、フォームが正しいコンテキストで実行され、基礎となるデータを操作するために必要な権限がユーザーに付与されていることを確認します。さらに、リッチテキスト項目から潜在的に悪意のあるコードや URL を削除したり、特定のユーザーがフォームにまったくアクセスできないようにしたり、今後システム管理者がフォームを埋め込むことができる場所の種別を制限したりするための追加措置を講じる必要もあります。ツールを選択する前に、セキュリティ要件を徹底的に文書化してください。Salesforce Well-Architected [Security Policy Template](/docs/architect/ja-jp/resources/guide/security-policy-template) には、この種別のドキュメントに関するガイドラインが含まれています。 #### 質問する内容: - 特定の操作を実行する前にフォームでユーザーのアクセス権を確認する必要がありますか? - ユーザー入力をサニタイズする必要がありますか? - フォームにアクセスできるユーザーを制御しますか? - フォームを埋め込む場所を制御しますか?
ユーザー権限の昇格 アクセス権を持つユーザーの制御 許可されるロケーションの制限
動的フォーム 利用不可 利用可 利用不可
画面フロー 利用可 利用可 利用不可
OmniStudio 利用不可 利用可 使用不可**
Screen Flow + LWC 利用可 利用可 利用不可
LWC 使用可能* 利用可 利用可
*Apexが必要
* * OmniScript には指定された対象ロケーションのセットを含めることはできませんが、FlexCard では含めることができます。
#### ユーザー権限の昇格 **_ユーザーコンテキスト_**で何かが実行されると、Salesforce は、組織の共有ルールに基づいて項目レベルセキュリティ、CRUD 権限、レコードアクセス権の検証など、一連のアクセスチェックを適用します。そのため、たとえば、ユーザーがケース更新フォームを実行できるのは、ケースを更新する権限、適切な項目レベルセキュリティ、および当該レコードへのアクセス権がある場合のみです。ただし、ユーザーが*自分*のフォームを使用しているときに特定の操作を実行できるようにし、他のフォームやインタラクションからは実行できないようにするにはどうすればよいでしょうか。ここで、**_システムコンテキスト_**の出番です。 システムコンテキストは、セッション中に実行ユーザーの権限を昇格させる手段であり、たとえば、ケース更新フォームを正常に入力するためにケースオブジェクトへの更新アクセス権をユーザーに付与する必要はありません。これは、認証されていないコミュニティで特に便利です。ゲストユーザーに潜在的に危険な機能を付与する代わりに、システムコンテキストで実行するようにフォームを設定します。 もちろん、システムコンテキストは両刃の剣であり、必要な場合にのみ使用する必要があります。フォームがシステムコンテキストで実行されると、関心のある特定の操作だけでなく、すべての CRUD 操作がオブジェクトレベルおよび項目レベルのセキュリティと共有をスキップします。また、システムコンテキストは、Salesforce がアクターとみなすユーザー (\[最終更新者] 項目に表示される名前) には関係ありません。ケースの更新など、フォームで実行される各操作では、フォームが別のコンテキストで実行されていても、アクターが実行ユーザーになります。 動的フォーム、OmniScript、LWC は常にユーザーコンテキストで実行され、この動作を上書きする方法はありません。 画面フローはデフォルトでユーザーコンテキストで実行されますが、システムコンテキストで実行するように設定することもできます。フローですべてのデータへのアクセス権を付与するのか、それとも共有などのレコードレベルのアクセス権を適用するのかを選択できます。 - システム コンテキストで実行されるフローに Lightning コンポーネントを埋め込む場合、そのフローでコンポーネントのコンテキストが上書きされることはありません。ユーザー アクセス チェックをスキップする必要がある場合は、フローを使用してこれらの操作を実行し、Lightning コンポーネントに適切なデータを渡したり、Lightning コンポーネントから適切なデータを渡したりすることをお勧めします。一部の標準コンポーネント (ルックアップなど) は、システムコンテキストで操作できません。 - フローで Apex アクションをコールする場合、さらに理解すべき微妙な違いがあります。Apex クラスが継承共有に設定されている場合、フローの設定に関係なく、共有のシステム コンテキストで実行されます。クラスに明示的な共有宣言がない場合、フローの設定に関係なく、共有なしでシステムコンテキストで実行されます。クラスが共有ありまたは共有なしに設定されている場合、共有され、フローのコンテキストが上書きされます。 **Experience Cloud サイトを使用したシステムコンテキストでのレコードの照会** Experience Cloud サイトのシステムコンテキスト (**特に未認証**) でフローを実行している場合は、\[レコードを取得] 要素に特定のフィールドのみを保存することをお勧めします。フローを使用していて、レコードを取得要素の結果をサブフロー、呼び出し可能なアクション、または Lightning コンポーネントに渡すと、そのオブジェクトのすべての項目をブラウザの開発者ツールを使用して検査できます。これにより、Experience Cloud サイトユーザーが意図しない項目を使用できるようになる可能性があります。\[レコードを取得] 要素で特定の項目を指定することで、システムコンテキストが有効になっていても適切な項目のみが表示されるようにできます。 OmniScript ロジックはクライアント側で実行されます。これにより、攻撃者は OmniScript の予期される実行を変更し*、*ブラウザーの開発者ツールを使用して Integration Procedure、データ マッパー、Apex メソッド コールへの応答を表示できます。OmniScript を使用している場合は、可能な限りサーバー側でビジネス ロジックを実行し、[@InvocableMethod アノテーション](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5)を介して公開される Apex メソッドに入力規則を実装することをお勧めします。 **入力のサニタイズ:** 悪意のあるユーザーから組織を保護するには、入力のサニタイズも検討します。公開されているフォームに入力があり、それを組織のリッチテキスト項目に対応付けることができるとします。悪意のある URL を隠す可能性がある HTML を削除する自動化を検討することをお勧めします。一般に、このサニタイズをフォームレベルで実装することは理想的ではありません。これらの項目には任意の数のソースを書き込むことができるためです。Fast Field Update フロー（保存前）を作成するか、オブジェクトで既存の Apex トリガーを使用して、フォームに入力される可能性のある HTML を削除または変更することをお勧めします。 **_ベスト プラクティス:_** - _特定の操作で実行ユーザーのアクセス権を昇格させる必要がない限り、フローはデフォルトのコンテキストで実行されるようにします。_ - セキュリティ上の理由により、ゲストユーザーのシステムコンテキストでのフローの実行は*避けてください。代わりに、Experience Cloud サイトのゲストユーザープロファイルに割り当てられた項目アクセス権が制限された権限セットを作成します。* - _Experience Cloud サイトのシステムコンテキスト実行フローでレコードを照会する場合、\[レコードを取得] 要素または呼び出し可能なアクションに必要なフィールドのみを保存します。_ - _フローでさまざまな操作を実行し、すべての操作に高度なアクセス権が必要ない場合は、サブフローを使用してシステムコンテキストで実行する操作を分離します。_ - _フォームを外部 Web ページに埋め込む場合は、ユーザー入力をサニタイズして高速項目更新フローまたは Apex トリガーを使用して HTML を削除し、最終的にリッチ テキスト フィールドにマッピングして、悪意のあるユーザーからのフィッシング攻撃を防ぐことを検討してください。_ #### 追加メモ: - OmniScript、FlexCard、LWC は、デフォルトでユーザーコンテキストで実行されます。 - LWC はデフォルトでユーザ コンテキストで実行され、フローはユーザ コンテキストで実行されますが、Apex コントローラで上書きできます。 - UI API を介して実行される操作は、ユーザーコンテキストで実行されます。 - Apex コントローラを介して実行される操作は、そのクラスによって異なります。これらの操作をシステム モードで実行するには、Apex クラスを共有ありまたは共有なしに設定します。 #### アクセス制御 フォームにアクセスできるユーザーを制御する必要がある場合、多くの場合、フォームが埋め込まれているコンテナを参照できます。たとえば、特定のアプリケーション、レコード タイプ、プロファイルで使用できるように Lightning ページを割り当てることができます。フォームの特定の入力が機密である場合、表示ルールを使用して誰に表示するかをさらに制御します。この機能は動的フォームと画面フローの両方に適用されます。 Apex クラスや Visualforce ページと同様に、特定のプロファイルまたは権限セットに[フローを制限](https://help.salesforce.com/articleView?id=flow_distribute_security.htm)できます。デフォルトでは、フローは無制限です。つまり、「フローを実行」ユーザー権限を持つすべてのユーザーがフローを実行できます。 OmniStudio を使用している場合は、OmniScript、Flexcard、Classic Card、または REST API からコールされたリモート・アクションを管理する Apex クラスへの明示的なアクセスをユーザーに要求するように[Apex クラス権限チェッカー](https://help.salesforce.com/s/articleView?id=sf.os_add_an_apex_class_permissions_checker_1.htm&type=5)を設定できます。 - 注: Apex クラスの権限チェックは、新規作成されたスクリプトではデフォルトで有効になっています。ただし、既存のスクリプトでは手動で有効にする必要があります。 - また、Apex クラス権限チェックは Apex クラスにのみ適用されます。[インテグレーション手順とデータマッパー](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5)にもプロファイルレベルの権限を設定することをお勧めします。 ゲストユーザー権限の詳細とベストプラクティスについては、次を参照してください。 - [ゲストユーザーレコードアクセスのベストプラクティス](https://www.learnexperiencecloud.com/s/article/Guest-User-Record-Access-Development-Best-Practices#Pattern6) - [セキュアサイトの開発:認証済みユーザーとゲストユーザー](https://developer.salesforce.com/docs/atlas.en-us.communities_dev.meta/communities_dev/communities_dev_security_authenticated_and_guest_users.htm) **_ベストプラクティス:_** - フローをゲスト ユーザに公開する*場合は、ゲスト ユーザ プロファイルに必要なフローのみへのアクセス権を付与します。ゲストユーザープロファイルに「フローを実行」を追加することもできますが、これはリスクの高い方法であると考えられます。* - システムコンテキストで動作するフローには特に注意*してください。これらのフローは特定のユーザーセットに制限することを強くお勧めします。データを保護するための抑制と均衡が少ないためです。* - _ゲスト ユーザー コミュニティで Apex を実行するすべての OmniScript で Apex クラス定義に「with sharing」が含まれていることを確認します。_ - _ゲストユーザープロファイルで、ゲストユーザーがコールできるようにする Apex クラスのみを割り当てます。割り当てないと、意図せずに追加のビジネスロジックがゲストユーザーに公開される危険があります。_ LWC の場合、実行ユーザーの権限割り当てをチェックして、特定の標準権限またはカスタム権限があるかどうかを確認できます。JavaScript から直接、@salesforce/userPermission および @salesforce/customPermission 範囲設定済みモジュールから Salesforce 権限をインポートできます。または、Apex を使用して確認することもできます。 #### 埋め込み制御 Lightning Web コンポーネントは、有効な[ターゲット](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.reference_configuration_tags)として追加された場合にのみ、特定の場所で使用できます。たとえば、コンポーネントをレコードページで使用可能にしたり、ユーティリティバー項目として使用できないようにしたりできます。 画面フローを有効化すると、画面フローがサポートされているすべての場所で、あらゆる場所で使用できるようにするかどうかに関係なく、使用できるようになります。ただし、Flow Builder では、画面を含む複数の種類のフローがサポートされます。ブレッド & バター種別は \[画面フロー] ですが、特定の場所に制限された特殊な種別がいくつかあります。たとえば、Field Service Mobile アプリケーションでは Field Service Mobile フローのみがサポートされます。Experience Cloud でのみサポートされる連絡要求フローも同様です。 フロー種別に関係なく、フローを作成した個人は、フローを埋め込むことができる場所を制御できません。フローは、そのフロー種別でサポートされるすべての場所で使用できます。 Salesforce Industries を使用している場合は、OmniScript に関して少し注意が必要です。OmniScript 自体に対象を指定することはできませんが、OmniScript に埋め込む FlexCard に対象を指定できます。 ### インタラクション設計 静的形式は過去のものです。今日は、このユーザー (今回はこの場所) に適切なプロパティと値でフォームを動的に更新することです。Salesforce のフォーム作成ツールについて、この流れで何ができるかを説明します。 #### 質問する内容: - フォーム内で動的応答をトリガーする必要があるインタラクションまたは条件の種別は? - フォームの入力時にバックグラウンドで画面外操作を実行する必要がありますか? - 項目を表示、必須、参照のみ、無効として設定するか、フォーム入力に基づいて書式設定を変更する必要がありますか?
画面外データ操作の実行 条件値と計算 条件付き表示 条件付き要件 条件付き書式 条件付き参照のみの状態 条件付き無効化状態
動的フォーム 使用不可 使用不可 利用可 使用不可 ロードマップ 使用不可 使用不可
画面フロー 利用可 使用可能** 利用可 使用可能* 使用不可 使用可能** 使用可能**
OmniStudio 利用可 利用可 利用可 利用可 利用可 利用可 利用可
Screen Flow + LWC 利用可 利用可 利用可 利用可 利用可 利用可 利用可
LWC 利用可 利用可 利用可 利用可 利用可 利用可 利用可
*静的チェックボックスではなく、リソースピッカーを使用するコンポーネントに制限されます。
**制限付きベータ
反応型画面のおかげで、画面フローのインタラクティブ性が実現しました。リアクティビティを使用すると、フロー画面の個々のコンポーネントが相互に通信できるため、画面フローが無限に強力になります。 **画面外データ操作の実行:**画面フローでは、画面アクションを使用して同じ画面のデータを取得する宣言型のアプローチが提供されます。画面アクションを使用すると、画面の変更時やユーザーがアクションボタンコンポーネントをクリックしたときに自動起動フローをトリガーできます。その後、これらの自動起動フローの結果を同じ画面にマッピングできるため、ユーザーが別の画面に移動する必要がありません。 LWC には、Salesforce データにアクセスしてフォームのコンポーネントのデータを動的に入力できるワイヤ アダプタが多数用意されており、開発者は Apex コントローラを使用してレコードを更新、削除、作成できます。 [Lightning Web コンポーネント オフ画面データ操作_Lightning Web コンポーネント オフ画面データ操作_](/docs/architect/ja-jp/reference-diagrams/guide/lightning-web-components-off-screen-data-operations) **表示:**表示は、すべてのフォーム作成ツールで動的に制御できます。動的フォーム、Flow Builder、OmniStudio は、コンポーネント表示機能を使用してこれに対応します。これにより、フォームの他の値やユーザーがモバイルデバイスを使用しているかどうかに基づいて、宣言的に項目を表示または非表示にできます。 - 動的フォームでは、レコード項目値、参照項目を介して関連するレコード、フォーム要素に基づいて表示を制御できます。 - フローでは、表示ルールを画面の他の入力や、数式や他のレコードの値など、フローの前半で入力された他のリソースに基づいて設定できます。 - **デバイスベースのルール:**最初から明確ではありませんが、ユーザーがモバイルデバイスを使用しているときに数式を使用して特定の項目を表示または非表示にできます。\$User.UIThemeDisplayed グローバル変数の値をチェックするフロー数式を記述します。値が Theme4t の場合、ユーザーは Salesforce モバイルアプリケーションを使用しています。 - **その他のリソースの評価:**手動変数および数式参照はサーバーでのみ評価されます。そのため、画面が最初に表示されるときのリソースの値は、別の画面に移動するまでの値になります。ナビゲーションでは、フローランタイムがフローエンジン (サーバー) に要求を送信し、手動変数と数式の最新の値を取得します。ユーザーが 1 つの画面を通過するときに表示ルールが更新されることが予想される場合 (onblur など)、画面の他のコンポーネントの値のみを参照していることを確認してください。 - OmniStudio では、\[条件付きビュー] プロパティを設定して、コンポーネントを条件付きで表示または非表示にできます。ただし、1 つの入力に複数の条件付きビュープロパティを追加することはできません。 **条件付き入力状態:**項目が必須、無効、参照のみなど、他のプロパティを動的に制御する必要がある場合は、いくつかのオプションがあります。期待どおり、LWC では入力状態を完全に反応的に制御できます。反応型画面フローコンポーネントでは、そのコンポーネントをサポートする標準コンポーネントの \[参照のみ]、\[無効]、\[必須] などのコンポーネント属性を動的に制御できます。OmniStudio では、コンポーネント固有の属性の全範囲がサポートされます。要件によってフローが必要と判断され、コンポーネントで特定の属性状態がサポートされていない場合は、埋め込み可能な LWC を作成して動的入力状態を実現できます。 項目が必須か参照のみかなど、他のプロパティを動的に制御する必要がある場合、短期的には LWC が最適です。LWC では、完全に制御できます。特に、ぼかしやクリックの処理方法に関する特注の要件がある場合に顕著です。 画面フローの反応型 LWC:画面フローの他のコンポーネントに反応したり変更したりできる LWC を作成する場合は、この [LWC Best Practices](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows) for Screen Flows (画面フローの LWC のベストプラクティス) ガイドを参照して、コンポーネントがフローランタイムエンジン内で適切に統合され、将来にわたって期待どおりに動作することを確認してください。
標準イベント処理 (onblur、onfocus) カスタムイベント処理
動的フォーム 使用不可 使用不可
画面フロー 利用不可 使用不可
OmniStudio 使用不可 使用可能*
Screen Flow + LWC 利用可 利用可
LWC 利用可 利用可
*OmniStudio 標準ランタイムでは Pub/Sub はサポートされませんが、Windows postMessage はサポートされます。
カスタムイベントの場合。入力の一部またはフォーム全体がページ内の他のものと通信する必要がある場合は、LWC が唯一のオプションです。 - 同じ DOM ツリー内で通信するには、[**CustomEvent インターフェイス**](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events)を使用します。 - DOM 間で通信するには、[**Lightning Messaging Service**](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel) を使用します。 - Lightning Messaging サービスが対象コンテナで[サポートされ](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_message_channel_considerations)ていない場合は、**pub/sub モジュール**を使用します。 #### 関連リソース - 詳細については、『_Lightning Web Components Dev Guide_』の「[Communicate with Events](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/events) and [Communicate Across the DOM](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.events_pubsub)」を参照してください。 - OmniStudio の場合は、「Lightning Web コンポーネントからの [Omniscript との通信](https://help.salesforce.com/s/articleView?id=sf.os_communicate_with_omniscript_from_a_lightning_web_component_18222.htm&type=5)」を参照してください ### スタイル 最適なユーザーエクスペリエンスを提供するには、フォームのスタイルが埋め込まれている他のアプリケーションまたはサイトと一貫していることを確認する必要があります。これを実現するには、Salesforce で提供される標準テンプレートの使用から、デザインのすべてのピクセルを完全に利用してよりシャープなデザインを実現するカスタム CSS の作成まで、あらゆることが考えられます。 #### 質問する内容: - 目的のスタイルと CSS はどの程度洗練されていますか? - ピクセル単位で完璧なカスタムスタイルが必要ですか? それとも標準テーマで問題ありませんか?
ダイレクトスタイル 組織およびエクスペリエンスビルダーのテーマ ピクセル単位のスタイル
動的フォーム 利用不可 利用可 利用不可
画面フロー 利用不可 利用可 ロードマップ
OmniStudio 使用可能* 利用不可 利用可
Screen Flow + LWC 利用不可 利用可 利用可
LWC 使用不可 利用可 利用可
*Flex Card のみ
FlexCards は、ツールで作成する UI (余白やパディング、タイポグラフィ、色など) のスタイルやレイアウトを宣言的に直接制御できる唯一の製品です。 動的フォームとフローはどちらも宣言型テーマ機能を尊重します。[Salesforce テーマ](https://help.salesforce.com/articleView?id=brand_your_org_in_lightning_experience.htm&mode=1)、[エクスペリエンスビルダーブランドセット](https://help.salesforce.com/articleView?id=community_designer_brandsets.htm)、または [LWR Experience Cloud サイト](https://developer.salesforce.com/docs/atlas.en-us.exp_cloud_lwr.meta/exp_cloud_lwr/brand_overview.htm)でサポートされる以上の制御が必要な場合は、プログラムソリューションを検討してください。 CSS の使用に慣れているチームには、いくつかのオプションがあります。 - フローと LWC は[標準設計トークン](https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/tokens_standard.htm)を継承します。 - OmniScript と FlexCard には、カスタマイズ可能な設計システムのサポートが含まれます。[Newport](https://help.salesforce.com/s/articleView?id=sf.os_customize_omniscripts_and_flexcards_with_the_newport_design_system.htm&type=5)。 - LWC では、独自のコンポーネントを記述し、その HTML と CSS を完全に制御できます。 可能な限り、テーマとデザインシステムを使用して、すべてのコンテンツに一貫したデザインを適用することをお勧めします。 リマインダー:Lightning コンポーネントはフローに組み込むことができます。そのため、フォームのデザインをピクセル単位で完璧に制御する必要があり、ナビゲーションモデルなど、フローの他の利点を使用する場合、両方の利点を活用できます。同じ原則が OmniScript と FlexCard にも適用されます。 ### レイアウト 迅速かつ効率的なデータ入力を可能にし、データの整合性を高める合理化されたフォームを設計するには、適切なレイアウトを選択することが不可欠です。このトピックについての詳細は、「[Salesforce Well-Architected - Forms](/docs/architect/ja-jp/well-architected/guide/engaging#フォーム) (Salesforce の適切なアーキテクチャ - フォーム)」を参照してください。 #### 質問する内容: - フォームのレイアウトを使用してユーザーエクスペリエンスを最適化する方法は? - フォームに新しいデータを簡単に入力できるように、既存のデータをユーザーに表示する方法は?
2 列 4 列 4 列を超える データの繰り返しブロック タブコンテナ アコーディオンコンテナ
動的フォーム 利用可 使用不可 使用不可 使用不可 利用可 利用可
画面フロー 利用可 利用可 使用不可 利用可 使用不可 利用可
OmniStudio 利用可 利用可 利用可 利用可 使用可能* 利用可
Screen Flow + LWC 利用可 利用可 利用可 利用可 利用可 利用可
LWC 利用可 利用可 利用可 利用可 利用可 利用可
*タブは、OmniScript の FlexCard にデータを埋め込む場合に使用できます。
動的フォームでは 2 列レイアウトがサポートされ、項目を使用して個々のセクションに分割できます。これらのセクションをタブやアコーディオンなどのコンポーネントに配置すると、使いやすく整理されたレイアウトを作成できます。 フローは、必要に応じてセクションコンポーネントを使用して表示できます。セクションを使用すると、フロー画面に最大 4 つの列と必要な数のセクションを追加できます。このコンポーネントは画面幅にも反応するため、小さな画面でも使用できます。最後に、条件付き表示をセクション全体に適用できるため、セクション内の複数の項目に表示を一括適用しやすくなります。フローセクションは列ヘッダーもサポートし、表示ラベルをクリックしてセクション全体を折りたたむことができるアコーディオンのような環境を提供します。 OmniScript には、項目とデータを表示するためのさまざまなレイアウトオプションがあります。条件付き折りたたみ可能なアコーディオンを含め、最大 12 列のデータセクションを作成できます。 LWC では、Lightning-record-［edit|view］-form およびサポートされる Lightning-［input|output］- フィールドを使用してレイアウトを制御できます。レイアウトの制限は HTML/CSS の制限のみです。Lightning-record-form は、関連付けられたページレイアウトのセクション設定に従います。たとえば、ページレイアウトでセクションが 2 列の場合、このコンポーネントでは 2 列になります。 ### トランスレーション 異なる地域のユーザーや異なる言語を話すユーザーがフォームにアクセスできるようにするには、フォームの作成に使用するツールがローカライズ要件を満たしていることを確認する必要があります。その他の指針と推奨事項については、「[Salesforce Well-Architected - Localization](/docs/architect/ja-jp/well-architected/guide/compliant#ローカライズ) (Salesforce の適切なアーキテクチャ - ローカライズ)」を参照してください。特にフォームの場合、ローカライズ要件として、通常、テキスト要素を他の言語に翻訳する必要があります。 #### 質問する内容: - フォームを複数の国または地域で使用しますか? - フォームのテキストを他の言語にローカライズする必要がありますか?
ビルダーに入力された表示ラベル コードの表示ラベル
動的フォーム 使用可能* 使用不可
画面フロー 利用可 利用可
OmniStudio 利用可 利用可
Screen Flow + LWC 利用可 利用可
LWC 使用不可 利用可
*項目セクションヘッダーのみ
カスタム項目をローカライズした場合、動的フォームでは翻訳された表示ラベルが適用されます。動的フォームでは、Lightning アプリケーションビルダーでコンポーネントの表示ラベルと属性に割り当てた[カスタム表示ラベル](https://help.salesforce.com/s/articleView?id=platform.lightning_page_components_use_expressions_for_labels.htm&type=5)も尊重されます。 トランスレーションワークベンチにより、フローではすべての標準画面コンポーネントとカスタム画面コンポーネントのユーザー向け表示ラベルの翻訳がサポートされます。次の画面コンポーネントの表示ラベル、ヘルプテキスト、エラーメッセージをローカライズできます。テキスト、ロングテキストエリア、数値、通貨、チェックボックス、ラジオボタン、選択リスト、複数選択リスト、チェックボックスグループ、パスワード、日付、日付/時間。 標準のアクション (\[メールを送信] や \[Chatter に投稿] など) に対する翻訳サポートは組み込まれていません。ただし、回避策があります。翻訳済み表示ラベルを[カスタム表示ラベル](https://help.salesforce.com/articleView?id=cl_about.htm)で定義する場合、Flow Builder で設定するときにアクションまたはコンポーネントでそのカスタム表示ラベルを参照できます。カスタム表示ラベルを参照するフロー数式を作成し、フローの適切な場所でその数式を参照します。 OmniScript では、翻訳にカスタム表示ラベルが使用されます。[このヘルプドキュメント](https://help.salesforce.com/s/articleView?id=sf.os_create_multi_language_omniscripts.htm)を参照して、OmniScript を多言語に対応させます。 LWC だ特定のベース コンポーネントは、トランスレーション ワークベンチで設定されている場合、関連付けられたオブジェクトの項目、ヘルプ テキスト、検証メッセージの翻訳を自動的に継承します（Lightning-record-form など）。 新しい翻訳可能な表示ラベルをコードに導入する必要がある場合、カスタム表示ラベルが依然として主役です。必要なカスタム表示ラベルを宣言し、@salesforce/label 範囲設定モジュールからコンポーネントにインポートします。 ### UI テストの自動化 Selenium など、いくつかのエンドツーエンドのテスト自動化ツールがあり、ユーザーがフォームを操作する方法をシミュレーションできます。これらのテストは、Lightning ページや画面フローなど、任意の標準またはカスタム UI に対して記述できます。ただし、この種のテストでは、実行中の各メソッドの出力を確認できないことに注意してください。UI テストの自動化の要件を検討するときは、この点を考慮してください。 #### 質問する内容: - フォームの自動テストが必要ですか? - どのような種類のテストを実行する必要がありますか? - テスト自動化に必要な粒度は?
単体テスト エンドツーエンドの自動化
動的フォーム 使用不可 使用可能*
画面フロー 使用不可 使用可能*
OmniStudio 使用可能* 使用可能*
Screen Flow + LWC 使用可能* 使用可能*
LWC 利用可 利用可
*コードが必要
UI テスト自動化の要件を考慮します。 **単体テストを**使用すると、業界標準の CI/CD システムおよびツールと連携するより詳細な自動化と検証が可能になり、コンポーネントのビジネスロジック、JavaScript コントローラー、出力をテストできます。ローコードのみを使用してテストを自分で作成することはできませんが、Salesforce ではエンドツーエンドのサービスを厳密にテストしています。 コンポーネントのメソッドが複雑で、個別にテストする場合は、メソッドを専用の JavaScript ファイルに格納します。これにより、`import { sort } from 'c/utils';` などの LWC および Jest テストにインポートできます。 [Salesforce で](https://developer.salesforce.com/blogs/2020/01/ui-test-automation-on-salesforce.html)エンドツーエンドの自動化を構築するためのさまざまなオプションの比較については、「Salesforce での UI テストの自動化」を参照してください。ISV のノーコードソリューションを使用するケース、Build Your Own テスト自動化ソリューションを使用するケース、または Selenium WebDriver や WebdriverIO などのオープンソースのテストフレームワークを使用するケースに関する考慮事項が含まれます。これらのソリューションは、Lightning ページの動的フォーム、ユーティリティ バーの画面フロー、クイック アクションのフローの LWC など、Salesforce のあらゆる UI インタラクションで有効です。 ### メトリクス フォームを本番環境にリリースしたら、フォームが効果的に使用されていることを確認します。使用事例によっては、単に入力回数を追跡することから、ユーザーが情報を送信する前に入力に費やす時間まで、あらゆるものを指します。ツールを選択する前に、追跡する KPI を必ず特定してください。 #### 質問する内容: - フォームの利用状況を追跡する必要がありますか? - フォームが効果的に使用されているかどうかを決定する KPI は?
ページビュー フォームにかかった時間 フォーム入力の追跡 成功率の追跡
動的フォーム 使用可能** 使用不可 使用不可 使用不可
画面フロー 利用可 使用可能* 利用可 利用可
OmniStudio 利用可 使用可能* 利用可 利用可
Screen Flow + LWC 利用可 使用可能* 利用可 利用可
LWC 使用可能** 使用可能* 利用可 利用可
*パッケージベースの OmniStudio ランタイムが有効になっている場合に使用可能
** 親Lightningページの使用状況を追跡することで使用可能
フォームの全体的な使用状況と採用を追跡する必要がある場合は、まずローコードツールを使用します。動的フォームと画面フローは、どちらも標準のカスタムレポートタイプを使用して追跡できますが、画面フロー追跡レポートではより詳細に追跡できます。LWC の利用状況を追跡する必要がある場合、すぐに使用できるかどうかは、その LWC を使用している場所によって異なります。Lightning ページにある場合は、Lightning ページの使用状況の追跡に使用できるすべてが LWC に適用されます。フローに埋め込まれた LWC についても同様です。 動的フォーム自体は標準では追跡できませんが、[Lightning 使用オブジェクト](https://help.salesforce.com/articleView?id=lex_usage_reports.htm)を使用して親 Lightning ページの使用状況を追跡できます。標準 Lightning ページを追跡するには、_Users with Lightning Usage by Page Metrics_ カスタム レポート タイプを使用します。カスタム Lightning ページでも同様に、カスタム レポート タイプ「_Users with Lightning_ Usage by FlexiPage Metrics」を使用します。 特定のフォーム (そのフォームが属するページだけではない) の採用を追跡するために、フローが役立ちます。「サンプルフローレポート:画面フロー」で、次のような質問に回答できます。 - このフォームの完了率は?適切に採用されているか? - ユーザーがこのフォームに入力するのにどのくらい時間がかかりますか? - ユーザーが最も時間を費やしている画面は? - ユーザーが逆方向に移動する頻度は? - エラーが発生する頻度は? 標準レポートがニーズに合わない場合は、標準レポートをコピーして独自の変更を加えるか、*画面フロー*レポートタイプを使用して独自のレポートをゼロから Build Your Own します。 パッケージベースの OmniScript ランタイムを使用している場合は、[OmniStudio for Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5)を使用できます。このサービスでは、あらゆる種別のイベントを追跡します。たとえば、OmniScript のステップの完了に要する時間を追跡して、プロセスの改善を特定できます。Standard OmniStudio でこのサービスをサポートするための OmniStudio チームのロードマップに記載されています。 画面フロー、OmniScript、Lightning ページに埋め込まれていない LWC で同じものを追跡するには、標準オプションはありません。Apex を使用してカスタムソリューションを構築できます。 ### パッケージ化およびリリース テストや本番へのリリースのためにソリューションを上位の環境にリリースする必要がある場合、変更セットや DevOps センターを使用することに慣れている可能性があります。これらのリリースオプションでは、動的フォーム、フロー、LWC が完全にサポートされています。OmniStudio には別のツールが必要です。[IDX ワークベンチ](https://help.salesforce.com/s/articleView?language=en_US&id=sf.os_idx_workbench_desktop_application.htm&type=5)。 #### 質問する内容: - フォームをどのようにリリースする予定ですか? - フォームは複数の Salesforce 組織に配布されますか?
第一世代管理パッケージ (1GP) 第二世代管理パッケージ (2GP) ロック解除済みパッケージ 変更セット DevOps Center
動的フォーム 利用可 利用可 利用可 利用可 利用可
画面フロー 利用可 利用可 利用可 利用可 利用可
OmniStudio 使用不可 使用不可 使用不可 使用不可* 使用不可*
Screen Flow + LWC 利用可 利用可 利用可 利用可 利用可
LWC 利用可 利用可 利用可 利用可 利用可
*IDX ワークベンチを使用して、OmniStudio ソリューションを他の組織にリリースします。
AppExchange で配布するためにソリューションをパッケージ化する予定の ISV またはパートナーは、最初に動的フォーム、フロー、および LWC を確認することをお勧めします。OmniStudio ではパッケージ化はサポートされていません。 ## その他のトピック ### ローコードからプロコードへの連続性のナビゲーション このガイドでは、動的フォーム、画面フロー、OmniStudio、LWC でどのような機能とカスタマイズレベルが可能かを理解するのに役立つことに重点を置いています。概要: ローコードからプロコードへの継続
- LWC は、フォームを作成するための最もカスタマイズ可能で堅牢なオプションですが、配置するガードレールの数が最も少なくなります。[セキュリティ](/docs/architect/ja-jp/well-architected/guide/secure)と[拡張性](/docs/architect/ja-jp/well-architected/guide/reliable#拡張性)を確保する方法でコンポーネントを構築するかどうかは、ユーザー次第です。 - 動的フォームは最も柔軟性に欠けますが、ミスステップが発生する可能性ははるかに少なくなります。 - フローと OmniStudio は中間に位置します。動的フォームよりも強力ですが、LWC のレベルにはまだ達していません。同じトークンで、動的フォームよりもガードレールが少なくなっていますが、カスタムコードよりも破られにくくなっています。 複数のツールが請求に適している場合、どのツールがチームに適しているかが判断されます。他の[アーキテクト決定ガイド](/decision-guides)では、その決定を行うときに考慮すべき追加の側面が紹介されています。 ここでは、これらの各側面の詳細には触れませんが、このドキュメントで評価する特定のツールについて解釈します。 **専門スキル**:比較するツールに関するチームの専門知識は?LWC または JavaScript に精通しているメーカーはどれくらいいますか?Flow Builder のエキスパートであるか、つま先を浸すことに関心を示したメーカーはどうでしょうか?概して、動的フォームとフローのスキルは、フォームを作成する幅広いユーザーがより容易に習得できます。動的フォームは最も宣言型のフォーム作成ツールであり、フローよりも常に簡単に学習できます。とはいえ、フローチームはそのハードルをできるだけ低くすることに取り組んでいます。複雑さという点で、OmniStudio はフローと LWC の中間に位置し、フォーム作成の強力な機能を提供します。 **配送の委任**:LWC を必要とする要件があるからといって、ソリューション全体を LWC で構築する必要があるわけではありません。LWC が必要な部分はコーディングし、不要な部分はローコードソリューションで作成するなど、ソリューションをモジュール化する方法を検討します。これにより、多様なチームの効率を最大化し、各個人が専門分野に適した問題を解決できるようになります。 次に、フローと LWC について説明します。反応型画面コンポーネントを使用すると、画面フローコンポーネントが同じ画面上で相互にやりとりできるようになり、アーキテクト、システム管理者、開発者向けのまったく新しいツールが使用可能になります。開発者は、組織全体で再利用できる明確な目的に基づくモジュールコンポーネントを作成できるようになり、チームの全員の生産性が向上します。開発者は、標準フローコンポーネントとカスタムフローコンポーネントを組み合わせてフォームのダイナミズムを実現することで、新しい課題の解決に集中し、時間を節約できます。フローの反応型コンポーネントを使用すると、フォームの作成時にフローと LWC を混在させることができます。 **メンテナンス性と長期所有**:複数ステップのフォームがある場合は、フローから開始するか、フローと LWC を組み合わせて使用することをお勧めします。ローコードのチームがソリューションをメンテナンスしている場合、その利用者向けにソリューションを可能な限り設定および拡張できるようにする方法を検討します。どのツールを選択しても、ソリューションを[構成可能](/docs/architect/ja-jp/well-architected/guide/composable)な単位に整理して、メンテナンス性と安定性を向上させます。 ### ページレイアウト 今後、レコード詳細ページを設定するための推奨方法は、Lightning ページを使用した Lightning アプリケーションビルダーでの動的フォームです。ページレイアウトが強化されて久しく、今後もその傾向は続くでしょう。その理由は次のとおりです。 - 動的フォームの柔軟性は向上しています。Lightning アプリケーションビルダーでは、項目やセクションを任意の場所に直接配置できます。ここでは、セクション、タブ、アコーディオンを利用できます。また、Lightning ページのコンポーネントと同様に、複数のページレイアウトやレコードタイプを定義しなくても、項目やセクションの表示を制御できます。 - アコーディオンおよびタブコンポーネントでは、最初に表示される項目の数を制限できます。どういう意味だと思う?ページの読み込み時間を短縮。 - Lightning ページでは、ページの内容やページへのアクセス権を持つユーザーなど、ページに関するすべてを Lightning アプリケーションビルダーから管理できるため、レイアウト管理がシンプルになります。Lightning ページに変更を加えるためにページレイアウトを更新する必要がなくなりました。言うまでもなく、表示ルールを使用することで、誰がいつどの項目を表示するかを制御するために複数のページ (またはページレイアウト) を作成する必要がなくなります。また、Lightning ページとページレイアウトの両方を割り当てるのではなく、Lightning ページのみをユーザーに割り当てる必要があります。 可能な限り動的フォームを使用し、必要な場合にのみページレイアウトに戻ることをお勧めします。いつものように、組織にとって最も影響のある改善点に関するフィードバック[を Idea Exchange](https://ideas.salesforce.com/s/)でお待ちしています。 ### Performance 動的フォーム、画面フロー、OmniStudio、LWC に関連するパフォーマンスに関する考慮事項は、これらのテクノロジー自体がどのようなフレームワークに基づいているかが中心になります。LWC ベースのもの (もちろん LWC も) は、Aura ベースのものよりもパフォーマンスが優れています。LWC フレームワークでは、コア機能がフレームワークの抽象化を介して JavaScript ではなく Web エンジンでネイティブに実装されるため、パフォーマンスが向上します。よく知らない場合は、[このブログ投稿](https://developer.salesforce.com/blogs/2018/12/introducing-lightning-web-components.html)を参照してください。 2019 年に、Aura と LWC の同じ機能のパフォーマンスを比較した[ケース スタディ](https://developer.salesforce.com/blogs/2019/06/case-study-dreamhouse-gains-speed-by-switching-to-lwc.html)を実施しました。DreamHouse を Aura から LWC に変換した結果、開発環境が現在の Web フロントエンド開発標準とパターンにはるかに適合しただけでなく、パフォーマンスが大幅に向上しました。ラボでの測定値では、同じ 2 つのページで、コールド キャッシュでは**2.4%~24.7**%、ウォーム キャッシュでは**31.83%~\*\***63.32%\*\*の向上が示されています。 では、フォームテクノロジーはどのフレームワークを使用していますか?つまり、この優れたパフォーマンスからメリットを得られるフォームテクノロジーは? - Lightning ページのメタデータに統合されている動的フォームは、LWC スタックを使用する基盤上に構築されており、要求の厳しい機能を実装できます。パフォーマンスのボーナスとして、動的フォームでは順次表示が使用されます。これにより、多数の項目が含まれるページのページ読み込み時間が短縮されます。 - 画面フローは LWC に基づいて作成されており、2 つの標準コンポーネントを除き、ほとんどの標準コンポーネントが LWC に変換されています。ファイルのアップロードと画像。フローチームはフローランタイムクライアントとそのほとんどのコンポーネントを LWC に変換しましたが、顧客は Aura 画面コンポーネントを LWC に変換する必要があります。さらに、Salesforce では画面フローの新しい反応型コンポーネントフレームワークの LWC コンポーネントのみがサポートされます。その方法を説明する優れた Trailhead モジュールがあります。[Lightning Web Components for Aura Developers](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers) (Aura 開発者向けの Lightning Web コンポーネント)。言うまでもなく、画面フローまたはその他のコンテナのカスタムコンポーネントを作成する場合は、常に LWC を使用してください。 - 使用可能な OmniStudio のバージョンがいくつかあります。長年の顧客の場合、Angular を使用している可能性があります。すべての新規ユーザーは LWC ベースの OmniScript と FlexCard から開始し、既存のユーザーは Angular から移行することをお勧めします。 - LWC は . . .LWC かこれはフリービーです。 ## 完了の挨拶 アーキテクトは、使用可能なすべてのオプションと、それを特定の使用事例でどのように適用できるかをしっかり理解することが重要です。Salesforce でフォームを作成する場合、オプションはローコード (Lightning アプリケーションビルダーの動的フォーム、Flow Builder の画面フロー、OmniStudio の OmniScript を使用) からプロコード (LWC フレームワークを使用) まで多岐にわたり、画面フローまたは OmniScript と LWC が中間に組み合わされます。Salesforce でフォームを作成または再設計する場合は、このガイドを参考にしてください。合理化された便利なフォームを設計する方法に関するガイダンスが必要な場合は、[Salesforce Well-Architected にお問い合わせください。Engaging](/docs/architect/ja-jp/well-architected/guide/engaging)。 ### ご意見をお聞かせください お客様に最も関連性の高いコンテンツを公開するには、アンケートに[ご協力ください](https://forms.gle/FCFCES6vsRbKv4E29)。このコンテンツに関するフィードバックをいただき、次に何をご覧になりたいかお聞かせください。 # プラットフォーム決定ガイドの使用開始 このセクションでは、Salesforce Platform の機能に関する重要なアーキテクチャ上の意思決定を行うための実践的な指針を提供します。非同期処理、レコードトリガーイベント、フォーム作成、イベント駆動型アーキテクチャ、ステップベースの非同期フレームワークについて説明し、アーキテクトが拡張性とメンテナンス性が高く、パフォーマンスに優れたプラットフォームソリューションを設計できるようにします。 --- ## 非同期処理 [非同期処理](/docs/architect/ja-jp/decision-guides/guide/async-processing)では、Salesforce の非同期操作のツールとアプローチに関するガイダンスが提供されます。 - **非同期処理ツール**:Queueable Apex、スケジュール済み Apex、プラットフォームイベントトリガー、変更データキャプチャ、スケジュール済みパス (確定後フロー)、非同期パス (レコードトリガーフロー) の比較と、適切な使用事例に関する指針。 - **サーバー側の非同期処理**:実行時間の長いデータベース操作、外部コールアウト、および大量のレコード処理のパターン。 - **クライアント側の非同期処理**:Apex 継続コールアウトやクライアント側の非同期処理などの手法。ブラウザーまたはモバイルアプリケーションで実行される可能性があります。 - **決定フレームワーク**:使用事例の検証、拡張性、トランザクションが真に非同期である場合の理解、極端な負荷イベントの監視、処理を検討します。 - **ベストプラクティスとアンチパターン**:送信インテグレーション、一般的な落とし穴の監視、回避など、適切な使用のためのガイダンス。 アーキテクトは拡張性と信頼性が高く、メンテナンス可能な非同期パターンを実装できるため、パフォーマンスを低下させる落とし穴を回避できます。 --- ## フォームの作成 [Building Forms](/docs/architect/ja-jp/decision-guides/guide/build-forms)は、アーキテクトが Salesforce フォーム作成オプションについてガイドします。 - **フォーム作成ツール**:動的フォーム、画面フロー、OmniStudio、画面フローと Lightning Web コンポーネント(LWC)、LWC の比較(スキルとライセンスに関する考慮事項を含む)。 - **決定フレームワーク**:オブジェクトへの影響、フォーム範囲、ナビゲーション、場所 (アプリケーション、モバイル、Web)、UX、テスト自動化を考慮します。 - **ツール選択ガイダンス**:簡単なレコードレイアウトから複数ページのウィザード、ブランド設定された顧客向けフォームへのおすすめ。 - **組み合わせパターン**:画面フローナビゲーションと LWC スタイル設定などのツールを組み合わせるためのガイダンス。 - **高度な機能**:ツールの選択肢を提供する機能と制限について詳しく説明します。 アーキテクトが特定の UX、機能、インテグレーション要件に適したフォーム作成方法を選択できるようにします。 --- ## イベント駆動型アーキテクチャ [イベント駆動型アーキテクチャ](/docs/architect/ja-jp/decision-guides/guide/event-driven)では、Salesforce イベントツールとパターンの包括的なガイドが提供されます。 - **イベントツール**:プラットフォームイベント、変更データキャプチャ、Pub/Sub API、MuleSoft Anypoint、ストリーミング API、インテグレーションに関する考慮事項の概要。 - **イベント駆動型パターン**:さまざまなイベント駆動型の使用事例の公開/登録、ファンアウト、渡されたメッセージ、ストリーミング、キューイングパターンが含まれます。 - **MuleSoft との統合**:エンタープライズアーキテクチャでの Anypoint コネクタ (Pub/Sub、JMS、Kafka、Solace、MQ、MQTT、AMQP) の使用。 - **プラットフォームイベントおよび変更データキャプチャ**:PushTopic/汎用イベントからの移行による、レコードと項目の変更を公開するための推奨メカニズムに関するガイダンス。 - **実装パターン**:拡張性、一貫性、エラー処理、監視に関するベストプラクティス。 アーキテクトは、複数のシステムを効率的に接続するスケーラブルでほぼリアルタイムのイベント駆動型システムを設計できます。 --- ## ステップベースの非同期フレームワーク [ステップベースの非同期](/docs/architect/ja-jp/decision-guides/guide/step-based-async-framework)フレームワークは、モジュラー型の拡張性の高い非同期ジョブ処理のフレームワークを提供します。 - **フレームワークアーキテクチャ**:コンポーネントには、キュー可能 Apex、ファイナライザー、スケジュール済みフロー、Apex カーソル、呼び出し可能なアクション、Slack インテグレーションが含まれます。 - **ステップベースの処理**:休憩は、共有ガバナンスと運用の可視性を使用して実行、再試行、再開できる独立したステップに分割されます。 - **実装ガイダンス**:ステップ インターフェイス、ステップ プロセッサ、Apex 呼び出し可能レイヤ、遅延処理、通知のパターン。 - **ベストプラクティス**:ほとんどの情報が CRM に存在する場合、大量のワークロードがある場合、階層またはツリーベースのレコード処理の場合にお勧めします。使用すべきでない状況に関する指針。 - **エンタープライズ クラスの機能**:ガバナンス、コンプライアンス、分散状態、進行状況の追跡、SLA の監視、障害診断、監査レベルのログ。 アーキテクトは、モノリシックな一括処理ジョブとチェーンされた非同期コールに代わるスケーラブルな方法を提供し、完全な運用の透明性で大量の Salesforce ワークロードをサポートします。 --- ## レコードトリガーオートメーション [レコードトリガー自動化](/docs/architect/ja-jp/decision-guides/guide/record-triggered)は、Salesforce Platform でレコードトリガー自動化を設計するためのフレームワークを提供します。 - **ツールの選択**:自動化密度(低、中、高)と密度選択マトリックスに基づいて、レコード トリガー フローと Apex トリガーを使用するケース。 - **自動化密度**:自動化の数量、レコード量、依存関係の無秩序な増加を評価して、フロー、ハイブリッド(呼び出し可能な Apex を使用するフロー)、Apex トリガーのいずれかを選択する方法。 - **エントリー ポイントとガバナンス**:Salesforce オブジェクトごとに 1 つのエントリポイント。エントリ条件、再帰制御、順序付き実行に関するガイダンス。 - **非同期呼び出し**:レコードトリガーフローまたは Apex から非同期プロセスを呼び出すタイミングと方法。エラー処理とガバナ制限に注意してください。 - **ベストプラクティス**:一括処理、ハイブリッド フローと Apex の設計、トリガー自動化の一般的な落とし穴の回避のパターン。 アーキテクトは、プラットフォーム標準に準拠した拡張性、メンテナンス性、パフォーマンスに優れたレコードトリガー自動化を設計できます。 ## 概要 Salesforce Platform は、複雑なビジネスプロセスの要求を満たすために自動化アーキテクチャを継続的に進化させてきました。旧世代 (ワークフロールールとプロセスビルダー) では、イベント駆動型ロジックの最初のステップが提供され、イベント駆動型ロジックの自動化機能が拡張され、ビルダーの範囲が広がりました。 この進化により、次の 2 つの補完的な柱を中心に、ハイパフォーマンスの統合アーキテクチャが実現しました。レコードトリガーフローおよび Apex トリガー。このドキュメントでは、トリガー自動化を設計するときに十分な情報に基づいて意思決定を行うためのフレームワークとガイドラインについて説明します。 ## 範囲内の商品
フロー Salesforce Flowは、強力なポイント・アンド・クリック自動化ツールです。ユーザーは、コードを記述せずに、Flow Builderを使用して複雑なビジネス・プロセス、画面、ロジックを視覚的に作成できます。データ更新、メールの送信、ユーザーへの案内などのタスクを自動化し、画面フロー (ユーザー操作) やトリガーフロー (レコード/スケジュール済みイベント) などの種別で柔軟性を提供します。
Apex Salesforce Apex は、Java に似た Salesforce Platform 用の独自のオブジェクト指向プログラミング言語で、カスタムビジネスロジックの構築、プロセスの自動化、宣言型ツール以外のコア CRM 機能の拡張に使用されます。
## ポイント Salesforce Platform で拡張性、メンテナンス性、パフォーマンスに優れたレコードトリガー自動化を構築するには、統制の取れたアーキテクチャ主導のアプローチが必要です。フローと Apex の選択とそれぞれの実装は、明確な原則セットに従って行われます。これらのポイントはこれらの原則を要約し、最新の自動化設計の基本ルールとして機能します。 - **Salesforceオブジェクトの自動化密度に基づいて、ジョブに適したツールを選択します。** - **低密度**の自動化には、Salesforceオブジェクトのレコードトリガーフローを使用します。 - 呼び出し可能なApexを使用してレコード トリガー フロー ロジックを増強し、**中密度**の自動化を実現します。 - SalesforceオブジェクトのApexトリガーを使用して、**高密度**の自動化を実現します。 - **非同期プロセスをトリガーするときは注意してください。** このルールは、レコード トリガー フローで非同期プロセスを呼び出す場合でも、Apex からキュー可能なジョブを呼び出す場合でも適用されます。このパターンは、作業の負荷を軽減しがちですが、複雑なエラー処理シナリオが発生し、ガバナ制限に達するリスクが高まる可能性があります。 - **Salesforce オブジェクトごとに 1 つのエントリポイントを使用します。** 特定の Salesforce オブジェクトで、自動化へのエントリポイントとして 1 つのメカニズムを使用します。同じオブジェクトのエントリ ポイントとしてフロー トリガーと Apex トリガーを混在させないようにしてください。 ## 決定ポイント ### 宣言型とプログラムによる実装 フローと Apex には、共通の基本機能セットがあります。各ツールは、レコードの照会、条件ロジックの実行、変数の割り当て、およびレコードの作成、更新、削除などの DML 操作 (指定された順序で実行) を実行できます。 ただし、この機能の重複は、ツールが交換可能であるという意味ではありません。アーキテクチャの選択は、タスクを実行できる_かどう_かではなく、タスクを_どのよう_に実行し、パフォーマンス、拡張性、および保守性に長期的な影響があるかについてです。フローは、宣言型の明確さと簡単なプロセスの実装速度に優れており、Apexは複雑なソリューションに必要な詳細な制御とロー・パワーを提供します。 ### 自動化密度 **自動化密度**は、特定の Salesforce オブジェクトにかかる負荷です。これは、オブジェクトの最適な実装を判断するためのヒューリスティックとして機能します。自動化の密度が高まるにつれて、トランザクション制限に違反する可能性が高くなります。 量と複雑さの 3 つの特定のディメンションを調べて、自動化密度を計算します。 - **自動化数量:**1 つのデータ操作言語 (DML) イベント中に実行される一意の自動化メタデータエントリ (フロー、トリガーアクションなど) の未加工数。 - **レコード量：**API 読み込みまたは高負荷のバッチ処理によって処理されるトランザクションあたりのレコード数。パフォーマンスが重要になります。 - **依存関係の無秩序な増加：**最初の CRUD 操作によってトリガーされる下流の DML 操作の基準。1 つの更新が関連オブジェクトの更新にカスケードされるグラフの深さを定量化します (ケース → 取引先 → 取引先責任者 → カスタム積み上げ集計など)。 自動化密度ディメンション Salesforceアプリケーションの範囲と複雑さが増してきたら、1つのプライマリ エントリー ポイント(レコード トリガー フローまたはApexトリガー)にコミットします。1 つの Salesforce オブジェクトで複数のメカニズムにわたって自動化をパーティション分割すると、メンテナンス性が低下し、ガバナンスが断片化してしまうため、避けてください。 ### 密度選択マトリックス このマトリックスを使用して、Salesforce オブジェクトに必要なアーキテクチャ標準を決定します。 - **レコード トリガー フロー**は、自動化密度が低い場合に推奨されるソリューションです。互いに独立していてわかりやすい自動化に最適なパワーとアクセシビリティのバランスを実現します。 - **ハイブリッド パターン(**呼び出し可能なApexを使用したレコード トリガー フロー)は、複雑さが増している中密度の自動化に適した強力でメンテナンス可能な選択肢です。このパターンにより、チームは宣言型フローで順序付けられた振付を維持しながら、計算負荷の高い操作をApexに委任し、アクセス性とパフォーマンスのバランスを取ることができます。 - **Apexトリガー**は、高密度の自動化をサポートする堅牢なアーキテクチャ基盤に必要なビルディング ブロックを提供します。Apexのパフォーマンス、詳細な制御、およびオブジェクト指向の抽象化と多態性は、これらのシナリオの複雑さと拡張性の管理に適しています。
密度レベル 自動化数量 データ量 (バッチサイズ) 依存関係の無秩序な増加 アーキテクチャ標準
Low (低) < 15
オートメーション		 標準
ユーザー主導の UI 操作または小さな API 読み込み (1 ～ 200 レコード)		 分離
自己完結型ロジック。同じオブジェクトまたは関連オブジェクトに対する 0 ～ 1 のダウンストリーム DML 操作。		 レコードトリガーフロー
Medium (中) 15–30
オートメーション		 モデレート
標準バッチ処理 (慎重な一括処理が必要なロジックを使用)		 結合
親/子は 2 ～ 4 個のダウンストリーム DML 操作を更新します。再帰のリスク		 ハイブリッドパターン
フロー + 呼び出し可能な Apex
High (高) > 30
オートメーション		 High (高)
一括 API 読み込みを使用する大量のデータ (2,000 ～ 10,000 件以上のレコード)		 複雑および再帰的
深い連動関係グラフ (5 つ以上の下流 DML 操作)。三角再帰ループのリスク		 Apexトリガー メタデータ フレームワーク
実際のアーキテクチャ上の意思決定では、自動化密度のすべてのディメンションをまとめて加重する必要があります。特定の Salesforce オブジェクトの自動化メカニズムを選択するときは、将来の範囲を考慮してください。 また、Salesforce はマルチテナント環境で共有リソース管理を適用し、暴走した自動化によって共有リソースが独占されないように [府の制限](https://developer.salesforce.com/docs/atlas.en-us.salesforce_app_limits_cheatsheet.meta/salesforce_app_limits_cheatsheet/salesforce_app_limits_platform_apexgov.htm)を適用しているため、1 日あたりの DML 操作の合計数を考慮してください。1 日の DML 量が多い Salesforce オブジェクトでは、自動化の選択を慎重に行う必要があります。たとえば、CPU 時間 (60,000 ミリ秒) とヒープサイズ (12 MB) の非同期制限は同期制限よりも高くなります。さらに、非同期実行に関する組織の 24 時間の制限 (ユーザーライセンスの 25 万倍 (200 倍) として計算) では、実行時の例外を回避するために 1 日あたりの合計 DML をアーキテクチャ設計に組み込む必要があります。 ## 商品比較 レコードトリガーフローは、レコードトリガー自動化のためのプラットフォームの主要な宣言型ツールです。フローの使いやすさと組み込みのプラットフォーム保護により、チームは拡張性と信頼性に優れたソリューションを簡単に構築できます。これは、Salesforce Platform でソリューションを構築するほとんどのチームにとって理想的な選択肢です。 Apex は、プラットフォーム独自の強力な型付けのオブジェクト指向プログラミング言語です。Apex は、自動化密度の高い Salesforce オブジェクトや、高パフォーマンス、高度なロジック、トランザクションの詳細な制御を必要とする使用事例に使用します。 意思決定プロセスを支援するために、このマトリックスでは主要なアーキテクチャ機能間のフローと Apex を直接比較しています。
機能 レコードトリガーフロー Apex トリガー
デリバリとメンテナンスの迅速化 推奨
Flow Builder のビジュアル・ユーザー・インタフェースを使用すると、管理者やその他の宣言型ビルダーは、Apexコードの作成、テスト、リリースよりも迅速に自動化を作成および変更できます。このインターフェースにより、より幅広いチームメンバーがビジネス上の価値を実現でき、単純なタスクの専門的な開発者リソースへの依存が軽減されます。		 専門知識が必要
Apex では、コードの実装、テスト、管理に適切なスキルを持つソフトウェア開発者が必要です。
モジュール性 利用可
レコードトリガーフローはデフォルトでモジュール化されています。モノリシックロジックではなく、チームは特定の要件に合わせて個別のフローを作成し、フロートリガーエクスプローラーを使用してそれらを一緒に振り付けます。このモジュール化により、変更が分離され、簡単に拡張できるため、長期的な所有コストを大幅に削減できます。		 利用可
Apex は、設計上、機能モジュールに分割されています。各 Apex クラスは、1 つの機能モジュールを実装することを目的としています。
表示とガバナンス 推奨
フローの視覚的な性質により、ビジネスロジックが直感的に表現されます。フロートリガーエクスプローラーでは、オブジェクトのすべてのフローの統合ビューが提供されるため、アーキテクトやシステム管理者はコードを読むことなく簡単に理解、管理、トラブルシューティングできます。		 専門知識が必要
メタデータ フレームワークを使用してトリガーを整理することは有益ですが、Apexでは、コードを整理して保守できるように、統制の取れた開発チームが必要です。
高パフォーマンスの一括データ処理 非推奨
複雑なロジックや大量のデータを処理する場合、ガバナ制限に達するリスクが高くなります。		 推奨
Apexコードはプラットフォームのコア・サービスに近い場所で実行され、開発者はクエリの最適化、データ処理、アルゴリズムの効率性をより詳細に制御できます。これにより、特に大量のデータを含む複雑なシナリオでパフォーマンスと拡張性が向上します。
堅牢なロジックとデータ構造 利用可
フロー変換要素は、いくつかの複雑な処理タスクに役立ちます。ただし、フローにはネイティブの Map および Set データ構造がないため、複雑なデータ処理が煩雑になり、計算効率が低下します。		 推奨
Apex では、対応付け、設定、プログラムによるループにフルアクセスして、効率性の高い安全な一括データ操作を実行できます。Apex は、フル機能のプログラミング言語であり、複雑なビジネス問題を保守可能かつ効率的に解決するのに役立つ複雑な論理構造、データ構造、設計パターンへのアクセスも提供します。Apexには、現在宣言型ツールでは使用できない高度な関数（BusinessHours、Cryptoなど）の豊富な標準ライブラリが含まれています。
トランザクション制御 使用不可
フローでは、部分的なトランザクションの確定またはロールバックで `Database.savepoint`、`Database.rollback`、または部分的に成功した DML 操作にアクセスできません。		 利用可
Apexは、トランザクションの整合性と複雑なエラー・リカバリのシナリオをフルかつ詳細に制御します。
メール配信 推奨
レコードトリガーフローから事前設定されたメールアラートを送信するのは、簡単で拡張性があります。カスタムメールアラートは、実行時に作成および配布できます。カスタムメールには、毎日のメール送信制限が適用されます。		 利用可
Apex はカスタム電子メール メッセージを生成および送信できます。Apex から送信されるすべてのメールには、1 日あたりのメール送信制限が適用されます。
プラットフォーム保護の適用 推奨
フローには、自動一括処理や自動再試行などの組み込みの保護が含まれます。これらの保護により、価値実現までの時間を短縮し、複雑な手動コーディングを必要とするパフォーマンスの低下を回避できます。		 手動実装が必要
一括処理などの保護は、明示的にコーディングする必要があります (コレクションの管理やループ内での SOQL の回避など)。自動再試行はトリガーに固有ではなく、実装するには複雑なカスタムロジックが必要です。
非同期処理 利用可
フローは、非同期パスで個別のトランザクションを必要とする自動化の簡単なメカニズムを提供します。これらの自動化には 1 日の制限が適用されます。		 利用可
Apex では、変更データキャプチャと、分離されたトリガー登録者によって処理されるキュー可能なイベントを使用して、完全な制御が可能になります。
スケジュール済み処理 推奨
フローのスケジュール済みパスには、ユニークで強力なスケジュール機能 (「完了予定日の 3 日前に開始」など) があります。この機能には、レコードのデータが変更された場合の自動キャンセルと再スケジュールが含まれます。これらの自動化には 1 日の制限が適用されます。		 使用不可
Apex トリガーでは、自動キャンセルを使用する一時的なレコード固有のイベントをネイティブにスケジュールできません。スケジュール済み Apex は存在しますが、基本的に異なるメカニズムであり、特定の時間に実行され、トリガーの一部として個々のレコードの処理中にスケジュールされることはありません。
注文と振付 利用可
フロートリガーエクスプローラーでは、管理者は同じオブジェクトの複数のフローの相対的な実行順序を定義できます。		 利用可
トリガーフレームワークでは、自動化の正確な順序を詳細に制御できます。
同じレコードの項目自動更新 使用可能 (保存前)
レコードトリガーフローは、最初の DML 確定の前にトリガーレコードを更新するための最もパフォーマンスの高い宣言型オプションです。		 使用可能 (保存前)
Apex は、最小限のオーバーヘッドで最高のパフォーマンスを提供します。
クロスオブジェクト CRUD 使用可能 (保存後)
フローは、シンプルで複雑度の低いクロスオブジェクト DML 操作に適しています。		 使用可能 (保存後)
Apexは、重複除外、エラー処理、クロスオブジェクトDML操作のパフォーマンスをより詳細に制御します。
高価な計算の重複排除 利用可
フローは、自動一括処理によって冗長なクエリと DML ステートメントを排除することに長けています。ただし、異なるフロートリガー間、または 1 つのトランザクション内の同じフローの複数の呼び出し間で状態をキャッシュまたは共有することはできません。この制限は、極端なパフォーマンスのシナリオでは重要になる場合があります。		 推奨
Apexは、コストのかかる操作の重複除外メカニズムを提供します。開発者は、静的プロパティと変数を使用するトランザクションキャッシュと、プラットフォームキャッシュを使用するプラットフォームレベルのキャッシュを活用して、データを保存および再利用できます。これらの技術は、SOQL クエリなどのトランザクションガバナ制限の消費を減らし、高いパフォーマンスと拡張性を確保するために重要です。
カスタムエラー処理 利用可
CustomError 要素は、保存操作をブロックし、ユーザーにメッセージを表示することができます。		 推奨
addError() メソッドは、柔軟な項目レベルおよび条件付きエラーメッセージングを提供します。
## 使用事例 ### 最適なおすすめ 次の表に、一般的な使用事例の一般的な「最適」な推奨事項を示します。最終的には、このドキュメントの「_関連するベストプラクティス_」セクションに記載されているような、特定のシナリオに最適な追加考慮事項も考慮します。ここでは、フローとApexの特定の組み合わせが最適なアプローチである場合についての詳細を説明します。
使用事例 説明 Best-Fit 根拠
高パフォーマンスのバッチ処理 何千ものレコードを効率的に処理する必要がある自動化 Apex Apex は、プラットフォームとのインタフェースと未フォーマット時の速度を実現する豊富な API を提供します。
複雑なデータ処理 高度なデータ操作が必要なシナリオ Apex Apex は、Map や Set などのデータ構造を提供します。これらは、フローではネイティブに使用できず、パフォーマンスが高く一括安全なコードを記述するために不可欠です。
トランザクション制御 セーブポイント、ロールバック、部分的な確定などの制御メカニズム Apex Apex は Database.savepoint や Database.rollback などのメカニズムへのアクセスを提供し、部分的に成功した DML 操作を処理する機能を備えています。
高度なカスタム検証 レコードの複数の項目のデータ検証 Apex フローでは `CustomError` 要素を使用して保存を防ぐことができますが、サブフローを含むすべてのフロー種別で使用できるわけではありません。Apex addError() メソッドは、トリガー処理中にいつでもレコードに追加できる複数の項目固有のエラー メッセージを提供します。
単純なプロセス内のロジックがやや複雑 高度な関数の標準ライブラリによって簡略化された、中程度の複雑さのロジックとデータ操作 (複雑なプロセスの一部として発生) フロー + Apex レコード トリガー フローはオーケストレーション レイヤーとして機能し、高複雑度の操作は呼び出し可能Apex内にカプセル化されます。
シンプルから適度に複雑なロジック 主データオブジェクトと関連データオブジェクトの両方に対するトリガー更新による、低から中程度の複雑さのデータ操作 フロー フローは、管理者と開発者の両方がアプローチできる宣言型モデルに基づいているため、通常はフローが適しています。
通知および送信メッセージ 送信メールおよびメッセージの送信 フロー フローを使用すると、レコードの変更時にメールアラートと送信メッセージを送信し、容易かつ拡張性の高い方法で行うことができます。
スケジュール済み処理 将来の動的な日付 (完了予定日の 3 日前など) での自動化 フロー スケジュール済みパスは、レコードのデータが変更された場合にプラットフォームが自動的にこれらのパスのスケジュール、キャンセル、再スケジュールを処理するため、フローに独自の強みを提供します。
### スケーラブルな処理:詳細な非同期使用事例 拡張性は、実装を設計するときの重要な考慮事項です。レコードトリガーオートメーションのビジネスロジックが複雑になったり、実行時間が長くなったり、大量のデータが関係したりすると、Salesforce Platform のコアガバナ制限がアーキテクチャ上の制約になります。データの一括更新、複雑な API コールアウト、重い計算などの操作は、合計 CPU 時間や 1 つのデータベーストランザクション内の DML ステートメント数などの制限に違反するリスクを高めます。制限例外が原因で同期トリガーが失敗すると、ユーザーの保存トランザクション全体がロールバックされ、ユーザーエクスペリエンスが低下し、データが失われる可能性があります。この固有のリスクにより、複雑な作業の負荷が軽減されるアーキテクチャパターンが必要になります。 この場合、非同期自動化が不可欠です。アーキテクトは、非同期メカニズムを使用して、実行時間が長い作業や大量の作業を、同期レコード保存の主トランザクションから効果的に分離できます。迅速かつ信頼性の高い方法で保存が完了し、重い処理は後で実行される別のプラットフォーム管理トランザクションに委任されます。分離により、安定性が向上し、トランザクションの失敗が回避され、拡張性の高いエンタープライズアプリケーションを構築するために不可欠です。このプラットフォームには、信頼性、量、複雑さに関する個別の利点とトレードオフがある、このための特殊なツールがいくつか用意されています。 ### フローの非同期パス レコードトリガーフローの \[非同期で実行] パスは、「起動して忘れる」非同期ロジックの最もシンプルなメカニズムを提供します。このパスは、元のレコード保存トランザクションがデータベースに正常にコミットされた後、個別のトランザクションで実行されます。 - **理想的な使用事例**:これは、即時実行やカスタムエラー処理を必要としないタスクに適しています。たとえば、メール通知の送信、フォローアップ ToDo の作成、外部システムへの簡単なコールアウトなどです。 - **制限**:このメカニズムは、他の非同期フローインタビューと同じ 1 日のガバナ制限を共有します。大量の処理には適していません。 ### 変更データキャプチャ (CDC) 変更データキャプチャ (CDC) は、大規模シナリオでのレコード変更によってトリガーされる非同期ロジックを処理するための高スループット、拡張性、復元性の高いパターンです。このモデルでは、トリガーの唯一の責務はレコードの同期保存です。次に、プラットフォームは、大規模イベントバスへのレコードの変更を含む詳細なイベントメッセージを公開します。個別の専用 Apex トリガーがこの変更イベントに登録します。複雑で実行時間が長い作業や非同期の作業を実行します。 - **給付**:このパターンでは、非同期プロセスを最初のユーザートランザクションから分離します。非同期処理が失敗しても、ユーザーのレコード保存はロールバックされません。このパターンでは、複数の内部登録者または外部システムが使用できる耐久性のあるイベントストリームも提供され、イベントを最大 72 時間再生できるため、強力な復元力が得られます。 - **制限**:CDC イベントメッセージには、レコードの前の状態 (Apex `Trigger.oldMap`に相当) は含まれません。イベントペイロードには、新しい項目値が含まれますが、変更元の値は含まれません。そのため、特定の状態遷移に基づいてロジックを実装することが困難です (たとえば、`Status__c`が「待機中」から「承認済み」に変更された場合にのみ実行)。イベント登録者でオブジェクトの項目履歴を照会することでこれを軽減できますが、これによりプロセスが複雑になり、特定の関心項目で項目履歴管理が使用できない場合があります。これにより、CDC にオフロードできる自動化の種類が制限される場合があります。 デフォルトでは、CDC は最大 5 つの Salesforce オブジェクトで有効にできます。追加が必要な組織は、この制限を削除し、イベント配信の割り当てを増やすアドオンライセンスを購入できます。 ### トリガーからのキュー可能 Apex Queueable Apex ジョブをトリガーから直接キューに入れることは、リスクの高いパターンと見なす必要があります。これは、Apex による制御が必要な場合 (複雑なロジックやカスタム再試行メカニズムなど) にのみ使用され、CDC は実行可能なオプションではありません。 Queueable Apex が必要な場合は、実装に適切な保護を含める必要があります。 - **チェックの制限**:別のジョブを追加する前に、コードでトランザクションにすでにキューに入っているジョブの数を確認する必要があります。 ``` if (Limits.getQueueableJobs() < Limits.getLimitQueueableJobs()) { ... } ``` - **コンテキスト認識**:コードは、一括処理ジョブ (`System.isBatch()`) などの非同期コンテキスト内で実行されているかどうかを検出し、そのコンテキストでのトランザクションあたりの 1 ジョブの制限を厳格にするように動作を変更する必要があります。 ### トリガーされた非同期 Apex の制限に関する考慮事項 同期トリガーから非同期 Apex を呼び出すと、安定性のリスクが生じます。組織レベルの影響 (制限を超えるなど) を回避するために、このパターンには厳格な設計とテストが必要です。 - 非同期Apex実行の1日あたりの制限(`Batch`、`Queueable`、`@Future`)は、組織全体で共有されます(通常は25万件、またはユーザー・ライセンスに基づく計算)。20,000 レコードの一括データ読み込みでは、トリガーが 200 のチャンクで実行され、100 の個別のトリガー呼び出しが発生します。一括バッチサイズが 200 レコード未満の場合、さらに多くなります。各呼び出しで非同期ジョブがキューに入れられると、1 つのデータ読み込みによる 1 日あたりの制限のかなりの部分が消費される可能性があります。この消費により、非同期リソースの他の重要なビジネスプロセスが飢餓になる可能性があります。 - ジョブをキューに入れるためのガバナ制限は、コンテキストによって大幅に異なります。UI のユーザーアクション (_同期_トランザクション) によって起動されるトリガーから、最大 50 個のキュー可能なジョブをキューに追加できます。ただし、バッチ Apex クラスの `execute` メソッド内 (非_同期_トランザクション) で起動されたトリガーから、キューに入れることができるジョブは 1 つのみです。この違いを考慮しないと、大規模データ操作中に`LimitException`エラーが発生する、一般的で重大な障害点になります。 - トリガー コンテキストから直接 Schedulable Apex(`System.schedule`)または Batch Apex(`Database.executeBatch`)をコールすると、アンチパターンになります。これらのメソッドは、トリガーコンテキストから呼び出すようには設計されていません。これを行うと、非同期 Apex 割り当てが急速に消費され、制限例外が発生します。 ### 適切な非同期パターンの選択 各非同期メカニズムには、パフォーマンス、ガバナ制限、信頼性に関する特定のトレードオフがあります。このディシジョンツリーをガイドとして使用して、これらのオプションを操作し、使用事例に適したメカニズムを選択してください。 非同期パターン決定ツリー ### スケジュール済みジョブの代替 フローチャートが示すように、大規模な DML 操作に直面しているが (オブジェクトの制限などにより) 変更データキャプチャを使用できない場合、多くの場合、最適なアーキテクチャの選択はトリガーで呼び出されるプロセスを完全に回避することです。 代わりに、スケジュール済みプロセスを使用することを検討してください。これは、スケジュール済みフローまたはスケジュール済み Apex のいずれかです。必要な手順は次のとおりです。 1. 同期トリガーでシンプルで低コストの更新を実行します。たとえば、`Status__c` フィールドを「処理待機中」に設定したり、Chatter投稿などの低コストの関連レコードを挿入して、レコードの処理が必要であることを示します。 2. 15 分ごとや 1 時間ごとなど、定期的に実行されるスケジュール済みジョブ (スケジュール済みフローまたはスケジュール済み Apex) を作成します。 3. スケジュール済みジョブで待機中の状態のすべてのレコードを照会し、制御された大量のコンテキストで複雑なロジックを実行して、レコードを処理済みとして更新します。 このパターンは、重い処理をユーザーの同期保存から完全に分離し、トリガー起動バッチのトランザクションあたり 1 つのジョブの制限を受けず、非リアルタイム要件に対応する拡張性とガバナンスに優れたソリューションを提供します。 スケジュール済みジョブの遅延がビジネス要件で許容されず、CDC またはトリガー起動キューの使用が引き続き制限されている場合は、アーキテクチャの重大な不一致を示します。この時点で、異なるメカニズムを考慮する必要があります。コアアプリケーション設計を再評価すると、次のような特定の結論に達する可能性があります。 - CDC オブジェクト制限を削除するアドオンの購入。 - ほぼリアルタイムの処理が本当に「必須」なのか、スケジュール済みジョブの遅延がプラットフォームの安定性にとって許容可能なトレードオフなのかを判断するビジネス要件に根本的に挑戦します。 ## 機能以外の考慮事項 ### 複雑さ 実装の複雑さのレベルは、ソリューションの総所有コストだけでなく、変化するビジネス要件に適応する能力にも影響します。ベストプラクティスに従わないと、実装が複雑になる可能性があります。このドキュメントの「_Related Best Practices_ (関連するベストプラクティス)」セクションでは、ソリューションの複雑さを軽減するための推奨事項を次に示します。 - ハイブリッドパターン:フローでの複雑なロジックの呼び出し可能な Apex - Apex トリガーでのメタデータフレームワークの使用 - メガフローと複数のフロー ### プロセスと標準 ドキュメントはオートメーション自体と同じくらい重要です。メンテナンス性が確保されるだけでなく、AI やエージェントベースのツールにとっても重要です。ドキュメントは、ビジネスプロセスの理解と管理に役立ちます。 **In Flow** - すべての要素と変数に一貫した命名規則を設定します。 - フローの \[説明] 項目を使用して、フローの全体的な目的、トリガー条件、意図した結果を説明します。 - 個々の要素 (`Get Records`、`Action`、`Transform` など) で [説明] 項目を使用します。これは、意図を伝えるための最良の方法です。これは、呼び出し可能なアクションとサブフローで特に重要であり、説明はアクションによって実行される複雑なロジックを説明する主要な場所です。 **In Apex** - ロジックの背後にある_理由_を、_何_であるかだけでなく、明確にコードにコメントします。 - メタデータ駆動型フレームワークを使用している場合は、メタデータレコードに人間が判読可能な \[説明] 項目が含まれていることを確認し、各ハンドラークラスが実行する内容と実行タイミングを説明します。 DevOps とソース管理は、成熟した開発ライフサイクルの一部です。Salesforce プロジェクトでは、Git などのソース管理ツールを常に使用します。Apex クラスと Salesforce フローはどちらもビジネス ロジックを定義するメタデータであり、バージョン管理する必要があります。 レコードトリガー自動化の管理のコンテキストでは、最新の DevOps パイプラインには不可欠な利点があります。 - **自動化された品質チェック：**[Salesforce Code Analyzer](https://developer.salesforce.com/docs/platform/salesforce-code-analyzer/overview) などのツールは、パイプラインで自動的に実行するように設定できます。静的分析では、昇格前に両方の自動化ツールの問題パターンを検出し、パフォーマンス低下の一般的な原因である、フロー ループ内の非効率的な`Get Records`要素やループのApex内の`SOQL`クエリなどの問題にフラグを設定できます。 - **回帰防止:**自動化密度が高まるにつれて、1 つのフローまたは Apex クラスを変更すると、同じオブジェクトの他の自動化に意図しない結果が生じる可能性があります。提案された変更に対して自動化されたApexテストを実行する堅牢なDevOpsテスト戦略は、新しいフロー バージョンで既存のApexロジックが破損しないこと(およびその逆)を確認する最も信頼性の高い方法です。 - **コラボレーションと表示：**ソース管理は「唯一の情報源」です。これにより、システム管理者と開発者は同じオブジェクトの自動化に並行して取り組むことができます。また、貴重な監査証跡も提供されます。本番プロセスが中断すると、自動化を変更した_ユーザー_、自動化を変更した_タイミング_、および(確定メッセージを介して)自動化を変更した_理由_をすぐに確認できます。 管理者と開発者が混在するチームの場合、[DevOps Center](https://help.salesforce.com/s/articleView?id=platform.devops_center_overview.htm&type=5)では、これらのすべてのステップをコレオグラフィーするのに役立つ統合インターフェイスが提供され、拡張性の高いソース制御ベースの開発プロセスをチームの全員が利用できるようになります。 ドキュメントと DevOps のこの組み合わせにより、組織の長期的な健全性とメンテナンス性が確保され、フォローするすべてのアーキテクトとシステム管理者にメリットがもたらされます。 ## 関連するベストプラクティス 上記の決定ガイドは、実装を計画する前に使用することをお勧めします。使用事例に最適な製品を選択できるようにすることを目的としています。製品を選択したら、実装の既存のベストプラクティスを理解することが重要です。 ### ハイブリッドパターンの活用:フローでの複雑なロジックの呼び出し可能な Apex _オブジェクトあたり1_つのツールの原則は、高密度の自動化を管理するために重要ですが、それを純粋に宣言型か純粋にプログラム スタックかの二者択一として解釈しないでください。より効果的で管理しやすいアーキテクチャ・パターンでは、ハイブリッド・モデルを活用します。つまり、レコード・トリガー・フローをオーケストレーション・レイヤーとして配置しながら、呼び出し可能なApex内で高複雑度の操作がカプセル化されます。 ハイブリッドパターン図 #### オーケストレーションレイヤー:フロー レコードトリガーフローは、ビジネスプロセスのオーケストレーションレイヤーとして機能します。エントリ条件と実行コンテキスト (_何_と_いつ_) を所有します。このレイヤー内で決定ロジックとルーティングを保持することで、フロートリガーエクスプローラーでアーキテクチャのプロセストポロジーを透過的かつ管理可能にし、重要なビジネスロジックがコード内で不明瞭にならないようにします。 #### 複合コンポーネント:呼び出し可能な Apex 複雑なコンポーネントの一般的な例として、ケースレコードのサービスレベル契約 (SLA) の計算の実装があります。BusinessHours オブジェクトとその関連ロジックは、非勤務時間と休日を除外する正確な計算に不可欠ですが、フローではネイティブにアクセスできないため、専用の Apex クラスが使用されます。このクラスは、多くの場合 `ServiceLevelAgreementCalculator` などと呼ばれ、`@InvocableMethod` で注釈が付けられた 1 つの静的メソッドを使用して設計され、経過した営業時間を計算し、SLA が「目標内」か「違反」かを判断し、構造化された出力を返します。このアプローチでは、Apexの複雑で高パフォーマンスのロジックをカプセル化しながら、レコード・トリガー・フローの宣言型オーケストレーション・レイヤーにシームレスに実行して統合できます。 Apex`ServiceLevelAgreementCalculator`・クラスが定義されると、レコード・トリガー・フロー内で使用できるようになります。 このパターンは、懸念の厳格な分離を示しています。宣言型レイヤーはトランザクションライフサイクルとオーケストレーションの管理に使用され、コードは高複雑度の実行に使用されます。コードを基盤ではなく機能的なユーティリティとして扱うことで、パフォーマンスとメンテナンス性のバランスを取ります。 #### ハイブリッドパターンの主な利点 **モジュール性**:決定は、プロセス全体で Apex またはフローを使用するという単一性からそれます。代わりに、アーキテクチャでは複雑なロジックが個別の一括安全ユニットと個別にテスト可能なユニットにカプセル化されます。これらのユニットは宣言型レイヤーで使用される再利用可能なコンポーネントとして機能し、アーキテクチャ設計を複雑にすることなく自動化を拡張できます。 **再利用性**:ロジックはトリガーイベントから分離されます。適切に設計されたコード ユニット(`InvocableMethod`など)は、1回のみ記述されますが、複数のエントリー ポイントで利用されます。レコードトリガーフロー、画面フロー、外部インテグレーション。このコードの再利用により、冗長な開発が排除されます。 **メンテナンス性**:プロセスフローロジックは、宣言型フロー内で引き続き表示および管理できます。この一元化により、デバッグのオーバーヘッドが大幅に削減され、システムの実行順序が確定的で透過的になります。 #### ハイブリッドパターンの制限とトレードオフ フローから呼び出し可能な Apex を使用するハイブリッド モデルは強力ですが、汎用的なアプローチではありません。アーキテクトは、ハイブリッド ソリューションに取り組む前に、特定の制限とトレードオフを認識しておく必要があります。 - **保存前サポートなし**:これは最も重要な制限です。呼び出し可能なアクションは、保存後コンテキスト (アクションと関連レコードのフロー) でのみ使用できます。高パフォーマンスの保存前コンテキスト (項目の高速更新のフロー) では使用できません。そのため、このパターンを使用して同じレコードの項目自動更新を委任することはできません。保存前フローまたはコンテキスト前Apexトリガー内でネイティブのフロー要素を使用して、高パフォーマンスの作業を実行します。 - **復元後のサポートなし：**現在、レコードトリガーフローでは、削除後の復元コンテキストはサポートされていません。Salesforce オブジェクトに、ごみ箱からレコードを復元するときに自動化を実行するというビジネス要件がある場合、Apex トリガーが唯一のソリューションです。 - **大規模シナリオのパフォーマンス・オーバーヘッド：**フロー ランタイムから Apex ランタイムへの移行は、ゼロ コストの運用ではありません。一般に高速ですが、フローのランタイムから呼び出し可能アクションにドロップする動作は、Apex トリガー内に完全に収まるネイティブ実行ほど計算速度は速くありません。ほとんどの中密度の自動化では、このマイクロオーバーヘッドはアクセシビリティの向上にとって無視できるほどの価値があります。ただし、非常に高パフォーマンスで大量のシナリオでは、Apexのみのフレームワークの方が未フォーマット時の計算速度の点で有利です。 ### 従来の自動化の戦略 自動化密度ヒューリスティックは新しいグリーンフィールドアーキテクチャの決定的な指針となりますが、エンタープライズ Salesforce 環境の現実は多くの場合、より微妙な違いがあります。成熟した組織では、同じ Salesforce オブジェクトで動作するレコードトリガーフローと Apex トリガーを見つけるのが一般的です。このシナリオは、前に説明したハイブリッド パターンとは異なります。ここでは、フローと Apex トリガーが結合されておらず、連携するように設計されていません。 この共存は、多くの場合、プラットフォーム機能の進化や従来の技術的負債が原因です。これは許容される運用状態ですが、アーキテクトは最終状態ではなく計算されたトレードオフとして処理する必要があります。 オーケストレーションが断片化することで、ガバナンスとメンテナンスのオーバーヘッドが大きくなり、開発、テスト、インシデント処理の作業がバラバラになり、煩雑になります。これにより、解決までの時間 (TTR) が増加し、運用が複雑になります。 - 新しい Salesforce オブジェクトの場合、主要なガイドとして自動化密度の原則に従います。 - ハイブリッド フットプリント、デュアルApexトリガー、レコード トリガー フローのエントリー ポイントを使用する既存のSalesforceオブジェクトの場合、密度を評価し、メンテナンス可能なハイブリッド状態にリファクタリングするように設計します。 - 低密度の場合は、Apexトリガーをレコード トリガー フローにリファクタリングし、実行順序を指定して、1つの自動化エントリ ポイントに取り込みます。 - 中密度の場合、適切な実行順序で複雑なメガフローをフローのサブセットにリファクタリングします。Apexトリガーは、コンテキストの復元後のサポートなど、どうしても必要な場合にのみ導入してください。 - 高密度の場合は、Apexトリガーの実装をお勧めします。 ### Apex トリガーでのメタデータフレームワークの使用 Salesforce Platform での組織のビジネスプロセスが成熟するにつれて、レコードトリガー自動化の量と複雑さは必然的に増加します。基本的なベストプラクティスは、_ApexトリガーをSalesforceオブジェクト_ごとに1つ管理することです。プラットフォームでは、同じイベントに対して同じオブジェクトに対する複数のトリガーの実行順序が保証されないため、このルールは非常に重要です。この制限により、動作が不安定になったり、競合状態になったり、デバッグが困難になったりする可能性があります。 ただし、_ワン トリガー_の原則に従うと、アーキテクチャ上の課題が生じます。つまり、その1つのエントリー ポイントから呼び出されるすべてのビジネス ロジックを、メンテナンス可能で拡張可能な方法で管理およびオーケストレーションする方法です。 #### Classic トリガーハンドラーの制限 このアーキテクチャの最初の進化は Classic トリガーハンドラーパターンでした。この方法では、1 つの Apex トリガーですべてのロジックが対応するハンドラ クラス（`OpportunityTriggerHandler` など）に委任されます。このメソッドにより、ロジックがトリガーファイルから分離され、開発者はハンドラクラスのメソッド (`afterInsert()` など) 内の実行順序を決定的に制御できます。 このパターンは改善されていますが、多くの場合、ハンドラークラスがモノリシックになります。ビジネス要件が追加されるにつれ、クラスは大規模になり、管理が難しくなり、単独でテストすることも困難になります。すべての個々のプロセスの実行順序が 1 つのメソッド内でハードコードされるため、クラスがマージの競合を起こしやすく、大規模なエンタープライズ環境でのガバナンスとメンテナンスのオーバーヘッドが大幅に増加します。 #### 解決策:メタデータ駆動型トリガーフレームワーク モジュール性とオーケストレーションのコア問題を解決するために、アーキテクトは**メタデータ駆動型トリガー フレームワーク**に移行します。これは、自動化ロジック自体を実行_方法_と実行_タイミング_の設定から分離する、アーキテクチャ上の重要な飛躍です。 このフレームワークは、次の 3 つの主要な利点に基づいて構築されています。 - **パーティショニング:**1 つのハンドラ クラスではなく、コア ビジネス ロジックは小さな原子 Apex クラス（`RecalculateAccountValues` クラスや `NotifySalesLeads` クラスなど）に分割され、各クラスは_単一責任原則_に従います。このモジュール化により、ロジックをテスト、デバッグ、および理解しやすくなっています。 - **順序と振付:**実行順序が Apex でハードコードされなくなりました。代わりに、通常はカスタムメタデータ型 (`TriggerAction__mdt` など) に保存されている設定レコードによって宣言的に定義されます。これにより、管理者はリリースやコードの変更を必要としないメタデータレコードを変更するだけで、自動化アクションの並び替え、追加、削除ができます。 - **バイパス機能：**このフレームワークでは、標準化された詳細なバイパス機能が提供されます。各自動化アクションは、そのメタデータレコードを使用してグローバルに無効にするか、カスタム権限を参照して特定の管理ユーザーに対してスキップするように設定できます。 オブジェクトの単一の Apex トリガーは、動的ディスパッチャーとしてのみ機能します。ビジネスロジックが含まれておらず、代わりに中央`MetadataTriggerHandler`クラスがインスタンス化されます。このハンドラは、カスタムメタデータレコードを照会して実行順序を動的に決定し、指定された順序で正しいアトミック Apex クラスを呼び出します。自動化は、1 つの透過的で管理可能なレイヤーで統合されます。 ### トランザクションでの高価な操作の重複排除 堅牢なフレームワークでApexを使用する重要なメリットは、トランザクションの状態を管理でき、重複作業を排除してパフォーマンスを最適化できることです。ロジックが蓄積されると、保存順序内のさまざまな自動化が同じコストのかかる操作を個別に実行し、貴重なガバナ制限を消費して DML 操作時間が増加することがよくあります。 このフレームワークは、次の 2 つの主要な戦略でこれに対処するように設計されています。 - **共有状態管理：**1つのApexトランザクションの範囲内で、静的プロパティと変数を使用してデータをキャッシュします。これにより、設定の`SOQL`クエリなどの高価な操作は、トリガーの異なるレコードまたはフェーズで自動化ロジックが複数回呼び出された場合でも、1 回のみ実行されます。トランザクション制限の消費が大幅に削減されます。 - **プラットフォーム・キャッシュ使用率：**単純なトランザクション内キャッシュを超えるには、プラットフォームキャッシュを使用して、データベース全体で特定のデータを照会しないようにします。この管理対象のメモリ内キャッシュは、非プリミティブで、コードベース全体で頻繁に参照され、トランザクション全体 (プロファイル、ロール、営業時間など) で不変のデータを取得する場合に最適です。`Cache.CacheBuilder` インターフェイスを使用して、システムは最初にキャッシュを確認し、データが存在しない場合にのみデータベースクエリを実行するため、パフォーマンスと拡張性が最大限に高まります。 ### 同じレコードの更新で保存前を使用 オートメーションでトランザクションを開始するレコードの項目値のみを変更する必要がある場合は、必ず保存前更新を使用してください。これは、フローの高速項目自動更新 (保存前に実行) と Apex トリガーのコンテキスト前ロジック (挿入前、更新前) の両方に適用されます。 このパターンは、2 回目の DML 操作と再帰的な保存サイクルが回避されるため、どのツールを使用してもパフォーマンスは優れています。変更は、データベースにコミット_される前_にメモリ内のレコードに対して行われ、元のトランザクションの一部として保存されます。保存順序全体を再実行し、すべての自動化を再度実行する 2 回目の保存のオーバーヘッドが排除されます。 ### 非制御の再帰の防止 非制御再帰は、更新後のトリガーでよく発生する落とし穴で、トリガーのロジックによって DML 更新が実行され、同じトリガーが再度起動されます。これにより、ガバナ制限例外で終了する無限ループが作成されます。これまで、静的 Boolean フラグや処理済みレコード ID のコレクションは、このような再帰を防ぐために使用されてきましたが、より正確で堅牢なパターンは、レコード自体の新しいバージョンと古いバージョン間で項目値を比較してロジックをゲートすることです。 ロジックは、関心のある特定の項目が実際に変更された場合にのみ実行します。これにより、重要なデータが変更されない同じトランザクション内の後続の DML 操作でトリガーのロジックが実行されなくなります。 #### レコードトリガーフローでの再帰の制御 レコードトリガーフローでは、条件の要件を満たすようにレコードが更新されたときにのみ実行されるようにフローを設定することで、非制御の再帰を防止します。 レコードトリガーフローでの再帰の制御 フローで入力条件数式を使用する場合、`$Record` グローバル変数 (新しい値を表す) と `$RecordPrior` グローバル変数 (保存前の元の値を表す) を比較することで、暴走を回避できます。たとえば、商談の \[金額] 項目が変更された場合にのみフローが実行されるようにするには、次のように入力条件で使用します。 ``` $Record.Amount != $Record__Prior.Amount ``` #### Apex での再帰の制御 新しいバージョンのレコード `Trigger.new` の項目値と古いバージョンのレコード `Trigger.oldMap` の項目値を比較し、探している特定の変更が行われているかどうかを確認します。このアプローチにより、自動化が即効性を発揮し、必要な場合にのみ実行されるため、システムの効率が向上し、破滅的な再帰ループを回避できます。 ### 自動化のスキップ 適切に設計された Salesforce 組織では、自動化をスキップするための一貫した信頼性の高いメカニズムが必要です。これは省略可能な機能ではなく、データの整合性を維持し、管理タスクを有効にするためのコア業務要件です。 次のようなシナリオでは、バイパスフレームワークが不可欠です。 - 大量のデータを読み込む場合、レコードごとにトリガーをトリガーすると、プロセスが大幅に遅くなり、制限例外が発生し、誤った関連レコードと通知が作成される可能性があります。バイパスを使用すると、データをクリーンかつ効率的に挿入できます。 - インテグレーションユーザーは、外部の記録システムからデータを同期する必要がある場合があります。ユーザーが開始した変更 (メールの送信、ToDo の作成など) で通常起動される自動化は、変更が別のシステムから行われた場合に望ましくない場合や冗長になる場合があります。 - システム管理者またはサポートスタッフは、レコードの修正更新を実行する必要がある場合があります。バイパスメカニズムを使用すると、意図しない結果になる可能性がある標準のビジネス自動化をトリガーせずにこれらの変更を行うことができます。 **カスタム権限**:バイパスロジックを実装するための最新のスケーラブルな標準はカスタム権限です。これらは、いくつかの理由で古い方法よりも優れています。 - **柔軟性:**カスタム権限は、権限セットを使用してユーザーに割り当てることができます。この手法は、最新の Salesforce セキュリティおよびアクセスモデルに準拠しているため、きめ細かく柔軟な割り当てが可能です。バイパスは特定のユーザーに付与することも、特定の有効期限で一時的に付与することもできます。 - **メンテナンス性:**カスタム権限を使用すると、プロファイルやユーザーを自動化ロジックにハードコードすることを回避できます。ユーザーのロールが変更されたり、新しいプロファイルにアクセスをバイパスする必要がある場合、変更は単純な権限セットの割り当てであり、リリースを必要とするコードやフローの変更ではありません。 - **拡張性:**カスタム権限は、複雑なユーザーベース全体で例外を管理するためのスケーラブルなフレームワークを提供します。権限セット、権限セットグループ、またはプロファイルを使用してユーザーに割り当てることができます。権限セットまたはプロファイルへの関連付けもソースメタデータで表現できます。 **実装パターン**:一貫したバイパスパターンを組織内のすべてのレコードトリガー自動化に適用します。 **レコードトリガーフローのバイパス**:フローを迂回する最も効率的な方法は、フローがまったく実行されないようにすることです。これは、フローのエントリ条件に条件を追加することで実現されます。 - レコードトリガーフローの開始要素で、\[条件の要件] を \[数式の評価を True に設定] に設定します。 - 数式ビルダーで、`$Permission` グローバル変数を使用してカスタム権限のチェックを組み込みます。チェックを既存のエントリ条件と組み合わせます。 - 数式パターン: ``` ( ) && NOT($Permission.Bypass_This_Flow) ``` - このパターンにより、指定されたカスタム権限がユーザーに割り当てられ_ていない_場合にのみフローが実行されます。このチェックは、フローインタビューが作成される前に実行されるため、最もパフォーマンスの高い方法です。 **Apex トリガーフレームワークのバイパス**:Apexで、バイパス・ロジックをメタデータ駆動型トリガー・フレームワークに直接統合し、詳細な制御を可能にします。 - `TriggerAction__mdt` カスタムメタデータ型には、`BypassPermission__c` などのテキストフィールドを含める必要があります。 - `MetadataTriggerHandler` クラスでは、アクションを動的に実行する前に、コードがこの項目の値を読み取る必要があります。 - フィールドに値が入力されている場合、ハンドラは `FeatureManagement.checkPermission()` メソッドを使用して、現在の実行ユーザーに指定したカスタム権限があるかどうかを判断します。 - `checkPermission()` が true を返すと、ハンドラはその特定のアクションをスキップし、シーケンスの次のアクションに進みます。 - このパターンは、グローバルバイパス (すべての`TriggerAction__mdt`レコードが同じ権限を参照している場合) とアクションごとの詳細なバイパス (異なるレコードが異なる権限を参照している場合、または一部のレコードにまったくバイパス権限がない場合) の両方を可能にするため、強力です。 ### メガフローと複数のフロー これは、オブジェクトのすべての自動化を 1 つの巨大なフローに統合するためのアンチパターンです。ロジックを複数の適切な条件のフローに分割するよりも 1 つのフローに統合する方がパフォーマンスに大きな影響を与えません。パフォーマンスの最も重要な向上は、次の点にあります。 - 同じレコードの項目自動更新の保存前フローの使用。 - 特定の使用事例に影響しない変更に対してフローの実行が除外されるように、正確なエントリ条件を記述します。 [フロートリガーエクスプローラー](https://trailhead.salesforce.com/content/learn/modules/record-triggered-flows/meet-flow-trigger-explorer)では、オブジェクトの各フローに順序値を割り当てて、順次実行順序を保証できます。 Flow Trigger Explorer ## リソース
Apex フロー 業務