在宅勤務のClash設定術｜Zoom・Slack・Meetを快適に使う方法

在宅勤務で Zoom・Slack だけ不安定になる理由

在宅勤務の通信トラブルは、「インターネット全体が遅い」というより、特定の仕事用サービスだけが別の経路へ流れていることが原因になりがちです。たとえばブラウザでニュースは普通に開けるのに、Zoom の会議中だけ音声が途切れる、Slack のメッセージ送信が数秒遅れる、Google Meet の画面共有だけが頻繁に止まる、といった症状です。

Clash を使っている環境では、購読プロファイルのルール、システムプロキシ、TUN モード、DNS の応答経路が組み合わさり、アプリごとに異なる結果になることがあります。Web ブラウザはシステムプロキシを参照していても、Zoom のデスクトップアプリや Slack のバックグラウンドプロセスは同じ方法でプロキシを継承するとは限りません。そのため、ブラウザ上の Web 版 Meet は正常なのに、ネイティブアプリの音声だけが不安定になることがあります。

仕事用の通信をすべて同じノードへ送れば解決するとは限りません。ビデオ会議では、最大速度よりも遅延の揺れ、パケットロス、UDP の扱いが重要です。一方、Slack のファイルプレビューやアプリ更新では、安定した HTTPS 接続と CDN への到達性が重視されます。さらに、国内の社内ポータルや勤怠システムまで海外経由にすると、かえって遅くなったり、ログイン判定で問題が起きたりします。

仕事用サービスを分ける設計とルールの考え方

在宅勤務向けの分流は、サービス名だけで大きく一括するより、会議、チャット、ファイル、国内サービスという通信の目的で分けると管理しやすくなります。Zoom の場合はミーティング本体、ログイン、設定情報、更新処理が完全に同じホストへ集約されているとは限りません。Meet も Google アカウントの認証と会議メディアの通信が別の接続として現れる場合があります。

まず自分の接続ログから実際に現れたドメインを確認し、必要なものだけを明示的なルールへ追加します。未知のホストを検索結果から大量にコピーする方法は、将来の仕様変更で誤判定を増やします。サービス側のドメインが変更されたときは、会議が始まらない、ログインだけ失敗する、画面共有だけ止まる、といった症状の違いから不足している層を推測できます。

例として、会議用の出口を WORK_MEETING、チャットと業務 SaaS 用を WORK_APPS、国内通信を DIRECT とします。名前は任意ですが、同じグループにすべて詰め込まず、ノードを選ぶ目的を分けておくことが重要です。会議用グループでは、短時間の速度測定だけでなく、実際の通話中に遅延が安定するノードを優先してください。

MATCH を広いルールとして最後に置くことも忘れないでください。先頭側に広すぎる GEOIP や大規模なルールセットがあると、意図した仕事用ドメインへ到達する前に別のポリシーへ吸収されることがあります。Clash は上から順番に評価し、最初に一致したルールを使うため、ルールの正しさだけでなく並び順が結果を決めます。

Clash で在宅勤務用の分流を作る手順

ここでは、購読プロファイルを直接書き換えず、ローカルオーバーライドまたは自分で管理できる YAML に設定を追加する流れを説明します。購読が更新されるたびに本文へ直接追記した内容が消える構成では、原因を再現できません。最初に現在のプロファイルをバックアップし、どのファイルが実際に有効なのかを GUI のプロファイル画面で確認してください。

1. 現在のモードを確認する：まず Rule モードになっているかを確認します。Global モードではルールの分流結果を検証できず、Direct モードではすべてが直結するため、今回の目的と一致しません。
2. システムプロキシと TUN を整理する：ブラウザだけを対象にするならシステムプロキシで足りますが、Zoom や Slack のようなアプリも同じ経路へ乗せたい場合は、クライアントの対応状況を確認したうえで TUN を検討します。TUN を有効にする場合は、管理者権限、仮想ネットワークアダプター、他の VPN との競合を確認してください。
3. 仕事用グループを用意する：会議用と業務アプリ用でプロキシグループを分けます。会議中にノードを変更すると接続が再確立されることがあるため、勤務開始前に安定したノードを選んでおきます。
4. 観測したドメインを追加する：接続ログに表示されたホストだけを DOMAIN または DOMAIN-SUFFIX で登録します。サービス全体を推測して無関係なドメインまで追加するのではなく、ログイン、会議、ファイル取得の単位で少しずつ追加します。
5. DNS の結果を確認する：DNS が別の場所で解決されると、ルール上は正しくても想定外の IP や CDN に接続する場合があります。Fake-IP、Redir-Host、TUN の DNS 設定はクライアントとコアの仕様に合わせ、変更後は Clash を再起動して比較します。
6. 短いテストを繰り返す：会議へ入る前に Slack の送受信、Zoom のテストミーティング、Meet のマイク確認、画面共有の開始を順番に試します。一度に多くの設定を変更せず、ひとつずつログと体感を比較してください。

