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

JetBrains Junie CLI ベータ×Clash Verge Rev：ターミナル Agent の API 分流と DNS 実測（2026）

JetBrains Junie CLIは、ターミナルからそのまま動かせるコーディング向け AI エージェントとして 2026 年にベータ段階へ広がりつつある注目株です。IDE を開かずにプロジェクト文脈で計画・実行し、必要ならMCPも束ねられます。一方で検索ユーザーの多くが直面するのが、「モデル APIやJetBrains 認証、追加ホストへの HTTPS が増えた結果、タイムアウトや DNS ねじれがターミナル側だけに出る」パターンです。本稿はClash Verge Rev（Mihomo 系）を前提に、API 分流とDNSを接続ログ主導で揃える実測手順を、日本語の検索意図（Junie CLI、JetBrains、ターミナル Coding Agent、Clash Verge Rev など）に沿って整理します。公式のエンドポイント集合はアップデートで変わり得るため、記載のドメイン例は出発点であり、必ず自分の環境のログを正としてください。

検索意図の整理：Junie CLI を「ただ通せば動く」と決めつけない

Junie CLIは JetBrains 側の説明どおり、LLM を切り替え可能なターミナルエージェントとして設計されており、ローカルのリポジトリでプランと実行、必要に応じてサブエージェントやスキルを足す、という外向き通信が階層的に増えるタイプのツールです。検索では「Junie CLI ベータ」「JetBrains ターミナル Agent」「Junie API Key」「BYOK」などの語がセットで現れますが、ネットワーク観点では共通して次の問いに着地しやすいです。どの認証経路で動かしているか、どのモデルプロバイダの FQDNに実際に伸びているか、社内プロキシや二重プロキシが挟まっていないか、最後にDNS とルール順のねじれが無いか、です。

ブラウザ中心のクラウドエージェントと違い、ターミナルはシステムのプロキシ設定を自動では読まないケースが普通にあります。Git やコンテナ、pnpm／brew のサブプロセスが別経路を取ると、「ブラウザでは Junie の案内ページが見えるのに、CLI だけ遅い」という擬似一方通行にも見えます。同種の切り分けは、ChatGPT 上の Codex 向けに書いたOpenAI Codex×Clash の分流・DNS 稿とも響き合いますが、本稿の主役はJetBrains 系のターミナル実行です。入口の用語整理にはチュートリアルとカスタムルール解説、ルール断片を壊さず足す発想はWindows 11 の Mixin 稿（macOS でも発想は共通化できます）を先に眺めると読みやすくなります。

Junie CLI が増やしがちな外向き通信の型（ざっくり地図）

実ホストはビルドと設定で増減するため、ここでは観測カテゴリだけ示します。第一にJetBrains アカウントや Junie 側の利用管理に絡む HTTPS があり、第二に選択したモデル（OpenAI／Anthropic／Google など）やBYOKに応じた推論系ホストが乗ります。第三に、MCP サーバや外部ツール呼び出しが有効なら、その都度追加ドメインがログに現れます。ここまで重なると、「ベータを有効にした日だけ遅い」「特定サブコマンドだけ失敗する」など、原因が単一行の DOMAIN ルールに収まらなくなるのが普通です。

CI や SDK と併用する読者もいるはずで、HTTP で増える外向き先を段階実測で潰す枠組み自体はCursor Agent SDK×Clash の CI 稿と酷似します。違いは JetBrains が前面に出るぶん、認証とドキュメント取得の経路が Cursor 系とは別集合になりやすい点です。だからこそコピペ用の固定ドメイン全集に依存せず、Clash Verge Rev の接続画面に出た FQDN を資産化するのが安全です。

前提：Clash Verge Rev で最初に見るのは接続ログではなく「二重プロキシ」か

ターミナルでHTTPS_PROXYを足したうえで、macOS や Windows のシステムプロキシも Clash が上書きしていると、同一プロセスが別ポートへ二段で振られることがあります。NO_PROXYに広すぎる除外を入れると、今度は意図せずDIRECTへ抜けて社内 DNS の黑洞に落ちる、という逆パターンも起きます。まずは環境変数と GUI の「システムプロキシ／TUN」適用を一本化し、Junie を最小再現コマンド（例：バージョン表示や軽いドライラン）に落として観察すると、ログが読みやすくなります。

Verge Rev の画面構成やログの見方は、IDE 前提のCursor 3×Verge Rev の段階実測稿と手順が似ます。本稿ではターミナルのCoding Agentに寄せて、接続一覧に出るプロセス名／送信元ポートとマッチしたルール行の対応をメモする前提で書きます。

