日本語
  • カスタムドメイン
  • 複数ドメイン
  • 認証

認証用カスタムドメインとは何か、なぜ複数ドメインが重要なのか

認証用カスタムドメインや複数ドメインがコンバージョン、セキュリティ、ブランディングをどのように改善するか、そして Logto が DNS の煩わしさなしにそれらを管理するのにどう役立つかを学ぼう。

Ran
Ran
Product & Design

ユーザー認証に何週間も費やすのはもうやめましょう
Logto でより速く安全なアプリをリリース。数分で認証を統合し、コア製品に集中できます。
始めましょう
Product screenshot

もし急いでプロダクトをリリースしたことがあれば、この話はきっと身に覚えがあるはず。

あなたのアプリは example.com で順調に運営されている。マーケティングキャンペーンも好調、ユーザーも順調に増えて、全てが洗練されて見える。そんな中、新しいユーザーが サインイン をクリックする。

auth.example.com のような見慣れた URL の代わりに、ブラウザはまるでテスト環境みたいな my-tenant-123.app.logto にジャンプする。

技術的には何も問題はない。そのページは安全。ログインもちゃんと動く。
でもユーザーの最初の反応はこうだ。

「え、今どこに飛ばされた？」

その“1 秒の不安”が離脱の原因になる。

  • コンバージョン の観点では、サインインやサインアップはあなたのファネルの中で最も細い部分。追加の「このドメインなに？」という瞬間が friction を生む。
  • セキュリティ の観点では、ユーザーは何年も 「URL を確認しよう」 と教えられてきた。もしログイン用ドメインが自分のブランドと違えば、それは“本番環境”よりもむしろフィッシングに見えてしまう。

ほぼすべての大企業がこんなドメインを使う理由がある。

  • login.company.com
  • auth.company.com
  • accounts.company.com

彼らが遊びでやっているわけじゃない。ログイン用ドメインはプロダクト体験の一部だからだ。

今回の記事では、

  • 認証用カスタムドメイン とは実際どんなものか
  • 1 つ のログインドメインで十分な場合、複数 を計画すべきタイミング
  • よくあるログインドメインの失敗（“redirect URI が一致しません”地獄の回避方法）
  • Logto のカスタムドメイン対応が、DNS エンジニア にならずともこれらを解決する仕組み

について解説したい。

認証用カスタムドメインとは？

シンプルにいこう。

すべての Logto テナントは、デフォルトドメイン {{tenant-id}}.app.logto で提供される。そのため、これまでユーザーが飛ばされていた先は https://my-tenant-123.app.logto/sign-in だった。

認証用カスタムドメインは、この見える URL をあなたが所有するもの、たとえば auth.example.com に差し替える。これで https://auth.example.com/sign-in のように、ユーザーをブランドのまま維持できる。

裏側の認証サービスは同じ。でも第一印象は大きく違う。

ルートドメインではなくサブドメインを使う理由

Logto のカスタムドメインは、基本的に サブドメイン で使うことが想定されている。

  • auth.example.com
  • auth.us.example.com

実際、認証用ならこれが理想だ：

  • ルートドメインはたいていあなたのメインサイト（example.com）のために確保されている。
  • DNS の “ゾーン頂点”（zone apex）は CNAME を使えないが、Logto のホストサインインは CNAME で domains.logto.app を指してトラフィックをルーティングする必要がある。
  • Logto は証明書を Cloudflare で管理する。もしルートドメインで TLS を終了するにはゾーン全体（既存の A, MX, TXT など含む）を管理する必要があり、それはマルチテナント SaaS では現実的ではない。

Apex-flattening レコード（ALIAS/ANAME）は結局別の IP（自社以外）を返すので、Logto の証明書管理対象にならない。つまりホストサインインはサブドメイン上で動かすしかない。サブドメインを CNAME で Logto に向ければ、検証、SSL、稼働監視は Logto 側で処理——あなたの apex ドメインはそのまま好きに使える。

「CNAME 追加すればOK」じゃ終わらない理由

よくある誤解：

「DNS に CNAME 追加しときゃ終わりでしょ？」

残念ながら、それだけでは足りない。

見えるログイン用ドメインを変えるだけでは十分ではない。カスタム認証ドメインを導入した瞬間、あなたはこんな部分に対処することになる：

  • サインイン・登録ページの URL
    ホストページの訪問先が https://auth.example.com/... に変わる。

  • OIDC / OAuth リダイレクト URI
    アプリやコネクタはリダイレクト・コールバック URL に同じドメインを使う必要がある。間違えば redirect_uri_mismatch のようなエラーになる。

  • ソーシャルログイン & エンタープライズ SSO（IdP）
    Google、GitHub、Azure AD、Okta などはすべてリダイレクト URI や ACS URL 内のドメインを検証する。

  • パスキー（WebAuthn）
    パスキーは登録した正確なドメインに紐づく。ドメインを変えればそれはもう使えない。

  • SDK 設定
    Logto SDK も endpoint でテナントのドメインを参照する。エンドポイントが違うとアプリと認証基盤で食い違いが起きる。

DNS は必要か？もちろん。 でも「CNAME 足したら終了」と考えると、他のどこかが確実に壊れる。

