Surface Pro 7でMicrosoft Edgeのみを使っている環境で、AT&Tのアカウントやサポートに突然サインインできず「Access Denied／Reference #18」が出る――この現象はブラウザー設定や共有回線の一時ブロックが重なって起きがちです。原因の仕組みと、再現性の高い直し方を順序立てて解説します。
症状の全体像と前提環境
以下の条件がそろうと、AT&Tのログインやサポートページでエラーになるケースが散見されます。
- 端末：Surface Pro 7（Windows）
- ブラウザー：Microsoft Edgeのみを利用
- ネットワーク：シニア向け集合住宅などの共用インターネット回線
- エラー表示：
Access Denied
You don’t have permission to access …
Reference #18.xxxxxxxx
他の多くのサイトは閲覧可能で、VPN・プロキシは使っていない、という状況でも発生します。エラーに示されるReference #18.……のような番号は、サイト側のセキュリティ装置（WAF／ボット対策）の判定と関連付けられたトラッキングIDで、遮断の種類や検知ルールに紐づきます。
先に結論：最短で切り分けるなら
時間をかけずに原因を絞り込むなら、次の順で試すのが最短ルートです。
- InPrivateウィンドウでAT&Tにアクセス（Edge右上のメニュー→新しいInPrivateウィンドウ）。
→ これで入れるなら、Cookie／キャッシュ／拡張機能の影響です。 - スマホのテザリングで同じSurface Pro 7を接続してアクセス。
→ これで入れるなら、共用回線の外向きIP（施設の出口）がブロックされています。 - ダメならEdgeのキャッシュ・Cookie全削除とDNS/IPリフレッシュを実行。
→ それでも不可なら、施設側に解除依頼＋AT&TにReference番号を伝えて照会が堅実です。
なぜ起きるのか：仕組みを理解する
「Access Denied」は多くの場合、以下の要因が単独または複合で発生します。
- 共有回線の外向きIPが一時ブロック：同じ施設の誰かのアクセスや機器の自動通信が、サイトの防御ルールに触れてIP単位で遮断されることがあります。あなた自身が何もしていなくても影響を受けます。
- ブラウザー側の識別情報が怪しまれる：Cookie、ローカルストレージ、サービスワーカー、指紋情報、異常なリクエストヘッダー（拡張機能が書き換え）などが誤検知されることがあります。
- DNSや時刻の不整合：DoH（Secure DNS）の設定、キャッシュが壊れた、PCの時刻ズレなどで正規の経路や証明書検証に齟齬が出ると、リスク判定が上がります。
- サイト側の誤判定：WAFやボット対策の閾値やルール更新で、特定の条件が一時的に厳しくなることがあります。
回答・解決策（基本編：必ず効果検証）
次の表を上から順に実施します。どの手順で改善したかを記録すると、再発時の対処が速くなります。
| 手順 | 対応内容 | 目的・補足 |
|---|---|---|
| 1 | Edge のキャッシュと Cookie を全削除 アドレスバーに edge://settings/clearBrowserData と入力→Cookie とその他のサイトデータ、キャッシュされた画像とファイルを選択→すべての期間で削除 | 誤判定の一因になる追跡データを初期化。 ※保存済みログインが消えるため後で再入力が必要。 |
| 2 | InPrivateウィンドウで再アクセス | 拡張機能や保存データの影響を除外して挙動を確認。 |
| 3 | Edgeの拡張機能を一時的に全停止 アドレスバーに edge://extensions/ →すべてオフ | 広告ブロッカー、UA切替、セキュリティ系がヘッダーを書き換えて遮断の引き金になることがあります。 |
| 4 | DNS と IP のリフレッシュ Windows 検索で「PowerShell」を右クリック→「管理者として実行」→以下を順に実行 | 名前解決キャッシュや一時ブロックされた経路を更新。 |
ipconfig /flushdns
ipconfig /release
ipconfig /renew
実行後、PCと可能であればルーターも再起動します。
| 5 | VPN／プロキシ／セキュリティソフトの再確認 Windows 設定→ネットワークとインターネット→プロキシで自動検出や手動プロキシが有効になっていないか確認。セキュリティソフトの「Web保護」等の一時停止も検証。 | 無自覚な経由サーバーやトラフィック改変があると、サイト側で遮断される場合があります。 |
| 6 | スマホのテザリングで接続テスト | これで正常にログインできれば、施設の共有ネットワーク（外向きIP）由来のブロックの可能性が高い。 |
| 7 | 施設の IT 管理者へ相談 「AT&Tの att.com ドメインでアクセス拒否が出る」「共用IPがブロックされていないか」などを伝える。Reference番号・発生日時・端末名を添える。 | 共有回線では他居住者の挙動で同じ外向きIPがブラックリスト入りすることがあります。 |
| 8 | 代替策（暫定） ・Chrome等の別ブラウザーで試す ・スマホアプリ「myAT&T」で用件を進める ・AT&Tテクニカルサポートに電話し、自分のIPがブロックかをReference番号と共に確認 | 根本解決までの回避策。ブラウザーや回線を変えると判定がリセットされる場合があります。 |
ブラックリストとは？（補足）
大手サイトは不正アクセス対策として、疑わしい挙動が検出されたIPアドレスやCookie等の識別子を一時的にブロックする仕組み（ブラックリスト／グレーリスト）を持ちます。共用ネットワークでは同一外向きIPを多数で共有するため、自分に非がなくても巻き添えで遮断されやすくなります。
コマンド集：通信まわりの初期化（安全な範囲）
以下は一般的に安全で、通信系の不整合を解消するのに役立ちます。管理者権限のPowerShellで実行してください。
# DNSキャッシュのクリア
ipconfig /flushdns
# IPリースの更新（有線/無線の現在のアダプターで）
ipconfig /release
ipconfig /renew
# Winsockのリセット（通信スタックの初期化。再起動が必要）
netsh winsock reset 実行後はPCを再起動します。ネットワーク機器（家庭用ルーター等）がある場合は、可能ならそちらも電源再投入でキャッシュをクリアしてください。
切り分けの思考法：結果で原因を推定する
- InPrivateでOK／通常ウィンドウでNG → Cookie／拡張機能／サービスワーカー起因。データ削除と拡張機能停止で改善。
- テザリングでOK／施設回線でNG → 施設の外向きIPがブロック。IT管理者へ解除・経路確認を依頼。
- ブラウザーを変えるとOK → Edge固有の設定（DoH、追跡防止、拡張機能）影響の可能性。Edge設定の見直しへ。
- どの手段でもNG → サイト側で広範な遮断または端末レベルの異常。Windowsの時刻ズレやセキュリティソフト、ネットワークドライバー更新を確認。
Microsoft Edgeの詳細チェック（効果が高い順）
Cookieとサイトデータをピンポイントで削除
edge://settings/siteDataを開き、検索欄にatt.comと入れてヒットした項目を個別削除。- ログイン状態だけをリセットできるため、他サイトの影響を最小化できます。
追跡防止レベルとサードパーティCookie
edge://settings/privacy→ 追跡防止レベルが厳重だと、ログイン周りのサブドメイン連携が阻害されることがあります。まずはバランスで検証。- サードパーティCookieのブロックをオンにしている場合、サイトごとの例外で
att.comを許可して動作確認します。
Secure DNS（DNS over HTTPS; DoH）の一時無効化
edge://settings/privacy→ セキュア DNS を使用するがオンならオフにして再検証。- 特定のDNSリゾルバーとサイト側の地域判定が噛み合わず、誤検知を招くことがあります。
拡張機能のホワイトリスト方式
- 広告ブロッカーやスクリプト制御系はログインページと相性が悪いことがあります。
edge://extensions/で一括無効→問題が解消したら、AT&T関連ドメインを除外に加えるか、必要最小の拡張だけ戻すのが安全です。
サイト権限とポップアップ、JavaScript
- ポップアップ、JavaScript、リダイレクトのブロック設定で、ログインフローが止まることがあります。
edge://settings/contentでatt.comを許可側に。
サービスワーカーとキャッシュの深い掃除（上級）
- Edgeの開発者ツール（F12）→Applicationタブ→Service Workers→登録解除、Clear storageの全選択でクリア。
- サイトのPWA的コンポーネントが壊れた場合に有効です。
Windows側で見直すポイント
- 日時とタイムゾーン：設定→時刻と言語で「時刻を自動的に設定」「タイムゾーンを自動的に設定」を有効化。証明書検証に関わるため、ズレは禁物です。
- ネットワークアダプターのリセット：設定→ネットワークとインターネット→ネットワークの詳細設定→ネットワークの復元。注：再起動と再設定が必要。
- IPv6の一時無効化テスト：アダプターのプロパティで「Internet Protocol Version 6 (TCP/IPv6)」のチェックを外し、挙動に変化が出るか確認。戻し忘れに注意。
- DNSサーバーの手動指定：一時的にパブリックDNS（例：1.1.1.1 / 8.8.8.8）へ変更して動作確認。改善するなら、施設内DNSの解決経路に問題がある可能性。
施設（共有回線）側に依頼する内容テンプレート
テザリングでは接続でき、共用回線ではできない場合、施設の外向きIPがサイト側でブロックされています。以下を伝えると話が早いです。
- 現象：AT&Tのログイン／サポートページで「Access Denied（Reference #18）」
- 日時：発生日時（タイムゾーン含む）
- 対象：ドメイン
att.comおよび関連サブドメイン - 外向きIP：施設インターネットのグローバルIP（IT側で把握）
- 希望：当該ドメインへの通信フィルター・WAF・CGNATポリシー・Geo/ASNフィルタを確認し、必要ならIPの変更・解除を実施
IT管理者側の措置としては、出口IPの変更、誤検知を招くプロキシ設定の見直し、フィルタリング機能の例外登録などが候補です。
AT&T側に伝えるべき情報（電話サポート時）
- Reference番号（画面の
Reference #18.xxxxxxxx） - 発生日時とタイムゾーン
- 自分の外向きIP（施設のもの／テザリングのもの）
- ブラウザー：Microsoft Edge（バージョン）／Surface Pro 7
- 実施済み対処（Cookie削除、InPrivate、拡張無効、DNSリフレッシュ）
この情報が揃っていれば、IPブロックやルール誤検知の調査がスムーズです。
一時回避と実務の継続
- 別ブラウザー（Chrome等）でログインできるなら、解決までの業務用に使い分け。
- myAT&Tアプリをスマホで利用して、支払い・契約確認などを先に処理。
- 電話サポートで手続き可能なものは代替手段を依頼。
再発防止のベストプラクティス
- 重要サイトはInPrivateを既定運用：ログイン専用のInPrivateで、不要な拡張機能や追跡データの干渉を避ける。
- 拡張機能は最小限＋ホワイトリスト：広告ブロッカー等は
att.comを除外。 - 定期的なブラウザーの衛生管理：四半期に一度、クッキー／キャッシュのクリーニングと拡張機能棚卸し。
- 施設のIT方針を共有：外向きIPが頻繁に変わる／共有人数が多い環境では、ログインが厳格な金融・通信系サイトで同様の事象が出やすいことを周知。
実例シナリオ：こうして直った
ケースA：拡張機能が原因
広告ブロッカーとプライバシー保護の拡張を同時使用。AT&TのログインリダイレクトでサードパーティCookieが必要だったが、厳格ブロックで遮断。InPrivateで正常→拡張を一時停止→サイト例外に追加で解決。
ケースB：共用回線のブロック
施設の回線ではAccess Denied、テザリングでは成功。IT管理者に外向きIPの解除を依頼し、24時間後に自動解除（WAFの一時ブロック）されたことで復旧。
ケースC：DNSまわりの不整合
EdgeのSecure DNSが特定リゾルバーに向き、地域判定の齟齬でログインフローが停止。Secure DNSを一時オフ→ipconfig /flushdns→再起動で復旧。
チェックリスト（保存版）
- Edge：Cookie・キャッシュ全削除（期間＝すべて）
- Edge：InPrivateで再現するか
- Edge：拡張機能を全停止→原因の拡張を特定
- Edge：追跡防止＝バランス／サードパーティCookie許可（サイト例外）
- Edge：Secure DNSを一時オフ→検証
- Windows：日時・タイムゾーンを自動設定
- Windows：ipconfig /flushdns → /release → /renew
- Windows：netsh winsock reset（必要時）
- ネットワーク：テザリングで検証
- 施設：外向きIPのブロック有無を確認（Reference番号と日時を連絡）
- 暫定：別ブラウザー／myAT&Tアプリ／電話サポート
トラブルが長引くときの追加手段（注意して実施）
- Edge設定のリセット：
edge://settings/reset→「設定のリセット」。拡張や検索エンジン等が初期化されます。 - プロファイル新規作成：
edge://settings/profiles→ 新しいプロフィールで再テスト。プロファイル破損の切り分けに有効。 - ネットワークドライバー更新：デバイスマネージャーからWi‑Fi／有線アダプターのドライバーを最新に。
- セキュリティソフトの「HTTPSスキャン」設定：一時オフで検証し、原因なら例外設定に移行。
安全上の注意
- Cookieやキャッシュ削除でサイトの自動ログインが解除されます。必要なID・パスワードを控えてから実施してください。
- ネットワークの復元やWinsockリセットは、VPNクライアント等の設定に影響する場合があります。業務端末では管理ポリシーを確認してください。
- IPv6の無効化は恒久措置にせず、あくまで切り分けに留めてください。
まとめ
Surface Pro 7でMicrosoft Edgeのみを使用している環境でAT&Tの「Access Denied（Reference #18）」が発生する場合、ブラウザー側のデータ初期化・InPrivate確認・拡張機能停止・DNS/IPリフレッシュを順に実施し、テザリングで回線切り替え検証を行うのが最短です。テザリングで通るなら、施設の外向きIPがブラックリスト化している可能性が極めて高いため、IT管理者への解除依頼が決め手になります。上記手順を段階的に進めれば、多くのケースで短時間に復旧できます。再発防止には、重要サイトのInPrivate運用、拡張機能の最小化、定期的なクリーンアップが有効です。
実践チェックシート（印刷・保存用）
| 確認項目 | 実施 | 備考 |
|---|---|---|
| InPrivateでAT&Tにアクセスしてみた | □ | 正常ならCookie/拡張の問題 |
| EdgeのCookie/キャッシュを全削除 | □ | 期間＝すべて |
| 拡張機能を全停止して検証 | □ | 原因拡張を特定 |
| ipconfig /flushdns → /release → /renew | □ | 再起動も実施 |
| Secure DNSを一時オフ | □ | edge://settings/privacy |
| テザリングで同じ端末からアクセス | □ | これでOKなら施設IPが要調査 |
| IT管理者にReference#・時刻付きで連絡 | □ | 外向きIPのブロック解除依頼 |
| AT&TサポートへReference#を伝達 | □ | IPブロックや誤検知の確認 |
FAQ
- Q：他のサイトは問題ないのにAT&Tだけ拒否されます。PCの故障ですか？
A：PC故障ではなく、サイト固有の防御ルールが発動している可能性が高いです。まずはInPrivateとテザリングで切り分けを。 - Q：Reference番号は何に使う？
A：サイト側のログ検索キーです。サポートはこれを手掛かりに、なぜ拒否されたか（IP・ヘッダー・Cookie等）を追跡できます。 - Q：Edgeを再インストールすべき？
A：ほとんどのケースでは不要です。Cookie削除→拡張停止→Secure DNS見直し→DNS/IPリフレッシュで改善します。 - Q：ウイルス対策を切るのは危険では？
A：恒久的に切るのは禁物です。一時停止で検証し、原因ならAT&Tドメインを例外登録してください。 - Q：IPv6をオフのままでいい？
A：いいえ。切り分けが終わったら元に戻してください。今後IPv6依存のサービスも増えます。
参考：本記事の推奨手順の要点（要約）
- ブラウザー起因か回線起因かをInPrivate＋テザリングで二軸切り分け。
- ブラウザー起因ならCookie/キャッシュ削除・拡張停止・Secure DNS見直しで解消。
- 回線起因なら施設のITに外向きIPのブロック解除を依頼。Reference番号が決め手。
- 待機できない用事は別ブラウザー／アプリ／電話で先に処理。
コメント