設計判断の理由

なぜこのような複雑な共有設定アーキテクチャを選択したのか、その背景にあるビジネス要件と技術的判断について解説します。

根本的な設計選択

選択1: externalSharingModel = Private

決定内容

<CustomObject>
  <sharingModel>Private</sharingModel>
  <externalSharingModel>Private</externalSharingModel>
</CustomObject>

主要なビジネスオブジェクト（Design Family, Product, Vendor Brand）で、最も厳格な共有設定を採用。

ビジネス要件

マルチテナント完全分離

Brand A のデータ → Brand A のユーザーのみアクセス可能
Brand B のデータ → Brand B のユーザーのみアクセス可能

R.Design Brand Communityは、複数のブランド企業が同じプラットフォームを使用するB2Bマーケットプレイスです。各ブランドは独立した事業者であり、競合他社のデータを閲覧できてはいけません。

技術的な代替案との比較

結論

ビジネス要件（マルチテナント分離）を満たすには、Private設定が必須でした。技術的複雑さは、避けられないトレードオフです。

選択2: Community Userがレコード所有者

決定内容

各レコードの所有者（Owner）は、実際にそれを作成したブランドのCommunity Userに設定する。

Design Family レコード
  OwnerId: 005... (Brand A User1 - Community User)

検討した代替案

案A: Community Userが所有者（採用）

レコード作成者: Brand A User1 (Community User)
所有者: Brand A User1
    ↓ Sharing Set Settings
共有先: Brand A の他のユーザー (User2, User3)

メリット:

• ✅ データ所有権が明確
• ✅ Chatterでの自然なコラボレーション
• ✅ 監査証跡が正確（CreatedBy, LastModifiedBy）
• ✅ ビジネスプロセスとの整合性
• ✅ 将来的なデータ移行が容易

デメリット:

• ❌ 共有設定が複雑
• ❌ Sharing Set Settings必須

案B: 内部ユーザーが所有者（不採用）

レコード作成者: Brand A User1 (Community User)
所有者: Internal User (System Admin)
    ↓ Sharing Rules
共有先: Brand A のユーザー全員

メリット:

• ⚠️ 内部ユーザーが完全なコントロール権限
• ⚠️ Sharing Rulesがシンプル

デメリット:

• ❌ Chatterコラボレーションが不自然
• ❌ データ所有権が不明確
• ❌ 監査証跡が不正確
• ❌ レコード削除などの操作を内部ユーザーに依頼する必要
• ❌ “自分のデータ” という感覚がない

決定的な理由

1. Chatterでの@mentionとコラボレーション

【Community Userが所有者の場合】
Brand A User1: "@User2 このデザインを確認してください"
    ↓ User2 に通知
    ↓ User2 はレコードにアクセス
    ↓ Chatterで会話が続く ✅

【内部ユーザーが所有者の場合】
Brand A User1: "@User2 このデザインを..."
    ↓ レコードフィードへのアクセスが制限される可能性
    ↓ コラボレーションが不自然 ❌

R.Designでは、ブランド内のチームワークとリアルタイムコラボレーションを重視しています。Chatterは、その中核機能です。

2. レコード所有権による操作の違い

内部ユーザーが所有者の場合、Community Userは「編集権限を与えられただけの人」になり、本当の意味での管理者になれません。

3. ビジネスモデルとの整合性

R.Design Brand Communityは、B2Bマーケットプレイス的な性質を持ちます：

• 各ブランドは独立した事業者
• 各ブランドが自社のデータを管理
• プラットフォームはインフラを提供するのみ

このモデルでは、「各ブランドユーザーがデータを所有する」のが自然です。

4. 将来的な拡張性

もし将来、以下のような展開があった場合：

Brand A が自社のSalesforce組織に移行
  ↓
レコードオーナー = Brand A User であれば
  ↓
データ移行とOwnership移転が明確

内部ユーザーが所有者だと、移行時のOwnership移転が複雑になります。

結論

Community Userを所有者にする 選択は、ビジネス要件とユーザー体験を優先した結果です。技術的複雑さよりも、正しいビジネスロジックの実現を優先しました。

選択3: Owner_Account__c カスタムフィールド

決定内容

多くのオブジェクトに Owner_Account__c カスタムフィールドを追加し、共有判定に使用。

<CustomField>
  <fullName>Owner_Account__c</fullName>
  <label>Owner Account</label>
  <referenceTo>Account</referenceTo>
  <type>Lookup</type>
</CustomField>

なぜ必要だったのか

問題: Sharing Set Settingsの制約

Experience CloudのSharing Set Settingsでは、複数階層をまたいだ複雑なリレーションシップパスを使用できません。

❌ 作成できない共有ルール:

User.Contact.Account = Design_Family.Maker_Code__r.Owner.Account

（Owner を経由したAccount参照は不可）

✅ 作成可能な共有ルール:

User.Contact.Account = Design_Family.Maker_Code__r.Owner_Account__c

（直接ルックアップフィールド参照）

技術的な回避策

Vendor Brand (Maker_Code__c) に3つのAccount参照:

Owner_Account__c は、Sharing Set Settingsの技術的制約を回避するための専用フィールドです。

