はじめに
VS Code 1.118（2026年4月リリース）で、GitHub Copilot のスキル（Skill）機能に context: fork という実験的機能が追加されました。
Claude Code ではすでに利用されている機能だと思いますが、VS Code Copilot では今回が初登場です。
一言でいうと「スキルを動かすときに、メインの会話を汚染しないよう専用の作業スペースを使う」機能です。
地味に見えますが、独自スキルを使っていて「スキルを呼んだ後に Copilot の回答がおかしくなる」と感じたことがある方には刺さる改善です。この記事では、問題の背景から仕組み・設定方法・類似概念との違いまで整理します。
問題
スキルがコンテキストを圧迫する
LLM には「コンテキストウィンドウ」という限界があります。一度に処理できるトークンの上限です。
チャットのやり取りやツール呼び出しの結果はすべてこのウィンドウに積み上がっていくため、ウィンドウが溢れると古い情報が削除され、回答品質が低下します。
context: fork 以前の問題
スキルが動作するとき、内部では複数回のツール呼び出し（ファイル検索・ドキュメント読み込みなど）が発生します。これらすべての中間結果がメインの会話コンテキストに直接流れ込んでいました。
この状態が続くと：
- 以前の会話内容が押し出されて消えていく
- Copilot が文脈を見失い、的外れな回答をするようになる
- 長いセッションほど劣化が顕著になる
解決策：
context: fork による専用コンテキスト
context: fork を使うと、スキルの実行がメインの会話から切り離されたサブコンテキストで行われます。プロセスの「fork」（子プロセスを生成して独立させる）のイメージが近いです。
context: fork 適用後のシーケンス
設定方法
1. 実験的機能を有効化
VS Code の設定で以下を有効にします：
github.copilot.chat.skillTool.enabled = true
2. SKILL.md に context: fork を追加
---
name: my-skill
description: コードレビューを行うスキル
context: fork # ← これだけ追加する
---
# スキルの内容（以下は変更なし）
...
Subagent と context: fork の違い
あれ、Subagent と似てない？と思った方もいるかもしれません。両者は「メインエージェントから切り離して処理する」という点では共通していますが、目的と仕組みが異なる概念のようなので、自分なりに整理してみます。
VS Code Copilot における「Subagent」とは
Copilot エージェントには、メインエージェントが特定のタスクを別のエージェントに委譲する仕組みがあります。サブエージェントは独立したモデル（多くは小型モデル）として動作し、タスクを処理して結果を返します。
context: fork との関係と違い
| 観点 | Subagent | context: fork |
|---|---|---|
| 主な目的 | 処理を別モデルに委譲（コスト・速度） | コンテキストをメインから隔離（品質維持） |
| モデル | 別モデル（主に小型モデル）を使用 | 同じモデルで動作する場合もある |
| コンテキスト | 独立したコンテキストを持つ | メインからforkして独立したコンテキストを持つ |
| 対象 | エージェントツール全般 | スキル（SKILL.md）限定 |
例えると:
- Subagent: 会社で言えば「別の部署に仕事を依頼する」。 → 担当者が違う。
-
context: fork: 同じ担当者が「メモ帳を別に用意して作業し、完成品だけ報告する」 → メモ書きが散らかった机の上を見せない。
というイメージでしょうか。両者は組み合わせて使うこともできると思いますが、目的が違うため混同しないように注意が必要そうです。
まとめ
| ポイント | 内容 |
|---|---|
| 何が変わった | SKILL.md に context: fork を書くだけでスキルの実行を隔離できるようになった |
| なぜ嬉しい | スキルの中間結果がメインコンテキストを圧迫しなくなり、長いセッションでも回答品質が安定する |
| Subagent との違い | Subagent はモデルの分離、context: fork はコンテキストの隔離。目的が違う |
| 向いているスキル | 多ステップのツール呼び出し・大量のドキュメント参照を行うスキル |