Webアプリのカスタムドメイン設定：DNS、SSL、カットオーバー

カスタムドメインで何が変わる（何が起こりうるか）

カスタムドメインは単に見た目の良いURL以上のものです。プラットフォームのサブドメイン（例えば Koder.ai の下にあるアプリ）から自分のドメインに移す瞬間、ブラウザやネットワークは別のサイトとして扱います。これによりルーティング、セキュリティ、ユーザーセッションの挙動が変わります。

カスタムドメインに切り替えると、次の点がすぐに変わります：

• DNS ルーティング：ユーザーは古いホスト名ではなく、DNS が指す先に到達します。
• TLS/SSL：証明書は新しいホスト名に合致している必要があり、実際のユーザーが来る前に有効でなければなりません。
• リダイレクト：www に寄せるか apex ドメインに寄せるかを決め、HTTP→HTTPS の一貫したルールが必要です。
• クッキーとセッション：クッキーはドメインに紐づきます。old-platform.example のログイン用クッキーは app.yourdomain.com では自動的に動作しません。
• キャッシュと浸透：DNS リゾルバやブラウザは結果をキャッシュするため、全員が同時に切り替わるわけではありません。

短時間の障害は多くの場合タイミングの問題です。DNS が先に新ホストへトラフィックを送ると、SSL がまだ準備できておらずブラウザ警告が出ます。逆に SSL は有効でも、DNS キャッシュが残っていて多くのユーザーが古い場所へ行き続けることもあります。

リダイレクトはログインを微妙に壊すことがあります。ホスト名を変えるリダイレクト（apex → www、またはその逆）は、別ホスト用に設定されたクッキーを失わせます。認証プロバイダはコールバック URL が古いドメインのままなら失敗します。

リスクの少ないカットオーバーは重複を計画します：古い URL を動作させ続け、新しいドメインを並行して立ち上げ、予測可能な瞬間にトラフィックを切り替え、ロールバックは DNS を戻すだけで簡単にできるようにします。

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 を管理しているかを把握する

ドメインをレジストラで購入していても、DNS は別の場所でホストされていることが多いです。現在どこでレコードが編集されているか、誰がアクセス権を持っているか、変更を自動化している仕組みがあるか（社内の IT、代理店、マネージド DNS など）を確認してください。現在のレコードをログインして見られないなら、先にそれを解決してください。

またドメインを既に何が使っているか監査してください。メールは典型的な落とし穴で、レコードを削除や上書きするとメール配信が壊れます。

事前に次を文書化してください：

• 主要ホスト名（apex か www）とリダイレクト方向
• 今必要なサブドメイン（app、api、admin）と将来の案
• DNS がどこでホストされているか、誰が公開できるか
• 既存の重要なレコード（MX、SPF、DKIM、DMARC、検証用 TXT）
• クッキーと認証の期待値（単一ホストかサブドメイン間で共有するか）

マーケティングが既に example.com でメールを運用しているなら、メール関連のレコードは触らず、アプリに必要なレコードだけを追加してください。

使用する DNS レコードとその重要性

カスタムドメイン移行でのリスクの大半はアプリ自体ではありません。誤った DNS 変更でトラフィックが行き先不明になったり、メールが壊れたり、SSL 検証が失敗したりすることです。

コアなレコード（A、CNAME、その他）

A レコードは名前を IP アドレスに向けます。簡単に言えば「このサーバーに送れ」です。プロバイダが固定 IP を与える場合、apex（example.com）によく使います。

CNAME レコードはある名前を別の名前に向けるエイリアスです。簡単に言えば「この名前はあのホスト名の別名として扱え」です。www.example.com をプラットフォームのホスト名に向けるときに一般的です。

多くの DNS プロバイダは apex 用に ALIAS/ANAME を提供します。これは CNAME のように振る舞いますが example.com で使えます。対応していれば、ターゲットが動いても IP を直接触らずに済むので管理が楽です。

簡単なモデル：

• A: name -> IP（直接）
• CNAME: name -> name（エイリアス）
• TXT: name -> text（所有証明やポリシー）
• MX: name -> メールサーバー（触るつもりがないなら触らない）

TXT レコード：検証、SSL、メールの安全性

TXT レコードはドメイン所有の確認（プラットフォーム検証）や SSL 証明書の検証 トークンに使われます。TXT は SPF のようなメールポリシーにも使われます。既存の SPF TXT を誤って削除・上書きするとメールが壊れます。

TTL：変更速度のつまみ

TTL は他のシステムが DNS の応答をどれだけ長くキャッシュするかを制御します。カットオーバーの1日前に、変更予定のレコードの TTL を下げておく（一般的に 300～600 秒）。安定したら再び TTL を上げて負荷を減らします。

