ブラウザ版 M365／Copilot はなぜ「一律出口」に弱いか

ブラウザで開く Microsoft 365（Outlook、Word、Excel オンラインなど）は、単一の office.com だけで完結しません。認証は login.microsoftonline.com、静的資産とテレメトリは別サブドメイン、Copilot パネルは microsoft.com 配下の API と連携し、CDN／解析／検索まで含めると数十〜数百のホストへ短時間に分散します。出口を一律の「PROXY」や広すぎる GEOIP に寄せると、「一覧は出るのに本文だけ読めない」「Copilot だけ永遠にロード」「サインイン後すぐ再ログイン」といった部分的成功が起きやすいです。

同じ Microsoft エコシステムでも、当サイトの GitHub Copilot（VS Code 拡張）向けの記事 は、github.com と marketplace.visualstudio.com を含む開発者 IDE の通信が主題です。本稿はブラウザ上の Office とブラウザ版 Copilot に焦点を当て、エディタ拡張と混同しないよう整理します。Clash は接続ごとにルールでポリシーを選べるため、M365 用の束を明示し、ルール分流のベストプラクティス に沿って MATCH の手前まで順序を固定すると、再現性が上がります。

「社内プロキシだけ無効にしたら直る」ケースもあれば、「VPN と競合して TLS が途中で切れる」ケースもあります。いずれもどのホストがどのポリシーに乗ったかをログで確かめるのが早道です。

典型症状と観測のコツ

代表的には次のようなパターンです。(1) Outlook の Web がヘッダーだけ表示されメール本文が出ない。(2) Word オンラインで共同編集が繋がらない。(3) 右ペインの Copilot がスピナーのまま。(4) サインイン直後にトークン更新で再ログインを繰り返す。Chrome／Edge／Firefox で再現が変わる場合は、拡張やブラウザ独自の「セキュア DNS（DoH）」の有無も疑います。

ℹ 観測のコツ：失敗した瞬間にライブ接続やログへ出るホスト名をメモし、認証・メイン UI・Copilot・CDN のどの層かに分類します。TLS ハンドシェイク前に落ちるなら経路／SNI、握手後に滞るなら HTTP／HTTP2 以降のレイヤを疑い、接続ログと TLS タイムアウト の切り分けとも照らします。

microsoft.com／office.com 周辺の束ね方

完全なホスト表は SKU と時期で変わるため、固定リストのコピペより観測＋ルールプロバイダ追従が現実的です。出発点としては DOMAIN-SUFFIX,microsoft.com、DOMAIN-SUFFIX,microsoftonline.com、DOMAIN-SUFFIX,office.com、DOMAIN-SUFFIX,live.com、必要に応じて sharepoint.com / onenote.com / bing.com（Copilot 連携で触れる場合）などを同じ低遅延・同一地域ノードへ揃えたいグループに載せます。企業テナントでカスタムドメインを使う場合は、一覧に無い FQDN が混ざるため、その都度ログから追記してください。

逆に「microsoft.com を丸ごと DIRECT」へ寄せすぎると、別用途のサブドメインまで意図と違う経路になり副作用が出ることがあります。業務ブラウザ用のプロファイルと、ゲーム・動画など広い MATCH を分ける運用が読みやすくなります。

ルール例：M365 用ポリシーグループへ集約する

狭い DOMAIN を先に、GEOIP や巨大リストの前へ M365 束を置くのが安全です。次は概念例です。グループ名 M365_STABLE は、遅延が安定したノード（または契約・ポリシーが許す DIRECT）に割り当ててください。

rules.yaml（例：概念のみ／本番は検証のうえ調整）

# Place M365 bundle BEFORE broad GEOIP / catch-all rules
rules:
  - DOMAIN-SUFFIX,office.com,M365_STABLE
  - DOMAIN-SUFFIX,microsoft.com,M365_STABLE
  - DOMAIN-SUFFIX,microsoftonline.com,M365_STABLE
  - DOMAIN-SUFFIX,live.com,M365_STABLE
  - DOMAIN-SUFFIX,sharepoint.com,M365_STABLE
  - DOMAIN-SUFFIX,msauth.net,M365_STABLE
  - DOMAIN-SUFFIX,msftauth.net,M365_STABLE
  - MATCH,PROXY_OR_DEFAULT

サードパーティのブロック系ルールセットが microsoft.com の一部を先に拾うと、ブラウザだけ静かに失敗します。ルールの版と順序を ベストプラクティス に沿って棚卸しし、意図しない先行マッチを潰してください。

