/fork と /subtask の使い分け — 分岐は手元から切り離し、委譲はセッションに残す

いつもの癖で /fork を打ちました。手元で少しだけ試したいことがあって、会話をそのまま枝分かれさせるつもりでした。

ところが返ってきたのは、いつものセッション内の応答ではありませんでした。claude agents の一覧に、見慣れない行が1つ増えていたのです。複製された会話は、私の手元とは別の場所で動き始めていました。

Claude Code 2.1.212 で、/fork の役割が変わりました。会話を新しいバックグラウンドセッションへ複製するコマンドになり、これまで /fork が担っていたセッション内サブエージェントの起動は /subtask へ移っています。名前は同じでも、引き受ける仕事が入れ替わったことになります。

最初は戸惑いましたが、いくつか回してみて、この分け方には筋が通っていると感じるようになりました。以下は、私自身が個人開発の作業を回しながら整理した使い分けの基準です。

2つのコマンドが引き受けるようになった役割

まず、何がどちらに割り当てられたのかを並べておきます。

観点	`/fork`	`/subtask`
作られるもの	会話を複製した独立したバックグラウンドセッション	いまのセッション内で走るサブエージェント
どこに現れるか	`claude agents` の一覧に独立した行として	いまのセッションの中（親の文脈の内側）
手元の作業への影響	止めない（別の場所で走る）	その場の応答として返るまで待つ
引き継ぐもの	複製時点までの会話全体	親から渡した指示と権限モード
向いている場面	「この続きを別方向でも試したい」	「この作業の一部を切り出して任せたい」

言い換えると、/fork は分岐、/subtask は委譲を引き受けるようになりました。分岐は手元から出ていき、委譲は手元に残ります。

セッションにタイトルが付いていない場合、複製先には入力したプロンプトから名前が付きます。一覧で「これは何の枝だったか」を思い出せるかどうかは、この自動命名の出来にかなり左右されます。私は分岐の第一声を、あとから読んで意味が通る一文にするよう意識するようになりました。「さっきの方針でリファクタを進めて」ではなく「認証まわりをセッション Cookie から JWT へ寄せる案を試す」と書いておく、という程度の話です。

分岐が手元の作業を奪わなくなった

以前の /fork で困っていたのは、枝分かれさせた瞬間に、その枝が目の前を占領してしまうことでした。試したかったのは「もう一つの可能性」であって、いま進めている実装を中断することではありません。それでも、応答が返るまでは手元が塞がっていました。

新しい /fork は、この関係を逆にしました。複製先は独立したバックグラウンドセッションとして走り、手元の会話はそのまま続けられます。枝は勝手に育ち、様子を見たくなったら claude agents から覗きに行く。作業の主導権が手元に残ったまま、というのが大きな違いです。

分岐が安くなると、判断の仕方も変わります。「どちらの設計が良いか」を頭の中だけで比べる代わりに、迷った時点で片方を /fork に出してしまい、手元ではもう片方を進める。30分後に両方の結果を並べて選ぶ、という進め方が現実的になりました。私はこのやり方を好みます。頭の中で比較を完了させようとすると、たいてい最初に思いついた方に引っ張られるからです。

なお、/resume をエージェントビューで打つと、一覧から削除したものも含めて過去セッションのピッカーが開きます。選んだものはバックグラウンドセッションとして再開されます。分岐を出しっぱなしにして忘れても、あとから拾い直せるということです。

/subtask を選ぶのはどんなときか

では /subtask はいつ使うのか。判断の軸は「結果が手元の文脈に戻ってくる必要があるか」の一点だと考えています。

戻ってくる必要があるなら /subtask です。テストの失敗原因を調べさせて、その結論を踏まえて次の修正を書く。依存関係の一覧を作らせて、それを見ながら移行順序を決める。こうした作業は、結果が親の会話に統合されて初めて意味を持ちます。別セッションに出してしまうと、戻す手間の方が高くつきます。

戻ってくる必要がないなら /fork です。「この方針でも一応やってみて」「別のライブラリで書いたらどうなるか見ておいて」。これらは結果が独立して評価できるので、手元と切り離せます。

/subtask まわりで一つ、挙動が変わった点があります。Task ツールの mode パラメータが非推奨になり、指定しても無視されるようになりました。サブエージェントは既定で親セッションの権限モードを継承します。

