1. はじめに

GitHub Copilot app では、設定の Manage sessions からセッションやチャットをまとめてアーカイブまたは削除できます[^agent-sessions]。どちらも通常の一覧から対象を片付ける操作に見えるため、「何が残るのか」「後から戻せるのか」が分かりにくいのが実情です。

この記事を作成する背景は、操作手順が GitHub Docs に、worktree や未コミット変更の扱いが GitHub Copilot app の公式 changelog に分かれて記載されていることです。この記事の目的は、2026 年 8 月 27 日時点の公式情報を基に両者の違いを整理し、安全な選び方を示すことです。

2. 削除とアーカイブの違い

結論から言えば、再開する可能性があればアーカイブ、セッションを恒久的に片付けるなら削除です。

観点アーカイブ削除
主な目的一覧を整理し、必要なら後で再開する不要なセッションを恒久的に片付ける
セッションの復元公式 changelog で復元機能を確認できるUI から復元する公式手順は確認できない
worktree ベースの作業領域worktree を削除し、復元用の状態を保持するworktree を削除する
未コミット・未追跡ファイル復旧用 Git ref へ退避され、復元時に自動で戻る削除前に退避されるが、復旧は手動の Git 操作になる場合がある
ディスク容量worktree は片付くが、履歴を含む総容量の削減量は明記されていない削除画面に回収予定のローカル容量が表示される

この表の worktree に関する記述は、new working tree を使うセッションが対象です。GitHub Copilot app は、セッションの実行場所として new working tree、ローカルリポジトリ、cloud sandbox を選べるため、すべてのセッションがローカル worktree を持つわけではありません[^agent-sessions]。

3. サブセッションと別セッションの違い

GitHub Copilot app では、複数の会話が並んでいても、その関係は同じとは限りません。本記事では、公式情報の child session と nested session をまとめて「サブセッション」と呼びます。

観点サブセッション別セッション
作り方親セッションから /spawn [PROMPT] などで作るサイドバーの Sessions にある + から新規に始める
関係親子関係があり、サイドバーでは親の配下に表示される親を持たないトップレベルの作業単位
主な用途親の作業から切り出した調査・実装・検証を委譲する親の文脈に依存しない別タスクを進める
片付け親のアーカイブ・削除時に、子も一緒に処理するか確認されるほかのセッションとは独立してアーカイブ・削除する

3.1 サブセッションは親から委譲する作業単位

/spawn [PROMPT] は、限定した作業を委譲する child session を作るコマンドです。公式 changelog では、この親子関係を nested session と表現し、サイドバーに階層線を表示することや、親をアーカイブ・削除するときに子も一緒に処理するか確認することが記録されています[^app-slash-commands][^app-changelog]。

サブセッションは、1 つの目的を分担するときに向いています。たとえば、親セッションで機能実装を進めながら、子セッションへテスト調査だけを委譲する使い方です。親の作業と無関係なタスクまで子にすると、片付けるタイミングが不要に連動するため、別セッションのほうが管理しやすくなります。

3.2 別セッションは独立したトップレベルの作業単位

通常の新規セッションは、サイドバーの Sessions にある + から開始し、実行場所やモード、モデルを個別に選びます[^agent-sessions]。親子関係を持たないため、ほかのセッションのアーカイブ・削除に連動しません。

別の issue、別の pull request、別の目的を扱うなら、サブセッションではなく独立したセッションが適しています。同じリポジトリを扱う場合でも、new working tree を選べば専用の作業領域とブランチで並行作業できます[^agent-sessions]。

3.3 /fork は会話を引き継いで分岐する

/fork は、現在のセッションを直近のターンで分岐させるコマンドです。分岐先は元の会話を引き継ぎ、/merge-to-parent で作業を元のセッションへ統合できます[^app-slash-commands]。

現在の公式 changelog では、forked session は親の配下ではなく、独立したトップレベル項目としてサイドバーへ表示されます[^app-changelog]。したがって、表示上は別セッションに近い一方、会話の出発点とマージ先を持つ点では完全に独立した新規セッションとも異なります。

使い分けは次のとおりです。

  • 親のタスクを分担する: /spawn でサブセッションを作る
  • 現在の会話から別案を試す: /fork で分岐する
  • 無関係なタスクを始める: Sessions の + から別セッションを作る

4. アーカイブすると何が起きるか

4.1 セッションを再開できる状態で片付ける

GitHub Docs は、Manage sessions でセッションやチャットを検索・絞り込みし、複数選択してアーカイブまたは削除できると説明しています。アーカイブしたチャットについては、同じ画面から復元できることも明記されています[^agent-sessions]。

アーカイブしたセッションの復元手順は GitHub Docs にまだ明記されていません。一方、公式 changelog には「アーカイブしたセッションの復元」や「アーカイブした workspace の復元」に関する修正が複数あり、セッションの復元機能が存在することは確認できます[^app-changelog]。

4.2 worktree と未コミット変更をどう扱うか

公式 changelog は、セッションをアーカイブまたは削除するとき、worktree を削除する前に未コミット・未追跡ファイルを復旧可能な Git ref へ退避すると説明しています。また、現在のアーカイブでは、退避した作業がセッションの復元時に自動で戻ります[^app-changelog]。

したがって、アーカイブは「worktree をそのまま残して一覧から隠す」操作ではありません。ローカルの作業領域を片付けながら、後でセッションを再開できる状態を保つ操作と捉えるのが適切です。

