ニュース

GitHub Copilot CLI worktree対応|v1.0.78を検証

GitHub Copilot CLI worktree対応|v1.0.78を検証

この記事の結論

GitHub Copilot CLI worktree対応のv1.0.78を解説。実験的/new-worktreeとツール実行時間のライブ表示の使い方、暴走検知への効果、Claude Code・Cursorとの違いを整理します。

判断の分かれ目は「並行タスクの分離をどの層でやるか」に尽きます。エージェントCLIを2つ以上同時に走らせるとき、同じ作業ディレクトリのまま突っ込むのか、git worktreeで物理的にファイルを分けるのか。ここを曖昧にしたまま並行運用を始めると、片方のエージェントがもう片方の編集中ファイルを上書きする事故が起きます。検証環境で複数エージェントを並行運用していると、この「分離漏れ」が最も多いトラブル原因でした。

2026年8月3日にリリースされたGitHub Copilot CLI v1.0.78は、まさにこの分離をCLI本体に取り込むアップデートです。実験的コマンド/new-worktreeによるworktree分離と、ツール呼び出しごとの実行時間ライブ表示という2つの機能が入りました。Claude CodeやCursorが先行してきた領域にCopilot CLIが追いついてきた形で、どのツールで並行タスクを回すかの選定軸が変わります。リリースノートの原文を確認しながら、使いどころと他ツールとの違いを整理していきます。

v1.0.78で追加された2つの機能

公式リリースノート(2026年8月3日付)に記載された主要機能は次の2つです。

  • タイムラインヘッダーでのツール実行時間表示 — 原文は「Timeline headers show how long each tool call took, right-aligned and ticking live while it runs (for calls of at least 5 seconds)」。各ツール呼び出しの所要時間が右寄せで表示され、実行中はライブでカウントが進みます。対象は5秒以上かかる呼び出しで、デフォルトで有効。無効化は/settings showToolDurationsから行えます。
  • 実験的な/new-worktreeコマンド — 原文は「Add the experimental /new-worktree command to create a new worktree and start a new conversation in it」。新しいgit worktreeを作成し、その中で新しい会話を開始します。

1点注意があります。GitHub公式ブログの週次まとめ(2026年8月7日付)では、この機能を「the new experimental /worktree command」と表記しており、リリースノートの/new-worktreeと表記が揺れています。手元のバージョンでどちらのコマンド名が有効かは、CLI内で/を入力して補完候補を確認するのが確実です。実験的(experimental)機能なので、今後のリリースで名称や挙動が変わる可能性は織り込んでおきましょう。

Copilot CLIをエージェント基盤として評価している方は、7月末のAgent SkillsとMCPサポートのGA化と合わせて見ると、機能拡充のペースがつかめます。週次リリースの積み重ねで、CLIが単なる補完ツールからエージェント運用基盤へ寄っていく流れがはっきりしてきました。

目玉2つ以外で見逃せない変更

同じv1.0.78のチェンジログには20項目以上の変更が並んでいます。全部を追う必要はありませんが、並行運用・安全性の観点で効くものを拾っておきます。

変更 内容 実務への影響
/rewindのgit非依存化 gitリポジトリでなくても巻き戻し可能に。復元対象はCopilotが変更したファイルのみ git管理外のディレクトリ(設定ファイル置き場や検証用スクラッチ)でも安全網が効く
/permissionsコマンド追加 承認モード(approval mode)をセッション内で切り替え 信頼できる定型作業と慎重に見たい作業で、承認の厳しさを都度調整できる
サンドボックスのバイパス範囲を限定 サンドボックス回避の許可が現在のセッションのみに適用 一度の許可が永続化して安全境界が緩みっぱなしになる事故を防ぐ
セッション切り替え時のMCP維持 セッションを切り替えてもMCPサーバーが再起動されない 複数セッション運用時の待ち時間が減る。worktree分離との相性がよい
長いセッションの再開高速化 トランスクリプト読み込みの最適化で再開が大幅に高速化、長い履歴は段階的に描画 数日がかりのタスクを同一セッションで続ける運用が現実的になる

