設計ツールの通信はなぜ「一律出口」に弱いか

Figma の Web クライアントは figma.com の HTML を取ったあと、別サブドメインの API、静的アセット用ホスト、リアルタイム協調用の WebSocket 相当の接続、埋め込みプレビューやサンドボックス用ドメインへ短時間に分散します。Adobe 側も Creative Cloud デスクトップ／ブラウザ管理画面が adobe.com 系だけで完結せず、Adobe IMS（Identity Management） でのサインイン、adobe.io 配下の API、フォント同期の typekit.net／use.typekit.net、地域やプロダクトで変わる CDN エッジまで含めると、ブラウザの開発者ツールを開くと一画面で十数〜数十ホストが並ぶのが普通です。

ここでメイン UI だけ低遅延ノード、静的 CDN だけ別ノード、認証だけ直進、といった部分的分流が起きると、画面上は「くるくる」したまま進まない・コンポーネントだけ読み込めない・フォントがフォールバックのまま、といった部分的成功に見えます。Clash は接続単位でポリシーを選べるため、設計ツール用に明示的な束を切り、ルール分流のベストプラクティス に沿って広い GEOIP や MATCH より前へ置くと、再現性が上がります。同じ「CDN が絡む SaaS」でも、Google API と gstatic 束のような別エコシステムとホスト名は重ならないため、記事どうしを混ぜないでください。

デスクトップの Creative Cloud アプリはブラウザより OS のルーティングや独自の TLS クライアント挙動の影響を受けやすく、TUN 対応クライアントの選び方も合わせて確認すると、取りこぼしの切り分けが速くなります。

典型症状と観測のコツ

代表的には次のようなパターンがあります。(1) Figma のタブは開くがキャンバスが白いまま、左ペインだけ出る。(2) コメントやインスペクトは見えるが特定ページだけ永遠にロード。(3) Creative Cloud でフォント同期やストック素材のサムネイルだけ失敗。(4) ブラウザではログインできるがデスクトップアプリだけサインインループ。Chrome／Edge／Firefox で差が出るときは拡張ブロッカーやブラウザのセキュア DNS（DoH）も疑います。

ℹ 観測のコツ：失敗した瞬間のホスト名をライブ接続ログに残し、(a) 認証 IMS／OAuth 系、(b) 本体 API、(c) 静的・CDN、(d) フォント・タイプキット、のどれかに分類します。TLS が張る前に切れるなら経路・SNI、握手後に止まるなら HTTP レイヤや HTTP/2 を疑い、接続ログと TLS タイムアウト の整理と突き合わせると早いです。

Figma 側：本体・プレビュー・静的ホストの束ね方

公式ドキュメントや実測では時期で増減するため、固定リストの丸写しより自分の環境で出た FQDN をログに追記する運用が安全です。出発点のイメージとして、DOMAIN-SUFFIX,figma.com と DOMAIN-SUFFIX,figma.site（埋め込みや一部プレビューで触れることがあるホスト群）を同一の DESIGN_TOOLS 向けポリシーへ載せ、www.figma.com 単体だけ拾うような狭いルールに寄せすぎないようにします。社内でカスタムプロキシやゼロトラストクライアントと併用している場合、ブラウザとデスクトップ版 Figma で別プロセスになるため、プロセス別の挙動も頭に置いてください。

サードパーティ製の広告ブロック用ルールセットが figma.com 配下のテレメトリや解析ドメインを先に REJECT していると、本体は動くのに特定機能だけ沈黙、という形にもなり得ます。意図しない先行マッチがないか、ルール順を棚卸ししてください。

Adobe／Creative Cloud 側：IMS・API・フォント CDN

Creative Cloud は adobe.com のページ表示だけでなく、Adobe IMS 系（例：adobelogin.com、地域プレフィックス付き IMS ホスト）、services.adobe.com 周辺の認可フロー、adobe.io の API、CC デスクトップが参照するアップデート／ライセンス確認用ホスト、さらに typekit.net や use.typekit.net などのフォント配信までが連鎖します。ここが別出口に割れると「アプリは起動するが同期だけ失敗」「Web では見えるフォントがデスクトップだけ代替フォント」といった症状に見えます。

企業向け Admin Console や Federated ID を使うテナントでは、IdP 側の FQDN も混ざるため、失敗ログに出たホストをその都度 DESIGN_TOOLS 束へ足す前提で読むのが現実的です。SaaS 束の考え方は Microsoft 365 のブラウザ束に近いですが、ホスト名はまったく別セットです。

ルール例：DESIGN_TOOLS 用ポリシーへ集約する

狭い DOMAIN や設計ツール用 rule-providers を、巨大な GEOIP や動画／AI 向けリストより手前へ置きます。グループ名 DESIGN_TOOLS_STABLE は、遅延が安定しライセンス地域とも整合するノード（または契約上許される DIRECT）に割り当ててください。

rules.yaml（例：概念のみ／本番は検証のうえ調整）

