[私のドメイン] の変更に関する推奨方法の確認

[私のドメイン] の変更前の推奨手順

• アクセスを維持する — [私のドメイン] のログイン URL またはサイト URL が変更されると、シングルサインオン (SSO) や多要素認証 (MFA) などの認証方法が動作しなくなる場合があります。[私のドメイン] への変更をリリースする前に、システム管理者とユーザーのログインアクセスを保持します。
  

  重要 [私のドメイン] のログイン URL への変更をリリースする前にこの指針に従わない場合、Salesforce 組織からロックアウトされる可能性があります。
• [私のドメイン] の名前がブランドを反映していることを確認する — 拡張ドメインを使用すると、Salesforce で組織に対してホストされるすべての URL に [私のドメイン] の名前が含まれます。これには、システムで管理される Experience Cloud サイトと Salesforce サイトの URL も含まれます。変更に拡張ドメインのリリースが含まれる場合、[私のドメイン] の名前が外部ブランドを反映していることを確認します。含まれない場合、[私のドメイン] の変更の一環として [私のドメイン] の名前を変更できます。
  

  メモ https://www.example.com などのカスタムドメインを使用している場合、システムで管理されるサイト URL はユーザーに表示されません。
• 早期にプロビジョニングする — スケジュールに従って変更をリリースするには、目的の [私のドメイン] の変更を、スケジュールされたリリースの 1 日以上前に保存します。

  [私のドメイン] への変更を保存すると、Salesforce によってドメインがプロビジョニングされます。つまり、新しい [私のドメイン] の URL を有効化する準備が整います。プロビジョニングプロセスは通常数分で終了しますが、最大 24 時間かかることがあります。プロビジョニングの問題はあまり発生しませんが、プロセスを停止して [私のドメイン] の変更を再度保存することが要求される場合があります。この場合、プロセスが再起動されます。

  プロビジョニングプロセスが完了すると、変更を要求したシステム管理者にメールが送信されます。必要な限り、プロビジョニング済みの状況で新しい [私のドメイン] を維持することができます。または、新しいドメインをリリースしないように選択した場合、変更をキャンセルできます。

  最も重要なことは、[私のドメイン] をリリースするまでユーザー接続は影響を受けないということです。ユーザーが新しい [私のドメイン] のログイン URL にアクセスした場合、元の [私のドメイン] のログイン URL にリダイレクトされます。それ以外の場合、誰も新しいドメインにアクセスできません。

• [私のドメイン] の変更後のリダイレクトを理解して、テスト中のリダイレクトを無効にする — [私のドメイン] の詳細への変更をリリースするたびに、以前の [私のドメイン] のホスト名が現在の [私のドメイン] のホスト名にリダイレクトされます (このリダイレクトを無効にしている場合を除く)。ただし、[私のドメイン] を複数回変更した場合、組織の最後の [私のドメイン] の URL セットのみがリダイレクトされます。[私のドメイン] の変更をリリースする前に、既存の [私のドメイン] の URL リダイレクトに対する影響を考慮します。以前の [私のドメイン] のリダイレクトがあるかどうかを確認するには、[私のドメイン] ページの [リダイレクト] セクションを確認します。

  [私のドメイン] の URL リダイレクトは中断を回避するのに役立ちますが、永続的なソリューションとして意図されるものではありません。すべてのサービスでリダイレクトが正常に機能するとは限りません。また、リダイレクトによって最終 Web ページの読み込みプロセスに 1 つのステップが追加されます。新しい [私のドメイン] をリリースするときは、テスト中にリダイレクトを無効にして、古い URL へのすべての参照を更新することを強くお勧めします。

  リダイレクト、リダイレクトを制御する設定、および [私のドメイン] のホスト名リダイレクトを記録する方法についての詳細は、「[私のドメイン] のリダイレクト」を参照してください。

• ハードコードされた Salesforce 組織 URL のインベントリを作成する — ハードコードされた URL では、その URL はコード内でプレーンテキストで存在します。[私のドメイン] の変更や組織の移行など、URL が変更された場合にこれらの URL を手動で更新する必要があります。そのため、可能な限りハードコード化された URL ではなく、相対的および動的に作成された URL を使用することをお勧めします。

  ハードコードされたリンクを解決する最初のステップは、Salesforce 組織のどこにハードコードされたリンクがあるかを見つけることです。インベントリは組織への必要な更新を完了するのに役立つ可能性があり、関連する機能をテストに含めることができます。

  Salesforce コードを検索するには、Salesforce CLI などのツールを使用して各 Salesforce 組織のメタデータをダウンロードします。次に、Microsoft Visual Studio などのコードエディターを使用して、[私のドメイン] を変更する予定の組織に属する URL を検索します。検索する内容を判断するには、インスタンス化 URL を使用して、「[私のドメイン] の URL 形式」を参照します。

  これには時間がかかる可能性があるため、[私のドメイン] の変更プロセスの早い段階でインベントリを作成することをお勧めします。また、別の Salesforce 組織を参照する URL をインベントリで識別することもお勧めします。