個別には小粒でも、方向性は一貫しています。「セッションを複数持つ」「長く持つ」「安全境界を細かく制御する」——いずれも並行・長期運用の足回りです。/new-worktreeが実験的に入ったのは思いつきではなく、この足回り整備の延長線上にあると読むのが自然です。逆に言うと、worktree分離を本格的に使う前提条件(セッション管理・承認制御)が同時に整備されている今のタイミングは、試し始めるにはちょうどよい時期です。

ツール実行時間のライブ表示が暴走・ハング検知に効く理由

一見地味な機能ですが、実運用では時間表示のほうが先に価値を発揮すると考えています。理由は、エージェントの異常は「出力」ではなく「時間」に最初に現れるからです。

エージェントCLIのツール呼び出しは、正常時なら数秒で返ります。ところが次のような異常系では、出力が止まったまま時間だけが過ぎます。

  • テスト・ビルドの無限待ち — watchモードのままテストコマンドを実行してしまい、プロセスが終了しない
  • 対話プロンプト待ちのハング — コマンドが確認入力(y/n)を待って停止している
  • ネットワーク待ちの滞留 — 外部APIやパッケージレジストリへの接続がタイムアウトせずに滞留
  • 意図しない大規模処理 — 想定よりはるかに広い範囲を対象にした検索や一括変換が走っている

これまでのCopilot CLIでは、こうした状態は「なんか止まってる気がする」という感覚でしか検知できませんでした。v1.0.78では、実行中のツール呼び出しにライブでカウントが進む時間表示が付くため、「このシェルコマンドはもう40秒走っている。普段は3秒で終わるやつだ」という異常検知が目視でできます。5秒未満の呼び出しには表示されない仕様も合理的で、正常系の高速な呼び出しで画面がうるさくならず、注意を向けるべき「長い呼び出し」だけが可視化されます。

公式ブログもこの機能の目的を「See live tool-call durations in the timeline to identify slow commands(遅いコマンドを特定するため)」と説明しています。表示が不要な場合は設定画面から切れます。

# CLI内で設定画面を開き、showToolDurations をオフにする
/settings

# 該当項目: showToolDurations(デフォルト: 有効)

実行時間の可視化は、コスト管理の入り口でもあります。長時間走るツール呼び出しはトークン消費や課金の増加に直結するため、「どの呼び出しが遅いか」を日常的に見る習慣は、マルチエージェント構成を組む前の基礎体力になります。

/new-worktreeで並行タスクを分離する手順

もう1つの目玉が実験的コマンド/new-worktreeです。git worktreeは、1つのリポジトリ履歴を共有したまま、別ブランチを別ディレクトリにチェックアウトできるgit標準機能です。/new-worktreeはこれをCLI内から実行し、作成したworktree内で新しい会話を開始します。

使いどころは「今の会話を汚したくない別タスクが割り込んできたとき」です。たとえばリファクタリングの途中でバグ修正の依頼が来た場合、同じディレクトリで作業を切り替えると、エージェントの編集が混線します。worktreeで分離すれば、ファイルもブランチも会話も別々になります。

# Copilot CLIのセッション内で実行
/new-worktree

# → 新しいworktreeが作成され、その中で新しい会話が始まる
# 元の会話・元のディレクトリの状態はそのまま残る

worktreeの状態確認と後片付けは、git標準コマンドで行えます。

# 現在のworktree一覧を確認
git worktree list

# 不要になったworktreeを削除
git worktree remove <worktreeのパス>

# 参照が残った場合の掃除
git worktree prune

動作環境: GitHub Copilot CLI v1.0.78以降、git導入済みリポジトリ。実験的機能のため、worktreeの作成場所やブランチ命名などの細部は公式ドキュメントで最新仕様を確認してください。

注意: 本番運用のリポジトリで使用する前に、必ず検証用リポジトリで動作確認してください。worktreeの削除はディレクトリごと消えるため、未コミットの変更が残っていないかをgit statusで確認してから削除するのが安全です。

