Webアプリのカスタムドメイン設定：明確な DNS レコード手順、SSL 発行、リダイレクト、ダウンタイムやクッキー問題を避ける低リスクなカットオーバープラン。
カスタムドメインは単に見た目の良いURL以上のものです。プラットフォームのサブドメイン（例えば Koder.ai の下にあるアプリ）から自分のドメインに移す瞬間、ブラウザやネットワークは別のサイトとして扱います。これによりルーティング、セキュリティ、ユーザーセッションの挙動が変わります。
カスタムドメインに切り替えると、次の点がすぐに変わります：
www に寄せるか apex ドメインに寄せるかを決め、HTTP→HTTPS の一貫したルールが必要です。old-platform.example のログイン用クッキーは app.yourdomain.com では自動的に動作しません。短時間の障害は多くの場合タイミングの問題です。DNS が先に新ホストへトラフィックを送ると、SSL がまだ準備できておらずブラウザ警告が出ます。逆に SSL は有効でも、DNS キャッシュが残っていて多くのユーザーが古い場所へ行き続けることもあります。
リダイレクトはログインを微妙に壊すことがあります。ホスト名を変えるリダイレクト（apex → www、またはその逆）は、別ホスト用に設定されたクッキーを失わせます。認証プロバイダはコールバック URL が古いドメインのままなら失敗します。
リスクの少ないカットオーバーは重複を計画します：古い URL を動作させ続け、新しいドメインを並行して立ち上げ、予測可能な瞬間にトラフィックを切り替え、ロールバックは DNS を戻すだけで簡単にできるようにします。
作業を始める前に、ユーザーが実際に入力する名前と静かにリダイレクトすべき名前を正確に書き出してください。多くの「なぜ半分しか動かないのか」問題は、チームで唯一の正しいホスト名に合意していないことが原因です。
まず大きな選択：apex（example.com）を主要にするか、www（www.example.com）を主要にするか。どちらでも動きますが、1つを選び、もう一方はリダイレクト扱いにします。これはクッキーの面でも重要です：アプリは一貫したホストで動かす方がセッション管理が楽です。
次に今必要なサブドメインと後回しにできるものを決めます。よくあるパターンはウェブアプリに app.example.com、API に api.example.com、後で admin.example.com や assets.example.com を追加する形です。Koder.ai のようなプラットフォームでカスタムドメインを設定する場合、これらの選択は SSL 検証と DNS の指し先に直接影響します。
ドメインをレジストラで購入していても、DNS は別の場所でホストされていることが多いです。現在どこでレコードが編集されているか、誰がアクセス権を持っているか、変更を自動化している仕組みがあるか（社内の IT、代理店、マネージド DNS など）を確認してください。現在のレコードをログインして見られないなら、先にそれを解決してください。
またドメインを既に何が使っているか監査してください。メールは典型的な落とし穴で、レコードを削除や上書きするとメール配信が壊れます。
事前に次を文書化してください：
www）とリダイレクト方向マーケティングが既に example.com でメールを運用しているなら、メール関連のレコードは触らず、アプリに必要なレコードだけを追加してください。
カスタムドメイン移行でのリスクの大半はアプリ自体ではありません。誤った DNS 変更でトラフィックが行き先不明になったり、メールが壊れたり、SSL 検証が失敗したりすることです。
A レコードは名前を IP アドレスに向けます。簡単に言えば「このサーバーに送れ」です。プロバイダが固定 IP を与える場合、apex（example.com）によく使います。
CNAME レコードはある名前を別の名前に向けるエイリアスです。簡単に言えば「この名前はあのホスト名の別名として扱え」です。www.example.com をプラットフォームのホスト名に向けるときに一般的です。
多くの DNS プロバイダは apex 用に ALIAS/ANAME を提供します。これは CNAME のように振る舞いますが example.com で使えます。対応していれば、ターゲットが動いても IP を直接触らずに済むので管理が楽です。
簡単なモデル：
TXT レコードはドメイン所有の確認（プラットフォーム検証）や SSL 証明書の検証 トークンに使われます。TXT は SPF のようなメールポリシーにも使われます。既存の SPF TXT を誤って削除・上書きするとメールが壊れます。
TTL は他のシステムが DNS の応答をどれだけ長くキャッシュするかを制御します。カットオーバーの1日前に、変更予定のレコードの TTL を下げておく（一般的に 300～600 秒）。安定したら再び TTL を上げて負荷を減らします。
編集前にゾーンをエクスポートするかスクリーンショットを取り、変更する各レコードの古い値・新しい値・TTL を書き出してください。問題が起きたらロールバックは以前の値に戻すことです。
既に MX、DKIM、その他の TXT を使っているドメインではこれが最も重要です。
SSL（鍵マーク）はブラウザとアプリ間の通信を暗号化します。現代のブラウザや多くの API はデフォルトで HTTPS を期待します。HTTPS がないと警告やブロックが発生し、Service Worker、位置情報、決済フローなどが動作しないことがあります。
証明書を発行するには CA がドメインの所有を確認する必要があります。一般的な検証方法は HTTP 検証と DNS TXT 検証です：
CDN を使っている場合や新ドメインでアプリにまだ到達できない場合は、DNS 検証が楽なことが多いです。
証明書をどこで発行するかは構成によります。チームがホスティング側で直接発行することもあれば、CDN 側で発行することもあります。カスタムドメインをサポートするプラットフォーム（例：Koder.ai）が証明書を管理してくれる場合もあります。重要なのは更新を含む証明書のライフサイクルを誰が管理するかを把握することです。
証明書の発行は常に即時ではありません。DNS 浸透、検証チェック、レート制限などで遅れることがあります。再試行を計画し、カットオーバーをぎりぎりの時間に設定しないでください。
実務的なタイミング計画：
証明書はユーザーがアクセスする全てのホスト名をカバーしている必要があります。SAN（Subject Alternative Names）リストを確認してください。アプリを example.com と www.example.com の両方で提供するなら、両方を含める必要があります。
ワイルドカード（*.example.com）は多くのサブドメインに便利ですが、apex（example.com）はカバーしません。
具体例：www.example.com だけの証明書を発行すると、ユーザーが example.com を入力した場合、適切なリダイレクトや example.com 用の有効な証明書がなければ警告が出ます。
リダイレクトは単純に聞こえますが、ここでほとんどのドメイン問題が発生します：ループ、混在コンテンツ、ユーザーがホスト間を行き来してログアウトしてしまうなど。
1つの正規ホストを選び、それに従ってください：www.example.com か example.com（apex）のどちらか。もう一方は選ばれたホストへリダイレクトするようにします。こうすることでクッキー、セッション、SEO が一貫します。
安全なデフォルト：
http:// → https:// に 301 リダイレクト。HTTP→HTTPS ではユーザーを往復させないルールが必要です。ループを防ぐ最も簡単な方法はリクエストの実際のスキームに基づいて判定することです。アプリがプロキシや CDN の背後にある場合、元のスキームが何であったかを示す転送ヘッダを尊重するよう設定してください。そうでないとアプリはすべてのリクエストが HTTP だと誤認し、永遠にリダイレクトし続ける可能性があります。
移行中は古いパスを維持してください。ルートを変更する場合（例：/login を /sign-in に変えるなど）は、該当パスの明示的なリダイレクトを追加してください。汎用的にホームへ飛ばすだけではブックマークや共有リンクが壊れます。
HSTS は最初は保留にしてください。早すぎる適用は後で検証やトラブルシュートのために HTTP を使う必要がある場合にブラウザが拒否してしまうことがあります。HTTPS が安定し、サブドメインのカバレッジが確認できてから有効にしましょう。
影響を限定してリダイレクトを検証するには、一時的なテストホスト名を使い、いくつかの実際のディープリンク（認証ページを含む）を試し、コマンドラインでリダイレクトのステップと最終到達先を確認してください。
安全なカットオーバーはほとんどがタイミングの問題です。新しいドメインをテスト済みで準備が整ってから実際のユーザーを受け入れ、DNS 変更が迅速に広がるようにして、問題が起きたときに速やかに対応できるようにします。
変更を加える前に DNS TTL を下げてください（変更する予定のレコードのみ）。可能であれば前日に下げ、古い TTL が切れるのを待ちます。
次にホスティング／プロバイダでカスタムドメインを追加し、必要な検証を完了します。Koder.ai のようなプラットフォームを使っている場合は、先にドメインを追加してプラットフォーム側で所有権確認やルーティング準備をさせます。
SSL は早めに発行してください。検証によっては数分以上かかることがあるため、切り替え時にその遅延が発生しないようにしておきます。
公開前にプライベートな検証を行ってください：ローカルの hosts エントリなどでパブリック DNS に依存せずに新エンドポイントを叩き、HTTPS と正しい証明書でサイトが読み込まれることを確認します。
段階的アプローチで問題があればすぐ止められるようにします：
www）で SSL が有効であることを確認してからユーザーを切り替える。DNS レベルでのカナリアができない場合でも、まず www だけを切り替えて apex は残すなど、ホスト名単位で段階的に進められます。
どのレコードを元に戻すか、誰が行うかを事前に書いておいてください。ロールバックは通常 DNS を元の状態に戻すことです。
古いセットアップが有効であること（古いドメインの SSL も含めて）を確認し、ユーザーが戻れるようにしてから問題を修正します。
ドメイン変更は単なる DNS の変更以上です。多くのアプリでは「ログイン状態」はブラウザが特定のホスト名に紐づけたクッキーに依存しています。ホスト名を変えるとブラウザは古いクッキーを送らなくなり、アプリは全員がログアウトしたように見えることがあります。
クッキー設定が原因であることが多い点：
app.old.com 用に設定されたクッキーは app.new.com に送られません。.example.com のように設定すれば app.example.com と www.example.com の間で共有できます。Lax が一般的に問題ないことが多いですが、一部の SSO や決済リダイレクトでは None と Secure が必要です。リスクを減らすため、短期間だけ両方のドメインを動かす移行を計画してください。古いホスト名をリクエストに応答させ、慎重にリダイレクトしつつ、新ドメインでセッションを更新できるようにします。可能であれば共有のセッションストアを使い、どちらのホスト名に当たってもユーザーを認識できるようにします。
SSO や OAuth を使っている場合はカットオーバー前に設定を更新してください：コールバック URL、許可されるオリジン、リダイレクト URI のホワイトリストなど。これらが古いドメインのままだと、ID プロバイダでのサインインは成功してもアプリに戻る際に失敗します。
まず壊れやすいフローをテストしてください：サインアップ（メール確認含む）、ログイン/ログアウト、パスワードリセット、決済の戻り、複数タブでのセッションなど。
例：www.example.com を example.com にリダイレクトする場合、クッキーを .example.com に設定するか、常に一方のホスト名を使うようにしないとユーザーがホスト間を往復してセッションを失います。
ほとんどのドメイン問題は「謎のインターネット障害」ではありません。DNS、証明書、リダイレクトルールの小さな不一致が本番ユーザーが来たときに露呈するだけです。
簡単に陥る罠のひとつは apex ドメインです（example.com）。多くの DNS プロバイダは apex に真の CNAME を置けません。apex に CNAME を無理に設定すると静かに失敗したり、一部ネットワークだけで不安定に解決されたりします。DNS ホストがサポートする方法（A/AAAA、あるいは ALIAS/ANAME）を使ってください。
別の頻繁に起きる原因は SSL が新しいエンドポイントで準備できる前に DNS を切り替えてしまうことです。ユーザーが到着してアプリは読み込まれるが、証明書がなく一部ホスト名しかカバーしていないためブラウザがブロックします。実務では example.com と www.example.com の両方をカバーする証明書を用意しておくことが望ましいです。
よくあるミス：
www → apex、apex → www）や、一方で HTTP を強制し他方で HTTPS を強制する矛盾http:// をハードコードしたアセットによる混在コンテンツを配信してしまい、ブラウザ警告や機能不全を引き起こす簡単なチェック：両方のホスト名（www と apex）を HTTPS で開き、ログインしてリロードし、アドレスバーが HTTP に戻らないことを確認してください。
Koder.ai のようなプラットフォームでこれを行う場合でも、カスタムドメインが接続され SSL が発行されていることを確認してから本番 DNS を触り、悪いリダイレクトやレコード変更が長時間残らないようロールバックオプションを用意しておいてください。
落ち着いたカットオーバーは準備作業が大半です。目標は単純：ユーザーはログインを維持し、クッキーが動作し、問題があればすぐロールバックできることです。
これらは古いドメインにトラフィックがある間に行ってください。可能なら1日かけて DNS 変更が落ち着く時間を取ります。
www、api など）を文書化し、SSL 検証方法（DNS または HTTP）を決める。www→apex（またはその逆）、単一の正規ホスト。DNS を切り替えたら最初の 1 時間をインシデント演習のように扱い、ダッシュボードだけでなく実際のユーザーフローを監視してください。
プラットフォームがカスタムドメインや SSL を自動で処理してくれる場合でも、このチェックリストは重要です。多くの問題は DNS とリダイレクトから生じ、アプリコードではありません。
アプリが myapp.koder.ai のような一時的なプラットフォームアドレスで動いているとします。動いていますが、顧客に example.com を使ってほしい。www.example.com は apex にリダイレクトし、全て HTTPS に強制したいとします。
リスクを低くする簡単な DNS 計画：何も変更する前に現在の動作状態を記録（スナップショットが取れるなら取る）し、事前に DNS TTL を短くしておきます。
既存のプラットフォーム URL を残したまま新しいレコードを追加します：
example.com: プラットフォームが提供するホスティングターゲットを指す A/ALIAS レコードwww.example.com: example.com（またはプロバイダのターゲット）を指す CNAMEmyapp.koder.ai はそのまま残して既知の正常なフォールバックを維持DNS が整ったら両方のホスト名（example.com と www.example.com）の SSL を申請します。証明書が発行され有効になるまでトラフィックは切り替えないでください。そうしないとブラウザ警告が発生します。
明確なチェックポイントを含むカットオーバーのタイムライン：
example.com をテスト（ホーム、静的アセット、API コール）www→apex）移行後はクッキーの挙動を検証してください。ログインしてリロードし、www と apex の両方でログイン状態が維持されるか確認します。セッションが切れる場合、多くはクッキーのドメインや SameSite 設定が古いホストを前提にしていることが原因です。
カットオーバーが成功しても仕事は終わりません。ほとんどのドメイン移行トラブルは後で発生します：証明書の有効期限切れ、慌てた DNS 変更、リダイレクトの変更でログインフローが壊れるなど。
実際に続けられる小さな監視ルーチンを設定してください。エンタープライズツールは不要ですが、信頼できるいくつかの指標は必要です：主要ページ（ホーム、ログイン、認証済みページ）の可用性チェック、証明書有効期限のアラート（30 日前と 7 日前など）、エラー率の追跡（単なるアップタイムではなく 4xx/5xx の急増を監視）、定期的なリダイレクト検証（HTTP が HTTPS に行き、正規ホストが表示されること）など。
自信がついたら DNS TTL を元に戻してください。低 TTL は変更時に便利ですが、解決回数が増えて小さなミスの影響が大きくなります。多くのチームは通常 1～4 時間の TTL を選びます。
最後に、状態が鮮明なうちに最終状態を文書化してください：存在するレコード（タイプ、名前、値、TTL）、サポートするホスト名、正確なリダイレクトルール、証明書がどこで発行されているか、何をカバーしているか（apex、www、サブドメイン）、更新を誰が管理しているか。
プラットフォーム上で構築・デプロイしている場合、ドメインがファーストクラス機能として扱われ、スナップショットやロールバックが簡単なら、将来のドメインやリダイレクト変更が必要になったときのストレスは減ります。Koder.ai ではカスタムドメインがスナップショットやロールバックと並列に扱われるため、何かを素早く元に戻す必要があるときに役立ちます。
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.