Windows 11 で Copilot が開かない？Microsoft・Copilot 系ドメインを Clash（mihomo）で分流する実測手順（2026）

1. なぜ「Copilot ＋ Windows ネイティブ」は別カテゴリか

当サイトでは、OpenAI・Anthropic・Google・DeepSeek など“ブラウザや API クライアントが伸びる先”を個別の記事で扱ってきました。これらと比べ、Copilotは copilot.microsoft.com のようなMicrosoft 管理下のエンドポイントに加え、Bing や Edge サービス、Microsoft アカウント（login.live.com など）へ通信が分散しやすいのが特徴です。さらに、シェル統合のホストと、Edge タブ内の Web ビューが同じ名前空間とは限らないため、「片方だけタイムアウト」が起きると、ルールの漏れを疑う前に失敗している URL のホスト名一覧を取るのが近道になります。

本稿が扱うのはネットワーク経路とルール設計の一般論です。サービスの利用可否・表示される地域メッセージ・組織ポリシーは、技術レイヤーとは別にアカウント設定や契約・法令に依存します。企業端末では MDM や条件付きアクセスが先に効く場合があり、そのときは社内規程を優先してください。ここで示す手順は、あくまで個人環境や許可された検証環境での参考として読んでください。

クライアントの導入や購読の取り込みは サブスクリプション導入ガイドを参照し、Windows 11 での GUI から TUN までの流れは Clash Verge Rev の初回設定（Windows 11）と併読すると全体像が掴みやすいです。

2. 症状を「シェル」「Edge」「認証」の三層で切り分ける

第一層はWindows シェル側の Copilot パネルです。ここはブラウザのタブとは別プロセスになりやすく、システムプロキシだけでは届かず TUN が必要というケースが報告されます。症状が「サイドバーだけ白い」のに、Edge で copilot.microsoft.com は開けるなら、まずUWP／システムコンポーネント経路とWin32 の Edge 経路でプロキシの効き方が分かれていないかを疑います。

第二層はMicrosoft Edge 内の Copilot／Discover 周辺です。ここでは edgeservices.bing.com や www.bing.com 系、設定同期や拡張機能ストアに向く別ホストが混ざりやすく、「チャット欄だけ読み込めない」は単一の DOMAIN-SUFFIX に収まらないことがあります。開発者ツールのネットワークタブで赤くなっているホスト名を列挙し、共通サフィックスがあれば束ねます。

第三層はMicrosoft アカウント／Entra ID のサインインです。login.microsoftonline.com、login.live.com、*.microsoftonline.com などは、Copilot 本体とは別タイミングで失敗すると「サインインできない」に見えます。Copilot 用の策略に載せすぎると意図しない出口へメールや Teams まで流れるリスクもあるため、職場プロファイルでは慎重に、個人用途ではログで実際に伸びているホストに合わせて最小限に足すのが安全です。

3. まず束ねたいホスト：Copilot・Bing・Microsoft アカウント

インフラは変わり得るため、次の一覧は出発点の例です。実際の通信先はブラウザの開発者ツール、mihomo のログ、必要なら DNS クエリログで突き合わせてください。Copilot の Web エントリは copilot.microsoft.com を中心に、bing.com 配下の API や Edge サービスが続く構成が一般的です。横断的に現れる microsoft.com、msn.com は広いため、最初から丸ごと同じ策略に載せると副作用が大きい場合があります。迷うときは症状再現中にだけ出るホストから優先的に DOMAIN 行を追加し、安定してから DOMAIN-SUFFIX に寄せると安全です。

認証まわりでは login.live.com、login.microsoftonline.com、account.microsoft.com が典型です。ストアや更新系の edge.microsoft.com や 設定ページのフェッチ先が混ざると、Copilot 以外の画面まで同じノードへ流れます。越境アクセスという観点では、利用する出口の国／事業者ポリシーと、Microsoft 側の利用条件を別レイヤーで確認してください。本稿は経路の切り分けに特化し、特定の地域への接続を推奨するものではありません。

ルールの評価順は ルールルーティング解説のとおり、具体的な DOMAIN／DOMAIN-SUFFIX を、広い GEOIP や MATCH より上に置きます。購読ルールセットの末尾に追記するだけでは効かないことがある点に注意してください。

4. mihomo ルール例：MICROSOFT_AI 策略へ DOMAIN-SUFFIX で載せる

実務では Copilot／Bing 周辺専用の策略グループを一つ切り、そこに安定したノードを割り当てると切り分けがしやすいです。以下は構造の例です。プロキシ名・ノード名は環境に合わせて置き換え、職場端末では範囲を狭めるか、管理者承認のうえで試してください。

# proxy-groups: optional dedicated group for Copilot / Bing / Microsoft web endpoints
proxy-groups:
  - name: MICROSOFT_AI
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

# rules: place before broad MATCH / GEOIP; extend with DOMAIN lines from your logs
rules:
  - DOMAIN-SUFFIX,copilot.microsoft.com,MICROSOFT_AI
  - DOMAIN-SUFFIX,bing.com,MICROSOFT_AI
  - DOMAIN-SUFFIX,bingapis.com,MICROSOFT_AI
  - DOMAIN-SUFFIX,microsoft.com,MICROSOFT_AI
  - DOMAIN-SUFFIX,live.com,MICROSOFT_AI
  - DOMAIN-SUFFIX,microsoftonline.com,MICROSOFT_AI
  - MATCH,PROXY

