Salesforce Experience Cloudアーキテクチャのマスターガイド：スケーラビリティ、セキュリティ、ライセンスの設計

執筆者：Salesforce アーキテクト

背景と適用シナリオ

Salesforce Experience Cloud（旧称 Community Cloud）は、顧客、パートナー、従業員といった様々なステークホルダーと繋がり、ブランド化されたデジタル体験を構築するための強力なプラットフォームです。顧客向けのセルフサービスポータルから、パートナーとの協業を促進する PRM (Partner Relationship Management) サイト、従業員間のコラボレーションスペースまで、その活用範囲は多岐にわたります。しかし、その強力な機能性と柔軟性の裏側には、複雑なアーキテクチャ設計の必要性が潜んでいます。

Salesforce アーキテクトとして、我々の責務は単にサイトを構築することではありません。ビジネス要件を、スケーラブルで、セキュアで、かつ将来的な拡張にも耐えうる堅牢な技術ソリューションに落とし込むことです。不適切なアーキテクチャ設計は、パフォーマンスの低下、セキュリティ脆弱性、ライセンスコストの増大、そして最終的にはユーザーエクスペリエンスの著しい悪化を招きます。本記事では、Experience Cloud のアーキテクチャを設計する上で最も重要な３つの柱である「ライセンスモデル」「データセキュリティ」「パフォーマンス」に焦点を当て、アーキテクトの視点からその原理とベストプラクティスを深く解説します。

原理の説明

成功する Experience Cloud の実装は、盤石な設計思想に基づいています。ここでは、アーキテクトが意思決定を行うべき中核的な要素を分解して説明します。

1. ユーザーライセンスモデルの選定

Experience Cloud の設計における最初の、そして最も重要な分岐点の一つがユーザーライセンスの選定です。ライセンスは、ユーザーがアクセスできる機能、オブジェクト、そして共有モデルの範囲を決定づけるため、初期段階での適切な選択がプロジェクト全体のコストと拡張性を左右します。主要なライセンスタイプを理解することが不可欠です。

・Customer Community: 大量の外部ユーザー（B2Cシナリオなど）向けに設計されたライセンスです。ナレッジ記事の参照やケースの起票といった、比較的シンプルなセルフサービス機能に適しています。ロール（役割）階層を持たず、共有は主に Sharing Set（共有セット）に依存します。コスト効率が最も高いライセンスです。

・Customer Community Plus: Customer Community の機能に加え、レポートやダッシュボードへのアクセス、高度な共有（ロール、共有ルール）が可能になります。取引先や取引先責任者レコードへのアクセス権限をより詳細に制御したい場合に適しています。B2B シナリオでの顧客ポータルなどに利用されます。

・Partner Community: パートナー（代理店、再販業者など）との協業を目的とした最も高機能なライセンスです。リード、商談、キャンペーンといった Sales Cloud の主要オブジェクトへのアクセス権を持ち、Customer Community Plus の全ての機能を含みます。パートナーエコシステムを構築する PRM サイトに最適です。

・External Apps: 高度にカスタマイズされたデジタル体験を構築するためのライセンスです。Salesforce の標準オブジェクトへのアクセスは限定的ですが、カスタムオブジェクトを多用し、独自のビジネスロジックを展開するアプリケーションに適しています。

アーキテクトは、ユーザーが実行する必要のあるビジネスタスクを詳細に分析し、「どのオブジェクトに」「どのような権限レベルで」アクセスする必要があるかを明確にした上で、必要最小限かつ最適なライセンスを選択する責任を負います。

2. データセキュリティと共有モデル

Experience Cloud は外部ユーザーに組織のデータへのアクセスを許可するため、セキュリティモデルの設計は最優先事項です。内部ユーザーとは全く異なるアプローチが求められ、ここでの設計ミスは情報漏洩に直結する可能性があります。

・外部組織の共有設定 (External Organization-Wide Defaults): 全てのセキュリティ設計の基礎となります。内部ユーザー向けの OWD とは別に、外部ユーザー向けの OWD を設定します。ベストプラクティスは、全てのオブジェクトに対して「非公開 (Private)」に設定し、必要に応じてアクセス権を付与していく「最小権限の原則 (Principle of Least Privilege)」を徹底することです。

