Outlook 365（Outlook on the web）にサインインしようとすると「Authentication Required」→「Continue」を押しても同じ画面に戻る無限ループ…。本記事はその症状を素早く回避し、恒久的に防ぐための実践手順と、企業テナントで起きがちな根本原因の見つけ方を、利用者向けと管理者向けに分けて詳しくまとめました。
対象読者と先に結論
対象は、www.office.com にアクセスすると認証ループに陥って Outlook Web に進めない人、または組織内で同様の問い合わせが増えている管理者です。結論だけ先に述べると、次の二つで大半は解決・回避できます。
- 回避ログイン：
account.microsoft.comでサインイン → 左上のワッフルメニュー → Outlook を選ぶ。 - 恒久パス：今後は
outlook.office.comをブックマークしてそこから入る（www.office.com を経由しない）。
それでも解消しない場合は、Cookie/キャッシュのクリア・3rd-party Cookie の許可・拡張機能/プロファイルの影響排除・ネットワーク/セキュリティ製品の除外設定・条件付きアクセス等のテナント設定確認を順に見ていきます。最後にエラーコードの早見表と、管理者がサインインログから原因を特定する勘所も用意しました。
症状の具体像
代表的な訴えは以下の通りです。
www.office.comにアクセスすると「Authentication Required」が表示される。- Continue を押しても同じ画面に戻り、ポップアップ → 認証画面の無限ループになって先に進めない。
- ブラウザーは Chrome でも Edge でも再現する（場合によっては片方のみのこともある）。
この現象は、www.office.com（ポータル/ハブ）の認証フローが複数ドメインをまたぐのに対し、ブラウザーや拡張・ポリシー・ネットワーク機器が Cookie やリダイレクトをうまく受け渡せないと発生しがちです。一方、Outlook Web 本体である outlook.office.com は比較的シンプルな遷移で済むため、直接アクセスが有効な回避策となります。
今すぐできる回避と恒久パス
① Microsoft アカウント経由で回避ログイン（応急）
https://account.microsoft.com/に直接アクセスして、通常どおりサインインします。- 左上のワッフルメニュー（9点アイコン）を開き、Outlook を選びます。
- そのまま Outlook Web に遷移できれば、www.office.com の認証ループを迂回して利用できます。
補足：個人の Microsoft アカウント（MSA）でサインインしている場合は、ワッフルからの Outlook が outlook.live.com（個人向け）に遷移することがあります。職場/学校アカウントでの利用が前提なら、続く「② 直接 URL」を推奨します。
② 直接 Outlook の URL を使う（恒久的・短縮パス）
https://outlook.office.com/をブックマークし、今後はここからアクセスします。- www.office.com 側の認証エラーを回避でき、URL も短くアクセスが速いのが利点です。
なぜこれで回避できるのか（仕組みの要点）
ポータルの www.office.com は、利用者の契約・使用状況に応じて様々なサービスへルーティングし、複数のドメイン間で認証状態を橋渡しします。ここで 3rd-party Cookie がブロックされていたり、トラッキング防止/広告ブロッカーがサインイン関連スクリプトを誤検知したり、SSL インスペクションなどでトークンが失効したりすると、フローの途中でセッションが確立できずにループします。対して outlook.office.com に直行すれば、余計な分岐が少ないため失敗ポイントが減ります。
追加の根本対策（ブラウザー側）
| 対策 | 内容 | 効果 |
|---|---|---|
| ブラウザーの Cookie・キャッシュ削除 | 古いセッショントークンや壊れた Cookie を一掃。対象ドメインを限定して行うと安全。 | 高 |
| シークレット／InPrivate ウィンドウ | 拡張や保存データ、プロファイル汚れの影響を排除して再現性を確認。 | 中 |
| 3rd‑party Cookie を許可 | 認証のクロスドメイン Cookie がブロックされるとフローが途切れるため、例外許可を設定。 | 中 |
| 別ネットワークで試す | 社内プロキシ/セキュリティ製品の干渉を切り分け。モバイル回線や自宅回線でテスト。 | 低 |
Cookie/キャッシュの安全なクリア方法（Chrome/Edge 共通の考え方）
- まずは 対象ドメインだけを消すのが安全です。以下を目安に個別削除します：
office.com/www.office.comoutlook.office.comlogin.microsoftonline.com/login.windows.netmicrosoft.com/live.com/msauth.net関連
- ブラウザーの「サイトの設定」→「保存されたデータ」から各ドメインのデータを削除します。
- それでも改善しない時のみ、期間を「全期間」にして Cookie/キャッシュの全体削除を検討します（他サイトの再ログインが必要になる点に注意）。
3rd‑party Cookie を許可（例外登録のすすめ）
ポリシーや拡張機能で「サードパーティ Cookie をブロック」にしている環境では、以下のような例外登録が効果的です。アンカーリンクは作りませんが、文字列をそのままブラウザーの例外欄に追加できます。
[*.]microsoft.com
[*.]office.com
[*.]office365.com
[*.]live.com
[*.]msauth.net
[*.]msftauth.net
[*.]microsoftonline.com
Chrome の「プライバシーとセキュリティ」→「サードパーティ Cookie」→「サイトの例外」や、Edge の「Cookie とサイトのアクセス許可」→「サードパーティ Cookie」→「許可」などから設定できます。組織配布の拡張（広告ブロッカーやセキュリティ系）がある場合は、一時的に無効化して挙動を確認しましょう。
プロファイル・拡張・時刻の見直し
- 新規プロファイルでサインインを試すと、既存プロファイルの汚れ（壊れたデータや設定）を切り分けできます。
- 拡張機能は一旦すべて無効化し、問題が出なくなったら一つずつ有効化して犯人を特定します。
- PC の時刻ズレはトークンの有効/発効時刻チェックに影響します。自動同期にして NTP で時間合わせしましょう。
ネットワーク/セキュリティ製品の影響を切り分ける
企業ネットワークでは、プロキシ・SSL インスペクション・DNS フィルタがサインイン関連ドメインに介入してループすることがあります。スマホのテザリングなど別回線で再現しないなら、次を参考に除外を検討します。
| カテゴリー | 代表ドメイン | 推奨アクション |
|---|---|---|
| 認証（Azure AD/Entra ID） | login.microsoftonline.com, login.windows.net | SSL インスペクション除外・キャッシュしない・圧縮/改変しない |
| Outlook Web | outlook.office.com | 同上。HTTP/2/3 のダウングレードや改変を避ける |
| 静的コンテンツ/認証リソース | aadcdn.msauth.net, aadcdn.msftauth.net, auth.gfx.ms | ブロック/置換しない。コンテンツフィルタの誤検知に注意 |
| ポータル/ハブ | www.office.com / www.microsoft365.com | リダイレクトや Cookie を改変しない。短期でのキャッシュ無効化を検討 |
管理者向け：テナント（Microsoft Entra ID / 旧 Azure AD）の確認ポイント
ブラウザーやネットワークを整えても直らない場合、テナントのポリシーや認証構成がトリガーになっている可能性があります。特に以下を確認してください。
条件付きアクセス（CA）との相性
- 対象アプリが「すべてのクラウドアプリ」になっていると、www.office.com（Office Home / Shell）にも厳しい制御がかかり、遷移途中で再評価→ループに陥ることがあります。意図せず二重に評価されないか確認します。
- サインイン頻度ポリシーや永続ブラウザーセッションの設定が厳しすぎると、ポータル遷移のたびに再認証が走ることがあります。要件に応じて緩和を検討します。
- 承認済みクライアントアプリ必須など、ブラウザー向けに適用しても効果がない（むしろ失敗を誘発する）設定が混在していないか見直します。
多要素認証（MFA）/サインイン方法
- MFA の要求タイミングが重複すると、Office ポータル側のリダイレクトと噛み合わずループすることがあります。一貫したプロンプト戦略に調整します。
- Auth アプリの通知が届いてもブラウザー側で Cookie が受け取れなければ完了しないため、ユーザー側対策（3rd-party Cookie 等）も併せて周知します。
外部 ID/フェデレーション
- AD FS 等のフェデレーション環境では、IdP 側の Cookie 属性（
SameSiteなど）や リダイレクト URI の整合性問題でループが発生することがあります。ブラウザーの開発者ツールで 3xx 応答が繰り返されていないか確認を。
サインインログで原因に当たりをつける
「Microsoft Entra 管理センター」→「サインイン」から当該ユーザーのログを確認し、該当時刻のイベントを並べて見ます。
- アプリ名：Office Home（ポータル）や Exchange Online（Outlook Web）での失敗が交互に続いていないか。
- 結果の詳細/エラーコード：下記の早見表に該当するか。
- 条件付きアクセスの結果：ポリシーが重複評価され Block/Require になっていないか。
エラーコード早見表（まずはここを見る）
| コード | 意味（要約） | 最初の一手 |
|---|---|---|
AADSTS50058 | セッション/Cookie が見つからない。サインイン状態を認識できない。 | 3rd-party Cookie 許可、Cookie/キャッシュ削除、outlook.office.com へ直行。 |
AADSTS53003 / 53004 | 条件付きアクセスによりブロック、もしくはデバイス非準拠。 | CA ポリシーの対象/条件/例外を再確認。デバイス準拠の満たし方を確認。 |
AADSTS50158 | 外部 IdP へのアクセスが必要/未完了。 | フェデレーション先の応答と Cookie 属性を確認。SSL インスペクション除外。 |
AADSTS700016 | アプリケーションが見つからない（誤ったアプリ ID 等）。 | カスタムアプリの構成を確認。標準の OWA で出る場合はネットワーク改変を疑う。 |
AADSTS50011 | リダイレクト URI 不一致。 | 主にカスタム/SaaS 連携で発生。OWA で出る時は中間機器の URL 書き換えを疑う。 |
ユーザー向け：再発しないための運用Tips
- ブックマークは
outlook.office.comを第一候補に。ポータルを経由したい場合だけwww.office.comを使う。 - ブラウザー更新や拡張の追加後に挙動が怪しくなったら、まず InPrivate/シークレットで試す。
- 広告ブロッカーを使う場合は、Microsoft ドメインを除外しておく。
- 共用端末では、利用後にサイトデータの消去か InPrivate 利用を徹底。
管理者向け：トラブル時の「速攻」切り分けフロー
- ユーザーに
outlook.office.com直行を案内 → 使えるか確認。 - InPrivate/新規プロファイルで再現するか → 再現するなら ネットワーク/ポリシーの可能性が高い。
- 別ネットワーク（テザリング等）で再現するか → 再現しないなら 社内機器の除外設定を検討。
- サインインログでエラーコード/ポリシー適用状況を確認 → CA の対象整理と サインイン頻度/永続設定の整合性を調整。
技術的背景：なぜ「ポータルだけ」詰まりやすいのか
www.office.com（または www.microsoft365.com）は、ユーザーのプラン・最近使ったアプリ・組織設定に応じてダッシュボードやアプリランチャーを提供します。この過程で複数のファーストパーティ/サードパーティ Cookie を安全属性（Secure / HttpOnly / SameSite）付きで設定し、login.microsoftonline.com などとリダイレクトをやり取りします。SameSite=Lax/None と 3rd-party 認識の組み合わせ、トラッキング防止の厳格化、SSL インスペクションによる TLS 再終端が混ざると、ブラウザーが Cookie を添付しない/破棄する→サーバーは「未サインイン」と判断→再認証要求がループという構図になります。Outlook Web に直行すると、フローに登場するドメインが減り、Cookie の往復が単純化するため成功しやすくなります。
よくある質問（FAQ）
Q. Outlook デスクトップは使えるのに Web 版だけダメ。なぜ？
A. デスクトップ版（MAPI/EWS/Graph）はブラウザーの Cookie に依存しません。Web 版はブラウザーの Cookie・拡張・ネットワーク改変の影響を強く受けます。
Q. Edge でも Chrome でも現象が出る。
A. それでも InPrivate/シークレットや新規プロファイルで直ることがあります。両方で出る場合はネットワークやテナントの可能性も視野に。
Q. ゲストとして別テナントの Outlook を開くときだけループする。
A. テナント切替（プロフィールスイッチ）時の Cookie/リダイレクトが厳格な CA とぶつかっている可能性があります。招待元テナントと自テナントで CA を見直し、Office Home を過剰に縛らない構成を検討しましょう。
ユーザー向けの最終チェックリスト
- ① 応急：
account.microsoft.com→ ワッフル → Outlook を試す。 - ② 恒久：
outlook.office.comをブックマークしてそこから入る。 - ③ 追加：Cookie/キャッシュ削除、3rd‑party Cookie 許可、拡張停止、InPrivate で再試行。
- ④ 切り分け：別ネットワークで試す（テザリング等）。
- ⑤ 相談：解消しないときは管理者に 「認証ループ（AADSTS50058）」等のエラー情報を添えて連絡。
管理者向けの最終チェックリスト
| 観点 | 見る場所 | 典型シグナル | 初期対応 |
|---|---|---|---|
| サインインログ | Entra 管理センター → サインイン | AADSTS50058 が連発、Office Home/Exchange Online の繰り返し | CA の対象/条件の重複解消、サインイン頻度/永続の緩和 |
| CA ポリシー | セキュリティ → 条件付きアクセス | 「すべてのクラウドアプリ」に厳格制御、排他条件なし | Office Home と OWA で評価が二重化しないよう再設計 |
| ネットワーク | プロキシ/SSL インスペクション | Microsoft 認証ドメインに対する改変/検査/キャッシュ | 除外適用（login.microsoftonline.com 等）と再テスト |
| エンドポイント | ブラウザーポリシー/拡張 | 3rd-party Cookie 一律ブロック、広告ブロッカーの誤検知 | 例外登録と拡張のホワイトリスト化 |
どうしても解消しない場合の連絡テンプレート
管理者/サポートへの問い合わせ時は、次の情報があると調査が速くなります。コピーしてご利用ください。
件名：Outlook Web 認証ループ（AADSTS50058）発生の件
内容：
・発生日時：
・影響端末/OS/ブラウザー（バージョン）：
・再現手順：例）www.office.com → 「Continue」→ 同画面に戻る（ループ）
・回避策の試行結果：account.microsoft.com 経由は○/×、outlook.office.com 直行は○/×
・InPrivate/新規プロファイル/別ネットワークでの再現性：
・拡張機能の有無：
・画面スクリーンショット/エラーコード：AADSTS50058 など
・組織内の同様事例の有無：
まとめ
- 最短の回避策：
account.microsoft.com→ ワッフル → Outlook。 - 恒久的な入り口：
outlook.office.comをブックマークしてダイレクトにアクセス。 - それでもダメなときは、Cookie/キャッシュ/3rd-party Cookie/拡張/ネットワークを順に点検。
- 企業テナントでは、条件付きアクセス・サインイン頻度・MFAがループの引き金になることも。サインインログで根拠を持って調整しましょう。
参考：実施手順のクイック表（印刷・配布用）
| 手順 | 操作 | 期待結果 | うまくいかない時 |
|---|---|---|---|
| 1 | account.microsoft.com にサインイン → ワッフル → Outlook | Outlook Web が開く（ループ回避） | 個人 Outlook に行く場合は次へ（手順2） |
| 2 | outlook.office.com をブックマークし直接アクセス | ポータルを経由せず OWA に入れる | サインイン画面が繰り返されるならブラウザー対策へ |
| 3 | 対象ドメインの Cookie/サイトデータを削除 | 壊れたトークンを除去できる | InPrivate/新規プロファイルで再テスト |
| 4 | 3rd‑party Cookie 例外を登録 | クロスドメイン認証が通る | 広告ブロッカーやセキュリティ拡張を停止 |
| 5 | 別ネットワークで試す（テザリング等） | ネットワーク干渉の有無を切り分け | 社内機器の除外設定を検討 |
| 6 | 管理者にエラーコード/時刻を添えて連絡 | サインインログから根本原因に到達 | CA/ポリシー見直しで再発防止 |
補足：よく使うドメイン一覧（除外/例外登録用）
# 認証・サインイン
login.microsoftonline.com
login.windows.net
aadcdn.msauth.net
aadcdn.msftauth.net
auth.gfx.ms
# アプリ本体
outlook.office.com
[www.office.com](http://www.office.com)
[www.microsoft365.com](http://www.microsoft365.com)
# 補助・個人系
live.com
microsoft.com 最後に
Outlook Web の認証ループは、一見するとブラウザーの不調ですが、背後では複数の要素（Cookie 方針、拡張、ネットワーク機器、テナントのポリシー）が絡み合っています。まずは「Outlook に直行」という最短ルートを確保しつつ、段階的に原因を切り分ければ、再発の芽を着実に摘み取れます。チーム内のヘルプ記事としても本稿を流用し、利用者と管理者の双方で同じ手順と用語を共有しておくと、次回以降の対応速度が大きく向上します。
コメント