Salesforce外部オブジェクトを活用したデータ戦略最適化：アーキテクトのためのガイド

背景とアプリケーションシナリオ

現代の企業システムは、様々なデータソースに分散した情報を扱っています。顧客情報がCRMにある一方で、商品在庫はERPに、注文履歴は別のレガシーシステムに、というようにデータがサイロ化していることは珍しくありません。このような状況では、顧客の360度ビュー（360-degree view of the customer）を実現したり、リアルタイムなビジネス判断を下したりすることが困難になります。

Salesforceは、クラウドベースの顧客関係管理（CRM）プラットフォームとして、顧客データの統合と活用を推進していますが、すべてのデータをSalesforce内に保存することが常に最善の選択とは限りません。例えば、非常に大容量のデータセット、リアルタイム性が極めて重要なデータ、あるいは外部システムの主権が維持されるべきデータなどです。ここで登場するのが、Salesforceの強力な統合機能であるSalesforce Connect（Salesforceコネクト）と、その主要な構成要素である外部オブジェクト（External Objects）です。

外部オブジェクトとは、外部システムに存在するデータをSalesforce内で標準オブジェクトやカスタムオブジェクトと同様に表示・操作するための機能です。これにより、データ自体をSalesforceに複製することなく、外部システムからリアルタイムでデータを取得・利用できるようになります。これは、データ重複の排除、Salesforceストレージコストの削減、そして常に最新のデータにアクセスできるという点で非常に大きなメリットをもたらします。

アーキテクトの視点から見ると、外部オブジェクトは以下のような多様なアプリケーションシナリオでその真価を発揮します。

ERP連携：ERP（Enterprise Resource Planning）システムに格納されている顧客の注文履歴、在庫情報、配送状況などを、Salesforceの商談（Opportunity）や取引先（Account）レコードからリアルタイムに参照します。例えば、セールス担当者が顧客との電話中に、在庫状況を確認して即座に回答するといったユースケースです。
レガシーシステムとの共存：既存のレガシーシステムが保有する大量のマスターデータをSalesforceに移行することなく、サービスコンソール（Service Console）から参照し、顧客対応に活用します。これにより、データ移行のコストとリスクを回避しつつ、SalesforceのUI/UXを提供できます。
データウェアハウス連携：データウェアハウス（Data Warehouse）に蓄積された膨大な顧客行動ログやWebサイトのアクセス履歴などを、Salesforceのマーケティングやサービス部門から参照し、パーソナライズされたサービスを提供します。
クロス組織連携：複数のSalesforce組織を運用している企業において、ある組織のオブジェクトデータを別の組織の外部オブジェクトとして参照します。これにより、組織間のデータ共有が簡素化され、効率的な運用が可能になります。

これらのシナリオにおいて、外部オブジェクトはシステム間のデータ連携をシンプルにし、ユーザーエクスペリエンス（UX）を統一し、組織全体のデータ活用能力を飛躍的に向上させる重要なアーキテクチャパターンとなり得ます。

原理説明

外部オブジェクトがどのように機能するかを理解することは、その効果的な設計と実装の鍵となります。その中核をなすのがSalesforce Connectです。

Salesforce Connectと外部データソース

Salesforce Connectは、Salesforceと外部システム間のブリッジとして機能します。外部システムとの接続は、外部データソース（External Data Source）としてSalesforce組織内で設定されます。外部データソースには主に以下の3つのタイプがあります。

OData 2.0/4.0 アダプター：最も一般的なタイプで、外部システムがOData（Open Data Protocol）仕様に準拠したRESTful APIを提供している場合に利用されます。これにより、Salesforceは外部システムからスキーマ情報やデータを自動的に取得できます。
クロス組織アダプター（Cross-Org Adapter）：別のSalesforce組織に接続するために使用されます。Salesforce to Salesforce連携とは異なり、リアルタイムアクセスとより柔軟なデータマッピングが可能です。
カスタムアダプター（Custom Adapter）：ODataやクロス組織アダプターでは要件を満たせない場合に、Apexコードで完全にカスタマイズされたアダプターを開発できます。これにより、SOAPサービス、独自のREST API、レガシーデータベースなど、あらゆる外部システムと接続することが可能になります。

外部データソースを設定した後、Salesforceは外部システムのスキーマ（テーブルやフィールド）を検出し、それをSalesforceの外部オブジェクトにマッピングします。このプロセスは、管理者によって手動で行うか、または外部データソースからスキーマを同期（Sync）することで自動的に行われます。

外部オブジェクトの作成とフィールドマッピング

外部オブジェクトは、標準オブジェクトやカスタムオブジェクトと同様に、オブジェクトマネージャー（Object Manager）で管理されます。外部オブジェクトが作成されると、外部システムのテーブルやビューに対応する形で、Salesforce内に仮想的なオブジェクトが生成されます。このオブジェクトには、外部システムのフィールドがSalesforceのデータ型にマッピングされた形でフィールドが作成されます。

