なぜ「Firefly 周り」だけが切れやすいのか

2026 年前後、各種メディアでも話題になっている Firefly をはじめとする生成系機能は、単体アプリの中に閉じた処理ではなく、Adobe Creative Cloud のアカウント、ライセンス、クラウド同期、そしてオンラインの推論や補助 UI までが細かく分割されたホストへ伸びていきます。その結果、一般の Web ブラウザで ChatGPT を開くときのような「一つのドメインに集約された会話」より、認証・同期・機能別 API が別レーンに乗りやすく、社内ネットワークや地域制限のある回線では「アプリ本体は動くのに、ログインだけ回る」「同期だけタイムアウト」「アシスタントだけ応答しない」といった部分的症状が出やすいのが実情です。

本稿は Firefly の機能レビューではなく、Clash／Mihomo（旧称 Clash Meta）でAdobe エコシステム向けトラフィックを分流し、DOMAIN-SUFFIX と独立したプロキシグループ（ポリシーグループ）、DNS、ノード選定をセットで確認する実測手順に焦点を当てます。汎用 LLM の Web／API 向け記事（例：ChatGPT 専用の整理）とはドメイン設計が異なるため、Creative Cloud 利用者向けの切り分けとして読み分けてください。分流の共通の型はルール分岐の詳解ガイドと重なるので、初めてルール順を触る場合はあわせて参照すると理解が早いです。

典型症状：どこで詰まっているように見えるか

実務で寄せられる相談をざっくり分類すると、次のようなパターンが多いです。いずれも「プロキシは ON のはず」なのに、体感がバラバラになる点に注意してください。

• Adobe アカウントのログイン画面やブラウザ連携が終わらず、スピナーのまま進まない
• Creative Cloud デスクトップでパッケージの取得・同期・フォント同期だけが極端に遅い、または失敗する
• Photoshop など本体は起動するが、パネルやFirefly アシスタント、クラウド連携の一部だけがタイムアウトやエラーになる
• 同一マシンで別ブランドのクラウド同期は問題ないのに、Adobe 系だけ不安定——といったホスト単位の偏り

ここで重要なのは、症状の「見え方」がアプリ UI 上では同じでも、背後では adobe.com 系、adobe.io 系、adobelogin.com 系など、別サフィックスのホストに分散している可能性が高いことです。だからこそ、まず開発者ツールやクライアントの接続ログで実際に触っている名前を拾い、DOMAIN-SUFFIX で束ねるのが現実的です。

独立プロキシグループを切る理由

購読プロバイダーが配るデフォルトでは、「海外まとめて一つの select」に乗せる構成が多く、それ自体は悪くありません。ただし Adobe 系は長めの TLS セッションや複数ホストへの連続アクセスが続きやすく、動画 CDN や一般ブラウジングと同じ出口に乗せると、ノード側のレート制限や輻輳の影響を受けやすくなります。

そこで ADOBE_PROXY のような専用プロキシグループを用意し、ルールで Adobe 関連サフィックスだけそこへ流すと、(1) 一般トラフィックのノード切り替えと独立して安定ノードに固定できる、(2) ログ上で「どの接続がどの出口か」追いやすい、(3) トラブル時の切り分け対象を狭められる、という利点があります。名称は既存の YAML と衝突しない任意の文字列で構いません。

DOMAIN-SUFFIX で束ねやすいホストの考え方

サブドメインや CDN の追加は随時あり得るため、ここに列挙する名前は「出発点」です。設定後は必ず実機のネットワークタブや Clash の接続一覧で漏れホストを確認し、必要なら行を足してください。

• ブランド・製品ページ・一部 UI：adobe.com 配下（例：creativecloud.adobe.com、firefly.adobe.com など）
• API・バックエンド系：adobe.io 配下（サービスごとにサブドメインが分かれやすい）
• アカウント・認証：adobelogin.com および地域別 IMS ホスト（環境によって名前が分岐します）

DOMAIN-KEYWORD,adobe, のような書き方は手早い反面、意図しないサイトまで巻き込みやすいので、まずは DOMAIN-SUFFIX で足りるかを優先し、どうしても足りない箇所だけ最小限のキーワードを足すと安全です。

ルール順：最初にマッチした行が勝つ

Clash 系の rules: は上から順に評価され、最初の一致で打ち切られます。巨大な RULE-SET のあとに Adobe 行を追記していると、GEOIP や広い MATCH に先に飲み込まれ、分流が効いていないつもりになる典型パターンです。

実務的には、Adobe 向けの具体的な DOMAIN 行を、大雑把な締め行より上に置きます。GUI でルールを追加したあとは、必ず一覧の順序を目視してください。評価順の考え方はルール分岐ガイドの評価順序の節と同じです。

YAML の骨格例（概念サンプル）

実際のキーやインデントは利用中のコア・GUI のスキーマに合わせてください。ここでは proxy-groups に Adobe 用グループを用意し、rules から参照するイメージだけ示します。

proxy-groups:
  - name: ADOBE_PROXY
    type: select
    proxies:
      - 🇯🇵 低遅延
      - 🇸🇬 安定
      - 🌐 自動選択

rules:
  - DOMAIN-SUFFIX,adobe.com,ADOBE_PROXY
  - DOMAIN-SUFFIX,adobe.io,ADOBE_PROXY
  - DOMAIN-SUFFIX,adobelogin.com,ADOBE_PROXY
  - DOMAIN-SUFFIX,adobeaemcloud.com,ADOBE_PROXY

