# ホワイトラベルとカスタムドメイン

Source: https://help.didit.me/ja/workflows/white-label-and-custom-domain
Updated: 2026-10-12

検証フローをverify.didit.meではなくverify.yourbrand.comから提供する方法 - 要件、2つのDNSレコード、そして費用について解説します。

自社で管理する**サブドメイン** - `verify.yourbrand.com` - を2つのCNAMEレコードでDiditに向けます。これはWhite Labelの一部で、Customizationへの書き込み権限が必要で、アカウントで有効化されている必要があります。ルートドメインと`www.`は拒否されます。

[Video: ホワイトラベルKYC：ロゴ、カラー、メール、ドメインをフローに反映 - Didit Academy](https://www.youtube.com/watch?v=xHjIc7DmLHo)

## 何が変わるか

「Secured by」は残ります。ファビコンは変更できます。各アプリに1つのスタイルがあり、LiveとSandboxで共有されます。ライト・ダーク別の配色はありません。

![Domainタブとsave changesを備えたDiditコンソールのホワイトラベルエディタ](https://help.didit.me/screenshots/customization-light.webp)

*ホワイトラベルはここで設定し、その後ワークフローでオンにします。*

## 要件

| 要件 | 詳細 |
|---|---|
| **サブドメインのみ** | `verify.yourbrand.com`。`yourbrand.com`のようなルートドメインや、`www.`のプレフィックスは拒否されます |
| **未使用であること** | そのサブドメインが、すでに自社の別のサイトやアプリを指していないこと |
| **DNSへのアクセス** | 自社のDNSプロバイダーで2つのレコードを作成する必要があります |
| **権限** | Customizationへの書き込み権限。読み取り専用メンバーにはセクションが無効化されて表示されます |
| **アカウントで有効化されていること** | カスタムドメインはWhite Labelの一部であり、自社アカウントで有効化されている必要があります |
| **250ドル以上の残高** | ドメインの追加には、**追加時点で残高に250米ドルのクレジット**が必要です。これは一度きりの条件であって留保金ではありません。ドメインの検証が済めば、その後残高が250ドルを下回っても有効なままです |

## 仕組み

コンソールでサブドメインを入力すると、Diditが追加すべき2つのDNSレコードを生成します。

どちらも必須です。両方が解決されると、コンソールから所有権を検証し、フローは自社ドメインからの配信を開始します。

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

   Liveで**本人確認 → カスタマイズ → ドメイン**を開き、サブドメインを追加します。

2. **両方のDNSレコードを作成する**

   表示された2つのDNSレコードを正確にコピーします。 1つ目はCNAME、2つ目はCNAMEまたはANAMEです。

3. **所有権を検証する**

   反映には最大1時間かかり、反映後に**DNSを確認**を押します。

> **Note:** 検証が完了しない場合、原因はほぼ常にDNSです。誤ったレベルで追加されたレコード（ゾーン名を自動的に付加するプロバイダーで`verify.yourbrand.com.yourbrand.com`になってしまうケース）、レコードの手前にあるプロキシやCDNによる書き換え、あるいは単に伝播がまだ終わっていないだけ、のいずれかです。報告する前に、そのレコードが実際に何に解決されているかを確認してください。

## 費用

カスタムドメインはホワイトラベルの一部で、**完了した検証1件につき0.20ドル**で課金されます。ホワイトラベル料金に上乗せされる別項目ではなく、月額プランもドメインごとの追加料金もありません。ただし、自社ドメインから配信するワークフローはホワイトラベルのワークフローであり、ホワイトラベル価格が適用されます。他に必要なのは**ドメイン追加時の最低残高250ドル**だけで、そのクレジットはその後の検証に使えます。[課金対象となるチェック](https://help.didit.me/ja/billing-credits/what-counts-as-billable)を参照してください。
## リダイレクトの代わりに埋め込む

カスタムドメインは「URLにDiditと表示される」問題を解決します。関心があるのが「ユーザーにアプリを一切離れてほしくない」ということであれば、答えは別のものになります。フローを埋め込むことです。自社のフロントエンドの中に検証を描画するWeb SDKとインコンテキストのオプション、そしてモバイル向けのネイティブSDKがあります。[連携方法](https://help.didit.me/ja/integration/integration-options)をご覧ください。

これらのどれが自社のプランで利用可能かは、想定に頼らずDiditの担当者に確認する価値があります。特にそれを前提にプロジェクトの範囲を決めようとしている場合はなおさらです。

## リセラーやマルチブランドの構成

自社の複数の顧客に代わって検証を実行し、それぞれが独自のブランディングを求める場合、それは1社1ブランドとは異なる形です。Diditがサポートする構成は**組織内でエンド顧客ごとに1つのアプリケーション**で、それぞれが独自のワークフローとブランディングを持ち、それに伴うリセラー条件が適用されます。構築前に[組織、アプリケーション、環境](https://help.didit.me/ja/account-organization/organizations-and-applications)を参照してください。マルチブランド構成を後から改修するのは、最初からそう作るよりはるかに手間がかかります。
## 関連

- [ブランディングと検証体験のカスタマイズ](https://help.didit.me/ja/workflows/customize-branding-and-experience)
- 完全なリファレンス: [Custom domain](https://docs.didit.me/console/custom-domain)