📖 チュートリアル ⏱ 約20分で読めます

2026：Microsoft Copilot ウェブを Clash で安定利用——M365 ログイン周りのドメイン分流と DNS の段階実測

2026 年も Microsoft Copilot は Microsoft 365 や Edge・Windows の UI と深く結びつき、ブラウザで Copilot ウェブを開いたときの背後には、製品フロント用のホスト、サインインとトークンまわり、テナント／ライセンスの確認、静的アセットや CDN が別々の FQDNとして現れやすい構成です。Clash（多くの場合 Clash Meta／Mihomo コア）で分流ルールが狭すぎる、または DNS（fake-ip と DoH）と噛み合っていないと、「ページの枠は出るのにチャットだけ失敗」「ログイン画面だけ無限ロード」といった部分的成功に見えがちです。本稿は Zoom／Teams の会議向け分流記事や 開発者向け Cursor／GitHub 記事とはホスト集合を明確に分離し、Copilot／M365 ブラウザ体験に寄せたDOMAIN 束ねとRule モードでのログ実測までを日本語で整理します。エッジ構成は更新で変わり得るため、以下の YAML は出発点の例とし、自分の環境の接続ログを正としてください。職場・学校のネットワーク方針や利用規約は必ず優先してください。

症状を分類すると切り分けが速い

ブラウザで Copilot や M365 ポータルを開いたとき、(1) ランディングは表示されるが会話 API や提案カードだけタイムアウトする、(2) login.microsoftonline.com 周りだけ別挙動になる、(3) Outlook や OneDrive など連携アプリへのリダイレクトでだけ詰まる、というパターンに分けられます。(1) はフロントとバックエンドのホストが DIRECT のまま、あるいは遅い／不安定なノードに分散していることが多く、(2) は認証ドメインがルールの下の方で RULE-SET に飲まれている、(3) は *.office.com や *.microsoft.com のサブセットが意図しない出口に落ちている、が典型です。開発者ツールのネットワークタブで失敗しているリクエストのホスト名をメモしてからルールへ反映すると、当てずっぽうが減ります。

用語の整理は チュートリアル、ルールの書き方は カスタムルールの解説 と併読するとスムーズです。生成系 AI 全般の別プロバイダは ChatGPT／OpenAI API 向け記事で別ホストとして扱っているため、Copilot 用ルールと混同しないのがポイントです。

分流の土台：proxy-groups に「Copilot／M365 用」を切る

購読テンプレの PROXY をそのまま指すより、CopilotProxy のような用途名のグループを select または url-test で用意し、rules からは常にそのグループ名を参照するのが運用しやすいです。Microsoft 系は TLS と長めのセッションが多いので、同じ高品質ノードに揃えるのが基本方針です。認証だけ別出口にしたい場合は login.microsoftonline.com だけ別グループに分ける、といった切り方もありますが、まずは束ねて動作確認してから狭めると切り分けが楽です。ネストや型の詳細は proxy-groups のガイド を参照してください。

💡 ヒント テンプレのグループ名と rules 内の綴りが一致しているかを最初に確認してください。ここがずれると「ルールを足したのに効かない」状態になりがちです。

ホストの考え方：Copilot ウェブと M365 連携（出発点）

Copilot のブラウザ体験では copilot.microsoft.com が中心になりやすく、製品ラインによっては copilot.cloud.microsoft のようなホストが現れる場面もあります。検索や補助機能の文脈では www.bing.com や edgeservices.bing.com 系が挟まることがあります。職場・学校アカウントでは login.microsoftonline.com、コンシューマー寄りでは login.live.com がログインフローに現れやすいです。Microsoft Graph やサブストレート API では graph.microsoft.com、Office ウェブでは substrate.office.com、outlook.office.com、www.office.com などが現れます。静的アセットや CDN として res.cdn.office.net、statics.teams.cdn.office.net のようなホストがログに出ることもあります。

方針として、(A) 上記をまとめて CopilotProxy に寄せるのがシンプル、(B) まずは microsoft.com と office.com のサフィックスを優先し、ログに出たホストを順次足す、のどちらかから始めると安全です。DOMAIN-SUFFIX,microsoft.com の一括は手早い一方、ゲームや別サービスまで同じ出口に乗るため、影響範囲が気になる場合はログで必要なサフィックスに絞る運用が向きます。ルールの上から先にマッチした行が優先されることは カスタムルール記事 のとおりです。コミュニティの RULE-SET と併用する場合も、Copilot／M365 向けの例外を上に積むと意図した出口に寄せやすくなります。

rules:
  # Examples only — tune group name (CopilotProxy) and domains to your logs
  - DOMAIN-SUFFIX,copilot.microsoft.com,CopilotProxy
  - DOMAIN-SUFFIX,copilot.cloud.microsoft,CopilotProxy
  - DOMAIN-SUFFIX,microsoft.com,CopilotProxy
  - DOMAIN-SUFFIX,office.com,CopilotProxy
  - DOMAIN-SUFFIX,live.com,CopilotProxy
  - DOMAIN-SUFFIX,microsoftonline.com,CopilotProxy
  - DOMAIN-SUFFIX,bing.com,CopilotProxy
  - DOMAIN-SUFFIX,graph.microsoft.com,CopilotProxy