既存レコードを上書きしない、ロールバックを記録する

編集前にゾーンをエクスポートするかスクリーンショットを取り、変更する各レコードの古い値・新しい値・TTL を書き出してください。問題が起きたらロールバックは以前の値に戻すことです。

既に MX、DKIM、その他の TXT を使っているドメインではこれが最も重要です。

SSL 発行：検証方法、タイミング、カバレッジ

SSL（鍵マーク）はブラウザとアプリ間の通信を暗号化します。現代のブラウザや多くの API はデフォルトで HTTPS を期待します。HTTPS がないと警告やブロックが発生し、Service Worker、位置情報、決済フローなどが動作しないことがあります。

証明書を発行するには CA がドメインの所有を確認する必要があります。一般的な検証方法は HTTP 検証と DNS TXT 検証です：

• HTTP 検証はアプリ上の特定の URL に一時的なファイルやレスポンスを置きます。
• DNS TXT 検証は DNS ゾーンに TXT レコードを追加します。

CDN を使っている場合や新ドメインでアプリにまだ到達できない場合は、DNS 検証が楽なことが多いです。

証明書をどこで発行するかは構成によります。チームがホスティング側で直接発行することもあれば、CDN 側で発行することもあります。カスタムドメインをサポートするプラットフォーム（例：Koder.ai）が証明書を管理してくれる場合もあります。重要なのは更新を含む証明書のライフサイクルを誰が管理するかを把握することです。

タイミングと再試行

証明書の発行は常に即時ではありません。DNS 浸透、検証チェック、レート制限などで遅れることがあります。再試行を計画し、カットオーバーをぎりぎりの時間に設定しないでください。

実務的なタイミング計画：

• 事前に DNS TTL を下げておき、変更が早く反映されるようにする。
• 検証レコード（DNS TXT や HTTP トークン）を早めに追加する。
• 証明書がすべてのホスト名で発行されたことを確認してからトラフィックを切り替える。

カバレッジ：正しいホスト名が含まれているか確認する

証明書はユーザーがアクセスする全てのホスト名をカバーしている必要があります。SAN（Subject Alternative Names）リストを確認してください。アプリを example.com と www.example.com の両方で提供するなら、両方を含める必要があります。

ワイルドカード（*.example.com）は多くのサブドメインに便利ですが、apex（example.com）はカバーしません。

具体例：www.example.com だけの証明書を発行すると、ユーザーが example.com を入力した場合、適切なリダイレクトや example.com 用の有効な証明書がなければ警告が出ます。

リダイレクトルール：www、apex、HTTP→HTTPS と安全なデフォルト

リダイレクトは単純に聞こえますが、ここでほとんどのドメイン問題が発生します：ループ、混在コンテンツ、ユーザーがホスト間を行き来してログアウトしてしまうなど。

1つの正規ホストを選び、それに従ってください：www.example.com か example.com（apex）のどちらか。もう一方は選ばれたホストへリダイレクトするようにします。こうすることでクッキー、セッション、SEO が一貫します。

安全なデフォルト：

• 1つの正規ホスト。もう一方からは単一の 301 リダイレクト。
• すべてのリクエストで http:// → https:// に 301 リダイレクト。
• リダイレクト中はパスとクエリ文字列を保持（ディープリンクが動くように）。
• リダイレクトは一度だけ行う（http → https → www のようなチェーンは避ける）。

HTTP→HTTPS ではユーザーを往復させないルールが必要です。ループを防ぐ最も簡単な方法はリクエストの実際のスキームに基づいて判定することです。アプリがプロキシや CDN の背後にある場合、元のスキームが何であったかを示す転送ヘッダを尊重するよう設定してください。そうでないとアプリはすべてのリクエストが HTTP だと誤認し、永遠にリダイレクトし続ける可能性があります。

移行中は古いパスを維持してください。ルートを変更する場合（例：/login を /sign-in に変えるなど）は、該当パスの明示的なリダイレクトを追加してください。汎用的にホームへ飛ばすだけではブックマークや共有リンクが壊れます。

HSTS は最初は保留にしてください。早すぎる適用は後で検証やトラブルシュートのために HTTP を使う必要がある場合にブラウザが拒否してしまうことがあります。HTTPS が安定し、サブドメインのカバレッジが確認できてから有効にしましょう。

影響を限定してリダイレクトを検証するには、一時的なテストホスト名を使い、いくつかの実際のディープリンク（認証ページを含む）を試し、コマンドラインでリダイレクトのステップと最終到達先を確認してください。

ダウンタイムを避ける段階的なカットオーバープラン