末尾の adobeaemcloud.com は、チームや企業向けクラウド文脈で触れることがあるサフィックスの一例です。自環境で接続が出なければ行ごと削除して構いません。このあとに、社内ドメインや国内 GEOIP、最後に MATCH など、環境に合った一般ルールを続けます。

DNS と Fake-IP：ルールと解決経路を揃える

ルールはドメイン名でマッチする行と、名前解決後の IP でマッチする行が混在します。DNS が Clash 外のリゾルバに流れていると、画面上は正しそうな YAML でも、実接続は別経路に落ち、誤直結やタイムアウトに見えることがあります。

• OS や一部デスクトップアプリが、Clash の DNS ではなくシステム DNSを直叩きしている
• Fake-IP モードのまま、アプリ側の挙動とリゾルバ設定が噛み合わず、マッチと実接続の関係が複雑化する
• GEOIP 行が、想定と異なる国コードの IP に反応し、意図しないポリシーに落ちる

対策の方向性は「名前解決の経路をできるだけ一本化し、TUN や DNS ハイジャックを併用するならその前提でルールを読む」ことです。OS 全体へ透過的に効かせる場合はTUN モード完全ガイドの DNS の節が参考になります。設定変更後は、OS の DNS キャッシュやアプリの再接続をセットで行ってください。

実測ステップ：こう順に見ると迷子になりにくい

ステップ 1：接続ログでホストとポリシーを確認

Creative Cloud や対象アプリを起動し、問題の操作（ログイン、同期、Firefly パネルの開閉など）を再現します。Clash 側の接続一覧またはログで、(1) どのホスト名に伸びているか、(2) どのプロキシグループ／ノードに割り当てられているか、(3) 失敗時はタイムアウトか TLS エラーか、をメモします。ここで adobe.io だけ別出口に落ちている、などが分かると、DOMAIN-SUFFIX の不足か、順序の問題かが切り分けやすくなります。

ステップ 2：DNS クエリの出口を確認

Fake-IP／Redir-host など、利用中のモードに合わせて「名前解決がどこで起きているか」を確認します。ブラウザは通るがデスクトップアプリだけおかしいときは、まずこの層を疑う価値が高いです。必要なら一時的に DoH のみ、またはルータ経由を切り離すなど、変数を減らした状態で再現してください。

ステップ 3：ノードを切り替えて再現性を見る

ADOBE_PROXY 内で別地域・別事業者のノードに切り替え、同じ操作を繰り返します。特定ノードだけ失敗するならルール以前の問題（サーバー側・UDP・IPv6 など）の可能性もあるため、url-test や手動 select で比較します。遅延テストが全滅に見えるときの層別切り分けは別稿のチェックリストも参考になります。

よくある落とし穴

汎用 AI 向けルールをそのまま流用する

ChatGPT や Claude 向けに書いた DOMAIN-SUFFIX だけでは、Adobe の認証や adobe.io 上の API まではカバーできません。エコシステムが違うので、ルールセットは用途別に分けて保守するほうが長期的に安全です。

ルールは足したのに効かない

多くは順序かグループ名の綴りです。存在しないグループ名を指すと、意図しないフォールバックの原因になります。外部ルールセットを大量に読み込んでいる場合、Adobe 用の明示行が下に埋もれていないかを確認してください。

TUN を有効にしたのにアプリだけ乗らない

macOS ではシステム拡張の許可や仮想 NIC の状態によって、期待した取り込みにならないことがあります。TUN 周りのトラブルはClash Verge と macOS のシステム拡張の手順も参照し、レイヤーごとに切り分けてください。

運用で効く観測の習慣

ルールを増やすほど、後から読むのが難しくなります。Adobe 系はホスト追加が起きやすいので、(1) 四半期に一度、代表アプリでネットワークタブをざっと確認する、(2) 購読ルールセットの更新ログをメモする、(3) 接続一覧で出口が想定どおりかスポットチェックする——の三段だけでも、迷子時間は大きく減ります。

用語や全体像の整理はチュートリアル・ドキュメントも参照してください。オープンソースの挙動を追う場合は GitHub 上のリポジトリが有用ですが、日々のクライアント入手と更新は説明の揃った配布ページのほうが取り違えが少ないです。

まとめ

Adobe Creative Cloud と Firefly を含むオンライン機能は、単一のチャット画面ではなく、認証・同期・API にまたがる複数ドメインへ分散しやすいため、汎用 LLM 向けの分流設計とは別に、Clash で DOMAIN-SUFFIX と独立プロキシグループを切るのが実務では扱いやすいです。そのうえで、ルール分岐の評価順序とDNS（Fake-IP・リゾルバ経路）をセットで設計しないと、YAML は正しいつもりでも部分的症状が残りがちです。

同種ツールのなかでも Clash 系は表現力と可観測性の両立がしやすく、デスクトップのクリエイティブ系ソフトとサブスク型クラウドが混ざる環境でも長期運用向きです。Windows／macOS／Linux 向けビルドはダウンロードページから環境に合わせて選べます。ルールの基礎から押さえ直す場合はルール分岐の詳解、OS 全体へ透過的に効かせたい場合はTUN ガイドと併読すると、本稿の手順がすぐ実装に落ちます。用途別にトラフィックを制御できる点が、単純な常時 VPN よりも現場では実用的な体験になりやすいでしょう。→ Clash クライアントを無料でダウンロードし、Adobe 向け分流を試す