追加されたのは「分ける」機能

GitHub Copilot の週次リリース (2026 年 8 月 7 日公開) に、複数のサーフェスへまとめて機能が入りました。

揃っているか・崩れないかという観点で並べ直すと、今回の追加はどれも「作業を分ける」方向 です。本筋と脇道を分ける、作業環境を分ける、状態を戻せるようにする。

サーフェス追加されたもの
Desktop app/side、Auto のモデル表示
CLI/worktree (実験的)、/rewind の改善
VS Code 1.132/btw

順に見ていきます。

本筋を止めずに聞ける

いちばん使う場面が想像しやすいのが、/side と /btw です。どちらも 本筋の作業を止めずに別の質問をする ための機能です。

VS Code 側の説明を引きます。

Ask side questions with /btw...without interrupting the agent's current turn.

エージェントが動いている最中でも、割り込まずに聞けます。 Desktop app では /side が同じ役割です。

なぜこれが要るか

作業中に別のことを聞きたくなる場面は、思っている以上に多くあります。「そういえばこの書き方でよかったか」「さっきのファイルはどこだったか」。

これまでは、選択肢が 2 つしかありませんでした。今の流れの中で聞くか、別の会話を立てるか。

前者は、本筋の文脈に関係のない話が混ざります。あとから読み返したときに、何の話をしていたのか分かりにくくなります。 後者は、前提を渡し直す手間がかかります。

脇道として分けられると、この間が取れます。本筋は本筋のまま残り、聞きたいことも聞けます。

コツ

効いてくるのは、あとから読み返すときです。本筋の流れが混ざらないと、経緯を追いやすくなります。1 人で使っていても、翌日の自分が読む場面で差が出ます。

整理として見ると

この機能は、Claude Code 側で先に入っていた会話の分岐や、GitHub Copilot 自身の peer chat と近い方向にあります。どのツールも、1 本の会話にすべてを詰め込む形から離れつつあります。

理由は単純で、1 本にまとめるほど読み返しにくくなるから です。長い会話の中から必要な部分を探す作業は、それ自体が時間を食います。

揃えておくと後が楽なのは、この使い分けです。本筋に関係する話は本筋へ、関係しない話は脇道へ。 最初は意識が要りますが、慣れると自然に分かれます。

作業環境を分ける

CLI には、実験的な /worktree が入りました。

Create an isolated worktree and begin a separate conversation with the new experimental /worktree command.

独立した作業環境を作って、そこで別の会話を始められます。 本体の作業に影響を与えずに、別のことを試せる形です。

用途としては、次のような場面が考えられます。

  • 今の変更を保ったまま、別のやり方を試したい
  • 長く動かす作業と、短い確認作業を並行させたい
  • 壊れてもよい環境で、思い切った変更を試したい

ただし 実験的な位置づけです。 本番の作業で頼り切るのは早い段階だと考えます。挙動が変わる可能性がある前提で触ってください。

分離が効く条件

作業環境を分ける機能は、分けた先が本当に独立しているかで価値が決まります。 分けたつもりで本体に影響が及ぶなら、分ける意味がありません。

この点は、他のツールでも過去に問題になった箇所です。「分離しているはず」が実際には効いていなかった、という不具合は現実に起きています。

実験的な機能を試すときは、本体に影響が出ていないかを最初の数回だけ確認してください。 慣れてから確認しても遅くはありませんが、最初の 1 回で見ておくほうが安心して使えます。

VS Code 側のその他の変更

VS Code 1.132 には、/btw 以外にも入っています。細部ですが、日々の使い勝手に効く部分です。

音声入力が、既定で端末上の多言語モデルを使うようになりました。 手を止めずに指示を出したい場面で効きます。端末上で処理されるので、話した内容がそのまま外へ出る形にはなりません。

Markdown の差分を、実験的なハイブリッドエディタで開けるようになりました。 文章の差分は記号だけの表示だと読みにくく、実際にどう変わるのかが掴みにくい部分です。ここが読みやすくなると、文書の変更を確認する回数が増えます。

後者は、コードより文書を多く扱う人に効きます。 仕様書や手順書を AI に直させている場合、差分の読みやすさがそのまま確認の質になります。

状態を戻せる範囲が広がった

/rewind は以前からありましたが、Git が無い環境でも使えるようになりました。

Use /rewind without Git to restore the conversation and files Copilot changed.

戻せるのは、会話と Copilot が変更したファイルです。Git で管理していない場所での作業や、まだ初期化していないディレクトリでも巻き戻せます。

小さな変更に見えますが、使える場面は広がります。 ちょっとした調べもの用のディレクトリや、設定ファイルだけを置いた場所など、Git を入れていない場所は現実に多くあります。

FIXITFIXIT

こんなに一度に増えると、覚えきれないんだけど。

IrodoriIrodori

全部は要りません。使う場面が来たときに思い出せれば十分です。

FIXITFIXIT
どれから試すのがいい？
IrodoriIrodori