イメージで考える：「ログイン用ドメイン」がどうスタックを流れるか

ユーザーのブラウザがスタート地点だと想像しよう：

  1. ブラウザのアドレスバー

    • ユーザーが https://example.com で サインイン をクリック。
    • https://auth.example.com/sign-in へリダイレクトされる。

  2. 認可サーバー & discovery document

    • アプリは OpenID 設定エンドポイント：
      https://auth.example.com/oidc/.well-known/openid-configuration を使う。
    • これは認証リクエストの送信先やトークンの受け取り先を教える。

  3. リダイレクト URI（OIDC/OAuth コールバック）

    • サインイン完了後、Logto は例えば https://app.example.com/callback へリダイレクトする。
    • IdP もアプリ側も、この URL の一致が必要。

  4. ソーシャルログイン・SSO のホップ

    • auth.example.com からユーザーは Google、Microsoft Entra ID、Okta などにジャンプするかもしれない。
    • それらプロバイダーもリダイレクト URI 内のカスタム認証ドメインを検証する。

  5. メールのマジックリンク・パスワードリセットリンク

    • メール内のリンクも一貫してカスタムドメインにして混乱を防ぐべき。

各ステップで、ドメインが重要になる。カスタムログインドメインを導入したら、そのドメインが全工程で一貫して流れる必要がある。

カスタムドメイン戦略は DNS テクニックよりも、「一貫した識別設計」であるべき理由がここにある。

シングル or 複数カスタムドメイン

多くのチームにとって auth.example.com だけで十分だ。だがプロダクト・地理・顧客層が広がると、事前に準備しないとあっという間に限界に突き当たる。

チーム／用途ごとの典型的なドメイン設計例：

シナリオドメイン例メリット（なぜ役立つか）
1 ブランドのログインauth.example.com, account.example.comアドレスバーがブランドどおり。{{tenant-id}}.app.logto デフォルトもテスト用途で残せる。
地域別の体験auth.us.example.com, auth.eu.example.com, auth.apac.example.com1 テナント内で地域ごとにローカライズ（同意画面やコンプライアンスノーティスも）。
環境隔離auth.staging.example.com, auth.example.comテナントやコネクタを丸ごと複製せずに QA/プレビュー用トラフィックを隔離。
組織ごとのブランディングauth.customer-a.com, auth.customer-b.comエンタープライズ顧客にはホワイトラベルの入口を、中央集約型でユーザー・組織・SSO を一元管理。
ブランド・製品ラインごとauth.shop.example.com, auth.app.example.com, auth.studio.example.comアイデンティティ基盤は統一のまま、ブランドごとに一貫したログイン体験を提供。
複数 TLDauth.foo.com, auth.foo.co.uk, auth.foo.dev国別や用途特化サイトをリージョンごとに設定コピーせずサポートできる。
インフラ駆動型auth.edge.example.com, auth.api.example.comCDN/エッジルールにも合わせつつ、Logto が認証バックエンドとして裏側で統一運用。

Logto ならカスタムドメインもラクラク

Logto なら DNS や PKI のプロにならずとも、こんな機能が初期から手に入る：

  • 1 テナントで複数ドメイン対応。 地域・環境・顧客・ブランドごとに別ホストを割当ても複製不要。プラン制限はあるが“1 アイデンティティ基盤・多入口”の本質は変わらない。
  • デフォルトも生きたまま。 auth.example.com を追加しても、{{tenant-id}}.app.logto デフォルトは停止しない。内部ツールや段階的公開にデフォルトを活用できる。
  • コネクタ自動調整。 SDK は正しい endpoint を指し、ソーシャル・エンタープライズ SSO コネクタも各ドメイン用の有効なリダイレクト URI や ACS URL を自動でリストアップ——手動貼り付け不要。
  • SSL も自動管理。 CNAME 追加後は Logto 側で DNS 検証・証明書発行・更新まで自動。鍵管理や突然の期限切れとも無縁。

次にやるべきこと

ここまで読んだあなたは次のどちらかだろう。

すでに Logto 利用中？

すぐに複数カスタムドメインを試せる：

  • コンソール > 設定 > ドメイン に進み、たとえば新規リージョンやブランド配下の大口顧客用に 2 つ目のドメイン追加などをしよう。
  • 必要に応じて SDK の endpoint を更新。
  • ソーシャル/SSO コネクタごとにカスタムドメイン対応のリダイレクト URI・ACS URL を IdP 側にも登録。

これでログイン体験の整理や、ユーザー信頼・コンバージョンへのインパクトも検証しやすくなる。

Logto 初心者も安心！

まず始めるなら：

  • Logto でアカウント作成し、テナントを新規作成。
  • コンソール > 設定 > ドメイン で無料枠のカスタムドメインを利用して、auth.example.com を初日から公式ログイン用に割り当てよう。
  • デフォルトの {{tenant-id}}.app.logto ドメインも内部向けやテスト用途に備えて温存。

これで「テスト環境っぽいログイン URL」と永遠にオサラバ。成長局面でのドメイン移行地獄を未来のあなたに残さずにすむ。

DNS レコード例やトラブル対策も含むステップバイステップ手順はこちら：
公式ドキュメント「カスタムドメイン」も要チェック！