フロントエンド技術の進化とAgentforceの登場により、Salesforce開発のアーキテクチャが大きな転換期を迎えています。
最新のAPI仕様において、データやAIエージェントの処理を外部アプリケーションへ露出させる「Headless 360」の概念が本格的に浸透し始めました。開発者はAPIやMCP（Model Context Protocol）ツールを介して、Salesforceのプラットフォーム機能に任意のシステムからシームレスにアクセスできるようになっています。
このような技術的背景から、アーキテクトやCTOの間で「独自のReactやNext.jsアプリでUIを自由に構築できるのであれば、UIのレンダリングエンジンとしてのExperience Cloudはもはや不要なのではないか？」というアーキテクチャ上の問いが生まれるのは自然な流れです。
結論から述べます。Experience Cloudは不要になるのではなく、「完全なヘッドレス構成」と明確に棲み分けられ、プラットフォーム内での役割が再定義されます。
本記事では、公式ドキュメントに基づくアーキテクチャの仕様（事実）と、システム運用のライフサイクルや総所有コスト（TCO）を見据えたトレードオフ（見解）を整理し、自社の要件においてどちらを選択すべきか、5つの観点から解説します。
Headless 360 ✕ ヘッドレスID の基本アーキテクチャ（事実）
まず、Experience Cloudのエクスペリエンスビルダーを使わずに「完全なヘッドレス構成」を実現するための仕組みを整理します。
Headless 360単体では、あくまでデータやロジックへのアクセス経路が提供されるに過ぎません。外部のReactアプリなどからSalesforceのデータに安全にアクセスするには、「誰がアクセスしているか」を証明する堅牢な認証基盤が必要です。ここで重要になるのが、Experience Cloudがバックエンド機能として提供するヘッドレスID（Headless Identity）です。
- 認証の委譲: 外部のカスタムUIは、ヘッドレスIDのAPI（Headless Login等）を呼び出し、SalesforceからOAuth 2.0に基づくアクセストークンを取得します。
- アイデンティティの確立: 発行されたトークンは、Salesforce内の実在する外部ユーザー（Customer Community等）のレコードに完全に紐づいています。
- ガバナンスの自動適用: このトークンを使用してHeadless 360（Agentforceの会話クライアント等）を呼び出すと、Salesforceのコアレイヤーで共有ルール、共有セット、項目レベルセキュリティ（FLS）が強制的に適用されます。
これにより、「UIは100%外部の技術で構築しつつ、認証やデータへのアクセス制御はSalesforceのコアプラットフォームに委ねる」というセキュアでコンポーザブルな構成が、標準機能によって保証されます。
【比較表】アーキテクチャ選定を左右する5つの観点
この強力なヘッドレス構成が可能になった現在、Experience Cloudの標準機能（LWRアーキテクチャ）を使用するアプローチと比較して、どのようなトレードオフが発生するのでしょうか。
まずは、システム設計時に意思決定者が考慮すべき5つの観点を比較表で整理します。いずれもデータ源泉にSalesforce CRMを含むものと仮定し、「ヘッド」部分をSalesforce外部で開発するのかExperience Cloudで構築するのかを天秤にかけています。
| 比較観点 | Headless 360（完全ヘッドレス構成） | Experience Cloud（標準LWR構成） |
|---|---|---|
| 1. UI自由度 | 無限（100% 自由） React, Next.js, モバイルアプリ等を使用可能。プラットフォーム特有の制約なし。 | 一定の枠組みあり LWRとLWCに準拠。SLDSやLWS（Lightning Web Security）の制約を受ける。 |
| 2. 開発リソース | 一般的なWebエンジニア 市場に多いReactエンジニア等をアサイン可能。Salesforce固有のUI知識は最小限。 | Salesforceエンジニア LWC、Apex、Experience Cloudの標準機能やセキュリティモデルに精通した人材が必要。 |
| 3. セキュリティ | コア層で担保（UI側は実装依存） データアクセス権限は自動適用されるが、フロントエンドのセッション管理等は自前での実装が必要。 | フルマネージド（強固） 認証フロー、MFA、セッション管理、クリックジャッキング対策等が標準で完備されている。 |
| 4. インフラ/ライセンス | 二重のコスト構造 Salesforceのユーザーライセンスに加え、独自UIをホストするインフラ（AWS等）の費用と運用保守が発生。 | Salesforceに一元化 インフラはSalesforceが完全ホスト。ライセンス費用内で運用が完結する。 |
| 5. ビジネス部門の運用 | エンジニア依存（低アジリティ） デザイン変更や文言修正でも、都度エンジニアによるコード改修とデプロイが必要。 | ノンプログラミング（高アジリティ） エクスペリエンスビルダーを用いて、非エンジニア（マーケター等）が自律的に運用可能。 |
以下に、それぞれの観点における技術的背景と運用フェーズへの影響（見解）を深掘りします。
1. UIの自由度とデータ源泉の柔軟性
- 完全ヘッドレス構成: アーキテクチャ上の最大のメリットは、LWS（Lightning Web Security）の制約を完全に回避できる点です。最新のサードパーティ製JavaScriptライブラリ、複雑なWebGLアニメーションの導入、あるいは既存のiOS/Androidネイティブアプリへの統合が自由に行えます。Salesforceは数あるAPIの一つとして扱われます。
- Experience Cloud（LWR）: LWC（Lightning Web Components）の作法やサンドボックス内での開発となります。CRMデータの表示には最適化されていますが、極度に特殊なUX要件や、外部システムのデータを大量にマッシュアップするような画面構成には不向きな場合があります。
2. 開発リソースの調達とベンダーロックイン
- 完全ヘッドレス構成: ReactやNext.jsに精通したフロントエンドエンジニアを中心にチームを編成できます。これにより、開発リソース調達のボトルネックが解消され、UI層における特定のプラットフォームへのベンダーロックインを防ぐことができます。
- Experience Cloud（LWR）: LWCやExperience Cloudの権限設定などに精通した、比較的市場に少ないSalesforceエンジニアへの依存度が高まります。
3. セキュリティの責任分界点
Salesforceへのデータアクセス（バックエンド側）のセキュリティは、どちらの構成も同等に堅牢です。違いは「フロントエンド側の脆弱性対策」を誰が担保するかという責任分界点にあります。
- 完全ヘッドレス構成: ログイン画面のセッション固定攻撃対策、CSRF対策、アクセストークンのセキュアな保持（Cookie属性の設定など）、およびOAuth認可コードフローにおけるPKCE（Proof Key for Code Exchange）の実装など、フロントエンド固有のセキュリティ設計はすべて開発チームが自前で実装し、責任を負う必要があります。
- Experience Cloud（LWR）: これらWebアプリケーションの標準的な脆弱性対策は、Salesforceのプラットフォーム側がフルマネージド環境として自動的に提供・アップデートします。
4. インフラ保守とライセンスの総所有コスト（TCO）
「ヘッドレスにすればSalesforceのライセンス費用が浮く」というのはよくある誤解です。ヘッドレスIDを利用して外部ユーザーを認証する以上、Experience Cloudのログインベース等のライセンスは通常通り消費されます。
- 完全ヘッドレス構成: Salesforceのライセンス費用に加え、外部UIをホストするインフラ（Vercel、AWSなど）の稼働費、およびそのインフラの死活監視・保守運用コスト（SREリソース）が新たに発生します。
- Experience Cloud（LWR）: UIのホスティング、CDN、SSL証明書の更新などはSalesforceインフラ内で完結するため、インフラ管理の手間と隠れたコストを大幅に抑制できます。
5. ビジネス部門のアジリティ（最大の分岐点）
システムリリース後の「運用フェーズ」における俊敏性が、アーキテクチャ選定の最も重要な決定要因となります。
- 完全ヘッドレス構成: UIがReact等のコードで構成されるため、ちょっとしたバナー画像の差し替えやキャンペーンページの追加であっても、毎回フロントエンドエンジニアへの依頼、コード修正、テスト、デプロイ作業が必要になります。別途ヘッドレスCMSを導入する解決策もありますが、システムはより複雑化します。
- Experience Cloud（LWR）: 「エクスペリエンスビルダー」により、マーケティング担当者や業務部門がノンプログラミングで自律的にサイトを更新・管理できます。市場の変化に合わせた迅速なコンテンツ配信が可能です。
自社はどちらを選ぶべきか？（見解）
これらの事実と総所有コスト（TCO）のトレードオフを踏まえ、それぞれのアーキテクチャを採用すべきユースケースを導き出します。
【Experience Cloud（LWR）を採用すべきケース】
- 顧客サポートポータルやB2Bコマースなど、Salesforce内のCRMデータの表示・操作が主要な要件である。
- リリース後、ビジネス部門が主導してコンテンツを頻繁に更新・追加するアジャイルな運用体制を目指している。
- インフラの運用保守やフロントエンドの脆弱性対策を自社で継続的に担保する専任リソースを持たない。
【完全ヘッドレス（Headless 360 ✕ ヘッドレスID）を採用すべきケース】
- すでに大規模な自社のWebサービスやネイティブアプリが稼働しており、そこにAgentforceやSalesforceのデータをシームレスに組み込みたい。
- コンシューマー向け（B2C）サービスなどで、ブランドの世界観をミリ単位で表現するため、LWCの枠組みを超えた高度なUX/UIが絶対条件である。
- 独立したフロントエンド開発チームとインフラ運用体制（SRE）が存在し、自社で継続的なデプロイサイクルを回せる。
具体的な実装方法は以下の記事を参照ください。
まとめ
Headless 360の成熟は、「SalesforceはUIの制約が厳しい」という過去の常識を覆しました。意思決定者は、フルマネージドで堅牢なExperience Cloudという基盤を選択することも、独自の最新技術スタックでコンポーザブルなヘッドレス構成を組むこともできるという、強力な選択肢を手に入れました。
技術選定において最も重要なのは、構築時の「開発のしやすさ」や「自由度」だけに目を奪われることなく、「リリース後のビジネス運用を誰がどのように担い、システムライフサイクル全体でどれだけのコストがかかるのか」を見極めることです。自社の組織体制とビジネス要件に最適なアーキテクチャを選択してください。
参考URL
What Salesforce Headless 360 Means For Developers
Headless Identity for Customers and Partners
Agentforce – Hosted MCP Servers
読者の声