Clashでリモートワークを快適にするZoom・Slack設定術

リモートワークでは、オンライン会議、社内チャット、ファイル共有、ブラウザー作業を同時に使うため、通信経路のわずかな不安定さが大きなストレスになります。Zoomの映像が一時停止したり、Slackの通知が遅れたりすると、会話のテンポだけでなく仕事全体の効率にも影響します。Clashを仕事用に調整すれば、ZoomやSlackなど必要なサービスだけを安定したプロキシ経路へ振り分け、普段利用する国内サイトや社内ネットワークは直接接続にできます。この記事では、ClashおよびMihomoでリモートワーク向けのルールを設計し、実際の接続を確認するまでの手順を解説します。

リモートワーク用の通信設計を先に決める

最初に重要なのは、すべての通信をプロキシへ送るのではなく、用途ごとに経路を分けることです。仕事中に必要なサービスは、会議、チャット、認証、ファイル共有など複数のドメインへ接続します。Zoomだけを1つのドメイン名で指定しても、ログイン、会議参加、音声、画面共有、アップデートで別のホスト名が使われる場合があります。そのため、公式に公開されているドメイン情報や、Clashの接続ログで実際に確認した宛先をもとにルールを作成します。

プロキシグループには、仕事用ノードだけを登録した Work のようなグループを用意すると便利です。通常のブラウジング用グループと分けておけば、会議中にノードを切り替えても、個人利用の通信設定へ影響しません。複数のノードがある場合は、安定性を重視するなら fallback、応答速度を重視するなら url-test が適しています。ただし、Zoomの会議中に頻繁な切り替えが起きると接続が再確立される可能性があるため、仕事用グループでは過度に短いテスト間隔を避けてください。

ZoomとSlackをルールで振り分ける

Clashのルールは上から順番に評価され、最初に一致したルールが適用されます。したがって、ZoomやSlackのルールを一般的な広告、地域、グローバルのルールより上に配置する必要があります。ルールの順番が低すぎると、先に GEOIP,CN,DIRECT や大きなルールプロバイダーに一致し、本来使いたい仕事用プロキシへ到達しません。

ドメインの末尾を基準にするサービスには DOMAIN-SUFFIX が適しています。サブドメインもまとめて対象にできるため、個別のホスト名を大量に記述せずに済みます。一方、ZoomやSlackは地域、機能、契約プランによって接続先が変わることがあります。設定後は必ず実際の接続一覧を確認し、見つかった追加ドメインをルールへ反映してください。

# 仕事用サービスを先に処理
rules:
  - DOMAIN-SUFFIX,zoom.us,Work
  - DOMAIN-SUFFIX,zoom.com,Work
  - DOMAIN-SUFFIX,slack.com,Work
  - DOMAIN-SUFFIX,slack-edge.com,Work
  - DOMAIN-SUFFIX,slack-msgs.com,Work

  # ローカル・社内ネットワークは直接接続
  - DOMAIN-SUFFIX,local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve

  # その他の国内通信と最終処理
  - GEOIP,CN,DIRECT
  - MATCH,Work

上の例にある Work は、実際の設定に存在するプロキシグループ名へ置き換えてください。グループ名に日本語や記号を使うこともできますが、設定ファイルの参照ミスを避けるため、短い英数字の名前にしておくと管理しやすくなります。また、社内VPNが特定のCIDR範囲を使用する場合は、そのアドレスを DIRECT のルールへ追加します。社内ネットワークの範囲を確認せずに広いIP帯を指定すると、外部サービスまで直接接続になるため注意が必要です。

Clashで実際に設定して動作を確認する

ここでは、既存の設定を壊さずに仕事用ルールを追加する流れを説明します。Clash Verge、Clash Verge Rev、Mihomoを利用している場合は、プロファイルの編集画面からYAMLを開きます。Clash for Windowsや他のクライアントでは、設定ファイルをバックアップしてから同様の項目を編集してください。

1. 現在使用しているプロファイルを複製し、remote-work.yaml など分かりやすい名前で保存します。
2. 複数のノードから、会議に使う候補を2台から3台選び、Work グループを作成します。
3. rules の上部へZoom、Slack、社内ネットワークのルールを追加します。
4. 設定を保存して読み込み直し、YAMLの構文エラーがないことを確認します。
5. Zoomを起動してテスト会議へ参加し、Slackでメッセージ送信とファイル表示を行います。
6. ダッシュボードのConnectionsや接続一覧を開き、実際の宛先と適用ルールを確認します。

動作確認では、単にアプリが起動したかだけでなく、用途別に確認することが大切です。Zoomでは会議参加後に音声、カメラ、画面共有を順番に試します。画面共有だけ失敗する場合は、メインの会議ドメインとは別のメディア関連ホストが使われている可能性があります。Slackではワークスペースへの接続、リアルタイム通知、画像やファイルのダウンロードを個別に試してください。

接続一覧には、宛先ドメイン、使用されたルール、プロキシグループ、転送量などが表示されます。ZoomやSlackの通信が MATCH に落ちていたり、意図しないグループへ送られていたりする場合は、実際のドメインを確認して専用ルールを追加します。ルール変更後は、既存の接続が古い経路を保持することがあるため、アプリを再起動するか、ダッシュボードから該当接続を閉じて再接続してください。

会議を安定させるための調整とトラブル対策

Zoomの映像が止まる場合、まずノードの遅延だけでなく、パケットロスとアップロード帯域を確認します。映像送信や画面共有では上り帯域が継続的に必要です。速度テストの瞬間値が高くても、数分間のパケットロスが発生するノードは会議に向きません。仕事用ノードを選ぶときは、会議を想定した時間帯にテストし、遅延のばらつき、再接続、音声の途切れを比較してください。

Slackの通知が遅れる場合は、WebSocket接続が正しく維持されているかを確認します。Slackのメッセージ同期や通知は通常のページ読み込みとは異なる長時間接続を使うため、プロキシグループの切り替え、接続タイムアウト、頻繁なDNS変更の影響を受けることがあります。ノードの自動切り替えが頻発する場合は、url-test の tolerance を適切に設定し、数ミリ秒の差だけでノードが変わらないようにします。

DNSについては、ドメインベースのルールを正しく適用できるよう、Clash側でDNS処理を有効にする構成が扱いやすいです。ただし、社内ドメインやプリンター、ファイルサーバーなどはローカルDNSが必要な場合があります。*.local や社内ドメインを無条件に外部DNSへ送るのではなく、社内環境の要件に合わせて fake-ip-filter や nameserver の設定を調整してください。

設定を安定運用するには、仕事用ルールを大きなルールセットへ無造作に混ぜないことも重要です。ZoomとSlackのように業務上必須のサービスは、専用のセクションやRule Providerとして分離すると、後から見直しやすくなります。毎月一度、接続ログとノードの状態を確認し、使われなくなったルール、重複したドメイン、失敗するノードを整理しましょう。必要な通信だけを適切な経路へ送る構成にすれば、会議の安定性を高めながら、通常のブラウジング速度とプライバシーも無理なく両立できます。