これは地味ですが効きます。親を制限の緩いモードで走らせているなら、切り出したサブエージェントも同じ緩さで走るということです。以前のように、サブエージェント側だけ mode で締める、という書き方は通らなくなりました。権限は親の側で決める。設計の責任が一箇所に寄ったと考えるのが素直だと思います。

# 権限モードは親セッションの起動時に決める
# サブエージェントはここで決めたモードを継承する
claude --permission-mode acceptEdits
 
# 分岐先も同様。複製元の設定を引き継いだうえで独立して走る
# /fork したあと、様子を見るときは:
claude agents

分岐を増やす前に、上限を決めておく

同じ 2.1.212 で、セッション単位の上限が2つ入りました。

対象	既定値	環境変数
WebSearch の呼び出し	200回 / セッション	`CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION`
サブエージェントの起動	200回 / セッション	`CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION`

どちらも /clear で予算がリセットされます。狙いは、暴走した検索・委譲のループを止めることです。

私はこの変更を、今回の更新の中でいちばん長く考えました。上限を設ける、という判断の裏には、実際に暴走したログがあったはずだと想像したからです。私自身、夜間にタスクを回していて、朝になってから「これは何を探し続けていたのだろう」と首をかしげたことがあります。あのときログに残っていたのは、似たクエリの延々とした繰り返しでした。

止まらない仕組みを作るより、止まる仕組みを最初から入れておく。そちらの方が誠実だと、いまは思っています。

実務では、既定の200回をそのまま使うより、用途ごとに絞る方が安全側に倒せます。

# 無人で回す夜間ジョブ: 予算を明示的に絞る
export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=20
export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=10
claude -p "今日のリリースノートを要約して docs/ に書き出す"
 
# 対話で調べ物をするとき: 既定の200回で足りることがほとんど

20回という数字に根拠はありません。私の場合、日次の要約ジョブが実際に使うのは3〜5回程度で、それが20を超えたら「何かがおかしい」と判断できる、という程度の目安です。この「おかしいと判断できる線」を自分の実測から引けるかどうかが、上限設定の実質だと思います。既定値の200は、その線を引く前の暫定値として受け取るのが良さそうです。

もう一つ、応答性に関わる変更があります。2分を超える MCP ツール呼び出しは、自動でバックグラウンドへ移るようになりました。しきい値は CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS で調整でき、無効化もできます。長い呼び出しでセッションが固まらなくなった、という話です。

# しきい値を5分に緩める（既定は 120000 ms = 2分）
export CLAUDE_CODE_MCP_AUTO_BACKGROUND_MS=300000

分岐・委譲・長い呼び出し。この3つがそれぞれ「手元を塞がない」方向に揃ったのが、今回の更新の輪郭だと感じています。

手元の設定に落とす

判断フローとして書き下すと、こうなります。

結果が親の会話に戻る必要があるか → あるなら /subtask、ないなら /fork
手元の作業を止めたくないか → 止めたくないなら /fork
権限をどこで決めるか → 親セッションの起動時に決める（mode は無視される）
予算はいくつか → 実測の3〜5倍を上限に。既定の200は暫定値として扱う

あわせて、セッション間のやり取りが軽くなった点も触れておきます。SendMessage の本文が再生履歴とツール結果へ二重に入らなくなり、エージェント間メッセージのトークン消費が減りました。分岐や委譲を増やすほど効いてくる改善です。

セッションの切り替えと文脈の整理については、Claude Code の /clear と /compact を使い分ける — 長時間作業を止めない切り替え術が土台になります。サブエージェントの実装パターンそのものはClaude Code のマルチエージェント並列実行 — Task ツールと SubAgent の実装パターンと運用の勘所に、走らせたバックグラウンドセッションの見張り方は背景セッションが実行中のまま固まっていた — agents ビューにハートビートを添えて停滞を数分で捕まえるにまとめてあります。

おわりに

/fork と /subtask の分かれ方は、コマンド名の付け替えというより、分岐と委譲という別々の営みに、別々の場所を与えた変更でした。

まず試していただきたいのは、次に「どちらの設計にしようか」と迷った瞬間です。頭の中で比べ切ろうとせず、片方を /fork に出してしまう。手元でもう片方を進めて、あとから両方を並べる。この一回で、分岐が安くなったことの意味が体感できるはずです。

私自身まだ手探りの最中ですが、共に学んでいけたら嬉しいです。