上記に無いホストがログに出たら、それが次に追加すべき行です。地域・契約・条件付きアクセスや企業ポリシーによっては、プロキシ経路を変えても利用が制限される場合があります。技術的な経路整備とアカウント側の許可は別問題なので、管理者のメッセージやポータルのエラーコードも併記して判断してください。

DNS と DoH：fake-ip とルールを揃える

分流ルールが正しくても、DNS が期待と違う応答を返すと、タイムアウトや証明書エラーに見えます。Clash／Mihomo 系では dns ブロックの fake-ip、redir-host、DoH の有無が挙動に直結します。テンプレの推奨設定から大きく外すと切り分けが難しくなることもあるため、まずは購読既定で再現する→ 問題が続くときに、(1) DoH エンドポイントの信頼性とレイテンシ、(2) nameserver-policy で microsoft.com や office.com だけ別 DNS に寄せる、(3) IPv6 の有無と OS の解決順、を一度に一項目ずつ変えるのが安全です。

ブラウザ独自の Secure DNS（DoH）と Clash 側の DNS が二重に効いていると挙動が読みにくいので、比較時にはブラウザ側を一時オフにする方法もあります。Windows で一部 UWP やストアアプリがプロキシを読み違える場合は Windows 11 の UWP とシステムプロキシ記事も参照してください。Electron 系のスタンドアロンクライアントを使う場合は、システムプロキシを読まない経路があるとルールが効きません。そのときは TUN モード でトラフィックをコア側に寄せる案を検討してください。

動作モード：Rule・Global・Direct の使い分け

Rule が日常運用の基本です。Global は「すべてをプロキシへ」として、一時的にルール不足かノード品質かを切り分けるのに便利ですが、国内サイトまで遠回りになるため常時利用はおすすめしません。Direct はベースライン計測用に、Clash を事実上オフに近い状態で挙動を見るときに使います。Copilot だけ不調なときは Rule に戻し、該当ホストが意図したポリシーにマッチしているかをログで確認するのが定石です。トンネル型 VPN との違いは Clash と VPN の比較 も参照してください。

⚠️ 注意 本稿は正規のライセンスと利用規約を前提とします。職場・教育機関ではプロキシ迂回が禁止されている場合があります。技術的に可能でも、規程と管理者の指示を優先してください。

実測手順：ログで「宛先」と「採用ルール」を確認する

  1. 1

    Baseline（Direct または Clash 停止）

    まず Direct でブラウザから Copilot を開き、同じ端末から開発者ツールで主要リクエストのホスト名を控え、症状が再現するかを記録します。企業ネットワークではベースライン自体が制限されていることもあります。

  2. 2

    Rule に戻し、サインインとチャットでログを読む

    ログイン完了後の会話投入、提案の読み込み、M365 ポータルへの遷移のそれぞれについて、接続一覧／コアログで向いているドメインとマッチしたルール行（またはポリシー名）をメモします。リストにないホストが出たら、それが次に追加すべき行です。

  3. 3

    一行ずつルールを足して再計測

    DOMAIN-SUFFIX を追加し、同じ操作を繰り返します。一度に大量変更すると効いた変更が特定できません。意図と違う行にマッチしているときは、より具体的なルールを上へ移動します。

  4. 4

    DNS ログがあれば併記する

    名前解決結果がおかしい場合はルールより先に DNS を直します。クライアントが DNS ログを出せない場合は、ログレベルを上げる、別ツールで確認するなど環境に合わせてください。

この繰り返しが本稿でいう「段階実測」です。検索で見つかるドメイン一覧は参考にとどめ、自分のログを正としてメンテすると、UI やエッジ変更にも追従しやすくなります。Google 系の整理は Gemini 向け記事 で別ホスト集合として扱っているため、混同せず参照してください。

よくある質問

ルールを足したのにサインインだけ失敗する

microsoftonline.com や live.com がより汎用の RULE-SET より下にあり、DIRECT や意図しないポリシーに落ちているパターンです。該当行を上に移動するか、より先頭に DOMAIN ルールを追加してください。

DOMAIN-SUFFIX,microsoft.com にしたら他の通信まで変わった

サフィックス一括は広くマッチします。影響が大きい場合はログで実際のホストを列挙し、必要なサブドメインだけに狭めてください。

Teams の会議向け記事と何が違う？

会議やメディア転送では UDP／RTC や別 CDN が前面に出やすく、本稿はブラウザの Copilot／M365 ウェブに寄せたホスト束ねです。症状に応じて両方を参照し、ログでホストを足し引きしてください。

まとめ

Microsoft CopilotのようにブラウザフロントとサインインとM365 連携が分かれやすい体験では、分流ルールを用途別に整理し、DNS（DoH を含む） と Rule モードでのログ検証をセットにすると、「枠は見えるのに中身だけ不安定」といった症状に対処しやすくなります。本稿のドメイン例は出発点であり、ログに基づきルールを育てることが長く使うコツです。生成系の別路線は ChatGPT／OpenAI API 向け記事、動画・ストリーミング全般は Netflix 向け記事の切り口とも役割が異なります。

クライアントの入手は 本サイトのダウンロードページ を第一にすると、記事との対応も追いやすくなります。ルールの基礎を固めたい場合は カスタムルール完全ガイド も併せてどうぞ。用途ごとに出口を切り替えられる点では、端末全体を常時トンネルする汎用 VPN に比べ、Clash の運用体験が一段整理されやすい場面が多いです。

→ Clash を無料ダウンロードし、Microsoft Copilot 向けの分流と DNS を試す