特に重要なのが、外部システムのレコードを一意に識別するためのキーです。Salesforceでは、外部オブジェクトに対して外部ID（External ID）フィールドが提供されます。これは、外部システムのプライマリキー（Primary Key）またはユニークキー（Unique Key）にマッピングされるべきです。外部IDは、SOQLクエリでのフィルタリングや、後述するリレーションシップの確立に不可欠な要素となります。

データアクセス方式と書き込み可能外部オブジェクト

外部オブジェクトは主に外部データのリアルタイム読み取り専用アクセスに使用されますが、OData 4.0アダプターまたはカスタムアダプターを使用することで、書き込み可能外部オブジェクト（Writable External Objects）として設定することも可能です。これにより、Salesforceから外部オブジェクトに対してDML操作（Insert, Update, Delete）を実行し、その変更をリアルタイムで外部システムに反映させることができます。ただし、外部システムのデータ整合性への影響を慎重に評価し、厳密なエラーハンドリングを設計する必要があります。

リレーションシップ

外部オブジェクトは、他の標準オブジェクトやカスタムオブジェクト、あるいは別の外部オブジェクトとの間にリレーションシップ（Relationships）を持つことができます。これにより、関連するデータをSalesforce内でシームレスに表示・操作することが可能になります。

間接参照関係（Indirect Lookup Relationship）：Salesforceの標準オブジェクトまたはカスタムオブジェクトから、外部オブジェクトを参照するリレーションシップです。この関係では、参照元オブジェクトのカスタム間接参照項目が、参照先（外部）オブジェクトの外部IDフィールドに一致することで関連付けが行われます。
外部参照関係（External Lookup Relationship）：外部オブジェクトから、Salesforceの標準オブジェクトまたはカスタムオブジェクトを参照するリレーションシップです。この関係では、外部オブジェクトの項目が、参照先SalesforceオブジェクトのIDフィールドまたは外部IDフィールドに一致することで関連付けが行われます。
マスター・ディテール関係（Master-Detail Relationship）：外部オブジェクトは、標準オブジェクトやカスタムオブジェクトのマスターとして設定することはできません。しかし、外部オブジェクト同士の間でマスター・ディテール関係を設定したり、標準/カスタムオブジェクトがマスターで外部オブジェクトがディテールになる間接参照マスター・ディテール関係を設定したりすることは可能です。

SOQLによる外部オブジェクトへのアクセス

Salesforceの強力なデータ操作言語であるSOQL（Salesforce Object Query Language）は、外部オブジェクトに対しても適用可能です。これにより、Salesforceアプリケーション、レポート、およびApexコードから、外部データをシームレスにクエリできます。ただし、外部オブジェクトに対するSOQLには、いくつかの標準オブジェクトとは異なる特性や制約があります。

SOQLクエリの基本

外部オブジェクトは、API参照名に __x サフィックスが付加されます。SOQLクエリではこのサフィックスを使用して外部オブジェクトを指定します。

// 例1: 外部システムの商品情報を取得
// External_Product__x は外部オブジェクトのAPI参照名
// ExternalId は外部オブジェクトの標準フィールドで、外部システムのユニークIDにマッピングされます。
// Product_Name__c は外部システムの商品名にマッピングされたカスタムフィールドと仮定します。
SELECT Id, ExternalId, Product_Name__c, Price__c
FROM External_Product__x
WHERE Price__c > 100
LIMIT 50

上記のクエリは、Salesforceから外部データソースにODataクエリとして変換され、外部システムで実行されます。結果はSalesforceに返され、Salesforceレコードとして表示されます。

リレーションシップを介したクエリ

外部オブジェクトがSalesforce標準/カスタムオブジェクトと間接参照関係や外部参照関係を持っている場合、SOQLのサブクエリを使用して関連データを取得できます。

// 例2: 取引先に関連する外部オブジェクトの注文履歴を取得
// Account (取引先) が External_Order__x (外部注文) に対して間接参照関係を持っていると仮定します。
// Account.External_Account_ID__c が External_Order__x.Customer_External_ID__c にマッピングされているケース。
// External_Order__x は Customer_External_ID__c フィールドを持つ。
List<Account> accountsWithOrders = [
    SELECT Id, Name, (
        SELECT Id, ExternalId, Order_Number__c, Order_Date__c
        FROM External_Orders__r // 間接参照関係の子リレーション名 (通常は外部オブジェクトの複数形)
    )
    FROM Account
    WHERE Name LIKE 'Acme%'
];

for (Account acc : accountsWithOrders) {
    System.debug('Account Name: ' + acc.Name);
    if (acc.External_Orders__r != null) {
        for (External_Order__x order : acc.External_Orders__r) {
            System.debug('  Order Number: ' + order.Order_Number__c + ', Date: ' + order.Order_Date__c);
        }
    }
}

