Notion・Figma・Miroを快適化するClash分割ルール設定術

Notion・Figma・Miroを同じ経路にしない理由

Notion、Figma、Miroは、どれも仕事で使うウェブサービスですが、通信の性格まで同じではありません。Notion はワークスペースのページ表示、画像やファイルの取得、検索、同期 API など複数のホストへ接続します。Figma は編集画面だけでなく、リアルタイムの共同編集、画像・フォント・プラグイン関連の CDN、WebSocket 接続を組み合わせます。Miro もボード本体、コメント、画像、テンプレート、共同編集用の長時間接続が分かれていることがあります。

そのため、三つのサービスを広い海外向けルールへ一括投入するだけでは、必ずしも快適になりません。国内の業務 SaaS、社内ポータル、オンラインストレージまで同じプロキシへ送ると、認証画面の表示が遅くなったり、ファイルアップロードの経路が遠回りになったりします。反対に、すべてを DIRECT にすると、特定の API や CDN だけがタイムアウトし、原因がサービス障害なのか Clash のルール不足なのか分かりにくくなります。

本稿の目的は「Notion、Figma、Miroに関係する通信だけを無条件に海外へ送る」ことではありません。まず自分の環境で実際に表示されたホストを観測し、必要な通信だけを用途別のポリシーグループへ振り分けます。国内サービスは原則として直接接続し、仕事用ツールは遅延と安定性を見ながら専用グループを選ぶ、という狭い分流が基本です。サービスの仕様変更によってホスト名が増えた場合も、ログを根拠に小さく追加できる構成を目指します。

専用グループと国内 DIRECT を分ける設計

最初からサービスごとに大量のグループを作ると、ノード選択の手間と設定ミスが増えます。まずは仕事用の通信を受ける WORK_APPS、国内サービスを受ける DIRECT、それ以外の一般通信を受ける既存のグループという三層に分けると、挙動を確認しやすくなります。Notion、Figma、Miroの三つを同じ出口で試し、Figma の共同編集だけ遅い場合に FIGMA_WORK を分離する、という順番が現実的です。

グループの種類は、普段の作業スタイルで選びます。複数の候補から自分で固定したい場合は select が向いています。接続確認用 URL の応答を見て自動的に低遅延の候補へ切り替えたい場合は url-test が候補になります。ただし、測定 URL が実際の Notion や Figma の API 品質を完全に表すわけではありません。自動選択に任せきりにせず、編集・同期・アップロードの体感を数分間確認してください。

仕事用ツールでは、単純な最短 ping だけよりも、接続の継続性と出口 IP の変化の少なさが大切です。Figma や Miro のような共同編集サービスは長時間の WebSocket 接続を使う場合があり、途中で出口が頻繁に変わると再接続や編集状態の更新が発生します。Notion でもログイン、ページ取得、ファイル同期が異なるタイミングで走るため、毎回別のノードへ切り替わる構成は安定性を下げることがあります。

YAML の概念例

次の断片は、実際の購読設定へそのまま貼り付ける完成品ではありません。利用しているノード名、コアのバージョン、既存グループの構造に合わせて書き換えてください。特に購読側が同名グループをすでに定義している場合は、重複した名前を作らないようにします。

proxy-groups:
  - name: WORK_APPS
    type: select
    proxies:
      - BEST_WORK
      - DIRECT

  - name: BEST_WORK
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    proxies:
      - Node-A
      - Node-B

rules:
  - DOMAIN-SUFFIX,notion.so,WORK_APPS
  - DOMAIN-SUFFIX,notion.site,WORK_APPS
  - DOMAIN-SUFFIX,figma.com,WORK_APPS
  - DOMAIN-SUFFIX,miro.com,WORK_APPS
  - DOMAIN-SUFFIX,社内サービス.example,DIRECT
  - MATCH,DEFAULT

DOMAIN-SUFFIX はサブドメインをまとめて扱えるため出発点として便利ですが、広すぎる指定には注意が必要です。たとえば Figma のすべての関連ホストが同一ドメイン配下にあるとは限らず、外部 CDN や認証基盤が別の名前で表示されることがあります。未知のホストを推測で追加するより、Clash の接続一覧で通信先、ポート、使用ルール、選択された策略を確認してから DOMAIN や DOMAIN-SUFFIX を加える方が安全です。

接続ログから不足ホストを見つける

設定を変更する前に、Clash Verge、Clash Verge Rev、Mihomo 系クライアントの接続画面を開き、対象サービスだけを短時間操作します。Notion ならログイン後にページを開き、画像を表示し、検索とページ移動を行います。Figma ならファイルを開いてズーム、コメント、簡単な編集、共有設定の確認まで進めます。Miro ではボードを開き、付箋の追加、画像表示、コメント、共同編集の状態を確認します。この操作を一つずつ行えば、どの段階で新しいホストが現れるか追跡できます。

