症状の整理：プロキシは有効なのに Copilot だけ不調
Windows 11 でタスクバーの Microsoft Copilot を開くと読み込みが終わらない、Edge の Discover／サイドバー／ショッピング系パネルがスピナーのまま、あるいは「お住まいの地域では利用できません」に近い文言だけが出る──。一方で、別ブラウザや一般サイトは問題なく、Clash のダッシュボード上では期待どおりのノードに流れているように見える、というパターンは 2026 年時点でもよく聞きます。
ここで重要なのは、「システムプロキシがオン＝その UI の全トラフィックが同じ出口に揃う」ではないという点です。UWP／シェル寄りのコンポーネント、Microsoft アカウントや Entra ID の認可フロー、Bing や Office 365 系のエンドポイントは、ルール一つ抜けや DNS の取りこぼしだけで「表向きは繋がっているのに AI パネルだけ欠落」という見え方になりやすい領域です。まずは感情論ではなく、どのホストがどのポリシーに落ちているかをログとルール順で確認するのが近道です。
Microsoft 側で押さえたいホストの考え方
具体的なサブドメインはサービス更新で増減するため、ここでは「束ね方」の原則に留めます。多くの環境で効くのは、microsoft.com、microsoftonline.com、live.com、bing.com、msn.com、windows.net 系、azureedge.net や CDN 子域、さらに Copilot まわりで話題になりやすい copilot.microsoft.com 周辺の束ねです。Edge のサイドバーは edgeservices.bing.com など Bing スタックへ寄るケースが多く、「検索は動くがサイドバーだけ死ぬ」ときは Bing 系のルール抜けや SNI／QUIC 周りの取りこぼしを疑います。
サードパーティの巨大ルールセットだけに頼ると、更新タイミングで一瞬だけホワイトリストに紛れ込むことがあります。運用としては、自前の DOMAIN-SUFFIX 束ねをポリシーグループの手前に置き、「Microsoft スタックはこのグループへ」という一本化が再現性を上げます。細かい記法は 分流ルールの深掘りと、Windows 全般の入門は Windows 向けチュートリアルを併読すると整理しやすいです。
分流ルールの順序：先に当たった行が勝つ
Clash 系では ルールは上から評価され、最初にマッチした行で打ち切られるのが基本です。つまり、MATCH や広い GEOIP 行の上に、意図した Microsoft 束ねが来ていないと、常に別ポリシーへ吸い込まれます。逆に、テスト中に DIRECT を先頭で広く置きすぎると、意図せず国内直結のまま認可だけ失敗する──といった「半分だけ壊れた UI」が出ます。
実務的には、(1) ログで実際に出ている SNI／ドメインをメモし、(2) その文字列にマッチする行が設定ファイルのどこにあるかを検索し、(3) その行より上に競合する広いルールがないかを確認、の三段が定石です。HTTP/3（QUIC）でホスト名が見えずルールに載らない場合は、Meta Sniffer と QUICの整理も参照してください。
TUN モードとシステムプロキシ：二重有効は混乱の元
GUI クライアントによっては、TUN（仮想 NIC でフルトラフィック）とシステムプロキシ（WinHTTP／ユーザー環境のプロキシ設定）を同時に有効にできますが、挙動の読み方が難しくなります。典型は「ブラウザはシステムプロキシ、シェル／ストア系は TUN、名前解決だけ別ルート」といった経路の分裂です。Copilot や Edge サイドバーのような境界付近コンポーネントは、この分裂に敏感です。
切り分けのコツは、まずどちらか一方に寄せて挙動が単調になるかを見ることです。多くのユーザーは、安定優先なら TUN のみ、あるいは システムプロキシのみのどちらかに固定し、もう一方を明示的にオフにします。TUN の設計思想自体は TUN モードガイドにまとめてあります。IPv6 が併走している環境では、片系だけがプロキシを迂回して「半分成功」のように見えることもあるため、ルーター側や OS 側の IPv6 設定も視野に入れてください。
DNS と fake-ip：ブラウザと OS の見え方を揃える
プロキシコア側で fake-ip や専用 DNS を使っている場合、Windows のリゾルバが返す IP と、Clash が返す仮想 IPがアプリ種別ごとに食い違うと、TLS や証明書検証の手前で奇妙な失敗が出ます。特に Microsoft アカウントログインやトークン取得は、短いリダイレクトの連鎖に敏感です。
対処の基本線は、(1) Clash の DNS セクションで「どのドメインをどのサーバに聞くか」を意図どおりに分け、(2) 可能なら OS／ブラウザ側の DNS over HTTPS を一時的に切って挙動差を確認、(3) それでもズレるなら redir-host や専用の nameserver 指定を検討、です。DeepSeek や Gemini 向けの稿とは対象ドメインが異なりますが、「HTTP はプロキシ、DNS だけ直結」という構図は共通の落とし穴なので、同じ発想でログを追うとよいです。
Windows の「プロキシ除外」リストが誤って広すぎないか
Windows のインターネット設定には、プロキシを使わないアドレス（バイパス／例外）を列挙する欄があります。社内イントラやローカルホストを除外する用途は正当ですが、ここに *.microsoft.com や広いワイルドカードを誤って入れると、システムプロキシは有効でも対象ホストだけ直結し、結果として Copilot や Edge 統合 UI だけが期待した出口に乗りません。
また、セキュリティ製品や別 VPN が同じレジストリ／WinHTTP 設定を書き換えているケースもあります。Clash 側のルールは完璧でも、OS が「このサフィックスはプロキシを使うな」と言っていると勝ちます。疑わしいときは、バイパス欄をいったん最小化して再現性を確認し、必要な除外だけを戻すのが安全です。
Edge 本体と WebView：プロセス単位の注意
Edge のサイドバー類は、メインの msedge.exe 以外に WebView2 由来のプロセスが絡むことがあります。通常はユーザープロファイルと同じネットワークスタックを共有しますが、企業ポリシー（管理されたブラウザ）や別プロファイルでは、拡張機能・セキュリティソフトのフィルタが追加されます。「InPrivate では動くが通常窓だけ死ぬ」など、プロファイル差が出たら拡張とポリシーを疑う段階です。
ここは Clash だけでは完結しない領域ですが、同じ端末で別プロファイルや一時的な拡張無効化で再現が消えるかを見ると、ルール問題か端末ポリシー問題かを切り分けられます。
実務チェックリスト（短時間で回す順）
最後に、現場でそのまま使える順序を並べます。(1) Clash のログで Copilot／Edge 操作時のドメインと最終ポリシーを確認する。(2) そのドメインにマッチするルール行より上に、広い DIRECT／GEOIP 競合がないか検索する。(3) TUN とシステムプロキシの二重有効をやめ、片方に寄せて再テストする。(4) Windows のプロキシ除外に広い Microsoft 系が紛れ込んでいないか確認する。(5) DNS（fake-ip／DoH）を疑い、一時的に経路を単純化する。(6) それでもダメならアカウント地域・ライセンス・会社ポリシー側のメッセージと本文を照合する、という流れです。
この手順は、生成 AI サービス単体の稿（例：ChatGPT／Claude 分流や Gemini 向けガイド）とはドメイン集合が異なりますが、「ルール順・DNS・OS 設定の三位一体で見る」という姿勢は共通です。用途が違う記事を組み合わせて読むほど、自分の環境に合ったプロファイルが組みやすくなります。
まとめ
Windows 11 の Copilot や Edge サイドバーは、見た目はブラウザの一部に見えても、認証・Bing・Microsoft 365 基盤など複数ホストへ分散しやすい UI です。Clash 利用者にとっての要点は、ルールの上から順に効く評価モデルを前提にログで証拠を取ること、TUN とシステムプロキシを同時に頼りすぎないこと、そして OS のプロキシ除外が意図せず Microsoft 系を直結させていないかを確認すること、の三つに集約されます。
ルールと DNS を一体で設計できる点は、Clash エコシステムの強みです。単発のドメイン追記より、Microsoft スタック用の束ねとポリシーグループを先に決め、順序競合を減らすほうが、デスクトップ AI 入口のような「境界付近」の不具合には効きやすいでしょう。
Clash を無料ダウンロードして試す → 各 OS 向けの案内と合わせて、本記事のチェックリストで一度挙動を整理してみてください。