Nginx、.htaccess、CDNルール、Edge Redirects: リダイレクトはどこで管理すべきか

Nginx、Apache .htaccess、CDNルール、アプリケーションのmiddleware、edge redirectsは、どれもURLを別のURLへ送れます。問題は「どの層ならリダイレクトできるか」ではありません。SEO、広告パラメータ、クライアント確認、本番反映、切り戻しが関わるとき、そのルールをどの層が持つべきかです。

単発の301なら、server configに置いても自然です。数万件の移行マップ、ドメイン変更でpathとUTMを残す必要があるケース、LINEやQRコード経由のリンクを端末別に分けたいケースを、複数の設定ファイルやプラグインに隠すのは危険です。

この記事は、WordPress、EC-CUBE、Shopify、BASE、STORES、自社CMS、headless構成、複数ブランドサイトの移行で、Nginx、.htaccess、CDNルール、CMSプラグインが混在しているチーム向けです。

判断の原則

リダイレクトは、そのルールを安全にレビューし、テストし、本番反映し、監視し、必要なら切り戻せる層に置きます。

リダイレクト事故の多くは、構文ミスだけで起きるわけではありません。責任が分かれすぎていることが原因です。

• 開発チームはNginxやアプリmiddlewareを持つ
• hostingや制作会社はApache .htaccess を触る
• SEO担当は移行マップとSearch Consoleのリスクを見る
• マーケティングは広告URL、UTM、LINE配信、QRコードを管理する
• CDN設定はHTTPS、root/www、hostname正規化を持つ
• クライアントや事業部は移行先ページを承認する

すべての層がリダイレクトできる状態では、ブラウザは最終的に到達するかもしれません。しかし、どのルールが発火したのか、なぜhopが増えたのか、どの層でqueryが消えたのか、どの変更を戻すべきかが見えなくなります。

まず実際のルーティングを描く

ルールを移す前に、requestが通る層を描きます。日本の既存サイトでは、次のような構成が珍しくありません。

1. DNSがhostnameをCDNまたはedge networkへ向ける
2. CDNルールがHTTPS、root/www、旧ドメイン、国別pathを正規化する
3. edge routingがキャンペーンリンク、ブランドリンク、移行マップを処理する
4. NginxまたはApacheがserver-level rewriteを実行する
5. .htaccess、WordPress、EC-CUBE、Shopify、CMSプラグインが別のルールを実行する
6. アプリmiddlewareがアカウント、商品、言語、キャンペーン、機能ルートを判断する

一番早く実行される層が、必ずしも安全とは限りません。安全なのは、そのルールの意図を持てる層です。HTTPS正規化はネットワーク層でよくても、クライアント確認済みの移行マップはレビューと切り戻しができる層に置くべきです。

server configが適している場合

NginxやApacheの主設定は、ルールが小さく安定しており、同じ開発チームがserver deployを持つ場合に向いています。

危険信号はNginxかApacheかではありません。SEO、広告、サポート、クライアントがそのルールを確認する必要があるなら、隠れたサーバーファイルはsystem of recordとして弱くなります。

.htaccessを移行システムにしない

.htaccessはApacheの分散設定のためにあります。主設定にアクセスできない場合には便利です。ただし、その柔軟さは移行案件ではリスクになります。

リダイレクト運用では、よく次の問題が起きます。

• ルールがディレクトリごとに散り、1つの移行マップとしてレビューできない
• per-directory rewriteはserver configの例とパスの扱いが違う
• hosting panel、FTP、CMS、プラグイン経由でrelease flowを迂回できる
• debug時に、最終レスポンス前にどのファイルが読まれたか把握する必要がある

Apacheのドキュメントも、主設定にアクセスできるなら .htaccess を避けることを勧めています。移行ではperformanceだけでなく、ガバナンスが重要です。移行マップにはowner、review status、import history、rollbackが必要であり、散らばったファイル編集だけでは足りません。

共有ホスティングや古いWordPressで他に選択肢がない場合は使えます。ただし、代理店の移行マップ、広告リンク、国別/端末別ルーティング、商品カタログ変更の長期管理場所にはしない方が安全です。

CDNルールで十分な場合

CDN redirect rulesは、ロジックが単純でネットワーク層に属する場合に向いています。

例：

• apexからwww、またはwwwからapex
• HTTPからHTTPS
• 少数の固定ドメイン転送
• 旧hostnameの廃止
• プラットフォームチームが持つメンテナンスredirect

一方で、CSV import、クライアントレビュー、path例外、query保持、rule-level analytics、国/端末条件、batch rollbackが必要になると、CDNルールだけでは運用しづらくなります。その段階では、redirectはネットワーク正規化ではなくtraffic infrastructureです。

edge redirectsが向いている場合

edge redirectsは、実行場所だけでなく運用workflowが必要なときに向いています。

たとえば次のような場合です。

