GitHub Copilot for JetBrains IDEsを使っている開発チームにとって、今回の更新で最も重要なのは、JetBrains IDEからCopilot CLI agentへ作業を委任できるようになったことです。あわせて、実行中・待機中のエージェントセッションをまとめて確認できる統合セッション表示も追加されました。
これにより、IntelliJ IDEA、PyCharm、WebStormなどのJetBrains IDE上で、コード修正や調査、テスト作成のような複数ステップの作業をGitHub Copilotに任せやすくなります。一方で、管理者は「Editor preview features」「Copilot CLIの利用可否」「モデル・MCP・監査ログ・機密情報の扱い」を確認してから展開する必要があります。
GitHub Copilot for JetBrains IDEsの今回の更新で何が変わったのか
今回の公式Changelogでは、JetBrains IDE向けGitHub Copilotに複数の改善が入っています。中心はCopilot CLI agentのPublic Preview対応ですが、開発者体験・管理・安定性に関わる変更も含まれます。GitHub Blogの該当Changelogは2026年5月13日付で公開されており、リリース情報としては日本語圏で2026年5月14日前後に確認されるケースがあります。(The GitHub Blog)
| 変更点 | 内容 | 影響を受ける人 |
|---|---|---|
| Copilot CLI agentの追加 | JetBrains IDEからローカルで動作するCopilot CLI agentへタスクを委任できる | 開発者、テックリード |
| 統合セッション表示 | 実行中・待機中のセッション状態をチャット画面で確認できる | 開発者、レビュー担当者 |
| Ask question tool | Agent modeでエージェントが追加質問できる | 開発者、要件定義担当 |
グローバル.agent.md対応 | ~/.copilot/agents配下の.agent.mdでワークスペース横断のカスタムエージェント定義が可能 | 開発者、標準化担当 |
| GHESサインイン改善 | GitHub Enterprise Serverへのサインイン導線が改善 | 企業利用者、管理者 |
| UX・信頼性改善 | UI応答性、ドラッグ＆ドロップ、補完、選択操作などを改善 | JetBrains IDE利用者 |
| Edit modeの扱い変更 | 該当ChangelogではEdit mode supportの削除が案内されている | 既存運用をしていた開発者 |
今回の更新は、単なる「補完機能の強化」ではありません。GitHub Copilotを、IDE内で会話するアシスタントから、一定の作業単位を任せられるエージェントへ近づける変更です。
Copilot CLI agentがJetBrains IDEから使えるようになる意味
Copilot CLI agentは、ターミナル上で動くGitHub Copilotのエージェント機能です。今回の更新では、このCopilot CLI agentをJetBrains IDEのチャットから選び、IDEの文脈を接続した状態でタスクを委任できるようになりました。GitHubはこの機能をPublic Previewとして案内しています。(The GitHub Blog)
従来のCopilot Chatでは、開発者が質問し、回答を読み、必要に応じて手でコードへ反映する流れが中心でした。Copilot CLI agentを使うと、たとえば次のような作業を「一連のタスク」として依頼しやすくなります。
- 既存APIの仕様を確認し、影響範囲を調べる
- 小さなバグ修正を行い、関連テストを追加する
- リファクタリング候補を洗い出し、変更差分を作る
- READMEや設定ファイルをコード変更に合わせて更新する
- レガシーコードの構造を調査し、修正方針をまとめる
実務では、「1行の補完」よりも「調べる、直す、テストする、差分を確認する」という連続作業に時間がかかります。Copilot CLI agentの価値は、この連続作業をIDEの外へ完全に移動せずに進められる点にあります。
Worktree isolationとWorkspace isolationの使い分け
Copilot CLI agentでは、変更の適用方法を制御するために複数のisolation modeが用意されています。公式Changelogでは、別のGit worktreeで作業するWorktree isolationと、現在のワークスペースへ直接変更するWorkspace isolationが説明されています。(The GitHub Blog)
| モード | 変更の入り方 | 向いている作業 | 注意点 |
|---|---|---|---|
| Worktree isolation | 別のGit worktreeで作業し、現在のブランチにはすぐ影響しない | 大きめの修正、調査を含む変更、失敗しても戻したい作業 | 作業後に差分を確認し、必要な変更だけ適用する |
| Workspace isolation | 現在のワークスペースに直接変更する | 小さな修正、すぐ試したい変更、検証済みの単純作業 | 変更が即座に作業ツリーへ入るため、事前にGitの状態を整理しておく |
迷った場合は、最初はWorktree isolationを選ぶのが安全です。特に、業務コード、複数ファイルの変更、依存関係の更新、マイグレーション、セキュリティ関連の修正では、いきなり現在のワークスペースへ適用しない方がレビューしやすくなります。
Workspace isolationは、すでに方針が明確で、影響範囲が小さい作業に向いています。たとえば、テスト名の修正、軽微な型エラーの解消、ドキュメントの文言修正などです。
統合セッション表示でエージェント作業の状況を追いやすくなる
今回の更新では、JetBrains IDEのチャット画面に統合セッション表示が追加されました。各セッションにはタイトル、エージェント種別、経過時間、ステータスが表示され、エージェント種別や状態で絞り込むこともできます。(The GitHub Blog)
この機能は、複数のエージェント作業を並行して進めるチームほど効果があります。
たとえば、次のような場面です。
- あるセッションでテスト追加を依頼し、別セッションでリファクタリング案を作らせる
- Copilot CLI agentと通常のAgent modeの作業状態を見分ける
- キューに入っている作業と実行中の作業を確認する
- 終了した作業の変更概要を見て、レビュー対象を決める
エージェント機能は便利ですが、「何を頼んだか」「今どこまで進んでいるか」が見えにくいと、逆に作業管理が難しくなります。統合セッション表示は、Copilotをチーム開発の作業フローに入れるうえで重要な改善です。
Ask question toolで曖昧な依頼による失敗を減らせる
Agent modeにはAsk question toolも追加されました。これは、エージェントが追加情報を必要としたときに、焦点を絞った確認質問を行える機能です。公式情報では、Agent mode、custom agents、sub agents、Copilot CLI agentでサポートされ、Ask modeでは利用できないとされています。(The GitHub Blog)
実務でAIエージェントが失敗しやすい原因の一つは、依頼が曖昧なまま作業を進めることです。
たとえば、次のような依頼は失敗しやすいプロンプトです。
ログイン周りを直してこのままだと、UIの問題なのか、APIの認証エラーなのか、セッション管理なのか、テストの失敗なのかが分かりません。
Ask question toolがあることで、エージェント側から「対象はフロントエンドですか、バックエンドですか」「再現条件はありますか」「既存テストを先に確認しますか」といった確認が入りやすくなります。結果として、不要なファイル変更や見当違いの修正を減らせます。
グローバル.agent.md対応でチーム標準を使い回しやすくなる
今回の更新では、ワークスペース単位の設定に加えて、~/.copilot/agents配下の.agent.mdによるグローバルなカスタムエージェント定義がサポートされました。これにより、複数のワークスペースで同じエージェント定義を使いやすくなります。なお、GitHubはグローバルエージェントを製品内で管理する機能について、今後のリリース予定として案内しています。(The GitHub Blog)
活用しやすい例は次のとおりです。
| エージェント定義の例 | 使い道 |
|---|---|
| コードレビュアー | セキュリティ、可読性、命名、例外処理の観点で差分を確認する |
| テスト作成担当 | 既存テストのスタイルに合わせてユニットテストを追加する |
| 移行支援担当 | フレームワークやライブラリ更新時の影響範囲を調査する |
| ドキュメント担当 | コード変更に合わせてREADMEや内部ドキュメントを更新する |
ただし、グローバル設定は便利な反面、すべてのプロジェクトに同じ指示が効いてしまいます。会社標準の命名規則やレビュー観点はグローバルに置き、プロジェクト固有の制約はリポジトリ側の指示ファイルに置く、という分け方が現実的です。
GHES利用企業ではサインイン導線も確認しておく
GitHub Enterprise Server、つまりGHESを使っている企業では、サインインフローの改善も重要です。今回の更新では、サインイン時に「Continue with GitHub Enterprise」を選び、enterprise typeを選択して、ホスト名またはURLでEnterpriseインスタンスへ認証できるようになったと案内されています。(The GitHub Blog)
管理者は、展開前に次の点を確認しておくとトラブルを減らせます。
| 確認項目 | 見るべきポイント |
|---|---|
| GHESのURL | 開発者が入力すべきホスト名・URLを明確にする |
| 認証方式 | SSOや社内IdPとの連携で追加手順がないか確認する |
| ネットワーク | 社内VPN、プロキシ、証明書の影響を確認する |
| サポート窓口 | サインインできない場合の問い合わせ先を決める |
特に大規模組織では、機能そのものよりもサインインやポリシー設定でつまずくことが多くあります。リリース告知だけでなく、社内向けの短い利用手順を用意しておくと定着が早くなります。
管理者が最初に確認すべき設定
GitHub Copilot BusinessまたはGitHub Copilot Enterpriseで利用している場合、今回のCopilot CLI agent機能を使うには、管理者側の設定確認が欠かせません。公式Changelogでは、BusinessまたはEnterpriseの契約者がこの機能を使うには、管理者がEditor preview features policyを有効にする必要があると説明されています。(The GitHub Blog)
また、GitHub Docsでは、組織やEnterpriseでCopilotの機能・モデルの可用性をポリシーで制御できること、プレビュー段階の一部機能はEditor preview featuresポリシーで制御されることが説明されています。(GitHub Docs)
| 設定 | 確認する理由 | 推奨アクション |
|---|---|---|
| Editor preview features | Public Preview機能の利用可否に関わる | まず小規模チームで有効化し、動作確認後に広げる |
| Copilot CLI policy | CLI自体が無効だと利用できない可能性がある | EnterpriseまたはOrganizationのAI controlsで確認する |
| モデル利用ポリシー | 開発者が使えるモデルが制限される | 許可モデルと用途を明文化する |
| MCPポリシー | 外部ツール連携やMCPサーバー利用に関わる | 承認済みMCPサーバーのみ許可する |
| Copilot seat割り当て | 利用者にCopilotのシートが必要 | 対象者のライセンス割り当てを確認する |
| 監査ログ | ポリシー変更の追跡に必要 | 変更者、変更日時、対象ポリシーを確認できる体制にする |
GitHub Docsでは、Copilot CLIはEnterpriseまたはOrganizationレベルで有効・無効を制御でき、モデル選択、カスタムエージェント、MCPポリシー、監査ログ、シート割り当てなどが関係すると説明されています。(GitHub Docs)
Copilot CLIの導入条件とインストール方法も確認する
JetBrains IDEからCopilot CLI agentを使う場合でも、前提としてCopilot CLIの利用条件を満たしている必要があります。GitHub Docsでは、Copilot CLIはすべてのCopilotプランで利用可能で、Organization経由で利用している場合は組織設定でCopilot CLIポリシーが有効である必要があると説明されています。(GitHub Docs)
インストール方法は環境によって異なります。公式Docsでは、WindowsではWinGet、macOSとLinuxではHomebrew、全プラットフォームではnpm、macOSとLinuxではインストールスクリプトが案内されています。npm利用時はNode.js 22以降が前提です。(GitHub Docs)
代表的な導入方法は次のとおりです。
npm install -g @github/copilotwinget install GitHub.Copilotbrew install copilot-cli管理者が社内展開する場合は、開発者に自由に導入させる前に、次の3点を決めておくと安全です。
| 決めること | 理由 |
|---|---|
| 推奨インストール方法 | npm、Homebrew、WinGetが混在するとサポートしづらい |
| 更新タイミング | Preview機能では挙動変更が起きやすいため |
| 問い合わせ先 | IDE、CLI、認証、ネットワークの問題を切り分けるため |
セキュリティとガバナンスで注意すべきポイント
Copilot CLI agentは便利ですが、通常のコード補完よりも広い範囲のファイル変更やコマンド実行に関わる可能性があります。そのため、管理者と開発者は「何を許可し、何をレビューするか」を明確にする必要があります。
GitHubのCopilot CLIベストプラクティスでは、破壊的な操作には明示的な承認が必要であること、提案された変更を受け入れる前にレビューすること、権限のallowlistを慎重に使うこと、秘密情報をコミットしないことが注意点として示されています。(GitHub Docs)
特に重要なのは、Copilot CLIに適用される管理ポリシーと、適用されない管理ポリシーの違いです。GitHub Docsでは、Copilot CLIに対して、IDE固有ポリシー、ファイルパスベースのContent exclusions、ユーザー設定のモデルプロバイダーに関する一部制御が適用されない旨が説明されています。(GitHub Docs)
つまり、「IDE側で除外設定をしているからCLI agentでも同じように守られる」とは考えない方が安全です。機密ファイル、顧客データ、秘密鍵、社内限定の設計資料などを扱うリポジトリでは、Copilot CLI agentの利用範囲を先に整理してください。
開発者向け：安全に試すための手順
開発者が今回の機能を試すなら、いきなり本番ブランチや大規模変更で使うのは避けるべきです。最初は小さなタスクで、変更範囲を確認しやすい使い方から始めると失敗が少なくなります。
| 手順 | やること | 失敗しやすいポイント |
|---|---|---|
| 事前確認 | Gitの作業ツリーをクリーンにする | 未コミット変更とagentの変更が混ざる |
| プラグイン確認 | GitHub Copilot pluginを最新安定版に更新する | 古いバージョンで機能が表示されない |
| CLI確認 | copilotコマンドが使えるか確認する | PATH、認証、Node.jsバージョンで詰まる |
| 小さく依頼 | 1つの不具合修正やテスト追加から試す | 抽象的な依頼で意図しない変更が増える |
| isolation選択 | 初回はWorktree isolationを選ぶ | Workspace isolationで不要な変更が直接入る |
| 差分確認 | 変更ファイル、テスト、実行コマンドを確認する | 生成コードをそのままマージしてしまう |
| レビュー | 人間のレビューを必ず通す | AI生成コードの責任範囲が曖昧になる |
プロンプトも、できるだけ具体的に書くと精度が上がります。
悪い例です。
この機能を直して良い例です。
ユーザー登録フォームでメールアドレスが空のときにバリデーションエラーが表示されない問題を調査してください。
関連するコンポーネント、API、既存テストを確認し、最小限の修正案を作成してください。
変更はWorktree isolationで進め、最後に変更ファイルとテスト結果を要約してください。依頼には、対象、期待する結果、確認してほしい範囲、変更の大きさ、テストの要否を入れると、Copilot CLI agentの作業が制御しやすくなります。
チーム展開時のおすすめ運用
チームで展開する場合は、いきなり全開放するよりも、段階的に導入した方が安全です。
| フェーズ | 対象 | 目的 |
|---|---|---|
| 検証 | テックリード、数名の開発者 | IDE連携、認証、ポリシー、ログの確認 |
| 小規模展開 | 1チームまたは1プロジェクト | プロンプト例、禁止事項、レビュー基準を整備 |
| 標準化 | 複数チーム | .agent.md、利用ガイド、サポート手順を共有 |
| 本格展開 | 対象部門全体 | 利用状況、品質、レビュー負荷、コストを継続確認 |
評価指標は「Copilotを使ったかどうか」ではなく、開発プロセスにどう効いたかで見るべきです。たとえば、GitHub DocsのCopilot CLIベストプラクティスでは、IssueからPull Requestまでの時間、マージ前の反復回数、コードレビューのフィードバックサイクル、テストカバレッジ改善などが測定例として挙げられています。(GitHub Docs)
既存運用からの移行で注意すること
今回の更新では、Plan agentがsub-agent workflowで自動起動されなくなり、必要な場合はmode pickerから選ぶ形になったと案内されています。また、該当ChangelogではEdit mode supportの削除も記載されています。(The GitHub Blog)
既存の社内手順書や開発者向けガイドで、次のような記述がある場合は見直してください。
| 見直すべき内容 | 理由 |
|---|---|
| 「Plan agentが自動で動く」前提の説明 | 今回の変更で自動起動されない挙動が案内されている |
| Edit mode前提の操作手順 | 該当Changelogでsupport removedとされている |
| Agent modeとAsk modeの混同 | Ask question toolはAsk modeでは利用できない |
| IDE側の除外設定だけに依存した説明 | Copilot CLIでは適用されない制御がある |
| すべての開発者が同じ機能を使える前提 | プラン、ポリシー、モデル許可、シート割り当てで差が出る |
特に、社内Wikiに「Copilotの使い方」をまとめている企業では、IDE補完、Copilot Chat、Agent mode、Copilot CLI agentを分けて説明することをおすすめします。機能ごとの権限、得意な作業、レビュー基準が異なるためです。
今回の更新をどう活用すべきか
GitHub Copilot for JetBrains IDEsの今回の更新は、JetBrainsユーザーにとって大きな前進です。Copilot CLI agentをIDEから使えることで、複数ステップの開発作業を委任しやすくなり、統合セッション表示によって作業状態も追跡しやすくなりました。
ただし、Public Preview機能であること、管理ポリシーの確認が必要なこと、CLIにはIDE固有の制御がそのまま効かない場合があることを踏まえる必要があります。
まず管理者は、Editor preview features、Copilot CLI policy、モデル、MCP、シート割り当て、監査ログを確認してください。開発者は、最新のGitHub Copilot pluginとCopilot CLIを準備し、小さなタスクをWorktree isolationで試すところから始めるのが安全です。
この更新をうまく使えば、GitHub Copilotは単なるコード補完ツールではなく、調査、修正、テスト、レビュー準備まで支援する開発ワークフローの一部になります。最初の一歩として、チーム内で「どの作業をCopilot CLI agentに任せ、どの作業は人間が必ず判断するか」を決めておくと、導入効果と安全性のバランスを取りやすくなります。
コメント