# Place design-tool bundle BEFORE broad GEOIP / streaming / AI lists
rules:
  - DOMAIN-SUFFIX,figma.com,DESIGN_TOOLS_STABLE
  - DOMAIN-SUFFIX,figma.site,DESIGN_TOOLS_STABLE
  - DOMAIN-SUFFIX,adobe.com,DESIGN_TOOLS_STABLE
  - DOMAIN-SUFFIX,adobe.io,DESIGN_TOOLS_STABLE
  - DOMAIN-SUFFIX,adobelogin.com,DESIGN_TOOLS_STABLE
  - DOMAIN-SUFFIX,typekit.net,DESIGN_TOOLS_STABLE
  - DOMAIN-SUFFIX,behance.net,DESIGN_TOOLS_STABLE
  - MATCH,PROXY_OR_DEFAULT

behance.net はアカウント連携で触れる場合があるため任意です。実際のテナントでは cc-api-data.adobe.io のような深いサブドメインが増えるので、ログで拾い足してください。ルールプロバイダの版更新で意図せず REJECT が先に当たっていないか、ベストプラクティスに沿って定期的に確認します。

汎用 AI／動画ルールセットとの棲み分け

当サイトでは ChatGPT や Claude、YouTube・Spotify など別ドメイン集合向けの分流記事を多数掲載しています。設計ツール向けにまとめた束を、それらの記事どおりの「openai.com 束」「googlevideo 束」に置き換えないでください。典型として、OpenAI API／CDN 分流 と YouTube の動画 CDN 分流 は、Figma／Adobe のホストをカバーしません。ストリーミングで鍛えた「音声 CDN を本体と同じポリシーへ」という発想は Spotify 本体と scdn の束の記事と似ますが、対象ドメインは別物です。

システムプロキシ・TUN とデスクトップアプリ

ブラウザはシステムプロキシを読みますが、Creative Cloud デスクトップは独自の設定や OS のルートテーブルに従うことがあり、ブラウザだけ Clash が効いてもアプリが取りこぼす、というパターンが出ます。取りこぼしが残るときは TUN でカーネル側から揃えるのが有効です。優先度や VPN との競合は TUN の深掘り記事 を参照してください。

ループプロキシにも注意します。購読更新やルールプロバイダ取得だけが不安定なチェーンに入ると、ルールが古いままになり「昨日まで Figma が開いていた」状態に戻ります。更新系は DIRECT か安定した専用グループへ残してください。

DNS、fake-ip、ブラウザ DoH のズレ

Clash の fake-ip とブラウザの DoH が二重になると、ルールが期待した名前解決経路とずれ、名前は解けるのに証明書検証や接続が変に見えることがあります。nameserver-policy や fake-ip フィルタの整理は Clash Meta の DNS：nameserver・fallback・fake-ip を併読してください。Adobe／Figma とも、CDN の CNAME チェーンが長いと、一見無関係に見えるエッジドメインへ飛ぶため、ログの FQDN をそのまま信じて追記する姿勢が安全です。

⚠ コンプライアンス：Adobe・Figma の利用規約、ライセンス地域、職場のセキュリティ方針を遵守してください。本稿は許可されたネットワークでの接続安定化の整理であり、未承認の迂回やポリシー回避を推奨するものではありません。

許可された利用の前提で押さえるチェック

  1. この環境で Clash と Figma／Adobe サービスを使うことが許可されているか確認する。
  2. 失敗時のホスト名を列挙し、認証・本体 API・静的 CDN・フォントの層に分類する。
  3. 設計ツール束が MATCH より前で一貫しているか、ブロック系ルールセットと衝突していないか確認する。
  4. ブラウザのみ・TUN ありで A/B 比較し、デスクトップアプリの取りこぼしを潰す。
  5. Clash DNS／fake-ip とブラウザ DoH の二重構成がないか確認する。
  6. 購読とルールプロバイダ取得がループせず成功する経路を残す。
  7. ライセンスや Adobe ID のエラーが続く場合は、ネット以外（アカウント状態・地域設定）を IdP／アカウント画面で除外する。

ログ行を時系列で残すと、全設定のやり直しより早く原因に辿り着けます。

まとめ

Figma と Creative Cloud の「くるくる」や読込失敗は、単一ドメインの遅延だけでは説明しきれません。認証・本体・静的 CDN・フォント配信へ分かれた通信を、Clash で DESIGN_TOOLS 向けポリシーへ束ね、システムプロキシか TUN のどちらが実トラフィックを覆っているか揃えれば、多くのケースは再現可能な経路のずれに還元できます。DNS／fake-ip とブラウザ DoH を同じ前提で扱い、ルールセットは汎用 AI や動画向けプリセットと混同しないことが長期運用のコツです。

→ 方針が固まったら、Clash を無料ダウンロードし、設計ツール専用のプロファイルとして試してください。キャンバスとフォント同期に奪われた時間を、本来の制作に戻せます。