システムプロキシ・TUN とブラウザの取りこぼし

Chromium 系は通常システムプロキシ設定を読みますが、起動フラグや拡張、別プロファイルで挙動が変わります。Electron アプリと違い、ブラウザは比較的素直でも、企業管理ポリシーでプロキシが固定されていると Clash 側と二重化します。取りこぼしが残るときは TUN モードでカーネル側から揃えるのが有効です。TUN と VPN／ゼロトラストの競合や優先度は TUN の深掘り記事 を参照してください。

ループプロキシにも注意します。OS 全体やブラウザを Clash に向けたまま、購読取得だけが不安定なチェーンに入るとルールが古くなり、「昨日まで動いていた」状態になります。購読更新とプロバイダ取得は DIRECT か安定した専用グループへ残してください。

DNS、fake-ip、ブラウザ DoH のズレ

Clash の fake-ip と、ブラウザ内の「DNS over HTTPS」が二重になると、ルールが期待した名前解決の経路とずれ、名前は解けるのに TLS が張れない症状に見えることがあります。DNS 側の nameserver-policy／フォールバック、fake-ip フィルタとルールを一致させる整理は Clash Meta の DNS：nameserver・fallback・fake-ip を併読すると早いです。社内 DNS が分割ホライズンを返している場合は、社外経路での比較試験も有効です。一般的な当たりは FAQ も参照してください。

企業 SSO・Conditional Access との見分け

デバイスコンプライアンス、場所、リスクスコア、レガシ認証禁止など、Azure AD／Entra ID のポリシー拒否は Clash で経路を揃えただけでは解消しません。「別ブラウザなら通る」「会社端末だけダメ」「モバイルのみダメ」といったパターンは、まず IdP のサインインログと条件付きアクセスのヒットを確認します。Clash はネットワーク層の出口と名前解決を揃える道具であり、識別情報やデバイス状態そのものを書き換えるものではありません。

GitHub Copilot（IDE）向け記事との棲み分け

GitHub Copilot（VS Code）向け記事 は Marketplace・github.com API・拡張取得 CDN を重視します。本稿はブラウザ上の Office と Microsoft 365 Copilot を主眼に置き、ホスト束の考え方は近い一方、観測すべきプロセスと再現条件が異なります。IDE を併用する場合はプロファイルを分け、ルール順の衝突を避けるのが安全です。

⚠ コンプライアンス：法令、Microsoft の利用規約、職場のセキュリティ方針を遵守してください。本稿は許可されたネットワークでの接続安定化の整理であり、未承認の迂回やポリシー回避を推奨するものではありません。

許可された利用の前提で押さえるチェック

  1. この環境で Clash と Microsoft 365／Copilot を使うことが許可されているか確認する。
  2. 失敗時のホスト名を列挙し、認証／メイン UI／Copilot／CDN の層に分類する。
  3. office.com / microsoft.com 束が MATCH より前で一貫しているか、ルールセットの版と衝突がないか確認する。
  4. システムプロキシのみ・TUN のみで A/B 比較し、ブラウザの取りこぼしを潰す。
  5. Clash DNS／fake-ip とブラウザ DoH の二重構成がないか確認する。
  6. 購読更新とルールプロバイダ取得がループせず成功する直列経路を残す。
  7. 再ログインが続く場合は SSO・Conditional Access のログでネット以外の拒否を除外する。

ログ行やスクリーンショットを段階ごとに残すと、全設定のやり直しより早く原因に辿り着けます。

まとめ

ブラウザ版 Microsoft 365 と Copilot の不安定さは、単一ドメインの遅延では説明しきれません。office.com／microsoft.com／認証 IdP／CDNへ分かれた通信を、M365 向けポリシーグループへ束ね、システムプロキシまたは TUN のどちらが実トラフィックを覆っているか揃えれば、スピナーや再ログインの多くは再現可能な経路のずれに還元できます。DNS／fake-ip／ブラウザ DoH を同じ前提で扱い、それでも切れる場合は SSO 側の拒否を疑う順番が現実的です。Clash はルールとログが読めるため、プリセット任せより観測に基づく分流が長期運用ではラクになります。

→ 方針が固まったら、Clash を無料ダウンロードし、業務ブラウザ用のプロファイルとして試してください。読み込み待ちや再認証に奪われた時間を、本来の仕事に戻せます。