DOMAIN-SUFFIX,microsoft.com は広く効く一方、不要な通信まで同じ出口へ寄せる可能性があります。問題が Copilot と Bing に限定して再現するなら、まず copilot.microsoft.com と bing.com から始め、ログで不足が出たら edgeservices.bing.com などを DOMAIN で足す運用が現実的です。認証だけ別ノードにしたい場合は、グループを分けるか、ルール行の順序で優先度を調整します。

mihomo（Clash Meta）の挙動やログの見方は、他トピックと共通する部分が多いです。HTTPS の SNI がルールに乗るかは Sniffer 設定やモードに依存するため、必要に応じて Claude 向け DNS 稿や Sniffer 関連の記事で補完してください。

5. DNS・fake-ip でズレる典型と Edge の Secure DNS

fake-ip を有効にしていると、アプリが受け取る IP はローカルプールのダミーであり、実際の出口決定はコア側のルールと接続フェーズで行われます。このギャップが、「名前解決は成功したのに期待した策略に乗らない」という体感に繋がることがあります。Edge では ブラウザ独自の Secure DNS（DNS over HTTPS）が有効だと、mihomo の DNS モジュールをすり抜ける場合があります。症状がブラウザに偏るときは、Edge 設定のプライバシー／セキュリティから Secure DNS を一時的にオフ、またはOS の DNS と整合する設定に寄せて再試行してください。

切り分けの手順としては、（1）コアの DNS ログで copilot／bing 関連クエリがコアに届いているか、（2）接続ログで MICROSOFT_AI（または意図した策略）にマッチしているかを同じ操作シナリオで見比べます。シェル側だけ失敗するときは、TUN が有効か／例外プロセスが残っていないかもセットで確認します。

企業ネットワークでは分割 DNS やプロキシ自動設定が入り、自宅で動いた設定が再現しないことがあります。その場合は社内ポリシーを優先し、本稿は個人環境向けの参考として扱ってください。

6. TUN とシステムプロキシ：Windows 11 ではどちらが効くか

Windows 11 では、システムプロキシを読むアプリと、読まずに直結するアプリが混在します。Copilot のように OS に近いコンポーネントが絡むと、TUN（仮想 NIC）でトラフィックをまとめて拾う方が確実な場面があります。モードごとの違いは TUN モードの解説も参照し、名前解決と実接続のログが矛盾していないかを確認してください。

Clash Verge Rev を使う場合の初期設定の流れは、Windows 11 向けの初回セットアップ記事に整理してあります。管理者権限や Wintun の導入が絡む点も、同記事と合わせて読むと手戻りが減ります。

7. 実測の進め方：ログと開発者ツールでホストを拾う

おすすめの順序は次のとおりです。（1）問題の操作をしながらコアログで Copilot／Bing 関連ホストがどの策略にマッチしたかを確認する。（2）意図したグループに揃っているのに失敗するなら、DNS ログと fake-ip、Edge の Secure DNS を確認する。（3）シェル側だけ失敗するなら TUN とプロセス境界を疑い、（4）認証だけ失敗するなら login.* 系を別ルールで切り出すか、範囲を見直す。（5）それでも断続するなら別ノードへ切り替え、HTTP ステータスと TLS エラーを記録する。

開発者ツールのネットワークタブで失敗しているホスト名をメモし、mihomo のログのタイムスタンプと突き合わせると、ルールの漏れと DNS の漏れを同時に潰しやすくなります。HTTP/3（QUIC）が気になる場合は、Gemini 向け QUIC 記事の切り分けも参考にしてください。

8. つまずきやすいポイント（Windows Update との住み分けなど）

第一に、microsoft.com を広くプロキシへ寄せすぎると、更新やストア系まで同じ出口へ流れる可能性があります。アップデートの失敗や遅延が出たら、Windows Update 向けホストを DIRECT に残すなど、既存の購読ルールセットの方針と衝突していないかを確認してください。

第二に、ルールの順序ミスです。広い MATCH や GEOIP が先に勝つと、Copilot 用の行が評価されません。ルールの並びを購読ファイル全体で見直してください。

第三に、サービス側のメンテナンスやアカウント制限です。プロキシを正しくしても 403 やレート制限が返る場合は、公式のステータスやフォーラム情報と突き合わせてください。

9. まとめ

Windows 11 と Edge に深く統合された Microsoft Copilotは、copilot.microsoft.com を中心とした Microsoft・Bing 系ドメイン群に通信が分散しやすく、シェル・ブラウザ・認証のどこで失敗しているかによって打ち手が変わります。まず mihomo で専用策略へホストを束ね、挙動が割れるときは DNS（fake-ip）と Edge の Secure DNS、TUN／システムプロキシを疑うと切り分けが速くなります。ChatGPT や Gemini 向けの記事とは対象の名前空間が異なるため、本稿はMicrosoft ネイティブ文脈の足がかりとして使ってください。

同じ Clash 系スタックでも、GUI の表記とコア世代は移り変わります。購読とルールを整理し、ログでホスト名を追う姿勢を保つのがいちばん確実です。クライアントの入手から始めるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから環境を揃えるのがおすすめです。