📖 チュートリアル ⏱ 約23分で読めます

ReSharper 2026.2 Junie（Visual Studio 内 Agent）がタイムアウトするとき｜Clash Verge Rev で分流と DNS を段階実測（2026）

JetBrainsは 2026 年 5 月時点で ReSharper 2026.2 の早期アクセスを進め、JunieをVisual Studio 内のコーディング向け AI エージェントとして使う導線を強めています。日本語の検索では「ReSharper 2026.2」「Junie」「Visual Studio」「JetBrains AI Agent」と並んで「モデル API タイムアウト」「Clash Verge Rev」「分流ルール」「DNS」がセットで現れやすく、実務の悩みはだいたい次の一言に集約されます。ブラウザやターミナルでは通るのに、IDE だけ推論が固まる。本稿はClash Verge Rev（Mihomo コア）の接続ログを正として、分流とDNSを段階的にそろえ、Visual Studio 上の Junieを安定稼働に近づける手順をまとめます。公式のエンドポイント集合は更新で変わり得るため、記載のドメイン例は出発点に過ぎません。

検索意図の整理：IDE 内 Junie と Junie CLI は「通す穴」が違う

すでにターミナル前提で Junie CLI を切っている読者は、Junie CLI×Clash Verge Rev の実測稿と比較読みすると理解が速いです。CLI はシェル環境変数の影響を強く受け、GUI のブラウザとは経路が分かれやすい――その話は同稿で扱い済みです。一方、Visual Studioで動く JetBrains AI Agent（製品面の呼称は時期により Junie／エージェント機能の総称として揺れ得ますが、検索上はひとまとめになりがち）は、親プロセスが devenv.exe 系であり、子として ServiceHub や各種ホスト プロセスが増えます。結果として「環境変数でプロキシを入れたつもりでも IDE だけ別ルート」「システムプロキシは有効なのに特定子プロセスだけ直叩き」という、プロセス境界ベースの切り分けが前面に出ます。

だから本稿の主眼は、固定的なドメイン大全を暗記することではなく、Clash Verge Rev の Connections 相当のビューに出た FQDNとマッチしたポリシー名のペアを資産化することです。用語の土台はチュートリアルとカスタムルール解説、Windows 側でルール断片を壊さず足す発想はClash Verge Rev の Mixin 稿が近いです。エディタ一般の「裏でエージェントが増える」パターン自体はCursor 3×Verge Rev の稿とも響き合いますが、本稿は ReSharper と Visual Studio のプロセス構成に寄せます。

Visual Studio×ReSharper が増やしがちな外向き通信の地図（カテゴリだけ）

実ホストはビルド、地域、選択モデル、BYOKの有無、社内プロキシの有無で増減するため、ここでは観測カテゴリに留めます。第一に JetBrains アカウントやライセンス確認、製品アップデート、Junie関連のドキュメント・利用管理 UI に絡む HTTPS があります。第二に、エージェントが参照するモデル API（例：OpenAI 系、Anthropic 系、Google 系など）のエンドポイントと、その前段の CDN が乗ります。第三に、社内で追加のフィルタや証明書検査が挟まると、見かけ上は「TLS が遅い」「ストリームだけ切れる」に見えることがあります。この三層が重なると、単一の DOMAIN-SUFFIX 行に原因が収まらないのが普通です。

したがって運用では、社内 wiki の古い「許可ドメイン表」を盲信せず、問題が出た日のログ行からルールを後ろ向きに狭めていく方が安全です。DNS も同様で、端末側 resolver とコアの fake-ip が噛み合わないと、短い REST は成功して長い応答だけ失敗するように見えることがあります。ここはGemini CLI 向け DNS 実測稿などで触れた「単一変数で振る」方針と同型です。

前提：プロキシ適用を一本化してからログを読む

Visual Studio を動かす Windows で、HTTPS_PROXY をシェルに足したまま Clash Verge Rev が システムプロキシも注入していると、同一系統の通信が二段で別ポートへ振られることがあります。逆に NO_PROXY が広すぎると、今度は意図せず DIRECT へ抜けて社内 DNS の黑洞に落ちる、というパターンもあります。まずは「環境変数」「OS のプロキシ」「TUN／メタルールの直指定」の重なりを解体し、Junie を最小の再現操作（短い説明生成や軽いリファクタ提案だけ）に落として観察すると、ログが読みやすくなります。

ループバック例外や UWP 周辺が絡む読み方はWindows 11 のループバック稿も参照ください。本稿では「IDE の子プロセス群がどのモードで外向きしているか」を、Verge Rev の接続一覧のプロセス名／送信元とルールヒットで追う前提で書きます。

💡 ヒント JetBrains 側で公開されている説明 URL（junie.jetbrains.com など）は比較的まとまっている一方、モデル側のサブドメインは地域や課金設定で増減しやすいです。「公式に載っていないから通さない」ではなく、ログに出た事実でルールを足すのが実務的です。

ステップ 1：タイムアウト行の FQDN をログファーストで採取する

分流ルールという言葉は、設定ファイルをいじる前にどのホストが実際に遅い／失敗しているかを確定することを意味します。Clash Verge Revでは、Connections やログビューから長時間の TLSやリトライに結びつく行を拾い、FQDNと採用された proxy-groups名を対でメモします。購読テンプレに含まれる巨大 RULE-SETが先に当たって意図しない出口へ落ちている場合、ここで初めて表面化します。

