ClashでNotion・Figma・Miroを快適化する仕事用設定ガイド

Notion・Figma・Miroを同じルールで扱わない理由

Notionで議事録やデータベースを整理し、Figmaでデザインを編集し、Miroでオンライン会議のボードを共有する働き方では、すべての通信を同じ出口へ送る設定が必ずしも快適とは限りません。サービスごとに利用するドメイン、認証方式、静的アセットの配信元、リアルタイム通信の仕組みが異なるためです。Notionはワークスペースの読み込みやログインに複数のホストを使い、Figmaはデザインデータだけでなく画像・フォント・コメント・共同編集用の接続を扱います。Miroもボード本体とファイル配信、通知、共同編集のための通信が分かれることがあります。

そこで本稿では、Clashの分割ルーティングを仕事用ワークフローに合わせ、必要なサービスだけをプロキシ経由へまとめる考え方を紹介します。目的は「海外サービスをすべてプロキシへ送る」ことではありません。業務で使うNotion・Figma・Miroの通信を安定したグループへ集約し、それ以外の国内サイト、社内ポータル、一般的な検索や動画サービスはDIRECTに残して、速度とトラブルの少なさを両立することです。

なお、サービス側のドメイン構成は更新されます。古いブログ記事に掲載されたドメイン一覧をそのまま貼り付けるのではなく、ClashのConnectionsやブラウザの開発者ツールで実際に接続先を観測し、必要最小限のルールを追加してください。特にFigmaやMiroのようなSaaSは、ログイン画面だけ確認して「設定完了」と判断すると、編集画面を開いた段階で別のCDNやWebSocket接続がDIRECTへ落ちることがあります。

仕事用ポリシーグループと分割ルーティングの設計

まずプロキシグループを、業務サービス向けと通常閲覧向けに分けます。たとえば購読設定に複数ノードがある場合、Notion・Figma・Miroを送る親グループとして WORK_APPS を用意し、通常の海外サイトには既存の PROXY、国内サイトには DIRECT を使う構成です。WORK_APPS は手動選択の select でもよいですが、作業時間帯にノード品質が変わりやすい環境では url-test や fallback を選択肢に入れられます。

ただし、業務サービスのログイン状態や共同編集セッションでは、頻繁に出口IPが変わると再認証を求められたり、セキュリティ確認が増えたりすることがあります。速度測定だけで最速ノードを選ぶより、長時間の作業で接続が安定するノードを優先してください。特にFigmaの編集中にノードが切り替わると、画面上は操作できても保存やコメント送信が遅延する場合があります。最初は固定した一つのグループで動作を確認し、その後に自動選択へ移すと原因を追いやすくなります。

ルールの順序も重要です。Clashは通常、上から順番に評価し、最初に一致したルールのポリシーを採用します。広い地域ルール、広告ブロック、GEOIP、最後の MATCH が先に処理される構成では、仕事用ドメインを追加しても意図したグループへ届きません。Notion・Figma・Miroに関する明示的なルールは、広い GEOIP や MATCH より上へ置き、例外としてDIRECTにする社内ドメインはさらに上へ置く、という順番が読みやすい構成です。

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

rules:
  - DOMAIN-SUFFIX,notion.so,WORK_APPS
  - DOMAIN-SUFFIX,figma.com,WORK_APPS
  - DOMAIN-SUFFIX,miro.com,WORK_APPS
  - DOMAIN-SUFFIX,your-company.example,DIRECT
  - MATCH,PROXY

上の断片は考え方を示す最小例です。実際の購読設定には既存のプロキシ名、ルールプロバイダ、DNS設定、他のポリシーグループがあります。そのため YOUR_STABLE_NODE を実際の名前へ置き換え、同じ名前のグループを二重に作らないようにしてください。YAMLを編集した後は、インデント、グループ名の綴り、ルールの重複を確認し、Clashの設定検証を通してから再読み込みします。

Notion・Figma・Miroを観測してルールを追加する手順

Notionから始める場合は、まずワークスペースへログインし、ページの読み込み、検索、ファイル添付、コメント投稿を順番に行います。ログインだけでなく、データベースの絞り込みや画像プレビューまで試すのがポイントです。表示された接続先を見て、基本ドメインが安定しているか、画像やファイルが別のホストへ出ているかを確認します。すべての関連ドメインを一気に登録するのではなく、DIRECTで失敗した通信だけを記録し、必要なものを段階的に DOMAIN または DOMAIN-SUFFIX で追加してください。