Claude Code・Cursorの同種機能とどう違うか

worktreeによる並行タスク分離は、Copilot CLIの発明ではありません。Claude CodeとCursorはすでに同種の機能を持っており、成熟度には差があります。公式ドキュメントで確認できる範囲を比較します。

観点 GitHub Copilot CLI v1.0.78 Claude Code Cursor
起動方法 セッション内の/new-worktree(実験的) 起動時の--worktree-w)フラグ、またはセッション内で依頼 /worktreeコマンド、Agents Windowからの並列起動
作成場所・命名 公式ドキュメントに明記された仕様は確認中(実験的機能) .claude/worktrees/<name>/配下、ブランチ名worktree-<name> Cursorが自動管理。.cursor/worktrees.jsonでセットアップをカスタム可能
サブエージェント分離 該当機能なし(本体会話の分離のみ) サブエージェント定義にisolation: worktreeを指定して常時分離可能 並列エージェントごとに自動でworktreeを割り当て(最大8並列)
後片付け git標準コマンドで手動管理 セッション終了時に未変更なら自動削除、変更ありなら確認プロンプト。定期スイープあり Cursor側で自動管理
成熟度 実験的(2026年8月導入) 安定機能として公式ドキュメントに詳細仕様あり 安定機能(Cursor 2.0以降の並列エージェント基盤)

公平を期すと、この観点ではClaude CodeとCursorが明確に先行しています。Claude Codeは分離の強制(worktree内セッションからメインチェックアウトへの書き込みをブロックする仕組み)まで公式ドキュメントに明記されており、分離の「破れ」への対処も進んでいます。この分野でどんな穴が問題になるかは、Claude Codeがサブエージェントのworktree分離の穴を塞いだ事例が参考になります。分離機能は「作れる」ことより「破れない」ことが本題で、Copilot CLIの実装がそこまで踏み込むかは今後の観察ポイントです。

一方でCopilot CLIが有利なのは、GitHub Copilotのサブスクリプション内で完結する点です。すでにCopilot Business/Enterpriseを契約している組織なら、追加契約なしでworktree分離を試せます。「まず今ある契約の範囲で並行タスク分離を体験し、要件が高度化したらClaude CodeやCursorの成熟した実装を検討する」という順番が、2026年8月時点では現実的な判断だと考えています。

導入と設定の手順

Copilot CLIをこれから入れる場合の手順です。前提はNode.js 22以降と、GitHub Copilotのサブスクリプションです。

# インストール(npmグローバル)
npm install -g @github/copilot

# .npmrcで ignore-scripts=true にしている場合
npm_config_ignore_scripts=false npm install -g @github/copilot

# 起動
copilot

# 初回はCLI内で認証
/login

導入後にv1.0.78の新機能を確認する流れは次のとおりです。

  • 適当なタスクを依頼し、5秒以上かかるツール呼び出しの右側に経過時間がライブ表示されることを確認する
  • 表示が不要なら/settingsからshowToolDurationsを無効化する
  • gitリポジトリ内で/new-worktree(環境によっては/worktree)を実行し、新しいworktreeと新しい会話が開始されることを確認する
  • 作業後はgit worktree listで残存worktreeを確認し、不要なものをgit worktree removeで削除する

注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。特に実験的機能はバージョンアップで挙動が変わる前提で運用に組み込むべきです。

【要注意】よくあるつまずきと対策

つまずき1: worktreeを作りっぱなしにする

/new-worktreeを試すたびにworktreeが増え、どれが現役か分からなくなる
⭕ タスク完了時にgit worktree listで棚卸しし、マージ済みのものは即削除する

なぜ重要か: worktreeは1つごとに作業ツリー全体のディスクを消費し、ブランチも増え続けます。Claude Codeのような自動クリーンアップはCopilot CLIの実験的実装には期待できないため、手動の棚卸し習慣が必須です。

つまずき2: worktree内で依存関係を入れ忘れる

