この記事で分かること
在宅勤務では、Zoom のビデオ会議とSlack のメッセージ・ファイル同期を同時に使う場面が少なくありません。ブラウザでの閲覧は問題ないのに、会議中だけ音声が途切れる、画面共有が数秒遅れる、Slack の通知や添付ファイルがなかなか表示されない、といった症状が出ると、仕事全体のテンポが崩れてしまいます。本稿では、Clash Verge Rev や Mihomo 系クライアントを前提に、リモートワークで使う Zoom と Slack を安定させるための設定を整理します。
ポイントは、すべての通信を無条件にプロキシへ送ることではありません。社内 VPN、社内ポータル、国内の業務サービスは DIRECTに残し、必要なクラウド接続だけを適切なポリシーへ振り分けます。さらに、Zoom のようなリアルタイム通信と、Slack のような HTTPS・WebSocket 通信では、重視すべき条件が異なります。遅延だけでなく、パケットロス、接続の持続性、ノードの混雑、DNS の一貫性まで確認することで、感覚だけに頼らない調整ができます。
なお、会社から支給された端末やネットワークでは、プロキシ、VPN、TUN、DNS の変更が禁止されている場合があります。社内規程や情報システム部門の指示がある場合は、それを優先してください。個人所有の端末でも、会議の録画や顧客情報を扱うときは、通信経路とログの扱いを事前に確認しておくと安心です。
Zoom と Slack で異なる安定性の条件
Zoom と Slack を同じ「仕事用アプリ」として一括設定すると、期待した結果にならないことがあります。Zoom の音声や映像は、短時間の遅延よりも継続的なパケットロスと経路の揺れに弱い通信です。会議開始時にはログインや会議情報の取得で HTTPS を使い、会議中は音声・映像・画面共有のために複数の接続を維持します。プロキシを通したことでログインは成功しても、会議中のメディア経路が別の場所へ出ていると、映像だけ止まることがあります。
一方、Slack はメッセージ取得、ファイルのダウンロード、画像プレビュー、通知、ワークスペースへの WebSocket 接続などを組み合わせます。メッセージが届かない場合は単純な速度不足だけでなく、長時間接続が途中で切れて再接続を繰り返している可能性があります。ファイル送信だけが失敗するなら、メッセージ用のホストとアップロード用の CDN が異なることも考えられます。
| 用途 | 優先したい条件 | 確認する症状 | 設定の考え方 |
|---|---|---|---|
| Zoom 音声 | 低遅延、低いパケットロス | 声の robot 化、音声の一時停止 | 混雑していない近距離ノードを優先 |
| Zoom 映像 | 安定した帯域、経路の一貫性 | 画面共有の遅延、映像の低画質化 | 頻繁な自動切り替えを避ける |
| Slack 通知 | WebSocket の持続性 | 通知がまとめて届く、再接続表示 | 関連ホストを同じポリシーへ揃える |
| Slack ファイル | 安定した HTTPS と十分な上り速度 | 添付ファイルだけ失敗する | ログに出た CDN のホストも確認 |
会議中にノードを自動選択で頻繁に切り替える設定も注意が必要です。速度テストの数値が高いノードでも、夕方の利用時間帯に混雑することがあります。まずは候補を二つか三つに絞り、同じ時間帯に短いテスト会議を行いましょう。数値上の最速より、音声が安定し、接続が途中で切れないノードのほうが実務には向いています。
Clash で仕事用の分流を設定する手順
ここでは、Clash Verge Rev の画面と Mihomo 系の一般的な設定項目を想定します。クライアントのバージョンによって表示名は少し異なりますが、考え方は共通しています。いきなり TUN を有効にするのではなく、まずシステムプロキシとルール分流で動作を確認してください。
-
プロファイルをバックアップする
現在使っている YAML プロファイルを複製し、仕事用として別名で保存します。元のプロファイルを直接編集すると、普段のブラウジング設定まで変わってしまいます。購読更新で手動ルールが上書きされる構成もあるため、変更した箇所をメモしておきましょう。
-
プロキシグループを確認する
仕事用には、固定ノードを一つ選べるグループと、複数候補から選べるグループを用意します。最初から「URL テストで最速」を常用すると、会議中の切り替えが発生する場合があります。会議の予定がある時間帯は、安定性を確認したノードを手動で固定するほうが安全です。
-
ルールを上から順に配置する
ルールは上から評価されるため、社内ネットワークやローカルアドレスの除外を先に置き、その後に Zoom、Slack 関連のルールを追加します。最後に残った通信を受ける MATCH の扱いも確認してください。業務サービスを意図せずプロキシへ送ると、認証やアクセス制御に影響することがあります。
-
システムプロキシを有効にする
Clash Verge Rev のシステムプロキシをオンにし、ブラウザと Slack デスクトップアプリをいったん終了してから起動し直します。アプリによっては起動時にプロキシ設定を読むため、設定変更後も古い接続を保持していると、変更が反映されたように見えないことがあります。
-
短いテストを実施する
Slack でメッセージ、画像、比較的大きなファイルを順番に送受信し、Zoom では音声、カメラ、画面共有を一つずつ確認します。Clash のログで対象ホストが想定したポリシーに一致しているかを見ながら、症状と時刻を記録してください。
設定例を作るときは、実際のログに表示されたホスト名を基準にします。サービスのドメイン構成はクライアント更新や地域によって変わるため、インターネット上の古いドメイン一覧をそのまま貼り付けるのは危険です。まずは必要な通信を一つずつ観察し、同じサービスに属する接続が DIRECT と PROXY に分かれていないかを調べます。
rules:
- DOMAIN-SUFFIX,zoom.us,Work-Proxy
- DOMAIN-SUFFIX,slack.com,Work-Proxy
- DOMAIN-SUFFIX,slack-edge.com,Work-Proxy
- DOMAIN-SUFFIX,example.corp,DIRECT
- GEOIP,LAN,DIRECT
- MATCH,Main-Policy上の例は考え方を示すためのもので、利用環境へそのまま追加する完成済みリストではありません。example.corp のような社内ドメインは実際の環境に置き換え、社内 DNS や VPN が必要なサービスは管理者の指定に従います。Zoom と Slack の通信をすべて一つのプロキシグループへ送る場合でも、接続が不安定なときはログ上のホスト単位で分けるほうが原因を見つけやすくなります。
遅延や切断が起きたときの切り分け
「Zoom が重い」「Slack が遅い」という感覚だけでは、ノード、Wi-Fi、DNS、アプリ、相手側の会議サーバーのどこに問題があるか判断できません。最初に、Clash をオフにした状態でも同じ症状が出るかを確認します。ただし会社のネットワーク規程がある場合は、勝手に接続方式を変えず、許可された検証方法を使ってください。
次に、発生時刻と症状を分けて記録します。Zoom なら「入室できない」「音声だけ途切れる」「画面共有だけ遅い」を分け、Slack なら「通知」「送信」「ファイル」「検索」「再接続」を別々に見ます。これらは同じサービス名でも異なる通信を使うため、すべてを一つの原因として扱うと、不要なルールを増やすことになります。
- Clash の接続ログで、失敗直前のホスト、ポリシー、接続方向を確認する。
- ノードを固定し、自動選択による経路変更を止めて再現性を作る。
- 別の Wi-Fi または有線接続で試し、家庭内無線の混雑を切り分ける。
- DNS の応答先が設定変更の前後で変わっていないか確認する。
- 会社の VPN がある場合は、Clash の TUN と同時に使わず、どちらか一方で検証する。
TUN は、アプリがシステムプロキシを読まない場合に有効な選択肢です。たとえば Slack の一部プロセスや補助サービスが環境変数を無視する場合、TUN によって OS のルーティング層から通信を捕捉できる可能性があります。しかし、TUN は便利な反面、社内 VPN、セキュリティソフト、Docker、仮想マシン、IPv6 と競合することがあります。TUN をオンにした途端に社内サイトが開けなくなったなら、機能を強制するのではなく、まずルートと除外設定を元に戻してください。
DNS を変更した後に Slack だけ接続が不安定になった場合は、キャッシュも確認します。アプリを終了しただけでは WebSocket の接続情報が残ることがあるため、再起動後にログイン状態、通知、ファイル転送の順で確認します。Zoom では会議中のノード変更を避け、いったん会議を終了してからノードを切り替えるほうが、古い接続と新しい接続が混在しにくくなります。
また、速度テストの結果をそのまま品質と考えないことも重要です。下り速度が十分でも、上りの遅延やパケットロスが大きければ、画面共有や音声は不安定になります。平日の朝、昼休み、夕方など利用者が増える時間帯に、同じノードで短いテストを行い、平均遅延だけでなく接続の揺れと切断回数を比べてください。
在宅勤務で安定性を保つ運用のコツ
一度動いた設定を放置するより、変更を少なくして再現性を保つことが重要です。購読更新のたびにノード名やグループ構成が変わる場合は、更新後に仕事用プロファイルを確認し、ポリシー名が消えていないかを見ます。ルールの編集機能があるクライアントでは、購読プロファイル本体とローカルオーバーライドを分けて管理すると、更新時の復旧が容易になります。
会議用ノードは「最も速いもの」ではなく、「同じ時間帯に安定して使えるもの」を選びます。予備ノードを一つ用意し、切り替え後に Zoom の再接続と Slack の通知を確認する手順を決めておくと、障害時の判断が速くなります。ただし会議中に何度も切り替えると、音声や映像のセッションが再構築されるため、短時間で直らない場合は会議のチャットや電話など、会社が認める代替手段も考えておきましょう。
セキュリティ面では、認証情報や顧客データを含む通信を、出所の分からないノードへ送らないことが基本です。無料ノードや公開プロキシは、速度だけでなく運営者、ログ方針、暗号化の扱いが確認できないことがあります。勤務先のデータ保護規程で許可された経路を使い、必要以上に TUN で全通信を捕捉しないようにします。国内サイトや社内システムを DIRECT にする設計は、速度面だけでなく、業務アクセスの範囲を分かりやすく保つ意味でも役立ちます。
Clash のログは原因調査に便利ですが、画面共有中に機密性のあるホスト名や URL が表示される可能性があります。スクリーンショットをサポートへ送るときは、トークン、ユーザー ID、社内ドメイン、ファイル名などをマスキングしてください。設定ファイルを共有する場合も、購読 URL、認証情報、秘密鍵が含まれていないかを必ず確認します。
専用の VPN アプリは導入が簡単でも、アプリ単位の分流や細かなログ確認ができず、国内サービスまで一律に遠回りすることがあります。別のプロキシクライアントでは、設定項目が少ない代わりに WebSocket、TUN、DNS の挙動を個別に調整しにくい場合もあります。相比之下、Clash は Zoom と Slack をログで分けて確認し、国内サイトを DIRECT に残しながら、必要な通信だけを選んだノードへ送れるため、在宅勤務の「会議は安定、普段の業務サイトは高速」という構成を組み立てやすいのが利点です。