Web IDE 系の通信はなぜ「Vercel＋Replit＋レジストリ」に分散しやすいか

2025–2026 年頃の「プロンプトからサイトやアプリを出す」系ツール（Lovable、Replit Agent、他ベンダー名は商標）は、ブラウザ上の一画面の裏で編集用 UI・ビルド・プレビュー配信・パッケージ解決が別ホストに分かれます。多くの公開プレビューは vercel.app 配下の URL、管理やデプロイは vercel.com、Replit なら replit.com や repl 系、併せて npm レジストリ、unpkg／jsDelivr／esm.sh などの静的パッケージ CDN、GitHub からの取得までが短時間に走ります。ここに対して、Cursor 向けのように「推論系 API だけを一つの openai 束へ」と整理したプリセットをそのまま当てると、プレビュー用エッジとレジストリ用ホストが抜け、部分的成功（UI は出るが依存取得だけ TLS タイムアウト）に見えがちです。本テーマ用に AI_WEB_BUILD のようなストラテジを一つ定め、Windsurf／Codeium 束（VS Code 拡張市場系）とドメインは重ねない想定で読んでください。

ノードの地理的な出口も絡みます。Vercel 側のエッジとレジストリのエッジが片方だけ別地域に乗ると、ビルドは通っても Waterfall 上の 1 本が長いという形に見えます。出口を揃えたあと、まだ挙動が揺れるときは、ルールの前に 同じ国／地域のノードに固定できるか、まず検討の価値があります。

典型症状：プレビューは出るのに中身だけ遅い

代表的なパターンは次の通りです。(1) エディタは開くが、ビルドログの依存取得行だけ遅延・再試行が続く。(2) プレビュー iframe の最初の白画面が長いが、vercel.app への初回以降は速い。(3) Replit ではランタイム起動は成功するが、npm i 相当の通信だけ別経路に割れて失敗する。(4) ブラウザ A では動くが B では崩れる——拡張の広告・トラッキングブロックが cdn. 系を先に弾いていないかも疑います。失敗行の SNI をライブ接続に残し、ビルド基盤・プレビュー配信・レジストリのどの箱かに分類すると、下の rule-providers 追記の優先度が付けやすいです。

ℹ 観測のコツ：同じ操作の直前 30 秒分のログを抜き、(a) vercel・now.sh 系（ホスティング・プレビュー）、(b) replit 本丸、(c) npm／unpkg／jsdelivr 等（パッケージ）、(d) 画像最適化や分析で増えるサブドメイン、に大まかに分けます。TLS が張る前に落ちるなら SNI や DNS、握手後に止まるなら帯域とノード品質、と TLS 記事 の表と併せて照合します。

Vercel 側：vercel.com・プレビュー・Edge／画像最適化

出発点として、DOMAIN-SUFFIX,vercel.com と DOMAIN-SUFFIX,vercel.app、場合によっては DOMAIN-SUFFIX,now.sh など同じ AI_WEB_BUILD ストラテジに載せます。ダッシュボード、Git 連携、デプロイ API、*.vercel.app プレビュー、画像最適化用のリライト先などは時期で増えるため、固定リスト一発より自分のセッションで出た FQDN をルールに追記する運用が安全です。誤って広告ブロッカー用 rule-providers の REJECT が先に当たると、プレビューは「一瞬は出るがリロードで落ちる」に見えることがあるため、ルールの上から順の棚卸しを併用してください。静的ホスティング一般の比喩を借りるなら、Figma／Adobe 束の「本体系と配信層の二段」と発想は似ますが、ホスト名の集合は交換不可です。

Replit 側：replit.com・開発コンテナとエージェント用ホスト

Replit は replit.com 本体の他、replit 名義の各種 API、開発コンテナやエージェント、ターミナル相当の裏回線が別 FQDN に分かれやすいです。プランや機能で増えるサブドメインは、ドキュメントより手元のログが信頼できます。Vercel 側の束と分けたい場合はストラテジ名を REPLIT_ONLY に分ける手もありますが、症状が「依存取得とランタイムの二段でズレ」なら、まずは一つの AI_WEB_BUILD に寄せ、ログで必要な分だけ分割する方が再現性が上がることが多いです。

npm レジストリとパッケージ CDN（unpkg 等）の束ね方

ビルドのボトルネックは registry.npmjs.org や npmjs 名義に加え、unpkg.com、cdn.jsdelivr.net、esm.sh など、フロントが import 解決に使う配信面へ分散します。いずれか一方だけ DIRECT や別国ノードに落ちると、一部パッケージの取得だけ劇的に遅い形になります。チーム方針で GitHub から git+https 取得を使うなら、GitHub 束のホスト定義と衝突しないか（同一ストラテジに寄せるか、github.com を汎用 PROXY から切り出すか）を決め、ターミナル／Docker 経由の CLI まで同じ出口になるよう揃えます。ローカルで pnpm や yarn を併用する場合も、同じ要領でレジストリ FQDN を追記します。

ルール例：AI_WEB_BUILD 用ストラテジへ集約する