本筋を止めずに聞けるものが、いちばん分かりやすいと思います。

セッションを並べて管理できる

CLI には、複数の会話を管理するサイドバーも入りました。同時に走らせている会話を一覧から扱えます。

Desktop app 側でも、関連するセッションをグループ化して並べ替えられるようになっています。どちらも、会話が増えたときに探せなくなる問題への対処 です。

実際、並行して作業する使い方が一般的になると、「さっきの会話がどれか分からない」という状態が起きます。 名前も付いていない会話が 10 個並ぶと、開いて確かめるしかありません。

一覧から扱えると、この探す時間が消えます。地味ですが、並行して使うほど効いてきます。

コツ

会話が増えると分かっているなら、始めるときに名前を付けておく のがいちばん効きます。一覧の見やすさは、機能より付けた名前で決まります。

Auto が何を使ったか見える

もう 1 点、性質の違う変更があります。Desktop app で、Auto が実際にどのモデルで処理したかを表示する ようになりました。

Auto now shows which model handled each completed request, plus AI credit and cache details when they're available.

AI クレジットとキャッシュの情報も、取得できる場合は一緒に出ます。

これは 切り分けに効きます。 Auto に任せていると、結果に差を感じたときに原因が分かりません。速かったのか遅かったのか、どのモデルだったのか。表示されると、そこが判断材料になります。

費用の面でも同じです。どのモデルがどれだけ使われているかが見えると、想定と違う配分になっていたときに気づけます。

揃っているかという観点で言えば、「任せているけれど何が起きたかは分かる」状態のほうが健全です。 任せることと、見えないことは別であるべきです。

どこから試すか

一度に増えると、どれから触ればよいか迷います。使う場面が想像できるものから試すのが確実です。

機能試す優先度理由
/side /btw高い日常的に発生する場面がある
Auto のモデル表示高い何もしなくても効く
/rewind中程度必要になったときに思い出せば足りる
/worktree低い実験的。用途がはっきりしてから

Auto のモデル表示は、意識しなくても効きます。 表示されるようになるだけなので、覚えることがありません。

いちばん下は急がなくて構いません。実験的な機能を早く触る必要があるのは、それで解ける困りごとが今ある場合だけです。

週次で機能が増えることの扱い

Copilot は週次でリリースが出ます。毎回追いかけるのは現実的ではありません。

揃えておくと後が楽なのは、追う頻度と観点を決めておく ことです。

頻度見るもの
週次見なくてよい
月に 1 度まとめて眺めて、使えそうなものを拾う
随時期限のある変更・廃止だけは即座に

いちばん下だけ切り分けてください。モデルの廃止や仕様の変更は、放置すると動かなくなります。 機能の追加は、知らなくても困りません。

この切り分けをしておくと、週次のリリースノートを開かなくても実務が回ります。 実際、今回追加された機能はどれも「知らなくても今までどおり使える」ものです。

なお、同じ月に Copilot ではモデルの廃止も予定されています。そちらは期限があるので、こちらは見てください。詳細は GitHub Copilot で 6 モデルが 9/1 廃止 にまとめています。

覚えることを増やしすぎない

最後に、道具の使い方全般の話をします。機能が増えるたびに全部覚えようとすると、かえって手が止まります。

現実的なのは、困ったときに「そういえば何かあった気がする」と思い出せる状態 です。そこから調べれば間に合います。

そのために効くのは、増えた機能を 「何のための機能か」でまとめておく ことです。今回なら「作業を分けるもの」でひとまとまりになります。個別のコマンド名を覚えるより、こちらのほうが残ります。

チームへ共有するときも同じです。コマンド名を並べるより、「本筋を止めずに聞けるようになりました」と書くほうが伝わります。 使い方の説明は、必要になった人が調べれば足ります。

Copilot を使い込む側の話は GitHub Copilot を実プロジェクトで使い倒す 6 つのポイント に、同時期に入った画像対応は Copilot Vision が正式提供に にまとめています。

なお、同じ時期に Kimi K3 も Copilot で選べるようになりました。機能とモデルは別軸の変化ですが、どちらも「選べる幅が広がった」という点では同じです。 そちらは Kimi K3 が GitHub Copilot で使えるようになった を参照してください。

まとめ

  • 今回の追加はどれも「作業を分ける」方向。本筋と脇道、作業環境、状態の巻き戻し
  • /side (Desktop app) と /btw (VS Code) で、本筋を止めずに別の質問ができる
  • CLI の /worktree は実験的。独立した作業環境で別の会話を始められる
  • /rewind が Git 無しでも使えるようになり、対象の場所が広がった
  • Auto が実際に使ったモデルを表示するようになり、差を感じたときの切り分けができる
  • 全部覚えなくてよい。「何のための機能か」でまとめておけば、必要なときに思い出せる
  • 週次リリースは追わなくてよい。期限のある変更と廃止だけ切り分けて見る