書き込み可能外部オブジェクトへのDML操作

書き込み可能外部オブジェクトが有効になっている場合、ApexからDML操作を実行することで、外部システムのデータを更新できます。

// 例3: 外部システムの商品在庫数を更新
// External_Product__x が書き込み可能として設定されていると仮定します。
// ExternalId は外部システムのプライマリキーにマッピングされています。
// Stock_Quantity__c は外部システムの在庫数にマッピングされています。
External_Product__x externalProduct = new External_Product__x();
externalProduct.ExternalId = 'PROD-XYZ-001'; // 外部システムの商品ID
externalProduct.Stock_Quantity__c = 150; // 新しい在庫数

try {
    update externalProduct; // DML操作が外部システムにプッシュされます
    System.debug('External product updated successfully!');
} catch (DmlException e) {
    System.debug('Error updating external product: ' + e.getMessage());
}

⚠️ 注意: DML操作が外部システムにプッシュされるため、外部システムのデータ整合性、トランザクション管理、エラー処理を慎重に設計する必要があります。Salesforceのトランザクションは外部システムのトランザクションと同期しない場合があります。

注意事項とベストプラクティス

Salesforce外部オブジェクトは強力な機能ですが、導入を検討する際にはいくつかの重要な注意事項とベストプラクティスを理解しておく必要があります。アーキテクトとしては、これらの要素を設計段階で考慮し、堅牢でスケーラブルなソリューションを構築することが求められます。

パフォーマンス (Performance)

外部オブジェクトはデータをリアルタイムで取得するため、パフォーマンスは外部システムの応答速度、ネットワーク遅延、そしてSalesforce Connectアダプターの効率に直接依存します。

外部システムの最適化：ODataエンドポイントまたはカスタムアダプターが接続する外部システムは、高速なクエリ応答と高い可用性を持つように最適化されている必要があります。インデックスの最適化やデータベースのチューニングが不可欠です。
ネットワーク遅延の考慮：Salesforce組織と外部システム間の物理的な距離やネットワーク構成は、遅延に大きな影響を与えます。可能な限り、地理的に近い場所にシステムを配置するか、専用のネットワーク接続を検討してください。
SOQLのフィルタリング：SOQLクエリのWHERE句は、可能な限り外部システム側で効率的に処理されるように設計します。外部システムでインデックスが貼られているフィールドをWHERE句に使用すると、パフォーマンスが向上します。Salesforce側でフィルターを適用すると、すべてのデータが転送された後にフィルタリングされるため、パフォーマンスが低下します。
クエリの制限：一度に大量のデータを取得するクエリは避けるべきです。必要最小限のフィールドを選択し、LIMIT句や効率的なWHERE句を活用してください。

セキュリティ (Security)

外部データへのアクセスは、Salesforce組織全体のセキュリティを確保する上で非常に重要です。

認証情報の管理：外部データソースへの認証には、指定ログイン情報（Named Credential）の使用を強く推奨します。これにより、認証情報をハードコードすることなく、安全に管理できます。
プロファイルと権限セット（Profile and Permission Set）：標準オブジェクトやカスタムオブジェクトと同様に、外部オブジェクトに対するアクセス権限（参照、作成、編集、削除）をプロファイルや権限セットで厳密に制御します。
外部システム側の権限：Salesforce Connectを介して外部システムにアクセスするユーザー（またはシステムユーザー）が、外部システム側で適切なデータアクセス権限を持っていることを確認します。

API制限 (API Limits)

Salesforce Connectを介した外部データへのアクセスには、SalesforceのAPI制限が適用されます。特に注意すべきはコールアウト制限です。

Salesforce Connectのコールアウト制限：Salesforce Connectは、外部システムへのコールアウト（Callout）として機能します。ApexのHTTPコールアウトと同様に、トランザクションあたりのコールアウト数、コールアウトの合計時間などに制限があります。大量のユーザーが同時に外部オブジェクトにアクセスする場合、これらの制限に抵触しないよう設計が必要です。
取得行数の制限：SOQLクエリで外部オブジェクトから取得できる行数にも制限があります。大量のデータを扱う場合は、ページネーション（Pagination）や段階的なデータ取得を考慮する必要があります。

データ型マッピング (Data Type Mapping)

外部システムのデータ型とSalesforceのデータ型を正確にマッピングすることは、データの整合性と表示の正確性を保つために重要です。

Salesforceでサポートされていない外部システムのデータ型（例：特定のバイナリデータ、XMLフィールド）は、Salesforce側で表示できないか、適切な型に変換するカスタムアダプターが必要になる場合があります。

検索とレポート (Search and Reporting)

外部オブジェクトは標準オブジェクトとは異なる振る舞いをすることがあります。

