メインコンテンツへスキップ
独自のサブドメインから認証フローを配信できます。verify.didit.meの代わりにverify.yourbrand.comを使えます。ユーザーは最初から最後まで自社ドメイン上にとどまるため、ホワイトラベルフローに残る最後のDidit表記もなくなります。
カスタムドメインはホワイトラベルの機能の一つで、ScaleプランとEnterpriseプランで利用できます。また、Customizationへの書き込み権限が必要です。読み取り専用権限のメンバーには、このセクションが無効の状態で表示されます。
組織がScaleまたはEnterpriseプランから外れると、カスタムドメインは削除され、新しい認証リンクは再びDiditのドメインを使用します。有料プランに移行しないまま終了したScaleトライアルも同様です。2026年11月1日より前に接続したカスタムドメインは、どのプランでもそのまま利用できます。ただし、そのドメインを削除した場合、カスタムドメインを再度追加するにはScaleまたはEnterpriseプランが必要です。
カスタムドメインは本番アプリケーションでのみ利用できます。サンドボックスアプリケーションでは追加できず、サンドボックスのセッションは常にデフォルトのホスト型検証ドメインで実行されます。ドメインを設定するには、Business Consoleで本番アプリケーションに切り替えてください。

​
要件

​
仕組み

Business Consoleでサブドメインを入力すると、DiditがDNSプロバイダーに追加する2つのDNSレコードを生成します。 両方のレコードが必要です。レコードが解決されたらコンソールから所有権を確認します。確認が完了すると、お使いのドメインからフローが配信されるようになります。

​
ドメインを設定する

1

ドメインを追加する

Customization > Domainに移動し、サブドメイン(例: verify.yourbrand.com)を入力してAdd Domainをクリックします。コンソールがDNSレコードを生成します。これには数秒かかります。
2

2つのレコードをコピーする

コンソールには、Verification CNAMEとCloudFront CNAMEのそれぞれについてカードが表示されます。各カードには2つの値があります。
DNSプロバイダーに貼り付ける際は、HostnameとData/URLを取り違えないでください。また、各値はコピーボタンを使ってコピーしてください。確認用の値は長く、入力ミスが起きやすいためです。
3

DNSプロバイダーで両方のレコードを追加する

両方のレコードをCNAMEとして作成します。CloudFrontのレコードだけを追加してしまうことが、後でドメイン確認に失敗する最も多い原因です。TTLは300に設定してください。こうしておくと、後から修正した場合でも数時間ではなく数分で反映されます。
4

所有権を確認する

コンソールに戻り、Verify domainをクリックします。成功するとパネルがDomain verifiedに変わり、ボタンが消えます。失敗した場合は、具体的な理由を記したVerification failedのボックスが表示されます。何かを変更する前にその内容を読んでください。不足しているレコードや誤っているレコードが示されています。
DNSの反映は通常数分で完了しますが、最大で24〜48時間かかる場合があります。コンソールにDNS changes detectedと表示された場合、レコードは正しく、反映が完了するのを待っている状態です。操作は不要です。

​
ドメインを変更または削除する

フローを別のサブドメインに移すには、新しいサブドメインを入力してUpdate Domainをクリックします。Diditが新しいレコードのペアを発行するため、それらをDNSプロバイダーに追加し、再度検証する必要があります。 verify.didit.meに戻すには、フィールドを空にしてRemove Domainをクリックします。
カスタムドメインが設定されている間は、Diditのログイン画面を再度有効にすることはできません。先にドメインを削除してください。

​
トラブルシューティング

サブドメインに、CNAMEと競合するAレコードがあります。1つのホストに両方を設定することはできません。Aレコードを削除し、CNAMEのみを残してください。Aレコードがない場合は、CloudFrontのCNAMEが誤ったターゲットを指しています。コンソールのData/URLの値と1文字ずつ照合してください。
DNSプロバイダーに両方のレコードが存在することを確認してください。最も多い原因はCloudFrontのレコードだけを追加しているケースです。この場合、フローは読み込まれているように見えますが、証明書はいつまでも発行されません。コンソールのVerification failedボックスに、欠落しているレコードまたは誤っているレコードが表示されます。
両方のレコードをDNS only（グレーのクラウド、プロキシオフ)に設定してください。オレンジのクラウドのプロキシはリクエストを横取りし、証明書の発行を妨げます。cPanelなど、プロキシの切り替えがないプロバイダーは影響を受けません。
プロバイダーによってはゾーンを自動的に付加するため、verify.yourbrand.comがverify.yourbrand.com.yourbrand.comになってしまいます。そのようなプロバイダーでは、コンソールに表示される完全な名前ではなく相対名を入力してください。たとえばverify.yourbrand.comではなくverify、_abc123.verify.yourbrand.comではなく_abc123.verifyと入力します。その後、保存したレコードを開き直し、保存された完全な名前がコンソールのHostnameと完全に一致していることを確認してください。
レコードはTTLの期間中キャッシュされます。TTLを300に下げ、以前の値の有効期限が切れるのを待ってから再度テストしてください。

​
次のステップ

  • UIのその他の部分もブランドに合わせる: 色、ロゴ、フォントはカスタマイズで設定します。
  • ワークフローごとにスタイルを有効にする: ブランディングは、Include custom styleをオンにしたワークフローにのみ適用されます。ホワイトラベルを参照してください。
  • 開示義務を確認する: カスタムドメインはDiditのブランディングを隠しますが、Diditの役割を隠すものではありません。コンプライアンス上の責任を参照してください。
最終更新日 2026年11月1日