1. 検索意図と前提：Teams 代理と「どの層が割れたか」
本稿が想定する読者は、Teams 代理やゲートウェイの有無を疑いつつ、手元の Windows ビデオ会議環境で再現性のある改善を求める企業ユーザーまたはリモートワーク担当です。Teams はサインイン、会議室 UI、メディア転送、OneDrive 連携のプレビュー、通知まで別ホスト群へ並列アクセスするため、一行のルールずれが「会議だけ不安定」「ファイルだけ開かない」といった形で現れます。まず「すべてを単一の遅い出口に流している」のか、「Microsoft 365 の認証と Teams CDN が別策略に落ちている」のかを分けることが、その後の作業時間を大きく節約します。
設定ファイルの流れをまだ把握していない場合は、サブスクリプション取り込みの記事で YAML の骨格を押さえてから読み進めてください。
2. 二つの典型：全量代理の「重さ」と M365／CDN の「分裂」
全量代理が効きすぎていると、往復遅延のばらつきだけでなく、企業プロキシやノード側の帯域制限が会議の短いパケット連打にそのまま効きます。体感では「ロボット声」「画面が数秒遅れて追いつく」に近づきます。対して経路分裂では、チャットは同期されるのにカメラ映像だけ来ない、共有ボタンを押すと止まる、添付のサムネイル生成だけタイムアウトなど、レイヤーごとの成功と失敗が混在しやすいです。Clash の接続ビューで、同じ秒付近に出たホスト名と命中したポリシー名を横に並べると、どちらの型に近いかが比較的早く判別できます。
3. Microsoft 365 と Teams を「層」に分けて眺める
以下は設計メモとしての区分であり、実際の FQDN はテナントとリージョンで変わります。コピペ用の完成ルール集ではなく、ログで表を作り直すための枠組みとして使ってください。
| 層 | イメージ | 症状との対応 |
|---|---|---|
| サインイン・トークン | login.microsoftonline.com、login.live.com 系 | Teams は開けるがすぐサインアウト、他 Office アプリも連鎖的に再ログインを求める。 |
| Teams 本体・API | teams.microsoft.com、*.teams.microsoft.com、Graph 相当 | チャンネル一覧は出るが会議に入れない、Presence が更新されない。 |
| 静的 CDN・クライアント更新 | 静的配信サブドメイン、インストーラ取得 | バージョンアップだけ失敗、初回セットアップが極端に遅い。 |
| メディア・共有・ファイル | 会議メディア、共有用エッジ、ストレージ連携 | 音声途切れ、共有トラックだけ建立しない、プレビューが回り続ける。 |
2026 年時点でも Microsoft はエッジ構成を更新し続けるため、過去に動いていた購読ルールだけに依存するのは危険です。自分の接続ログで一度ホスト表を更新するのが最も安全です。
4. Windows 特有：システムプロキシ、UWP、バックグラウンド更新
Teams デスクトップは OS のシステムプロキシ設定を参照しますが、別製品の常駐 VPN や企業 Wi‑Fi プロファイルと併用すると、見かけ上だけ別インターフェースに落ちることがあります。Store 由来コンポーネントやループバック制限が絡むケースは、Windows UWP と Clash の記事と合わせて読むと理解が早いです。まず Clash 側でシステムプロキシかTUNのどちらでトラフィックを握っているかを固定し、接続ログで Teams 関連行が期待する策略グループに入っているかを確認します。
5. ドメイン収集：会議・共有・添付をシナリオ分けする
収集手順は次のとおりです。シナリオを分けるとログが読みやすくなります。
- Clash を起動し、システムプロキシまたは TUN を有効化する。併用中の別 VPN は一旦無効化する。
- Teams で会議に参加し、音声・映像の途切れを再現する。接続ビューで同時刻付近のホストをメモする。
- 別セッションで画面共有を開始し、失敗や黒画面を再現する。大きな帯域を使うホストが増えないか確認する。
- チャットにファイルを添付し、プレビューとダウンロードの両方を試す。スピナーが止まらない時間帯のホスト名を拾う。
- 購読ルールのどの行より上に自作ルールを置くべきかを決める。
ポート競合やコア起動失敗など汎用の切り分けはトラブルシュート記事へ。本稿は Microsoft のマルチドメイン構成に焦点を当てます。
6. DNS 診断：名前解決がルール判定より先に崩れるとき
fake-ip モードはルール照合を速めますが、設定次第では「ルールに見えた名前」と「実接続の宛先」の整合が崩れ、クライアントが静かにリトライを続けることがあります。Microsoft 365 のようにサブドメインが多いサービスでは、軽いズレでも会議クライアントにはただの回線不良に見えます。上流 DNS を信頼できるサーバにそろえ、ログで頻出するサフィックスへ nameserver-policy 等を当てる、DoH と通常 UDP の二系統で結果が食い違わないかを nslookup や dig で確認する、といったDNS の切り分けをルール編集と同列に置いてください。フィールド名は Mihomo／Clash Meta のバージョンで差があるため、利用中のドキュメントと照合が必要です。
7. 推奨する切り分け順序（コピー用チェックリスト）
- Clash が起動していること、システムプロキシかTUNのどちらで握っているかを確認する。
- 接続ログで Teams／M365 関連ホストが意図したポリシーグループに入っているか、誤った
DIRECTがないかを見る。 - DNS モードと
fake-ipの組み合わせを確認し、必要なら特定ゾーンだけ実アドレス解決へ寄せる。 - 認証・Teams 本体・CDN・メディアをホスト／サフィックス単位でルール化し、購読内の広い
DIRECTより上側に矛盾なく配置する。 - 全量代理が疑わしい場合は、会議に不要なトラフィックを出口から外すか、会議専用の低揺らぎノードへ寄せる。
8. 分流ルールの考え方（記述例は置き換え前提）
購読ルールに「広い DIRECT」が先に入っていると、意図せず国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN-SUFFIX を上側に置くのが実務的です。以下は例示であり、実際のホスト名は必ずログで確認して置き換えてください。テナントや政府クラウドでは別ゾーンになるため、そのままでは動きません。
# Example only — verify hostnames in your Clash logs before use
rules:
- DOMAIN-SUFFIX,microsoft.com,PROXY
- DOMAIN-SUFFIX,microsoftonline.com,PROXY
- DOMAIN-SUFFIX,teams.microsoft.com,PROXY
- DOMAIN-SUFFIX,office.com,PROXY
- DOMAIN-SUFFIX,live.com,PROXY
- DOMAIN-SUFFIX,skype.com,PROXYメディアや大容量転送だけ別グループ（例：PROXY_MEDIA）に切り出すと、障害時に「認証は通っているが CDN だけ別出口」といった切り分けがしやすくなります。グループ名は proxy-groups に定義済みである必要があります。
9. システムプロキシと TUN：取りこぼしを減らす
システムプロキシは導入が容易ですが、プロキシ設定を読まないプロセスや別 VPN ドライバと併用すると経路が分裂します。TUN はルーティング層で取り込むため一貫性は上がりますが、権限や競合のトレードオフがあります。有効化する場合はTUN モードの解説を参照し、有効化後に再接続ログで Teams 関連がすべて期待どおりの経路になったかを検証してください。UDP を扱う会議では、ノード側の UDP 透過性とセットで見るのが実務的です。
10. Zoom 記事・Copilot 記事との読み分け
会議アプリ同士でもドメイン集合は一致しません。Zoom と Clash の CDN／WebRTC 分流記事では、低遅延メディアと Web シェルの分裂を中心に扱いました。IDE まわりの Microsoft 認証はGitHub Copilot／Models と Microsoft 分流記事で別角度から整理しています。本稿はTeams クライアントと Microsoft 365 の横断に絞ります。症状が似ていてもログの FQDN が異なる場合は、記事を読み分けたうえでルールを束ねてください。
11. 追加の落とし穴：IPv6、SSL 検査、ゲスト参加
IPv6 が有効な回線では、IPv4 だけプロキシに乗っているといったデュアルスタックの偏りで、会議だけ別経路に落ちることがあります。企業ゲートウェイの SSL 検査が証明書チェーンと衝突すると、プロキシ設定が正しくても接続エラーに見えます。外部ゲストとの会議では、招待リンク経由の別ドメインが増え、想定外の DIRECT に落ちることもあるため、再現手順にゲスト参加を含めるとログが厚くなります。別 PC へプロキシを配る場合はLAN プロキシの記事で allow-lan とファイアウォールの要点を確認してください。
12. まとめ：証拠ベースで Teams CDN と M365 を束ねる
Windows での Teams の落線や画面共有の失敗、添付プレビューのスピナーは、単一の設定ミスよりもモード・DNS・ルール順・ノードの揺れの積み重ねで起きがちです。本稿の順序どおりにログで確認していけば、「とりあえず別ノード」より再現性の高い改善が期待できます。購読ルールに頼り切らず、自分の環境で Teams と Microsoft 365 周辺のホスト表を更新する習慣を持つと、ポリシー変更にも強くなります。
接続ログと YAML 編集を GUI でまとめられるクライアントを使うと、運用負荷も下がります。同種ツールのなかでも、策略表示とコアの整合が取りやすい製品ほど、マルチドメインの業務アプリで長く使い続けやすい印象です。安定した出口設計から始めたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める