検索：デフォルトでは、外部オブジェクトはグローバル検索の対象外です。Salesforce Connect Search Sync を設定することで検索可能になりますが、完全なリアルタイム性や高度な検索機能は期待できない場合があります。より複雑な検索要件がある場合は、カスタム検索コンポーネントの実装を検討する必要があります。
レポート：外部オブジェクトは、標準レポートタイプでは制限がある場合があります。間接参照関係や外部参照関係が適切に設定されていれば、結合レポート（Joined Report）でSalesforceのデータと外部データを組み合わせることが可能ですが、集計関数などの利用には制限がある場合があります。

書き込み可能外部オブジェクト (Writable External Objects)

外部オブジェクトにDML操作を許可する場合、特に注意が必要です。

データ整合性：SalesforceでのDML操作が外部システムに即座に反映されるため、外部システム側のデータ整合性ルール、ビジネスロジック、トリガーなどに影響がないか慎重に評価します。
エラー処理：外部システムでの更新失敗は、SalesforceのDML例外として処理される必要があります。ユーザーに適切なフィードバックを提供し、必要に応じてロールバック戦略を検討します。

まとめとアーキテクチャ上の推奨事項

Salesforce外部オブジェクトは、リアルタイムデータアクセス、データ重複排除、Salesforceストレージコスト削減という観点から、現代のデータ統合戦略において非常に価値のあるツールです。しかし、その実装には慎重な設計と深い理解が求められます。アーキテクトとして、外部オブジェクトの導入を検討する際に以下の推奨事項を考慮することで、プロジェクトの成功確率を高めることができます。

外部オブジェクトの適用判断基準

外部オブジェクトが最適なソリューションであるかどうかを判断するには、以下の質問に答えることが重要です。

リアルタイム性が最優先か？：常に最新のデータが必要な場合、外部オブジェクトは優れた選択肢です。そうでない場合、ETLツールやバッチ処理によるデータ複製も検討すべきです。
データ重複を避けたいか？：Salesforce内にデータを複製したくない場合、外部オブジェクトはストレージとデータガバナンスの観点から有利です。
外部システムが信頼性とパフォーマンスを提供するか？：外部システムのダウンタイムや遅延は、Salesforceユーザーエクスペリエンスに直接影響します。外部システムの安定性と応答速度が極めて重要です。
複雑なSOQLクエリや高度なレポート作成が必要か？：外部オブジェクトは標準オブジェクトほど複雑なクエリやレポート機能をサポートしない場合があります。要件が非常に複雑な場合は、データの複製を検討するか、Salesforce内で集計オブジェクトを作成するなどの代替手段を検討してください。
Salesforce内でのデータの共有ルールがシンプルか？：外部オブジェクトの共有モデルは標準オブジェクトほど柔軟ではありません。複雑な共有ルールが必要な場合は、注意が必要です。

アーキテクチャ上の推奨事項

段階的な導入：まずは小規模なデータセットやクリティカルでないユースケースで外部オブジェクトを導入し、パフォーマンス、ユーザビリティ、そして外部システムへの影響を評価します。
ODataエンドポイントの最適化：外部システム側のODataエンドポイントは、クエリパラメータの効率的な処理、インデックスの使用、適切なページネーションの実装によって、Salesforce Connectからのリクエストに迅速に応答できるように設計・チューニングします。
Named Credentialの活用：外部データソースへの認証には必ずNamed Credentialを使用し、認証情報のセキュリティと管理の容易さを確保します。
カスタムアダプターの検討：標準のODataアダプターで要件を満たせない場合（例：特定の認証フロー、高度なデータ変換、非OData準拠のAPIへの接続など）は、Apexでカスタムアダプターを開発することを恐れないでください。ただし、開発コストとメンテナンス負荷が増大することを考慮し、費用対効果を評価します。
エラーハンドリングとモニタリング：特に書き込み可能外部オブジェクトを実装する場合は、外部システムでのエラーを適切に処理し、ユーザーにフィードバックを提供するメカニズムを構築します。Salesforce Connectの利用状況とパフォーマンスを継続的にモニタリングし、ボトルネックを特定して改善するプロセスを確立します。
ユーザーへの教育：外部オブジェクトの特性（例：リアルタイム性による遅延の可能性、特定の検索・レポート機能の制限）について、ユーザーに適切に教育し、期待値を管理します。

外部オブジェクトは、Salesforceをエンタープライズのデータハブへと進化させるための鍵となる技術です。適切な設計と運用により、企業はデータサイロを打破し、リアルタイムな洞察に基づいたより迅速で正確な意思決定を下すことが可能になります。アーキテクトとして、これらの考慮事項を戦略的に取り入れることで、外部オブジェクトの真の価値を最大限に引き出すことができるでしょう。

にゃんこのSalesforce日記

このブログを検索