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

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

執筆: Didit サポート · 更新日: 2026年9月15日

#何が変わるか

カスタムドメインを使うと、ユーザーは検証の全工程を通じて自社のドメイン上にとどまります。Style Editorと組み合わせれば、フロー内に残るDiditへの最後の目に見える参照も消えます。

123

1. Brandingには、ユーザーに見えるロゴと色が入ります。
2. Domainは、検証済みのカスタムドメインがverify.didit.meを置き換える場所です。
3. Save changesするまで何も反映されません - そしてワークフロー側でもホワイトラベルを有効にする必要があります。

#要件

#仕組み

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

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

1. ドメインを追加する

   Business Console → White Label → Domainでサブドメインを入力し、Add Domainをクリックします。コンソールがレコードを生成します。

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

   表示された通りに、自社のDNSプロバイダーで追加してください。設定が一部だけだと、証明書が発行されずドメインは使用できません。

3. 所有権を検証する

   レコードが解決されたら、コンソールから検証します。DNSの伝播は最も時間のかかる部分で、完全に自社のプロバイダー側に依存します。

#費用

カスタムドメインはホワイトラベルの一部で、完了した検証1件につき0.20ドルで課金されます。ホワイトラベル料金に上乗せされる別項目ではなく、月額プランもドメインごとの追加料金もありません。ただし、自社ドメインから配信するワークフローはホワイトラベルのワークフローであり、ホワイトラベル価格が適用されます。他に必要なのはドメイン追加時の最低残高250ドルだけで、そのクレジットはその後の検証に使えます。課金対象となるチェックを参照してください。

#リダイレクトの代わりに埋め込む

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

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

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

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

#関連

• ブランディングと検証体験のカスタマイズ
• 完全なリファレンス: Custom domain