はじめに
リモートワークでは、ビデオ会議の音声や映像、チャット、ファイル共有など、複数の通信を同時に安定させる必要があります。特に Zoom は低遅延の音声・映像通信を使用し、Slack はメッセージだけでなく画像、ファイル、外部連携サービスにも接続するため、単純に「回線速度が速い」だけでは快適に利用できないことがあります。
Clash を使うと、アプリケーションやドメインごとに通信経路を分けられます。たとえば、Zoom と Slack の必要な通信だけを安定したプロキシグループへ振り分け、国内の業務サイトや社内システムは DIRECT で接続する構成です。すべての通信を一つのノードへ流すよりも、遅延や混雑の影響を抑えやすくなります。
この記事の目標
Zoom 会議の安定性と Slack の応答性を高めながら、国内通信の速度と社内サービスへの到達性を維持することを目指します。
まず確認したい通信の特徴
設定を始める前に、問題が本当に Clash で解決できる種類のものかを確認しましょう。Wi-Fi の電波が弱い、家庭内で大容量の動画を同時に再生している、ルーターの負荷が高いといった原因は、ルールを変更しても改善しません。会議中だけ遅くなるのか、特定のサービスだけ接続しにくいのかを切り分けることが重要です。
| 通信 | 重視する指標 | 基本方針 |
|---|---|---|
| Zoom の音声・映像 | 遅延、ジッター、パケットロス | 低遅延で UDP 対応の経路を優先 |
| Slack のメッセージ | 接続開始時間、再接続の少なさ | 安定したノードへ振り分け |
| Slack の画像・ファイル | 転送速度、接続の安定性 | 混雑しにくい経路を使用 |
| 国内サイト・社内 VPN | 到達性、遅延、アクセス制御 | 原則として DIRECT |
Zoom は会議の種類やクライアントのバージョンによって利用する接続先が変わる場合があります。また、Slack もワークスペース、ファイル配信、通知、アプリ連携で複数のドメインを使用します。そのため、最初から過度に広いキーワードルールを作るのではなく、ログで実際の接続先を確認しながら追加してください。
業務ネットワークの注意
会社が指定する VPN、認証システム、端末管理ツールは、勝手にプロキシ経由へ変更しないでください。社内規定、情報システム部門の指示、顧客データの取り扱いを優先しましょう。
1ノードとプロキシグループを選ぶ
Zoom と Slack のために重要なのは、表示上の速度よりも、会議時間中の安定性です。Clash の遅延テストが短くても、夕方に混雑したり、UDP が利用できなかったりすると、音声が途切れる原因になります。複数の地域や事業者のノードを用意し、実際の会議環境で比較してください。
- 遅延： 数値が低いほど有利ですが、単発の測定値ではなく、時間帯ごとの変動も確認します。
- パケットロス： 音声や映像では速度よりも重要です。短いテストだけでなく、実際の会議で確認してください。
- UDP 対応： Zoom の通信で UDP を利用する構成では、プロバイダーとノードが UDP 転送に対応している必要があります。
- 帯域と混雑： 利用者が多い共有ノードは、ファイル転送や会議が重なる時間帯に品質が低下しやすくなります。
- 信頼性： 無料ノードや出所が不明な設定は、認証情報や業務データの安全性を確認できないため避けます。
プロキシグループには、たとえば Work や Work-Asia のような分かりやすい名前を付けます。自動選択だけに任せると、会議の途中でノードが切り替わることがあります。重要な会議では、事前に動作確認したノードを手動で固定し、予備ノードを別に用意しておくと安心です。
2Clash に分流ルールを設定する
ここでは Mihomo コアを使用する Clash Verge Rev などを想定し、業務用グループへ Zoom と Slack の通信を振り分ける例を紹介します。設定画面の名称や Merge の対応状況はクライアントによって異なるため、作業前にプロファイルをバックアップしてください。
業務用グループを作成する
既存のプロキシ名はプロバイダーごとに異なるため、下記のグループ名は例です。実際には、自分の設定ファイルに存在するプロキシ名へ置き換えてください。
この例では、Zoom と Slack の代表的なドメインを Work へ送っています。ドメイン一覧はサービスの仕様変更で変わる可能性があるため、接続ログに表示されたホスト名と、勤務先のネットワークポリシーを照合してください。ワイルドカードを広く指定しすぎると、関係のない通信までプロキシに入り、速度低下や社内サービスの不具合につながります。
設定のポイント
ルールは上から順番に評価されます。Zoom や Slack のルールを広い DOMAIN-KEYWORD や MATCH より上に置き、意図したグループへ確実に到達させてください。
システムプロキシと TUN を使い分ける
ブラウザーや通常のデスクトップアプリだけを対象にするなら、まずは System Proxy を有効にして動作を確認します。Zoom の補助プロセス、Slack の自動更新、他の業務アプリまで同じルールで扱いたい場合は、クライアントの権限と社内ポリシーを確認したうえで TUN Mode を検討します。
TUN モードはシステム全体の通信を仮想インターフェースで受け取るため、システムプロキシに対応していないアプリも対象にできます。一方で、社内 VPN、プリンター、ファイルサーバー、オンライン会議用の UDP 通信と競合することがあります。問題が起きた場合は、TUN をいきなり常用せず、対象アプリ、DNS、ルート設定を一つずつ確認してください。
3DNS と会議前の動作確認
接続先の名前解決が不安定だと、Zoom の会議参加や Slack のワークスペース読み込みに時間がかかります。Mihomo の DNS を有効にする場合は、使用するモードと社内ドメインの扱いを明確にしてください。社内 DNS が必要な環境で外部 DNS へ置き換えると、社内サービスが見つからなくなることがあります。
fake-ip は多くのアプリで便利ですが、社内システムや特殊な認証、ゲーム・会議機器などで互換性の問題が出ることがあります。問題があるドメインは fake-ip-filter に追加し、必要に応じて redir-host を試してください。設定を変更した後は DNS キャッシュを消去し、Clash を再起動してから再テストします。
実際の会議で確認する項目
- 会議開始前にノードを選択し、Clash の接続ログで Zoom と Slack が
Workグループへ入っているか確認します。 - Zoom のテスト会議で、音声、カメラ、画面共有をそれぞれ数分間試します。
- Slack でメッセージ、画像、ファイル、スレッド、通知が正常に動作するか確認します。
- 社内 VPN、勤怠システム、クラウドストレージなど、業務に必要な国内サービスへアクセスします。
- 会議中にノードの自動切り替えが発生していないか、切断や再接続の記録を確認します。
会議の品質が悪い場合は、最初に Wi-Fi から有線接続へ切り替え、他の端末の大容量通信を止めます。それでも改善しなければ、別のノード、別の地域、別の DNS モードを順番に試します。複数の設定を同時に変更すると原因が分からなくなるため、変更内容と結果を簡単に記録しておくと復旧が早くなります。
4安全に運用するための保守
リモートワークの通信には、会議内容、顧客情報、社内ファイルのやり取りが含まれます。Clash の利便性だけでなく、サブスクリプションの提供元、ノードの運営者、ログの取り扱い、会社の利用規程を確認してください。信頼できないプロファイルを読み込んだり、内容を理解しないまま外部のルールを Merge したりするのは危険です。
- プロファイルを定期的に更新： 更新後はルールの差分を確認し、不要な設定や知らない外部ドメインが追加されていないか点検します。
- 設定をバックアップ： 正常に動作した YAML とクライアント設定を保存し、変更前の状態へ戻せるようにします。
- 業務時間外に検証： 重要な会議の直前に新しいコアやルールを導入せず、余裕のある時間にテストします。
- 不要時は停止： 会社のネットワークや金融サービスなど、プロキシを通さないほうがよい通信では System Proxy や TUN を確認します。
- 障害時の代替手段を用意： 予備ノード、スマートフォンのテザリング、ブラウザー版 Slack など、業務を止めない方法を準備します。
最終的な理想は、何でもプロキシへ送ることではありません。Zoom と Slack のように安定性が必要な通信、社内システムのように直接接続が必要な通信、検証対象外の通信を分け、それぞれを定期的に見直すことです。小さく設定してログと実際の利用感を確認すれば、Clash は日常業務に合わせた柔軟なネットワーク管理ツールとして活用できます。