IDE 経由の失敗は、ユーザー目線では「Junieのスピナーが回り続ける」程度に見えるため、ブラウザの開発者ツールほど手掛かりが無い点に注意してください。だからこそ、プロキシ側ログの行単位の観測が価値を持ちます。Junie CLI篇で強調したのと同様、臆測ドメインを大量に足しても当たり率は上がりません。

ステップ 2：狭い DOMAIN 系ルールを上へ寄せる（例は叩き台）

ルールは上から評価されるため、実測で得たホストを DOMAIN／DOMAIN-SUFFIX でまとめ、GEOIP や広いルールセットより上へ移します。以下は例であり、利用中のモデルや地域、JetBrains側アップデートで必ず変わります。自分のログへ置き換える前提の YAML 断片です。

rules:
  # Outbound label must match YOUR profile (e.g. Proxy / Auto)
  - DOMAIN-SUFFIX,jetbrains.com,JunieVs
  - DOMAIN-SUFFIX,junie.jetbrains.com,JunieVs
  # Model providers — append ONLY hosts from YOUR IDE logs
  - DOMAIN-SUFFIX,openai.com,JunieVs
  - DOMAIN-SUFFIX,anthropic.com,JunieVs
  - DOMAIN-SUFFIX,googleapis.com,JunieVs

広い DOMAIN-SUFFIX は便利ですが、課金・テレメトリ・別用途の通信まで同一出口へ吸い上げる副作用も出ます。運用ではログに出た行から後ろに狭げる方向が安全です。PROCESS-NAME で devenv.exe だけ別処理、といった切り口もありますが、表示名のゆらぎがあるため接続ログの実名と突き合わせてください。

ステップ 3：DNS を fake-ip／nameserver-policy で単一変数で振る

DNSは「プロキシは通っているはずなのに名前解決だけ妙」という形で、TLS 以前に失敗します。Mihomo 系では dns.enhanced-mode や nameserver-policy、DoH の選択が絡み、端末側 resolver と二重に噛み合わないとストリームだけ途切れることがあります。一度に一つのノブだけを回すのが実務的で、fake-ip と redir-host 系の切替、特定サフィックスだけ別 DNS へ寄せる試行、IPv4 のみに固定する試行を順番に踏むと原因が追いやすくなります。

rule-providers の更新周期と DNS 変更の位相がズレると、同じ操作でも成否がフラップして見える点はinterval 稿の観点と合わせて読むと理解が早いです。

⚠️ 注意 会社支給端末ではクラウド推論が規程上ロックされている場合があります。技術的にルールを通しても許可と監査に反する操作は避け、社内手順を優先してください。

Mixin／プロファイル覆写：購読を壊さず差分だけ足す

リモート購読を直編集すると、自動更新で上書きされます。Clash Verge Revでは Mixinやプロファイル覆写で、ポート・DNS・ルール断片だけをローカル差分として足せます。差分はチームでリポジトリ化し、ReSharper のビルドやモデル切替のたびにログで再検証する運用が続きます。

チェックリスト：Visual Studio 固有の見落としを潰す

  1. 1

    認証とモデル提供者を固定する

    JetBrains Account／Junie API Key／BYOK のどれで動かすかを一つに決め、IDE 内の設定画面と実際のログの宛先が矛盾していないか確認します。

  2. 2

    二重プロキシを解体する

    環境変数・システムプロキシ・TUN の重なりを解き、Junie を最小操作で再現します。

  3. 3

    接続ログで FQDN と policy を採取する

    タイムアウト行とマッチしたルール名を一覧化し、固定表に無いホストを優先的にルールへ反映します。

  4. 4

    ルール順と DNS を順に直す

    狭い DOMAIN を上へ、続いて DNS 単一変数検証へ進みます。

よくある質問

Edge では Junie のヘルプが読めるのに Visual Studio だけ止まる

プロキシ設定の参照経路がアプリごとに異なる典型です。システムプロキシ注入を疑いつつ、netsh winhttp 側の残り設定や、開発者向けプロキシツールの二重化も確認してください。

BYOK にすると急にルールが足りなくなるように見える

モデル提供者のエンドポイントがそのまま増えるからです。広いサフィックスで一括するほど副作用も増えるため、ログ起点で狭めていきます。

ReSharper 2026.2 のスケジュールは？

早期アクセスの公開範囲や名称は変わり得ます。導入判断は公式告知を正としてください。本稿はネットワークの切り分け型を提供します。

まとめ

ReSharper 2026.2 と Visual Studio の組み合わせは、検索上も「IDE 内 JetBrains AI Agent」として注目が高まっています。一方で Junie のように外向き通信が階層的に増える機能は、単一 VPN や画面からドメイン単位の微調整がしづらい汎用プロキシでは追従コストが高くなりがちです。接続の事実がログで見えず、例外を雑に足すだけだと設定はすぐに負債化します。

一方、Clash／Mihomo 系はルール順と可視ログを軸に、モデル API と JetBrains 周辺を同じフレームで整えられるため、IDE 内エージェントとも相性が良いです。VPN との違いはClash と VPN の比較も参考にし、入手経路はダウンロードページからどうぞ。

→ Clash を公式の入手先から入手し、Visual Studio の Junie 通信をログで整える準備をする