• Open CTI や Service Cloud Voice などのコンピューターテレフォニーインテグレーション (CTI): テレフォニープロバイダーとの連携 — 拡張ドメインをリリースするか、[私のドメイン] の名前の変更をリリースすると、Open CTI または Service Cloud Voice 設定で使用されている URL が変更されます。

  Salesforce コールセンターや、クリック-to-ダイヤルなどの Open CTI をインテグレーションに使用している場合は、テレフォニープロバイダーと連携して、新しい URL をテレフォニープロバイダーの許可リストに追加します。また、Salesforce URL へのハードコードされた参照に関する設定も確認します。可能であれば、代わりにこれらのハードコード化された参照を相対 URL に更新してください。

  Amazon Connect を使用する Service Cloud Voice または Amazon Connect からのパートナーテレフォニーを使用する Service Cloud Voice の場合は、アクションは必要ありません。[私のドメイン] をリリースすると、Salesforce によって設定が更新されます。

  Service Cloud Voice with Partner Telephony を使用している場合は、テレフォニープロバイダーとつながります。新しい URL を許可リストに追加し、プロバイダーと調整して、変更をリリースした後に新しい URL で設定を更新します。

  詳細は、「[私のドメイン] の変更に関する組織の更新」を参照してください。

• Experience Cloud 向け Mobile Publisher アプリケーションをアップグレードする — .force.com の Experience Cloud サイト URL を使用する Experience Cloud 向け Mobile Publisher アプリケーションを設定している場合、本番で拡張ドメインを有効にしてリリースする前に Mobile Publisher バージョン 10.0 以降にアップグレードします。手順については、「Experience Cloud 向け Mobile Publisher アプリケーションと拡張ドメイン」を参照してください。

  https://www.example.com のようなカスタムドメインを使用して Experience Cloud サイトをホストし、Mobile Publisher アプリケーションでそのカスタムドメインを使用する場合、この制限は適用されません。また、この制限は Lightning 向け Mobile Publisher アプリケーションには適用されません。

• [私のドメイン] 設定を確認する — [私のドメイン] の変更は、既存の設定を確認し、テストおよびリリース後の検証用に記録し、変更を加える絶好の機会になります。たとえば、[私のドメイン] ログインページで、ブランド設定を更新したり、ID プロバイダーを介してログインするオプションを追加したりします。使用可能な設定オプションを確認するには、「[私のドメイン] 設定の構成」および「[私のドメイン] のリダイレクト」を参照してください。
• 現在の認証設定を文書化する — [私のドメイン] の変更によって [私のドメイン] のログイン URL、Experience Cloud サイト URL、または Salesforce サイト URL が更新される場合、[私のドメイン] の変更をリリースする前に既存の設定を文書化することをお勧めします。このスナップショットは、ロールバック計画の貴重な参照情報となります。取得する設定についての詳細は、「[私のドメイン] の変更後に必要な認証更新の判断」を参照してください。
• ログイン参照を、動的に作成されるホスト名に置き換える — 安定性を維持し、セキュリティを強化するには、[私のドメイン] のログイン URL を使用してコードで Salesforce にログインすることをお勧めします。これらの参照を将来の [私のドメイン] の変更から保護するには、Apex を使用して URL を取得します。Apex で [私のドメイン] のログイン URL のホスト名を取得するには、System.DomainCreator クラスの getOrgMyDomainHostname() メソッドを使用します。システムで管理されるホスト名を使用して Experience Cloud サイトにログインする場合、System.DomainCreator クラスの getExperienceCloudSitesHostname() メソッドを使用してそのホスト名を取得します。

  [私のドメイン] の変更をリリースする前に、動的に作成されるホスト名を使用できます。動的に作成されるホスト名を使用すると、対応するシステム管理 URL を変更しても関連するコードに影響はありません。この方法では、リリース後の作業が軽減されます。

  詳細は、『Apex 開発者ガイド』の「コードを使用した Salesforce へのログイン」および「DomainCreator クラス」を参照してください。