結論

カスタムフィールドの追加は、Sharing Set Settingsの制約を回避し、Account-based sharingを実現するための必然的な実装でした。

複雑さのトレードオフ

選択したもの

犠牲にしたもの

代替アーキテクチャの検討

案1: 別々のSalesforce組織

構成

Brand A → 独立したSalesforce組織
Brand B → 独立したSalesforce組織
Brand C → 独立したSalesforce組織

メリット

• ✅ 完全なマルチテナント分離
• ✅ 各ブランドが独立してカスタマイズ可能
• ✅ 共有設定がシンプル

デメリット

• ❌ コストが非常に高い（組織ごとにライセンス費用）
• ❌ マスターデータの共有が困難
• ❌ プラットフォーム全体の管理が困難
• ❌ ブランド間のコラボレーションが不可能

判定

❌ 不採用 - コストとマスターデータ共有の問題

案2: Experience Cloud Sites 分離

構成

同じSalesforce組織内で、ブランドごとに別々のExperience Cloud Siteを作成

メリット

• ✅ ブランドごとにUIをカスタマイズ可能
• ⚠️ ある程度のデータ分離

デメリット

• ❌ レコードレベルの分離は結局Sharing設定が必要
• ❌ Experience Cloud Site数に制限あり
• ❌ 管理が複雑
• ❌ コストが高い（Site数に応じた費用）

判定

❌ 不採用 - 根本的な問題（レコード分離）は解決しない

案3: 採用した設計（現状）

構成

1つのSalesforce組織 + 1つのExperience Cloud Site
  └─ Private OWD
  └─ Sharing Set Settings
  └─ Community Userが所有者

メリット

• ✅ コストが最も低い
• ✅ マスターデータの共有が容易
• ✅ プラットフォーム全体の管理が一元化
• ✅ 柔軟な共有設定（必要に応じてブランド間共有も可能）

デメリット

• ❌ 共有設定が複雑
• ❌ メンテナンスコストが高い

判定

✅ 採用 - コスト、機能、拡張性のバランスが最適

この設計が適しているケース

✅ 適している要件

1. B2Bマーケットプレイス

   • 複数の独立した事業者が同じプラットフォームを使用
   • 各事業者のデータを完全に隔離する必要がある

2. コラボレーション重視

   • 同じ組織内のユーザー間でリアルタイムコラボレーション
   • Chatterでの@mentionと会話

3. データ所有権の明確化が必要

   • 規制要件やコンプライアンス
   • 将来的なデータ移行の可能性

4. コスト最適化

   • 各事業者に独立したSalesforce組織を提供するのはコスト的に不可能

❌ 適していない要件

1. シンプルな共有要件

   • 全員が全データを閲覧可能
   • 複雑なマルチテナント分離が不要

2. メンテナンス人員が限られている

   • トラブルシューティングやメンテナンスに十分なリソースを割けない

3. 頻繁な構成変更が必要

   • ビジネスルールが頻繁に変わる
   • 共有設定の変更コストが高い

学んだ教訓

1. Customer Community Licenseの制約を理解する

2. カスタムフィールドによる回避策

複雑なリレーションシップパスは、カスタムフィールドでフラット化することで、Sharing Set Settingsで使用可能になります。

3. ドキュメント化の重要性

複雑な共有設定は、徹底的なドキュメント化が必須です。そうしないと、数ヶ月後に誰も理解できなくなります。

4. テストの重要性

新規ブランドをオンボーディングする際は、必ず以下をテスト：

• 自ブランドのレコードにアクセス可能か
• 他ブランドのレコードにアクセス不可か
• Chatterで@mentionが機能するか

将来的な改善案

短期的な改善

1. 診断ツールの作成

   // 特定のレコードに対して、ユーザーがなぜアクセスできる/できないかを診断
   AMC_SharingDiagnosticTool.analyzeAccess(recordId, userId);

2. オンボーディングチェックリストの自動化

   • Flowで新規ブランド追加時の設定を一部自動化

3. ドキュメントの継続的更新

   • 新しいSharing Ruleを追加する際は、必ずドキュメントを更新

長期的な検討

1. Customer Community Plus への移行検討

   • より多くのカスタムオブジェクトにアクセス可能
   • Reports & Dashboardsが使用可能

2. Apexによる共有ロジックの一部自動化

   • 特定の条件下で、Apex Managed Sharingを使用

3. Experience Cloud の新機能活用

   • Salesforceが提供する新しい共有機能を継続的に評価

まとめ

この設計選択は正しかったのか？

はい、ビジネス要件を満たすためには、この選択が最適でした。

理由:

1. マルチテナント完全分離を実現（ビジネス要件）
2. 同一ブランド内でのリアルタイムコラボレーション（ユーザー体験）
3. データ所有権の明確化（法的要件）
4. コスト最適化（経済的要件）

トレードオフ:

• 技術的複雑さは増したが、これは上記要件を満たすための必然的な結果

関連ドキュメント

• 前のステップ: ライセンスとプロファイル - ユーザー設定
• 次のステップ: トラブルシューティング - 問題診断

更新履歴

• 2026年1月21日: 初版作成