安全なカットオーバーはほとんどがタイミングの問題です。新しいドメインをテスト済みで準備が整ってから実際のユーザーを受け入れ、DNS 変更が迅速に広がるようにして、問題が起きたときに速やかに対応できるようにします。

1) 本番 DNS を触る前の準備とテスト

変更を加える前に DNS TTL を下げてください（変更する予定のレコードのみ）。可能であれば前日に下げ、古い TTL が切れるのを待ちます。

次にホスティング／プロバイダでカスタムドメインを追加し、必要な検証を完了します。Koder.ai のようなプラットフォームを使っている場合は、先にドメインを追加してプラットフォーム側で所有権確認やルーティング準備をさせます。

SSL は早めに発行してください。検証によっては数分以上かかることがあるため、切り替え時にその遅延が発生しないようにしておきます。

公開前にプライベートな検証を行ってください：ローカルの hosts エントリなどでパブリック DNS に依存せずに新エンドポイントを叩き、HTTPS と正しい証明書でサイトが読み込まれることを確認します。

2) 小さく、可逆に切り替える

段階的アプローチで問題があればすぐ止められるようにします：

• 事前に TTL を下げ、以前の TTL 期間が完全に経過するのを待つ。
• ホスト側でドメイン検証を完了し、内部的に正しいアプリへ向いていることを確認する。
• すべてのホスト名（apex と/または www）で SSL が有効であることを確認してからユーザーを切り替える。
• DNS の変更は管理された方法で行う：可能ならサブドメインや一部リージョン、限定されたユーザーで先に切り替える。
• 古いドメインは稼働させてリダイレクトを継続し、トラフィックとエラー率が安定するのを観察する。

DNS レベルでのカナリアができない場合でも、まず www だけを切り替えて apex は残すなど、ホスト名単位で段階的に進められます。

3) 落ち着いているうちにロールバックを計画する

どのレコードを元に戻すか、誰が行うかを事前に書いておいてください。ロールバックは通常 DNS を元の状態に戻すことです。

古いセットアップが有効であること（古いドメインの SSL も含めて）を確認し、ユーザーが戻れるようにしてから問題を修正します。

切り替え後のクッキー、セッション、認証回りの回避策

ドメイン変更は単なる DNS の変更以上です。多くのアプリでは「ログイン状態」はブラウザが特定のホスト名に紐づけたクッキーに依存しています。ホスト名を変えるとブラウザは古いクッキーを送らなくなり、アプリは全員がログアウトしたように見えることがあります。

クッキー設定が原因であることが多い点：

• Domain はどのホスト名がクッキーを受け取るかを決めます。app.old.com 用に設定されたクッキーは app.new.com に送られません。.example.com のように設定すれば app.example.com と www.example.com の間で共有できます。
• Path はクッキーが送られる経路を制限します。狭すぎると UI がクッキーを見られないことがあります。
• Secure はクッキーが HTTPS のみで送られることを意味します。HTTPS に限定した移行では HTTP リクエストでは送られません。
• SameSite はクロスサイトのリダイレクトや埋め込みフローに影響します。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 の両方をカバーする証明書を用意しておくことが望ましいです。

よくあるミス：

• 変更前に TTL を下げないで DNS を変えてしまい、古い応答が切れるまで何時間も待つ
• ループを作るリダイレクトルール（www → apex、apex → www）や、一方で HTTP を強制し他方で HTTPS を強制する矛盾
• http:// をハードコードしたアセットによる混在コンテンツを配信してしまい、ブラウザ警告や機能不全を引き起こす
• MX や TXT といった非ウェブの DNS レコードを忘れてメールやドメイン検証が壊れる
• ひとつのブラウザだけでテストして、キャッシュされた HSTS やクッキーの癖を見逃す

簡単なチェック：両方のホスト名（www と apex）を HTTPS で開き、ログインしてリロードし、アドレスバーが HTTP に戻らないことを確認してください。

Koder.ai のようなプラットフォームでこれを行う場合でも、カスタムドメインが接続され SSL が発行されていることを確認してから本番 DNS を触り、悪いリダイレクトやレコード変更が長時間残らないようロールバックオプションを用意しておいてください。

カットオーバー前・中・後のクイックチェックリスト

落ち着いたカットオーバーは準備作業が大半です。目標は単純：ユーザーはログインを維持し、クッキーが動作し、問題があればすぐロールバックできることです。

カットオーバー前

これらは古いドメインにトラフィックがある間に行ってください。可能なら1日かけて DNS 変更が落ち着く時間を取ります。