• サイトを提供するカスタムドメインを考慮する — カスタムドメインを使用すると、https://www.example.com などの所有するドメインを使用して、Experience Cloud サイトと Salesforce サイトを提供することができます。Salesforce 組織がコンテンツを提供しますが、サイトはカスタムドメインで提供されるため、ユーザーエクスペリエンスを明確にブランド設定できます。このため、カスタムドメインでサイトを提供することをお勧めします。

  カスタムドメインを考慮している場合、待機中の [私のドメイン] の変更前にカスタムドメインを設定することをお勧めします (可能な場合)。システムで管理されるサイト URL が変更されても、顧客は引き続きカスタムドメインを使用します。この安定性によって、[私のドメイン] の変更後に必要な更新数が削減されます。たとえば、マーケティング資料、メール、ソーシャルメディアページ、テンプレートでサイト URL を参照している場合、カスタムドメインは有効なままです。

  詳細は、「カスタムドメイン」を参照してください。

• ユーザーアドレスの検証を考慮する — [私のドメイン] のログイン URL の変更は、新しいログイン URL のロールアウトの一環としてユーザーを検証する絶好の機会になります。非同期メール検証を使用して、メッセージを内部ユーザーと外部ユーザーに送信し、ユーザーが所有する有効なメールアドレスで登録されていることを確認します。非同期メールメッセージには確認リンク (URL) が含まれています。メールテンプレートをカスタマイズして、検証メールメッセージにブランドを設定することもできます。

  詳細は、「非同期メールを使用したメールアドレスの確認」を参照してください。

組織を更新するタイミングを理解する

テスト計画と稼働開始計画を作成するには、[私のドメイン] の変更に対する組織の更新方法と [私のドメイン] の変更に関するチェックリストの例を確認します。

すべてのステップがすべての組織に適用されるわけではありません。計画を作成するときに、[私のドメイン] の変更に不適切なステップを削除します。次に、[私のドメイン] の変更をリリースした後の更新の優先度を設定します。たとえば、大量のユーザーがテストを開始する前に認証と許可リストを完了する必要があります。

本番でのダウンタイムを減らすには、[私のドメイン] の変更をリリースする前にどの更新を行うことができるかを特定します。次に、変更をリリースする前に本番でこれらの更新をできるだけ多く行います。

本番リリースに必要な時間を推定できるようにするには、新しい [私のドメイン] の URL を必要とする更新をメモし、その更新を稼働開始計画に含めます。

テスト計画に関する推奨事項

テストチームの規模が小さいか大きいかにかわらず、テスト計画は、必要なテスト領域を確実に含めるのに役立ちます。

[私のドメイン] の変更のテスト計画に関する推奨事項を次に示します。

• 本番を更新する前に [私のドメイン] の変更を Sandbox でテストします。ユーザーに影響を与えずに本番でテストすることはできません。[私のドメイン] の変更をリリースすると、組織にアクセスするすべてのユーザーとサードパーティにすぐに適用されます。
• テストする領域の優先度を設定します。自動テストが存在する場合、エンドユーザーテストを開始する前に自動テストを実行します。ビジネスに対する最大の影響と、問題の解決に最も時間のかかる領域に焦点を絞ります。たとえば、一部の顧客は最初に公開サイトと収益を生み出す機能をテストします。または、テスト担当者が関与している間に、より多くのトラブルシューティング時間を提供するために、複雑なカスタマイズを優先することができます。また、パッケージで提供される機能に関する問題を解決するには、多くの場合パッケージ開発者と連携する必要があります。そのため、重要なパッケージ機能は早期にテストしてください。
• AppExchange からパッケージをインストールした場合、パッケージで提供される機能とコンポーネントをテストに含めます。リンクのあるコンポーネントに焦点を絞ります。たとえば、パッケージで提供される Visualforce ページには、サイト、コンテンツ、またはその他の Visualforce ページへのリンクが含まれている可能性があります。問題の優先順位付けができるように、インストール済みパッケージと対応する機能をテスト計画にメモしておくことをお勧めします。

  ほとんどの場合、パッケージで提供されるこれらのコンポーネントは編集できません。また、これらのコンポーネントのいずれかを更新すると、将来のパッケージの更新で変更が上書きされる可能性があります。

  AppExchange パッケージ開発者は相対パスを使用してリンクを作成することをお勧めします。その方法に従うと、更新したリンクは、拡張ドメインの有効化など、[私のドメイン] の変更後に正常に機能します。ただし、すべてのパッケージ開発者がその推奨事項に従うわけではありません。パッケージで提供されるコンポーネントまたは機能で問題が発生した場合、修復には更新されたバージョンのパッケージが必要になる可能性があります。このため、パッケージで提供される機能をテストの早い段階でテストし、パッケージ修復のための時間を全体的なプロジェクトに組み込みことをお勧めします。

