免責事項: 本報告書の内容は、執筆時点でのSalesforceの仕様および公開ドキュメントに基づいています。クラウドプラットフォームの機能やUIは頻繁にアップデートされるため、実際の作業にあたっては必ずSalesforceの公式ヘルプ(Salesforce Help)やリリースノートも併せて参照することを強く推奨します。
- はじめに：なぜカスタムドメインが必要なのか
- カスタムドメイン導入の技術的障壁と解決策
- アーキテクチャ解説：Salesforce CDNと「シングル証明書」
- 実装フェーズ1：事前準備（サブドメイン運用の推奨）
- 実装フェーズ2：【本番】Salesforce組織でのドメイン登録
- 実装フェーズ3：DNSレコードの設定（最重要プロセス）
- 実装フェーズ4：【本番】プロビジョニングと有効化
- 実装フェーズ5：【本番/Sandbox】サイトとの紐付けとSEO設定
- 実装フェーズ6：【本番/Sandbox】完成したサイトドメインの表示を確認
- 運用上の絶対ルール：DNSレコードを削除しないこと
- Sandbox環境でのテスト
- まとめ
- 参考URL
はじめに：なぜカスタムドメインが必要なのか
Salesforce Experience Cloudは、顧客、パートナー、従業員をつなぐデジタルプラットフォームとして進化を続けています。企業がこのプラットフォームを利用してポータルサイトやヘルプセンター、Eコマースストアを構築する際、最も初期に直面する課題の一つが「URLのブランディング」です。
デフォルトで割り当てられる *.my.site.com や *.force.com といったドメインは機能的ですが、ビジネスの現場では以下のリスクを孕んでいます。
- ブランドの一貫性の欠如: 顧客は企業名（例: Example Inc.）のサイトにアクセスすることを期待しているが、URLに force.com や site.com が含まれていると、第三者のサービスに飛ばされたと認識し、離脱率の上昇を招く可能性がある。
- SEOへの悪影響: 検索エンジンはドメインの信頼性を評価する役割を持つ。共有ドメインは固有のドメインオーソリティを構築しにくく、検索順位の最適化において不利になる場合がある。
- セキュリティ認識: 近年、サイバーセキュリティへの意識向上に伴い、ユーザーはURLの正当性を厳しくチェックする傾向にある。自社ドメイン配下での運用は、正規のサービスであることを証明する最も基本的な手段である。
本記事では、セキュリティとパフォーマンスを最大化するために推奨される「Salesforce CDN」オプションを使用したカスタムドメイン（例: www.example.com）の実装手順を解説します。単なる手順書ではなく、「裏側で何が起きているのか」というアーキテクチャもあわせて理解していきましょう。
カスタムドメイン導入の技術的障壁と解決策
カスタムドメインの導入は、従来、高度なITスキルを要する作業でした。SSL証明書の購入、CSR（証明書署名要求）の生成、秘密鍵の管理、Webサーバーへのインストール、そして定期的な更新作業といった複雑なライフサイクル管理が必要とされたからです。
Salesforceはこれらの障壁を取り除くため、「Salesforce CDN」オプションを強化しました。このオプションを選択することで、SSL証明書の取得から更新、CDNエッジサーバーへの配布といった複雑なプロセスをSalesforceが代行（マネージドサービス化）することが可能となりました。これにより、管理者はDNSのレコード設定というわずかな作業のみで、世界水準のパフォーマンスとセキュリティを持つカスタムドメイン環境を構築できるようになったのです。
アーキテクチャ解説：Salesforce CDNと「シングル証明書」
設定作業における誤操作やトラブルを防ぐためには、その背後で動いている技術的な仕組みを理解しておくことが極めて重要です。ここでは、専門用語を平易な概念に置き換えつつ、Salesforce CDNとカスタムドメインの動作原理を解説いたします。
DNS（ドメインネームシステム）の役割
インターネット上のWebサイトは、実際には「IPアドレス」と呼ばれる数字の羅列（例: 203.0.113.1）によって識別されるサーバー上に存在します。しかし、人間にとって数字の羅列は記憶しにくいため、「ドメイン名」（例: www.example.com）という文字列を使用しています。
DNSは、この「ドメイン名」を「IPアドレス」に変換する、インターネット上の電話帳のようなシステムです。ユーザーがブラウザにURLを入力すると、コンピュータはDNSサーバーに問い合わせを行い、接続先のサーバーの場所（IPアドレス）を特定します。
Experience Cloudにおけるカスタムドメイン設定とは、ユーザーが所有する電話帳（DNS）に、「www.example.com へのアクセスは、SalesforceのCDNサーバーへ転送してほしい」という指示（CNAMEレコード）を書き込む作業に他なりません。
Salesforce CDNの役割
Salesforce CDN（Content Delivery Network）は、Webサイトの画像、CSS、JavaScriptファイルなどの静的コンテンツを、世界中に分散配置された多数のサーバー（エッジサーバー）にコピーして保存（キャッシュ）する仕組みです。
ユーザーがExperience Cloudサイトにアクセスすると、Salesforceのデータセンター（北米や日本など特定箇所に存在）に直接アクセスするのではなく、ユーザーの物理的な位置に最も近いCDNエッジサーバーからコンテンツが配信されます。これにより、以下のメリットが享受できます。
- 劇的なパフォーマンス向上: 物理的距離による遅延（レイテンシ）が解消され、ページの読み込み速度が大幅に短縮される。これは特にモバイルユーザーやグローバルに展開する企業にとって重要である。
- 可用性と耐障害性: アクセスが急増した場合でも、負荷が世界中のサーバーに分散されるため、サイトがダウンするリスクを軽減できる。
- セキュリティの強化: Salesforce CDNパートナー（主にAkamai、Commerce LWRなどの一部構成ではCloudflare）が提供するWebアプリケーションファイアウォール（WAF）やDDoS攻撃対策機能により、悪意あるトラフィックからサイトが保護される。
シングル証明書モデル（Single Certificate）
Webサイトの通信を暗号化し、盗聴や改ざんを防ぐ技術がSSL/TLSです。これを実現するためには「証明書」が必要となります。Salesforce CDNを利用する場合、証明書の管理モデルには大きく分けて二つの歴史的変遷が存在します。
- 共有証明書（Shared Certificate）: 過去に主流であったモデル。一つの証明書に複数の企業のドメインが含まれる。コスト効率は良いが、証明書の詳細情報に他社のドメインが表示されるため、セキュリティポリシーの厳しい企業では敬遠されることがあった。
- シングル証明書（Single Certificate）: 現在の標準モデル。顧客のドメイン専用の証明書が発行される。他社のドメインが含まれることはなく、セキュリティと信頼性が高い。本記事で解説する手順は、この「シングル証明書」モデルに基づく。
シングル証明書モデルでは、証明書の発行元（認証局：Let’s Encryptなど）が「ドメインの所有権」を厳格に確認するプロセスが必要となります。これが、後述する _acme-challenge レコードの設定が必要となる理由です。
実装フェーズ1：事前準備（サブドメイン運用の推奨）
サブドメイン vs ルートドメイン
Salesforce CDNを利用する場合、サブドメインの使用が最も強く推奨されます。
- サブドメインの例: www.example.com, portal.example.com, support.example.com
- 理由: DNSの標準仕様（RFC）において、サブドメインには「CNAMEレコード」を設定することが許可されているが、ルートドメイン（例:
example.com）には通常許可されていないため。 - 結論: 特別なDNSサービス（ALIASレコード等）を利用しない限り、基本的には
wwwなどのサブドメインの採用を推奨する。
必要な権限
作業を始める前に、以下の権限を確認してください。
- Salesforce: 「ドメインの管理」および「サイトの管理」権限。
- DNSプロバイダー:
example.com等を管理しているサービスのDNSレコード編集権限。
実装フェーズ2：【本番】Salesforce組織でのドメイン登録
まず、Salesforce本番環境でドメインを受け入れる準備を行います。
- Salesforceの [設定] > クイック検索で「ドメイン」と入力し、[ドメイン] を選択します（※[私のドメイン]ではありません）。
- [ドメインを追加] をクリックし、ドメイン名（例:
www.example.com）を入力します。 - ドメイン構成オプションで、必ず以下を選択してください。
☑️ Salesforce コンテンツ配信ネットワーク（CDN）を使用してドメインを提供します。
このオプションを選択することで、SSL証明書の複雑な管理（CSR生成や更新作業）をSalesforceに委任（マネージドサービス化）できます。
💡保存する前に！
画面上部にCNAMEターゲットが表示されます。2種類の文字列をコピーしてください。
1. www.example.com.xxxxxxxxxxx.live.siteforce.com
2. _acme-challenge.www.example.com.xxxxxxxxxxx.live.siteforce.com
保存する前にDNSレコードの設定が必要です。この画面を表示したまま実装フェーズ3を完了してから、こちらに戻ってきて保存ボタンを押すとDNSのチェック処理が実行されます。
実装フェーズ3：DNSレコードの設定（最重要プロセス）
ここが最大の山場です。シングル証明書モデルでは、DNSサーバーに2つの異なるCNAMEレコードを設定する必要があります。
サブドメインの作成
必要に応じて、サブドメインの設定を行なってください。
Webアクセスの転送用レコード
ユーザーがサブドメイン付きのドメインURLにアクセスした際に、それをSalesforceのCDNサーバーに誘導するためのレコードです。これがないとサイトが表示されません。
# DNSレコード設定例 1
# タイプ: CNAME
# ホスト名: www
# ターゲット: Salesforce設定画面で表示されたCNAME値
www.example.com IN CNAME www.example.com.[OrgId].live.siteforce.com
# TTL: 300(5分) または デフォルト値
証明書発行の検証用レコード（_acme-challenge）
Salesforceが裏側で使用している認証局に対し、「私がこのドメインの正当な管理者です」と証明するためのレコードです。これがないとSSL証明書が発行されず、設定プロセスが完了しません。
# DNSレコード設定例 2
# 重要: ホスト名の先頭に必ず "_acme-challenge." を付けてください
# タイプ: CNAME
# ホスト名: _acme-challenge.www
# ターゲット: Salesforce設定画面で表示された "_acme-challenge." 付きの値
_acme-challenge.www.example.com IN CNAME _acme-challenge.www.example.com.[OrgId].live.siteforce.com
# TTL: 300(5分) または デフォルト値
多くのトラブルは、この _acme-challenge のスペルミスや、アンダースコア（_）の抜けによって発生しています。慎重に入力してください。
ここまで完了したら、Salesforce画面に戻って [保存] ボタンを押してください。
実装フェーズ4：【本番】プロビジョニングと有効化
DNS設定が完了すると、Salesforceのドメインステータスは「プロビジョニング（Provisioning）」になります。
待機時間の目安
この処理には、通常 4時間〜14時間 程度かかります（数分で終わる場合もあります）。
バックグラウンドでは以下の処理が自動実行されています。
- DNSの
_acme-challengeレコードを確認し、所有権を検証。 - 認証局からSSL証明書を取得。
- 世界中のCDNエッジサーバーへ証明書を配布。
DNS伝播の確認
DNSレコードを追加しても、その情報が世界中のインターネットに行き渡るまでには時間がかかります（DNSプロパゲーション）。
設定後、以下のツールなどを使用してレコードが正しく反映されているか確認できますのでおすすめです。
- 確認ツール: https://www.whatsmydns.net/
- 確認方法:
- 検索窓にドメイン名（例: www.example.com）を入力し、プルダウンから CNAME を選択して検索。
- 検索窓に検証用ドメイン名（例: _acme-challenge.www.example.com）を入力し、同様に検索。
- 世界中の地域の多くで、設定したSalesforceのターゲットURL（…live.siteforce.com）が表示されれば成功。
有効化（Activation）
ステータスが「有効化の待機中（Awaiting Activation）」に変わったら、[ドメイン]画面で[有効化(Activate)] ボタンをクリックしてください。これにより、インターネット上でのCDN配信が開始されます。
有効化の瞬間からトラフィックが切り替わります。そのため、既存サイトの移行などの場合はユーザーアクセスの少ない時間帯（夜間や週末）に実施しましょう。
実装フェーズ5：【本番/Sandbox】サイトとの紐付けとSEO設定
ドメインの準備は整いましたが、まだ「このドメインにアクセスしたら、どのExperience Cloudサイトを表示するか」という定義がされていません。最後にその紐付けを行います。
カスタムURLの設定
- [設定] > [カスタムURL] を開きます。
- [新規カスタム URL] ボタンでドメインとExperience Cloudサイトを紐付けます。
- ドメイン: 作成した
www.example.com - サイト: 対象のサイト
- パス: 通常は
/（ルート）
- ドメイン: 作成した
SEO設定（優先ドメイン）
エクスペリエンスビルダーを開き、[設定] > [全般] > [優先ドメイン] で、設定したカスタムドメインを選択して公開します。これにより、検索エンジンに対して正規のURL（カノニカルタグ）を明示でき、SEO評価の分散を防げます。
実装フェーズ6：【本番/Sandbox】完成したサイトドメインの表示を確認
サイトを公開したら実際にアクセスした際に表示されるURLを確認できます。
無事にカスタムドメインでExperience Cloudサイトを表示できていますね。
運用上の絶対ルール：DNSレコードを削除しないこと
運用開始後、最も注意すべき点があります。
警告: DNS設定で追加したCNAMEレコード（特に _acme-challenge）は、設定完了後も絶対に削除しないでください。
Salesforce CDNは証明書の更新を自動で行いますが、更新のたびに _acme-challenge を使用して所有権の再検証を行います。もしレコードを削除してしまうと、次回の更新時に検証が失敗し、ある日突然サイトのSSLが無効になる（警告が表示される）リスクがあります。
Sandbox環境でのテスト
本番環境への適用の前に、Sandbox環境でカスタムドメインをテストしたいというニーズは多くあります。SandboxでもカスタムドメインとCDNの設定が可能です。
ドメイン名は一意である必要があるため、本番と同じドメイン（例: www.example.com）をSandboxに設定することはできません。Sandboxではテスト用サブドメイン（例: dev.example.com）を使用して検証してください。
まとめ
カスタムドメインの導入は、サイトの信頼性とセキュリティを担保するための必須の投資です。一見複雑な手順に見えますが、Salesforce CDNの「シングル証明書」モデルは、運用コスト（証明書更新の手間）を大幅に削減してくれます。
- サブドメインで設計する。
- DNSには 2つのCNAME を正確に登録する。
- プロビジョニング完了まで 待つ。
- 運用中もDNSレコードは 消さない。
これらを守ることで、安全かつ高速なデジタル体験を顧客に提供することができます。
参考URL
Step-by-Step Guide to Configuring Custom Domains for Experience Cloud Sites
Custom Domain with Salesforce CDN – Salesforce Mojo
Retiring Domain Certificates – Trailhead – Salesforce
Article: Setup and Considerations for Multiple Domains in Experience Cloud
How to Set Up a Custom Domain for Your Salesforce Digital Experience
Update your naked domain configuration to avoid service disruption – Salesforce Help
Change the Domain Name for a Custom Domain – Salesforce Help
Article: Leverage Content Delivery Network(CDN) With Experience Cloud For An Enhanced User Experience
Domain Setup Delay? | Salesforce Trailblazer Community – Trailhead
Common Single Domain Certificate Errors when Using Direct-to-Customer LWR sites
Set Up a Custom Domain for Testing in a Sandbox – Salesforce Help
読者の声