💡 ヒント JetBrains のドキュメント（junie.jetbrains.com など）は公開 URL の変更が比較的まとまっている一方、モデル側や CDN のサブドメインは地域・課金・モデル選択で増減しやすいです。社内ガイドの固定表が古いままだと、ルールだけが現実とズレます。

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

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

CLI 専用のタイムアウトと DNS の相関は、汎用的にまとめたClaude Code CLI×DNS の実測メモとも呼応します。Junie でもストリームが長い処理ほど、短い REST では隠れていたfake-ip と resolver のねじれが出やすいです。ログに出ない臆測ドメインをルールに足しても当たり率は上がらないので、失敗行に出たものだけをルールの種にしてください。

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

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

rules:
  # Stable outbound group label matches YOUR profile (e.g. Proxy / Auto)
  - DOMAIN-SUFFIX,jetbrains.com,JunieApi
  - DOMAIN-SUFFIX,junie.jetbrains.com,JunieApi
  # BYOK / model providers — add ONLY what YOUR logs show
  - DOMAIN-SUFFIX,openai.com,JunieApi
  - DOMAIN-SUFFIX,anthropic.com,JunieApi
  - DOMAIN-SUFFIX,googleapis.com,JunieApi

このまま採用しても効くことはありますが、事故の温床でもあります。不要な広いDOMAIN-SUFFIXは遅延や課金系の別経路まで吸い上げるため、運用ではログに出た行から後ろに狭げる方向が安全です。PROCESS-NAMEやIP-CIDRを併用する場合も、表示名が OS やビルドで微妙に異なるので一字一句の一致を確認してください。

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

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

Windows 環境で rule-providers の更新周期やキャッシュとDNS 更新の位相を揃えたい場合は、合わせてrule-providers の interval 稿も参考にしてください。Junie のように API 呼び出しが断続的に増えるツールでは、ルールセット更新と DNS のタイミングがズレると、同じコマンドでも成否がフラップして見えます。

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

Mixin と購読 YAML：壊さず足す運用

リモート購読を直編集すると、自動更新で上書きされます。Clash Verge Rev ではMixin／プロファイル覆写で、ポート・DNS・ルール断片だけをローカル差分として足せます。差分はチームでリポジトリ化し、Junie のバージョンやモデル切替のたびにログで再検証する、という運用が長く続きます。GUI のクリック順と注意点は、前述の Mixin 記事に委ねつつ、本稿では購読本体は触らないことを強く推奨します。

ステップ運用を俯瞰するチェックリスト

  1. 1

    認証方式を一つに固定する

    JetBrains Account／Junie API Key／BYOK のどれを使うかを決め、ターミナルと CI で混線しないよう鍵の置き場を揃えます。

  2. 2

    二重プロキシを解体する

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

  3. 3

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

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

  4. 4

    ルール順と DNS を順に直す

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

よくある質問

Junie は jetbrains.com さえ通れば十分？

多くの場合、単一行では足りません。モデル提供者や MCP、キャッシュ配信のホストが加わります。接続ログの表を唯一の正としてください。

BYOK にするとルールが急に複雑になる理由は？

各プロバイダのエンドポイントがそのまま増えるからです。まとめて広いサフィックスに逃げるほど、不要な通信まで同一出口へ寄せる副作用が出やすくなります。

GUI では速いのにターミナルだけ遅いように見える

プロキシ適用の単位がアプリごとに異なる典型です。シェルに明示的にプロキシを足し、NO_PROXY の過剰指定を疑ってください。

まとめ

JetBrains Junie CLIのベータは、開発者の検索トピックとしても、ターミナル Coding Agentという運用軸でも注目が集まっています。その一方で、モデル／認証／ツール連携のどれを選んでも外向き HTTPS の集合は静的ではありません。だからこそ本稿では、Clash Verge Revを用いてAPI 分流とDNSを、ログ主導の段階実測で揃える順序をまとめました。

従来型の単一モードVPNや、画面上から細かなドメイン単位のポリシーを扱いづらい汎用プロキシでは、エージェント実行のたびに増えるホストへ柔軟に追従しにくい面があります。一方、Clash／Mihomo 系はルールの順序とログを起点に微調整できるため、Junie のように外向き先が増えやすいツールとも相性が良いです。入手経路を整理したい場合はダウンロードページを参照し、VPN との違いはClash と VPN の比較記事も併読すると判断がしやすくなります。

→ Clash を公式の入手先から入手し、Junie CLI のターミナル通信をログで整える準備をする