・共有セット (Sharing Sets): Customer Community ライセンスユーザーにレコードへのアクセス権を付与するための主要なメカニズムです。ユーザーの取引先または取引先責任者レコードから、対象オブジェクトのレコードへの参照関係（または間接的な参照関係）に基づいてアクセスを許可します。例えば、「ユーザーの取引先に紐づく全てのケース」へのアクセスを許可する、といった設定が可能です。

・共有ルールとロール階層 (Sharing Rules and Role Hierarchy): Customer Community Plus や Partner Community ライセンスでは、アカウントレコードの下に最大３階層のロール階層を構築できます。これにより、パートナー企業のマネージャーが部下のレコードを閲覧する、といった階層に基づいたアクセス制御が可能になります。共有ルールと組み合わせることで、より柔軟なデータ共有が実現します。

・Apex による共有管理 (Apex Managed Sharing): 標準の共有機能では実現不可能な、複雑で動的な共有要件に対応するための最終手段です。Apex コードを使って、オブジェクトの共有レコード（Share object）を直接作成・削除し、プログラム的にアクセス権を制御します。アーキテクトは、この手法のパフォーマンスへの影響とメンテナンスコストを慎重に評価する必要があります。

3. パフォーマンスとスケーラビリティの考慮事項

サイトのパフォーマンスはユーザーエクスペリエンスに直結します。特に、何十万、何百万というユーザーがアクセスする可能性のある B2C サイトでは、初期設計段階からのパフォーマンス考慮が不可欠です。

・ページの読み込み速度: Lightning Web Components (LWC) を最適化し、サーバーへのデータ要求（Apex コール）を最小限に抑えることが重要です。画像などの静的リソースには Salesforce CDN（コンテンツ配信ネットワーク）を活用し、クライアント側でのレンダリングを高速化します。

・データ量の考慮: 大量のデータ（特に単一の取引先に紐づく子レコードが数万件を超えるようなケース）は、共有ルールの再計算やクエリのパフォーマンスに影響を与えます。これは「データスキュー (Data Skew)」として知られており、アーキテクトはデータモデル設計の段階でこれを予見し、回避策（例：レコード所有権の分散、アーカイブ戦略）を検討する必要があります。

・ガバナ制限 (Governor Limits): Experience Cloud ユーザーの API コール数や Apex 実行時間には、内部ユーザーとは異なる、より厳しい制限が課せられています。インテグレーションや複雑なカスタム処理を設計する際は、これらの制限を常に念頭に置き、効率的なコードを実装するよう開発チームに指示する必要があります。

示例代码

ここでは、標準の共有機能では対応できない複雑な要件を満たすために、アーキテクトが設計判断を下すことがある「Apex による共有管理 (Apex Managed Sharing)」のコード例を示します。この例では、特定のプロジェクト（`Project__c`）レコードを、関連するパートナーユーザーにプログラムで共有します。

このコードは、トリガーやコントローラークラス内で実行されることを想定しています。`RowCause` にカスタムの理由（`My_Custom_Cause__c`）を指定することで、レコード所有者が変更されてもこの共有設定が削除されないようにしています。これは Apex Managed Sharing の重要なベストプラクティスです。

// このコードは、特定のプロジェクトレコードへのアクセス権を
// プログラムで付与する方法を示します。

// 共有したいプロジェクトレコードのIDを取得
Id projectId = 'a01XXXXXXXXXXXXXXX';
// アクセスを許可したいパートナーユーザーのIDを取得
Id partnerUserId = '005XXXXXXXXXXXXXXX';

// 共有ルールの理由（RowCause）を定義します。
// これは事前に「Project__c」オブジェクトの共有の理由として設定しておく必要があります。
Schema.Project__Share.RowCause projectShareReason = Schema.Project__Share.RowCause.My_Custom_Cause__c;

// 共有レコード（Share Object）のインスタンスを作成
Project__Share projectSharing = new Project__Share();

