AIコーディングが、昨日の続きになる。
同じリポジトリの説明を、毎回最初からやり直す。モデルを変えるたびに、使う場所も変わる。その小さな摩擦が、ひとつのアップデートで減り始めました。
「API層とUI層を分ける」
local provider
記憶が増えれば便利です。でも、古いルールが残ったままなら、便利さはそのまま誤解にもなります。このアップデートの価値は、記憶があることだけではなく、記憶を検証・削除できる範囲まで設計されていることにあります。
一つの更新に、四つの変化がある
「Memoryが追加された」という一行だけを見ると、単なる便利機能に見えます。実際の更新はもう少し広い。GitHubはJetBrains向けCopilotに、長期的な文脈、ローカルモデル、ターミナル、エージェントの観測性を同時に近づけました。
会話をまたいで覚える
リポジトリの事実や、ユーザーのコーディングの好みを後のAgentセッションで参照します。
モデルを持ち込める
OllamaをBYOKプロバイダーとして設定し、JetBrainsの体験の中でモデルを選べます。
端末との距離が縮まる
Copilot CLIを統合ターミナルから自動インストール。CodexのログやSkillsも扱いやすくなります。
つまり、AIを「質問に答える窓」から、プロジェクトの癖を持った作業相手へ近づける更新です。
ただし、GitHubが発表したのはJetBrains向けプラグインの機能追加です。すべてのCopilotクライアントが同じ日に同じ動作になる、という意味ではありません。
「覚える」は、二種類に分かれている
AIの記憶と聞くと、会話全体を丸ごと保存するイメージが浮かびます。Copilot Memoryの公式説明は、もう少し限定的です。
プロジェクトの事実
コーディング規約、アーキテクチャの判断、ビルドコマンド、プロジェクト固有のルールなど。リポジトリにアクセスできる利用者の範囲で使われます。
個人の好み
「変更前にテストを実行してほしい」のような、ユーザーごとの対話・作業の好み。別のリポジトリにも、そのユーザーのCopilot操作として適用されます。
根拠を確認する
リポジトリの事実には、それを支えるコードへの引用が付きます。現在のブランチで確認できた事実だけが使われます。
この区別は重要です。チームのルールと個人の好みは、似ているようで扱う責任が違うからです。さらに、使われない記憶は28日後に自動削除され、リポジトリの事実はオーナーが確認・削除できます。
Memoryは有料Copilotプラン向けの公開プレビューです。個人プランではデフォルトで有効、組織・Enterpriseでは管理者の許可後にユーザーがオプトアウトできます。
Ollama対応は、「全部ローカル」という意味ではない
BYOKは Bring Your Own Key の略で、サービス側が用意したモデルだけでなく、自分で用意したモデルやプロバイダーを接続する方式です。今回、JetBrains版CopilotでOllamaを選べるようになりました。
Ollamaは、PC上でモデルを動かすためのランタイムです。公式APIの既定URLは http://localhost:11434。つまり、対応モデルを自分のマシンに置き、IDEからそのモデルへリクエストを送る経路を作れます。
試作・学習・機密度の低い作業
モデルを自分で選びたい、外部APIの利用量を分けたい、ネットワーク境界を小さくしたい場合。
AgentとTool Calling
Copilot CLIの公式要件では、モデルにTool Callingとストリーミングが必要です。ローカルで動くことと、Agentとして十分に動くことは別です。
管理ポリシー
BusinessやEnterpriseでは、管理者がローカルBYOKを無効化できます。個人の設定だけで導入を決められない場合があります。
「Ollamaを選んだので、ソースコードが一切外へ出ない」とは断定しないでください。 モデル推論の経路と、Copilot Memory、MCP、クラウドAgentなど周辺機能のデータ経路は分けて確認する必要があります。
どんな仕事が、少しだけ軽くなるか
大きな自動化を始める必要はありません。毎回の説明を一つ減らすだけで、効果は見えます。
- 01参加したばかりのリポジトリ： README、ビルド手順、命名規則を調べたあと、Copilotがどの事実を参照したか確認する。
- 02レビューの往復： 「このプロジェクトではテストを先に実行する」という前提を毎回貼らず、Memoryの内容と根拠がまだ正しいか見る。
- 03モデルを比べる： 同じ小さな修正をGitHub-hosted modelとOllamaで試し、速度・修正量・失敗時の戻しやすさを比べる。
- 04端末へ移る： IDEの統合ターミナルからCopilot CLIを導入し、同じプロジェクト文脈でコマンド実行と差分確認を行う。
ここで大切なのは、モデルの“賢さ”を一回の回答で決めないことです。前提共有の手間、検証のしやすさ、失敗したときの復旧まで含めると、開発体験の差が見えます。
便利さの裏側に、三つの境界がある
- 公開プレビュー： Copilot Memoryは仕様変更の可能性があります。チームの正式なルールをMemoryだけに預けず、READMEや設定ファイルを正本として残す。
- 権限と秘密情報： Memory、MCP、Agentの権限は別々に確認する。APIキーや本番データを「覚えさせる」前に、保存・表示・削除の経路を確認する。
- ローカルモデルの限界： Ollamaはローカルで使えても、モデルがTool Callingに対応していなければAgent作業は成立しません。速度や品質はPCのメモリ、GPU、モデルサイズに左右されます。
- 古い記憶： 28日で消える仕様は安全弁ですが、重要な設計判断の代わりにはなりません。根拠のない記憶は削除し、正しいルールはコードとドキュメントに戻す。
今日試すなら、最初に一つだけ確認する
JetBrainsのGitHub Copilotプラグインを最新版へ更新し、Copilot Memoryの設定画面を開く。まず、現在のアカウントと組織でMemoryが有効か、どの種類の情報を保存・削除できるかを確認します。
Ollamaを試す場合は、いきなり本番リポジトリでAgentを走らせず、変更を戻せる小さな作業用ブランチから始めるのがよいでしょう。モデルを起動し、同じ修正を一度だけ比べる。それで十分です。
# 例: Ollama側の状態を確認
ollama serve
ollama ls
# JetBrains側では、CopilotのModel providerから
# Ollamaと対象モデルを選び、テスト用ブランチで実行する冒頭の問いへの答えは、こうです。 AIに任せる範囲が増えるほど、「何を覚えさせたか」と「どのモデルに送ったか」を人間が確認できる設計が必要になります。GitHubの今回の更新は、その確認をIDEの中へ持ち込んだ点に価値があります。