日本語
認証用カスタムドメインとは何か、なぜ複数ドメインが重要なのか
認証用カスタムドメインや複数ドメインがコンバージョン、セキュリティ、ブランディングをどのように改善するか、そして Logto が DNS の煩わしさなしにそれらを管理するのにどう役立つかを学ぼう。
Ran
Product & Design
Product & Design
認証用カスタムドメインや複数ドメインがコンバージョン、セキュリティ、ブランディングをどのように改善するか、そして Logto が DNS の煩わしさなしにそれらを管理するのにどう役立つかを学ぼう。
もし急いでプロダクトをリリースしたことがあれば、この話はきっと身に覚えがあるはず。
あなたのアプリは example.com で順調に運営されている。マーケティングキャンペーンも好調、ユーザーも順調に増えて、全てが洗練されて見える。そんな中、新しいユーザーが サインイン をクリックする。
auth.example.com のような見慣れた URL の代わりに、ブラウザはまるでテスト環境みたいな my-tenant-123.app.logto にジャンプする。
技術的には何も問題はない。そのページは安全。ログインもちゃんと動く。
でもユーザーの最初の反応はこうだ。
「え、今どこに飛ばされた？」
その“1 秒の不安”が離脱の原因になる。
ほぼすべての大企業がこんなドメインを使う理由がある。
login.company.comauth.company.comaccounts.company.com彼らが遊びでやっているわけじゃない。ログイン用ドメインはプロダクト体験の一部だからだ。
今回の記事では、
について解説したい。
シンプルにいこう。
すべての 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.comauth.us.example.com実際、認証用ならこれが理想だ：
example.com）のために確保されている。domains.logto.app を指してトラフィックをルーティングする必要がある。A, MX, TXT など含む）を管理する必要があり、それはマルチテナント SaaS では現実的ではない。Apex-flattening レコード（ALIAS/ANAME）は結局別の IP（自社以外）を返すので、Logto の証明書管理対象にならない。つまりホストサインインはサブドメイン上で動かすしかない。サブドメインを CNAME で Logto に向ければ、検証、SSL、稼働監視は Logto 側で処理——あなたの apex ドメインはそのまま好きに使える。
よくある誤解：
「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 足したら終了」と考えると、他のどこかが確実に壊れる。
ユーザーのブラウザがスタート地点だと想像しよう：
ブラウザのアドレスバー
https://example.com で サインイン をクリック。https://auth.example.com/sign-in へリダイレクトされる。認可サーバー & discovery document
https://auth.example.com/oidc/.well-known/openid-configuration を使う。リダイレクト URI（OIDC/OAuth コールバック）
https://app.example.com/callback へリダイレクトする。ソーシャルログイン・SSO のホップ
auth.example.com からユーザーは Google、Microsoft Entra ID、Okta などにジャンプするかもしれない。メールのマジックリンク・パスワードリセットリンク
各ステップで、ドメインが重要になる。カスタムログインドメインを導入したら、そのドメインが全工程で一貫して流れる必要がある。
カスタムドメイン戦略は DNS テクニックよりも、「一貫した識別設計」であるべき理由がここにある。
多くのチームにとって 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.com | 1 テナント内で地域ごとにローカライズ（同意画面やコンプライアンスノーティスも）。 |
| 環境隔離 | 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 | アイデンティティ基盤は統一のまま、ブランドごとに一貫したログイン体験を提供。 |
| 複数 TLD | auth.foo.com, auth.foo.co.uk, auth.foo.dev | 国別や用途特化サイトをリージョンごとに設定コピーせずサポートできる。 |
| インフラ駆動型 | auth.edge.example.com, auth.api.example.com | CDN/エッジルールにも合わせつつ、Logto が認証バックエンドとして裏側で統一運用。 |
Logto なら DNS や PKI のプロにならずとも、こんな機能が初期から手に入る：
auth.example.com を追加しても、{{tenant-id}}.app.logto デフォルトは停止しない。内部ツールや段階的公開にデフォルトを活用できる。endpoint を指し、ソーシャル・エンタープライズ SSO コネクタも各ドメイン用の有効なリダイレクト URI や ACS URL を自動でリストアップ——手動貼り付け不要。ここまで読んだあなたは次のどちらかだろう。
すぐに複数カスタムドメインを試せる：
endpoint を更新。これでログイン体験の整理や、ユーザー信頼・コンバージョンへのインパクトも検証しやすくなる。
まず始めるなら：
auth.example.com を初日から公式ログイン用に割り当てよう。{{tenant-id}}.app.logto ドメインも内部向けやテスト用途に備えて温存。これで「テスト環境っぽいログイン URL」と永遠にオサラバ。成長局面でのドメイン移行地獄を未来のあなたに残さずにすむ。
DNS レコード例やトラブル対策も含むステップバイステップ手順はこちら：
公式ドキュメント「カスタムドメイン」も要チェック！