2026 年の文脈：Foundry 集中と「線路がぶれる」症状
2026 年 4 月頃から、Microsoft は MAI-Image-2-Efficient などの新モデルを Microsoft Foundry や MAI Playground から試せる導線を前面に出しており、開発者のコンソール操作とREST／SDK からの API 呼び出しが同時に増えやすい局面です。Azure 上の AI ワークロードは、ポータルやリソース管理、Entra ID（旧 Azure AD）による認可、推論エンドポイント、テレメトリ用の別ホストまでFQDN の束が太いのが普通です。購読ルールの「Microsoft」カテゴリに含まれていても、更新の遅れや自分のルール列での順序ミスで一部だけ DIRECT とプロキシが混在すると、体感では「ログインや一覧は速いのにチャットや推論だけ止まる」「同じコードでも成功率が時間帯で変わる」といった部分的不調に見えがちです。
本稿の目的は「Microsoft サービス全体をざっくり高速化」ではなく、Clash Microsoft Foundry／Azure AI プロキシまわりで実際に出るホスト名を軸に Foundry 分流の型を示し、TLS の SNI と DNS、接続ログで自己検証できるようにすることです。クラウド利用は居住地域の法規制と Microsoft／Azure の利用規約に従う前提であり、規制回避を助長する意図はありません。ルールの共通理解は ルール分流の総覧記事 と併読すると早いです。
「ポータルは開くが Foundry だけ不安定」と呼ばれる典型
コミュニティや社内チャットでよく挙がるのは次のパターンです。（1）Outlook や Teams は問題ないのに、ai.azure.com 上のプレイグラウンドだけ読み込みが長い。（2）デプロイ済みの Azure OpenAI エンドポイントだけが間欠的に timeout や connection reset になる。（3）ブラウザでは成功するが、CI やコンテナから同じ URL が失敗する。（4）ノードを手動で切り替えた直後だけ成功率が変わる。原因はリージョン側の障害だけでなく、同一セッション内でもホストごとに別策略へ落ちている、DNS の返答と実コネクションの経路が一致していない、企業プロキシやセキュリティ製品が長時間 TLS だけ切断する、などレイヤの異なる要因が重なります。
切り分けの第一歩は、Clash の接続ログで実際に使われた FQDN と割り当てられた策略名を突き合わせることです。Microsoft はプロダクト更新でサブドメインが増えやすいため、公開されているドメイン一覧を盲信せず、自分のテナントとリージョンで出たログを正にしてください。関連記事の横断には ブログ一覧 も便利です。
ドメイン軸：Foundry／Azure AI で押さえたいホスト名の束
mode: rule で運用している場合、広い GEOIP や最終 MATCH より前に、コンソールと推論で繰り返し現れるホストを専用の策略グループへ流すのが基本形です。環境により差はありますが、出現しやすいのは ai.azure.com（Azure AI Foundry の UI 周辺）、portal.azure.com と management.azure.com（リソース管理）、login.microsoftonline.com や login.live.com（認証）、graph.microsoft.com（Microsoft Graph）、推論まわりの *.openai.azure.com や cognitiveservices.azure.com、ドキュメント・静的アセットの learn.microsoft.com、CDN 系の *.azureedge.net などです。Foundry 分流では「推論だけ」ではなく認証とポータルも同じ安定出口に寄せるかどうかを最初に決めると設計がブレにくく、Entra のリダイレクトで別リージョンの IP に飛ぶケースでもログで追いやすくなります。
DOMAIN-SUFFIX,azure.com のように一括で合わせる方法もありますが、Blob や別ワークロードまで同一出口に吸い込むとレイテンシや課金観点で想定外になりがちです。運用初期は DOMAIN,ai.azure.com や DOMAIN-SUFFIX,openai.azure.com のようにAI コンソールと推論に近い名前から限定し、ログで不足分を足すのが安全です。DOMAIN-KEYWORD,microsoft は無関係ホストを巻き込みすぎるため避け、国内向けトラフィックを GEOIP,CN,DIRECT へ落とす構成では、Azure AI 向けの細かい DOMAIN 行は CN 判定より上に置いてください。
TLS／SNI：ルールは合っているのに握手だけ失敗するとき
HTTPS ではクライアントが送る SNI（Server Name Indication）がホスト名と一致している必要があり、中間機器や誤った透明プロキシがあるとルール上は正しい出口なのに TLS だけ失敗することがあります。Clash 側では策略と実ノードの組み合わせはログで追えますが、ブラウザ拡張や企業ルート証明書による MITM が混ざると症状が紛れやすいので、まず同一マシン上で curl とブラウザを切り替えて再現するかを確認してください。Azure AI の公式 SDK は環境変数 HTTPS_PROXY を参照するため、値が Clash のローカルポートを指しているか、別プロキシでルールを迂回していないかもセットで見ます。
rule-providers：購読ルールと手書きルールの併用
コミュニティの rule-providers に「Microsoft」や「Azure」向けのセットがあれば保守負担を減らせます。一方でリストが広すぎると、意図しない Microsoft 365 トラフィックまで同じ策略に流れ、普段は速い経路が遠回りになることもあります。実務では（1）購読で大枠を取り、（2）Foundry 試用でログに出た不足 FQDN だけ rules: 冒頭に DOMAIN で足す、の二段が扱いやすいです。リストの更新日と実挙動がずれたときは、Clash 側でプロバイダの再読み込みが反映されているかを先に確認してください。
策略グループ：固定出口・自動選択・フォールバック
安定アクセスを優先するなら、単一ノードへの手動 select だけに頼らず、url-test でレイテンシの良い出口を自動選ぶ、あるいは fallback で失敗時に別集合へ逃がす、といった二段構えが扱いやすいです。本稿では便宜上、Microsoft／Azure AI 向けの入り口を AI-AZURE と呼びます。中身は既存の「海外用まとめグループ」を参照しても構いませんし、規約と SLA の観点で地域を絞ったノードだけを入れ子にしてもよいでしょう。名称のタイポは設定ミスの典型なので、GUI で改名したら rules: 側も同時に更新してください。
GEOIP や広い MATCH より必ず上に置いてください。
YAML の記述例（ホスト名はログに合わせて差し替え）
以下は説明用の断片です。実際の FQDN はクライアントの接続ログに合わせて調整してください。コピペのままでは動かない場合があります。
proxy-groups:
- name: AI-AZURE
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
proxies:
- 低遅延ノード A
- 低遅延ノード B
- フォールバック用ノード
rules:
- DOMAIN,ai.azure.com,AI-AZURE
- DOMAIN-SUFFIX,openai.azure.com,AI-AZURE
- DOMAIN-SUFFIX,cognitiveservices.azure.com,AI-AZURE
- DOMAIN,login.microsoftonline.com,AI-AZURE
- DOMAIN,graph.microsoft.com,AI-AZURE
- DOMAIN,portal.azure.com,AI-AZURE
- DOMAIN,management.azure.com,AI-AZURE
- GEOIP,CN,DIRECT
- MATCH,既定の策略グループDOMAIN-SUFFIX,cognitiveservices.azure.com は他の Cognitive Services も含むため、本番ではログベースでより細かく分割することを推奨します。url-test の計測 URL や間隔は環境に合わせて調整してください。課金や運用方針で出口を固定したい場合は、上位に select を置き、普段は自動選択・障害時だけ手動切替、という構成も有効です。
コンソール（Foundry）と API クライアントの違い
Microsoft Foundry のブラウザ UI は長めのセッションやストリーミングを多用し、SDK や CI からの Azure AI プロキシ経由の呼び出しは短いリクエストを高頻度で繰り返す、といったトラフィック形状の差があります。どちらも TLS で海外へ向かいますが、失敗メッセージの出方が異なるため、「画面は開けるが推論だけ不安定」「エンドポイントだけ失敗」といった切り分けがつきやすいです。Windows で WSL やコンテナを併用している場合は、WSL2 とホストのプロキシ橋渡し が別問題として絡むこともあるため、ログ上の送信元インターフェースも確認してください。
DNS・fake-ip と「ルールは合っているのに不通」
enhanced-mode: fake-ip を使うと、ドメインルールと実コネクションのタイミングがずれ、一見ルールは PROXY なのに期待と違う経路になることがあります。Azure AI のような長めのセッションや、再試行付きクライアントでは、DNS のフォールバックや fake-ip-filter をセットで見直す価値があります。詳しい型は Fake-IP と DNS の解説 を参照してください。IPv6 が有効な回線では、IPv4 ベースの判定だけでは取りこぼすケースもあるため、経路とアドレスファミリの両方をログで確認してください。
システムプロキシと TUN の使い分け
ブラウザはシステムプロキシ設定を尊重しますが、一部のネイティブアプリやプロキシ非対応のバイナリはそうとは限りません。OS 全体の TCP／UDP を Clash に取り込みたい場合は TUN が有効です。権限やスタックの違いは TUN モード解説 にまとめています。macOS ではターミナルと GUI のプロキシ設定が分かれやすい点は、Shell 環境変数の記事 も参考になります。
他クラウドの生成 AI 記事との役割分担
既に公開している ChatGPT／OpenAI API、Gemini／Google AI Studio、Claude／Anthropic、Grok／xAI は、それぞれ別ベンダーのドメイン束に焦点を当てています。本稿はそれらとキーワードを重ねず、Microsoft Foundry と Azure AI エンドポイントに絞った Foundry 分流の型です。OpenAI ブランドのパブリック API と、テナント配下の Azure OpenAI ではホスト名が根本的に異なるため、ルール列でもファイルを分けて管理すると運用が楽になります。
効果の確認手順（実測ベース）
- 接続ログを開き、Foundry または MAI Playground で短い推論を実行して、想定ホストが
AI-AZUREに割り当てられたか確認する。 - SDK や curl でデプロイ済みの推論 URL にリクエストし、同じく策略と実出口を照合する。
AI-AZUREを一時的に地域の分かりやすいノードへ固定し、タイムアウト率や応答時間の変化を比較する。- DNS クエリと実 IP の対応が期待どおりか、fake-ip 利用時はフィルタ設定も含めて確認する。
よくあるつまずき
ルールを足しても挙動が変わらない
より上の行で別ルールに吸われている、策略名の綴りが一致していない、環境変数でプロキシが固定されている、ブラウザ拡張が独自プロキシを指定している、といった理由が多いです。ログの「一致したルール行」と「実際の出口」を突き合わせてください。
Microsoft 365 まで遅くなった
広すぎる DOMAIN-SUFFIX や誤ったキーワードルールが原因で、メールや会議まで AI-AZURE に流れている可能性があります。ログの FQDN を精査し、ルールを絞り込んでください。
まとめ
2026 年春の新モデル試用で Microsoft Foundry や MAI Playground へのトラフィックが増えても、Azure AI 周辺はコンソール・認証・推論でホストが分岐しやすく、出口がリクエストごとにぶれると間欠的な失敗が増えがちです。Clash Microsoft Foundry 向けには、接続ログを正にした ドメイン前置き と DNS／fake-ip の点検、必要なら TLS／SNI まわりの切り分けが実務的な近道です。他ベンダーの生成 AI 向け記事と組み合わせれば、ひとつの設定ファイルの中でベンダー別チャネルを整理しやすくなります。
クライアントの導入や更新は、プラットフォーム別の入手先がまとまった ダウンロードページ から行うと、本稿の設定を追いながら検証しやすくなります。
→ 無料で Clash をダウンロードし、Foundry と Azure AI 向けの分流ルールを自分の環境に合わせて整える