読み捨ての隔離（Read-and-Discard Isolation）

大量に読んで少しだけ持ち帰る仕事を、別のコンテキストに追い出す。捨てるのは読む過程で溜まった中間物であり、結果は要約として持ち帰る。成果を捨てるパターンではない。

問題

調べ物は、答えの何十倍もの中間物を生む。空振りした検索、開いて違ったファイル、候補のまま捨てた実装案 — どれも答えが出た時点で用済みになる。ところが読んだものは既定で積み上がり、エージェントには自分が読んだものを選んで取り消す術が無い。用済みの中間物は残り、以降のターンに毎回載り、本来の指示や制約を押しのける。「調査は終わった、実装しよう」と言った次のターンで、エージェントは調査の残骸ごと実装を始める。

コンテキスト

適用する条件:

読む量が持ち帰る量を大きく上回る — 探索、調査、影響範囲の洗い出し、レビュー
結果が数行に圧縮できる — 推奨、所在、可否の判断
中間物が後続で参照されない — 読んだこと自体には用がない

適用しないケース:

読んだものがそのまま後続の作業対象であるとき。編集するファイルの中身は、要約では編集の材料にならない
会話の経緯が判断に必要なとき。隔離したコンテキストは、それまでの見立ても制約も知らない
一度読めば済む小さな調べ物。境界を作ること自体にコストがある

隣接パターンとの境界:

委譲の損益分岐 — 隔離するという構造が本パターン、その値札が同パターン
セッション境界の設計 — 捨てる単位が会話そのものなら同パターン、会話の中の一区画なら本パターン
常駐物の棚卸し — 毎ターン載り続ける物を減らすのが同パターン、その場で急に膨らむ物を追い出すのが本パターン

解決

境界を越えられるのは、渡すタスクと持ち帰る要約という細い2本だけであり、その間で膨らむ中間物は隔離コンテキストごと消える。

なぜ効くのか。コンテキストを削る手立てが無いわけではない。しかし効くのは会話そのものを畳むか、全体を圧縮するかであり、いずれも粒度が会話まるごとである（この粗い側の設計が「セッション境界の設計」である）。

「この調査の残骸だけを落として、会話はそのまま続ける」という細かさでは働かない。細かく捨てたい対象 — 空振りした検索、違ったファイル — は、捨てたい単位が会話より小さいのに、道具の単位が会話なのである。

つまり**「読んでから、読んだものだけを消す」は選べない**。選べるのはどこで読むかである。

本パターンは、捨てたいものを最初から捨てられる場所で読ませる。使い捨てのコンテキストを立て、タスクだけを渡し、そこで好きなだけ読ませ、境界を一度だけ、要約の向きに通す。読んだものは境界を越えない。仕事が終われば、そのコンテキストは中間物ごと消える。主側から見れば、100ファイル読む調査も3行読む調査も、着地するのは同じ数行である。

効くのは非対称性があるときに限る。入力（読む量）が出力（持ち帰る量）を大きく上回るときだけ、境界を作るコストが割に合う。両者が近い仕事 — 読んだものをそのまま編集する類 — では、要約は情報を落とすだけで何も節約しない。適用条件を「大きいタスクかどうか」で判断すると外す。見るべきは大きさではなく比である。

境界の設計が品質を決める。隔離したコンテキストはこちらの経緯を知らない。渡すタスクが曖昧なら、何が重要かを判断できず、要約は薄くなるか的を外す。渡す側の責任は「短く渡す」ことではなく、何を答えれば十分かを明示して渡すことである。隔離は、うまく渡せたぶんだけ効く。

トレードオフ

利点

主コンテキストが調査量に比例して汚れない。 100ファイル読んでも主側に載るのは要約だけである。調査の規模と、その後の作業の余裕とを切り離せる。
「知らない」ことが利点に転じる。 経緯を受け取らないため、それまでの見立てに引きずられない。複数の視点を独立に得たいレビューでは、この無知そのものに価値がある。

代償

要約は不可逆な圧縮である。 何を落とすかを決めるのは隔離側であり、渡した側は落ちたものを見られない。要約が的を外していても、外したと気づく材料が主側に残らない。
境界には往復のコストがかかる。 立ち上げ、タスクの記述、結果の統合はタダではない。やり取りが増えれば消費も増える（後述のとおり公式も明記している）。小さな調べ物では、隔離のほうが高くつく。

GitHub Copilot での具体例

Copilot は単一の製品ではない。本パターンに対応する機構は VS Code と Copilot CLI の双方にあるが、人間がどこで介入できるかは面によって異なる。

