# architect 決定ガイド (decision-guides) - Full Documentation # Data 360 の相互運用性 多くの場合、企業はSalesforceやその他の外部データ レイク(_Snowflake_、_Google BigQuery_、_Databricks_、_Redshift_、_Amazon S3_などのオブジェクト ストレージ)にデータを保存します。複数のシステムでデータをサイロ化すると、AI 主導のエクスペリエンスを強化するためにデータの価値を最大限に活用したいと考えている企業にとって課題が生じます。Salesforce _Data 360_は、すべてのAgentforce AIエージェントが適切なコンテキストに適切なタイミングでアクセスするために使用する基本的なインテリジェンス レイヤーです。 複数のデータレーク間でデータをまとめる作業をしているアーキテクトは、そのデータを統合する最適な方法に関する主要なアーキテクチャ上の意思決定に直面します。_Data 360_ には、データ統合のための複数のオプションがあり、それぞれにさまざまな長所と短所があります。 ## ガイドの概要 このガイドでは、データ統合時の遅延、コスト、拡張性、ガバナンス、複雑さの要件にどのパターンが最適かを評価するフレームワークを提供し、データ取り込み、ゼロコピーデータ統合、またはハイブリッドアプローチを使用するタイミングを選択するのに役立ちます。また、このガイドは、さまざまなニーズに対応するさまざまなデータ取り込み方法とデータ統合方法の選択にも役立ちます。 外部データ レイク ハウスを_Data 360_と統合するには、データの新鮮さ、ガバナンス、パイプラインの効率性のトレードオフを慎重に検討する必要があります。たとえば、ゼロコピーデータ統合ライブクエリを使用すると、データの新鮮度が最大限に高まりますが、ネットワークを介して移動するデータが増えるとパイプラインの効率が低下する可能性があります。ほとんどの実際の実装では、マルチクラウド レイクハウス エコシステムで取り込みと統合を組み合わせることが最適な方法です。このハイブリッド アプローチにより、低レイテンシの運用ワークロード(リアルタイムのパーソナライズや不正行為の検出など)と分析ワークロード(規制レポートや履歴トレンド分析など)をサポートする、拡張性が高く、管理された相互運用性のあるアーキテクチャが実現します。このガイドは、適切な戦略を使用してこれらのトレードオフを解決する方法を判断するのに役立ちます。 ## 重要ポイント - **データ取り込み**では、データが Salesforce _Data 360_ にコピーされ、管理された正規データモデルが作成されます。これは、次のような場合に最適です。 - 包括的な**Customer 360を構築**します。 これにより、さまざまなソースを統合し、信頼できる1つのプロファイルに変換できます。 - **厳格な規制コンプライアンスに対応できます。**これにより、監査可能な一元化されたコピーを作成して、データアクセスと系統を厳密に制御できます。 - **ゼロコピー統合**は、重複なしで外部ソースをリアルタイムに照会し、リアルタイムのパーソナライズ、ライブ ダッシュボード、迅速なソース オンボーディングを可能にします。このアプローチには2つの主なオプションがありますが、バランスを取る必要があるトレードオフがあります。 - **ライブ クエリ:**外部データ プラットフォーム(_Snowflake_、_BigQuery_、_Redshift_、_Databricks_など)に存在する対話型分析とリアルタイム データ ダッシュボードに使用します。これにより、クエリ処理をソースシステムに転送し、必要な結果のみを返すことで、低速でコストのかかるデータの重複を回避できます。このアプローチは、新鮮さが重要な頻度の低いクエリやアドホッククエリに最適化されています。低い_QPS(クエリ/秒_)ワークロードに適しています(QPSが高いとクエリ コストが大幅に上昇する可能性があります)。 - **キャッシング（高速化クエリ）:** 頻繁に変更されないデータクエリに使用します。高速化されたクエリでは、設定可能な間隔 (15 分～ 7 日) で更新されるローカルキャッシュが維持されるため、ソースヒットの繰り返しが減少します。この方法では、ダッシュボードのパフォーマンスとコスト、セグメント化、BIワークロードのバランスを取ります（若干古い結果が許容される場合）。これは秒未満の意思決定には適していません。 - **ファイルフェデレーション:**クラウドのデータ レイク(_S3_や_ADLS_など)の大規模なバッチ処理とAIモデルのトレーニングに使用します。このアプローチでは、ファイルをオープンテーブル形式で直接照会することで、大量の ETL データセットとデータサイエンスのワークロードを解放し、低速でコストのかかる取り込みを回避します。 - **ハイブリッド モデルでは**、_統合プロファイル_の取り込みと、オムニチャネル エンゲージメント、Agentforce駆動型アクション、AI/MLトレーニングをサポートする新鮮さのための統合がブレンドされます。 ### 重要な考慮事項 - **ハイブリッドアーキテクチャを採用する。**多くの場合、データの取り込みと統合を組み合わせる必要があります。 - _データ取り込み_は、正規データモデルとコアガバナンスのための重要なデータに使用します。 - 他のすべてのデータ統合で_ゼロ コピーを_使用して、新鮮さを維持し、データ取り込みパイプラインの構築と管理に伴う運用オーバーヘッドを最小限に抑えます。 - **Data Ingestion Frequency Matters (データ取り込み頻度が重要)。**ビジネス価値、遅延のニーズ、運用の複雑さに基づいて頻度を選択します。 - 時間的制約のあるワークフロー(パーソナライズ、ライブ ダッシュボード、Agentforceアクションなど)に_リアルタイムを_使用します。 - 緊急度が中程度のプロセス (キャンペーンや運用レポートなど) には_ほぼリアルタイム_を使用します。 - 履歴データセットまたは低速データセットにはバッチを使用します。 - **統合パターンを遅延とパフォーマンスに合わせます。**新鮮さ、パフォーマンス、コストに対するアクセスパターンと要件に最も適したオプションを選択します。 - _ライブ クエリ_は、低レイテンシが重要となる運用ダッシュボードやリアルタイムのパーソナライズに使用します。 - クエリが頻繁に実行され、若干古い結果が許容される場合に_キャッシュ (クエリ_の高速化) を使用すると、パフォーマンスとコストのバランスを取ることができます。 - _ファイルフェデレーション_は、スループット負荷の高い大規模な分析またはバッチ ワークロードに使用します。これは、履歴データまたは時間的制約の少ないデータセットに最適です。 - **ガバナンスをデータレジデンシー要件と整合させましょう。** - 一元化されたガバナンスが重要な場合は、_データ取り込み_を使用します。 - 分散ガバナンスが許容される場合_は統合_を使用し、外部ソースでは厳格なガバナンスを適用します。 - ソースレベルのポリシー (_行レベルセキュリティ (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 ライブクエリ：
  • 外部システムに対する直接クエリと、データの重複のないスキーマオンリードを提供します。
  • 最大限の新鮮さを提供します。
  • 最小限のストレージオーバーヘッドを実現します。
  • リアルタイムの運用インサイトをサポート
  • ソースのパフォーマンスに依存します。
  • クエリ量が多いと遅延に影響する可能性がある
  • I/O を最小限に抑える述語プッシュダウンおよび集計を使用するクエリに適しています。
  • 大量のデータセットで絞り込まれていないクエリを使用しない
 Agentforce:
  • ライブ活動に適応する動的ワークフロー
アナリティクス:
  • 運用ダッシュボードとライブレポート
コンプライアンス：
  • ソースにおける行レベルセキュリティおよびマスキングを遵守します。
高速化されたクエリ (キャッシング):
  • 15 分～ 7 日間の範囲で設定可能な統合クエリのキャッシュされたローカルコピーを提供します。
  • 最適化されたクエリ実行を提供します。
  • 遅延を削減
  • 反復的なライブクエリよりもコストが低いです。
  • 頻繁なアクセスパターンのパフォーマンスを向上
  • キャッシュ管理が必要
  • キャッシュの陳腐化はキャッシュ間隔によって異なります。
  • 頻度の高いクエリに適しています。
  • 秒未満の判断には適していません。
  • インクリメンタルな更新では、更新/挿入のみがサポートされます。削除されたレコードはキャッシュから削除されません。
  • キャッシュをソースと同期させるために、定期的にフル更新を手動で行う必要がある
 Agentforce:
  • 迅速な意思決定のための事前集計されたエンゲージメントメトリクス
アナリティクス:
  • BI ダッシュボード、セグメンテーション、分析レポート
コンプライアンス：
  • 監査ログを使用して一貫して規制されたダッシュボード
ファイル統合：
  • オブジェクト ストアまたはレイク内の大規模な履歴データセット(S3、Iceberg、Google BigQuery、Redshiftなど)に直接アクセスできます。
  • 大規模なデータセットを処理する
  • Data 360 で必要なストレージは最小限
  • AI/MLワークロードをサポート
  • 参照のみ
  • クエリのパフォーマンスは外部システムのスループットによって異なる
  • 一括処理負荷が高く、スループット要件の厳しいジョブに適しています。
  • リアルタイムダッシュボードには適していない
 Agentforce:
  • 一般的ではない (バッチ処理が多い)
アナリティクス:
  • ML/AI トレーニング、履歴分析、ペタバイト規模のレポート
コンプライアンス：
  • 重複のない外部データセットへのアクセスを管理します。
