ChatGPT ワークスペースの Agent がぐるぐる？OpenAI と Slack ドメインを Clash（mihomo）で分流する実測（2026）

1. 典型的な症状：Agent だけ回る／Slack 連携だけ落ちる

ワークスペースまわりの体験は、画面上はシンプルでも背後の HTTP リクエストが複数ホストに分散しがちです。メインの会話 UI が表示できていても、別名の API エンドポイントや静的アセット用 CDN、外部 SaaS（Slack）の OAuth と Web APIが、リクエストごとに別のプロキシ策略や別ノードへ落ちていると、ユーザーから見ると「全体は生きているのに一部だけ永遠にスピナー」に見えます。

越境ネットワークでは、DNS の返答と実際の接続経路のズレ、HTTP/3（QUIC）と TCP の扱い差、社内プロキシやゼロトラスト製品の例外リストが重なると、再現性が低く感じられます。本稿は技術的に名前と出口を揃えることに焦点を当て、特定サービスの規約違反を助長する話や、未公表の内部ホスト名の列挙は扱いません。ホスト名は手元のログと開発者ツールで確認したものから足す運用が安全です。

チーム運用では、「ワークスペース用に決めた策略名」を README や社内 Wiki に書いておくと、個人のルール追記位置の差による切り分け地獄を減らせます。まずは失敗している URL のホスト部分をメモし、それが OpenAI 域か Slack 域かをラベル分けするのが近道です。

2. 既存の ChatGPT 記事との境界（封鎖・固定 IP ではない話）

当サイトのChatGPT 向けルール記事は、アカウントリスクや安定した出口 IP を意識した運用に寄った内容です。一方、Workspace Agents と Slack 連携のように複数事業者の名前空間が短い時間内に交互に現れるシナリオでは、まずすべての関連ホストを同じ低遅延かつ信頼できる策略グループへ載せる方が効くことが多く、「固定 IP にすれば必ず直る」という単純化は当てはまらないケースもあります。

たとえば Access Denied や利用地域に関するメッセージが画面に明示されている場合は、プロキシ以前のアカウント状態や契約プランを疑う段階に入ります。逆に、HTTP ステータスは返るが極端に遅い、一部の XHR だけ pending のままというパターンなら、本稿のドメイン束ねと DNS 校正の方が先に試す価値があります。

動画生成の Sora 向け記事は OpenAI 名の下でもメディア CDN の比重が高く、本稿はブラウザ上のエージェントと Slack などの B2B 連携に寄せています。用途が違えば載せるサフィックス集合も変わるため、購読ルールに丸ごと依存せずログドリブンで足す姿勢を共有します。

3. OpenAI 側で束ねたいドメインの出発点

ブラウザで ChatGPT を開く場合、会話 UI と設定まわりではchatgpt.com や chat.openai.com が目に付きます。アカウントや課金、開発者向けドキュメントでは openai.com や platform.openai.com が混ざることもあります。静的ファイルやスクリプトは oaistatic.com のような別サフィックスの CDNに逃がされることがあり、チャット用ドメインだけをプロキシに載せても読み込みが止まる典型原因になります。

Workspace Agents のようにバックグラウンドで追加の API 呼び出しが増える機能では、フロントのバンドル更新とあわせて新しいホスト名がログに現れやすいです。ルールを一度書いたら終わりではなく、数週間単位でネットワークタブを再点検する運用が現実的です。

ルールの評価順は ルールルーティング解説のとおり、細かい DOMAIN 行を広い MATCH や GEOIP より上に置きます。購読プロバイダの末尾に追記しただけでは先にマッチしてしまう広い行に飲まれることがある点に注意してください。

4. Slack：認証・API・添付と CDN の広がり

Slack はワークスペース URL（サブドメイン）と、グローバルな API ドメイン、ファイル配信や絵文字 CDNが組み合わさった名前空間です。代表的には slack.com、slack-edge.com、slack-files.com などが挙がりますが、Enterprise Grid やモバイルクライアント、サードパーティ連携を使うと追加のサブドメインがログに出ます。

ChatGPT 側から Slack へ戻る OAuth フローでは、短時間に複数ホストへリダイレクトが連鎖します。このとき途中のホストだけ別策略や DIRECT に落ちると、ブラウザでは「許可ボタンを押したはずなのに戻ってこない」ように見えます。OpenAI 用と Slack 用を別グループに分ける設計もありますが、切り分け初期は両方を同じ「コラボ用」グループにまとめる方が原因の分離が速いことがあります。

リアルタイム性の高い通信では UDP も絡みます。Discord 向けの UDP／TUN 記事と同様、TUN モードとノードの UDP サポートを確認してください。ただし Slack の REST と RTM／WebSocket の比率は環境差が大きいため、まずは HTTPS のホスト名を揃え、それでも欠けるときに UDP を疑う順が扱いやすいです。