VS Code — 主エージェントが要否を判断する

出典: Agents concepts（取得日: 2026-07-16）。同ページは subagent の第一の特徴を次のように定義している公式:

Context isolation: each subagent runs in its own context window. It doesn't inherit the main agent's conversation history or instructions. It receives only the task prompt.
Focused results: only the final result is returned to the main agent, keeping the main context focused and reducing token usage.
〔訳〕コンテキストの分離: 各 subagent は自分自身のコンテキストウィンドウで動作し、主エージェントの会話履歴や指示を継承しない。受け取るのはタスクのプロンプトのみである。焦点を絞った結果: 主エージェントに返されるのは最終結果のみであり、主コンテキストの焦点を保ちつつトークン使用量を減らす。

各 subagent は自分のコンテキストウィンドウで動き、主エージェントの会話履歴も命令も受け継がず、渡されるのはタスクのプロンプトだけである。返るのは最終結果だけである。「解決」で述べた境界が、そのまま製品の仕様として書かれている。

同ページは、この機構の目的が文脈の最適化であることを明言している公式:

Without subagents, every file read, search result, and intermediate step during research accumulates in the main agent's context window, potentially crowding out important information. Subagents perform their work in a separate context window and return only a summary, keeping the main conversation focused on the task at hand.
〔訳〕subagent が無ければ、調査中のあらゆるファイル読み取り・検索結果・中間の手順が主エージェントのコンテキストウィンドウに溜まり、重要な情報を押しのけかねない。subagent は別のコンテキストウィンドウで作業を行い、要約のみを返すことで、主となる会話を目下のタスクに集中させ続ける。

読んだもの・検索結果・中間の手順が主コンテキストに溜まり（accumulates）、重要な情報を**押しのけうる（crowding out）**という問題認識、および「別のコンテキストで作業し、要約だけを返す（return only a summary）」という解決 — 本パターンの「問題」節と「解決」節に一対一で対応する。

呼び出しの主体は主エージェントである（出典: Subagents in Visual Studio Code、取得日: 2026-07-16）公式:

Subagents are typically agent-initiated, not directly invoked by users in chat. To allow the main agent to invoke subagents, make sure the agent/runSubagent tool is enabled.
〔訳〕subagent は典型的にはエージェント主導で起動され、チャットでユーザーが直接呼び出すものではない。主エージェントが subagent を呼び出せるようにするには、agent/runSubagent ツールが有効になっていることを確認する。

人間の役割は、隔離を毎回命じることではなく、隔離が起こりうる状態を作っておくことである。プロンプトファイルから使う場合は、tools frontmatter に runSubagent または agent を含める。

同ページは渡し方についてこう書いている公式:

To optimize subagent performance, clearly define the task and expected output.
〔訳〕subagent の性能を最適化するには、タスクと期待される出力を明確に定義する。

「解決」で述べた渡す側の責任が、公式の推奨としても現れている。

探したが、無かった 不在確認

本カタログの初期メモには、この機構を #agent/runSubagent（# 付き）と表記し、「Run a task in an isolated subagent context」〔訳: 隔離された subagent のコンテキストでタスクを実行する〕という説明文を引く案があった。上記2ページ（Agents concepts と Subagents in Visual Studio Code）を 2026-07-16 に全文確認した結果、この文言はどちらにも無く、表記も # の付かない agent/runSubagent であった。よっていずれも採らない。

「無い」のは記述であって、機能ではない。 # 付き表記が誤りだと確認したわけではなく、確認したのは「この2ページには書かれていない」ところまでである。他の面や資料に存在する可能性は残る。

Copilot CLI — 人間が明示的に指示できる

出典: Creating and using custom agents for GitHub Copilot CLI（取得日: 2026-07-16）公式:

Work performed by a custom agent is carried out using a subagent, which is a temporary agent spun up to complete the task. The subagent has its own context window, which can be populated by information that is not relevant to the main agent. In this way, especially for larger tasks, parts of the work can be offloaded to custom agents, without cluttering the main agent's context window.
〔訳〕custom agent が行う作業は subagent を用いて実行される。subagent はタスクを完了するために立ち上げられる一時的なエージェントである。subagent は自分自身のコンテキストウィンドウを持ち、そこには主エージェントに関係のない情報を入れてもよい。こうして、特に大きなタスクにおいては、作業の一部を custom agent へオフロードでき、主エージェントのコンテキストウィンドウを散らかさずに済む。

