【M365】TeamsやOneNoteで「アカウント接続エラー」が頻発！同一ネットワークで特定端末のみ発生する原因と解決策

Microsoft 365（TeamsやOneNoteなど）にブラウザでアクセスした際、「アカウントへの接続で問題が発生しています。続行するには、もう一度サインインしてください。」 というエラーが表示され、サインインがループすることはありませんか？

さらに、Chromeのシークレットモードでアクセスを試みても、ERR_CONNECTION_RESET（接続がリセットされました） と表示されてページすら開けないケースがあります。

厄介なのは、「同じオフィスのネットワーク（または自宅の回線）に接続しているのに、正常に動くPCと、エラーになるPCがある」 という端末固有の挙動を示す点です。

今回は、この現象の根本原因をインフラ・ネットワークの視点から突き止め、実際に解決に至った切り分け手順と具体的な対策を解説します。

1. 発生する現象と初期の切り分け

今回対象とするトラブルの主な挙動は以下の通りです。

ブラウザでTeams、OneNote、M365ポータル等を開くと、サインインを何度も求められる、あるいは接続エラーになる。
Chromeのシークレットモードでアクセスすると、キャッシュやクッキーの影響を排除しているにもかかわらず、ERR_CONNECTION_RESET が発生する。
同一ネットワーク内の他のPCでは、全く問題なくアクセスできる。
M365以外は全く問題なくアクセスできる。

シークレットモードでも ERR_CONNECTION_RESET（TCP RSTパケットによる通信の強制切断）が発生する場合、ブラウザのデータ破損ではなく、「パケット・ネットワークレイヤー」、あるいはOSやセキュリティソフトなどの「カーネルレベルの通信干渉」に原因が絞られます。

大容量の認証トークンやCookieをHTTPヘッダーに乗せて送信（上り通信）するM365では、パケットサイズが回線の限界（MTU）を超えてしまい、通信が消失する「PMTUD（Path MTU Discovery）ブラックホール現象」がよく疑われます。

まずは端末の設定と、実際の回線が許容するパケットサイズ（MTU）のミスマッチを調査しました。

通常、パケットサイズの上限を調べる際は ping login.microsoftonline.com -f -l 1432 などのコマンドを用いますが、Microsoftのサーバーはセキュリティ対策（DoS攻撃防止など）のためにPing（ICMP通信）を遮断しています。

そのため、サイズに関わらず「要求がタイムアウトしました（Request timed out）」となり、正確な測定ができません。

測定の際は、確実にPingの返答（ICMP Echo Reply）を返してくれる外部のパブリックDNS（例: Googleの 8.8.8.8）を宛先にしてテストを行います。

コマンドプロンプトやPowerShellで、パケットの断片化を禁止するオプション（-f）をつけ、データサイズ（-l）を変化させて実行します。

DOS

ping 8.8.8.8 -f -l 1432

【検証結果の例】

この結果から、このネットワーク環境の実効MTUは一般的な1500（IPoEなど）ではなく、PPPoEやVPNなどの影響で1400付近まで制限されていることが分かります。

しかし、端末側の物理ネットワークアダプターの設定を netsh interface ipv4 show subinterfaces で確認すると、MTU値は 1500 のまま。ここにミスマッチが生じていました。

IPv4側で通信が通るサイズ（MTU 1400）に手動で引き下げても現象が改善しない場合、次に疑うべきは「IPv6」です。

Windowsや主要なブラウザ（Chrome/Edge）は、宛先がIPv6に対応している場合、IPv4よりもIPv6での接続を最優先（RFC 6724）にする仕様になっています。Microsoft 365のフロントエンドは完全にIPv6へ対応しているため、ブラウザは最優先でIPv6経路を選びます。

日本のインターネット環境（特にIPoEの各種トンネリングサービスやルーターのパススルー設定）において、IPv6側の通信経路やMTU、ファイアウォール（SPI）の挙動に不整合がある場合、巨大な認証パケットが流れた瞬間に通信が強制リセット（RST）されてしまいます。

端末の「IPv6通信」を一時的に無効化し、強制的にIPv4通信へと固定して挙動を確認します。

【結果】 IPv6を無効化した瞬間、これまでの接続エラー（ERR_CONNECTION_RESET）が嘘のように消え去り、TeamsやOneNoteへのアクセス・サインインが正常化しました。

切り分け検証として「IPv6のチェックを外す（無効化）」ことで解決しましたが、MicrosoftとしてはIPv6を完全に無効化するのではなく、「IPv6を有効に維持しつつ、IPv4を優先する設定」を推奨しています。

環境に合わせて、以下のいずれかの方法で恒久対策を行うのがベストです。

IPv6の機能をシステム内に残しつつ、通信の優先順位だけをIPv4に切り替えます。これにより、IPv6経路によるM365のトラブルを安全に回避できます。

管理者権限でPowerShellを開きます。
以下のコマンドを実行して、レジストリに設定を追加します。PowerShellNew-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Tcpip6\Parameters" -Name "DisabledComponents" -Value 32 -PropertyType DWord -Force ※ 32（16進数で 0x20）は、Microsoftが定義する「IPv6よりもIPv4を優先する」ための値です。
ネットワークプロパティでIPv6のチェックをオンに戻し、端末を再起動します。