2026 年 9 月 10 日更新。8 月の memory・Ollama 対応に加えて、9 月のサンドボックス管理を追記しました。

8 月 11 日の追加機能

2026 年 8 月 11 日、GitHub Copilot for JetBrains に Copilot memory と Ollama の BYOK 対応 が追加されました。方向の違う 2 つが同時に入っているので、分けて見たほうがわかりやすいです。

追加何が変わるか
Copilot memoryチャットをまたいで前提や好みが引き継がれる
Ollama の BYOK手元で動かしているモデルを Copilot から使える
管理者向け設定プラグイン・MCP・権限・計測をサーバー側で決められる

memory は 説明の手間を減らす方向、Ollama は どこでモデルを動かすかを選べるようにする方向 です。組織で入れるなら、先に管理者向けの設定を見るのが早いと思います。

Copilot memory — 説明のやり直しが減る

公式の記述はこの一文です。

Copilot Memory can now retain and recall useful information across agent chat sessions

エージェントチャットのセッションをまたいで、情報を保持して呼び出します。狙いは changelog にはっきり書かれていて、毎回同じプロジェクトの前提を説明し直さずに済むこと です。

有効・無効は 設定ポータルの Copilot Memory トグル で切り替えます。個別のチャットごとに指定する形ではありません。

有効化する前に決めること

便利さと引き換えに、決めておく点が 2 つあります。

1 つ目は、何が残るかを利用者に伝えることです。 会話をまたいで残るということは、社外秘の前提を一度書けば後続のセッションでも参照されるということです。書いた本人が忘れたころに引き継がれる可能性があります。

2 つ目は、案件をまたぐ端末の扱いです。 複数のクライアントワークを 1 台で回している場合、前の案件の文脈が次の案件のチャットに持ち込まれる余地があります。ここは切り替えの運用を決めてから有効化するほうが安全です。

注意

memory は「便利になる機能」であると同時に「情報が残る機能」です。導入の可否を各自に任せると、案件の境界が人によって変わります。組織で使うなら既定を決めて配ってください。

Ollama の BYOK 対応 — 手元のモデルを Copilot から使う

もう 1 つが Ollama です。

You can now use Ollama as a BYOK provider in GitHub Copilot for JetBrains

BYOK (Bring Your Own Key) のプロバイダーとして Ollama を選べるようになりました。プロバイダーの設定とモデル選択が JetBrains 側の体験に組み込まれているので、IDE を離れずに切り替えられます。

刺さるのは次のような場面です。

  • 外部にコードを出せない対象を扱うとき
  • 手元のモデルの性能を、普段の作業のなかで確かめたいとき
  • 通信が細い環境で、補完の待ち時間を減らしたいとき

ただし、ローカルモデルにすれば自動で安全になるわけではありません。 どこで動くかが変わるだけで、何を入力してよいかのルールは別に要ります。この線引きは AI 駆動開発のセキュリティ に整理しました。

ローカルで動かすモデル自体の選び方は Gemma 4 12B を実務で使う が参考になります。

FIXITFIXIT

ローカルのモデルって、そんなに使えるの？

TsumikiTsumiki

用途しだいです。補完や短い書き換えなら十分な場面が増えてきました。

FIXITFIXIT

じゃあ全部それでよくない？

TsumikiTsumiki

重い設計変更は厳しいです。まず自分の作業で切り替えて比べるのが早いですよ。

管理者向けに増えた制御

組織で使っているなら、ここが一番効きます。サーバー側で一元管理できるようになったのは次の 4 つです。

  1. プラグインの可用性
  2. MCP サーバーへのアクセス
  3. 権限バイパスの挙動
  4. OpenTelemetry の設定

memory と Ollama をどう扱うかを議論する前に、そもそも各自の端末で何が有効にできる状態なのかを揃えるほうが先です。 個別の端末で閉じてもらう運用は、人数が増えるほど破綻します。

MCP サーバーへのアクセス制御が入ったのは、実務では大きいところです。MCP は接続先しだいで手が届く範囲が変わるので、組織として許可する先を決めておかないと、端末ごとに違う状態になります。