subagent は使い捨て（a temporary agent spun up to complete the task）であり、主エージェントに関係のない情報で埋めてよい場所として定義されている。「読み捨て」の捨てる先がこれである。

CLI には、この非対称性をそのまま体現する組み込みエージェントがある（出典: About custom agents、取得日: 2026-07-16）公式:

task — A command execution agent that runs development commands (tests, builds, linters, formatters, dependency installs) and reports results efficiently. It returns a brief summary on success, and full output on failure, keeping the main context clean.
〔訳〕task: 開発コマンド(テスト・ビルド・リンター・フォーマッタ・依存関係のインストール)を実行し、結果を効率的に報告するコマンド実行エージェントである。成功時は簡潔な要約を、失敗時は全出力を返し、主コンテキストを綺麗に保つ。

成功時は要約だけ、失敗時は全出力。持ち帰る量を結果によって変えている。読み捨ててよいのは「うまくいったとき」だけであり、失敗したときは過程こそが情報である — という判断が製品に埋め込まれている。本パターンを実践するときの要約の設計にそのまま使える考え方である。

並列化は /fleet によって人間の側から指示できる（出典: Running tasks in parallel with the /fleet command、取得日: 2026-07-16）公式:

Context window: Each subagent has its own context window, separate from the main agent and other subagents. This allows each subagent to focus on its specific task without being overwhelmed by the full context of the larger task.
〔訳〕コンテキストウィンドウ: 各 subagent は、主エージェントや他の subagent とは別に、自分自身のコンテキストウィンドウを持つ。これにより各 subagent は、より大きなタスク全体の文脈に圧倒されることなく、自らの個別のタスクに集中できる。

ただし同ページは代償も明記している公式:

Each subagent can interact with the LLM independently of the main agent, so splitting work up into smaller tasks that are run by subagents may result in more LLM interactions than if the work was handled by the main agent. Using /fleet in a prompt may therefore cause more GitHub AI Credits to be consumed.
〔訳〕各 subagent は主エージェントとは独立に LLM とやり取りできるため、作業を subagent が実行する小さなタスクに分割すると、主エージェントが処理する場合より LLM とのやり取りが増えることがある。したがってプロンプト内で /fleet を使うと、より多くの GitHub AI Credits が消費されることがある。

隔離は無料ではない。公式が言っているのは「やり取りの回数が増えれば消費が増える」までであり、その損益をどう見積もるかは「委譲の損益分岐」で扱う。

面による違い

面	人間の介入点	出典
VS Code	主エージェントが隔離の要否を判断する。人間は `agent/runSubagent` を有効にし、プロンプトの書き方で示唆する	上記 Subagents in Visual Studio Code
Copilot CLI	`/fleet` で並列化を指示でき、プロンプト内の `@CUSTOM-AGENT-NAME` で特定のエージェントを指名できる	上記 fleet ページ

機構としては同じ「隔離されたコンテキスト」でありながら、人間の制御点は面によって違う。「Copilot では subagent が使える」という一括りの記述は、この差を消してしまう。実践に落とすと、VS Code では隔離が選ばれるように渡し方を設計する比重が大きく、CLI では /fleet や指名によって明示的に指示できる。

ただし公式の書き方は「typically agent-initiated, not directly invoked by users in chat」であり、限定が二重に付いている。VS Code で明示的に呼べないとは書かれていない。本カタログはこれを「呼べない」と読み替えない — 確認したのは「典型的には主エージェント主導である」ところまでである。

別名

呼称	出典
Subagent	一次 — VS Code・Copilot CLI 双方の公式が、隔離されたコンテキストで働く下位エージェントをこう呼ぶ（出典は具体例節）
Context isolation	一次 — VS Code 公式が subagent の第一の特徴に与えている名。機構ではなく性質を指す（出典は具体例節）
読み捨ての隔離 / Read-and-Discard Isolation	記述 — 本カタログの記述的呼称であり、一次資料に出典は無い

公式の Subagent は機構の名である。本パターンは実践であり、機構が無くても成立する — 別のセッションや別のウィンドウで調べ、結果だけを本題に書き戻す運用は、道具を問わず同じ構造を持つ。機構の名を実践の名として流用すると、機構の無い環境では実践ごと見落とされる。そのため実践の側に記述的な名前を与えた。

読み捨ての隔離（Read-and-Discard Isolation） ​

問題 ​

コンテキスト ​

解決 ​

トレードオフ ​

GitHub Copilot での具体例 ​

VS Code — 主エージェントが要否を判断する ​

Copilot CLI — 人間が明示的に指示できる ​

面による違い ​

別名 ​

関連 ​