// 親レコードID（共有対象のレコードID）を設定
projectSharing.ParentId = projectId;

// アクセスを許可するユーザーまたはグループのIDを設定
projectSharing.UserOrGroupId = partnerUserId;

// アクセスレベルを設定（'Read' または 'Edit'）
projectSharing.AccessLevel = 'Read';

// 共有の理由を設定
// これにより、手動での共有とは区別され、所有者変更時に自動削除されなくなります。
projectSharing.RowCause = projectShareReason;

try {
    // 共有レコードをデータベースに挿入
    Database.SaveResult saveResult = Database.insert(projectSharing, false);

    if (saveResult.isSuccess()) {
        System.debug('プロジェクトレコードの共有に成功しました。ID: ' + saveResult.getId());
    } else {
        // エラー処理
        for (Database.Error err : saveResult.getErrors()) {
            System.debug('共有エラー: ' + err.getStatusCode() + ': ' + err.getMessage());
            System.debug('エラーフィールド: ' + err.getFields());
        }
    }
} catch (Exception e) {
    System.debug('共有レコードの挿入中に例外が発生しました: ' + e.getMessage());
}

注意事項

Experience Cloud のアーキテクチャを設計する際には、以下の点に特に注意を払う必要があります。

・権限 (Permissions): プロファイル (Profile) と権限セット (Permission Set) の役割を明確に区別し、権限セットを中心とした権限付与モデル（Permission Set-led model）を採用することを強く推奨します。特に、誰でもアクセス可能なサイトの「ゲストユーザー (Guest User)」プロファイルの権限は、Salesforce のセキュリティアップデートにより年々厳格化されており、意図しないデータ公開を防ぐために定期的なレビューが不可欠です。

・API 制限 (API Limits): Experience Cloud ユーザーは、内部ユーザーと比較して API コール数の上限が低く設定されています。外部システムとの連携を設計する際は、API コールを効率化（一括処理など）する、あるいはキャッシュ機構を導入するなどの対策を講じ、制限に抵触しないよう注意深く設計する必要があります。

・ライセンスコンプライアンス (License Compliance): ユーザーに必要以上の機能を持つライセンスを割り当てることは、不要なコスト増に繋がります。定期的にユーザーのアクティビティを監査し、ライセンスタイプがそのユーザーの実際の利用状況と一致しているかを確認するプロセスを確立することが重要です。

まとめとベストプラクティス

Salesforce Experience Cloud のアーキテクチャ設計は、単なる機能の実装を超えた、戦略的な思考を要求されるタスクです。ライセンス、セキュリティ、パフォーマンスという３つの柱を常に念頭に置き、ビジネス要件と技術的な制約の間で最適なバランスを見出すことが、Salesforce アーキテクトの重要な役割です。

以下に、Experience Cloud プロジェクトを成功に導くためのアーキテクチャ上のベストプラクティスをまとめます。

1. 要件定義の徹底: 誰が、何を、どのように利用するのかを詳細に定義し、それをライセンスタイプと共有モデルに正確にマッピングします。

2. 最小権限の原則の遵守: 常に最も制限の厳しい設定からスタートし、ビジネス要件を満たすために必要な権限を、共有セット、共有ルール、権限セットを用いて段階的に付与します。

3. スケーラビリティを前提とした設計: 将来のユーザー数やデータ量の増加を見越して、データスキューを回避するデータモデルや、効率的なクエリを発行するコンポーネントを設計します。

4. 標準機能の最大限の活用: メンテナンス性とアップグレード性を考慮し、可能な限り Apex による共有管理のようなカスタム実装を避け、標準の共有機能を優先して利用します。

5. 定期的なセキュリティとパフォーマンスのレビュー: 一度構築して終わりではなく、Salesforce のリリースやビジネスの変化に合わせて、定期的にセキュリティ設定やパフォーマンスを監査し、最適化を続けます。

これらの原則に従うことで、単に機能するだけでなく、ビジネスと共に成長し、ユーザーに真の価値を提供し続けることができる、堅牢で持続可能な Experience Cloud を構築することが可能となります。

にゃんこのSalesforce日記

このブログを検索