ただし、コミットや push の代わりになる保証機能として扱うべきではありません。重要な変更はアーカイブ前にもコミットし、必要ならリモートへ push しておくと、アプリの状態に依存せず復旧できます。

5. 削除すると何が起きるか

5.1 セッションを恒久的に片付ける

公式 changelog では、自動クリーンアップに「非アクティブなセッションの自動アーカイブ」と「アーカイブ済みセッションの恒久的な削除」が別々の設定として用意されています。この表現からも、削除はアーカイブ後の最終的なクリーンアップとして位置付けられています[^app-changelog]。

削除時は worktree が取り除かれ、確認画面には回収予定のローカルディスク容量が表示されます[^app-changelog]。削除したセッションを UI から復元する公式手順は確認できないため、削除は元に戻せない操作として判断するのが安全です。

5.2 退避があっても、コミットを優先する

削除前にも、未コミットの作業はバックアップされます。過去の changelog には、未コミット・未追跡ファイルを復旧用 Git ref へ保存し、復旧には手動の Git 操作が必要になる旨が記録されています[^app-changelog]。

ただし、復旧用 ref の保持期間や、現在の UI から復旧手順へ到達できるかは公式情報で確認できません。削除直前の退避は最後の安全網と考え、残したい変更は先にコミット・push します。

5.3 同期済みセッションデータは別に確認する

GitHub Copilot のセッションデータには、ローカルに保存されるデータと GitHub アカウントへ同期されるデータがあります。Copilot CLI の /session delete は、同期済みコピーも削除するか確認します。一方、GitHub Copilot app の Manage sessions から削除した場合に、同期済みコピーまで同時に削除されるかは、参照した公式手順では明記されていません[^cli-session-data]。

プロンプトや履歴をデータ保持の観点から削除したい場合は、アプリ内の操作だけで完了したと決めつけず、GitHub.com 上の同期済みデータも確認します。認証情報を貼り付けた場合は、保存先の確認より先に、その認証情報を無効化またはローテーションしてください。

6. どちらを選ぶか

6.1 アーカイブを選ぶ場面

  • pull request は完了したが、プロンプトや判断過程を後で参照したい
  • 一時的に作業を止めるが、再開する可能性がある
  • 一覧を整理したいが、削除してよいと判断できない

アーカイブ済みセッションの元ブランチが削除されていても復元に失敗しないよう改善された記録があるため、マージ済み pull request の作業履歴を残す用途にも適しています[^app-changelog]。

6.2 削除を選ぶ場面

  • セッションの履歴も作業領域も今後使わない
  • 必要な変更をコミット・push 済みである
  • ローカルディスク容量を明確に回収したい

削除画面の容量表示を確認し、対象セッションを取り違えていないことを確かめてから実行します。ネストしたセッションがある場合は、子セッションも一緒にアーカイブまたは削除するか確認されるため、確認ダイアログを読み飛ばさないようにします[^app-changelog]。

6.3 迷ったときのチェックリスト

  1. 後で会話や差分を見返す可能性があるなら、アーカイブする
  2. 残したい変更をコミットし、必要なら push する
  3. ネストしたセッションを一緒に処理してよいか確認する
  4. 削除後にセッションを戻せない前提で判断する
  5. 機密情報を含む場合は、認証情報の無効化・ローテーションと同期済みデータの確認を行う

7. Copilot cloud agent のセッションとは扱いが異なる

GitHub.com の agents panel で管理する Copilot cloud agent のセッションは、停止後にアーカイブできますが、削除はできません。公式ドキュメントは、GitHub Copilot app を含むローカルセッションだけが削除対象になると説明しています[^manage-agent-sessions]。

この記事で説明した削除とアーカイブは、GitHub Copilot app の Manage sessions を対象としています。GitHub.com の Copilot cloud agent セッションと、GitHub Copilot app から開始するセッションを混同しないようにしてください。

8. 公式情報だけでは分からない点

2026 年 8 月 27 日時点で、次の点は公開された公式情報だけでは確認できませんでした。

  • アーカイブしたセッションを復元する具体的な UI 手順
  • 削除前に作成される復旧用 Git ref の保持期間
  • Manage sessions での削除と同期済みコピー削除の連動
  • ローカルリポジトリまたは cloud sandbox で実行したセッションの、アーカイブ時の作業領域の扱い

重要な作業を片付ける前には、アプリに表示される最新の確認文を読み、公式ドキュメントと changelog の更新も確認してください。

9. まとめ

GitHub Copilot app のアーカイブは、worktree ベースの作業領域を片付けつつ、後でセッションを復元できる状態を残す操作です。削除は、不要になったセッションを恒久的に片付ける操作で、対応する UI 復元手順は確認できません。

未コミット変更の退避機能はありますが、コミットや push の代替ではありません。戻す可能性が少しでもあればアーカイブし、必要な変更を Git に残した後で削除することが、安全で分かりやすい使い分けです。

10. 参考情報

この記事の執筆にあたり、AI の支援を受けています。掲載内容は 2026-08-27 時点の GitHub 公式情報に基づきます。

[^agent-sessions]: Working with agent sessions in the GitHub Copilot app — GitHub Docs（確認日: 2026-08-27）

[^app-changelog]: Changelog — GitHub（確認日: 2026-08-27）

[^app-slash-commands]: Slash commands for the GitHub Copilot app — GitHub Docs（確認日: 2026-08-27）

[^cli-session-data]: About GitHub Copilot CLI session data — GitHub Docs（確認日: 2026-08-27）

[^manage-agent-sessions]: Managing agent sessions — GitHub Docs（確認日: 2026-08-27）