Microsoft Edge で特定サイトを開くと「Coming Soon」へリダイレクトされてしまい、Chrome や Safari では正常に見える――そんな“Edge だけおかしい”状況に直面したときの原因と実務的な解決策を、PC（Windows）と iPhone/Android の両方で徹底解説します。今回は https://mywingstopsurvey.com（旧 URL: https://wingstop.com/survey）のケースを例に、サイト側要因とブラウザー側対処を整理しました。
Edgeで特定サイトが「Coming Soon」にリダイレクトされる現象の全体像
ユーザーからの報告では、PC と iPhone の Microsoft Edge で mywingstopsurvey.com にアクセスすると、常に .../Common/ComingSoon.htm に転送され、アンケート画面が表示できない一方、Chrome・Safari・Firefox では正しく表示されるというものでした。ブラウザー間で設定やお気に入りを同期しているため、「Edge 全体のキャッシュが共有されているのでは？」と疑いが生じがちですが、実際にはキャッシュや Cookie はデバイス間で同期されません。同期対象は主にお気に入り（ブックマーク）、パスワード、履歴、拡張機能、設定などであり、HTTP キャッシュやサイトごとの Cookie は各端末のローカルに保存されます。
今回のケースの結論
- 実際の原因：サイト側のアンケートシステムが改修中で、一定期間 “Coming Soon” ページへリダイレクトされる設定が有効になっていた。
- 現象が解消したタイミング：改修完了後は Edge を含む全ブラウザーで通常どおり表示されるようになった。
つまり、最終的には「待てば直る」タイプの問題でした。ただし、業務や調査で「今すぐ表示したい」「Edge だけ挙動が違う理由を切り分けたい」という場面は少なくありません。以下では、サイト側の復旧を待てない場合に効果のあるトラブルシューティングを、サイト単位でのキャッシュ／Cookie 削除や、開発者ツールを用いた検証を中心に詳述します。
なぜ「Edgeだけ」おかしく見えるのか：技術的背景
同一サイトでもブラウザーごとに表示が異なるのはめずらしくありません。理由は主に以下の通りです。
- リダイレクトのキャッシュ：301/302/307/308 などのリダイレクト応答は、ブラウザー側で一定条件下でキャッシュされます。特に 301（恒久的）や、サーバーがキャッシュ関連ヘッダーを返している場合、過去の転送先を Edge がしつこく保持してしまうことがあります。
- Cookie/セッションの違い：ログイン状態や AB テストの割り当て、地域分岐などを Cookie で制御しているサイトは、Cookie の値次第で表示や転送先が変わります。Edge にだけ古いセッションが残り、別ページへ誘導されるケースが典型です。
- Service Worker（PWA）：サイトがオフライン対応や高速化のために Service Worker を導入していると、キャッシュ戦略次第で古いアセットやプレースホルダーページを返すことがあります。
- 拡張機能の影響：広告ブロッカーやセキュリティ系拡張が特定のリクエストをブロックし、代替ページに飛ばされることがあります。InPrivate（シークレット）では拡張機能が既定で無効化されるため、切り分けに有効です。
- ネットワーク／DNS：企業プロキシ、DNS フィルタリング、マルチ CDN の地域ルーティング差異により、Edge からの名前解決や経路が他ブラウザーと異なる結果を返すことがあります（特に DOH 設定の差）。
よくある原因と対処の早見表
| 現象の源 | 典型症状 | Edgeでの確認・対処 |
|---|---|---|
| サーバー改修・停止 | 全ユーザーの一部で「Coming Soon」へ転送 | 時間をおいて再試行。Network タブで Location ヘッダーやステータス（3xx）を確認 |
| リダイレクトのキャッシュ | Edge だけ古い転送先に行く | サイト別の Cookie/キャッシュ削除、Ctrl+F5、InPrivate で再検証 |
| Cookie/セッション差 | 特定アカウントだけ再現 | 該当ドメインの Cookie を限定削除（パスワードは保持可） |
| Service Worker | 再読込しても変化なし | DevTools→Application→Service Workers→Unregister |
| 拡張機能 | 広告/追跡ブロックで一部 API が応答しない | InPrivate で再現性を確認、または拡張を一時無効化 |
| DNS/プロキシ | 社内ネットワークのみ発生 | 別回線（テザリング等）または DNS ホストキャッシュのクリア |
Windows版 Edge：サイトだけのキャッシュ／Cookieを安全に削除する手順
Edge には特定サイトだけのデータを消せる機能があり、保存済み ID・パスワードを温存しつつ問題を切り分けできます。全消去は他サイトのログイン状態も失いますが、サイト別削除なら影響を局所化できます。
方法A：設定からドメインを指定して削除
- Edge 右上の … メニュー → 設定 を開く。
- Cookie とサイトのアクセス許可 → Cookie とサイトデータの管理と削除 を選択。
- すべての Cookie とサイトデータ をクリック。
- 検索欄に
wingstopやmywingstopsurveyと入力して該当ドメインを絞り込み。 - 表示されたエントリ（例：
mywingstopsurvey.com、wingstop.com）を開き、削除 を実行。 - ページを Ctrl+F5（ハードリロード）で再読込、または新しい InPrivate ウィンドウでアクセスして挙動を確認。
方法B：アドレスバーの「サイト情報」から削除
- 問題のページを開いた状態で、アドレスバー左側の鍵アイコン（サイト情報）をクリック。
- Cookie とサイトデータ を開き、削除 または クリア を選択。
- タブをリロードして再確認。
方法C：開発者ツール（DevTools）から Service Worker/Storage をリセット
- F12 で開発者ツールを開く。
- Application パネル → Service Workers で該当サイトの Service Worker があれば Unregister。
- 同パネルの Clear storage で Cookies / Cache Storage / IndexedDB / Local Storage を選び、Clear site data をクリック（当該サイトのみ）。
- Network パネルの Disable cache にチェックを入れてリロードし、キャッシュ非使用のレスポンスを確認。
サイト別削除で「消えるもの／消えないもの」
| 項目 | 状態 | 補足 |
|---|---|---|
| 当該サイトの Cookie | 削除される | ログインセッションや AB テスト割当がリセット |
| 当該サイトのキャッシュ | 削除される | HTML/CSS/JS/画像などの再取得が発生 |
| 他サイトの Cookie/キャッシュ | 影響なし | サイト別削除のため他サイトのログインは維持 |
| 保存済みパスワード | 影響なし | Edge のパスワードマネージャーに保存された資格情報は消えない |
| お気に入り（ブックマーク） | 影響なし | 同期や整理状態は維持 |
モバイル版 Edge（iPhone/Android）の注意点
iOS/Android 版 Edge は、2025 年時点でサイト別の Cookie/キャッシュ削除に非対応です。アプリの「閲覧データのクリア」は全体に及ぶため、他サイトのログインも解除されます。モバイルで業務アカウントを多数保持している場合、安易な全消去は避けるのが無難です。
安全に試せる代替策
- InPrivate タブでの確認：モバイルでも InPrivate なら既存の Cookie に依存せず検証できます。
- 時間をおく：サイト側改修が完了すれば自然復旧するケースが多い（今回の事例が該当）。
- 別ブラウザーでの一時回避：Chrome/Safari で業務を継続し、Edge は復旧後に戻す。
どうしてもモバイル Edge で消したい場合のリスクと手順
- Edge モバイルの 設定 → プライバシーとセキュリティ → 閲覧データのクリア を開きます。
- Cookie とサイトデータ、キャッシュされた画像とファイル などを選択。
- 範囲を 全期間 または 過去 7 日間 に設定して削除。
注意：この操作はすべてのサイトに影響し、他サイトのログイン状態も失われます。業務影響を考慮し、可能ならサイト側の復旧を待つ方が安全です。
拡張機能・プロファイル・ネットワークでの切り分け
原因を早く絞り込むには、ブラウザー内部とネットワークの両面から段階的に確認します。
- 拡張機能を無効化：
Ctrl+Shift+Nで InPrivate を開き、同じ URL にアクセス。改善するなら拡張機能の影響が濃厚。通常ウィンドウ側で一つずつ無効化して犯人を特定。 - 別プロファイルで試す：Edge のユーザープロファイルを新規作成し、同期オフのまま検証。プロファイル固有の設定やデータが原因か切り分けられます。
- ネットワーク変更：社内 Wi‑Fi → テザリング（4G/5G）などに切り替え、プロキシやフィルタリング影響を排除。
- DNS キャッシュをクリア：アドレスバーで
edge://net-internals/#dnsを開き、Clear host cache を実行。OS 側でもコマンドプロンプトからipconfig /flushdnsを実行。
開発者ツール（DevTools）で「Coming Soon」転送の正体を掴む
「サイト側改修なのか、Edge の手元データなのか」を見極めるには、HTTP レイヤーの可視化が最短です。
Network タブでの基本チェック
- F12 → Network タブを開き、Disable cache にチェック。
- 該当 URL にアクセスし、最初のドキュメント要求（
mywingstopsurvey.com）を選択。 - Headers → Response Headers でステータスコード（
301/302/307/308）とLocationヘッダーを確認。.../Common/ComingSoon.htmが明示されていれば、サーバーまたは CDN レイヤーで転送設定中。 - Initiator/Timing を見て、リダイレクトがブラウザー側（Service Worker）で起きていないかも併せて確認。
Application タブでのキャッシュ層の洗い出し
- Service Workers：登録されていれば Unregister で無効化し、再検証。
- Storage（IndexedDB / Local Storage / Session Storage / Cache Storage）：不要なキーが残っていれば削除。
- Clear storage：対象サイトに限定して一括クリアが可能。
HAR/NetLog による再現性の記録
現象をチームで共有したい場合、Network パネルから HAR を保存し、相手の環境で解析してもらうと効率的です。また、より低レベルの記録には edge://net-export を用いて NetLog を取得できます（外部ビューアで閲覧）。
「同期」と「キャッシュ」は別物：誤解しやすいポイント
「Edge は同期しているから全端末のキャッシュが共通」という誤解は根強いですが、実際には下表の通りです。
| データ種別 | 同期対象 | 端末ローカル | 補足 |
|---|---|---|---|
| お気に入り（ブックマーク） | ○ | ○ | 端末間で同じアイテムが並ぶ |
| パスワード | ○ | ○ | 暗号化され同期。サイト別データ削除では消えない |
| 履歴/開いているタブ | ○ | ○ | 設定でオンにした場合 |
| 拡張機能・設定 | ○ | ○ | 一部項目はプロファイル依存 |
| Cookie | × | ○ | 端末ごとに独立。サイト別削除の対象 |
| HTTP キャッシュ | × | ○ | 端末ごとに保持。動作差の原因になりやすい |
ショートカット・現場で役立つ小技
- ハードリロード：
Ctrl+F5またはCtrl+Shift+R。 - InPrivate ウィンドウ：
Ctrl+Shift+N。拡張機能が既定で無効なため切り分けに最適。 - キャッシュ不使用での検証：DevTools → Network → Disable cache。
- DNS クリア：
edge://net-internals/#dns→ Clear host cache、Windows のipconfig /flushdns。
ケーススタディ：mywingstopsurvey.com（旧 wingstop.com/survey）
本件では、Edge（PC と iPhone）でアンケート URL にアクセスすると常に .../Common/ComingSoon.htm へリダイレクトされ、Chrome・Safari では正常表示という差が観測されました。最終的にはサイト側の改修中が原因で、作業完了後に Edge を含む全ブラウザーで正常化しています。
復旧を待てない場合でも、Windows 版 Edge のサイト別キャッシュ／Cookie 削除を実行すれば、ユーザー側に由来する要因（古いリダイレクトやセッション）を排除できます。保存済みの ID・パスワードには影響しないため、安心して試せます。モバイル版 Edge はサイト別削除に非対応のため、InPrivate での確認や時間をおく運用が推奨です。
トラブルシューティング実践フロー（最短ルート）
- InPrivate で再現確認（PC/モバイル）：拡張機能と既存 Cookie の影響を除去。
- Network タブで 3xx と Location を確認：サーバー側リダイレクトか、ブラウザー側のキャッシュかを即判定。
- Windows 版はサイト別削除：設定 → Cookie とサイトのアクセス許可 → Cookie とサイトデータの管理と削除 → すべての Cookie とサイトデータ から該当ドメインを削除。
- Service Worker を無効化：Application → Unregister、Clear storage。
- 別ネットワーク（テザリング等）で再試行：ネットワーク層の影響を除外。
- 時間をおく：サーバー改修・CDN 反映待ちの可能性を考慮。
補足：301/302 の“しつこい”リダイレクトを解除するコツ
- 301（恒久的転送）はブラウザーに強く記憶されがち。サイト別削除で当該ドメインのキャッシュと Cookie を確実にクリア。
- Service Worker が fetch をフックしている場合、サーバーが直ってもブラウザー側で古い応答を返すことがあります。Unregister → リロードで改善。
- HSTS が絡むケースでは、プロトコル強制（HTTP→HTTPS）が重なり挙動が複雑に見えます。基本はサイト別削除＋再取得で整合が取れることがほとんど。
運用上のおすすめ設定と再発防止
- 「終了時に閲覧データをクリア」は便利ですが、常用するとログイン維持ができず生産性を下げます。問題サイトのみの削除運用を基本に。
- 検証用プロファイルを一つ用意：拡張機能ゼロ・同期オフの“素の Edge”で再現性を素早く確認。
- ブックマークは新 URL に更新：旧
wingstop.com/surveyから新mywingstopsurvey.comへのエイリアスが絡むと、古い経路が再発するため。
FAQ
- Q. Edge の同期を切れば直りますか？
同期はキャッシュや Cookie を共有しません。サイト別削除の方が正攻法です。 - Q. パスワードは消えませんか？
サイト別削除では消えません。Edge の保存済みパスワードは別領域で管理されています。 - Q. モバイルでだけ直らないのはなぜ？
モバイル Edge はサイト別削除に未対応のため、既存 Cookie/キャッシュの影響が残りやすいからです。InPrivate での確認または時間経過を待つのが安全。 - Q. 会社の PC だけ「Coming Soon」になります。
プロキシや DNS フィルタリングの影響が疑われます。別回線で再現するか確認してください。
まとめ：今回の学び
- 現象の本質はサイト側の改修で、一時的に “Coming Soon” に転送されていただけ。復旧後は全ブラウザーで正常化。
- 待てない場合は、Windows 版 Edge のサイト別キャッシュ／Cookie 削除でユーザー側要因を排除し、DevTools で 3xx と
Locationを確認すると切り分けが速い。 - モバイル版 Edge はサイト別削除ができないため、InPrivate での検証か時間をおく対応が現実的。
- 「同期」と「キャッシュ」は別物。挙動差の多くは端末ローカルのデータに起因する。
付録：操作手順のクイックリファレンス
| 目的 | 操作 |
|---|---|
| サイト別 Cookie/キャッシュ削除（PC） | 設定 → Cookie とサイトのアクセス許可 → Cookie とサイトデータの管理と削除 → すべての Cookie とサイトデータ → ドメイン検索 → 削除 |
| ハードリロード | Ctrl+F5 または Ctrl+Shift+R |
| InPrivate | Ctrl+Shift+N |
| DevTools でキャッシュ無効 | F12 → Network → Disable cache にチェック → リロード |
| Service Worker の無効化 | F12 → Application → Service Workers → Unregister |
| DNS キャッシュのクリア | アドレスバーで edge://net-internals/#dns → Clear host cache、または ipconfig /flushdns |
| モバイルでの検証 | InPrivate タブでアクセス（サイト別削除は不可のため注意） |
最終結論
今回の「Edge で mywingstopsurvey.com が “Coming Soon” に転送される」問題は、サイト改修が直接原因でした。復旧後は Edge を含むすべてのブラウザーで正常に表示できます。とはいえ、同種のトラブルは今後も起こり得ます。Windows 版 Edge ならサイト別のキャッシュ／Cookie 削除で安全に切り分けでき、DevTools の Network と Application を併用すれば、「サーバー側の転送」 と 「手元のキャッシュ」 を明確に区別できます。モバイル Edge の場合は全体削除の副作用が大きいため、InPrivate での検証と時間経過を基本戦術に据えるのが得策です。
コメント