forkと通常のサブエージェントの違いを、一言で言うと？
forkは会話全体（同じシステムプロンプト、ツール、モデル、メッセージ履歴）を引き継ぎ、通常のサブエージェントは空白から始まって、タスクメッセージ、CLAUDE.md、git status、事前に読み込まれたスキルだけを受け取る。共通するのは、途中のツール呼び出しがメイン会話に入らず、最終結果だけが戻ることだ。
CIでclaude -pを使っています。アップグレードで請求額は増えますか？
リリースノートはforkのコストを数値化していないので、断定はできない。v2.1.302からclaude -pでもforkが既定で使え、Claudeが作業を振るときに選ぶことがあり、forkは履歴全体を持ち込む。DEV Communityの記事は、影響は増える方にも減る方にも出うるとして、数回測るよう勧めている。--output-format jsonのusageやOpenTelemetryでアップグレード前後のトークン使用量を比べ、CLAUDE_CODE_FORK_SUBAGENT=0を設定するか決める。
サブエージェントのfrontmatterにautoCompactWindowを書いたのに、効いていないようです。なぜですか？
順に確認する。素の整数で書く（200kは200と読まれて範囲外になる）。範囲は100000から1000000で、サブエージェントが本来引き継ぐウィンドウより小さい値でなければならない。CLAUDE_CODE_AUTO_COMPACT_WINDOWが設定されていると、それがこのフィールドに優先する。--agentやagent設定でセッション全体をサブエージェントとして動かす場合も効かない。最後にclaude --debugでログからinvalid autoCompactWindowを検索し、無視されたかを確認する。
エンジニアではありません。どう理解すればよいですか？
サブエージェントは、1つの作業を頼むアシスタントだと考えるとよい。通常のサブエージェントはタスクシートを渡されてゼロから始め、forkはここまでの会話記録全体を読んでから作業に入る。後者は説明し直す必要がないが、読む量が多い。この既定は自動化されたワークフローで変わったので、費用を見ているなら、アップグレード後に一度使用量を比べるようエンジニアに頼むとよい。
多くの人はサブエージェントを「まっさらなコンテキストで1つのことをやらせるもの」と考えている。forkサブエージェントは意図的にそうしない。公式ドキュメントによれば、forkは最初からではなく、ここまでの会話全体を引き継ぐサブエージェントで、サブエージェントが本来持つ入力の隔離を手放す代わりに、背景を改めて説明する手間をなくす。2026年10月16日のv2.1.302は、forkをclaude -p、Agent SDK、デスクトップアプリ、VS Codeで既定で有効にしたため、このトレードオフはより多くの場面で自動的に起きるようになった。
公式のサブエージェントのドキュメントによると、通常のサブエージェントの開始時のコンテキストは、自身のシステムプロンプト、タスクメッセージ、CLAUDE.md、git status、事前に読み込まれたスキルだけで、会話の履歴は見えない。forkはメインセッションと同じシステムプロンプト、ツール、モデル、メッセージ履歴を見て、メイン会話とまったく同じツール群を受け取る。つまり、通常のサブエージェントに適用されるツールを絞る2つのフィルターを飛ばす。output styleも同様で、ドキュメントは、通常のサブエージェントには「forkを除いて」届かないと述べている。
共通するのは出力の戻り方だ。forkのツール呼び出しは会話に入らず、最終結果だけが戻るので、メインのコンテキストはきれいなままだ。
ドキュメントの助言は、他のどのサブエージェントでも背景が多すぎて役に立たないとき、または同じ出発点から複数のやり方を並行して試したいときにforkを使う、というものだ。起動方法は2つある。Claudeに（forkモードがオンのとき）Agentツールでforkというサブエージェントタイプを要求させるか、いつでも/subtask <task>を実行する。例：/subtask draft unit tests for the parser changes so far。/subtaskにはv2.1.212以降が必要で、v2.1.161からv2.1.211まではこのコマンドは/forkと呼ばれていた。agent viewをオフにしていると/forkはforkサブエージェントを起動し、そうでなければ/forkはセッション全体を新しいバックグラウンドセッションにコピーする。
観察の方法：プロンプトの下のパネルにメインセッションと各forkが並び、↑／↓で移動し、Enterでforkのトランスクリプトを開いて追加メッセージを送れる。xは実行中のforkを止めるか行を消し、Escでプロンプトに戻る。forkが終わると、結果はメッセージとしてメイン会話に届く。成功した行はすぐ消え、失敗または停止した行は30秒残る。
v2.1.302のリリースノートによれば、forkサブエージェント（subagent_type: "fork"）は、ターミナルと同様に、claude -p、Agent SDK、デスクトップアプリ、VS Codeでも既定で有効になった。CLAUDE_CODE_FORK_SUBAGENT=0でオフにでき、claude mcp serveは決して提供しない。同じリリースでバックグラウンドの挙動も変わった。デスクトップアプリとVS Codeは、Claudeに選ばせず、メイン会話のサブエージェントを常にバックグラウンドで実行する。サブエージェント自身のAgent呼び出しは、claude -p、SDK、デスクトップアプリ、VS Codeで既定でフォアグラウンドで動く。
1つ不整合を指摘しておく。私が読んだ公式のサブエージェントのドキュメントのページは、forkモードが-pとAgent SDKでは自分でオンにしない限りオフだと、まだ書いている。ドキュメントがv2.1.302に追いついていない可能性が高いが、確認はできなかった。自分のバージョンでの実測を信頼し、重要ならCLAUDE_CODE_FORK_SUBAGENTを明示的に設定してほしい。
リリースノートはforkがコストに与える影響に触れておらず、私が読んだドキュメントのページ（forkの節の途中で切れていた）も、forkのプロンプトキャッシュには言及していない。DEV Communityの記事は、ヘッドレスの支出が増えることも減ることもあると述べ、何度か測ってから決めるよう勧めている。私の推論（ドキュメントの内容ではない）では、通常のサブエージェントは隔離でトークンを節約し、forkは履歴全体を入力として持ち込む。会話が長いほど入力は大きくなるが、オーケストレーターがブリーフを書く費用や、サブエージェントが背景を改めて調べ直す費用は省ける。どちらが得かは、会話の長さとタスクの性質で決まる。
v2.1.296から、サブエージェントのfrontmatterと--agentsの定義でautoCompactWindowを指定でき、100000から1000000の間のトークン数で、そのサブエージェントが早めに圧縮されるようになる。公式ドキュメントの規則は踏みやすい。
---
name: log-reader
description: Reads long log files and reports the errors it finds
autoCompactWindow: 200000
---200kは200と読まれて範囲外になり、サブエージェントはこのフィールドがないかのように動く。値が無視されたかを確認するには、claude --debugを実行し、デバッグログでinvalid autoCompactWindowを検索する。CLAUDE_CODE_AUTO_COMPACT_WINDOWが正の整数に設定されていると、サブエージェントはその変数のウィンドウを使い、このフィールドは効かない。--agentやagent設定でセッション全体をサブエージェントとして動かす場合にも効かない。以下は私の推奨で、公式の方針ではない。タスクが自己完結している、隔離したい、背景が短く説明できる場合は通常のサブエージェント。正しくこなすのに既存の議論が多く必要な場合や、同じ出発点から複数の方法を試したい場合はfork。自動化の中でv2.1.302に上げた後は、まず1回分のトークン使用量を測ってから、CLAUDE_CODE_FORK_SUBAGENT=0を設定するか決める。