見るべき項目は、単なるドメイン名だけではありません。接続時刻、プロトコル、ルール名、出口グループ、失敗理由を並べると、ページは表示できるのに同期だけ失敗するケースを分けられます。たとえば HTML は正常に取得できても、WebSocket の接続だけが別ルールで DIRECT に落ちているなら、画面は開くが共同編集が固まるという症状になります。逆に画像 CDN だけが遠いノードへ送られている場合は、編集操作よりアセット表示が遅く見えます。

ルールの追加は、次の順番で行うと変更履歴を管理しやすくなります。第一に公式サービスの主要ドメインを明示します。第二にログで再現した認証、API、WebSocket、ファイル配信のホストを一件ずつ追加します。第三に、追加後の接続が意図したグループへ入ったか確認します。最後に、数日使って問題がなければルール名とコメントを整理します。巨大なルールセットを一度に貼り付ける方法は、どの行が効いたのか分からなくなるため、仕事用の設定には向きません。

国内サービスを直接接続する範囲

分割ルールの効果を高めるには、プロキシへ送る対象を増やすより、直接接続する対象を明確にする方が重要です。国内の勤怠システム、社内ポータル、請求書サービス、国内ストレージ、ビデオ会議の地域エンドポイントなどは、組織のネットワーク要件が許すなら DIRECT を優先できます。ただし、ドメイン名だけで国内外を判断すると誤差が出ます。サービスが海外 CDN を使う場合や、社内 SSO が別地域の認証基盤を使う場合は、接続ログと業務上の要件を照合してください。

GEOIP,CN,DIRECT のような広域ルールは、国内向けの初期整理には便利ですが、IP データベースの更新時期や CDN の配置によって結果が変わります。また、ドメインルールより前に広い GEOIP ルールを置くと、必要な仕事用ドメインまで直接接続へ落ちる可能性があります。一般には、明示した Notion、Figma、Miro のルール、社内サービスの例外、地域判定、最後の MATCH という順番を意識します。

国内 DIRECT の確認では、速度だけでなく名前解決とログイン状態も見ます。DNS がプロキシ側で解決される構成と、OS 側で解決される構成では、同じドメインでも接続先が変わることがあります。DNS モードや fake-ip の設定を変更した直後は、古いキャッシュが残っている場合もあるため、ブラウザを再起動し、必要なら対象アプリのセッションを作り直してから比較してください。

ルール更新と複数端末での管理

SaaS は機能追加や CDN 移行によって接続先が変わります。一度動いたルールを永久に固定するのではなく、月に一度、またはサービスの障害や UI 変更があったタイミングで接続ログを見直します。更新時には、まず現在の YAML をバックアップし、変更した日付、目的、追加したドメイン、期待するグループをメモします。これだけで、後から購読更新によって設定が消えた場合にも復旧しやすくなります。

複数端末では、設定ファイルを丸ごとコピーするより、共通部分と端末固有部分を分ける方が扱いやすいです。ノード名やプロキシポート、TUN の有効化状態は OS とクライアントで異なります。一方、Notion、Figma、Miro のルールやグループの命名規則は共通化できます。共通ルールを別ファイルや管理用リポジトリで保管する場合も、購読 URL、認証情報、社内ドメイン一覧は含めないでください。

• Clash Verge：GUI で現在選択中のプロファイルと編集対象を確認し、購読更新後にローカル変更が残っているか確認する。
• Clash Verge Rev：プロファイルの差分と YAML の構文エラーを確認し、編集後に再読み込みして接続ログを見直す。
• Clash for Android：Wi-Fi とモバイル回線を分けてテストし、TUN とシステム VPN の競合を確認する。
• Mihomo：コアが対応するルール形式、DNS 動作、リモートプロバイダの更新結果をログで確認する。

設定を共有する際は、端末ごとの環境差を吸収するために「目的」「対象ドメイン」「利用グループ」「除外条件」を文章で残します。単にルール行だけを貼り付けると、別の端末で存在しないグループ名を参照したり、意図しない MATCH へ落ちたりします。変更後は Notion のページ同期、Figma の共同編集、Miro のボード更新、国内サービスのログインを短いチェックリストとして実行すると、設定の品質を一定に保てます。

Notion・Figma・Miroの分流では、すべてを一括転送する汎用 VPN や、画面上で自動選択だけを行う簡易クライアントでは、WebSocket の経路、国内サービスの除外、購読更新後の差分管理まで細かく扱いにくいことがあります。Clash V.CORE なら、接続ログを見ながら専用グループ、国内 DIRECT、DNS、複数端末向けのルールを段階的に調整でき、仕事用サービスだけを必要な経路へ寄せる運用を組み立てやすくなります。自分の環境で許可された範囲を確認しながら、この分割設定を試すなら、まずは ダウンロードページ から導入方法を確認してください。