IntelliAI Tools

ホスティングを乗り換えると、設定ファイルが全部使えなくなる

公開 ・ 公開と運用

ホスティングを乗り換えることになったとき、最初に思うのは「コードはそのままだから、繋ぎ直すだけだろう」です。

半分は合っています。アプリケーションのコードは、ほぼそのまま動きます。 静的サイトなら確実に動きます。

引き継げないのは、コードの外側にある設定です。そしてこれが、移行作業の大半を占めます。

このサイトは当初 Cloudflare Pages を前提に設計し、途中で AWS Amplify に変更しました。書いていた設定ファイルは1つも使えませんでした。 そのとき洗い出した内容を書きます。

引き継げるもの、引き継げないもの

引き継げるか
アプリケーションのコード ✅ そのまま
package.json と依存関係 ✅ そのまま
ビルドコマンド（npm run build） ✅ そのまま
出力ディレクトリ（dist/ など） ✅ そのまま
リダイレクトの設定 ❌ 形式が違う
レスポンスヘッダーの設定 ❌ 形式が違う
404の扱い ❌ 挙動が違う
ビルドの設定ファイル ❌ 形式が違う
環境変数 ❌ 手で登録し直し
独自ドメインとDNS ❌ 切り替え作業が必要

上4つは自動、下6つは手作業です。**そして下の6つは、間違えても「動いているように見える」**ものが多い。ここが厄介なところです。

リダイレクトの書き方がサービスごとに違う

同じことをするのに、書く場所も書式も違います。

サービス リダイレクトの指定方法
Cloudflare Pages public/_redirects（テキストファイル）
Netlify public/_redirects または netlify.toml
Vercel vercel.json の redirects / rewrites
AWS Amplify コンソールの「書き換えとリダイレクト」画面

Amplify だけファイルではありません。 リポジトリに _redirects を置いても読まれませんし、エラーにもなりません。黙って無視されます。

これが一番危ない形です。設定を書いてデプロイし、サイトは正常に表示される。リダイレクトだけが効いていない。テストしなければ気づきません。

このサイトでは www ありのドメインを www なしに寄せる301リダイレクトを、コンソールでこう設定しています。

送信元 ターゲット 種類
https://www.example.com/<*> https://example.com/<*> 301

<*> の書き方も Amplify 固有です。Cloudflare Pages や Netlify の _redirects では /* と :splat を使います。

# Cloudflare Pages / Netlify の書き方（Amplifyでは無効）
https://www.example.com/* https://example.com/:splat 301!

同じ意図の設定でも、書式が一致しません。変換してくれる仕組みはないので、手で書き直します。

レスポンスヘッダーも同じ構図

セキュリティ関連のヘッダー（X-Content-Type-Options、Strict-Transport-Security など）も、指定先が違います。

サービス ヘッダーの指定方法
Cloudflare Pages / Netlify public/_headers
Vercel vercel.json の headers
AWS Amplify リポジトリルートの customHttp.yml

Amplify は customHttp.yml という独自形式のファイルをリポジトリのルートに置きます。public/ の中ではなく、ルートです。場所も名前も形式も、他と一致しません。

public/_headers を置いたままにしても、やはり黙って無視されます。 ヘッダーが付いていないことは、ブラウザの開発者ツールでレスポンスヘッダーを見るまで分かりません。

ビルドの設定ファイル

各サービスがビルド手順を書くファイルを持っています。

サービス ファイル
Netlify netlify.toml
Vercel vercel.json
AWS Amplify amplify.yml（リポジトリルート）

Amplify の場合はこうなります。

version: 1
frontend:
  phases:
    preBuild:
      commands:
        - npm ci
    build:
      commands:
        - npm run build
  artifacts:
    baseDirectory: dist
    files:
      - '**/*'
  cache:
    paths:
      - node_modules/**/*

中身の意味はどのサービスでも同じです。「依存を入れて、ビルドして、dist を配る」。書式だけが違います。

404の扱いが一番差が出る

移行で見落とされやすく、影響が大きいのがここです。

Amplify はアプリを繋いだ時点で、あらゆるURLに index.html を200で返すという SPA 用のルールを既定で入れます。ページごとにHTMLがある静的サイトでは、これが入っていると存在しないURL全部が200を返します。

Cloudflare Pages や Netlify では、404.html があれば自動でそれを404で返すので、同じ問題は起きません。つまり、移行してはじめて壊れます。

詳しくは「AWS Amplifyの既定設定のままだと、存在しないURLが全部200を返す」に書きました。移行する場合は、切り替え直後に必ず確認してください。

移行前に洗い出す項目

作業を始める前に、現在の設定を一覧にしておくと手戻りが減ります。このサイトで使ったリストです。

リダイレクト

レスポンスヘッダー

その他

確認

AIに任せられる範囲

コードの変換や設定ファイルの書き換えは、AIに頼めば短時間で終わります。「この _redirects を Amplify のコンソール設定用の表に直して」と頼めば、そのまま出てきます。

任せられないのは、コンソールでの操作です。 リダイレクトの登録、ドメインの接続、環境変数の入力、DNSレコードの書き換え。これらは画面を開いて自分で押す必要があります。

そして、移行作業の失敗はほとんどここで起きます。 設定を1つ登録し忘れても、サイトは表示されるからです。

だから、移行そのものより移行後の確認のほうが重要です。上のチェックリストの「確認」の3項目は、実際にコマンドを打って数字を見てください。見た目では分かりません。

まとめ

コードを動かすのは1時間で終わります。設定を揃えるほうに時間がかかります。