9 月 8 日発表 — エンタープライズ管理サンドボックス

GitHub は 2026 年 9 月 8 日、JetBrains 向けのサンドボックス管理をパブリックプレビューとして発表しました。管理者がサンドボックスの有効化、ファイルシステムとネットワークへのアクセス、プロキシ、開発者ツール、macOS Keychain へのアクセスなどを一元設定できます。GitHub の公式発表 に記載されています。

管理ポリシーは個人の設定より優先され、該当する IDE の設定項目はロックされます。利用者は、組織が管理している項目を画面で識別できます。

Sandbox が表示される条件

GitHub Copilot > Sandbox は、次のどちらかの条件を満たすと表示されます。

  • 組織が Editor Preview を有効にしている
  • 管理設定でサンドボックスの有効・無効を構成している

どちらも満たさない場合、設定画面は表示されません。画面が見えないときは、管理者が組織の設定を確認してください。詳しい設定手順は ローカルサンドボックス設定の公式ガイド を参照できます。

導入時に管理者が確認すること

本記事では、検証用のプロジェクトで次の順に確認することを勧めます。

  1. 必要なファイル、通信先、プロキシ、開発者ツールを一覧にする
  2. 組織の管理設定を適用し、IDE で対象項目がロックされているか確認する
  3. 必要なビルドやテストが実行でき、禁止したアクセスは拒否されるか確認する
  4. 同じ更新で追加された enterprise policy diagnostics を使い、端末がポリシーを検出・適用しているか確認する

9 月 9 日に一般提供された Copilot app / CLI / Agent Host 向けの管理権限とは、提供段階を区別してください。エージェント操作の承認ルールは AI 駆動開発のセキュリティ設計 で説明しています。

組織のアクセス制御や導入手順を整備したい場合は、AI 開発ツール導入支援 でご相談いただけます。

その他の変更 (8 月 11 日発表分)

細かい追加もまとめておきます。

  • Copilot CLI の自動インストールに対応した (macOS・Linux・Windows の統合ターミナルが対象)
  • Codex Workflow のセッション情報が、デバッグログで確認できるようになった
  • カスタマイズボタンがチャット上部へ、デバッグログのボタンがオプションメニューへ移動した
  • チャット内でのファイル・フォルダー参照が復活した

最後の 1 つは、使っていた人には戻ってきた形です。参照が効かない前提で書いていた手順書があるなら、そこは更新してください。

導入の順番

入れる順番としては、次の並びが無駄が少ないと思います。

  1. 管理者向け設定を確認する (プラグイン・MCP・権限・計測)
  2. memory の既定を決めて配る (案件をまたぐ端末の扱いを含めて)
  3. Ollama は使いたい人から試す (全社の既定にはしない)

3 番を全社の既定にしないのは、手元のモデルは端末の性能に左右されるため です。速い端末では快適でも、そうでない端末では待ち時間が伸びます。まず触ってみて、自分の作業で速くなるかを見てから広げるほうが定着します。

Copilot 全般の使いどころは GitHub Copilot を実務で使うときの勘所 にまとめています。モデルの選択肢そのものも短い周期で入れ替わっているので、あわせて MAI-Code-1.1-Flash が Copilot に追加 も参照してください。

まとめ

  • 9 月 8 日発表の管理サンドボックスはパブリックプレビュー。組織の制限が個人設定より優先される

  • Copilot memory が、エージェントチャットのセッションをまたいで情報を保持・呼び出せるようになった

  • 有効・無効は設定ポータルの Copilot Memory トグルで切り替える

  • Ollama が BYOK プロバイダーとして追加され、手元のモデルを Copilot から使える

  • 管理者はプラグイン・MCP サーバー・権限バイパス・OpenTelemetry をサーバー側で設定できる

  • Copilot CLI の自動インストール、チャット内のファイル参照の復活なども入っている

  • 導入は、管理者設定 → memory の既定 → Ollama の順が無駄が少ない