5. mihomo ルール例：専用策略へ DOMAIN-SUFFIX を載せる

実務では 「ワークスペース＋コラボ」用の策略グループを一つ用意し、OpenAI 域と Slack 域のサフィックスをそこへ送る形が読みやすいです。以下は構造の例であり、プロキシ名や実在ホストは環境に合わせて置き換えてください。コメントは英語表記としています。

# proxy-groups: one group for workspace agents + Slack
proxy-groups:
  - name: WS_AGENT_COLLAB
    type: select
    proxies:
      - LOW_LATENCY
      - NODE_STABLE
      - DIRECT

# rules: keep specific DOMAIN rows above broad MATCH / GEOIP
rules:
  - DOMAIN-SUFFIX,openai.com,WS_AGENT_COLLAB
  - DOMAIN-SUFFIX,oaistatic.com,WS_AGENT_COLLAB
  - DOMAIN-SUFFIX,chatgpt.com,WS_AGENT_COLLAB
  - DOMAIN-SUFFIX,slack.com,WS_AGENT_COLLAB
  - DOMAIN-SUFFIX,slack-edge.com,WS_AGENT_COLLAB
  - DOMAIN-SUFFIX,slack-files.com,WS_AGENT_COLLAB
  - MATCH,PROXY

広すぎるサフィックスを安易に増やすと、国内向けの別サービスまで同じ出口に乗る副作用があります。ログに出た名前から必要最小限を足す方針を推奨します。また、url-test や fallback型の自動選択と併用する場合は、ワークスペース関連だけ select で固定し、その他は自動——といった二段構えにすると挙動が読みやすくなります。

設定の取り込み手順は サブスクリプション導入ガイドを参照しつつ、購読ルールとローカル追記の合成順に注意してください。GUI によっては「ルールファイルの読み込み順」が分かりにくいため、最終的にコアが解釈したルール一覧をログやダッシュボードで確認できるクライアントを使うと安全です。

6. DNS・fake-ip・Sniffer で「名前と出口」を一致させる

fake-ip モードでは、ローカルに返る IP が実体の名前と一対一で追跡できるよう設計されている一方、ブラウザや OS のスタブリゾルバとの組み合わせ次第でルール評価に使う文字列と実接続の見え方がズレることがあります。Sniffer（SNI）まわりの記事と併せ、HTTPS でどのホスト名が観測されたかをログに残す設定を確認してください。

DNS のフォールバックや複数アップストリームを使う場合、返答がレコード種別やキャッシュによってブレると、同じページでもリロードのたびに別ノードへ落ちるように見えることがあります。ワークスペースのエージェントのように複数リクエストの完了順序が重要な UI では、そのブレがスピナー長時間に直結します。

TUN とシステムプロキシの併用は TUN モード解説も参照し、ブラウザがどの経路でコアに到達しているかを一本化してください。特に企業端末では別製品のフィルタが DNS だけ握る構成があり、Clash 側の設定だけ整えても上位レイヤで上書きされることがあります。

7. 可復現の切り分け：ブラウザの開発者ツールとコアログ

次の順序が再現性高く試せます。（1）ブラウザの開発者ツールのネットワーク列で、スピナー中に pending のまま残るホスト名をメモする。（2）mihomo のログで、そのホストが どの策略にマッチしたかを突き合わせる。（3）意図した策略に入っているのに遅いなら、そのグループ内のノードを入れ替え、または遅延測定の間隔を調整する。（4）HTTP 4xx／5xx や明確な TLS アラートが出ているなら、経路以外の要因（セッション期限、管理者ポリシー、レート制限）を疑う。

メモしたホスト名は、OpenAI か Slack か、その他かに分類し、分類ごとにルール行を足すかどうかを決めます。「とりあえず全部 PROXY」より、ログに出たサフィックスだけを専用グループに載せる方が、後から国内サービスを壊しにくいです。

チームで検証するときは、同じ策略名・同じノードに揃えた端末同士で比較すると、個人設定の差分を早く潰せます。検証が終わったら、本番用と検証用でプロファイルを分けると運用が安全です。

長時間の読み込みは単一ホストの遅延だけでなく、複数ホストのうち最後のひとつが pendingという形でも起きます。ネットワーク列の「Waterfall」的な時間軸を見ると、どの名前がボトルネックかが掴みやすくなります。

8. まとめ

ChatGPT のワークスペースと Workspace Agents、Slack 連携のような複合シナリオでは、OpenAI 域と Slack 域のホストを意図した策略へ束ね、DNS・fake-ip・Snifferで名前と出口を一致させることが近道になりがちです。固定ノード迷信やアカウント封鎖一辺倒の説明とは角度が異なるため、症状に応じて既存の ChatGPT 記事と本稿を使い分けてください。

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