調査系のスキルを走らせると、rgやcatの出力がメイン会話にそのまま積み上がります。数千トークン使った末に、手元に残したいのは結論の数行だけ。context: forkを1行足すと、この実行過程を別コンテキストへ追い出せます。
context: fork が隔離するもの
メイン会話に返るのは結果だけ
Claude Codeの公式ドキュメント “Run skills in a subagent” は、context: forkを「a skill to run in isolation」と説明しています。スキル本文がそのままサブエージェントを動かすプロンプトになり、ファイル読み込みやgrepの途中経過はfork側のコンテキストに閉じます。メイン会話へ戻るのは最終出力だけ。調査スキルをforkにしたところ、会話に残るのは20〜30行の要約になり、同じセッションを以前より長く回せるようになりました。
会話履歴は引き継がれない
forkしたスキルは、呼び出し元の会話履歴を見ません。ドキュメントの表現では “It won’t have access to your conversation history”。直前のやり取りに依存する処理はforkに向かない、と読み替えられます。渡したい情報はスキル本文に書くか、後述の動的注入で埋め込む。ここを外すと、forkは文脈を持たないまま実行されます。
frontmatterに1行、最小構成
既存のスキルにcontext: forkを足すだけで挙動が変わります。TODOコメントを集計する例。
---
name: repo-scan
description: リポジトリ内のTODO/FIXMEを集計する
context: fork
agent: Explore
---
## タスク
`rg "TODO|FIXME" -n` の結果を集計し、ファイル別の件数と、
着手すべき項目を10件まで根拠付きで挙げてください。
/repo-scanで呼ぶと、集計はfork側で走り、会話には結果が返ります。
> /repo-scan
● Exploring in a forked subagent…
└ TODO 42件 / FIXME 8件。src/auth/ に集中(17件)。
優先: セッション失効処理の未実装(src/auth/session.go:88) ほか9件
もとのスキルとの差分は、frontmatterのcontext: forkとagent:の2行だけ。本文はそのまま流用できます。カスタムコマンドはスキルに統合されたので、.claude/commands/repo-scan.mdでも.claude/skills/repo-scan/SKILL.mdでも、同じ/repo-scanとして動きます。
agent: でエージェント型を選ぶ
agent:は、forkを動かすエージェント型の指定です。context: fork付きスキルなら、システムプロンプトはエージェント型から、タスクはSKILL.mdの本文。Exploreを選んだ理由は後半で扱います。
forkスキルとサブエージェント、向きが逆
「スキルとサブエージェントの組み合わせ」には向きが2つあります。ドキュメントの整理をそのまま表にすると、役割が逆なのが分かります。
| 方式 | システムプロンプト | タスク | 一緒に読むもの |
|---|---|---|---|
context: fork付きスキル | エージェント型から | SKILL.mdの本文 | CLAUDE.md(Explore/Planを除く) |
skillsフィールド付きサブエージェント | サブエージェントの本文 | Claudeの委譲メッセージ | プリロードしたスキル + CLAUDE.md |
隔離される側か、束ねる側か
context: forkは、スキル自身がサブエージェントになる側。スキル本文がタスクそのものになります。対して、サブエージェント定義にskillsを持たせる構成は、サブエージェントが指揮役で、スキルを道具として先読みする側。スキルの書き方そのものはClaude Code Skillの作り方—SKILL.md設計とtrigger発動の勘所にまとめています。
迷ったときの判断基準
選ぶ基準は、隔離される側か束ねる側か。毎回同じ手順を独立コンテキストで回したいならcontext: fork付きスキル。役割・判断基準・権限を固定した担当者として何度も委譲したいなら、カスタムサブエージェント。コードレビューや調査のように「担当者」を立てたい処理は後者が向きます。
動的コンテキスト注入と組み合わせる
forkが効くのは、スキル本文をシェルの出力で組み立てられるとき。ドキュメントの “Inject dynamic context” セクションが扱う!`command`記法です。プレースホルダがコマンド出力に置き換わってからClaudeに渡ります。
!`command` でプロンプトを先に組み立てる
PRを要約するスキルを、GitHub CLIの出力で組み立てる例。公式のサンプルをほぼそのまま引きます。
---
name: pr-summary
description: Summarize changes in a pull request
context: fork
agent: Explore
allowed-tools: Bash(gh *)
---
## Pull request context
- PR diff: !`gh pr diff`
- PR comments: !`gh pr view --comments`
- Changed files: !`gh pr diff --name-only`
## Your task
このPRの変更点と、未対応のレビュー指摘を挙げてください。
例のallowed-tools: Bash(gh *)は、このスキルが触れる道具をghコマンドだけに絞る指定。forkは独立したコンテキストで走るぶん、渡す権限は最小にしておくと余計な操作を防げます。複数指定するときはスペースかカンマで並べます。
実行順はドキュメントの通り。各!`command`が先に走り、出力がプレースホルダを置換し、Claudeは組み上がったプロンプトだけを受け取ります。これはpreprocessingで、Claudeがコマンドを実行するわけではありません。
> /pr-summary
● Running: gh pr diff / gh pr view --comments / gh pr diff --name-only
● Exploring in a forked subagent…
└ 認証ミドルウェアにレート制限を追加(3ファイル)。
レビュー指摘2件のうち、エラーメッセージのi18nが未対応。
差は差分の量で出ます。メイン会話でgh pr diffを実行すると、数百行の差分がそのまま会話に載ります。forkなら差分はfork側で消化され、会話に残るのは3〜4行の要約だけ。レビューの往復で何度もPRを覗くほど、この差が積み上がります。
agent: Explore で CLAUDE.md を読ませない
ExploreとPlanは、起動時にCLAUDE.mdとgit statusを読み飛ばします。agent: Exploreを指定したforkスキルが見るのは、SKILL.mdの本文とエージェント自身のシステムプロンプトだけ。PR要約のような一発仕事では、SKILL.md以外を読まないぶん、渡すトークンが減ります。
置換は一度きり
!`command`の置換は、元ファイルに対して1回だけ走ります。挿入されたコマンド出力は再スキャンされないので、出力の中にさらにプレースホルダが現れても展開されません。もう1点、!が認識されるのは行頭か空白の直後にあるときだけ。KEY=!`cmd`のように文字の後ろに続けると、リテラル文字列として素通りします。
呼び出しのタイミングを固定する
forkスキルは、副作用のある処理や、実行タイミングを自分で握りたい処理に向きます。ドキュメントの “Control who invokes a skill” は、呼び出し元を絞る2つのフィールドを挙げています。
disable-model-invocation でユーザー専用にする
disable-model-invocation: trueを付けると、Claudeは自動で起動しなくなり、/skill-nameで自分が叩いたときだけ走ります。デプロイやSlack送信のように、コードが整ったからとClaudeに勝手に判断されると困る処理向け。fork調査スキルでも、外部コマンドを叩くなら手動トリガーへ寄せておくと事故が減ります。
---
name: audit-deps
description: 依存パッケージのライセンスを棚卸しする
context: fork
agent: Explore
disable-model-invocation: true
allowed-tools: Bash(go *), Bash(pip *)
---
## タスク
依存パッケージのライセンスを一覧化し、
コピーレフト系(GPL/AGPL)を含むものを警告してください。
これで/audit-depsは手動でしか動きません。実行するとfork側でライセンスを集計し、結果だけが会話に戻ります。
> /audit-deps
● Exploring in a forked subagent…
└ 依存 128件。MIT/Apache-2.0 が大半。
要確認: 1件が LGPL-3.0(動的リンクのみ、再配布時に注意)
user-invocable: false で知識スキルに寄せる
逆にuser-invocable: falseは、Claudeだけが読むスキル。/legacy-system-contextのような、コマンドとして叩く意味の無い背景知識に使います。ドキュメントの例では、古いシステムの動きを説明するスキルが該当。この2つのフィールドはforkの有無と独立して効くので、組み合わせで「誰が・いつ・どのコンテキストで」を細かく決められます。
つまずきやすい点
タスクの無いスキルをforkしても空返し
公式ドキュメントはcontext: forkに警告を添えています。明示的な指示を持つスキルにだけ意味がある、と。規約だけを並べたスキルにforkを付けると、サブエージェントはガイドラインを受け取るものの、実行すべきタスクが無いまま何も返さず終わります。
# NG: タスクが無い。forkしても空返しになる
---
name: api-conventions
description: APIの命名規約
context: fork
---
エンドポイントは複数形、スネークケースで統一する。
規約のような「知識」はforkせず、Claudeが必要なときに読む通常スキルのままにしておく。forkは「やること」が書いてあるスキルに限定します。
ネストは5階層まで
2026年6月のアップデートで、サブエージェントからさらにサブエージェントを呼べるようになりました(背景チェーンは最大5階層)。forkしたスキルの中で別の調査エージェントを、もう一段起動できます。検証時のClaude Codeはv2.1系(v2.1.19x)、既定モデルはOpus 4.8。
よくある質問
context: fork とカスタムサブエージェントは何が違う?
入り口が違います。forkはスキル本文がそのままタスクになり、/skill-nameで手軽に呼べる。カスタムサブエージェントは、システムプロンプトを持った「担当者」を定義し、Claudeが必要に応じて委譲する側。同じ手順を毎回回すならfork、役割を固定して何度も任せるならサブエージェント。
forkスキルからメイン会話へは何が返る?
最終出力だけ。途中のツール呼び出しやファイルの中身はfork側のコンテキストに残り、会話へ渡るのは結果です。だからメイン会話が膨らまず、長いセッションでもトークンに余裕が残る。auto-compactに頼る前に、重い調査をforkへ逃がしておくと圧縮の頻度も下がります。
まとめ
context: forkはスキル本文をそのままサブエージェントのプロンプトにして、実行過程をメイン会話から隔離する- 会話履歴は引き継がれない。必要な情報はスキル本文か
!`command`で明示的に渡す agent: Exploreを指定するとCLAUDE.mdとgit statusを読まず、最小コンテキストで走る- タスクの無い規約スキルに付けても空返しになる。forkは「やること」が書いてあるスキル向け
- 毎回同じ手順を隔離実行したいならfork、役割を固定して委譲したいならサブエージェント