## Data 360 インテグレーションパターン Data 360 には、データ取り込み、ゼロコピーデータ統合、ハイブリッドアプローチの 3 つの主要なインテグレーションパターンがあります。 ### データ取り込み _データ取り込み_では、データがソースに残される_ゼロコピー_とは異なり、データが物理的_にData 360_にコピーされ、完全に管理されます。つまり、変換のコンピューティングは_Data 360_内で実行され、一元的なガバナンスと監査が提供されます。 #### データ取り込みのユースケース _データ取り込みを_使用して、コンプライアンスと業務管理のために正規の管理データセットをSalesforce _Data 360_に保存します。取り込みは、完全な制御、監査、トレーサビリティが必要な場合に使用します。データ取り込みは、一元的なコンピューティングとガバナンスが重要な、規制対象のワークフローや価値の高いワークフローに最適です。 取り込みは、アイデンティティ解決、規制レポート、ミッションクリティカルなAI駆動型ワークフローおよび顧客エンゲージメントのための信頼できる基盤を構築する場合に適しています。 データ取り込み概要 #### データ取り込みメソッド _データ取り込み_方法は、データの取り込みに使用するコネクタによって異なります。さまざまな取り込み方法を提供するコネクタもあれば、バッチモードまたはストリーミングモードでのみ動作するコネクタもあります。_Data 360_ コネクタと使用可能なメソッドの完全なリストについては、「[Data 360: Integrations and Connectors](https://help.salesforce.com/s/articleView?id=data.c360_a_sources_targets.htm&type=5) (Data 360: インテグレーションとコネクタ)」を参照してください。 - **リアルタイム：** - _変更データキャプチャ (CDC)_ を使用して、1秒未満の取り込みを提供します。 - 時間的制約のあるワークフロー (不正行為の検出、パーソナライズ、運用ダッシュボードなど) に適しています。 - _Data 360_内のプッシュ変換と集約により、下流のI/Oを削減し、コンピューティング使用量を最適化 - インクリメンタルなCDCを使用して、データのシャッフルを最小限に抑えることをサポートします。 - **ストリーミング:** - 1～3分ごとに小単位で取り込みます。 - 鮮度とコストのバランスをとります。 - キャンペーンオーケストレーション、ニアライブエンゲージメント、運用レポートに最適 - マイクロバッチを使用した I/O スパイクの制御をサポート - ソースで可能な場合、データを集計して転送量を削減し、ストレージを最適化します。 - **バッチ (スケジュール済み読み込み):** - 大規模なデータセットの定期的な取り込み（例：毎時、毎日、毎週など）を提供します。 - 履歴データセット、規制レポート、コンプライアンスの使用事例のコスト効率と信頼性を向上 - コンピューティングのローカル性をソースストレージと同じ領域に確保して、パフォーマンスを向上させ、コストを最適化 #### Architect Playbook (アーキテクトプレイブック) - **データ取り込みのユースケース:** - **Customer 360 統合プロファイルの生成。**顧客のIDおよび属性に関する唯一の信頼できる情報源を構築します。 - **規制コンプライアンスデータセットを管理します。**機密データに対して、ガバナンス、系統、監査可能性を確保します。 - **キャンペーンオーケストレーションを一元化します。**マーケティング、営業、サービスのすべてが一貫性のある信頼できるデータセットから実行されるようにします。 - **設計プラクティス:** - 履歴データや低レイテンシーが許容されるニーズ（たとえば、アーカイブレポートや定期スナップショットなど）に合わせたバッチ取り込みに対応します。 - CDC またはストリーミング API を使用して、業務ワークフローとパーソナライズワークフローの新鮮さを維持し、ほぼリアルタイムで更新できるようにします。 - データセット全体の再読み込みに代えて、インクリメンタルな読み込みを適用することで、ストレージとコンピューティングの増加を制御し、コストと効率を最適化します。 - 取り込みパイプラインを、コンピューティングのローカリティおよびインクリメンタルな処理に合わせることで、ネットワークI/Oを削減します。 - _Data 360_ 内で変換を適用して、未加工データを不必要に移動しないようにします。 - **コストに関する考慮事項:** - **リアルタイム取り込み**は、コンピューティングとパイプラインのコストが最も高く、価値が高く、時間的制約のあるワークフロー(パーソナライズ、運用ダッシュボード、Agentforce駆動型アクションなど)では妥当な可能性があります。 - **ストリーミング取り込み**には中程度のコンピューティングコストとストレージコストがかかるため、わずかな遅延を許容できる頻繁な更新 (キャンペーンオーケストレーションや運用レポートなど) に適しています。 - **バッチ取り込み**は、コンピューティング コストが低く、予測可能なストレージであるため、履歴データセットや頻度の低い更新に適しています。特定のコネクタを使用して Salesforce 組織から一括処理データを取り込むことは無料です。 - **更新モード**では、取り込みとコンピューティングの合計コストを削減する_インクリメンタルなリフレッシュ_モードを選択できます。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 のユースケース _ゼロ コピー_を使用して、データの重複のない外部システムのリアルタイム クエリを実行し、大規模データセットまたは一時的なデータセットへの俊敏性、最新性、拡張性の高いアクセスを実現します。ライブ ダッシュボード、探索的分析、AI/MLモデルのトレーニング、Salesforce _Data 360_を介したリアルタイムの顧客エンゲージメントに適しています。 ゼロ コピー データ統合の概要 #### ゼロコピーメソッド _ゼロ コピーを_使用する場合、アーキテクトは使用可能な3つのデータ統合方法のいずれかを選択する必要があります。それぞれに、新鮮さ、パフォーマンス、コストのトレードオフがあります。 - **ライブクエリ** - 外部システム(_Snowflake_、_Google BigQuery_、_Redshift_、_Databricks_など)に対してデータの重複なしで直接クエリを実行します。 - ネットワーク上のデータ移動を最小限に抑え、Salesforce _Data 360_の計算におけるI/Oを削減します。述語や集計をプッシュダウンできる場合に最適です。 - リアルタイムのインサイトと低レイテンシの運用ダッシュボードに適しています。 - 外部システムのパフォーマンスによって異なります。 - **キャッシング (高速化されたクエリ)** - 統合データのキャッシュされたコピーを Salesforce _Data 360_ に一時的に保存します。 - 期間 (分～日) を設定可能で、頻繁にアクセスされるデータセットの反復クエリコストと遅延を削減します。 - データは完全にはコピーされないため、更新はソースからのスケジュールされた更新で管理されます。 - _インクリメンタルなリフレッシュ_は、アップサートのみをサポートします。削除したレコードはキャッシュから削除されません。 - 定期的にフル更新を実行して、キャッシュがソースと同期されていることを確認します。 - **注：** _Snowflake_ コネクタでは、Snowflake が開始するステージングバケットを使用して加速率を高める_アンロード_機能がサポートされています。これはデフォルトで有効になっていますが、接続を編集することで無効にできます。 - **ファイル統合** - オブジェクト ストアの大規模なデータセット(_Iceberg_を使用する_S3_や_GCS_など)への参照のみの直接アクセスを提供します。 - データを移動することなく、AI/ML ワークロード、履歴分析、ペタバイト規模のレポートに適しています。 - クエリのパフォーマンスは、オブジェクト形式、パーティショニング、ネットワーク I/O に大きく依存します。大規模なスキャンでは、最適化されていない場合、大量の I/O が生成される可能性があります。 #### アーキテクトプレイブック - **使用事例** - **リアルタイムのパーソナライズ**と適応型ワークフローにより、顧客の行動の変化に応じて動的な提案、おすすめ、Next Best Actionが提供されます。 - **ライブ ダッシュボードと運用分析**により、ビジネス クリティカルなダッシュボードとKPIを外部倉庫から直接利用できます。 - 大規模な外部データセットを使用する**AI/MLモデル**のトレーニングでは、ファイルフェデレーションを介して移動することなく、データレークやウェアハウスからペタバイト規模のデータを活用します。 - **業種シナリオ** - **小売/メディア:** クリックストリームまたはコンテンツインタラクションデータを統合することで、パーソナライズされたおすすめとリアルタイムの顧客エンゲージメントを実現します。 - **財務:**機密データを重複させることなく外部倉庫を照会することで、不正行為の検出とリスク スコアリングをほぼリアルタイムで実行します。 - **Tech/Enterprise:** データセットが複数のシステムに存在する場合に、クロスクラウドレポート、ITサービスダッシュボード、運用分析をサポートします。 - **デザインプラクティス** - **ライブクエリ** - 新鮮度が重要な場合に、高QPSで低レイテンシのクエリに使用します。 - 述語と集計を外部システムに転送して、ネットワーク上のデータの入れ替えを減らします。 - 大量のデータを不必要にスキャンするクエリは避けてください。 - 代わりにパーティションのプルーニングとフィルターを検討してください。 - **ファイル統合** - 取り込みなしでオブジェクトストアのペタバイト規模のデータセットにアクセスできます。 - オブジェクトストレージを Salesforce の計算と同じクラウド領域に保持することで、遅延と出力コストを最小限に抑えます。 - パーティション分割された列形式 (Parquet/ORC) とプッシュダウン検索条件を使用して、I/O とネットワーク転送を削減します。 - クエリと述語のプッシュダウンを活用して、ソースでデータを絞り込んで集計することで、データの移動を減らします。 - I/O、遅延、コストが増加するため、リージョン間データアクセスは、絶対に必要でない限り避けてください。 - **キャッシング (高速化されたクエリ)** - コストとパフォーマンスのバランスを取るために、頻繁にアクセスするデータセットをキャッシングします。 - 更新間隔を設定して、新鮮度とクエリコストのバランスを取ります。 - **コンプライアンス:**統合システム内で_RLS(行レベルセキュリティ)_とマスキングポリシーを直接活用して、ソースでガバナンスを適用します。 - プラットフォーム間で統一された RLS とマスキングを行うためのベストプラクティスを次に示します。 - **一元化されたエンタープライズ ID を使用します。**Salesforce _Data 360_ のユーザーとエンティティを、外部システムの ID に対応する一意の一元化されたエンタープライズ識別子に対応付けます。 - **セキュリティポリシーを調整します。**対応付けられた ID に基づいて、統合システムの RLS およびマスキングポリシーが適用されるようにします。これにより、外部データを照会するときのコンプライアンスが保持されます。 - **ID スキーマの標準化。**不一致やアクセス違反を回避するために、すべてのデータソースで一貫した ID 属性 (メール、ユーザー ID、顧客 ID など) を維持します。 - **コストに関する考慮事項** - **ライブクエリ:** クエリあたりの支払モデルでは、外部レイクハウスの計算でコストが発生するため、QPS が高いスパイクが発生する可能性があります。これは、コストの変動よりもその価値が大きい、新鮮さを重視するユースケースに適しています。 - **Accelerated Query (Caching):** この方法では、ソースシステムへのヒットを減らすことでクエリコストを (_ライブクエリ_と比較して) 削減できますが、キャッシュへの入力と更新のためのバッチデータの取り込みコストは増加します。これは、頻繁にアクセスされるデータセットに適しています。 - **ファイルフェデレーション:**これは、オブジェクトストアのデータとして最も安価なストレージオプションです。ただし、クエリコストは、ファイルサイズ、パーティション分割、およびプルーニングによって異なります。これは、ペタバイト規模の履歴データや一括データに適しています。 #### ゼロコピー方法の決定条件 | 決定ポイント | ライブクエリ | キャッシング (高速化されたクエリ) | ファイルフェデレーション | | :----------------------- | :---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **データソースの場所** | 外部データ レイク ハウス(_Snowflake_、_Google BigQuery_、_Redshift_、_Databricks_など) | 外部データ レイク ハウス(_Snowflake_、_Google BigQuery_、_Redshift_、_Databricks_など) | オブジェクト ストアまたはクラウド データ レイク(_S3_、_ADLS_、_GCS_など)。_Iceberg_のようなオープン テーブル形式がよく使用されます。 | | **目的/使用事例** | 対話型の分析やリアルタイムダッシュボードに適しています。リアルタイムのパーソナライズと動的なワークフローに適しています。 | クエリが頻繁に発生するが、若干古い結果が許容される場合に適しています。BI ダッシュボードおよびセグメンテーションに適しています。 | 大規模なバッチ処理や AI/ML モデルのトレーニングに適しています。履歴分析やペタバイト規模のレポートに適しています。 | | **鮮度/レイテンシ** | 最大限の新鮮さを提供 リアルタイムでクエリを直接実行します。効果的な述語プッシュダウンを用いてソースシステムが低レイテンシクエリ用に最適化されている場合、1秒未満の意思決定をサポートします。 | 若干古い結果が許容される場合に使用します。新鮮度は、15 分～ 7 日間の範囲で設定できるキャッシュ間隔によって異なります。 | バッチ負荷が高く、スループット要件の厳しいジョブに適しています。リアルタイムダッシュボードには適していません。 | | **アクセスパターン** | 新鮮さが重要でクエリ量が少ない頻度の低いクエリやアドホッククエリに適しています。QPS が高いとコストが大幅に上昇するため、クエリ頻度が高いときにキャッシュ (Accelerated Query) を評価することが重要です。 | 高頻度の読み取りシナリオに適しています。頻繁なアクセスパターンのパフォーマンスが向上します。 | 読み*取り専用アクセス*を提供します。取り込みのないペタバイト規模のデータセットに適しています。 | | **パフォーマンスの促進要因** | 外部システムのパフォーマンスに大きく依存します。述語と集計をソース側にプッシュダウンできる場合に適しています。 | 繰り返されるライブクエリと比較して遅延が短縮されます。パフォーマンスは、キャッシュ管理と間隔によって異なります。 | パフォーマンスは、オブジェクト形式、パーティショニング、外部システムのスループットに大きく依存します。パーティション分割された列形式 (Parquet/ORC) を使用します。 | | **コストへの影響** | これはクエリごとの支払モデルであるため、外部レイクハウスの計算でコストが発生します。頻繁ではないクエリではコスト効率が高くなりますが、QPS 量が多いと経費が急増する可能性があります。 | コストは、繰り返されるライブクエリよりも低くなります。これにより、外部ソースを繰り返し照会する必要がなくなりますが、キャッシュストレージと更新オーバーヘッドが追加されます。 | これは最も安価なストレージオプションです。同じリージョン、同じクラウドのAWS設定の場合(US-East-1に_Data Cloud_テナントがあるUS-East-1の_S3_など)、アクセスされる行でクレジットは消費されません。クロス リージョンまたはクロス クラウド構成(_Azure_、_GCS_、異なる_AWS_リージョンなど)では、アクセスされる行のクレジット消費が発生します。クエリコストは、ファイルサイズ、パーティショニング、述語プッシュダウンの最適化によっても異なります。 | | **主な考慮事項** | 大量のデータを不必要にスキャンする絞り込まれていないクエリは避けてください。 | この方法では、キャッシュ管理が必要です。1秒未満の意思決定には適していません。 | クエリのパフォーマンスは、パーティショニングと述語プッシュダウンによる最適化に大きく依存します。 | ### ハイブリッドアプローチ ハイブリッド アーキテクチャにより、アーキテクトは重要なデータセットを _Data 360_ に固定して一元化されたガバナンスを実現すると同時に、統合クエリを活用して、最新性、重複の削減、大規模な外部データセットへのスケーラブルなアクセスを実現できます。このアプローチでは、I/O、計算の局所性、コスト、コンプライアンスの要件のバランスを取ります。 #### ハイブリッドユースケース ハイブリッドアプローチを使用して、データの取り込みとゼロコピーを組み合わせることで、バランスの取れたガバナンス、新鮮さ、運用効率を実現し、リアルタイムでアクション可能なインサイトを提供します。トレーサビリティ、RLS、マスキングが必要な価値の高い規制対象のデータセットには取り込みを使用し、新鮮さとパフォーマンスが重要な一時的または大量のデータセットには統合を使用します。 ハイブリッド アプローチの概要 #### アーキテクトプレイブック - **使用事例** - **オムニチャネルエンゲージメント:** 顧客の履歴データとリアルタイムの行動を組み合わせて、一貫性のあるコンテキスト対応環境を提供します。 - **AI/MLパイプライン:**厳選された正規データセットに基づいてモデルをトレーニングしながら、外部ソースからの未加工またはリアルタイムのシグナルで強化します。 - コンプライアンスと俊敏性の**混在ニーズ:** 機密データには厳格なガバナンスを適用し、運用の俊敏性には統合を適用します。 - **業種シナリオ** - **リテール:** ID解決とプロファイル統合には_取り込み_を使用し、リアルタイムのオファーとパーソナライズには_federation_を使用します。 - **医療:**IoTデバイス ストリームとセンサー データ_の統合を_使用して即時のコンテキストを確保しながら、_取り込み_によってゴールデン 患者レコードを維持します。 - **金融サービス:**外部の不正検出およびリスク モニタリング クエリに_統合_を使用しながら、規制対象のデータをコンプライアンス管理対象のレイクに取り込みます。 - **設計手法** - 取り込みによる**アンカーガバナンス:** 価値の高いデータや規制対象のデータを正規モデルに取り込み、Trustとコンプライアンスを確保します。 - **Use Federation for Freshness:**外部レイク ハウスが重複のないリアルタイムまたは大規模なデータ アクセスを提供できるようにします。 - **コストとパフォーマンス**のバランス: ワークロードをプロファイルして、_取り込み_と_統合_のどちらを使用するかを決定します。これにより、不要なストレージとクエリのコストを最小限に抑えます。 - **階層型ガバナンスの適用:**統合システムのセキュリティ制御(RLSやマスキングなど)を活用しながら、取り込まれたデータの一元的なガバナンスを適用します。 - **注:**ハイブリッド パイプラインを設計する場合、履歴データセットの増分取り込みを確保し、統合ソースに集計またはフィルターを転送してI/Oとコンピューティングの使用量を最適化することが重要です。 - **コストの考慮事項** - コンプライアンスや重要なデータの_取り込み_と、新鮮さが必要な場合の_統合_を組み合わせて、総コストとパフォーマンスを比較します。 - _取り込み_と統合を混在させる場合、I/Oと_コンピューティング_の配分を考慮します。ソースシステムに対するクエリの繰り返しによる計算コストを削減するには、読み取り頻度が高く、頻繁にアクセスされる統合データセットのキャッシュ (Accelerated Query) を使用します。 - このルールを使用して、取り込みと統合に関する意思決定をガイドします。データへのアクセス頻度は高くても、変更頻度が低い場合、_Accelerated Query_のコスト パフォーマンスは通常高くなります。ただし、データが頻繁に (アクセス頻度に対して) 変更される場合は、_ライブクエリ_または_取り込み_の方が適しています。コストの例をいくつか紹介します。 - **高速化:** 100万件のレコードから作成され、毎日約1万件の変更で更新されるダッシュボードは、1日あたり20回参照されます。_高速化_のコストは、_ライブ クエリ_の場合は約4,200クレジット/月であるのに対して、約600クレジット/月です。 - **ライブ クエリが有利な場合:** 30分ごとに変化するデータを使用して、1日に20回公開されるセグメント。_ライブ クエリの_コストは、この更新頻度では_高速化_に必要な約4,200クレジット/月であるのに対し、約28,800クレジット/月です。 ## 使用事例決定ガイド このロジックを適用する方法を示すいくつかの一般的なアーキタイプを詳しく見てみましょう。 - **「Single Source of Truth」アーキタイプ: 一元化とガバナンス** - **シナリオ:** グローバル企業全体の準拠した統合 _Customer 360_ プロファイルを作成する必要があります。データはさまざまなシステムから取得され、厳格な_GDPR_および_CCPA_規制に準拠する必要があります。また、データはすべてのマーケティングおよびサービスのやりとりの情報源として機能します。 - **推奨パターン:** **データ取り込み。**ここでの優先度は、ガバナンス、Trust、支配です。データを_Data 360_に取り込むことが、ソース システムから分離された、完全に監査可能な正規プロファイルを作成する唯一の方法です。 - **「リアルタイム・インサイト」の原型: 移動せずに分析** - **シナリオ:**データ サイエンス チームは、_Snowflake_で絶えず更新される大量のトランザクション テーブルに対して探索クエリを実行する必要があります。同時に、経営陣は、同じデータを活用したライブ_BI_ダッシュボードを求めています。毎日数ペタバイトのデータを移動すると、時間とコストがかかります。 - **推奨パターン:** **ゼロコピーフェデレーション。**ここで優先されるのは、スピード、アジリティ、および大規模運用時の費用対効果です。_ゼロ コピー_では、既存のデータ ウェアハウスの機能を活用して、データの重複によるオーバーヘッドやレイテンシを発生させることなく、リアルタイムのクエリを実行できます。 - **「ハイブリッド インテリジェンス」のアーキタイプ: コアのガバナンス、エッジのフェデレーション** - **シナリオ:** データレイクからのリアルタイムの行動シグナル (Web サイトのクリックなど) を使用して、管理され、取り込まれた顧客プロファイルを強化したいと考えています。コアプロフィールの安定性が必要ですが、ライブ データの即時性によって、その場でのパーソナライズを実現できます。 - **推奨パターン:****ハイブリッド アプローチ。**_データ取り込み_を使用して、本顧客データの安定した管理されたコアを作成します。_ゼロ コピー_を使用して、揮発性のリアルタイムの「エッジ」データを統合し、クエリ時にそれらを結合して、最新の完全なビューを作成します。 ## 進むべきパス エンタープライズデータ戦略は、もはや 1 つのインテグレーションパターンを選択することに焦点を絞るのではなく、相互運用性のあるデータエコシステム内で制御された柔軟性を構築することに重点を置いています。適切なアプローチでは、各ソースシステムをその新鮮さ、ガバナンス、コスト、アクセス要件に最も適したパターンに対応付けます。 - コンプライアンス、ID解決、運用ワークフローのために、ミッション クリティカルな規制対象のデータセットをSalesforce _Data Cloud_に取り込みます。 - _Zero Copy_を使用してデータを統合することで、ストレージを重複させることなく、ライブ、探索、AI主導の分析を行うことができます。 - クエリ頻度が高く、データ変更頻度が低い場合のソースシステムの負荷とクレジット消費を削減するための_キャッシュ (クエリ_の高速化) の適用 Salesforce _Data 360_ on _Hyperforce_は、複数リージョンの復元性と拡張性を実現します。_Iceberg_テーブルを備えたオープン レイク ハウスにより、コンピューティングの分離と、_Snowflake_、_Databricks_、_S3 Iceberg_などのプラットフォームとの相互運用性を実現し、真に相互運用性のあるマルチクラウド データ エコシステムのバックボーンを形成します。 データエコシステムが進化するにつれ、アーキテクチャのアジリティを維持するために、新鮮さ、コスト、パフォーマンス、コンプライアンスのバランスを継続的に保つ必要があります。そのため、取り込まれた管理データを統合アクセスで統合することで、プラットフォームを将来にわたって使用できることが重要です。これにより、クラウド、地域、ビジネスドメイン全体でリアルタイムインテリジェンス、AI の有効化、エンタープライズ規模のパーソナライズが可能になります。 汎用的なソリューションは、ほとんどのビジネスには適していません。最適な戦略では、適切なパターンを適切なビジネスドライバーにマッピングします。 ## 著者について **Yugandhar Bora**は、Salesforceのソフトウェアエンジニアリングアーキテクトで、データおよびインテリジェンスアプリケーションプラットフォーム内のデータアーキテクチャを専門としています。データ ガバナンスと統合データ モデルに重点を置き、自動化されたプラットフォーム プロビジョニング ソリューションにも貢献するEARB(_Enterprise Architecture Review Board_)イニシアティブを主導しています。 **Jan Fernando**は、Salesforceの_OCA(Office_ of the Chief Architect)のプリンシパル アーキテクトで、2012年にSalesforceに入社しました。スタートアップ エコシステム時代から豊富な経験があります。OCAに入社する前は、_プラットフォーム_組織で10年以上にわたり、いくつかの主要なテクノロジー トランスフォーメーションを率いていました。 # Data 360 プロビジョニング Salesforce Data 360は、[Hyperforce](https://www.salesforce.com/platform/public-cloud-infrastructure/)上に構築されたデータ プラットフォームで、Salesforceと外部データを、すべての顧客またはアカウントの明確で完全、かつ信頼できる全方位的なビューに統合します。 合併や買収、地域の業務、職務の分離、または歴史的な理由により、多くの場合、企業は複数の Salesforce 組織を運営しています。アーキテクトは Data 360 に関するいくつかの決定を行う必要がありますが、これらはすべてガバナンス、コンプライアンス、コスト、レイテンシ、および AI と組織間プラットフォームの機能を拡張する組織の能力に影響します。 ## ガイドの概要 このガイドでは、Data 360 を使用してプロビジョニングに関する意思決定を行うためのフレームワークについて説明します。 - 単一ホーム組織と複数組織構成の選択 - 複数の独立した Data 360 インスタンスのプロビジョニング - Data Cloud One を使用して 1 つのインスタンスで組織を統合する - Data 360 組織間のデータ共有を使用する独立した Data 360 インスタンス間のコラボレーション 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 アクセスを追加する戦略を立てることで、アーキテクチャを将来にわたって保証することが重要です。営業担当、サービス担当、マーケティング、コマース担当、業種、および Agentforce 全体で Salesforce の機能が Data 360 上に構築されることが増えています。これらのプラットフォーム機能を使用する組織は、独自の Data 360 をプロビジョニングするか、共有の Data 360 をコンパニオン組織として接続する必要があります。 このガイドは、アーキテクトがシンプルさ、エンタープライズ全体の一貫性、コンプライアンス、拡張性のバランスを取るプロビジョニング戦略を設計するのに役立ちます。これにより、組織は自信を持って Data 360 を Customer 360、AI、クロスプラットフォームのイノベーションに活用できます。このガイドを使用して、Data 360 が必要な組織と、Data Cloud One を使用するか、Data 360 組織間でデータ共有を使用するかを判断します。この戦略により、Data 360 中心の未来に向けた強固な基盤が確立されます。 ## 範囲内の商品
Salesforce Platform のロゴ Salesforce Data 360 は、任意のソース (CRM、Web、モバイル、外部データレイク) のデータを 1 つのアクション可能な顧客プロファイルにハーモナイズして統合する、Salesforce のリアルタイムのハイパースケールデータプラットフォームです。Customer 360プラットフォームの重要なコンポーネントとして、セールス、サービス、マーケティング全体のAI、分析、パーソナライズされたエクスペリエンスを強化します。
## ポイント - **すべての組織は、Data 360インスタンスへのアクセスを計画する必要があります。**各組織は、Data 360 ホーム組織をホストするか、Data Cloud One を介して接続されたコンパニオン組織である必要があります。 - **組織ごとではなく、企業全体を考慮します。**単独で、事業ごとの意思決定は避けてください。理想的には、エンタープライズアーキテクチャまたはデータガバナンス協議会が、プロビジョニング戦略について共同で決定するべきです。広範な統合データセットに依存する将来の AI およびアナリティクスのニーズを常に予測してください。 - **ガバナンスとオーナーシップ / 所有権を早期に計画します。**Data 360 を一元管理するか (Center of Excellence モデル)、事業部門に委任するかを決定します。システム管理者、セキュリティチーム、コンプライアンスリードの役割を定義します。オーナーシップが不明瞭であると問題が発生する可能性があるため、あいまいさを避けてください。 - **プロビジョニングはライセンスに関連付けられています。**Data 360 ライセンスを購入した組織によって、Data 360 がプロビジョニングされる場所が決まり、その組織の場所によって地域が決まります。 - **データソースのサポートに関する考慮事項を理解します。**さまざまなパブリッククラウドおよびゼロコピーデータソースでサポートされるリージョンに注意してください。また、これらのデータソースへの接続にセキュリティ体制のプライベートコネクトが必要かどうか、および地域内接続と地域間接続のどちらがサポートされるかも判断します。 - **単一組織または複数組織のいずれを使用しているかに基づいてプロビジョニングします。**単一組織の顧客は、既存の本番組織で Data 360 をプロビジョニングして、最短で価値を実現できます。複数組織のユーザーの場合、作成する Data 360 インスタンスの数をできるだけ少なくして複雑さを最小限に抑えます。理想的なのは、Data Cloud One 設定を使用することです。 - **複数の Data 360 インスタンスは、必要な場合にのみ**使用**してください。**複数のインスタンスは、コンプライアンス、レジデンシー、または組織の自律性によって必要とされる場合にのみ使用してください。このような場合は、Data 360 組織間[のデータ共有](https://help.salesforce.com/s/articleView?id=data.c360_a_share_data_between_dc_orgs.htm&type=5)を使用して安全なコラボレーションを実現します。 - **Data 360 組織間のデータ共有は、カスタム ETL パイプラインではなくコラボレーション用に設定します。**データ共有を介して特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。タグは共有されず、消費はソース組織に請求されます。 - **短期的なショートカットは避けてください。**長期計画なしで概念実証（POC）のために複数の Data 360 組織をスピンアップしないでください。パイロットと早期展開を企業全体のプロビジョニング戦略に合わせます。 ## 決定ポイント すべてのプロビジョニングの選択肢（Data Cloud One、Data 360 組織間のデータ共有、またはホーム組織の指定）を、次の横断的な考慮事項に照らして評価します。
考慮事項 重要な理由 シナリオの例
データレジデンシーとコンプライアンス データを保存および処理する場所を決定します。規制ルールでは、特定の地域または複数のインスタンスが必要になる場合があります。 あるグローバル銀行は、GDPR に準拠するためにフランクフルトに地理的に存在する Salesforce 組織で Data 360 テナントをプロビジョニングしています。US ディビジョンのバージニアの組織に別のテナントをプロビジョニングします。
ガバナンスとセキュリティ ポリシー管理や委任戦略を含め、Data 360 の管理者と所有権を特定します。 強力な中央 IT を持つ多国籍企業が、Center of Excellence によって管理される専用の Home 組織を作成します。
自律性と集中管理 異なるリーダーがデータの個別の所有権を持ちたい場合があります。自律性を重視する場合は、複数の Data 360 組織が優先されます。一元化により、Data Cloud One が優先されます。 独立した子会社を持つ持株会社では、各ビジネスユニットが独自の 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 360 インスタンスではなく Data Cloud One を採用してライセンスコストを削減します。
将来の拡張性 今日のプロビジョニングの選択肢は、成長の基盤となります。 ある SaaS 会社は、1 つの Data 360 インスタンスから開始し、Salesforce 組織の子会社を買収して Data Cloud One に拡張する予定です。
企業全体の AI 準備状況 AI機能と Agentforce では、すべての org に接続された Data 360 テナントが必要です。プロビジョニングの決定は、AI モデルが企業全体でどのようにトレーニングおよび有効化されるかに影響します。 ある金融サービス会社は、データをData Cloud Oneに統合し、Einstein AIモデルがエンタープライズ全体の本顧客データにアクセスできるようにします。
## 使用事例 Data 360 プロビジョニングの決定が必要なメジャーユースケースは 3 つあります。 - Home 組織の選択 - 複数組織戦略の適用 - Data 360 組織間でのデータの共有 ### ホーム組織の選択 Data 360 ライセンスを購入すると、そのライセンスに関連付けられた Salesforce 組織に Data 360 インスタンスがプロビジョニングされます。この組織は Data 360 ホーム組織と呼ばれます。ホーム組織は Data 360 インスタンスのアンカーです。これには次の内容が含まれます。 - Data 360 ストレージおよびコンピューティングの管理 (プロビジョニング時に選択したリージョン)。 - 管理、ガバナンス、セキュリティポリシーの適用 - データの取り込み、ハーモナイゼーション、ID解決、セグメンテーション、有効化のパフォーマンス マルチ組織のシナリオでは、ホーム組織で他の Salesforce 「コンパニオン」組織の中央 Data 360 インスタンスを管理します。 **ホーム組織:** - Data 360 インスタンスの地理的位置を決定します。 - Data 360 インスタンスの所有者と管理者を決定します。Data 360 ホーム組織の管理者は、Data 360 に取り込まれたすべてのデータにアクセスできます。 - Data Cloud One 設定でコンパニオン組織の接続を制御します。 - 企業データ戦略の基盤を設定します。後で変更するのは難しく、混乱を伴います。 Data 360 ホーム組織についての詳細は、「[Data 360 Integration Patterns and Practices](/docs/architect/ja-jp/fundamentals/guide/data360_integration_patterns_and_practices)」を参照してください。 #### 決定: Home Org として既存の Org か新規の Org のどちらを使用するか? 最初の大きな決定は、既存の本番組織で 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 のプロビジョニング** **最適な用途:** 1つの主要な組織で連携できない複数のSalesforce組織を使用しているお客様、または強力なCenter of Excellence(CoE)モデルを使用している企業。 新しい専用組織での Data 360 プロビジョニングを示す図 - **長所:** - 継承された組織の複雑さがなく、ガバナンスがクリーンな状態から始められます。 - 複数の事業分野にまたがる一元管理。 - コンプライアンスのニーズに基づいて地域を柔軟に選択できます。 - 1 つのビジネスユニットに縛られず、中立的な「共有サービス」組織として機能します。 - 将来の Data Cloud One アーキテクチャ (複数のコンパニオン組織があるホーム組織) に合わせて設定します。 - **短所:** - 顧客は、Data 360 をプロビジョニングする新しい Salesforce 組織のライセンスを取得する必要があります。 - Data Cloud One コンパニオン接続を介して組織を Data 360 に接続するには、追加のインテグレーションが必要です。 - 管理オーバーヘッド (ユーザー管理、セキュリティ、ID) を追加する場合があります。 - 既存の本番組織（Production Org）のプロビジョニングと比較して、タイム トゥ バリューが遅い。 **例:** ある多国籍金融サービス会社は、Data 360 をプロビジョニングするための専用のホーム組織を作成します。 すべてのビジネスユニット組織 (リテール、ウェルス、コマースバンキング) は、Data Cloud One を介してコンパニオン組織として接続します。 **決定基準**
考慮事項 Home Org としての既存の OrG（優先 Default） Home Org としての新規 OrG（代替）
シンプルさ 既存の本ユーザとデータ構造に基づいて構築され、より迅速に設定できます。
Data 360 はデフォルトでホーム組織と統合されています。		 新しい Salesforce 組織のライセンスと設定、およびそれを管理するための追加の管理オーバーヘッドが必要
タイム トゥ バリュー ローカル CRM データの迅速な使用 立ち上がりが遅く、統合が必要です。
ガバナンス 既存の Org の基本ガバナンスモデル（既存の本ユーザと権限セット）を継承します（Org がすでに中心になっている場合は、許容されます）。 ガバナンスを一新し、完全な白紙状態から始められます。COE 主導のモデルに最適です。
コンプライアンス 既存の組織の地域に関連付けられたレジデンシー 既存の組織から独立した地域を柔軟に選択
Performance ローカル CRM クエリで最高のパフォーマンス コンパニオン Org の接続性（同じリージョンか、他の Org とのクロスリージョンか）に依存します。
将来の拡張性 Data Cloud One と組み合わせると適切に機能します。誤った Org を選択した場合、後からの移行が困難になります。 Data Cloud One を使用して簡単に拡張できます。中立性を考慮した設計。
Cost (コスト) インクリメンタルなコストが低くなります。 環境の追加によるオーバーヘッドの増加
#### おすすめ 原則として、既存のメジャー Org をホーム Org として使用することで、初期作業を最小限に抑え、導入の加速を図ります。長期的なガバナンスまたはコンプライアンス戦略上必要な場合にのみ、新しい専用のホーム Org を作成します。新しい専用のホーム組織を作成することは、Center of Excellence (COE) を使用する大規模企業にとって一般的な選択肢です。 **単一組織環境** 既存の本番組織で Data 360 をプロビジョニングします。これにより、シンプルさと即時の価値が最大化されます。不要なインテグレーションのオーバーヘッドを回避できます。 **複数 Org 環境** ホーム組織として機能させるには、主要な組織 (通常はビジネスの大半を実行する組織、または一元化された CRM として機能する組織) を 1 つ選択します。これにより、複雑さが軽減され、設定作業を最小限に抑え、Data 360 の価値をすばやく実感できます。既存のメジャー Org を使用すると、新しい環境の管理にかかるコストとインテグレーション作業も回避できます。 **新しい専用のホーム Org を検討する場合** ホーム組織を作成すると、柔軟性と中立性が確保されますが、タイム トゥ バリューは遅くなります。 - 組織に強力な Center of Excellence (CoE) があり、ビジネスユニット組織から独立したガバナンスが必要な場合。 - コンプライアンスや組織の制約のために適切な既存の組織が 1 つもない場合。 ### マルチ組織戦略の適用 #### マルチ組織の課題 多くの場合、企業は複数の Salesforce 組織を運用していますが、これは特別なケースではなく、通常です。2024 年 2 月の時点で、約 19,000 人の Salesforce ユーザーがすでに複数の Salesforce 組織を運用しています。 なぜこのようなことが起こるのでしょうか？ - **買収および合併:** 新しく買収された企業は、独自のSalesforceインスタンスを持ち込みます。 - **地域業務:**EU、北米、アジア太平洋など、多くの場合、データレジデンシー法を満たすために別々の組織を使用します。 - **機能の分離:** Retail Banking、Wealth Management、Insuranceなど、さまざまなビジネスユニットが、自律性のために独自の組織を維持します。 - **規制または**セキュリティの分離: 特定の業界では、コンプライアンス上の理由で論理的に異なる組織に義務付けられています。 - **歴史的または技術的な理由:** 時間の経過とともに、顧客は複数の組織を有機的に蓄積します。 それぞれの理由は個別に意味を持ちますが、それらが組み合わさってデータが断片化します。統合レイヤーを使用しない場合、各組織には顧客の部分的なビューのみが表示されます。 アーキテクチャの課題: コンプライアンス、ガバナンス、自律性の要件を尊重しながら、組織全体のデータを 1 つの情報源に統合する方法は? --- #### Data Cloud One Data Cloud One は、複数の Salesforce 組織で 1 つの Data 360 インスタンスを共有できる Salesforce の複数組織接続アーキテクチャです。これは、複数の Salesforce 組織を使用する企業に推奨されるパターンです。 Data Cloud One クラスターでは、Data 360 インスタンスをホストするホーム組織として 1 つの Salesforce 組織が指定されます。他の Salesforce 組織はコンパニオン組織として接続し、ホーム組織の Data 360 の統合データとメタデータを使用します。 Data Cloud One アーキテクチャを示す図 **Data Cloud One のしくみ** - **データ取り込みと統合 (ホーム組織)** - すべてのデータ取り込み設定 (Salesforce CRM、外部ソース、ストリーミング、バッチ) は、ホーム組織からのみ実行されます。 - ホーム組織に関連付けられたData 360テナントは、ID解決、ハーモナイゼーション、モデリング、信頼できるお客様のプロファイルへの統合を実行します。 - Data 360 の管理、ガバナンスポリシー、タギング、マスキングは、ホーム組織から一元的に適用されます。 - **データスペースアーキテクチャ** - ホーム組織からデータはデータスペースに整理され、データスペースはデータ、メタデータ、プロセスの論理コンテナとして機能します。 - 企業は、ブランド、地域、または事業部門のデータスペースを作成できます。 - データスペース共有: ホーム組織から、特定のデータスペースがコンパニオン組織と選択的に共有されます。これにより、関連するデータ (および関連付けられたメタデータ) のみが適切な組織に転送されます。 - **メタデータ共有** コンパニオン組織は、ホーム組織から、データモデルオブジェクト (DMO)、統合プロファイルスキーマ、計算済みインサイト、セグメント[など](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5)のメタデータ定義を受け取ります。これらは、ローカルアセットのようにコンパニオン組織内にネイティブに表示されますが、ホーム組織にリンクされています。 - **ホーム組織とコンパニオン組織の機能** 機能へのアクセスは、ホーム組織とコンパニオン組織で異なります。コンパニオン組織はデータの取り込みや統合ができず、取り込み、モデリング、統合はホーム組織に依存します。コンパニオン組織は Data 360 データにアクセスして Data 360 プラットフォーム機能を強化し、共有された信頼できるデータの上にローカルインサイト、セグメント、フローを作成できます。将来のビジョンでは、有効化機能にもアクセスできます。
機能 ホーム組織 コンパニオン組織
Connect コネクタの設定、データストリームの作成、データの取り込み、統合 ✅ ❌
ハーモナイズと統合：データ変換と ID 解決の構築および実行 ✅ ❌
データスペースと権限によるデータの保護 ✅ ✅
セグメント化と予測 セグメント、インサイトの構築、Einstein Studioモデルの作成 ✅ ✅
Everywhere の有効化、データアクション ✅ ✅
プラットフォーム機能: プロンプトビルダー、フロー、レポート、強化、[さらに詳しく](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) ✅ ✅
Data 360 搭載の機能: Prospecting Center、Sales Cloud および Service Cloud の機能、Agentforce など ✅ ✅
- **プラットフォーム機能パリティ** ユーザーとビルダーの観点では、メタデータが共有されると、Salesforce Platform 機能の使用に関して自宅組織とコンパニオン組織でいくつかの機能の違いが生じます。サポートされている機能のリストは、「[Data 360 Features](https://help.salesforce.com/s/articleView?id=data.c360_a_companion_org_data_cloud_features.htm&type=5) on Companion org (コンパニオン組織の Data 360 機能)」を参照してください。 - Salesforce Platformの機能(フロー、レポート、プロンプトビルダー、ダッシュボード、その他のプラットフォーム固有のツールなど)は、メタデータが使用可能になると、自宅組織とコンパニオン組織の両方で機能します。 - Agentforce、見込み調査センター、Sales Cloud Einstein 機能、Service Cloud AI 機能などの Data 360 を活用した機能も、ホーム組織とコンパニオン組織の両方でシームレスに動作します。一部の機能は完全な互換性を達成するまでに時間がかかる可能性がありますが、全体的な目標は、Data 360 に依存するすべてのクロスクラウド機能について自宅組織とコンパニオン組織で同等の機能を実現することです。 - **消費モデル** コンパニオン組織のすべてのアクティビティ(クエリ、セグメントの実行、Data 360トリガー フロー、AIの使用状況、Einstein Trust Layerのログ記録など)では、ホーム組織のData 360クレジットが使用されます。消費は一方向です。クレジットは一元化され、請求され、ホーム組織のクレジット割り当てに対して追跡されます。ただし、ドリル ダウンすると、各個人組織が Digital Wallet で使用したクレジット数を確認できます。 - **設計原則: 横方向の構築** Data 360 の水平構造は、主に Data Cloud One を介して実装される基本的な設計原則であり、1 つの Data Cloud インスタンスを複数の別々の Salesforce CRM 組織にまたがることができます。目標は、新しくリリースされたすべての機能が、追加の設定なしでホーム組織とコンパニオン組織の両方で動作することです。この機能により、Data Cloud One は単なるデータアーキテクチャの選択肢ではなく、今後の Salesforce Platform の基盤要素となります。 --- #### 決定: 複数のデータ組織 vs. 共有 Data 360 (Data Cloud One) 複数の組織を持つ企業は、エコシステム内で Data 360 を配置する方法と場所を選択する必要があります。各組織で独立した Data 360 組織をプロビジョニングするのか、Data Cloud One を使用して 1 つのホーム組織で組織を統合するのか? **オプション A: 複数の独立した Data 360 組織** 各 Salesforce 組織は、独自の Data 360 インスタンスをプロビジョニングします。 **長所:** - **自律性:** 各ビジネスユニットまたは地域が独自の Data 360 を制御します。 - **各組織内**のシンプル化: ガバナンス、セキュリティ、カスタマイズがローカライズされています。 - **法令順守:** 厳格な規制の分離が必要な場合 (データが国境を越えてはならない場合など) に役立ちます。 **短所:** - **データ サイロ:**組織間でプロファイルを統合することはできません。 - **高いコスト:** インスタンスごとにライセンス、管理、インテグレーションが必要です。顧客は複数の異なる組織で同じソースデータを複数回取り込むことになります。 - **重複作業:** IDの解決、セグメンテーション、強化を各Data 360インスタンスで繰り返す必要があります。 **オプション B: 1 つの共有 Data 360 (Data Cloud One クラスタ)** 1 つの Data 360 がホーム組織にプロビジョニングされ、他の Salesforce 組織がコンパニオン組織として接続されます。 **長所:** - **Single Source of Truth (SSOT):** すべての組織で統合データモデルが共有されます。 - **コスト効率:** 1 つの Data 360 ライセンスとインフラストラクチャのみを管理します。 - **統合ガバナンス:** ポリシー、セキュリティ、およびコンプライアンスの管理を一元的に適用します。 - **組織間強化:** コンパニオン組織間でハーモナイズされたプロファイル、インサイト、セグメントにアクセスできます。 - **AIの準備**状況:エンタープライズ全体のデータセットにより、AIモデルのトレーニングと有効化を改善できます。 - **将来性:**新しいコンパニオン組織の追加は、新しいData 360組織を必要としないため簡単です。 **短所:** - **追加の準備:**1 つの Data 360 では、組織間接続を計画する必要があります。 - **レイテンシの考慮事項:** さまざまな地域のコンパニオン組織ではクエリが遅くなる場合があります。 - **複雑なガバナンス:** 組織ごとにカスタマイズのニーズが異なる場合、詳細なガバナンスが複雑になる可能性があります。 **オプション C: 複数の Data Cloud One クラスタ** ガバナンス、コンプライアンス、その他のビジネス要件により、すべての組織をクラスター化することが現実的でない**場合が**あります。そのため、企業が複数の Data 360 組織を運用し、それぞれが別のコンパニオン組織のクラスターのホーム組織であるハイブリッドソリューションを実装することが必要になる場合があります。 **例:** ある多国籍企業では、ヨーロッパ、米国、アジアなど、さまざまな地域に Salesforce 組織があります。地域のデータレジデンシー規制に準拠するため、各地域ごとに 1 つの Data 360 をプロビジョニングします。 **決定基準**
考慮事項 複数の独立した Data 360 組織 1 つの共有 Data 360 (Data Cloud One)
自治 組織またはビジネスユニットごとの高度な自律性 一元化されたガバナンス、組織ごとの自律性の低下
コンプライアンス 厳密な分離が必要な場合 (地域の法律など) に便利です。 レジデンシーで一元化が許可されている場合に最適
Cost (コスト) ライセンスコストと管理コストの増加 コスト効率が向上: 多くの組織で 1 つのライセンスを使用
ガバナンス 断片化。ポリシーは組織ごとに異なる 組織全体で一元化された一貫したポリシー
データサイロ 各組織が独自のビューを持つ（エンタープライズ 360 なし） 統合されたデータセット (重複なし)
AI/分析 各組織のデータに制限 精度が向上したエンタープライズ規模のモデル
複雑さ 管理するインスタンスの増加、インテグレーションの増加 シンプルなアーキテクチャ、可動部品の削減
Performance 組織内ユースケースに最適 コンパニオン組織のアクセスによる潜在的な遅延の増加
--- #### おすすめ **推奨パターン: Data Cloud One** 複数の組織にまたがるガバナンスを簡素化し、コストを最適化するには、接続されたコンパニオン組織と共に 1 つのホーム組織を使用します。 複数のData 360組織を**使用する場合:** コンプライアンス、レジデンシー、または組織の自律性によって厳密に必要とされる場合のみ、複数のData 360組織を使用します(規制のためにヨーロッパの業務を米国の業務から完全に分離する必要がある場合など)。 Data Cloud One でのホーム組織の**選択方法:** まず、主要な組織の 1 つ (通常はほとんどのビジネスが実行されている組織) を検討します。Data 360 をプロビジョニングすることで、複雑さを最小限に抑え、早期の価値を最大化できます。 適切な既存の組織がない場合にのみ、COE チームが管理する専用のホーム組織を作成することを検討してください。 **一般原則:** マルチ組織環境では、Data 360 組織の数を最小限に抑えます。Data Cloud One をデフォルトパターンとして選択すると、重複が減り、AI の準備が有効になり、ガバナンスが簡素化されます。 ### Data 360 組織間でのデータの共有 #### データ共有の必要性 Data Cloud One はほとんどの企業にとって推奨される方法ですが、次のような複数の Data 360 インスタンスをプロビジョニングする必要があるシナリオもあります。 - **地域のコンプライアンス。**ある多国籍リテーラーは、EU と米国にそれぞれ 1 つの Data 360 をプロビジョニングしています。Data 360-to-Data 360 データ共有により、ローカルデータからインサイトを作成し、そのインサイトを米国本社と共有できます。 - **ビジネスユニットのコラボレーション。**ある複合企業では、リテールと保険で別々の Data 360 組織を運営しています。Data 360 組織間のデータ共有により、ユーザーは移動やコピーを行うことなく、1 つの信頼できるデータソースにアクセスできます。Data 360 組織間のデータ共有により、保険組織はターゲットを絞ったクロスセルキャンペーン用にリテールの「価値の高い顧客」セグメントを受け取ります。 - **合併と買収。**親会社が、独自の Data 360 を持つ子会社を買収します。2 つのインスタンスを管理するにあたり、短期データサイロを維持することで、データセキュリティと SSOT の整合性が保たれます。同時に、2 つの Data 360 インスタンス間でデータを共有することで、移行中に必要なコラボレーションが可能になります。 - **フェデレーテッド・エグゼクティブダッシュボード。**複数の大陸にまたがる多国籍企業では、各リージョンごとに個々の Data 360 組織がプロビジョニングされます。エグゼクティブは、四半期ごとのパフォーマンスのフェデレーテッド・ビューを求めています。各リージョンの 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 などの機能は、それぞれローカルインスタンスで独立して動作します。共有は自動的に行われません。特定のオブジェクトについてのみコラボレーションするには、意図的なデータ共有を作成する必要があります。 #### Data 360 組織間でのデータ共有の長所と短所
要素 プラス面 マイナス面
データレジデンシー コラボレーションを可能にしながら、地域の分離をサポートします。 複数の Data 360 組織を管理する必要がなくなるわけではありません。
データの複製 ゼロコピー、オブジェクトの重複なし。 各データ共有に含めるオブジェクトを慎重に選択する必要があります。
ガバナンス 共有は明示的かつ意図的に行われます (オブジェクトレベル)。 タグまたはポリシーフローはありません。対象組織はガバナンスを再適用する必要があります。
複雑さ 一元化なしで選択的なコラボレーションを可能にします。 複数の Data 360 組織とデータ共有の管理が必要です。
**AI/Analytics** リージョンごとの AI 分析が可能。インサイトを組織間で共有できます。 データを意図的に共有しない限り、企業全体の AI は利用できません。
**プラットフォーム機能** 各組織の Data 360 搭載機能は独立して実行されます。 自動共有なし。慎重に設計しないと重複のリスクがあります。
Cost (コスト) ETL パイプラインの必要性を減らすことができる。 複数の Data 360 組織のコストは依然として発生します。データクエリとデータ共有の単位数を消費します。
#### 決定条件
考慮事項 Data Cloud One (マルチ組織に推奨) Data 360 組織間でのデータ共有
一元化された情報源 はい — すべての組織でデータモデルが共有されます。 いいえ — 各 Data 360 には独自のデータモデルがあります。
コンプライアンス レジデンシーで一元化が許可されている場合にのみ機能します。 居住法によって一元化が妨げられている場合に必要です。
ガバナンス 一元化され、一貫性があります。 フェデレーテッド — 意図的なオブジェクトレベルの共有。
複雑さ 可動部品が少なく、シンプル。 より複雑 — 設定データ共有と複数のデータ組織が必要です。
AI/分析 企業全体の AI モデル。 地域 AI。インサイトを選択的に共有する。
プラットフォーム機能 Shared Data 360 では、ホーム組織とコンパニオン組織全体で、すべての機能が一貫して動作します。 機能は Data 360 ごとに独立して実行されます。共有は明示的に行う必要があります。
#### おすすめ **エンタープライズに複数の Data 360 組織がある場合** - カスタムパイプラインを作成したりデータを複製したりするのではなく、Data 360 組織間でデータ共有を使用してコラボレーションします。 - データ共有を作成して対象組織に付与することで、特定のオブジェクト (DMO、計算済みインサイト、セグメント) を共有します。 - タグは共有されません。受信組織は、ガバナンス、分類、AI 強化のためにタグを再適用する必要があります。 **Data 360 組織間でのデータ共有の使用** - 一元化を妨げる規制要件を満たす。 - ビジネスユニットの自律性を維持しながら、選択的なコラボレーションを実現する。 - 複数のリージョンにわたって、フェデレーテッドなエグゼクティブダッシュボードを提供する。 - 統合がすぐには実現できない M&A シナリオの橋渡しをします。 **慎重に設計してください** Data 360-to-Data 360 データ共有は、Data Cloud One の置き換えではなく、統合戦略として扱います。 - オブジェクト固有の共有を使用します。 - 共有しすぎないようにします。 - データ共有をビジネスおよびコンプライアンスのニーズに合わせます。 #### 記憶 Data 360 プロビジョニングのデータ戦略を計画することは、組織ごとではなく、企業全体で取り組む必要がある重要な長期的なアーキテクチャ上の決定事項です。この初期の戦略的選択によって、顧客データの統合方法、ガバナンスの適用方法、およびプラットフォームの不可欠な機能 (特に AI と分析) の組織全体の拡張性が決まります。ガバナンスとオーナーシップのモデルを事前に計画し、断片化や複雑さの増大につながる短期的なショートカットを回避します。 ## リソース [Customer 360とは?](https://www.salesforce.com/products/what-is-customer-360/) [Data 360 インテグレーションのパターンとプラクティス](/docs/architect/ja-jp/fundamentals/guide/data360_integration_patterns_and_practices) [Data 360 アーキテクチャ](/docs/architect/ja-jp/fundamentals/guide/data-360-architecture) [Data 360 セキュリティアーキテクチャ](/docs/architect/ja-jp/fundamentals/guide/data360_security_architecture) **著者について** 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 のソフトウェアエンジニアリングアーキテクトで、データおよびインテリジェンスアプリケーションプラットフォーム内のデータアーキテクチャを専門としています。データガバナンスと統合データモデルに焦点を絞ったエンタープライズアーキテクチャレビューボード (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をプロビジョニングするときの基本的な意思決定を対象とします。 - **自宅組織の**選択: ガバナンス、コンプライアンス、タイム トゥ バリューを考慮して、既存の本番組織で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 対応のデータアーキテクチャを構築できます。 # 非同期処理 このガイドを使用して、各使用事例に適した Salesforce 非同期処理方法を選択してください。 ## ガイドの概要 このガイドは、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 エラーを回避します。 ローコード ライセンスの数と種類によって制限が増加する可能性があります。
スケジュール済みパス (確定後フロー) トリガーイベント (レコードの作成、更新、削除など) 後の動的にスケジュールされた時間に実行します。 ローコード ライセンスの数と種類によって制限が増加する可能性があります。
スケジュール済みフロー 指定した時刻と、毎日、毎週、または一度といった繰り返し頻度で、バックグラウンドでフローを実行し、バッチ内のレコードに対してアクションを実行します。 ローコード ライセンスの数と種類によって制限が増加する可能性があります。
プラットフォームイベントトリガー 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 に移動します。一度限りのプロセスまたは定期的に実行されるプロセス。 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に絶対的に存在する必要がない限り、代わりにSalesforce Connectを使用したデータの仮想化を検討してください。組織のデータが増加すると、最終的にデータ量が増加し、[パフォーマンス](/docs/architect/ja-jp/well-architected/guide/reliability.html#scalability-and-capacity-planning)に悪影響を及ぼし、技術的な負債が増加する可能性があります。データがすでに 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-からのアウトバウンドインテグレーション用プロコードツール) ### Salesforce からのアウトバウンドインテグレーション用のローコードツール
ガイダンス ライセンス タイミング ボリューム＆スケール デリバリー＆メンテナンス プライバシーとセキュリティ
使用するケース 追加ライセンス 同期 (要求/応答) または非同期 (起動/忘れ) 複数オブジェクトのサポート LDV/Bulk テストと導入** デバッグ 組み込みエラーハンドリング/再試行動作 保存状態のデータが暗号化されている場合でも使用可能 認証プロトコル
変更データキャプチャ Salesforce で行われたレコードレベルの変更を外部システムに公開する必要があり、カスタムペイロードが不要な場合。 必須 非同期 なし なし はい プロコードツールの使用 はい はい OAuth
外部サービス フロー、Apex、Einstein Bots、OmniStudioを使用してプロセスを調整する場合、外部システムAPIはOpenAPI仕様を使用して記述されます。 不要 同期 あり いいえ あり プロコードツールの使用 いいえ なし 指定ログイン情報
Heroku Connect 双方向同期を使用してデータを拡張して Heroku のモバイルアプリケーションや他のアプリケーションを有効にし、データを Salesforce にも複製する場合。 必須 非同期 はい はい 不可 プロコードツールの使用 はい はい、Shield Connect を使用 OAuth
OmniStudio インテグレーション手順 ユーザー操作なしでデータを変換し、ブラウザーではなくサーバーで処理することでパフォーマンスを向上させる必要がある場合。 必須 両方 はい はい はい 宣言型サポート はい はい 指定ログイン情報
Salesforce Connect/外部オブジェクト Salesforce UI にデータを表示し、データを外部システムに保存する場合。データは Salesforce に複製されません。 必須 同期 いいえ はい* はい プロコードツールと宣言型トレーサーを使用 いいえ なし 指定ログイン情報
*バージョン4.01より古いOdataアダプタには、コールアウト制限が適用されます。詳細については、「Odata Callout Rate Limit Considerations」を参照してください。** テストおよびリリースとは、より低い環境で構築し、メタデータ API、パッケージ、または変更セットを使用して本番環境にリリースする機能を指します。
### ユースケース: ローコードツールを使用したアウトバウンドインテグレーション > 商談が成立したら、関連付けられた商品の注文を会社の ERP システムまたは注文管理システムで作成する必要があります。 **Change Data Capture** 商談レコードが更新されると、Change Data Capture はオブジェクトへの更新を含む変更イベントを公開します。変更イベントは 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 Flow を使用して別のシステムへのコールアウトを自動化する場合。開発者は、フローで呼び出すことができる 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 組織や他の外部システムにデータを複製する場合。 必須 両方 はい はい はい はい はい はい 複数
[\*Add-on](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 からのアウトバウンドインテグレーション用プロコードツール
ガイダンス ライセンス タイミング ボリュームおよびスケール 提供およびメンテナンス プライバシーとセキュリティ
使用するケース 追加ライセンス 同期 (要求/応答) または非同期 (起動/忘れ) 複数オブジェクトのサポート 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-への受信インテグレーション用のハイブリッドツール) - [インバウンドインテグレーション用のプロコードツール](#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 システムで特定の応答が予期される場合、Data Mapper の変換または抽出アクションを使用して、取引先責任者レコードの更新によってトリガーで生成されたデータを宣言的に含む追加機能を持つ 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 には独自の Salesforce 組織があります。1 人の顧客が企業の複数のビジネスユニットを処理するため、取引先データと商談データが複数の組織に存在するとします。企業は、1つのSalesforce 組織で全ビジネスユニットのすべてのアカウントおよび商談データの集計ビューにアクセスする必要があります。 _注意: 以下のすべてのソリューションは、[重要ポイント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 または Core で測定）に合わせてフローが適切にサイジングされている限り、トランザクションボリュームに制限はありません。 **ネイティブのSalesforce API**クエリ操作は、特に数千件のレコードを効率的に抽出するのに適したSalesforce Bulk API 2.0を使用して、関心のある各組織に発行できます。各組織からクエリ結果を個別に取得し、顧客の要件に応じてカスタムアプリケーションまたはミドルウェアで集計できます。 **Salesforce Connect with** Cross-Org Adapter Salesforce Connect Cross-Org Adapter は、リモート組織の取引先または商談がすべて_異なる_オブジェクトとして中央組織に表示されるため、このシナリオには適していません。たとえば、すべてのSalesforce組織にまたがる全ての商談の金額の総計を算出する方法はありません。 **Selective Updates Cross-Orgnario (**組織間選択的な更新) シナリオ: ある営業担当が Salesforce 組織 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/reliability.html)された信頼性」を参照してください)。 - **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/operational-excellence.html)。
頻繁に変更されないソースデータソースシステムのデータの変更頻度が低すぎて定期的な更新で十分な場合は、イベント駆動型パターンではなく [バッチパターン] (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/reliability.html)された信頼性」を参照してください。他のパターンは、大量のデータが含まれるインテグレーションや、より長期間のメッセージ保持を必要とするシナリオなど、ここで説明する特定の使用事例に適用されます。 ### 一目でわかるパターン 次の表は、このドキュメントで説明されているパターンの属性を比較したものです。特定の使用事例の潜在的なパターンを特定する必要がある場合のクイックリファレンスとして使用します。
パターンほぼリアルタイム一意のメッセージコピー配信の保証メッセージサイズの削減データの変換
公開/登録✓✓✓
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 にのみ接続します。ローコード
### 公開/購読 コアアプリケーション内で重要なレコードの状態が変更された場合 (注文の状況が「処理中」から「出荷済み」に変更された場合など)、他の複数のシステムでそれぞれのタスクを実行するためにほぼリアルタイムの通知が必要になる可能性があります。このような変更の量が多く、メッセージが複雑な場合、特定のビジネスニーズが発生します。従来のポイント・ツー・ポイントインテグレーションは負担が大きく、メンテナンスが困難です。すべての連動アプリケーションに対して脆弱なカスタム接続を確立すると、技術的な負債が発生し、組織の迅速な拡張が妨げられます。これらの頻繁なデータ同期を管理するには、ソースシステムをすべての利用システムに直接結合せずに、堅牢なインテグレーションアプローチが必要です。 #### 公開/登録パターン 次の図は、複数のパブリッシャーと登録者がイベントバスを介してデータを共有する一般的な公開/登録パターンを示しています。この基本パターンは、このガイドの残りの部分にあるより具体的なパターンの基礎となります。このパターンの主な特徴を次に示します。 - パブリッシャーと登録者の間に直接のつながりはありません。パブリッシャーは、イベントバスにメッセージを送信するだけで、イベントバスはメッセージをリッスンする他のシステムにブロードキャストします。 - 同じシステムがパブリッシャーと購読者の両方になる可能性があります。 - システムは、複数の種別のイベントを公開または登録できます。 - このガイドのすべてのパターンと同様に、公開/登録パターンは、リモートプロシージャ呼び出し (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 では、引き続き現在の機能の範囲内でアウトバウンドメッセージをサポートしますが、この技術への追加投資は予定していません。* * イベントリレーは AWS Eventbridge にのみ接続します。
### 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/reliability.html#scalability-and-capacity-planning)された信頼性」を参照してください。 - **ケースまたは請求管理:** サービスベースの企業では、停止中にケースまたは請求数が急増する可能性があります。 - **複雑なデータ変換:** メッセージを変換するための複雑なロジックを必要とする組織は、多くの場合、変換よりも早くイベントが生成されることを懸念します。 #### 渡されるメッセージパターン このパターンは、変換よりも早くメッセージが生成されるという問題に対処します。ストリーミングメッセージプラットフォームとセグメント化されたメッセージ処理ロジックを専用コンポーネントに組み込むことで、大量のメッセージと必要なデータ操作を確実に処理できます。 「渡されるメッセージ」パターンは、メッセージ処理ロジックを複数のセグメント化されたコンポーネントに分割することで機能します。 - 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 パターンの非同期の性質上、メッセージがキューに追加されてから取得されるまでに長い遅延が発生する可能性があります。キューにはメッセージを保持するためのメモリまたはストレージ容量が必要なため、無制限に拡張することはできません。つまり、無制限にオフラインになっている登録者は、キューに十分なメッセージが蓄積されると、障害が発生する可能性があります。メッセージのバッファリングは、登録者の処理時間が長くなりすぎて大量のメッセージがキューに蓄積された場合にも同じ影響を及ぼす可能性があります。これらのリスクを軽減するには、すべてのメッセージキューのストレージ要件を徹底的に分析し、必要に応じて、メッセージが設定された時間内に取得されなかった場合や、メッセージが事前に定義された量に達した場合にキューを消去および無効にするプロセスを設計します。 ## 非機能の考慮事項 前のセクションにリストされている機能に関する考慮事項に加えて、決定に考慮すべき機能以外の考慮事項もあります。 ### ポイントツーポイントインテグレーションからの移行 イベント駆動型アーキテクチャが組織に適していると完全に確信していても、すでに多数のポイントツーポイントインテグレーションがある状況から開始している場合があります。すべてのインテグレーションを一度に置き換えるプロジェクトの資金を得ることは困難な場合があります。また、一部のレガシーシステムでイベント駆動型アーキテクチャを直接使用することさえできない場合もあります。これらのシナリオでは、最もビジネスクリティカルなアプリケーションを最初に変換してから、将来のプロジェクトで更新または置き換えられたときに他のシステムを変換することで、より疎結合なアーキテクチャに段階的に移行できます。このアプローチにより、イベントバスに新しいアプリケーションを簡単に追加でき、時間の経過と共にシステムが追加されても IT ランドスケープ全体の拡張性と耐障害性を維持できます。 ### 疎結合システム内のトレードオフ アーキテクトは、すべてのアーキテクチャにはトレードオフがあることを認識しています。イベント駆動型アーキテクチャも例外ではありません。疎結合のシステムでいっぱいのランドスケープは、拡張性と耐障害性に優れていますが、次のようなトレードオフも考慮する必要があります。 - **統合戦略全体:** 使用するツールやパターンに関係なく、まず、組織内のさまざまなシステムでデータを共有する方法に関する戦略を作成することが重要です。この戦略には、データの目標、データの共有方法と使用パターン、データソース、対象、構造、所有権とアクセスの要件を含める必要があります。 - **レガシーシステムのサポート:** 組織にイベント駆動型アーキテクチャパターンをサポートしていないレガシーシステムがある場合があります。回避策 (イベントに登録し、別のデータ転送手段を使用して出力をターゲットシステムに送信するパススルーとして機能するプロセスなど) を構築することは可能ですが、この場合は他のインテグレーション方法を検討することをお勧めします。 - **メッセージの構造変更:**最初のメッセージ構造が定義され、パブリッシャとユーザの間で合意されると、特にユーザが外部である場合、変更が困難になる可能性があります。この問題に対処する方法はいくつかあります。バージョン管理されたエンドポイントを使用できますが、開発者が同時に多くのバージョンを管理する必要がないように、各バージョンの明確なライフサイクルを定義して伝えてください。Heroku の Apache Kafka がランドスケープの一部である場合は、スキーマレジストリや同様のツールを検討することもできますが、ランドスケープ内の他のシステムでもサポートされている (および使用されている) ことを確認してください。 - パブリッシャーと登録者間の可視性**の欠如:** ほとんどのイベント駆動型アーキテクチャパターンでは、パブリッシャーは登録者の状況を認識しません。そのため、すべての登録者がオフライン中にパブリッシャーが重要なメッセージを送信すると、メッセージが配信されない場合があります。リプレイ機能を使用するか、すべての重要なメッセージに対して別々のサーバで実行される冗長なユーザを追加することで、この問題に対処できます。 - **パフォーマンスのボトルネック:**イベント駆動型アーキテクチャが拡張するにつれて、イベントバスが大量のパブリッシャーに同時にメッセージを送信しようとして多すぎると、メッセージ配信のボトルネックになる可能性があります。これに対処するには、イベントバスに割り当てられるメモリと処理リソースを増やすか、複数のイベントバスを使用して異なる種別のメッセージを並列処理します。 ## 関連するベストプラクティス すでに提供されているガイダンスに加えて、次のベストプラクティスも考慮してください。 ### イベント駆動型アーキテクチャの実装 イベント駆動型アーキテクチャを実装する前に、そもそも本当に使用する必要があるかどうかを検討します。前のセクションでは、各イベント駆動型アーキテクチャパターンに適した一般的なビジネスシナリオについて説明します。詳細は、「[適切に設計](/docs/architect/ja-jp/well-architected/guide/reliability.html)された信頼性」も参照してください。「イベント駆動型アーキテクチャを実装するときに考慮すべき課題」を確認して、想定しているパターンが特定の使用事例に最も適しているかどうかを判断します。 このガイドで扱うシナリオの大部分はインテグレーションに関連しますが、イベント駆動型アーキテクチャでは、プラットフォームイベントなどを使用して 1 つの Salesforce 組織内でメッセージを送信することもできます。プラットフォームイベントを内部メッセージングシステムとして使用するプロセスを設計するときは、該当する[イベント割り当て制限](https://developer.salesforce.com/docs/atlas.en-us.platform_events.meta/platform_events/platform_event_limits.htm)に留意してください。 ### アンチパターンを回避する 多くの場合、イベント駆動型アーキテクチャのアンチパターンは、Salesforce 組織の内部コミュニケーションの回避策としてイベントを使用することに起因します。一般的なアンチパターンは次のとおりです。 - **Apex トリガーから同じイベントオブジェクトに関連付けられたイベントを公開：** これにより、無限トリガーループが発生します。 - DML トランザクションが完了する前に **Apex からイベント**を公開： トランザクションが失敗してロールバックされた場合、［Publish Immediately］ （すぐに公開） 動作を持つ公開済みイベントはロールバック動作に含まれません。 - フローでの**イベントの公開**による後続の自動化の調整: 複数の自動化間でロジックを調整する最適な方法は、[サブフロー](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() をコールしてコンポーネントのこのインスタンスがフォーカスされたタブ内に含まれるかどうかを判断したりして、各イベントが意図した場合にのみ処理されるようにします。 - プラットフォームイベントの**公開動作に**は、\[Publish Immediately (すぐに公開)] と \[Publish After Commit (コミット後に公開)] の 2 つの公開動作があります。リアルタイムプラットフォームイベントは、トランザクションが成功して確定したかどうかに関係なくログイベントを公開する必要があるログ記録などの使用事例で使用できます。ただし、リアルタイムプラットフォームイベントでは、\[Publish Immediately (すぐに公開)] を慎重に使用してください。イベントは、購読者が同じトランザクション内でコンシュームし、行ロックやその他のレースコンディションを引き起こす可能性があります。 ### 効果的なイベントの設計 イベント駆動型アーキテクチャを実装する場合、成功への鍵の 1 つはイベント自体の設計方法の標準を設定することです。詳細は組織の使用事例によって異なりますが、一般的なガイドラインを次に示します。 - **イベントペイロードの最適な構造を決定します。**メッセージサイズを小さくすると処理時間が短縮されますが、大量のメッセージを登録者に送信しようとすると、パフォーマンスのボトルネックが発生する可能性があります。適切なバランスを見つけるために、ペイロードのサイズと構造に対して反復処理が必要な場合があります。MuleSoft および同様の ESB ツールでは、イベントに関連付けられたメッセージでカスタムペイロードを設計できるため、登録者側のパフォーマンスを向上させるためにデータ構造を視覚化できます。(詳細については、「[適切に設計](/docs/architect/ja-jp/well-architected/guide/reliability.html)された信頼性」を参照してください)。 - **プロセスをエンドツーエンドで検討してください。**インテグレーションがロールアウトされると追跡が困難になる可能性がある「無限ループ」シナリオを作成していないことを確認します。たとえば、レコードが更新されたときにイベントを公開し、同時に相互のイベントをリスンする 2 つのシステムで、処理時に追加の公開イベントがトリガーされます。 この種別のアンチパターンを修正するには、消費されたイベントの結果として行われた変更によって新しいイベントが公開されないようにするロジックを両方のシステムに追加します。また、すべてのイベント、関連付けられたトリガー、および影響を受ける可能性のあるダウンストリームシステムを文書化する必要があります。このドキュメントは、無限ループや類似するシナリオをできるだけ早くキャッチするための設計セッション中の参照資料として使用します。(詳細については、「[適切な設計 - Operational Excellence](/docs/architect/ja-jp/well-architected/guide/operational-excellence.html)」を参照してください)。 - **システム全体で共通の命名規則を使用します。**イベント駆動型アーキテクチャを含め、すべてのソフトウェア開発で一貫した命名規則を使用することをお勧めします。イベント名、構造、関連付けられたオブジェクト、エラー処理プロセスに関する一連の標準を文書化して、システム全体で一貫性を確保します。(詳細については、「[適切に設計](/docs/architect/ja-jp/well-architected/guide/operational-excellence.html)された運用性」を参照してください)。 ## リソース
パターンリソース
公開/登録Salesforce の適切なアーキテクチャ - 信頼性
Salesforce Well-Architected - Operational Excellence (適切に設計された Salesforce - 優れた運用性)
ブログ投稿: Achieve Architectural Efficiency with Event Relays (イベントリレーを使用したアーキテクチャの効率化)
ブログ投稿: Announcing Pub/Sub API Generally Available (パブリッシュ/購読 API 一般提供開始)
ブログ投稿: Moving from RESTful to EVENTful (RESTful から EVENTful への移行)
ブログ投稿: Event-Driven Architectures and the AsyncAPI Specification (イベント駆動型アーキテクチャと AsyncAPI 仕様)
動画: パブリッシュ/購読 Pattern Walkthrough
Fanoutブログ投稿: How to Work Within Platform Events Delivery Limits (プラットフォームイベント配信制限内での作業方法)
動画: Fanout Pattern Walkthrough (ファンアウトパターンウォークスルー)
パス済みメッセージ動画: Passed Messages Pattern Walkthrough (合格メッセージパターンウォークスルー)
ストリーミングブログ投稿: Designing for High-Volume Writes in Salesforce (Salesforce での大量の書き込みのための設計)
動画: ストリーミングパターンのウォークスルー
ドキュメント: Mule アプリケーションでのストリーミング
キューイングブログ投稿: Designing for High-Volume Writes in Salesforce (Salesforce での大量の書き込みのための設計)
ブログ投稿: How to Design Payment Architectures with Evented APIs (イベント API を使用した支払アーキテクチャの設計方法)
動画: Queueing Pattern Walkthrough (順番待ちパターンウォークスルー)
# インテグレーション・ディシジョンガイドのはじめに このセクションでは、Salesforce に適したデータインテグレーションツールとアプローチを選択するための実践的な指針を提供します。アウトバウンドインテグレーション、インバウンドインテグレーション、組織間シナリオを対象としており、アーキテクトはパフォーマンス、メンテナンス性、コストのバランスの取れたデータレイヤーインテグレーションの設計と実装を行うことができます。 --- ## Salesforce とのデータインテグレーション [Salesforce とのデータインテグレーション](/docs/architect/ja-jp/decision-guides/guide/data-integration)では、Salesforce データインテグレーションツールとベストプラクティスの概要を包括的に説明します。 - **Integration Tool Landscape** (インテグレーションツールの概要): ローコード、ハイブリッド、プロコードのオプションを含む Salesforce データインテグレーションツールの概要と、特定の使用事例に適したツールの選択に関する指針。 - **送信インテグレーション**: 変更データキャプチャ、外部サービス、Heroku Connect、OmniStudio Integration Procedure、Salesforce Connect、MuleSoft Anypoint、カスタムApexソリューションなど、Salesforceから外部システムにデータを送信する方法。 - **受信インテグレーション**: 外部データを Salesforce に取り込むためのアプローチ。データレプリケーションと仮想化の比較、および各ツールを使用するタイミングに関するガイダンスがあります。 - **組織間インテグレーション**:MuleSoft Anypoint、Heroku Connect、ネイティブSalesforce API、変更データキャプチャ、Salesforce Connect with Cross-Org Adapterなど、Salesforce組織間でデータを共有するための推奨方法。これには、従来のSalesforce-to-Salesforce実装を置き換えるためのガイダンスが含まれます。 - **決定フレームワーク**: 既存のツールやランドスケープ、データフローの要件 (タイミング、方向性、予想されるユーザーエクスペリエンス)、実装の複雑さ、メンテナンス性、データ量、プラットフォームの制限など、インテグレーションツールを選択する場合の主要な考慮事項。 アーキテクトはシナリオごとに適切なインテグレーションツールとパターンを選択でき、不要なデータレプリケーションを最小限に抑え、既存の ESB/ETL ソリューションを活用し、エンタープライズアーキテクチャの原則に準拠した拡張性とメンテナンス性に優れたインテグレーションを実現できます。 # エージェント型および従来のワークフローの自動化の決定 Agentforceを使用すると、企業はルールに簡単には削減できない自動化作業の新しいパラダイムを開くことができます。これらの新機能には、構造化されていない会話からの顧客のインテントの解決、システム全体のマルチパーティプロセスの調整、運用状況へのリアルタイムの対応が含まれます。エージェント型ワークフローでは、定義済みの手順を実行するのではなく、結果に基づいて推論するように設計された自動化が使用されます。この需要を満たすには、自動化の複雑さの全範囲で動作するプラットフォームと、各機能がどの段階に適しているかを示すフレームワークが必要です。 Agentforce は、Einstein Trust Layer、推論エンジン、エージェントスクリプト、Flow、Apex、Data 360 を 1 つの統合プラットフォームに統合します。この組み合わせにより、単純なレコードトリガーの自動化から、音声、ビジョン、ドキュメント、リアルタイムテレメトリにわたる複雑なマルチエージェントオーケストレーションまで、あらゆるものが処理されます。MuleSoft は、企業全体でエージェントワークフローを接続するために必要な MuleSoft ファブリック、ガバナンス、クロスシステムオーケストレーションを使用してこのプラットフォームを拡張します。Agentforce Operations（旧Agentforce Supply Chain）は、これらの機能を運用プロセスと製造プロセスの特定の要求に適用します。 ## ガイドの概要 このガイドでは、オーケストレーション密度フレームワークと、この商品ランドスケープ全体で情報に基づいた意思決定を行うためのガイドラインを紹介します。このフレームワークは、アーキテクトが Salesforce Platform のインテリジェントな自動化の使用事例に適した密度レベルを使用して適切なツールとパターンを選択するための反復可能なアプローチを提供します。 ## 範囲内の商品 | 商品 | 説明 | | :-------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Agentforce | [Agentforce](https://help.salesforce.com/s/articleView?id=ai.generative_ai.htm&type=5)は、AIエージェントを構築および導入するためのSalesforceのプラットフォームです。Atlasエンジンを使用して、ApexとData 360で動的にグラウンディングされたリアルタイムのアクションをトリガーします。 | | エージェントスクリプト | [エージェントスクリプト](https://developer.salesforce.com/docs/ai/agentforce/guide/agent-script.html)は、エージェントのワークフロー、ビジネスルール、会話ロジックを定義するために Agentforce Builder で使用される宣言型ドメイン固有言語 (DSL) です。 | | Agentforceグリッド | [Agentforce Grid](https://help.salesforce.com/s/articleView?id=ai.agentforce_grid.htm&type=5)は、AIワークフローを大規模に迅速に設計して運用するためのAIネイティブのノーコード スプレッドシートのようなインターフェイスです。 | | Agentforce Operations | [Agentforce Operations](https://help.salesforce.com/s/articleView?id=platform.automate_agentforce_supply_chain.htm&type=5)(旧称Agentforceサプライ チェーン)は、バックオフィス ビジネス プロセスを合理化および自動化するために設計された、AI搭載のコラボレーション ワークフロー管理オーケストレーション プラットフォームです。 | | MuleSoft | [MuleSoft](/docs/architect/ja-jp/fundamentals/guide/mulesoft-architecting-agentic-enterprise.html)は、エンタープライズ統合とエージェントによるガバナンスのための包括的で統合されたオープンなプラットフォームです。API 主導の接続と MuleSoft Agent Fabric および Agent Broker により、企業全体のエージェントワークフローを接続するインテグレーションファブリック、ガバナンスレイヤー、およびクロスシステムオーケストレーション基盤として機能します。 | | フローおよび Apex | [Salesforce Flow](https://help.salesforce.com/s/articleView?language=en_US&id=platform.automate_about.htm&type=5)は、コードなしで複雑なビジネスプロセスを視覚的に構築するための強力なポイント & クリック自動化ツールです。[Salesforce Apex](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_intro_what_is_apex.htm) は、Java に似た Salesforce Platform 専用のオブジェクト指向プログラミング言語です。カスタムビジネスロジックの構築、プロセスの自動化、宣言型ツール以外のコア CRM 機能の拡張に使用されます。 | ## ポイント Agentforce は、ルールベースの自動化から推論ベースのワークフローへの Salesforce Platform での作業の根本的な移行を表します。その可能性を引き出すには、アーキテクトはエージェントの配置、構成、オーケストレーションについて、十分な情報に基づいて慎重に判断する必要があります。次の原則は、エージェント型意思決定に対する反復可能なガイドラインを提供します。 - **適切なタスクに適切なツールを使用します。**実行パス、モダリティの組み合わせ、目標の複雑さに基づいてオーケストレーション密度を使用し、最適なソリューションを決定します。 - ルール ベースの確定的作業には、フローとApexを使用した**従来の自動化**を使用します。ここでは、一連のルールで結果の範囲を完全に設定して定義できます。従来の自動化では静的な実行パスになるため、予測可能で反復可能な結果が保証され、監査可能性にとって重要です。厳格なコンプライアンスと法令遵守を必要とするタスクには、従来の自動化を選択します。 - **Agentforce Grid**は、オーケストレーションの複雑さが低~中程度の一括推測の使用事例に使用します。このパターンでは、単一ターンの生成推論を使用して大量の CRM レコードのデータを分類、スコアリング、または集計し、即座に監査可能な高スループットの実行を保証します。 - **Agentforce と Agent Script** は、目的の結果がわかっているが、設計時に正確な実行パスを指定できない、自由回答型の目標を持つタスクに使用します。このパターンをガイド付き決定論による推論が必要な要件に適用して、予測可能で追跡可能な結果を実現します。 - **Agentforce Operationsを**使用して、サプライチェーン ワークフローのAI対応管理でコラボレーション ビジネス プロセスを合理化および自動化します。 - **オーケストレーション密度の低い使用事例へのエージェント ワークフローの適用は避けてください。**機能要件と非機能要件について、従来の自動化とエージェント自動化のトレードオフを評価します。従来の自動化では、使用事例に必要な拡張性、信頼性、パフォーマンスを実現できます。 - Agentforceと従来の自動化をフローおよびApexと組み合わせたエージェント自動化ハイブリッド アプローチを**採用する**のは、エージェント型または従来の自動化を単独で使用する場合よりも、この相乗効果の方が価値が高い場合です。 ## 決定ポイント Salesforce sObject は、従来、レコード自動化の主要なエントリポイントでした。insert、update、delete などのデータ操作言語 (DML) イベントの直後にルールに基づいてロジックが実行されます。効率的な[レコード トリガー自動化](/docs/architect/ja-jp/decision-guides/guide/record-triggered.html)のためのツールを決定するために、自動化の量、レコード量、依存関係の無秩序な増加を考慮して、システムの複雑さを測定する手段として[自動化密度](/docs/architect/ja-jp/decision-guides/guide/record-triggered#automation-density.html)を導入しました。従来の自動化では、データを構造化され、スキーマに準拠し、ルールベースの構造に取り込むには、広範な事前作業が必要です。 エージェント型オートメーションは、ユーザーインテントや非構造化データを入力として従来のオートメーションをアップグレードし、推論を適用することで目的の結果を達成します。アーキテクトは、マルチモーダル非構造化データの確率的推論を活用するタイミングと、予測できない結果のリスクを軽減するためにガイド付き確定的ワークフローを適用するタイミングを決定する必要があります。 要件がルールベースのステップの実行から結果に対する推論に移行する場合、アーキテクトは提案されたソリューションの推論の深さと目標の複雑さを評価するための標準化されたフレームワークが必要です。 ### オーケストレーション密度 オーケストレーション密度は、エージェントワークフロー内の複雑さの基準です。オーケストレーション密度は、実行パス、ゴールの複雑さ、モダリティの組み合わせの 3 つの要素によって決まります。自動化密度はシステムのルールと量の物理的な複雑さを測定しますが、オーケストレーション密度は目標に向けたエージェントのパスの推論の複雑さを測定します。複合オーケストレーション密度を使用して設計要件を評価し、アーキテクチャ標準にマップします。 - **Execution Path** (実行パス): ワークフローの範囲を完全に設定し、設計時に指定できる程度。完全に指定されたワークフローとは、ワークフローですべてのブランチと結果が定義され、実行パスが事前に決定されていることを意味します。指定できないワークフローには、コンテキストデータと命令に対する推論によって実行時に出現する可能性があるパスがあります。 - **目標の複雑**度: ワークフローで実行時に解決する必要がある個別の結果、決定ポイント、パスのバリエーションの数。複雑度の低いワークフローは、1つの限定されたタスクを事前に決められた結果で処理しますが、複雑度の高い目標は、設計時に予測できないエッジケースや競合する目標を含む複数のフェーズにまたがります。 - **モダリティの組み合わせ**: ワークフローで処理する必要がある入力タイプと、ワークフローで生成する必要がある出力フォームの範囲。モダリティが低い場合、標準CRMフィールドを読み取り、レコードの更新を行います。中モダリティでは、構造化された CRM 項目と静的な非構造化データ (メール本文やケーストランスクリプトなど) を組み合わせて使用し、レコードを更新します。高モダリティミックスでは、ライブオーディオやテレメトリーなどの動的なリアルタイムストリームが使用され、複数の外部システム間でマルチモダリティ出力が生成されます。 ![実行パス、目標の複雑さ、モダリティの組み合わせの軸を示すオーケストレーション密度フレームワークの図](https://architect.salesforce.com/ns-assets/determining-agentic-automation-orchestration-density-framework.png) ### 要素シーケンス 適切なオーケストレーション密度レベルを判断するには、実行パス、目標の複雑さ、モダリティの組み合わせを順次評価する必要があります。最初に実行パスを調べます。パスを完全に指定できる場合は、従来の自動化から開始します。エージェント型ソリューションを使用して、推論要件なしで確定的パスをオーケストレーションおよび実行するのはアンチパターンです。エージェントの無秩序な増加 (AI エージェントの過剰な増加、未管理) やエージェントのスロップ (AI が生成する低品質で不要な出力) を招き、価値の回収率が低下します。 部分的なパスや指定できないパスについては、引き続き目標の複雑さを評価します。目標の複雑さは明確に定義されているが、パス上の特定のノードで確率的評価が必要な場合は、特定のローカライズされたニーズを満たすためにフローまたは Apex からエージェントをコールすることを検討してください。代わりに、実行パスのステップで大量のレコード セットにわたって1つ以上のAI主導の要件が必要な場合は、Agentforce Gridを検討してください。グリッドでは、複数の AI またはエージェント列を介した複数ステップのシートベースのワークフローがサポートされます。これは、行指向の一括実行に最適です。このアプローチにより、パスが事前に定義できない場合にのみ確率的推論を呼び出すことで、ワークフローのパフォーマンスと監査性が維持されます。 競合するディメンション(不正の検出、ポリシーの遵守、顧客満足度の向上に伴う保険金支払の決定など)や指定できない実行パスによって目標の複雑さが増しているため、自動化のガイド付き確定性のためにAgentforceとAgent Scriptを検討してください。Salesforce とサードパーティシステムを使用する企業間ユースケースでは、MuleSoft Fabric と Agent Broker を使用します。 最後に、モダリティの組み合わせを評価して、マルチモダリティ接続や特殊なインテグレーションなど、必要な技術力を特定します。モダリティミックスは、密度の計算機能ではなく機能セレクターとして機能します。基本的なオーケストレーションロジックを変更することなく、ソリューションの入力と出力の形状を処理するために必要なインフラストラクチャを決定するのに役立ちます。 ### 密度選択マトリックス このマトリックスを使用して、エージェントの自動化のアーキテクチャ標準を決定します。自動化の問題を解決するアプローチを選択して、従来の自動化とエージェントによる自動化のバランスを取ります。 - **従来の自動化(**オーケストレーション密度が低い):レコードの変更によってプロセスがトリガーされ、データが構造化され、ロジックがルール ベースで事前に決定され、結果を予測できる必要がある場合(標準価格の計算や自動タスク作成など)は、従来の自動化を使用します。 - **Agentforce Grid(**低~中オーケストレーション密度):既存のレコード全体の一括 AI タスクを処理する必要がある場合に Agentforce Grid を使用します(たとえば、このリストの各取引先の最近の 50 件のケースを集計し、センチメント スコアを計算して、ケース フィールドにスコアを保持します)。 - **ハイブリッド オーケストレーション(**高次拡張自動化):複雑なエンド ツー エンドのビジネス プロセス(請求処理やオンボーディングなど)を自動化するときに、ハイブリッド オーケストレーションを使用します。このプロセスでは、AIの計画機能が必要ですが、フローとApexのトランザクションの整合性が必要です。 - **Agentforce Agent Script（高インテント複雑度）：** エントリ ポイント（チャット、電子メール、音声など）が構造化されておらず、解決に会話またはあいまいなユーザ要求を処理する機能が必要な場合にエージェント スクリプトを使用します。 | 密度レベル | Execution Path (実行パス) | 目標の複雑さ | Modality Mix (モダリティミックス) | アーキテクチャ標準 | | :---------------- | :----------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Low (低)** | 完全に指定可能 | **低：** 結果が事前定義された単一のタスク。 | **単一モダリティ:** 構造化された Salesforce オブジェクトレコードの読み取りと書き込みを行います。 | トリガーによるオートメーション。ユースケースに1つ以上の推論タスクがある場合、ワークフローでエージェントアクションを使用します。 | | **低 - 中** | 完全または部分的に指定可能 | **低:** 結果が事前定義された一連のステップ。 | **混合モーダル:** 入力または出力に構造化データと非構造化データが混在している可能性があります。 | Agentforce Grid Batch Inferences を使用して、エージェントアクションで既存のレコードの一括タスクを実行します。 | | **Medium (中)** | 完全または部分的に指定できます。実行パスは事前定義されていますが、中間ステップには推論が必要です。 | **中：** 結果が可変なApexまたはFlowベースの一連のステップ。 | **混合モーダル:** 入力または出力には、少量の構造化データと非構造化データが混在している可能性があります。 | ハイブリッド(Agentforce + Apex/フロー): 高密度の推論と計画には Agentforce、ガイド付き決定論には Agent Script、オーケストレーションには Apex/Flow を使用します。 | | **High (高)** | 部分的または指定不可。ゴールは事前定義されていますが、中間ステップにはランタイムコンテキストとユーザーインテントが必要です。 | **高:** 推論ニーズが高い複数の競合目標には、確定的な結果が必要です。 | **混合モーダル:** 入力または出力には、大量の構造化データと非構造化データがリアルタイムで混在している可能性があります。 | エージェントスクリプトを使用して、確定的支配と推論のバランスを取ります。サードパーティ MCP には MuleSoft エージェントファブリックを使用し、複雑なマルチエージェントコラボレーションには A2A を使用します。 | ## 商品比較 | 機能 | 従来の自動化(フロー/Apex) | Agentforceグリッド | Agentforce | Agentforce とエージェントスクリプト | | ------------------------------ | ------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | **ロジックタイプと決定性** | **確定的:** 固定の if-then-else ロジックを使用します。実行パスは、レコードの状態に基づいて 100% 予測可能です。 | **混在:**構造化されたステップで確定的ですが、個々のAIステップは確率的になる可能性があります。 | **確率的:** 複数ターンの推論を使用して、目標への最適なパスを決定します。 | **Guided Determinism:** 推論を使用してパスを計画し、確定的ノードパスでの実行を許可します。 | | **デリバリー速度** | **推奨 (フロー):** ビジュアルツールを使用すると、コードなしでレコードトリガーロジックをすばやく作成できます。 | 反復的なAI自動化**に推奨:**新しいフローを構築することなく、既存のレコード セット全体にAIロジックを適用する最速の方法。 | **推奨:**特定のドメインまたは問題に対するサブエージェント(以前のトピック)、手順、スキルの対応付けの設定。 | **推奨：**状態ベースのグラフとエッジ ロジックの高度なマッピング用。 | | **入力モダリティ** | **構造化のみ推奨:** CRM フィールドと関連レコードコレクションに制限されます。 | **半構造化に推奨：**レコードフィールドからの一括テキスト（説明、トランスクリプト）を処理します。 | **マルチモーダルに推奨**: 自然言語、音声、視覚 (非構造化データ) を処理します。 | **高密度に推奨:** マルチモーダル入力をリアルタイムのシステム状態データと合成します。 | | **推論深度 (計画)** | 使用**不可:** ロジックが不可欠です。動的にステップを「考える」ことや計画することはできません。ただし、データをエージェントに送信できます。 | **低:**レコード セット全体に適用される1ステップの推測(バッチAI)。 | **中/高:** 推論ループ (Reason-Act-Observe) を使用して複雑なインテントを解決します。 | **管理:** 推論は、ビジネス状態の定義済みグラフ内を移動することに制限されます。 | | **モジュール性と再利用性** | **推奨：**サブフローおよび Apex クラスを介してデフォルトでモジュール化されます。 | **制限あり:** ロジックは通常、特定のグリッド行に関連付けられます。列の設定とテンプレート化されたワークフローは、行セット全体で再利用できます。 | **使用可能:**スキル (フロー/Apex) は、異なるサブエージェント (以前のトピック) および接続されたエージェントで再利用されます。 | **推奨：**エージェントグラフのノードは、再利用可能な個別の機能単位です。 | | **トランザクションおよび DML 制御** | **推奨(Apex):**セーブポイント、ロールバック、一括処理を完全に制御します。 | **使用可能:** 各行は独立して処理されるため、実行範囲はレコードごとです。 | **制限あり:** アクションは、セッション内の個別の分離されたステップとして実行されます。 | **推奨:** フロー/Apex ノードを使用して、すべての DML の確定的アンカーとして機能します。エージェント間の分散トランザクション制御のサポートは制限されています。 | | **曖昧性の処理** | 使用**不可:** 定義済みのパスが必要です。予期しない入力は、失敗または静的エラーにつながります。 | **制限あり:**出力品質はプロンプトのグラウンディングによって異なります。ワークフローは対話形式で明確化を求めることはできません。 | **推奨:**質問するか、代替スキルを選択して「不明」状態を処理します。 | **使用可能:** 「代替ノード」を使用して、推論の失敗またはプロセスのタイムアウトを管理します。 | | **可視性とガバナンス** | **推奨:** フロートリガーエクスプローラーでは、すべてのレコードトリガーロジックが視覚的に表示されます。 | **使用可能:** グリッドベースの UI により、行レベルの結果が明確に表示され、出力の監査機能がサポートされます。 | **使用可能:** 監視ログにより、エージェントがどのように意思決定を行ったかを透過的に確認できます。 | **Requires Expertise:** グラフトラバーサルとLLM推論の両方のモニタリングが必要です。 | | **パフォーマンスと拡張性** | **推奨** 高ボリュームの同期レコード処理に最適化されています。 | **推奨**:大量のデータにわたって一括AIタスクを効率的に処理します。 | **遅延に敏感** 推測時間に依存し、高密度の一括更新には適しません。 | **モデレート** 複雑な長期のタスクに適していますが、オーバーヘッドが大きくなります。 | ## 使用事例 次の表に、さまざまな使用事例に最適な一般的な推奨事項を示します。 | 使用事例 | 説明 | ベストフィット | 根拠 | | ----------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **レコード処理** | 構造化された Salesforce オブジェクトの DML イベントによってトリガーされる自動化。設計時にすべてのブランチと結果を完全に定義できます。 | レコードトリガーフローを使用します。これは従来の低密度のオートメーションです。 | オーケストレーション密度が低い。単一モダリティ (構造化された CRM 項目) と、予測可能で監査可能な実行パスが含まれる単一の目標。 | | **複雑なロジックを使用したトランザクション制御** | 大量のレコードに対するセーブポイント、ロールバック、部分的なコミット、一括安全なデータ操作を必要とするオートメーション。 | Apexは、従来の低密度の確定的オートメーションに使用します。 | オーケストレーション密度が低い。Apex は、トランザクションの整合性、コストのかかる計算の重複排除、プラットフォームレベルのキャッシュを完全に制御します。この機能はフローでは使用できません。 | | **構造化されたプロセス内のロジックがやや複雑** | プロセス全体がルールベースだが、個々のステップで宣言型機能を超える計算やデータ操作が必要になる自動化。 | 低密度の確定的ロジックには、呼び出し可能な Apex を使用したフローを使用します。 | オーケストレーション密度が低い。フローはオーケストレーション レイヤーとして機能します。呼び出し可能なApexは、再利用可能な一括安全なコンポーネントとして高複雑度操作をカプセル化します。 | | **スケジュール済み処理と時間依存の処理** | レコードイベントに対して動的に計算された将来の日付で実行する必要があるオートメーション。 | 低密度の確定的処理には従来の自動化 (レコードトリガーフロー) を使用します。 | オーケストレーション密度が低い。[フローのスケジュール](https://help.salesforce.com/s/articleView?id=platform.flow_concepts_trigger_scheduled_path.htm&type=5)済みパスでは、レコード データが変更された場合に、スケジュール、キャンセル、再スケジュールが自動的に実行されます。これは、Apex トリガーではネイティブに使用できません。 | | **一括レコード推論** | 1 つの AI 推論ステップを多数の既存のレコードセットに均一に適用して、分類、概要、スコアを生成します。 | Agentforce Grid は、一括推論および大規模な反復的エージェント型機能に使用します。 | オーケストレーション密度が中程度。大規模な単一モダリティによる一括推論：エージェントは構造化されたレコードフィールドを読み取り、各レコードに均一な出力を書き戻します。目標の複雑度は低く、反復する1種類の推論パターンが用いられます。 | | **非構造化入力解決** | 推論によって解釈、分類、解決する必要がある自然言語の要求、メール、会話が入り口となる自動化。 | Agentforce は、中密度のインテント駆動型の非構造化入力解決に使用します。 | オーケストレーション密度が中程度。混合モダリティ：エージェントは非構造化された会話入力をコンシュームし、テキスト応答または構造化レコード更新を生成します。この目標には、境界のある結果セット全体でユーザーのインテントを解決する必要があります。 | | **確率的プロセス内のロジックがやや複雑** | プロセス全体がルールベースだが、個々のステップにはサマリーや RAG 取得などの AI 機能が必要な自動化。 | AI機能を必要とする低密度の確定的プロセスには、呼び出し可能なApexおよびプロンプトテンプレートを使用したフローを利用します。 | オーケストレーション密度が中程度。フローはオーケストレーション レイヤーとして機能しますが、[プロンプト テンプレート](https://developer.salesforce.com/blogs/2024/04/invoke-prompt-templates-from-flow-apex-or-the-rest-api)、[Agentforce サービスエージェント、および](https://help.salesforce.com/s/articleView?id=ai.agent_custom_invocable_action_flow_apex.htm&type=5) Agentforce 従業員エージェントは呼び出し可能なアクションとして表示されます。 | | **ガイド付きプロセスオーケストレーション** | 1 つのアクションの完了で追加のアクションがトリガーされる複数ステップのワークフローにまたがる自動化 | ガイド付きプロセスオーケストレーションを必要とする高密度の特定されていない実行パスには、[アクション付きエージェントスクリプト](https://developer.salesforce.com/sample-apps/agent-script-recipes/action-configuration/action-chaining)を使用します。 | 高いオーケストレーション密度 - 入力と出力の混合モダリティ。設計時に完全には予測できない競合の結果とエッジケース。エージェントスクリプトにはガイド付き決定論が用意されています。 | | **クロスシステムプロセスオーケストレーション** | 複数のバックエンドシステムにまたがり、一つのシステムがエンドツーエンドのフローを所有していないビジネスプロセスを調整する自動化。 | エージェントブローカーで MuleSoft Process API を使用して、中規模から高密度のクロスシステムプロセスオーケストレーションを行います。 | 高いオーケストレーション密度 - プロセス API は複雑な複数ステップのビジネスロジックをカプセル化するため、エージェントは注文処理や在庫確認などの操作の背後にあるオーケストレーションを理解する必要はありません。[エージェントブローカー](https://www.mulesoft.com/ai/agent-broker)は、1 つの自然言語目標から必要なエージェントとツールを動的に順序付けして呼び出します。 | | **バックエンドシステムの抽象化** | エージェントがネイティブの Agentforce 接続性のないレガシー システム、データベース、またはサードパーティの SaaS プラットフォームと連携する必要があるオーケストレーション。 | MCP コネクタで MuleSoft を使用して、レガシーシステムをラップし、モデルコンテキストを提供します。 | オーケストレーション密度が中程度。システム API は、記録システムへの安全で抽象化されたインターフェースを提供し、エージェントのワークフローをバックエンドの複雑さから分離します。MCP コネクタは、MuleSoft アプリケーションを MCP 準拠のサーバーに変換し、すぐに検出および呼び出しできるようにします。 | | **大量のドキュメント処理と例外処理** | 受信構造化ドキュメントと半構造化ドキュメントを既存のレコードに対して大規模に読み取り、解釈し、照合する自動化。適切な手動操作で、差異、部分一致、例外を処理します。 | Agentforce Operationsは、中密度のインテント駆動による大量のドキュメント処理に使用します。 | 中程度のオーケストレーション密度と半構造化された入力モダリティ。各ドキュメントに適用されるマッチングルール、例外パス、承認しきい値によって決まる目標の複雑さ。均一の単一ターン推論ではなく、レコードごとの推論が必要です。 | | **ベンダー間のマルチエージェントオーケストレーション** | 自動化には、異なるプラットフォームまたはベンダーで構築された専門エージェント間のコラボレーションが必要です。 | MuleSoft を A2A コネクタとエージェントファブリックと共に使用して、異なるシステムでマルチエージェントオーケストレーションを行います。 | オーケストレーション密度が中～高。A2A コネクタにより、各エージェントが作成またはホストされている場所に関係なく、エンタープライズクラスのガバナンスと信頼性を備えたピアツーピアのマルチエージェントワークフローが可能になります。 | | **非構造化ドキュメントからワークフローへの変換** | 非構造化ソース (SOP、サプライヤールールドキュメント、またはプロセス図) で定義された運用プロセスを手動コーディングなしで実行可能なエージェントワークフローに変換する必要がある自動化。 | Agentforce Operationsを使用して、高密度で発生する非構造化ドキュメントをワークフローに変換します。 | 高密度かつ、入力のモダリティミックスが高い状態。PDF、Word ドキュメント、画像ベースの図を取り込みます。取り込まれたプロセスの範囲と分岐によって決まる目標の複雑さ。実行パスは設計時に指定できません。 | | **マルチパーティオーケストレーション** | 外部関係者の調整されたオンボーディング全体にわたる自動化 - 多くの同時オンボーディングトラックで必要なデータの収集、コンプライアンスの検証、承認の管理、記録システムの更新を行います。 | Agentforce Operationsを使用して、中密度から高密度の、インテント駆動型および新興のマルチパーティオーケストレーションを実現します。 | オンボーディングを完了するには、複数の相互連動検証および承認ステップを順次解決する必要があります。モダリティミックスには、構造化レコード、非構造化ドキュメント、外部関係者とのコミュニケーションが含まれます。 | | **予測アセット介入** | 予測エンジンがリアルタイムのテレメトリを取得して差し迫った障害状態を特定し、調整された複数ステップのバックオフィス応答をトリガーする自動化。 | Agentforce OperationsとAgentforce for Manufacturingを使用して、高密度の予測資産介入を実現します。 | Data Cloud では、高モダリティの IoT テレメトリーと異常検知が処理されます。Agentforce Operationsは次に、フィールドサービスレコード、在庫データ、顧客とのコミュニケーションを管理する中程度のモダリティのバックオフィスワークフローをオーケストレーションし、プロセスをエンドツーエンドで解決します。 | | **大規模なサプライヤーベースのコミュニケーション管理** | 注文確認、配送日の変更、例外通知など、大規模なサプライヤーベース全体での継続的な構造化および半構造化されたコミュニケーションの管理を自動化します。 | 中密度のサプライヤーコミュニケーション管理を実現するために、Agentforce Operations for Batch Inferencesを使用します。 | サプライヤ間でコミュニケーションが統一されている場合、バッチ処理にAgentforce グリッドを使用します。回答にサプライヤーごとの文脈に応じた推論が必要な場合、Agentforce Operationsを使用して中密度にエスカレーションします。 | | **Lead Management (高速、インテリジェントなルーティング)** | リアルタイムのマーケティング応答を取り込み、AI スコアリングと Data Cloud 強化を使用して評価し、フローを使用して高品質のリードを適切な営業チームにインテリジェントに割り当ててルーティングする自動化。 | 従来の自動化（フロー）+ Data Cloud と AI を使用して、中密度の高速かつインテリジェントなリードルーティングを実現します。 | 高速性 (リードまでの所要時間 < 1 分) と、AI リードスコアリング、ジョブレベル、活動履歴に基づく複雑なデータ駆動型ルーティングが必要です。迅速で確定的な割り当てロジックにフローを使用します。これは、リードの評価と強化のために確率的 AI と Data Cloud によって強化されます。 | | **リードナーチャリング** | 商談の準備ができるまで、スコアの低いリードを育成します。 | Lead Nurturing Agent を使用して、低品質のリードをターゲティングし、中密度から高密度の自動化を実現します。 | リードデータと顧客の成功事例に基づいてパーソナライズされたマルチタッチメールを送信します。メール応答を処理し、ハンドオフにはフローを使用します。 | | **受信リード評価** | スコアの高い受信リードを自律的に評価して育成します。 | Lead Nurturing Agent を使用して、リードを評価してエンゲージします。 | マルチタッチメール送信、ミーティングの予約、商品 Q&A、異議申し立ての処理を実行します。割り当てられたリード所有者を介してメールを送信する「営業担当として送信」モードで動作します。 | ## 使用事例のマッピング ![オーケストレーション密度レベルのさまざまな自動化シナリオを示す使用事例の対応付け図](https://architect.salesforce.com/ns-assets/determining-agentic-automation-use-case-mapping.png) ## 機能以外の考慮事項 **遅延** 同期レコードトリガーフローは、プラットフォームトランザクション内で実行され、ミリ秒で完了します。Agentforce 推測時間は Atlas Reasoning Engine に依存し、推論の深さとモダリティの複雑さに応じて拡張されます。Agentforce は、遅延が主な制約となる大量の同期レコード処理には適していません。 **Cost (コスト)** エージェント型ワークフローの推論コストは、結果のビジネス価値に照らして正当化する必要があります。確定的パスが存在する大量の低オーケストレーション密度のタスクの場合、従来の自動化やAgentforce Gridの方が、エンドツーエンドのエージェント ワークフローよりも経済的である可能性があります。明示的な最大再試行制限とブレーカーを使用して、設計が適切な再試行パターンに対応していることを確認します。このガードレールにより、一括処理に関連する累積的なコスト超過リスクが制限されます。 **ガバナ制限** 非同期実行の 1 日のプラットフォーム制限に対して大量のエージェント型ワークフローを評価します。Agentforce Grid の一括処理は、標準のプラットフォームトランザクション制限に従います。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?_ga=2.244979463.387753096.1774889755-1655953164.1772207150)の両方を適用するため、1日あたりのDML操作の合計数を考慮してください。 **監査可能性とコンプライアンス** 従来の自動化では、フロートリガーエクスプローラーと Apex ログで完全に監査可能な実行履歴が生成されます。Agentforce ベースのエンドツーエンドまたはハイブリッドのパターンでは、エージェントの意思決定を透過的にする理由ログが生成されますが、解釈には専門知識が必要です。エージェントスクリプトを介したガイド付き決定論は、完全な実行監査可能性がコンプライアンス要件である規制対象の業界に推奨されるパターンです。 **エスカレーション** 高密度で運用されるエージェント型ワークフローでは、金融取引、規制申請、サプライヤーコミットメントなど、元に戻せない結果をもたらすアクションに対して明示的な人間の承認またはエスカレーションゲートを組み込む必要があります。エージェントスクリプト条件付き制御は、エージェント型ワークフロー内でこれらのゲートを決定論的に適用するメカニズムを提供します。 ## 関連するベストプラクティス **オーケストレーション設計ではシンプルさを優先します。**目標を達成できる最小限のオーケストレーションレベルで開始し、実際の負荷で検証して反復します。チェーン内のエージェント、ハンドオフ、または連動関係が追加されるたびに、一貫性のない動作が発生する可能性がある新しいサーフェスが導入されます。 指定可能な実行パスで、推論が必要なノードでエージェントの埋め込みを開始します。Agentforce でエージェントを作成するためのベストプラクティスに従います。多数のサブエージェント (以前は「トピック」) を詰め込まないようにし、手順を膨らませないようにします。自動化の使用事例でリリースされたエージェントは、唯一のインターフェースではないため、無駄を省くことができます。チェーン用の適切なプリミティブを選択します。オーケストレーション (委任) パターンでは、実行シーケンスをより厳密に制御でき、サブタスクをスペシャリストに委任できます。振付 (ハンドオフ) パターンは避けてください。ハンドオフ設計を実装する必要がある場合は、ローカルの目的ではなくグローバルに最適化できるように、目標、コンテキスト、状態を受信エージェントに提供します。 **アクションやツール**の無秩序な増加を回避します。アクションはエージェントの推論が実現される場所で、その設計によって信頼性の高い結果または失敗が生成されるかどうかが決まります。すべてのアクションは、AI エージェントが会話の次の展開を計画するために使用できる構造化された観察可能な応答を返す必要があります。 同じタスクを実行するために複数のアクション (および異なる出力構造) があると、エージェントが作業に適したツールを判断または選択する能力が低下します。エージェントが微妙な違いを見落としてしまう可能性があります。アクション定義が重複すると、誤った分類のリスクがあります。アクションライブラリが監査され、バージョン管理され、サブエージェント (旧称トピック) 範囲に準拠していることを確認します。 **観察可能な目標を定義します。**目標を単なる手順ではなく、観察可能な結果として定義します。漠然とした目標がエージェントのドリフトを招く。指定可能な実行パスを追加します。ハイブリッドな推論でエージェントグラフを使用して、明示的な状態を持つグラフノードとしてゴールをモデル化します。ランタイムはワークフローでのエージェントの現在の位置を追跡し、接線入力後に復元します。コンテキストウィンドウで追加情報を受け取ったときに目標を失うことはありません。 **テストと評価**。堅牢なテストおよび評価フレームワークを実装して、確率的ノードの推論とエージェントによる自動化の出力を検証します。期待される結果パスに対して実行パスを検証し、モデルが正しい結果に到達することを確認します。実行ステップで結果をアサートすることで、エージェントが成功を誤って報告したり、無限ループや回復不能なループに入ったりするサイレント失敗を回避します。[セッション追跡を](https://help.salesforce.com/s/articleView?id=ai.generative_ai_session_trace_about.htm&type=5)使用して、ターンバイターンのインタラクション、推論エンジンの実行、アクション、プロンプトとゲートウェイの入力/出力、エラーメッセージ、最終応答を検査します。 ## リソース
Agentforce 従来の自動化 Integration の制限と考慮事項」
**著者について** Arvind Palaniswamy は、Office of the Chief Architect, Well-Architected Team のソフトウェアエンジニアリングアーキテクトです。彼は第一原理を使って複雑なシステムを最もシンプルな形で組み立てたいのです数十年の経験とMS/MBA(ケロッグ)教育を通じてエンジニアリング、オペレーション、ビジネスを理解しています。 # フォームの作成 Agentforce 360 Platform でフォームを作成するオプションは複数あり、それらはローコードからプロコードまでのアプローチに及びます。この連続性の一方の端では、Lightning アプリケーションビルダーの動的フォームと Flow Builder の画面フローをローコードソリューションに使用できます。一方、プロコード ソリューションにはLWC(Lightning Webコンポーネント)フレームワークが使用されます。この連続性の中で、LWC によって拡張された画面フローと OmniStudio を使用して作成された顧客向けフォームを使用して、さまざまな方法でツールをブレンドできます。 ## ガイドの概要 このガイドでは、UI ソリューションのフォームの作成に関する決定フレームワークとガイダンスについて説明します。具体的には、多数のランタイムと機能以外の決定ポイントを使用して、特定の使用事例に最適なテクノロジーを適切に選択します。 ## ポイント - **Lightning ページの作成/編集/表示レイアウトを作成する場合は、動的フォームを使用します。**今後は、_Lightning アプリケーションビルダー_で_動的フォーム_を使用してレコード詳細ページを設定することをお勧めします。 - **1 つのオブジェクトのフォームを作成、作成、編集する必要がある場合は、_Lightning ページ_と_動的フォーム_を使用します。**これは、Agentforce 360 プラットフォームでフォームを作成する最も簡単な方法です。また、追加機能 (項目表示制御など) も提供されます。 - **複数ページのフォームまたはウィザードを作成する場合、厳格な UX 要件やブランド要件がなければ、画面フローを使用します。**画面フローには、複数のフォームを調整するための線形ナビゲーションフレームワークが用意されています。LWC を使用して、フォーム間を移動する独自のフレームワークを構築できますが、フォームの状態ではなくフォームそのものに焦点を絞ることができるように、フローに任せることをお勧めします。 - **フォームをサポートする追加のロジックまたはアクションが必要な場合は、画面フロー、OmniStudio、または LWC を使用します。**これらの各ツールは、1 つのレコードの作成や編集以外にも拡張できるようにすることで、さまざまな方法でソリューションを強化します。この場合、「_さらに_」という用語は、高度なロジック (分岐や反復など)、または外部システムとの統合、メールの送信、ユーザーのモバイルアプリケーションへの通知の転送などのアクションを指します。 - **高度なUX要件がある場合、またはUI表示以外の機能を動的に管理する必要がある場合は、LWCまたはOmniScriptを使用します。**テーマ設定と列ベースのレイアウトを使用して満たすことができる要件については、ローコードビルダーで直接フォームを作成できます。ただし、フォームのスタイルを詳細に制御するには、LWC の柔軟性が必要です。Industries のお客様で、ピクセル単位の完璧なブランド設定が必要な場合や、複雑な階層データを使用している場合は、OmniStudio を使用します。OmniStudio を使用すると、複雑なビジネスロジックとデータ変換を処理できるコンシューマーグレードのフォームを作成できます。 - **テスト自動化をリリースする必要がある場合は、LWC を使用します。**どの LWC を埋め込むかに関係なく、LWC の単体テストを作成できます。これにより、複数のレコードを使用した一括テストやネガティブテストなど、より堅牢なテスト戦略を作成できます。 - **「いずれか/または」の決定に縛られません。**複数のオプションを組み合わせて、使用事例に最適なソリューションを実現できます (たとえば、フローの組み込みナビゲーションシステムと LWC が提供する完全なスタイル設定の柔軟性が必要な場合、それらを組み合わせて使用できます)。 ## 範囲内のツール フォーム環境を実装および拡張するためによく使用されるツールを次に示します。 ### ツールの説明
動的フォーム Salesforce Lightningアプリケーションビルダーの動的フォームでは、モノリシックなレコード詳細コンポーネントが個別の設定可能な項目とセクションに分解されます。この機能により、管理者は項目を任意の場所に配置し、表示ルールを使用してユーザープロファイル、デバイス、データに基づいてコンポーネントを表示または非表示にすることで、柔軟でパフォーマンスの高いページを作成できます。これにより、ページが乱雑になるのを防ぐことができます。
画面フロー Salesforce Screen Flow は、Flow Builder 内の対話型自動化ツールで、カスタマイズされたステップごとのビジネスプロセスを進むためにユーザー入力が必要です。自動化されたバックグラウンド フローとは異なり、画面フローには、コードを記述することなく、Lightningページ、ボタン、カスタム アプリケーションを使用してデータの収集、情報の表示、アクションの実行を行うためのウィザードのようなユーザー インターフェイスが用意されています。
OmniStudio Salesforce OmniStudioは、ガイド付きの業界固有のデジタル エクスペリエンスと複雑なビジネス プロセスを迅速に構築するために設計されたローコードのツール スイートです。開発者は、FlexCardやOmniScriptなどのドラッグアンドドロップ・コンポーネントを使用して、ピクセル単位のユーザー・インタフェース（ガイド付きワークフローや動的ダッシュボードなど）を作成できます。OmniStudio では、宣言的に LWC を作成できます。
Lightning Web コンポーネント Salesforce Lightning Web コンポーネントは、HTML、CSS、最新の JavaScript を使用して構築された軽量なカスタム HTML 要素で、優れた Salesforce UI パフォーマンスを実現するためにブラウザーでネイティブに動作するように設計されています。開発者は、Auraコンポーネントと共存するカスタムユーザーインターフェースを作成できるため、業界標準と詳細なコンポーネントエコシステムを通じて開発を促進できます。
### ツールスキルセットとライセンス要件 次の表に、Salesforce でフォームを作成するために使用できるツールと、必要なスキルおよびライセンスの考慮事項を示します。 **注意:**各ツールでサポートされている特定の機能、クリック ベースのツールとコード ベースのツールのどちらを選択するか、および組み合わせるタイミングについては、後のセクションで詳しく説明します。
設定 その他のライセンス要件
動的フォーム ローコード なし
画面フロー ローコード なし
OmniStudio ローコード + プロコード 業種パッケージ
画面フローと Lightning Web コンポーネント ローコード + プロコード なし
Lightning Web コンポーネント プロコード なし
## 決定ポイント 商品とツールを選択するときには、いくつかの決定ポイントに留意してください。この表は、さまざまな決定ポイントの概要と高レベルのガイダンスを示しています。
決定ポイント ガイダンス
実行時ユースケースカテゴリ
Form Scope and Navigation → フォームのスコープとナビゲーション フォームのすべての項目を 1 つの画面に論理的に収まるようにするか、ユーザーが複数の画面間を移動できるようにする必要があるかを決定します。
場所 Salesforce アプリケーション内からモバイルアプリケーション、外部 Web サイトまで、フォームを埋め込む場所を特定します。
コントローラー データ変換や外部システムとのインテグレーションなど、ユーザーがフォームを操作しているときにバックグラウンドで実行する必要があるアクションやロジックを特定します。
入力規則 Salesforce が提供する標準システムレベル検証を超える追加の入力検証要件があるかどうかを確認します。
インタラクション設計 フォーム内で動的応答をトリガーする必要があるインタラクションまたは条件の種別を特定します。
スタイル 目的のスタイルと CSS の要件に必要な洗練度を決定します。
レイアウト フォームのレイアウト要件 (必要な列数、タブ数、アコーディオン数など) と、繰り返しデータブロックを表示する機能を特定します。
トランスレーション フォームを他の言語にローカライズする必要があるかどうかを決定します。
機能以外の考慮事項
セキュリティ 特定の操作を実行する前にフォームでユーザーのアクセス権を確認するかどうか、フォームにアクセスできるユーザーを制御するかどうか、フォームを埋め込む場所を制御するかどうかを決定します。
オブジェクトへの影響 フォームを 1 つのオブジェクトに対して操作するのか、複数のオブジェクトに対して操作するのかを決定します。
UI テストの自動化 DevOps プロセスでフォームの自動単体テストと自動エンドツーエンドテストのどちらを実行する必要があるかを判断します。
メトリクス ページビュー、フォームに費やした時間、完了率、成功率など、フォームの利用状況を追跡する方法を特定します。
パッケージ化と展開 フォームの作成後に配布または展開する方法を決定します。
**注意:** 後続の決定比較表には、ツールと機能のペアに関連付けられたいくつかの値があります。 - **使用可能:** このツール/機能は、基本的な考慮事項に従って動作します。 - **利用不可:** 今後 12 か月以内にサポートを追加する予定はありません。 - **最適でない:** このツール/機能は機能する可能性がありますが、最適なツールではありません。 - **該当なし:** このツールは特定のユースケースには適用されません。 ## 使用事例 次のシナリオを使用して、範囲、UX、運用ニーズに基づいてツーリングの選択肢を比較します。 ### フォームの範囲とナビゲーション 1 つの画面フォームからすべてのユーザー入力を取得できる場合は、動的フォームから開始します。レコードページの動的フォームでは、パス機能を利用して段階的なビジネスプロセスをサポートできます。 #### 尋ねる質問 - 1 つの画面が必要ですか? それとも、ユーザーが ToDo を完了するために複数の画面間を移動する必要がありますか? - ユーザーがフォームに入力するときに、プロセスの進捗状況を視覚的に確認できるようにしますか?ユーザーは各画面の情報を特定の順序で入力する必要がありますか? それとも、必要に応じて画面間を行き来できる必要がありますか? 動的フォームで提供される機能よりも多くの機能が必要な場合、フロー、OmniStudio、LWC のいずれかを選択するかどうかは、いくつかの追加の質問によって異なります。 - フォームの下部にナビゲーションバーを表示しても問題ありませんか?画面フローとOmniScriptのナビゲーションエクスペリエンスが望ましくないUXを提供する場合は、LWCを検討してください。 - フォームの背後で何を実行する必要があるか?システム管理者が設定できる動作が必要な場合は、フローを使用します。複雑な複数オブジェクトリレーションの場合は、_Omniscript_ または _LWC_ を使用します。
単一画面 マルチ画面フォーム 進行状況インジケーター ステップ/画面間のジャンプナビゲーション
動的フォーム 利用可 利用不可 利用可 利用不可
画面フロー 利用可 利用可 利用可 利用不可
OmniStudio 利用可 利用可 利用可 利用可
画面フロー + LWC 利用可 利用可 利用可 利用可
LWC 利用可 理想的ではない 理想的ではない 理想的ではない
フローまたは OmniStudio を選択した場合は、適切な UX を実現するために LWC の構築が必要な場合もあります。フォームのスタイルを正しく設定するために LWC をすでに作成している場合は、[そのコンポーネントを](https://developer.salesforce.com/docs/component-library/documentation/en/lwc/lwc.use_flow)フローに埋め込む必要があるかどうかを検討してください。 **ウィザードスタイルのナビゲーション** 一方、ソリューションがウィザード (ユーザーが複数の画面間を移動する) のように見える場合は、フローまたは OmniStudio を検討します。フローと OmniStudio にはナビゲーションモデルが組み込まれているため、複数の LWC を作成して管理する必要はありません。ナビゲーションは直線的で、前方に進むアクション、後方に戻るアクション、そしてフォームを後で保存するためのメカニズムがあります。目的に応じて、非線形ナビゲーションを使用するフォームを作成することもできます。 OmniStudio では、フォーム内のステップを表示する標準ナビゲーションから進行状況インジケーターが表示されるため、ナビゲーション上の重要な利点があります。ステップビューには、ユーザーが複数ステップフォームのどこにいるかが自動的に表示されます。フローとは異なり、ユーザーはフォーム全体のさまざまなステップをクリックして画面間を移動できます。 単一画面フォームを作成するか複数画面フォームを作成するかに関係なく、ユーザーが操作しやすいようにフォームを合理化することが重要です。 ### フォーム要素 標準 Lightning レコードページにフォームを埋め込む場合、比較対象のツールはどれも動作しますが、動的フォームは現在デスクトップでのみ使用できます。ユーザーが他の場所からフォームにアクセスできる環境を提供する場合、代替オプションを考慮する必要がある場合があります。 #### 尋ねる質問 - ユーザーはデスクトップ、モバイル、またはその両方からフォームにアクセスする必要がありますか? - ユーザーがユーティリティバーを使用してアプリケーションのどこからでもフォームにアクセスできる必要がありますか? - クイックアクションを有効にして、ユーザーが現在のページから移動せずにフォームに入力できるようにしますか? - フォームを外部 Web サイトで使用可能にする必要がありますか?
Lightning レコードページ Lightning ホームページまたはアプリケーションページ Aura Experience Cloud サイト LWR Experience Cloud サイト 組み込みSnap-Ins ユーティリティバー オブジェクト固有のアクション グローバルアクション Salesforce モバイルアプリケーション* Field Service Mobile Mobile SDK 外部サイトおよびアプリケーション カスタム LWC
動的フォーム 利用可 利用不可 利用不可 利用不可 利用不可 利用不可 利用不可 利用不可 利用可 利用不可 利用不可 使用不可 使用不可
画面フロー 利用可 利用可 利用可 利用可 利用可 利用可 利用可 使用不可 利用可 使用可能** 使用不可 使用不可 利用可
OmniStudio 利用可 利用可 利用可 使用不可 使用不可 利用可 使用不可 使用不可 利用可 使用不可 使用不可 利用可 利用可
画面フロー + LWC 利用可 利用可 利用可 利用可 利用可 利用可 利用可 使用不可 利用可 使用不可 使用不可 理想的ではない 利用可
LWC 利用可 利用可 利用可 利用可 利用可 利用可 利用不可 使用不可 利用可 利用不可 使用不可 利用可 利用可
*フローと LWC は Salesforce モバイルアプリケーションでサポートされていますが、フローと LWC の埋め込み方法のすべてはサポートされていません (たとえば、オブジェクト固有のアクションはモバイルではサポートされますが、ユーティリティバー項目はサポートされません)。

** Salesforce Field Service Mobile アプリケーションには、データキャプチャ が含まれます。Data Capture は、最新のフロー機能をサポートする、専用のオフラインランタイムを備えたフローエンジン上に構築されたオフラインファーストフォームソリューションです。このアプリケーションには、古いカスタムオフラインエンジンで実行される従来の Field Service Mobile フローも含まれますが、最新のフロー機能の多くはサポートされません。
動的フォーム機能にはレコードコンテキストが必要なため、Lightning レコードページでのみサポートされます。ただし、動的フォームは Experience Cloud ページではサポートされません。 レコードコンテキストを必要とするフローや、グローバルに機能するフローを作成できます。つまり、さまざまな場所にフローを埋め込むことができます。レコードコンテキストフローの場合、ロケーションには Lightning レコードページ、Experience Cloud レコードページ、オブジェクト固有のアクション、またはアクション & おすすめリリースが含まれることがあります。グローバルフローの場合、ロケーションにはユーティリティバー、他の Lightning またはエクスペリエンスビルダーページ、Snap、外部アプリケーションが含まれることがあります。現在、フローはグローバルアクションとしてサポートされていませんが、回避策として _Aura_ コンポーネントで_フローをラップ_できます。 OmniStudioでは、フローを配置できる_ほとんど_の場所に配置できるコンポーザー可能なFlexCardとOmniScriptを作成できますが、これらはコンポーザー可能ですが、パッケージ化することはできません。 LWC は、Salesforce、コミュニティ、オープンソースプロジェクト全体でメタデータを使用して対象に関連付けることができるコンポーネントを作成するための高度な再利用性を提供します。LWC コンポーネントは、[Lightning Out 2.0](https://developer.salesforce.com/docs/platform/lwc/guide/lightning-out-intro.html) を使用して独自の Web サイトに組み込むこともできます。 Lightning Out on External Sites LWC コンポーネントは、[Lightning-Flow](https://developer.salesforce.com/docs/component-library/bundle/lightning-flow/documentation) コンポーネントを使用してフローを起動することもできます。 OmniStudio は、OmniOut 機能を使用してコンテンツを外部サイトに公開するのに適しています。OmniStudio と OmniOut を使用すると、OmniScript フォームと FlexCard コンポーネントを標準コンポーネントにコンパイルし、サードパーティサイトまたはアプリケーションでプラットフォーム外で実行できます。 現在、このガイドで取り上げているフォーム技術は、Mobile SDK テンプレートでは正式にサポートされていません。Mobile SDK が使用事例に不可欠である場合は、フォーム要素を念頭に置いて、モバイルアプリケーションでネイティブにフォームを作成するか、Visualforce ページを作成することをお勧めします。 ### ロジック 動的フォームは、フォームの値を使用してレコードを作成または更新する必要がある場合に最適です。この範囲外の機能 (決定レイヤーや反復レイヤーの作成、フォームからの入力を使用した Slack 投稿やメールの生成など) には、フロー、OmniStudio、または LWC を活用する必要があります。 #### 尋ねる質問 - バックグラウンドで実行する必要があるアクションまたはロジックは? - 関連レコードの値を使用する必要がありますか? - フォームの操作は 1 つのトランザクション内で完了する必要があるか、複数のトランザクションで完了する必要があるか? - 外部システムと統合する必要がありますか? - 再利用性とモジュール性の要件は?
ログとアクション 階層データ管理 1 つのトランザクション内で操作 複数のトランザクションでの操作 Integration の制限と考慮事項」 モジュラー設計と再利用 パッケージ
動的フォーム 使用不可 使用不可 使用不可 使用不可 使用不可 使用不可 利用可
画面フロー 利用可 使用不可 利用可 利用可 利用可 利用可 利用可
OmniStudio 利用可 利用可 利用可 利用可 利用可 利用可 利用不可
画面フロー + 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 Interaction via Wire Adapters OmniStudio では、インテグレーション手順とデータマッパーを使用して (Salesforce の外部と内部の両方で) データを取得して変換します。多数のコードフリー関数により、さまざまなレベルのリレーションでデータセットをフラット化および拡張することに長けています。 フロー、OmniStudio、LWCはすべてApexと統合されるため、選択したソリューション内のギャップを簡単に埋めることができます（たとえば、LWCからのレコードを絞り込む必要がある場合は、Apex用のワイヤ・アダプタを使用して複雑なSOQLクエリを作成できます。クリック ベースのストーリーに悩まされている場合は、サーバー側のニーズに合わせて、Apexコントローラーに代わる実行可能な方法としてフローまたはOmniStudioを使用することを検討してください。 また、アクションをすぐに確定するか、フォームの特定の部分に割り当てるかを検討する必要があります。これは、複数ページのフォームを使用している場合に特に関連します。フローでは、複数のフォーム (フロー画面) からの入力を簡単に結合し、後でウィザード (フロー) で特定の操作を実行できます。これは、まさにフローの設計で推奨される方法です。最後にアクションを実行します (ユーザーが回答を変更するために画面を行き来する場合)。 #### 支配オペレーション トランザクションと [PfR の制限](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_gov_limits.htm)は、Agentforce 360 Platform に不可欠です。使用事例が非常に単純な場合、特定の操作が発生するトランザクションを制御することはさほど重要ではない可能性があります。ただし、複数の操作を複数の[トランザクション](/docs/architect/ja-jp/fundamentals/guide/architecture-basics#トランザクション)で実行するのではなく、1 つのトランザクションに組み合わせる必要がある使用事例がいくつかあります。 いくつかの例を次に示します。 - **ロールバック:** フォームのバックグラウンドで複数のレコードを作成するとします。3 番目のレコードの作成に失敗した場合、最初の 2 つのレコードをロールバックする必要がありますか?各アクションが互いに独立している場合は、個別のトランザクションとして実行できます。ただし、相互に連動していて、一方の障害で他方もロールバックする場合は、それらを 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 がコミットされ、前のトランザクションがクローズされ、新しいトランザクションが開始されます。 multi-screen flow 特定の設計要素 (特定のトランザクションにどの操作をグループ化するか) はユーザー次第です。 いくつかの例を次に示します。 screen flow with separate transactions - 開始すると、複数の画面で入力を収集し、1 つのトランザクション内で複数のアクションを実行するフローが表示されます。 - 次のフローでは、各操作を個別のトランザクションで実行します。 - フローでは、レコードのロールバックを使用して、一連のデータベース操作で 1 つの操作が失敗した場合にトランザクション全体をロールバックすることもできます。 Screen Flow with multiple create records レコードを作成し、レコードを更新して、追加のレコードを作成するフローがあるとします (次のフローを参照)。 このシナリオでは、最初の 2 つの要素が成功し、最後の 2 つの要素が失敗した場合、最初の 2 つの DML 操作で引き続き適切なレコードが作成および更新されますが、3 つ目の要素は作成および更新されません。 Screen Flow with Rollback \[レコードをロールバック] 要素を使用すると、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) (トランザクションのフローの一括処理)」を参照してください。 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 サービスを使用します。 External integrations via MuleSoft API に OpenAPI スキーマがある場合は、外部サービスを作成します。 External Integrations via OpenAPI その他のすべてのインスタンスでは、フローの **HTTP コールアウト**機能 (外部サービスを使用) または OmniStudio の **HTTP アクション**を使用します。 External integrations via HTTP OmniStudio には、インテグレーション手順を使用して外部システムにコールアウトし、データマッパーを使用してデータを変換できる豊富なインテグレーション機能が備わっています。 実装にカスタム Apex コードを使用するか外部サービスを使用するかに関係なく、**コールアウト**は引き続きコールアウトです。 必要な知識は次のとおりです。 - コールアウトの処理に非常に時間がかかる場合があります。 - コールアウトが同期的に実行される場合は、データベーストランザクションが開いている間に実行されます。 - 待機中のデータベース操作がある場合、Salesforce ではデータベーストランザクションを開いたままにすることはできません。 主な制限は、データの**作成**、**更新**、または**削除**操作を実行してから同じトランザクション内で**コールアウト**を実行するときに、データが不整合状態のままになる危険性です。このパターンは、上記の 3 番目の考慮事項により許可されません。これは、最初の 2 つの考慮事項により存在します。 フローでは、トランザクションを破棄することでこの制限をスキップできます。画面とローカルアクションにより、ブラウザコンテキストが再び導入されます。外部コールアウトを使用するときは画面とローカルアクションを使用できますが、呼び出し可能な詳細設定で**トランザクション制御を**有効にすることをお勧めします。トランザクション制御では、コールアウトが実行される前にトランザクションを自動的に終了できます。トランザクション制御を有効にするには、呼び出されたアクションの \[**詳細]** セクションで \[**常に新規トランザクション**を開始] を選択します。 External Integrations via Callouts LWC は、コールアウトがトランザクションに及ぼす影響を最小限に抑えるのに役立ちます。つまり、Lightning Data Service(LDS)を使用してデータ操作を実行し、Apexコントローラを使用して外部コールアウトを実行します。LDSコールは(Apexコールアウトとは別に)独自のトランザクション内で分離されるため、結果として生じるデータの不整合から保護されます。 #### 再利用性とモジュール性 動的フォームでは再利用はサポートされません。各 Lightning レコードは、特定のオブジェクトの特定の Lightning レコードページに関連付けられていますが、その Lightning レコードページを複数のアプリケーションやプロファイルなどに割り当てることができます。 複数のコンポーネントで使用できるライブラリ、ユーティリティー、およびコンポーネントを記述する方法と同様に、**サブフロー**の機能を利用してフローを作成するときにも、同様のデザインパターンを適用できます。これを行うには、フローを小さなモジュラ バケットに保存し、**サブフロー**要素を使用して他のフローからコールします。設計で必要な場合は、単独で、またはサブフローとして役立つフローを作成できます。 OmniStudio は、本質的にモジュール化を目的として構築されています。データマッパー、OmniScript、FlexCard、Integration Procedure はすべて独立して構築されていますが、相互に連携することもできます。FlexCard は、他の LWC、OmniScript、レコードページ、Experience Cloud サイト内に組み込むことができる LWC コンポーネントとして作成することもできます。 画面フロー、OmniScript、LWCはすべて再利用できるように構築でき、外部サイトやLightning Outアプリケーションなど、さまざまな場所に埋め込むことができます。ソリューションを構成できるように設計すると、適応性と安定性のメリットも得られます。 ### 入力規則 レコードの作成または更新に使用されるすべてのテクノロジーは、従来の入力規則であるか、Apexトリガーに組み込まれたカスタム入力規則であるかに関係なく、システムレベルの入力規則に準拠する必要があります。レコードの変更を実行するために使用しているテクノロジーに関係なく、すべての変更は保存順序に従う必要があります。つまり、入力規則に加えて、レコードの変更は多数の保存前または保存後フロー、トリガーの前または後、エスカレーションルール、割り当てルールなどによっても処理されます。 **注：** Apex [の実行順序](https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_order_of_execution.htm)をまだ確認していない場合は、確認してブックマークします。 #### 尋ねる質問 - フォームにシステムレベルの検証以外の追加要件はありますか? - フォーム内で必須項目または参照のみ項目を動的に設定する必要がありますか?
システムレベルの検証を尊重する このフォームに固有のカスタムフィールドレベル検証 カスタムフィールドレベル検証
動的フォーム 利用可 利用不可 利用不可
画面フロー 利用可 利用不可 利用不可
OmniStudio 利用可 利用可 利用可
画面フロー + LWC 利用可 利用可 利用可
LWC 利用可 利用可 利用可
通常、フロー画面または OmniScript ステップの入力はバインドされていないため、フォーム自体は特定のオブジェクトに関連付けられたシステムレベルの検証にネイティブに準拠しません。ただし、レコードを作成または更新するために使用する値は保存順序で処理されます。つまり、オブジェクトのシステムレベルの検証を通過します。 **注：** 一部の画面フローコンポーネントでは入力の妥当性検査がサポートされていません。 動的フォームでは、ページレイアウトと同様に、ページレベルで**必須**状態と**参照のみ**状態を設定できます。システムレベルの設定を上書きすることはできません。 フローでは、フォーム入力の検証を柔軟にカスタマイズできます。複数のチェックがクライアントレベルで実行されます (欠落している必須項目やデータ型のチェック、入力規則内の互換性のある数式へのフラグ付けなど)。セキュリティレベルを強化するために、入力検証もサーバーで評価されます。ユーザーが \[**次へ]** をクリックすると、フローは入力をサーバーに再度送信して検証します。無効な入力が返されると、ナビゲーションがブロックされ、適切なエラーが表示されます。 サーバーは次のチェックを行って入力を検証します。 - 入力の**必須**設定、または入力された値が基礎となるデータ型と互換性があるかどうか。 - 入力のカスタム検証。_Boolean_ 型の数式と、数式が満たされない場合に表示するエラーメッセージを指定する必要があります。 - 基盤となるコンポーネントのカスタム検証。フローのカスタム 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 ではシステム レベルの必要性は考慮されますが、ページ レベルの必要性は考慮されません）。カスタムコンポーネントの場合は、独自の検証メカニズムを作成できます。 ユーザーがデータを入力する必要がある項目は、フォームの先頭に表示される必要があります。フォームを送信する前に (可能な場合) クライアント側でユーザー入力を検証します。 ### インタラクションデザイン 静的フォームは時代遅れです。現在では、_特定_のタイミングで_特定_のユーザー向けに_特定_の場所で適切なプロパティと値を使用してフォームを動的に更新することに重点が置かれています。Salesforce フォーム作成ツールを使用して何が実現できるかを詳しく見てみましょう。 #### 尋ねる質問 - フォーム内で動的応答を引き起こすインタラクションや条件の種類は何ですか？ - フォームの入力中に画面外 (バックグラウンド) 操作を実行する必要がありますか? - フィールドを**表示**、**必須**、**参照のみ**、または**無効**として設定する必要があるか、フォーム入力に基づいて書式を変更する必要があるか。
画面外データ操作の実行 条件値と計算 条件付き表示 条件付き必須 条件付き書式 条件付き参照のみの状態 条件付き無効化状態
動的フォーム 利用不可 利用不可 利用可 利用不可 利用可 利用不可 利用不可
画面フロー 利用可 使用可能* 利用可 利用可 利用不可 利用可 利用可
OmniStudio 利用可 利用可 利用可 利用可 利用可 利用可 利用可
画面フロー + LWC 利用可 利用可 利用可 利用可 利用可 利用可 利用可
LWC 利用可 利用可 利用可 利用可 利用可 利用可 利用可
*静的チェックボックスではなく、リソースピッカーを使用するコンポーネントに制限されます。
**Reactive Screens**は、Screen Flowのインタラクティブ性を有効にします。リアクティビティを使用すると、フロー画面の個々のコンポーネントが相互に通信できるため、画面フローがより強力になります。 **画面外データ操作の実行** 画面フローでは、**画面アクション**を使用して同じ画面でデータを取得する宣言型のアプローチが提供されます。画面アクションを使用すると、画面内の変更時、またはユーザーが**アクションボタン**コンポーネントをクリックしたときに自動起動フローをトリガーできます。自動起動フローの結果を同じ画面にマッピングできるため、ユーザーは別の画面に移動する必要がありません。 LWC には、Salesforce データにアクセスしてフォーム・コンポーネントにデータを動的に入力するためのさまざまなワイヤ・アダプタが用意されています。これにより、開発者は Apexコントローラを使用してレコード**を更新**、**削除**、**作成**できます。 Lightning Web Components Off-Screen Data Operations **表示** 表示は、すべてのフォーム作成ツールで動的に制御できます。動的フォーム、Flow Builder、OmniStudio では、コンポーネント表示機能を使用してこれに対応します。フォーム内の他の値、またはユーザーがモバイルデバイスでフォームに入力しているかどうかに基づいて、宣言的にフィールドを**表示**または**非表示に**できます。 - 動的フォームは、レコードフィールド値、参照フィールド、フォームファクターに基づいて表示を制御します。 - フローでは、他の画面入力や、フローの前半で入力された他のリソース (数式や他のレコードの値など) に基づいて表示ルールを設定できます。 - **デバイスベースのルール:** 最初から明確ではないかもしれませんが、ユーザーがモバイルデバイスを使用しているときに数式を使用して特定のフィールドを**表示**または**非表示**にできます。**$User.UIThemeDisplayed** グローバル変数の値をチェックするフロー数式を記述します。値が **Theme4t** の場合、ユーザーは Salesforce モバイルアプリケーションを使用してフォームに入力しています。 - **Evaluate Other Resources (**その他のリソースを評価): 手動変数および数式参照は、サーバ上でのみ評価されます。つまり、画面が最初に表示されるときのリソースの値は、別の画面に移動するまでの値になります。ナビゲーション中に、フローランタイムはフローエンジン (サーバー) に要求を送信し、最新の手動変数値と数式値を返します。ユーザーが 1 つの画面を通過するときに表示ルールが更新されることが予想される場合 (onblur など)、画面の他のコンポーネントの値のみを参照していることを確認する必要があります。 - OmniStudio では、\[**条件付きビュー**] プロパティを設定することで、コンポーネントを条件付きで**表示**または非**表示に**できます。ただし、1 つの入力に複数の \[条件付きビュー] プロパティを追加することはできません。 **条件付き入力状態** 他のプロパティを動的に制御する必要がある場合 (フィールドが**必須**か、**無効**か、**参照のみか**など)、いくつかのオプションがあります。LWC では、入力状態を完全に反応的に制御できます。反応型画面フローコンポーネントを使用すると、そのコンポーネントをサポートする標準コンポーネントのコンポーネント属性 (**参照のみ**、**無効**、**必須**など) を動的に制御できます。OmniStudio では、コンポーネント固有の属性の全範囲がサポートされます。要件によってフローが必要と判断され、コンポーネントで特定の属性状態がサポートされていない場合は、埋め込み可能な LWC を作成して動的入力状態を実現できます。 他のプロパティを動的に制御する必要がある場合 (フィールドが**必須**か**参照のみか**など)、短期的には LWC を使用します。これは、完全に制御できるためです。これは、onblur や onclick の処理方法に関するカスタム要件がある場合に特に当てはまります。 **画面フローの反応型 LWC** 画面フローの他のコンポーネントに反応して変更できる LWC を作成する場合は、『画面フローの [LWC ベストプラクティス](https://developer.salesforce.com/blogs/2023/02/lwc-best-practices-for-screen-flows)』ガイドを参照して、コンポーネントがフローランタイムエンジンと統合され、意図したとおりに機能することを確認してください。
標準イベント処理 (onblur、onfocus) カスタムイベント処理
動的フォーム 利用不可 利用不可
画面フロー 利用不可 利用不可
OmniStudio 利用不可 使用可能*
画面フロー + 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 を作成することを意味します。 #### 画面フローのスタイルの上書き システム管理者は、画面コンテナまたは個々のコンポーネントに対して、制限された画面およびコンポーネントのスタイル設定の上書き (色、境界線、ボタンの表示など) を設定できます。これらの上書きはテーマとブランド設定の後に適用されるため、ビルダーはアプリケーションの他の部分に影響を与えることなく対象を絞った視覚的な調整を行うことができます。 スタイル上書きは、ローカライズされた視覚的な例外 (確認画面の強調表示や特定の行動要請 (CTA) の強調など) を目的としており、完全なスタイル設定システムではありません。CSS レベルの制御は提供されず、画面やフローで再利用できるようには設計されていません。 アーキテクチャの観点からは、スタイルは次の先行順序に従う必要があります。 1. **テーマおよびブランド**設定: Lightning テーマ、エクスペリエンスビルダーのブランドセット、または LWR サイトのテーマ設定 2. **フロースタイル上書き:** 対象を絞った画面またはコンポーネントの調整 3. **カスタムコンポーネント (LWC):** ピクセル単位で完璧な制御や再利用可能なデザインパターンが必要な場合 テーマとデザインシステムを使用すると、スタイル設定の一貫性、拡張性、およびメンテナンスの容易さを長期にわたって維持できます。 #### 尋ねる質問 - 目的のスタイルと CSS はどの程度洗練されていますか? - ピクセル単位で完璧なカスタムスタイルや標準テーマが必要ですか?
ダイレクトスタイル 組織およびエクスペリエンスビルダーのテーマ ピクセル単位のスタイル
動的フォーム 利用不可 利用可 利用不可
画面フロー 使用不可 利用可 使用可能**
OmniStudio 使用可能* 使用不可 利用可
画面フロー + LWC 使用不可 利用可 利用可
LWC 使用不可 利用可 利用可
*FlexCard のみ

** 画面コンポーネントには特定のスタイル属性を設定できますが、CSS の上書きは設定できません。
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 にも適用されます。 ### レイアウト 迅速かつ効率的なデータ入力を可能にし、データの整合性を高める合理化されたフォームを設計するには、適切なレイアウトを選択することが不可欠です。 #### 尋ねる質問 - フォームレイアウトを構造化してユーザーエクスペリエンスを最適化する方法は? - フォームに新しいデータを簡単に入力できるように、既存のデータをユーザーに表示する方法は?
2 列 4 列 4 列以上 データの繰り返しブロック タブコンテナ アコーディオン
動的フォーム 利用可 使用不可 使用不可 使用不可 利用可 利用可
画面フロー 利用可 利用可 使用不可 利用可 使用不可 利用可
OmniStudio 利用可 利用可 利用可 利用可 使用可能* 利用可
画面フロー + LWC 利用可 利用可 利用可 利用可 利用可 利用可
LWC 利用可 利用可 利用可 利用可 利用可 利用可
*タブは、OmniScript の FlexCard にデータを埋め込む場合に使用できます。
動的フォームでは、項目内の個々のセクションに分割できる 2 列レイアウトがサポートされます。これらのセクションをコンポーネント (タブやアコーディオンなど) 内に配置して、整理された使いやすいレイアウトを作成できます。 フローは、**セクション**コンポーネントを使って表示することもできます。フロー画面では、最大 4 つの列と無制限のセクションを追加できます。セクションコンポーネントは画面幅にも反応するため、小さな画面でも機能します。条件付き表示をセクション全体に適用できるため、セクション内の複数の項目に表示を一括適用しやすくなります。**フローセクション**では列ヘッダーもサポートされ、表示ラベルをクリックしてセクション全体を折りたたむことができるアコーディオンのような環境が提供されます。 OmniScript には、項目とデータを表示するためのさまざまなレイアウトオプションがあります。条件付きで折りたたみ可能なアコーディオンを含め、最大 12 列のデータセクションを作成できます。 LWC では、Lightning-record-［edit\|view］-form およびサポートされる Lightning-［input\|output］- フィールドを使用してレイアウトを制御できます。レイアウトの制限は HTML と CSS のみです。**Lightning-record-form** コンポーネントは、関連付けられたページレイアウトのセクション設定に従います (たとえば、ページレイアウトでセクションが 2 列の場合、コンポーネントでも 2 列になります)。 ### トランスレーション 異なる地域のユーザーや異なる言語を話すユーザーがフォームにアクセスできる必要がある場合、フォームの作成に使用するツールがローカライズ要件を満たしていることを確認する必要があります。 **注意:** 特にフォームの場合、ローカライズの要件として、通常、テキスト要素を他の言語に翻訳する必要があります。 #### 尋ねる質問 - フォームを複数の国または地域で使用しますか? - フォームのテキストを他の言語にローカライズする必要がありますか?
ビルダーに入力された表示ラベル コードのラベル
動的フォーム 使用可能* 使用不可
画面フロー 利用可 利用可
OmniStudio 利用可 利用可
画面フロー + 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`範囲設定済みモジュールからコンポーネントにインポートします。 ## 機能以外の考慮事項 このセクションを使用して、実装前にセキュリティ、品質、運用上の制約を評価します。 ### セキュリティ セキュリティは複雑なトピックであり、フォームの作成に関しては、明確ではない考慮事項がいくつかあります。基礎レベルでは、フォームが正しいコンテキストで実行され、基礎となるデータを操作するために必要な権限がユーザーに付与されていることを確認する必要があります。さらに、リッチテキスト項目から潜在的に悪意のあるコードや URL を削除したり、特定のユーザーがフォームにアクセスできないようにしたり、システム管理者が将来フォームを埋め込むことができる場所の種別を制限したりするための追加措置を講じる必要もあります。 ツールを選択する前に、セキュリティ要件を十分に文書化してください。この種別のドキュメントに関するその他の指針については、「Salesforce [Well-Architected Security Policy Template](/docs/architect/ja-jp/resources/guide/security-policy-template) (Salesforce の適切に構築されたセキュリティポリシーテンプレート)」を参照してください。 #### 尋ねる質問 - 特定の操作を実行する前にフォームでユーザーのアクセス権を確認する必要がありますか? - ユーザー入力をサニタイズする必要がありますか? - フォームにアクセスできるユーザーを制御しますか? - フォームを埋め込む場所を制御しますか?
ユーザー権限の昇格 アクセス権を持つユーザーの制御 許可される場所の制限
動的フォーム 使用不可 利用可 使用不可
画面フロー 利用可 利用可 使用不可
OmniStudio 使用不可 利用可 利用不可**
画面フロー + LWC 利用可 利用可 使用不可
LWC 使用可能* 利用可 利用可
*Apexが必要

* * OmniScript には指定された対象ロケーションのセットを含めることはできませんが、FlexCard では含めることができます。
#### ユーザー権限の昇格 プログラム**をユーザーコンテキスト**で実行すると、Salesforce は一連のアクセスチェックを適用します。これには、項目レベルセキュリティ、CRUD 権限、および組織の共有ルールに基づくレコードアクセス権の検証が含まれます (たとえば、ユーザーがケースの更新フォームを実行できるのは、ケースを更新する権限、適切な項目レベルセキュリティ、該当のレコードへのアクセス権がある場合のみです)。 ユーザーがフォームを使用しているときに特定の操作を実行できるようにし、他のフォームやインタラクションからは実行できないようにする場合はどうすればよいでしょうか?ここで**システム コンテキスト**の出番です。 **システムコンテキストを**使用すると、セッション中にユーザーの権限を昇格できます (たとえば、ユーザーはケース更新フォームに正常に入力するためにケースオブジェクトへのアクセスを更新する必要はありません)。これは、認証されていないコミュニティで特に便利です。ゲストユーザーに潜在的に危険な機能を付与するのではなく、システムコンテキストで実行するようにフォームを設定します。 \[システムコンテキスト] は、絶対に必要な場合にのみ使用してください。フォームがシステムコンテキストで実行されると、すべての CRUD 操作はオブジェクトレベルおよび項目レベルのセキュリティおよび共有コンポーネントをスキップします。また、\[システムコンテキスト] は、Salesforce が_アクター_とみなすユーザー (\[**最終更新者**] フィールドに表示される名前) とは関係ありません。フォームで実行される操作 (ケースの更新など) ごとに、_アクター_は現在のユーザーになります (フォームが別のコンテキストで実行されていても)。 **注意:** 動的フォーム、OmniScript、および LWC は常にユーザーコンテキストで実行され、この動作を上書きする方法はありません。 画面フローはデフォルトでユーザーコンテキストで実行されますが、システムコンテキストで実行するように設定することもできます。フローですべてのデータへのアクセス権を付与するか、レコードレベルのアクセス権を適用するかを決定できます。 - システム コンテキストで実行されるフロー内に Lightning コンポーネントを埋め込む場合、そのフローでコンポーネントのコンテキストが上書きされることはありません。ユーザー アクセス チェックをスキップする必要がある場合は、フローを使用してこれらの操作を実行し、Lightning コンポーネントに適切なデータを渡します。一部の標準コンポーネント（たとえば、ルックアップ）は、システムコンテキスト内で動作できません。 - フローが Apex アクションを呼び出す場合、その他の注意点があります。 - Apex クラスが_継承共有_に設定されている場合、フローの設定方法に関係なく、共有のシステム コンテキストで実行されます。 - クラスに明示的な共有宣言がない場合、フローの設定方法に関係なく、共有なしでシステムコンテキストで実行されます。 - クラスが_共有ありまたは_共有なしに設定されている場合、フローのコンテキストが上書きされます。 **Experience Cloud サイトを使用したシステムコンテキストでのレコードの照会** Experience Cloud サイトのシステムコンテキストでフローを実行している場合(特に未認証の場合)、\[**レコードを取得**] 要素には特定のフィールドのみを保存します。フローを操作しているときに、**レコード取得**要素の結果をサブフロー、呼び出し可能なアクション、または Lightning コンポーネントに渡すと、そのオブジェクトのすべての項目がブラウザの開発者ツールによって検査される場合があります。意図とは裏腹に、Experience Cloud ユーザーが項目を使用できるようになる場合があります。システムコンテキストが有効になっているときに正しいフィールドのみが表示されるようにするには、**レコードを取得**要素でそれらの特定のフィールドを指定します。 **注:**OmniScriptロジックはクライアント側で実行されます。これにより、攻撃者はOmniScriptの予期される実行を変更し、ブラウザーの開発者ツールを使用してインテグレーション手順、データ マッパー、Apexメソッド コールへの応答を表示できます。OmniScript を使用している場合、可能な場合はサーバー側でビジネス ロジックを実行し、[@InvocableMethod アノテーション](https://help.salesforce.com/s/articleView?id=sf.os_integration_procedure_invocation_55721.htm&type=5)を介して公開される Apex メソッドの入力規則を実装することが重要です。 **入力のサニタイズ** 悪意のあるユーザーから組織を保護するには、入力のサニタイズを使用します。公開されているフォームに入力があり、それを組織内の**リッチテキスト**フィールドにマッピングできるとします。悪意のある URL を隠す可能性のある HTML を削除する自動化を有効にすることを検討してください。 フォームレベルでサニタイズを実装することは理想的ではありません。これらの項目に書き込むソースがいくつもある可能性があるためです。この問題に対処するには、**高速項目更新フロー**（保存前）を作成するか、既存の **Apex トリガー**を使用してフォーム内に入力される可能性のある HTML を削除または変更します。 #### ベストプラクティス - フローをデフォルトのコンテキストで実行できるようにします (特定の操作で現在のユーザーのアクセス権を昇格させる必要がない限り)。 - ゲストユーザーのシステムコンテキストでのフローの実行は避けてください。項目アクセス権が制限されている権限セットを作成し、Experience Cloud ゲストユーザーのプロファイルに割り当てます。 - Experience Cloud サイトのシステムコンテキスト実行フローでレコードを照会する場合、必要なフィールドのみを \[**レコードを取得**] 要素または**呼び出し可能アクション**に保存します。 - フローでさまざまな操作 (すべて昇格アクセス権を必要としない) を実行する場合、サブフローを使用してシステムコンテキスト内で実行する操作を分離します。 - 外部 Web ページ内にフォームを埋め込む場合、潜在的なフィッシング攻撃を防ぐために、フォームを**リッチテキスト**項目に対応付ける必要がある場合があります。これを行うには、**高速項目更新フロー**または **Apex トリガー**を使用して、HTML を削除するようにユーザー入力をサニタイズします。 #### 追加メモ - OmniScript、FlexCard、LWCs は、デフォルトでユーザー コンテキストで実行されます。 - LWC はデフォルトでユーザーコンテキストで実行されます。 - フローはユーザ コンテキストで実行されますが、Apex コントローラを使用して上書きできます。 - UI API 内で実行される操作は、ユーザーコンテキストで実行されます。 - Apex コントローラを使用して実行される操作は、特定のクラスによって異なります。これらの操作をシステム モードで実行するには、**Apex クラス**を共有ありまたは共有なしに設定します。 #### アクセス制御 フォームにアクセスできるユーザーを制御する必要がある場合は、フォームが埋め込まれているコンテナを確認します （たとえば、Lightning ページを特定のアプリケーション、レコードタイプ、またはプロファイルで使用できるように割り当てることができます）。特定の入力が機密である場合、表示ルールを使用して誰に表示するかをさらに制御します。この機能は動的フォームと画面フローに適用されます。 [フローを](https://help.salesforce.com/articleView?id=flow_distribute_security.htm)特定のプロファイルまたは権限セットに制限できます （Apex クラスや Visualforce ページと同様）。デフォルトでは、フローは無制限です。つまり、「**フローを実行**」ユーザー権限を持つすべてのユーザーがフローにアクセスできます。 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 クラスにのみ適用されます。また、[インテグレーション手順およびData Mapper](https://help.salesforce.com/s/articleView?id=sf.os_security_for_dataraptors_and_integration_procedures_48147.htm&type=5)にプロファイルレベルの権限を設定することをお勧めします。 #### アクセス制御のベストプラクティス - フローをゲストユーザーに公開する場合は、ゲストユーザーが絶対に必要とするフローへのアクセス権をゲストユーザープロファイルにのみ付与してください。**「フローを実行**」をゲストユーザープロファイルに追加できますが、この方法はリスクが伴います。 - システムコンテキストで動作するフローを操作するときは注意してください。これらのフローは、データを保護するための抑制と均衡が少ないため、特定のユーザーセットに制限する必要があります。 - ゲスト・ユーザー・コミュニティ内でApexを実行するOmniScriptに、Apexクラス定義にリストされている**共有が含ま**れていることを確認します。 - ゲスト・ユーザー・プロファイルの場合は、ゲスト・ユーザーにコールを許可するApexクラスのみを割り当てます。この慣行に従うことで、意図せずに追加のビジネスロジックがゲストユーザーに公開されるのを防ぐことができます。 LWC の場合、現在のユーザーの権限の割り当てを確認して、特定の標準権限またはカスタム権限を持っているかどうかを確認できます。Salesforce 権限は、`@salesforce/userPermission` および `@salesforce/customPermission` 範囲設定済みモジュールから **JavaScript** で直接インポートできます。Apex を使用して権限を確認することもできます。 #### コントロールの埋め込み LWC は、有効[なターゲット](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 の対象は指定できませんが、埋め込む FlexCard の対象は指定できます。 ### UI テストの自動化 Salesforce には、ユーザーがフォームを操作する方法をシミュレーションできるエンドツーエンドのテスト自動化ツール ([Salesforce UTAM](https://developer.salesforce.com/blogs/2022/05/run-end-to-end-tests-with-the-ui-test-automation-model-utam) など) がいくつかあります。Lightning ページや画面フローなど、任意の標準またはカスタム UI のテストを作成できます。 **注意:** この種類のテストでは、実行中のメソッドの出力を検証できません。UI テストの自動化要件を設定するときは、次の点に留意してください。 #### 尋ねる質問 - フォームの自動テストが必要ですか? - どのような種類のテストを実行する予定ですか? - テストのオートメーションに必要な粒度は？
単体テスト エンドツーエンドの自動化
動的フォーム 使用不可 使用可能*
画面フロー 使用不可 使用可能*
OmniStudio 使用可能* 使用可能*
画面フロー + LWC 使用可能* 使用可能*
LWC 利用可 利用可
*コードが必要
**UI テストの自動化要件の考慮** **単体テスト**では、業界標準のCI/CDシステムおよびツールに準拠した詳細な自動化と検証が提供されます。このツールでは、ビジネス ロジック、JavaScriptコントロール、特定のコンポーネントの出力をテストします。ローコードアプローチを選択した場合、自らテストを作成することはできませんが、Salesforceはすべてのエンドツーエンドのオファリングを厳密にテストしています。 コンポーネントのメソッドが複雑な場合、メソッドを専用の JavaScript ファイルに配置することで個別にテキスト送信できます。これにより、LWC にインポートし、さらに **Jest テスト (たとえば、**import { sort } from 'c/utils';) に取り込むことができます。 ISV のノーコードソリューションを使用するか、カスタムテスト自動化ソリューションを構築するか、オープンソースのテストフレームワーク (Selenium WebDriver や WebdriverIO など) を使用してエンドツーエンドの自動化を行うことができます。これらのソリューションは、すべての Salesforce UI インタラクション (Lightning ページの動的フォーム、ユーティリティバーの画面フロー、クイックアクションフローの LWC など) で有効です。 ### メトリクス フォームを本番環境にリリースしたら、フォームが効果的に使用されていることを確認する必要があります。使用事例によっては、平均的なユーザーが情報を送信する前にフォームに入力していた時間まで、フォームに入力されている回数を追跡する必要がある場合があります。ツールを選択する前に追跡可能な KPI を特定することが重要です。 #### 尋ねる質問 - フォームの利用状況を追跡する必要がありますか? - フォームが有効に使用されているかどうかを判断できる KPI は?
ページビュー フォームにかかった時間 フォーム完了状況を追跡する 成功率の追跡
動的フォーム 使用可能** 使用不可 使用不可 使用不可
画面フロー 利用可 使用可能* 利用可 利用可
OmniStudio 利用可 使用可能* 利用可 利用可
画面フロー + 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 ページの場合は、FlexiPage Metrics による **Users with Lightning** Usage カスタム レポートを使用します。 フローは、特定のフォームの採用を追跡するのに役立ちます。**サンプルフローレポート**: 画面フローを使用して、次の種別の質問に回答します。 - このフォームの完了率は?現在、適切に採用されていますか? - ユーザーがこのフォームを完了するまでにどのくらいの時間がかかりますか？ - ユーザーが最も長い時間をかけて完了する画面はどれですか？ - ユーザーはどのくらいの頻度で前の画面に戻りますか？ - エラーが発生する頻度は? 標準レポートがニーズに合わない場合は、**画面フロー**レポートを使用して、標準レポートをコピーして変更を加えるか、独自のレポートをゼロから作成できます。 パッケージベースの OmniScript ランタイムを使用している場合は、[OmniStudio for Vlocity Tracking Service](https://help.salesforce.com/s/articleView?id=sf.os_vlocity_tracking_service.htm&type=5) も使用できます。このサービスでは、すべての種別のイベントを追跡します (たとえば、OmniScript のステップの完了に要する時間を追跡できるため、プロセスの改善点を特定するのに役立ちます)。 **注意:** 画面フロー、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 使用不可 使用不可 使用不可 使用不可* 使用不可*
画面フロー + LWC 利用可 利用可 利用可 利用可 利用可
LWC 利用可 利用可 利用可 利用可 利用可
*IDX ワークベンチを使用して、OmniStudio ソリューションを他の組織にリリースします。
ソリューションをパッケージ化して AppExchange で配布する予定の ISV またはパートナーの場合は、「動的フォーム、フロー、および LWC」を参照してください。OmniStudio ではパッケージ化はサポートされていません。 ### ローコードからプロコードへの連続体を辿る このガイドは、動的フォーム、画面フロー、OmniStudio、LWC で使用可能な機能とカスタマイズレベルを示すことを目的としています。 Low-Code to Pro-Code Continuum 概要を次に示します。 - フォームの作成に関しては、LWC が最も堅牢でカスタマイズ可能なオプションですが、配置されているガードレールの数が最も少なくなります。そのため、[セキュリティ](/docs/architect/ja-jp/well-architected/guide/trust.html)と[拡張性](/docs/architect/ja-jp/well-architected/guide/reliability.html#scalability-and-capacity-planning)を念頭に置いてコンポーネントを構築することが重要です。 - 動的フォームは最も柔軟性の低いオプションですが、踏み間違いの可能性ははるかに低くなります。 - フローと OmniStudio は少し中間にあります。動的フォームよりも強力ですが、LWC レベルにはまだ達していません。ただし、動的フォームよりもガードレールの数が少なく、カスタムコードよりも破るのが困難です。 複数のツールがニーズに適している場合があります。その場合、最終的にどのツールがチームにとって最適かによって判断が変わります。考慮すべきその他の側面についての詳細は、次の[アーキテクト決定ガイド](/docs/architect/ja-jp/decision-guides)を参照してください。 #### 尋ねる質問 - ツールを比較する場合、各ツールに関するチームの専門知識を評価することが重要ですか? - LWC または JavaScript に精通している開発者の数は? - Flow Builder のエキスパートである開発者や、詳細について興味を示した開発者がチームにいますか? 具体的な詳細は説明しませんが、これらの特定のツールがこれまでに説明した評価にどのように関連するかについてもう少し詳しく説明します。 **デリバリー委任** 一部の要件で LWC が要求されていても、LWC を使用してソリューション全体を構築する必要はありません。ソリューションをモジュール形式で構築する方法を判断することが重要です。そのためには、コード化された LWC が必要な部品と不要な部品を識別する必要があります。LWC を必要としない部分は、ローコードソリューションを使用して構築する必要があります。 フローと LWC には、さまざまなコンポーネント (反応型画面コンポーネントや画面フローなど) があり、同じ画面で相互に同期して、アーキテクト、システム管理者、開発者向けの新しいツールを利用できます。開発者は、組織全体で再利用できる明確な目的のモジュールコンポーネントを作成できるようになったため、チームの生産性が向上します。これにより、開発者は標準フローコンポーネントとカスタムフローコンポーネントを組み合わせてフォームのダイナミズムを実現することで時間を節約し、新しい課題の解決により多くの時間を費やすことができます。フローでのリアクティブコンポーネントの導入により、フォームの作成時にフローと LWC を混在させるのにこれほど適切なタイミングはありません。 **長期オーナーシップと保守性** 複数ステップのフォームを作成する場合は、フロー、またはフローと LWC の組み合わせから開始します。フォームを管理しているチームがローコードチームの場合、ソリューションを対象利用者に合わせて可能な限り設定および拡張できるようにします。安定性とメンテナンス性を向上させるには、どのツールを選択しても、ソリューションを[構成](/docs/architect/ja-jp/well-architected/guide/resource-and-cost-optimization.html#packaging-and-modularity)可能な単位にまとめることが重要です。 ### Performance 動的フォーム、画面フロー、OmniStudio、または LWC に関連するパフォーマンスの考慮事項は、テクノロジーが収容されているフレームワークに基づきます。LWC に基づく技術は、Aura に基づく技術よりも優れている傾向にあります。LWC は、フレームワークの抽象化を介した JavaScript ではなく、Web エンジンでネイティブに実装されるいくつかのコア機能によって、パフォーマンスが向上しています。 では、Salesforce のフォームテクノロジーでこれらのパフォーマンス上のメリットを活用するにはどうすればよいでしょうか?詳しく見てみましょう。 - 動的フォーム (Lightning ページメタデータ内に統合) は、LWC スタック基盤上に構築されており、これにより、長らく待ち望まれていた複数の機能を実装できます。動的フォームでは、パフォーマンスのさらなる向上として、多数の項目が含まれるページの読み込み時間を短縮する順次表示を使用します。 - 画面フローは LWC に基づいて構築されています。**ファイルアップロード**コンポーネントと**画像**コンポーネントを除き、個々の標準コンポーネントのほとんどは LWC に変換されました。フローチームはフローランタイムクライアントを LWC (およびそのほとんどのコンポーネント) に変換していますが、顧客は Aura 画面コンポーネントを LWC に変換する必要があります。Salesforce では、画面フローの**反応型コンポーネント**フレームワーク内の LWC コンポーネントのみがサポートされます。詳細については、「[Lightning Web Components for](https://trailhead.salesforce.com/en/content/learn/modules/lightning-web-components-for-aura-developers) Aura Developer」 Trailhead モジュールを参照してください。画面フロー（またはその他のコンテナ）のカスタムコンポーネント作成を検討している場合は、LWC! を選択してください。 - 使用可能な OmniStudio にはいくつかのバージョンがあります。長年の顧客の場合、**Angular** を使用している可能性があります。すべての新規ユーザーは、LWC ベースの OmniScript と FlexCard を使用することをお勧めします。また、既存のお客様には Angular からの移行も推奨しています。 - LWC は LWC を基盤としています。 ## リソース
動的フォーム - 動的フォームを使用したレコードの詳細の分割
- Lightning アプリケーションビルダーのサポートを求める
画面フロー - 画面フローを使用したユーザー操作
- フローを使用した ToDo の自動化
OmniStudio - Omnistudio
- OmniScript
- IDX ワークベンチデスクトップアプリケーション
- ニューポート設計システム
- Newport Design System を使用した OmniScript と FlexCard のカスタマイズ
LWC - Lightning Web コンポーネント
- Lightning Aura コンポーネント開発者ガイド
- Aura 開発者向けの Lightning Web コンポーネント
# プラットフォーム決定ガイドの始め方 このセクションでは、Salesforce Platform の機能に関する重要なアーキテクチャ上の意思決定を行うための実践的な指針を提供します。非同期処理、レコードトリガーイベント、フォーム作成、エージェントによるワークフローと従来のワークフローの自動化、イベント駆動型アーキテクチャ、ステップベースの非同期フレームワークについて説明し、アーキテクトが拡張性とメンテナンス性が高く、パフォーマンスに優れたプラットフォームソリューションを設計できるようにします。 --- ## 非同期処理 [非同期処理](/docs/architect/ja-jp/decision-guides/guide/async-processing)では、Salesforce の非同期操作のツールとアプローチに関するガイダンスが提供されます。 - 非**同期処理ツール**: キュー可能Apex、スケジュール済みApex、プラットフォームイベントトリガー、変更データキャプチャ、スケジュール済みパス(確定後フロー)、非同期パス(レコードトリガーフロー)の比較と、適切な使用事例に関するガイダンス。 - **サーバー側非同期処理**: 長時間のデータベース操作、外部コールアウト、および大量のレコード処理のパターン。 - **クライアント側非同期処理**: Apex 継続コールアウトやクライアント側非同期処理など、ブラウザーまたはモバイルアプリケーションで実行される手法。 - **決定フレームワーク**: 使用事例の検証、拡張性、トランザクションが真に非同期である場合の理解、極端な負荷イベントの監視、処理を検討します。 - **ベストプラクティスとアンチパターン**: 送信インテグレーション、一般的な落とし穴の監視、回避など、適切な使用のためのガイダンス。 アーキテクトは拡張性と信頼性が高く、メンテナンス可能な非同期パターンを実装できるため、パフォーマンスを低下させる落とし穴を回避できます。 --- ## フォームの作成 [フォームの作成](/docs/architect/ja-jp/decision-guides/guide/build-forms)は、アーキテクトがSalesforceのフォーム作成オプションについてガイドします。 - **フォーム作成ツール**: 動的フォーム、画面フロー、OmniStudio、画面フローと Lightning Web コンポーネント (LWC)、LWC の比較 (スキルとライセンスに関する考慮事項を含む)。 - **決定フレームワーク**: オブジェクトへの影響、フォーム範囲、ナビゲーション、場所 (アプリケーション、モバイル、Web)、UX、テスト自動化を考慮します。 - **ツール選択ガイダンス**: シンプルなレコードレイアウトから、複数ページのウィザードやブランド設定された顧客向けフォームへのおすすめ。 - **組み合わせパターン**: 画面フローナビゲーションと LWC スタイル設定などのツールを組み合わせるためのガイダンス。 - **高度な機能**: 機能と制限を詳しく調べて、ツールの選択肢を提供します。 アーキテクトが特定のUX、機能、インテグレーション要件に適したフォーム作成アプローチを選択できるようにします。 --- ## エージェント型および従来のワークフローの自動化の決定 [Determining Agentic Workflow Automation](/docs/architect/ja-jp/decision-guides/guide/determining-agentic-vs-traditional-workflow-automation.html) and Traditional Workflow Automationでは、オーケストレーション密度フレームワークを使用して従来の自動化とAgentforceのいずれかを選択するフレームワークが提供されます。 - **オーケストレーション密度フレーム**ワーク: 実行パス (完全指定と指定不可)、目標の複雑さ (単一タスクと競合する目標)、モダリティの組み合わせ (構造化された入力とマルチモーダル入力) に基づいて自動化の複雑さを評価します。 - **製品ランドスケープ**: さまざまな自動化シナリオでのフロー、Apex、Agentforce、Agent Script、Agentforce Grid、Agentforce Operations、MuleSoft の比較。 - **密度選択マトリックス**: オーケストレーション密度レベル (低、中、高) を、レコードトリガー自動化からハイブリッドオーケストレーション、エージェントスクリプトを使用したガイド付き決定論まで、アーキテクチャ標準に対応付けます。 - **決定フレームワーク**: 実行パスを最初に調査し、次に目標の複雑さ、モダリティの組み合わせを順に評価して、適切なツールを決定します。 - **使用事例ガイダンス**:従来の自動化(ルール ベース、確定的)、Agentforceグリッド(一括AIタスク)、ハイブリッド オーケストレーション(複雑なエンド ツー エンド プロセス)、エージェント スクリプト(推論ニーズのある構造化されていないエントリー ポイント)に関する具体的な推奨事項。 アーキテクトがオートメーション全体の範囲で情報に基づいた意思決定を行い、拡張性、監査可能性、保守性に優れたソリューションのために推論機能と確定的な支配のバランスを取ることができます。 --- ## イベント駆動型アーキテクチャ [イベント駆動型アーキテクチャ](/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 は、複雑なビジネスプロセスの要求を満たすために自動化アーキテクチャを継続的に進化させてきました。旧世代 (ワークフロールールとプロセスビルダー) では、イベント駆動型ロジックの最初のステップが提供され、イベント駆動型ロジックの自動化機能が拡張され、ビルダーの範囲が広がりました。 この進化により、レコードトリガーフローとApexトリガーという2つの補完的な柱を中心とした、パフォーマンスに優れた統合アーキテクチャが実現しました。 ## ガイドの概要 このドキュメントでは、トリガー自動化を設計するときに十分な情報に基づいて意思決定を行うためのフレームワークとガイドラインについて説明します。Salesforce レコードへの変更によってトリガーされる自動化の適切なアプローチを選択する際の指針となる 3 つの主要な決定ポイントと使用事例の要件のバランスを取ります。 ## スコープ内の商品
フロー 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 トリガーを混在させないようにしてください。 ## 決定ポイント 考慮すべき主な決定ポイントは次の 3 つです。 - 宣言型とプログラムによる実装 - オートメーション密度 - 密度選択マトリックス ### 宣言型とプログラムによる実装 フローと Apex には、共通の基本機能セットがあります。各ツールは、レコードの照会、条件ロジックの実行、変数の割り当て、およびレコードの作成、更新、削除などの DML 操作 (指定された順序で実行) を実行できます。 ただし、この機能の重複は、ツールが交換可能であるという意味ではありません。アーキテクチャの選択は、タスクを実行できる_かどう_かではなく、タスクを_どのよう_に実行し、パフォーマンス、拡張性、および保守性に長期的な影響があるかについてです。フローは、宣言型の明確さと簡単なプロセスの実装速度に優れており、Apexは、複雑なソリューションに必要な詳細な制御と強力な処理能力を提供します。 ### オートメーション密度 **自動化密度**は、特定の Salesforce オブジェクトにかかる負荷です。これは、オブジェクトの最適な実装を判断するためのヒューリスティックとして機能します。自動化の密度が高まるにつれて、トランザクション制限に違反する可能性が高くなります。 量と複雑さの 3 つの特定のディメンションを調べて、自動化密度を計算します。 - **オートメーション数量:** 1 つのデータ操作言語 (DML) イベント中に実行される一意の自動化メタデータエントリ (フロー、トリガーアクションなど) の未加工の数。 - **レコード量:** API 読み込みまたは高負荷のバッチ処理によって処理されるトランザクションあたりのレコード数。パフォーマンスが重要になります。 - **依存関係の無秩序な増加:** 最初の CRUD 操作によってトリガーされる下流の DML 操作の基準。1 つの更新が関連オブジェクトの更新にカスケードされるグラフの深さを定量化します (ケース → 取引先 → 取引先責任者 → カスタムロールアップなど)。 オートメーション密度ディメンション Salesforceアプリケーションのスコープと複雑さが増大するにつれて、レコードトリガーフローまたは Apexトリガーのいずれか、ひとつの主要なエントリーポイントに統一することを推奨します。1 つの Salesforce オブジェクトで複数のメカニズムにわたって自動化をパーティション分割すると、メンテナンス性が低下し、ガバナンスが断片化してしまうため、避けてください。 ### 密度選択マトリックス このマトリックスを使用して、Salesforce オブジェクトに必要なアーキテクチャ標準を決定します。 - **レコード トリガー フロー**は、自動化密度が低い場合に推奨されるソリューションです。互いに独立していてわかりやすいオートメーションに最適なパワーとアクセシビリティのバランスを実現します。 - **ハイブリッド パターン(**呼び出し可能なApexを使用したレコード トリガー フロー)は、複雑さが増している中密度の自動化に適した強力でメンテナンス可能な選択肢です。このパターンにより、チームは宣言型 Flow において整然とした処理の流れを維持しつつ、計算負荷の高い操作を 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をアーキテクチャ設計に組み込む必要があります。 ## 商品比較 レコードトリガーフローは、レコードトリガーによるオートメーションのためのプラットフォームのPremierな宣言型ツールです。Flow の使いやすさと組み込みのプラットフォームのセーフガードにより、チームは拡張性と信頼性に優れたソリューションを簡単に構築できます。これは、Salesforce Platform でソリューションを構築するほとんどのチームにとって理想的な選択肢です。 Apex は、プラットフォーム独自の強く型付けされたオブジェクト指向プログラミング言語です。Apex は、オートメーション密度の高い Salesforce オブジェクトや、高いパフォーマンス、高度なロジック、またはトランザクションにおけるきめ細かな制御を必要とするユースケースに使用してください。 意思決定プロセスを支援するために、このマトリックスでは主要なアーキテクチャ機能における Flow と 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 レコードトリガーフローはオーケストレーションレイヤーとして機能し、高複雑度のオペレーションはInvocable Apex内にカプセル化されます。
シンプルから適度に複雑なロジック 主データオブジェクトと関連データオブジェクトの両方に対するトリガー更新による、低から中程度の複雑さのデータ操作 フロー フローは、システム管理者とデベロッパーの両方が扱いやすい宣言型モデルに基づいているため、通常は最適な選択肢となります。
通知および送信メッセージ アウトバウンドメールおよびメッセージの送信 フロー フローを使用すると、レコードの変更時にメールアラートおよびアウトバウンドメッセージの送信が容易で、拡張性にも優れています。
スケジュール済み処理 将来の動的な日付 (完了予定日の 3 日前など) での自動化 フロー スケジュールパスは、レコードのデータが変更された場合にプラットフォームがこれらのパスのスケジュール設定、キャンセル、再スケジュールを自動的に処理するため、フローに独自の強みをもたらします。
### スケーラブルな処理: 非同期ユースケースの詳細 拡張性は、実装を設計するときの重要な考慮事項です。レコードトリガーオートメーションのビジネスロジックが複雑になったり、実行時間が長くなったり、大量のデータが関係したりすると、Salesforce Platform のコアガバナ制限がアーキテクチャ上の制約になります。データの一括更新、複雑な API コールアウト、重い計算などの操作は、合計 CPU 時間や 1 つのデータベーストランザクション内の DML ステートメント数などの制限に違反するリスクを高めます。制限例外が原因で同期トリガーが失敗すると、ユーザーの保存トランザクション全体がロールバックされ、ユーザーエクスペリエンスが低下し、データが失われる可能性があります。この固有のリスクにより、複雑な作業の負荷が軽減されるアーキテクチャパターンが必要になります。 この場合、非同期オートメーションが不可欠です。アーキテクトは、非同期メカニズムを使用して、実行時間が長い作業や大量の作業を、同期レコード保存の主トランザクションから効果的に分離できます。迅速かつ信頼性の高い方法で保存が完了し、重い処理は後で実行される別のプラットフォーム管理トランザクションに委任されます。分離により、安定性が向上し、トランザクションの失敗が防止され、拡張性の高い企業向けアプリケーションの構築に不可欠です。このプラットフォームは、信頼性、ボリューム、複雑さという各観点から明確な利点とトレードオフを持つ、いくつかの特殊なツールを提供します。 ### フローの非同期パス レコードトリガーフローの「非同期で実行」パスは、「起動して忘れる」非同期ロジックの最もシンプルなメカニズムを提供します。このパスは、元のレコード保存トランザクションがデータベースに正常にコミットされた後、個別のトランザクションで実行されます。 - **理想的な使用**事例: これは、即時実行やカスタムエラー処理を必要としないタスクに適しています。たとえば、メール通知の送信、フォローアップ ToDo の作成、外部システムへの簡単なコールアウトなどです。 - **制限事項**: このメカニズムは、他の非同期フローインタビューと同じ1日のガバナ制限を共有します。大量の処理には適していません。 ### 変更データキャプチャ (CDC) 変更データキャプチャ (CDC) は、大規模シナリオでのレコード変更によってトリガーされる非同期ロジックを処理するための高スループット、拡張性、復元性の高いパターンです。このモデルでは、トリガーの唯一の責務はレコードの同期保存です。次に、プラットフォームは、大規模イベントバスへのレコードの変更を含む詳細なイベントメッセージを公開します。個別の専用 Apex トリガーがこの変更イベントに登録します。複雑で実行時間が長い作業や非同期の作業を実行します。 - **メリット**: このパターンでは、非同期プロセスを最初のユーザートランザクションから分離します。非同期処理が失敗しても、ユーザーのレコード保存はロールバックされません。このパターンでは、複数の内部登録者または外部システムが使用できる耐久性のあるイベントストリームも提供され、イベントを最大 72 時間再生できるため、強力な復元力が得られます。 - **制限**: CDC イベントメッセージには、レコードの前の状態 (Apex `Trigger.oldMap`に相当) は含まれません。イベントペイロードには、新しい項目値が含まれますが、変更元の値は含まれません。そのため、特定の状態遷移に基づいてロジックを実装することが困難です (たとえば、`Status__c`が「待機中」から「承認済み」に変更された場合にのみ実行)。イベント登録者でオブジェクトの項目履歴を照会することでこれを軽減できますが、これによりプロセスが複雑になり、特定の関心項目で項目履歴管理が使用できない場合があります。これにより、CDC にオフロードできる自動化の種類が制限される場合があります。 デフォルトでは、CDC は最大 5 つの Salesforce オブジェクトで有効にできます。追加が必要な組織は、この制限を削除し、イベント配信の割り当てを増やす Add-on/アドオン ライセンスを購入できます。 ### トリガーからのキュー可能 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 を使用するハイブリッド モデルは強力ですが、汎用的なアプローチではありません。アーキテクトは、ハイブリッド ソリューションに取り組む前に、特定の制限とトレードオフを認識しておく必要があります。 - **No before-save support**: これは最も重要な制限事項です。呼び出し可能なアクションは、保存後コンテキスト (アクションと関連レコードのフロー) でのみ使用できます。高パフォーマンスな保存前コンテキスト（フィールドの高速更新のフロー）では使用できません。そのため、このパターンを使用して同じレコードのフィールドの更新を委任することはできません。保存前フローまたは保存前コンテキストのApexトリガー内でネイティブのフロー要素を使用して、高パフォーマンスの仕事を実行します。 - **No after-undelete support:** 現在、レコードトリガーフローでは復元後のコンテキストはサポートされていません。Salesforce オブジェクトに、ごみ箱からレコードを復元するときに自動化を実行するというビジネス要件がある場合、Apex トリガーが唯一のソリューションです。 - 大規模シナリオの**パフォーマンスオーバーヘッド:** フローランタイムから Apex ランタイムへの移行は、コストゼロの運用ではありません。一般に高速ですが、フローのランタイムから呼び出し可能アクションにドロップする動作は、Apex トリガー内に完全に収まるネイティブ実行ほど計算速度は速くありません。ほとんどの中密度のオートメーションでは、このマイクロオーバーヘッドは無視できるほど小さく、アクセシビリティの向上に十分見合うものです。ただし、極端に高パフォーマンスかつ高ボリュームのシナリオでは、Apexのみのフレームワークの方が純粋な計算速度の点で有利です。 ### 従来の自動化の戦略 オートメーション密度のヒューリスティックは、新しいグリーンフィールドアーキテクチャには決定的な指針を提供しますが、企業のSalesforce環境における実情は、より複雑なことが多いです。成熟した組織では、同じ Salesforce オブジェクトで動作するレコードトリガーフローと Apex トリガーを見つけるのが一般的です。このシナリオは、前に説明したハイブリッド パターンとは異なります。ここでは、フローと Apex トリガーが結合されておらず、連携するように設計されていません。 この共存は、多くの場合、プラットフォーム機能の進化や従来の技術的負債が原因です。これは許容される運用状態ですが、アーキテクトはそれを最終状態ではなく、計算されたトレードオフとして捉える必要があります。 オーケストレーションが断片化することで、ガバナンスとメンテナンスのオーバーヘッドが大きくなり、開発、テスト、インシデント処理の作業がバラバラになり、煩雑になります。これにより、解決までの時間 (TTR) が増加し、運用が複雑になります。 - 新しい Salesforce オブジェクトの場合、主要なガイドとして自動化密度の原則に従います。 - 既存の Salesforce オブジェクトで、ハイブリッドなフットプリントを持ち、レコードトリガーフローと Apex トリガーの両方のエントリーポイントが存在する場合、密度を評価した上で、メンテナンス性を考慮したハイブリッド状態にリファクタリングするよう設計します。 - 低密度の場合は、Apexトリガーをレコード トリガー フローにリファクタリングし、実行順序を指定して、1つの自動化エントリ ポイントに取り込みます。 - 中密度の場合は、複雑な大規模フローを、適切な実行順序を保ったまま、フローのサブセットにリファクタリングします。Apex トリガーは、削除取消後のコンテキストをサポートするなど、どうしても必要な場合にのみ導入してください。 - 高密度の場合は、Apexトリガーの実装をお勧めします。 ### Apex トリガーでメタデータフレームワークを使用する Salesforce Platform での組織のビジネスプロセスが成熟するにつれて、レコードトリガー自動化の量と複雑さは必然的に増加します。基本的なベストプラクティスは、_ApexトリガーをSalesforceオブジェクト_ごとに1つ管理することです。プラットフォームでは、同じイベントに対して同じオブジェクトに対する複数のトリガーの実行順序が保証されないため、このルールは非常に重要です。この制限により、動作が不安定になったり、競合状態になったり、デバッグが困難になったりする可能性があります。 ただし、_ワン トリガー_の原則に従うと、アーキテクチャ上の課題が生じます。つまり、その1つのエントリー ポイントから呼び出されるすべてのビジネス ロジックを、メンテナンス可能で拡張可能な方法で管理およびオーケストレーションする方法です。 #### Classic トリガハンドラの制限事項 このアーキテクチャの最初の進化は Classic トリガハンドラパターンでした。この方法では、1 つの Apex トリガーですべてのロジックが対応するハンドラ クラス（`OpportunityTriggerHandler` など）に委任されます。このメソッドにより、ロジックがトリガーファイルから分離され、開発者はハンドラクラスのメソッド (`afterInsert()` など) 内の実行順序を決定的に制御できます。 このパターンは改善されていますが、多くの場合、ハンドラークラスがモノリシックになります。ビジネス要件が追加されるにつれ、クラスは大規模になり、管理が難しくなり、単独でテストすることも困難になります。すべての個々のプロセスの実行順序が 1 つのメソッド内でハードコードされるため、クラスがマージの競合を起こしやすく、大規模なエンタープライズ環境でのガバナンスとメンテナンスのオーバーヘッドが大幅に増加します。 #### 解決策: メタデータ駆動型トリガーフレームワーク モジュール性とオーケストレーションのコア問題を解決するために、アーキテクトは**メタデータ駆動型トリガー フレームワーク**に移行します。これは、自動化ロジック自体を実行_方法_と実行_タイミング_の設定から分離する、アーキテクチャ上の重要な飛躍です。 このフレームワークは、次の3つの主要な利点に基づいて構築されています。 - **パーティショニング:** 1 つのハンドラ クラスではなく、コア ビジネス ロジックが小さな原子 Apex クラス (`RecalculateAccountValues` クラスや `NotifySalesLeads` クラスなど) に分割され、各クラスが \[_Single Responsibility Principle_ (単一責任の原則)] に従います。このモジュール化により、ロジックを個別にテスト、デバッグ、および理解しやすくなっています。 - **順序と振付:** 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 フロー 業務