• 大量の移行マップをimportし、レビューする
• path、query string、UTMの保持方針を管理する
• 国、端末、言語、header、cookie、campaignでdestinationを分ける
• ルールごとのhit数とanalyticsを見たい
• snapshotとして公開し、問題時にrollbackしたい
• SEO、マーケティング、開発、制作会社、クライアントが共同で確認する
• origin deployなしで高リスクURLを直したい

すべてのredirectをedgeへ移す必要はありません。ただし、変更頻度が高い、複数チームが見る、SEOや広告に影響するルールは、見えないサーバーファイルやCMSプラグインだけに置くべきではありません。

ownership matrixで分類する

移行前に、リダイレクトを意図とリスクで分類します。

この分類をしておくと、すべてのredirectを同じ設定行として扱わずに済みます。サーバー所有のcanonical redirectと、クライアント承認済みの移行マップはリスクが違います。

層を変える前に挙動を記録する

リダイレクトの置き場所を変えると、ガバナンスは改善しても挙動が変わることがあります。小さな移行として扱います。

変更前に記録するもの：

• source URL
• 現在の最終destination
• 現在のstatus code
• hop数
• query stringとUTMの挙動
• cookie、header、device、country条件
• rule owner
• rollback path

そのうえで、重要URLを Redirect Checker で確認します。SEO流入ページ、広告LP、LINEやQRで配布済みのURL、query付きpathを優先してください。ドメイン変更を含む場合は、pathやUTMを失わずにドメインをリダイレクトする方法 も見ておくと安全です。古い構成でhopが多い場合は、Redirect Chains and Loops を先に確認します。

よくある失敗

1つの意図を複数hopに分ける

http://old.example.jp/pricing
  -> https://old.example.jp/pricing
  -> https://www.old.example.jp/pricing
  -> https://www.new.example.jp/pricing

各ステップは単体では正しく見えます。まとめると、遅延、debugの難しさ、parameter消失の可能性が増えます。

CMSプラグインが基盤ルールを上書きする

WordPress、EC-CUBE、Shopify、その他CMSプラグインが、CDNやserverの判断後に再度redirectすることがあります。プラグインルールを残すなら、範囲を明確にし、QA対象に含める必要があります。

regexをレビューなしで使う

regexは大量のexact ruleを減らせます。ただし、広すぎるpatternは、本来個別判断すべきURLまで捕まえます。patternはanchorし、実URLでテストし、高価値例外は明示的なルールとして残します。

analyticsの所有者を決めない

redirectがserver configにあり、reportingが広告チームのスプレッドシートにあると、公開後に基本的な質問へ答えられません。どのruleが発火したか、どの国や端末で失敗したか、どのdestinationが404だったかを追えなくなります。

UrlEdgeでの位置づけ

UrlEdgeは、redirectがサーバーの小さな設定ではなくtraffic infrastructureになったときに使うための仕組みです。

基本の流れは次のとおりです。

1. Consoleでsource rule、owner、status code、path policy、query policy、notesを管理する
2. 大きなマップを Bulk URL Management でimportする
3. wildcardやregexを Advanced Redirect Rules で扱う
4. 条件付きdestinationが必要なら Geo Redirects や Device Targeting を使う
5. 重要URLを Redirect Checker で検証する
6. レビュー済みsnapshotをedgeへpublishし、rollbackを残す

data planeはCloudflare-backed edge infrastructure上で動きます。公開済みのドメイン設定は訪問者requestの近くで解決され、Consoleはreview、governance、analyticsの場になります。これにより、Nginx、.htaccess、CDNルール、CMSプラグインに散らばった脆いredirectを、originアプリをrouting control panel化せずに整理できます。

FAQ

edge routingは必ずNginxより速いですか？

必ずではありません。単純なserver redirectは十分速いことがあります。edge routingの価値は、origin dependencyを減らし、高頻度で変わるredirectにレビュー、監視、rollbackの運用モデルを持たせることです。

.htaccessのredirectはすぐ削除すべきですか？

いいえ。まず現在の挙動を理解し、別の層で再現できることを確認します。優先するのは、移行、キャンペーン、query、重複した意図、高価値URLに関わるルールです。

CDNルールとUrlEdgeは共存できますか？

できます。大切なのはownershipです。CDNはhostnameやprotocolの単純な正規化を持ち、UrlEdgeは移行マップ、branded links、条件付きrouting、analytics、rollbackを持つ、という分担が自然です。

何から移行すべきですか？

変更頻度が高いもの、複数チームが関わるもの、analyticsが必要なもの、SEOやcampaign価値があるものから始めます。安定していて低リスクなserver ruleは、明確な運用理由ができるまで残してかまいません。

参考資料

• Nginx: ngx_http_rewrite_module
• Apache HTTP Server: .htaccess files
• Apache HTTP Server: mod_rewrite
• Cloudflare Rules: Redirects
• MDN: Redirections in HTTP