先に結論
今回の JetBrains update で大きいのは、Copilot CLI agent を IDE の中で扱えるようになったことです。
ただし、便利になったというより、隔離モードと管理者ポリシーを先に決めないと広げにくい更新 と見たほうが実務には合います。
JetBrains 利用チームが最初に見るべきなのは次の3点です。
- Copilot CLI agent を IDE から public preview で使える
- worktree isolation と workspace isolation を選べる
- Business / Enterprise は Editor preview features policy が前提になる
何が変わったのか
GitHub は 2026-05-13 に、GitHub Copilot for JetBrains IDEs の update を公開しました。
今回の中心は、JetBrains から Copilot CLI agent を呼べるようになったことです。
これで CLI を別ウィンドウで回すだけでなく、IDE の文脈を持ったまま長時間の agent 作業を始めやすくなります。
同じ更新では、次の改善もまとめて入りました。
- unified sessions view で running / queued session を一覧で追える
- Ask question tool が agent mode で使える
- global
.agent.mdを~/.copilot/agentsに置ける - GHES sign-in flow が追加された
単発の機能追加ではなく、JetBrains を agent 実行の本格的な入口に寄せた更新です。
いちばん先に見るべきなのは隔離モードです
最初に決めたいのはモデルではなく、変更の当たり方です。
Copilot CLI agent には worktree isolation と workspace isolation の2つがあります。
worktree isolation は別の Git worktree で走るので、いまの branch を直接汚しません。
review 前提で安全に回したいなら、まずはこちらが候補です。
一方の workspace isolation は、今の workspace に直接変更を入れます。
試行は速いですが、チームでの標準にするなら branch 運用や review ルールとセットで考えたほうが安全です。
GitHub 起点で agent を広げる流れは、GitHub Copilot app technical previewで何が変わるか ともつながります。
管理者は policy を先に開ける必要があります
Business / Enterprise では、使いたい人がすぐ agent を触れるわけではありません。
GitHub の changelog では、Editor preview features policy を管理者が有効化する必要がある と案内されています。
ここを見落とすと、導入案内を出しても IDE 側で使えず止まりやすいです。
管理者目線では、次の3つを先に決めておくと混乱しにくいです。
- preview をどのチームまで開けるか
- 隔離モードの既定をどちらにするか
- global
.agent.mdを配るか、repo ごとに閉じるか
モデル承認や組織ポリシーの全体像は、GitHub Copilot Business / Enterprise のモデル承認ガイド も参考になります。
unified sessions view は地味ですが効きます
運用上は、unified sessions view もかなり大事です。
JetBrains の chat window から、running / queued session の状態、経過時間、agent type を一か所で見られるようになりました。
agent を複数本流すと、どれが止まっていて、どれが待ちなのかが分からなくなりがちです。
この一覧があるだけで、IDE 内の運用はかなり追いやすくなります。
特に、custom agent や sub-agent を混ぜるチームでは、実行そのものより、追跡のしやすさ が効きます。
global agent の考え方を整理したいなら、GitHub Copilot custom agents vs Claude Code skills vs Codex plugins｜再利用単位と運用の違い も合わせて読むとつながりやすいです。
GHES 利用組織には sign-in 改善も大きいです
GitHub Enterprise Server を使っている組織にとっては、GHES sign-in flow の追加も見逃しにくい更新です。
sign-in 時に GitHub Enterprise を選び、hostname や URL で enterprise instance に認証できるようになりました。
JetBrains 側で GHES の入口が整うと、Enterprise 環境だから IDE 連携が一段遅れる、という詰まり方を減らしやすくなります。
もちろん、実際の利用可否は自社の GHES 構成や管理ポリシーに依存します。
それでも、今回の更新で JetBrains でも Enterprise 環境を前提にした導入の話がしやすくなった のは確かです。
いま導入前に確認したいチェックリスト
迷ったら、次だけ先に決めるのが早いです。
- Editor preview features policy を開けるか
- worktree isolation を標準にするか
- GHES sign-in が必要な組織か
- global
.agent.mdを共通配布するか - Ask question tool を含む agent 運用をどこまで許すか
今回の update は、JetBrains で agent が動くようになった、で終わる話ではありません。
運用ルールまで含めて固められるなら、CLI 単独より IDE 内の導入体験はかなり前に進みます。