こんにちは、長い調査を一つの会話に詰め込みがちなアーキテクトのやまぱん！です 😅
補足コメントや質問、いいね、拡散、ぜひお願いします 🥺！
間違っていたら 優しく 教えてください！
TL;DR
-
SKILL.mdにcontext: forkを付けると、対応ホストは Skill を専用 subagent context で実行し、親へ最終結果だけを返します - Skill が呼び出された後は、prompt に毎回「subagent を使って」と書く必要がありません
-
context: forkは Agent Skills 共通仕様のフィールドではありませんが、VS Code と Claude Code がホスト拡張として対応しています - 一度きりの調査は通常の subagent、繰り返す長い workflow は forked Skill と使い分けます
- fork の前に、コマンドやクエリ側で対象・列・件数を絞る方が効果的です
今回の出発点は、VS Code の GitHub Copilot Chat で見つけた context: fork でした。調べてみると VS Code だけの機能ではなく、Claude Code も同じ frontmatter に対応しています。
context: fork 自体は、まだ Agent Skills 共通仕様の標準フィールドではありません。ただし、Agent Skills は複数ホストで使える open standard で、共通実装ガイドにも subagent delegation が optional な高度機能として掲載されています。私としては、今後ほかの agent host にも同様の機能が広がっていく可能性があると見ています。これは筆者の期待であり、確認済みの製品計画ではありません。
共通仕様側の正本は agentskills.io と公式 agentskills/agentskills リポジトリです。正式なロードマップページは見当たりませんが、context を含む Claude Code の frontmatter を共通仕様へ取り込む Open Issue #105 や、subagent と Skill の相互運用を扱う Discussion #152 は公開されています。まだ採用決定ではありませんが、標準側でも議論は始まっています（2026/08/05 時点）。
入力前・調査中・履歴蓄積後では、効く対策が異なります。この記事では中央の context: fork を中心に整理します。
この記事は Agent Skills の共通仕様と実装ガイド、VS Code / Claude Code の公式ドキュメント、私の環境で採取した GitHub Copilot Chat の debug log をもとにしています。ホストごとに対応状況が異なるため、利用時点の公式ドキュメントも確認してください。
長い調査では tool output もコンテキストを使う
VS Code の Context ドキュメントでは、モデルへ渡すコンテキストを次の要素から組み立てると説明されています。
- system instructions
- custom agents、skills、custom instructions などの customizations
- 現在の user message
- conversation history
- 開いているファイルなどの implicit context
- 明示的に参照したファイルや Web ページ
- file read、terminal command、code search などの tool outputs
VS Code の Context ドキュメントをもとに筆者作図。長い調査では、オレンジ色で示した tool outputs が増えやすくなります。
チャット本文だけを短くしても、長いログ、広い検索結果、多数の file read を同じセッションで続ければ、コンテキストは増えていきます。
なぜ context を分離するのか
context window は、モデルが現在の依頼を判断するための作業領域です。数百行のログ、途中で外れた検索結果、全文取得した Web ページは、調査中には必要でも、その後の判断で何度も参照するとは限りません。
それらを親コンテキストへ残し続けると、要件、決定事項、現在のコードなど、本当に引き継ぎたい情報に使える余地が減ります。compaction が必要になったときも、何を要約に残すかという別の判断が発生します。
分離の目的は情報を隠すことではありません。子の context には調査途中の raw output を置き、親には Decision / Key evidence / Next action のような再利用する結論だけを戻すことです。速度が必ず上がるとはまだ言えませんが、親会話の焦点を保つための情報設計として使えます。
Claude Code の Subagents ドキュメントでも、テスト、ドキュメント取得、ログ処理のような大量出力を subagent へ分離し、親には関連する要約だけを戻す使い方が紹介されています。
VS Code と Claude Code には、蓄積した会話を後から整理する compaction があります。どちらも /compact を手動で実行できます。
context: fork は、長い workflow の途中経過を最初から親コンテキストと分けます。
最小の forked Skill を作る
保存先はホストごとに異なります。VS Code でワークスペース共有するなら .github/skills/high-volume-investigation/SKILL.md、Claude Code なら .claude/skills/high-volume-investigation/SKILL.md に置けます。SKILL.md の内容は次のとおりです。
---
name: high-volume-investigation
description: Analyze broad searches, long logs, or multi-page research and return a compact decision. Use for high-volume read-only investigations.
context: fork
---
# High-volume investigation
- Filter, limit, or summarize tool output at the source.
- Keep intermediate output inside this context.
- Return only the decision, key evidence, and next action.
- Save raw output only when later audit is required; return its relative path.
VS Code と Claude Code では、context を省略した Skill は親コンテキスト内で実行されます。
context: fork を付けると、Skill は専用 subagent context で動きます。VS Code と Claude Code の公式ドキュメントは、どちらも Skill の処理を分離し、結果を親へ返す動作を説明しています。
上の例では、返却形式も次の 3 項目に絞りました。
- Decision
- Key evidence
- Next action
監査や再確認のために raw output が必要なら、ファイルへ保存して相対パスだけを返します。大量のログ本文を最終回答へ貼り直すと、fork しても親コンテキストへ戻ってしまうためです。
実行して fork を確認する
チャットから明示的に呼び出す場合は、次のように入力します。
/high-volume-investigation 大きなログから timeout の原因候補を調べて
description に合う依頼を agent が検出した場合は自動で呼び出されることもあります。ホスト別の最小確認手順は次のとおりです。
| ホスト | 準備 | 呼び出し後の確認 |
|---|---|---|
| VS Code |
.github/skills/high-volume-investigation/SKILL.md を配置し、chat.useAgentSkills と github.copilot.chat.skillTool.enabled を有効化する。/ メニューまたは Configure Skills で認識を確認する |
subagent の tool call が表示され、完了後に Skill の最終結果が親へ返る |
| Claude Code |
.claude/skills/high-volume-investigation/SKILL.md を配置する。セッション開始後に初めて .claude/skills/ 自体を作った場合は Claude Code を再起動する |
Skill 本文を task とする別 context の subagent が起動する。親の conversation history は引き継がず、完了結果が親へ返る |
この表は公式 Docs に基づく期待結果です。本記事では同一タスクを inline / fork で比較する実機 A/B までは行っていません。
通常の subagent 呼び出しとの違い
context: fork の実行先も subagent です。違いは、親 agent がその場で委譲を組み立てるか、Skill に subagent 実行を宣言しておくかです。
本記事では、.agent.md などで定義した persona・model・tools の組を custom agent、その custom agent を親から委譲して実行する形を custom agent の subagent 実行 と呼びます。
| 方法 | subagent を起動するきっかけ | 作業内容の定義場所 | 向いている場面 |
|---|---|---|---|
| 通常の subagent 委譲 | 親 agent が依頼を分解して判断 | その場の委譲 prompt | 一度きりの調査、並列分析 |
Skill の context: fork
|
Skill が手動または自動で呼び出された時点 | 再利用する SKILL.md
|
繰り返す長い調査 workflow |
| custom agent を subagent として実行 | 親 agent が特定の role を選択 |
.agent.md の persona、model、tools |
専門 role や固有の tool 権限が必要な作業 |
通常の subagent 委譲では、親 agent の判断や instruction に「広い調査は subagent へ渡す」というルーティングが必要です。forked Skill は、そのルーティングを再利用する SKILL.md に持たせます。prompt や Skill 本文に毎回「subagent を使って」と書く必要はありません。
ただし、Skill 自体が自動で選ばれるかは description と依頼内容の一致によります。確実に呼び出す場合は /high-volume-investigation のように slash command を使います。
context: fork はどこで使えるのか
Agent Skills は、もともと Anthropic が開発し、現在は複数の AI ツールで使われる open standard です。ただし、Skill の基本部分が共通だからといって、すべての frontmatter がどのホストでも同じように動くわけではありません。
Agent Skills specification が定義する frontmatter は、name、description、license、compatibility、metadata、allowed-tools です。context は含まれていません。公式の参照 validator でも、トップレベルの context は未知のフィールドとして検証エラーになります。
一方、Agent Skills のクライアント実装ガイドには、Skill を別の subagent session で動かす方法が「一部クライアントだけが対応する optional な高度機能」として紹介されています。context: fork は、この考え方を VS Code と Claude Code がホスト側の追加機能として提供したものです。
公式リポジトリには、context や agent などを共通仕様へ取り込む Issue #105 と、subagent・Skill・hooks・rules の相互運用を検討する Discussion #152 があります。どちらも採用済みの仕様や確定ロードマップではありません。一方で、複数ホストが同じ課題を持ち、標準側でも提案・議論が公開されていることは確認できます。
2026/08/05 時点で公式資料を確認できた範囲は次のとおりです。「公式文書に記載なし」は非対応の断定ではありません。
| ホスト | Agent Skills |
context: fork の公式文書 |
本記事での確認範囲 |
|---|---|---|---|
| VS Code | 対応 | Experimental として記載あり | 公式 Docs、Settings UI、設定値を確認。inline / fork の性能 A/B は未実施 |
| Claude Code | 対応 | ホスト拡張として記載あり | 公式 Docs のみ確認。実機未検証 |
| GitHub Copilot CLI | 対応 | 記載なし | 公式 Docs のみ確認。実機での fork 動作は未検証 |
| Copilot cloud agent | 対応 | 記載なし | 公式 Docs のみ確認。実機未検証 |
| OpenAI Codex | 対応 | first-class support を求める feature request が Open | Issue と公式 Docs を確認。Open Issue だけで未実装とは断定しない |
VS Code と Claude Code は同じ context: fork を使いますが、その周辺機能まで完全に同一ではありません。たとえば Claude Code は agent: Explore で実行する subagent type を指定できます。VS Code で同じ項目が動くとは限りません。
GitHub Copilot CLI と Copilot cloud agent も Agent Skills 自体には対応しています。ただし、2026/08/05 時点の公式 Docs では context: fork や Skill 単位の subagent 隔離は説明されていません。
複数ホストへ配る Skill では、私は次のように考えます。
-
name、description、本文、references/は共通部分として作る -
scripts/も同じ構成で配布できるが、実行言語、利用可能な tool、権限はホストごとに確認する -
context: forkが必須なら、対応ホストをcompatibilityと README に明記する - 厳密な Agent Skills 標準 validator を通す必要がある Skill には、トップレベルの
contextを入れない - 未対応ホストでは自動的な subagent 隔離を期待せず、そのホストの委譲機能で置き換える
metadata はクライアント固有情報を保存できる標準フィールドですが、context を metadata の下へ移しても VS Code や Claude Code の fork 指定にはなりません。移植性と fork 実行を両立するには、現状はホスト別の差分管理が必要です。
ケーススタディ: 88 MiB まで育った VS Code のチャット
この機能を調べたきっかけは、長期間使っていた GitHub Copilot Chat のセッションです。再開すると入力から応答まで重く感じることがあり、debug log ではモデルへ渡る入力と conversation compaction の大きさが目立ちました。
以下は fork 導入前の単一セッションを測った参考観測値であり、context: fork の効果測定ではありません。また、main.jsonl のファイルサイズと、モデルが一度に保持する context の大きさは同義ではありません。
私の環境で、一つのセッションを測った結果です。
| 項目 | 実測値 |
|---|---|
main.jsonl |
88.05 MiB |
llm_request レコード |
893 件 |
tool_call レコード |
961 件 |
child_session_ref レコード |
30 件 |
llm_request.inputTokens の最大値 |
387,570 |
summarizeConversationHistory の最大処理時間 |
91.4 秒 |
検証環境は Windows 11 / VS Code 1.131.0 (Stable) です。対象セッションの main.jsonl 全期間を走査し、type ごとのレコードを重複排除せずに数えました。child_session_ref の 30 件は一意な子セッション数ではなく、参照レコード数です。token は llm_request.attrs.inputTokens の最大値を採用しました。compaction は type == "llm_request" かつ attrs.debugName == "summarizeConversationHistory" のレコードを抽出し、トップレベルの dur（ミリ秒）の最大値 91,376 を 1,000 で割って 91.376 秒としました。MiB は $1,\mathrm{MiB}=1{,}048{,}576,\mathrm{bytes}$ で換算しています。
これは一つのセッションの観測値であり、「38 万 tokens を超えると必ず遅くなる」という閾値ではありません。セッションの大きさだけで重さの原因を確定できたわけでもありません。それでも、長い調査の途中結果まで親チャットへ積み上げる設計は見直せます。
先に User Data の instruction へ入れた対策
context: fork を見つける前に、最近の調査で繰り返していた対策を User Data の always-on instruction へ追加しました。毎回読む instruction なので、細かな手順を詰め込まず、どこで絞り、いつ委譲するかだけを残しています。
- 狭い確認は、対象・列・件数・範囲を絞って直接実行する。
- 広い検索、長いログ、複数ページ調査、100 行を超えそうな read-only 作業は isolated subagent へ委譲する。
- 子には subgoal、必要な入力、制約、判定基準だけを渡す。
- 親への返却は decision / key evidence / next action に絞る。
- raw output は後で監査・再読する場合だけファイルへ保存する。
このルールだけでも、親チャットへ大量の raw output を返す場面は減らせます。一方、Skill 自体が長い調査 workflow を持つ場合は、その中間処理をどこに置くかが残ります。そこで context: fork を使います。
実践例: 私の VS Code 設定
2026/08/05 時点の User Settings は次のとおりです。Profile や Workspace による上書きがないことも確認しました。
{
"chat.useAgentSkills": true,
"github.copilot.chat.skillTool.enabled": true,
"chat.tools.compressOutput.enabled": true,
"github.copilot.chat.summarizeAgentConversationHistory.enabled": false,
"github.copilot.chat.summarizeAgentConversationHistoryThreshold": 0.8
}
AI settings referenceと照らし合わせ、私は次の理由で使い分けています。
| 設定 | 私の値 | 理由 |
|---|---|---|
chat.useAgentSkills |
true |
Agent Skills を日常的に使うため |
github.copilot.chat.skillTool.enabled |
true |
context: fork を指定した Skill を専用 subagent context で実行するため |
chat.tools.compressOutput.enabled |
true |
git diff、一覧表示、install progress などのノイズをモデル送信前に減らし、context window の消費を抑えるため |
github.copilot.chat.summarizeAgentConversationHistory.enabled |
false |
残しておきたい会話の細部まで自動で要約されるのを避け、必要なタイミングで /compact または新しいチャットを選ぶため |
github.copilot.chat.summarizeAgentConversationHistoryThreshold |
0.8 |
自動要約を検証したときの残存値。現在は自動要約を OFF にしているため無効であり、推奨値ではない |
VS Code で forked Skill を使うには、Experimental 設定 github.copilot.chat.skillTool.enabled を true にします。この設定を有効にしても、普段の file read や terminal command がすべて自動で隔離されるわけではありません。fork されるのは、SKILL.md で context: fork を指定した Skill です。
筆者環境の VS Code Settings。GitHub > Copilot > Chat > Skill Tool: Enabled を有効にしています（2026/08/05）。
私の委譲目安は 100 行
数行の設定確認、狭い検索、単発テストまで subagent へ渡すと、委譲 prompt、起動、結果の要約という往復が増えます。私の運用では、read-only の作業で返却が 100 行を超えそうなら、forked Skill または subagent を検討します。100 行は VS Code の制限値ではなく、判断しやすくするために置いたローカルルールです。
件数だけでは判断できないため、次の条件も合わせて見ます。
- 一つの判断に対して複数ファイルを横断する
- 数千行のログから時間帯やエラーを探す
- 複数の公式ページを読み比べる
- 中間結果を親が再利用しない
fork の前に取得元で絞る
5,000 行のログを取得してから別 context へ渡すより、コマンド側で対象時間、エラー、必要な列を絞る方が速く済みます。
Select-String -LiteralPath .\app.log -Pattern 'ERROR|timeout' |
Select-Object -Last 30
検索 API やデータベースなら、取得元で filter、limit、summary を指定します。fork は、絞っても広い探索が残る場面に使います。
補足: VS Code で併用できるコンテキスト対策
コンテキストを小さくする対策について、何をするのか、いつ使うのかを整理します。
| 対策・機能 | 何をするか | 使うタイミング |
|---|---|---|
| 取得元で絞る（filter / limit） | コマンド、検索、API、DB の時点で対象・列・件数・期間を限定する | すべての調査で最初に行う |
chat.tools.compressOutput.enabled |
tool output をモデルへ送る前に後処理し、変更のない diff、lockfile、install progress などのノイズを減らす | 絞り込んでも tool output が大きくなりやすいとき。私は常時 ON |
context: fork |
Skill を専用 subagent context で実行し、親には最終結果だけを返す | 長いログ調査など、繰り返し使う workflow を隔離したいとき |
| custom subagent | role、model、tools、作業コンテキストを分けて一時的に委譲する | 一度きりの広い調査、並列分析、専門 role が必要なとき |
github.copilot.chat.summarizeAgentConversationHistory.enabled |
context window が埋まった際に、過去の conversation history を自動要約する | 自動的に要約されてもよい場合。私は OFF |
/compact |
現在の conversation history を任意のタイミングで手動要約する | 同じチャットを続けたいが、履歴が膨らんだとき |
| New chat | conversation history を持たない新しいセッションを開始する | 別タスクへ移るとき、または現在の履歴を引き継ぐ必要がないとき |
chat.tools.compressOutput.enabled は Preview 設定です。私は、取得元で対象・件数を絞った後に残る tool output のノイズを減らす第二の対策として有効にしました。
自動要約は、残しておきたい会話の細部まで要約されるのを避けるため false にしています。同じチャットを続けながら履歴を整理したい場合だけ /compact を使い、引き継ぐ必要がなければ新しいチャットへ切り替えます。automatic / manual compaction の違いは Manage context for AIで確認できます。
注意点
VS Code では context: fork は Experimental
この記事を書いた 2026/08/05 時点で、context frontmatter と dedicated skill tool は Experimental です。設定名や挙動が変わる可能性があります。
security sandbox ではない
fork されるのは会話のコンテキストです。ファイル、ネットワーク、コマンド実行の権限を自動的に制限する security sandbox ではありません。
外部から取得した Skill は、SKILL.md と同梱スクリプトを確認してから利用します。tool の承認や network access も、コンテキスト隔離とは別に設定してください。
raw output をファイルへ残す場合は、secret、個人情報、内部 URL を除去します。保存先はリポジトリ外、または .gitignore 対象の作業フォルダにし、不要になったら削除します。親へ返すのはローカル絶対パスではなく、必要な場合だけ監査用ファイルの相対パスにします。commit 前には誤って追跡対象へ入っていないか確認します。
最終結果の長さは自分で決める
forked Skill の最終結果は親へ戻ります。Skill に「詳しく報告して」とだけ書くと、長いレポートが親コンテキストへ入る可能性があります。
返却形式、最大件数、raw output の保存条件まで Skill に書いておくと、隔離の意図を保ちやすくなります。
性能改善の A/B 比較は今後の検証
今回確認したのは、大きなセッションで tool outputs と compaction が積み上がっていたこと、そして forked Skill が別 context で動くという公式仕様です。
同じ調査を inline と fork で実行し、親 request の input tokens、所要時間、cache hit rate を比較するところまでは実施していません。「fork すれば何秒速くなる」とは、まだ言えない状態です。
まとめ
context: fork は、繰り返す長い調査を Skill として再利用しながら、その途中経過を親コンテキストから分けるための指定です。VS Code では github.copilot.chat.skillTool.enabled、Claude Code では Skill frontmatter の追加機能として利用できます。
私の運用では、次の順でコンテキストを増やしすぎないようにしました。
- コマンドやクエリの時点で対象・列・件数を絞る
- 広い read-only 作業を forked Skill または subagent へ渡す
- 親への返却を decision / evidence / next action に絞る
- 必要に応じて tool output を Compress Output で送信前に圧縮する
- 必要な raw output だけファイルへ残す
- 親に蓄積した後は
/compactまたは新規チャットを使う
次は同じログ解析を inline と fork で実行し、親コンテキストの token 数がどこまで変わるか測ってみます 💪
参考
- Use Agent Skills in VS Code
- AI settings reference
- Context in Visual Studio Code
- Subagents in Visual Studio Code
- Manage context for AI
- About agent skills - GitHub Docs
- Adding agent skills for GitHub Copilot CLI
- Extend Claude with skills
- How to add skills support to your agent
- Agent Skills specification
- Support new Claude Code skills as commands frontmatter scheme - agentskills/agentskills #105
- Standardize interoperability between sub-agents and skills - agentskills/agentskills Discussion #152