この記事はバージョン Winter ’26 において執筆しています。
現在の動作と異なる場合がありますので、ご認識おきください。
Salesforce Experience Cloud が、単なる「Webサイト作成ツール」と決定的に異なる点。それは、バックエンドにある強力なCRMデータ（顧客情報）とリアルタイムに連動していることです。
「すべてのユーザーに同じ画面を見せる」のであれば、わざわざSalesforceを使う必要はありません。ログインしたユーザーの属性、過去の購入履歴、あるいは契約ランクに応じて、「その人だけに見せるべき情報」を出し分けることこそが、Experience Cloudの真骨頂です。
この記事では、サイトのパーソナライゼーションを実現する「利用者」の基本から、間違いやすい「権限」による制御テクニック、そしてLWRサイト特有の最新仕様までを解説します。
表示制御の「2つのアプローチ」
画面を出し分ける際、管理者は大きく分けて2つの武器を持っています。これらを適切に使い分けることが、メンテナンス性の高いサイト構築の第一歩です。
アプローチA：コンポーネントの表示/非表示
「同じページの中で、部品だけを出し入れする」 手法です。
- 挙動: ベースとなるページレイアウトは共通ですが、「キャンペーンバナー」や「管理者用メニュー」といった特定のコンポーネントだけが、条件に合致した人にのみ表示されます。
- 推奨: メンテナンス性が高いため、基本的にはこのアプローチを優先します。
アプローチB：ページバリエーション
「ページそのものを丸ごと切り替える」 手法です。
- 挙動: 例えば「ホーム」というページにアクセスした際、一般会員には「Home A（青色基調のデザイン）」、VIP会員には「Home B（金色基調、全く異なるレイアウト）」を表示します。
- 推奨: ユーザー属性ごとに全く異なる体験（UX）を提供したい場合に限定して使用します。
実務においては、9割のケースで「アプローチA（コンポーネント制御）」で十分です。
ページバリエーションは強力ですが、修正が発生した際に「Home AもHome Bも直さないといけない」という二重管理の罠に陥りやすいためです。
まずはコンポーネント単位の制御で実現できないか検討し、どうしてもレイアウト自体を大きく変えたい場合のみバリエーションを使用するのが賢明です。
利用者の作り方と4つの基本条件
表示制御を行うには、まず「誰に」見せるかを定義する「利用者」を作成します。
例えば利用者を作成するひとつの方法として、コンポーネントをクリックした後に、▼ → 利用者の部分にある割り当てをクリックします。
コンポーネントの表示制御に使用できる条件は、以下の4つが基本です。
- プロファイル (Profile)
- 特定のプロファイルを持つユーザー（例: Customer Community User）。
- 場所 (Location)
- ユーザーのIPアドレスに基づく地域。
- ユーザー (User)
- ログインユーザー自身の属性（例:
User.Department,User.IsActiveなど）。
- ログインユーザー自身の属性（例:
- 権限 (Permission)
- ユーザーが特定の「権限」を持っているか。
⚠️ 注意：レコードの値を使った制御について
「商談のフェーズが Closed Won の時だけ表示したい」といった、表示中のレコードの値に基づく制御は、「レコード詳細ページ」（Record Detail Page）に配置したコンポーネントでのみ利用可能です。
ホーム画面や一覧ページでは、現在表示しているレコードが特定できないため、この条件は選べませんのでご注意ください。
「権限」設定の落とし穴とベストプラクティス
条件の「権限」で選択できるリストには、「ロールの管理」や「レポートの実行」といった個別の権限（Standard Permissions）が表示されます。「権限セット名」そのものを直接選ぶことはできません。
特定の権限セット（例：Dealer Group）を割り当てた人にだけ表示したい場合は、以下のカスタム権限テクニックを使用するのが鉄則です。
- 設定: Salesforce設定で「カスタム権限」を作成する（例：
Access_Dealer_Portal）。 - 紐付け: 対象の「権限セット」のカスタム権限領域から、そのカスタム権限を有効にする。
- ビルダー: 利用者の条件で「権限」を選択し、作成したカスタム権限名（
Access_Dealer_Portal）を指定する。
これにより、プロファイルに依存せず、かつ権限セット単位で柔軟な表示制御が可能になります。
「利用者」を適用できる4つの要素
作成した「利用者」設定は、コンポーネント以外にも適用可能です。適用範囲を知ることで、サイトの表現力が広がります。
- コンポーネント (Components)
- 特定のバナーやリストのみを表示/非表示にする。最も一般的な使い方です。
- ページバリエーション (Page Variations)
- ページ全体を切り替える際に使用します。
- ブランドセット (Branding Sets)
- サイトの「色」や「フォント」の定義セットを切り替えます。
- 例：A社社員には「赤テーマ」、B社社員には「青テーマ」でサイトを表示する。
- テーマレイアウト (Theme Layout)
- ヘッダー、フッター、そしてナビゲーションメニューを含む外枠の設定です。
- 例：代理店ユーザーには「専用メニュー」を表示したい場合、代理店用のテーマレイアウトを作成し、そこに利用者を割り当てることで実現します。
【LWR】ビルダーの表示制御ができること・できないこと
LWRサイトには「式ベースの表示ルール」という機能がありますが、これには重要な制約があります。 それは、条件として選択できるリソースが「ユーザー (User)」に限られるという点です。
- できること（User属性）:
- 「役職がマネージャーの人にだけ表示する」
- 「東京在住の人にだけ表示する」
- できないこと（Data属性）:
- 「商談フェーズが
Closed Wonの時だけ表示する」 - 「CMSニュースのカテゴリが
重要の時だけ表示する」
- 「商談フェーズが
内部のLightningページ（App Builder）とは異なり、LWRのビルダー上では「現在表示しているレコードの値」を条件に使うことはできません。
【LWR】データ駆動の表示制御は LWC (lwc:if) で実装せよ
LWRサイトにおいては上記の制約があるため、コンテンツの中身やレコードの値に基づいて表示を切り替えたい場合、LWC（Lightning Web Components）の開発が必須となります。
LWC実装パターン
- LWCの
js-meta.xmlでlightning__RecordPageなどをターゲットにし、recordIdを受け取れるようにする。 - JavaScriptコントローラで、
@wire(getRecord)を使用してレコードの値を読み込む。 - HTMLテンプレートで
lwc:ifを使用して出し分ける。
/* JavaScript */
// 例：商談フェーズが 'Closed Won' の時だけ true になるゲッター
get isWon() {
return getFieldValue(this.record.data, STAGE_NAME_FIELD) === 'Closed Won';
}<!-- html -->
<template lwc:if={isWon}>
<div class="success-banner">成約おめでとうございます！</div>
</template>結論：表示条件が「人」か「データ」か。
「人」で出し分けるなら ビルダー設定。
「データ」で出し分けるなら LWCコード。
この使い分けが、LWRサイト設計の指針になると言えるでしょう。
まとめ
Experience Cloudにおけるパーソナライゼーションは、顧客満足度を高める強力なツールですが、複雑にしすぎると「誰に何が見えているのか管理者が把握できない」というカオスを招きます。
- Auraサイトにおいて、基本はページではなくコンポーネント単位の表示制御で対応する。
- Auraサイトにおいて、権限による条件はプロファイルではなくカスタム権限を活用して柔軟に管理する。
- LWRサイトにおいて、表示条件が「人」か「データ」かによって実装方法を見極める。
これらを意識して、メンテナンスしやすく、かつユーザーに寄り添ったサイト設計を目指してください。
参考URL
LWR サイトの式ベースの表示ルール (Expression-Based Visibility)
読者の声