❌ 新しいworktreeでいきなりビルドを依頼して、依存関係エラーで時間を溶かす
⭕ worktreeは「まっさらなチェックアウト」と捉え、最初にnpm install等のセットアップを実行する

なぜ重要か: worktreeはファイルを共有しません。node_modules.envのようなgitignore対象は新しいworktreeには存在しないため、セットアップを省くとエージェントがエラーの海で迷走します。これは前節のツール実行時間表示で「やけに時間がかかっている」として検知できる典型例でもあります。

つまずき3: 実験的機能を固定仕様として運用に組み込む

/new-worktree前提の運用手順書を書いて全員に配布する
⭕ コマンド名・挙動が変わる前提で、手順書にはバージョンと参照日を明記する

なぜ重要か: 現時点でもリリースノート(/new-worktree)と公式ブログ(/worktree)で表記が揺れています。experimentalラベルの機能は、リネーム・仕様変更・廃止のすべてがあり得ます。

よくある質問

ツール実行時間の表示はすべての呼び出しに出ますか?

いいえ。リリースノートの記載では、5秒以上かかるツール呼び出しが対象です。短時間で終わる正常な呼び出しには表示されず、時間のかかる呼び出しだけが可視化されます。デフォルトで有効、/settingsshowToolDurationsで無効化できます。

/new-worktreeはgitがないディレクトリでも使えますか?

worktreeはgitの機能なので、gitリポジトリであることが前提です。なお同じv1.0.78で、/rewindのほうはgit不要で動作するようになりました(Copilotが変更したファイルのみ復元)。「巻き戻しはgit不要、worktree分離はgit必須」と覚えておくと混乱しません。

Claude CodeやCursorからCopilot CLIに乗り換えるべきですか?

worktree分離だけを理由にした乗り換えは推奨しません。分離機能の成熟度は現時点でClaude Code・Cursorが上です。逆に、すでにCopilotを契約していて並行タスク分離を試したい場合は、追加コストゼロで始められるCopilot CLIが第一候補になります。

手動でgit worktree addした場合と何が違いますか?

作られるworktree自体は同じgit標準機能です。違いは会話の扱いで、/new-worktreeはworktree作成と同時に新しい会話を開始するため、元のタスクの文脈と割り込みタスクの文脈が混ざりません。手動でgit worktree addしてからCLIを起動し直しても同等のことはできますが、ターミナル移動と起動の手数が増えます。逆に、既存の特定ブランチからworktreeを切りたいなど細かい制御が必要な場面では、手動のgit worktree addのほうが確実です。

結論

冒頭の軸に戻ります。並行タスクの分離をどの層でやるか——v1.0.78によって、Copilot CLIでも「CLI内からのworktree分離」という選択肢が持てるようになりました。時間表示とworktree分離は独立した機能に見えて、実は同じ問題(複数タスク・長時間タスクをエージェントに任せたときの制御可能性)への回答です。走っているものを時間で監視し、走らせる場所をworktreeで分ける。この2つが揃うと、エージェントCLIは「1タスクずつ順番に頼む道具」から「複数タスクを並行で預ける基盤」に近づきます。

試す順番としては、まず時間表示で自分のワークフローの「遅い呼び出し」を把握し、次に割り込みタスクが来たタイミングで/new-worktreeを1回使ってみる。worktreeの棚卸しまで習慣化できたら、並行度を上げていく。実験的機能である点だけ忘れずに、小さく始めるのが確実です。

あわせて読みたい:

参考・出典

この記事を読んで導入イメージが固まってきた方へ

UravationではAIエージェント導入の研修・コンサルを行っています。

Need help moving from reading to rollout?

この記事を読んで導入イメージが固まってきた方へ

Uravationでは、AIエージェントの要件整理、PoC設計、社内導入、研修まで一気通貫で支援しています。

この記事をシェア

X Facebook LINE

※ 本記事の情報は2026年8月時点のものです。サービスの料金・仕様は変更される可能性があります。最新情報は各サービスの公式サイトをご確認ください。

関連記事