狭い DOMAIN や自己管理の rule-providers を、巨大 GEOIP や GEOSITE 由来の MATCH より手前へ。グループ名 AI_WEB_BUILD_STABLE には、遅延とライセンス上許される地域に合いやすいノード（契約上の DIRECT を含む）を割り当てます。下は概念例で、本番前に接続ログで必ず照合してください。

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

# Lovable / Replit / Vercel style bundle: place BEFORE broad AI/chat/streaming lists
rules:
  - DOMAIN-SUFFIX,vercel.com,AI_WEB_BUILD_STABLE
  - DOMAIN-SUFFIX,vercel.app,AI_WEB_BUILD_STABLE
  - DOMAIN-SUFFIX,now.sh,AI_WEB_BUILD_STABLE
  - DOMAIN-SUFFIX,replit.com,AI_WEB_BUILD_STABLE
  - DOMAIN-SUFFIX,npmjs.org,AI_WEB_BUILD_STABLE
  - DOMAIN-SUFFIX,unpkg.com,AI_WEB_BUILD_STABLE
  - DOMAIN-SUFFIX,jsdelivr.net,AI_WEB_BUILD_STABLE
  - DOMAIN-SUFFIX,esm.sh,AI_WEB_BUILD_STABLE
  - MATCH,PROXY_OR_DEFAULT

npmjs.org 一括で他の開発作業も全部同出口に乗るのが嫌なら、process-name や、時間帯限定のサブプロファイルに分ける、など衝突回避の設計を足してください。ルールプロバイダの更新で REJECT が先に刺さると、昨日まで通っていた、に戻りづらいので、購読更新の経路は安定した DIRECT か別グループに残すのがお勧めです。

汎用 OpenAI／Claude ルール束との違い

当サイトの Claude や DeepSeek 向け記事は、大規模言語モデル API のホストにフォーカスしています。一方、本稿の束は ホスティングとレジストリです。同じ「AI コーディング」という言葉でも、openai.com 束を増やすだけでは vercel.app の遅延は解けません。拡張市場周りの切り分けは Windsurf 記事、IDE 全般のログインは Cursor 記事と棲み分けてください。SaaS 束の汎用例として、Notion／AWS 分流 の「多段 CDN に割れた典型」に近い 体感の話はありますが、ドメイン表は 別物です。

システムプロキシ・TUN、Docker／CLI との併用

ブラウザ上の Lovable や Replit のタブはシステムプロキシを読みますが、横で動かす node や docker build は環境変数 HTTP_PROXY 系と NO_PROXY、あるいは TUN でしか揃わない、という分岐が出ます。TUN モードの深掘り と、クライアントの選定を併せて、どちらのプロセスが抜けているかを A/B します。端末作業の混線は 拡張プロキシと二重中継の記事とも絡みやすいので、ブラウザ拡張の「直 PROXY 指定」が残っていないかも点検します。

DNS、fake-ip、ノードの地域揃え

fake-ip とブラウザの DoH が二重だと、ルールが想定する名前解決と実接続が食い違い、プレビューだけ証明書警告に見えることがあります。Clash Meta の DNS 記事のとおり、nameserver-policy や fake-ip-filter を一箇所の前提に揃えます。ノード国と、Vercel／npm の観測リージョンが大きく食い違うときは、同じ法域に近い exit を試し、WAF やレート制限の誤差を減らします。IPv6 だけ直進するケースは IPv6 二重スタックの整理も併用してください。

⚠ コンプライアンス：各サービスの利用規約、職場のセキュリティ方針、クライアント先との契約で許可された通信経路を遵守してください。本稿は許可された環境で「出口の一貫性」を高める整理であり、未承認の迂回を推奨するものではありません。

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

  1. このネットワークで Lovable／Replit／Vercel 利用が方針上許可されているか確認する。
  2. 失敗行の FQDN を列挙し、ホスティング／Replit 本体／レジストリ・CDN の層に分ける。
  3. AI_WEB_BUILD 束が MATCH より前にあり、広告ブロッカー用 REJECT が割り込まないか確認する。
  4. ブラウザのみ、TUN 有り、CLI のみで A/B し、Docker／CLI 環境変数まで揃うか比較する。
  5. Clash DNS／fake-ip とブラウザ DoH の二重構成を解消する。
  6. ルールと購読の更新取得が、不安定なチェーンに乗っていないか確認する。

一連の操作に対するログ断片を残しておくと、プロファイル全入れ替えより早く、どの層の出口が揃っていないかに辿り着けます。

まとめ

Lovable や Replit の「重さ」は、単一の遅延ノードだけに還元できないことが多いです。Vercel 系プレビュー、Replit 本体、npm／パッケージ CDN へ分かれた通信を、Clash のルールセットで AI_WEB_BUILD 向けストラテジに束ね、TUN と DNS の前提を揃えれば、多くのケースは多域名同時接続の部分ずれとして説明できます。汎用の OpenAI／Claude 束と入れ替えないこと、他 SaaS 向けの表と混同しないことが、長期運用の要点です。

→ 方針が固まったら、Clash を無料ダウンロードし、小さなサブプロファイルに本稿の束だけ載せ、ライブ接続に出た FQDN を都度足していくのが近道です。止まっていたプレビュー待ちの時間を、本来の設計作業に戻せます。