• 変更予定のレコードの DNS TTL を下げ、現在の値を記録してすぐに戻せるようにする。
• 提供するすべてのホスト名（apex、www、api など）を文書化し、SSL 検証方法（DNS または HTTP）を決める。
• リダイレクトルールを用意してステージングでテストする：HTTP→HTTPS、www→apex（またはその逆）、単一の正規ホスト。
• 正確な URL に依存する認証設定を更新する：OAuth コールバック URL、許可オリジン、クッキーのドメイン設定、SSO 設定など。
• カットオーバー中に誰が何を監視するか（ログ、稼働監視、サポート受信箱）を決め、短い変更ウィンドウを設定する。

カットオーバー中と後

DNS を切り替えたら最初の 1 時間をインシデント演習のように扱い、ダッシュボードだけでなく実際のユーザーフローを監視してください。

• 実行中：4xx/5xx の急増、リダイレクトループ、ログイン失敗（特に “invalid redirect URI” や急なセッション切れ）を監視。
• 後で：複数ブラウザで証明書チェーンが有効か、重要ページが HTTPS で混在コンテンツなしに表示されるか確認。
• 後で：正規ホストがアドレスバーに表示されること、重要なクッキーが設定され送信されることを確認。
• 後で：古いドメインはしばらくリダイレクトを続ける。多くのユーザーは古いブックマークやメール経由で戻ってくる。

プラットフォームがカスタムドメインや SSL を自動で処理してくれる場合でも、このチェックリストは重要です。多くの問題は DNS とリダイレクトから生じ、アプリコードではありません。

例：プラットフォーム URL からカスタムドメインへ移行する場合

アプリが myapp.koder.ai のような一時的なプラットフォームアドレスで動いているとします。動いていますが、顧客に example.com を使ってほしい。www.example.com は apex にリダイレクトし、全て HTTPS に強制したいとします。

リスクを低くする簡単な DNS 計画：何も変更する前に現在の動作状態を記録（スナップショットが取れるなら取る）し、事前に DNS TTL を短くしておきます。

既存のプラットフォーム URL を残したまま新しいレコードを追加します：

• example.com: プラットフォームが提供するホスティングターゲットを指す A/ALIAS レコード
• www.example.com: example.com（またはプロバイダのターゲット）を指す CNAME
• myapp.koder.ai はそのまま残して既知の正常なフォールバックを維持

DNS が整ったら両方のホスト名（example.com と www.example.com）の SSL を申請します。証明書が発行され有効になるまでトラフィックは切り替えないでください。そうしないとブラウザ警告が発生します。

明確なチェックポイントを含むカットオーバーのタイムライン：

• T-24h: TTL を下げ、すぐにロールバックできることを確認
• T-0: アプリホストでドメインを有効にし、SSL が準備できていることを確認
• T+15m: シークレットウィンドウで example.com をテスト（ホーム、静的アセット、API コール）
• T+30m: リダイレクトを有効化（HTTP→HTTPS、www→apex）
• ロールバックの瞬間: ログインや API コールが失敗したら、DNS を以前のターゲットに戻しプラットフォーム URL を維持

移行後はクッキーの挙動を検証してください。ログインしてリロードし、www と apex の両方でログイン状態が維持されるか確認します。セッションが切れる場合、多くはクッキーのドメインや SameSite 設定が古いホストを前提にしていることが原因です。

次のステップ：監視、文書化、将来の変更を安全にする

カットオーバーが成功しても仕事は終わりません。ほとんどのドメイン移行トラブルは後で発生します：証明書の有効期限切れ、慌てた DNS 変更、リダイレクトの変更でログインフローが壊れるなど。

実際に続けられる小さな監視ルーチンを設定してください。エンタープライズツールは不要ですが、信頼できるいくつかの指標は必要です：主要ページ（ホーム、ログイン、認証済みページ）の可用性チェック、証明書有効期限のアラート（30 日前と 7 日前など）、エラー率の追跡（単なるアップタイムではなく 4xx/5xx の急増を監視）、定期的なリダイレクト検証（HTTP が HTTPS に行き、正規ホストが表示されること）など。

自信がついたら DNS TTL を元に戻してください。低 TTL は変更時に便利ですが、解決回数が増えて小さなミスの影響が大きくなります。多くのチームは通常 1～4 時間の TTL を選びます。

最後に、状態が鮮明なうちに最終状態を文書化してください：存在するレコード（タイプ、名前、値、TTL）、サポートするホスト名、正確なリダイレクトルール、証明書がどこで発行されているか、何をカバーしているか（apex、www、サブドメイン）、更新を誰が管理しているか。

プラットフォーム上で構築・デプロイしている場合、ドメインがファーストクラス機能として扱われ、スナップショットやロールバックが簡単なら、将来のドメインやリダイレクト変更が必要になったときのストレスは減ります。Koder.ai ではカスタムドメインがスナップショットやロールバックと並列に扱われるため、何かを素早く元に戻す必要があるときに役立ちます。