概念的なルール断片は次のようになります。実際のドメインは、契約しているサービス、組織のネットワーク方針、Clash のコア仕様に合わせて置き換えてください。存在を確認していないホスト名を追加しても、分流の品質は上がりません。

Illustrative work-from-home rules — replace domains with observed hosts

proxy-groups:
  - name: WORK_MEETING
    type: select
    proxies:
      - Stable-Node
      - DIRECT

  - name: WORK_APPS
    type: select
    proxies:
      - Stable-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,zoom.us,WORK_MEETING
  - DOMAIN-SUFFIX,zoom.com,WORK_MEETING
  - DOMAIN-SUFFIX,slack.com,WORK_APPS
  - DOMAIN-SUFFIX,google.com,WORK_MEETING
  - DOMAIN-SUFFIX,社内ドメイン,DIRECT
  - MATCH,FINAL

上の例は考え方を示すための雛型です。Zoom や Meet のメディア通信が必ず HTTPS のドメインルールだけで完全に制御できるとは限らず、UDP、QUIC、OS のファイアウォール、ルーターの QoS が影響することもあります。音声だけが途切れる場合は、ノード変更だけでなく Wi-Fi の混雑、2.4GHz 帯の干渉、家庭内の大容量アップロード、ルーターのバッファブロートも調べてください。

会議中の検証と、症状別の調整方法

設定を反映したら、まず接続ログで対象ドメインが意図したグループへ入っているか確認します。次に Zoom または Meet のテスト機能で、音声入力、音声出力、カメラ、画面共有を別々に確認します。すべてを一度に試すと、どの処理で問題が起きたのか分からなくなります。Slack では通常のメッセージ、画像添付、ファイルダウンロード、通知の再接続を順番に確認すると、チャット本体と CDN の差を見つけやすくなります。

音声が数秒ごとに途切れる場合は、平均速度よりもパケットロスとジッターを優先します。別ノードへ切り替えて改善するなら出口の品質が疑われますが、どのノードでも同じなら家庭回線、Wi-Fi、TUN の UDP 処理を調査します。画面共有だけ止まる場合は、共有データの経路、帯域上限、GPU エンコード、ブラウザ版とアプリ版の違いを比較します。

Slack の通知だけ遅れる場合は、WebSocket の長時間接続が再接続を繰り返していないかを見ます。メッセージ送信は成功するのに通知が来ないなら、チャット本体ではなくプッシュ通知やバックグラウンド通信が別ルールへ落ちている可能性があります。アプリを終了して再起動する前に、Clash の接続ログを保存しておくと、同じ現象を再現したときに比較できます。

日常運用では、仕事開始前に会議用グループを固定し、勤務後に必要なら普段使いのグループへ戻す方法が安全です。自動選択グループを使う場合も、測定 URL の応答時間だけで最適な会議ノードが決まるわけではありません。定例会議の時間帯に実際の音声品質を確認し、ノード変更の履歴と症状を簡単に記録すると、単なる思い込みで設定を増やさずに済みます。

ブラウザ拡張だけで対応する方法は手軽ですが、Zoom や Slack のネイティブアプリ、バックグラウンド通知、UDP ベースの会議通信まで一貫して扱えないことがあります。一般的な VPN は全通信を一括で送るため、社内ポータルや国内サービスまで遠回りになり、仕事用と私用の経路を細かく分けにくい場合があります。その点、Clash V.CORE はルール単位の分流、接続ログによる確認、TUN とシステムプロキシの使い分け、サービスごとのポリシーグループをまとめて管理できるため、Zoom・Slack・Meet の症状を個別に検証しながら在宅勤務の通信を整えられます。環境に合う構成を落ち着いて試したい方は、対応クライアントと最新版を確認できるダウンロードページから始めてください。