• 可能な限り、テスト担当者に各機能の明確なテスト手順を提供します。テスト担当者がすべての機能に精通している経験豊富なユーザーの場合、各ステップの詳しい説明は不要ですが、期待される結果を含めることは常に役立ちます。
• Sandbox でのテストと本番での稼働開始テストの違いを特定します。Sandbox で徹底的にテストすることをお勧めします。ただし、重大な問題は Sandbox テスト中に検出されることが想定されるため、多くの場合、本番テストでは詳細なテストは行われなくなります。使用するテスト方法で 2 つのバージョンのテスト計画が必要かどうかを決定します。

稼働開始計画に関する推奨事項

稼働開始計画により、本番に変更をリリースするときの不可欠な手順を確実に完了できます。

[私のドメイン] の変更の稼働開始計画に関する推奨事項を次に示します。

• 変更をプロビジョニングし、変更をリリースする準備が整っていることを確認する手順を含めます。
• 許可リストやハードコードされた URL の更新など、これらの多くの変更は、新しい [私のドメイン] をリリースする前に本番で行うことができます。本番でのダウンタイムを減らすには、稼働開始前にこれらの変更をできるだけ多く行います。
• [私のドメイン] の変更をリリースした後にのみ実行できる手順を詳細に記述します。本番リリース期間の前にその他のすべての変更を行います。
• 各ステップの所有者と提案されたタイミングをすべての参加者と共に明確にします。
• 影響を受ける公開サイトのメンテナンスイベントをスケジュールします。
• 最終的な稼働開始準備の一環として、すべての参加者の対応可能状況と連絡先の詳細を確認します。
• ユーザーと顧客に関連する通知を計画に含めます。
• ユーザーと顧客への影響を最小限に抑えるために、新しい [私のドメイン] のリリースは、週末など組織の受信トラフィック量が最小の時間帯に行います。
• 関連するテストが完了したらすぐに公開サイトを使用できるようにするメカニズムを実装します。

概要手順の例については、「[私のドメイン] の変更のプロジェクトチェックリストの例」の「本番を更新する準備を行います」、「本番を更新します」、および「リリース後の採用」セクションを参照してください。[私のドメイン] の変更をリリースした後に実行する手順の例については、リリース前およびリリース後のタスクのチェックリストの例を参照してください。

リリース後の推奨事項

[私のドメイン] の変更をリリースすると、Salesforce によって以前のホスト名がリダイレクトされます。ユーザーが古いブックマークとリンクを更新できるように、リダイレクトされる前に新しい URL をユーザーに通知します。[私のドメイン] の [現在の [私のドメイン] の URL にリダイレクトする前にユーザーに通知] オプションを有効にします。「[私のドメイン] のリダイレクトの管理」を参照してください。

拡張ドメインを有効にしてリリースした場合、Salesforce は Sandbox、Developer Edition 組織、パッチ組織、スクラッチ組織、Trailhead Playground のこれらのリダイレクトの一部を Winter '25 で停止しました。本番組織とデモ組織では、これらのリダイレクトは Spring '26 で停止します。 影響を受けるホスト名を確認し、その変更による潜在的な影響をテストします。詳細は、「非拡張ドメインのリダイレクトの終了への準備」を参照してください。

古いホスト名のアクセスを検出するには、ホスト名リダイレクトログを有効にすることをお勧めします。その後、複数日のホスト名リダイレクトログを収集するには、REST API を使用してホスト名リダイレクトイベント種別の日次クエリをスケジュールします。たとえば、クエリを実行する cron ジョブ (UNIX) やスケジュール済み ToDo (Windows) を設定できます。詳細は、『Salesforce Platform のオブジェクトリファレンス』の「[私のドメイン] のホスト名リダイレクトとホスト名リダイレクトイベント種別の記録」を参照してください。

以前のすべてのリダイレクトを無効化するかどうかを考慮します。たとえば、ブランドが変更された場合、以前の [私のドメイン] への参照を介して Salesforce 組織またはサイトにユーザーがアクセスできるようにするかどうかを決定します。リダイレクトについての詳細は、「[私のドメイン] のリダイレクト」を参照してください。以前のホスト名のリダイレクトを削除する場合、テストおよびコミュニケーションでは 2 番目の [私のドメイン] の変更として処理します。