> ## Documentation Index
> Fetch the complete documentation index at: https://docs.didit.me/llms.txt
> Use this file to discover all available pages before exploring further.

# KYC認証のカスタムドメイン：DNS設定

> Diditの認証フローをverify.didit.meではなく自社のサブドメインで提供できます。ドメインを追加し、DNSレコードを2件作成して所有権を確認します。

独自のサブドメインから認証フローを配信できます。`verify.didit.me`の代わりに`verify.yourbrand.com`を使えます。ユーザーは最初から最後まで自社ドメイン上にとどまるため、[ホワイトラベル](https://docs.didit.me/ja/console/white-label.md)フローに残る最後のDidit表記もなくなります。

> [!NOTE]
>
> カスタムドメインはホワイトラベルの機能の一つで、**Scale**プランと**Enterprise**プランで利用できます。また、**Customization**への書き込み権限が必要です。読み取り専用権限のメンバーには、このセクションが無効の状態で表示されます。

> [!NOTE]
>
> 組織がScaleまたはEnterpriseプランから外れると、カスタムドメインは削除され、新しい認証リンクは再びDiditのドメインを使用します。有料プランに移行しないまま終了したScaleトライアルも同様です。2026年11月1日より前に接続したカスタムドメインは、どのプランでもそのまま利用できます。ただし、そのドメインを削除した場合、カスタムドメインを再度追加するにはScaleまたはEnterpriseプランが必要です。

> [!NOTE]
>
> カスタムドメインは**本番アプリケーションでのみ**利用できます。[サンドボックス](https://docs.didit.me/ja/integration/sandbox-testing.md)アプリケーションでは追加できず、サンドボックスのセッションは常にデフォルトのホスト型検証ドメインで実行されます。ドメインを設定するには、Business Consoleで本番アプリケーションに切り替えてください。

***

## 要件

| 要件 | 詳細 |
| - | - |
| **本番アプリケーション** | ドメインは本番アプリケーションに属します。サンドボックスアプリケーションではカスタムドメインを設定できません。 |
| **サブドメインのみ** | `verify.yourbrand.com`のように指定します。`yourbrand.com`のようなルートドメインは受け付けられず、`www.`で始まるものも同様です。 |
| **使用中でないこと** | そのサブドメインが、既存の自社Webサイトやアプリケーションを指していてはいけません。 |
| **DNSへのアクセス** | DNSプロバイダーで2つのレコードを作成する必要があります。 |

***

## 仕組み

Business Consoleでサブドメインを入力すると、DiditがDNSプロバイダーに追加する2つのDNSレコードを生成します。

| レコード | 目的 |
| - | - |
| **検証用CNAME** | ドメインの所有を証明し、これによりSSL証明書が発行されます。 |
| **CloudFront CNAME** | サブドメインを認証UIに紐付けます。 |

両方のレコードが必要です。レコードが解決されたらコンソールから所有権を確認します。確認が完了すると、お使いのドメインからフローが配信されるようになります。

***

## ドメインを設定する

**1. ドメインを追加する**

**Customization > Domain**に移動し、サブドメイン(例: `verify.yourbrand.com`)を入力して**Add Domain**をクリックします。

コンソールがDNSレコードを生成します。これには数秒かかります。

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

コンソールには、**Verification CNAME**と**CloudFront CNAME**のそれぞれについてカードが表示されます。各カードには2つの値があります。

| カードのフィールド | DNSプロバイダーでの入力先 |
| - | - |
| **Hostname** | レコードの**name**(ホスト) |
| **Data/URL** | レコードの**value**(ターゲット) |

> [!WARNING]
>
> DNSプロバイダーに貼り付ける際は、**Hostname**と**Data/URL**を取り違えないでください。また、各値はコピーボタンを使ってコピーしてください。確認用の値は長く、入力ミスが起きやすいためです。

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

両方のレコードを`CNAME`として作成します。CloudFrontのレコードだけを追加してしまうことが、後でドメイン確認に失敗する最も多い原因です。

TTLは`300`に設定してください。こうしておくと、後から修正した場合でも数時間ではなく数分で反映されます。

**4. 所有権を確認する**

コンソールに戻り、**Verify domain**をクリックします。成功するとパネルが**Domain verified**に変わり、ボタンが消えます。

失敗した場合は、具体的な理由を記した**Verification failed**のボックスが表示されます。何かを変更する前にその内容を読んでください。不足しているレコードや誤っているレコードが示されています。

> [!NOTE]
>
> DNSの反映は通常数分で完了しますが、最大で**24〜48時間**かかる場合があります。コンソールに**DNS changes detected**と表示された場合、レコードは正しく、反映が完了するのを待っている状態です。操作は不要です。

***

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

フローを別のサブドメインに移すには、新しいサブドメインを入力して**Update Domain**をクリックします。Diditが新しいレコードのペアを発行するため、それらをDNSプロバイダーに追加し、再度検証する必要があります。

`verify.didit.me`に戻すには、フィールドを空にして**Remove Domain**をクリックします。

> [!NOTE]
>
> カスタムドメインが設定されている間は、Diditのログイン画面を再度有効にすることはできません。先にドメインを削除してください。

***

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

> [accordion] 500エラー、または別のCloudFrontディストリビューションに関するメッセージが表示される
>
> サブドメインに、CNAMEと競合する`A`レコードがあります。1つのホストに両方を設定することはできません。`A`レコードを削除し、CNAMEのみを残してください。
>
> `A`レコードがない場合は、CloudFrontのCNAMEが誤ったターゲットを指しています。コンソールの**Data/URL**の値と1文字ずつ照合してください。

> [accordion] 確認がいつまでも成功しない
>
> DNSプロバイダーに**両方**のレコードが存在することを確認してください。最も多い原因はCloudFrontのレコードだけを追加しているケースです。この場合、フローは読み込まれているように見えますが、証明書はいつまでも発行されません。
>
> コンソールの**Verification failed**ボックスに、欠落しているレコードまたは誤っているレコードが表示されます。

> [accordion] 証明書がいつまでも発行されない (Cloudflare)
>
> 両方のレコードを**DNS only**（グレーのクラウド、プロキシオフ)に設定してください。オレンジのクラウドのプロキシはリクエストを横取りし、証明書の発行を妨げます。
>
> cPanelなど、プロキシの切り替えがないプロバイダーは影響を受けません。

> [accordion] レコード名が重複する
>
> プロバイダーによってはゾーンを自動的に付加するため、`verify.yourbrand.com`が`verify.yourbrand.com.yourbrand.com`になってしまいます。
>
> そのようなプロバイダーでは、コンソールに表示される完全な名前ではなく**相対**名を入力してください。たとえば`verify.yourbrand.com`ではなく`verify`、`_abc123.verify.yourbrand.com`ではなく`_abc123.verify`と入力します。その後、保存したレコードを開き直し、保存された完全な名前がコンソールの**Hostname**と完全に一致していることを確認してください。

> [accordion] 修正の反映に何時間もかかる
>
> レコードはTTLの期間中キャッシュされます。TTLを`300`に下げ、以前の値の有効期限が切れるのを待ってから再度テストしてください。

***

## 次のステップ

* **UIのその他の部分もブランドに合わせる**: 色、ロゴ、フォントは[カスタマイズ](https://docs.didit.me/ja/console/white-label.md)で設定します。
* **ワークフローごとにスタイルを有効にする**: ブランディングは、**Include custom style**をオンにしたワークフローにのみ適用されます。[ホワイトラベル](https://docs.didit.me/ja/console/white-label.md#ワークフローでカスタムスタイルを有効にする)を参照してください。
* **開示義務を確認する**: カスタムドメインはDiditのブランディングを隠しますが、Diditの役割を隠すものではありません。[コンプライアンス上の責任](https://docs.didit.me/ja/console/white-label.md#ホワイトラベルのフローにおけるコンプライアンス上の責任)を参照してください。


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.