Figmaでは、ファイル一覧を開く、デザインファイルを編集する、画像を配置する、コメントを追加する、共同編集者のカーソルを見る、という順番で確認します。静的なファイル一覧は表示できても、編集画面の保存やコメントだけが遅い場合は、リアルタイム接続またはアセット配信のホストが別ルールへ落ちている可能性があります。ブラウザのネットワークログで websocket に相当する接続が見える場合は、Clashのライブ接続でも同じ時間帯の接続を照合してください。ルールを追加した後は、すでに開いているタブを再読み込みし、保存状態が正常に戻るか確認します。

Miroはボードの表示、付箋の追加、画像の貼り付け、参加者のカーソル、コメントや投票など、複数の通信を同時に使うサービスです。ボードは開くのに編集内容が反映されない、参加者の更新だけ遅れる、画像だけ空白になる、といった症状は、単純なDNS障害ではなく通信層の分割が不完全なときにも起きます。ボードを開いた瞬間と、付箋を追加して保存された瞬間を分けて観測し、どのホストがどのポリシーへ入ったかを比較すると、必要なルールを絞れます。

DOMAINとDOMAIN-SUFFIXの使い分け

特定のホストだけを仕事用グループへ送りたい場合は DOMAIN,example.com,WORK_APPS のように対象を限定します。サブドメインの増減をまとめて扱いたい場合は DOMAIN-SUFFIX,example.com,WORK_APPS が便利ですが、同じサフィックスを使う別用途のホストまで含まれる可能性があります。ルールを広く書くほど管理は楽になる一方、国内向けの静的配信や規約ページまでプロキシへ送られ、速度やアクセス判定に影響することがあります。迷った場合は、まず DOMAIN で狭く始め、接続ログに同じサフィックスの未処理ホストが複数現れたときだけ範囲を広げてください。

DNSモードを変更した直後は、ブラウザやOSのキャッシュが残っていることもあります。ルールを変更したのに動作が変わらない場合は、Clashの設定を再読み込みし、対象タブを閉じて開き直します。それでも改善しないときは、DNSの応答、TLSエラー、タイムアウト、ポリシー選択の四つを別々に確認します。「ページが開かない」という一つの症状に対して、毎回ノードを入れ替えるだけでは原因が隠れるためです。

業務中の遅延と切断を切り分ける実践チェック

Notionの文章編集だけが遅い場合、ページ本体ではなく画像、埋め込み、外部プレビューの取得が待ち時間を作っていることがあります。Figmaの保存が遅い場合は、ノードの混雑だけでなく、WebSocketの再接続や出口IPの変更を疑います。Miroの共同編集が止まる場合は、ボード本体とリアルタイム更新の経路が異なる可能性があります。このように、サービス単位で「使えない」と決めつけず、表示・編集・保存・共同更新の段階へ分解してください。

仕事用グループのノードを変更するときは、三つのサービスを同時に開いたまま切り替えない方が安全です。まずNotionの短いページで読み書き、次にFigmaで小さな変更を保存し、最後にMiroで付箋を一つ追加して同期を確認します。各テストの前後でClashの接続ログを保存すると、ノード変更によってどのホストの遅延が改善したかを比較できます。会社のSSOや多要素認証がある場合は、認証画面だけを何度も繰り返さず、管理者が定めた再認証手順に従ってください。

• ログインだけ失敗：認証ホスト、ブラウザのシステムプロキシ、Cookie、企業SSOの経路を確認します。
• ページやボードは表示される：保存、コメント、共同編集用の接続が別ポリシーへ落ちていないか確認します。
• 画像や添付ファイルだけ遅い：CDNやオブジェクトストレージのホストをライブ接続から特定します。
• 国内サイトまで遅い：広すぎるサフィックスやグローバルプロキシ設定を見直し、DIRECTの例外を上位へ置きます。
• 設定変更後に全体が不安定：ルールのインデント、グループ名、DNS、TUNとシステムプロキシの重複を確認します。

最後に、Clash for Windowsの古い設定画面や単純なブラウザ拡張だけでNotion・Figma・Miroを管理すると、アプリごとの経路差、WebSocket、TUN、DNSの状態を一画面で追いにくく、トラブル時に設定の所在が分からなくなりがちです。Clash V.COREなら、Mihomo系コアを利用したルール分流、接続ログによるホスト単位の観測、TUNとシステムプロキシの切り替えを仕事用に整理しやすく、必要なSaaSだけを安定したポリシーへまとめられます。Notionの整理、Figmaの編集、Miroの会議を日常的に使うなら、まず現在の構成をバックアップしてから、Clash V.COREのダウンロードページで自分の環境に合うクライアントを確認してみてください。