Claude Code の子セッション運用 — 欲しかった Spawn Task が来ても、戻らなかった話

はじめに

個人で開発しているモノレポは、ほぼ Claude Code on the web（クラウド側で動く Claude Code）で回している。規模の大きい対応では、1 つのセッションですべてを抱えず、親セッションから子セッションを立てて仕事を分ける運用にしている。

先日、その子セッションの立て方について、ちょっとした判断をした。ローカルでずっと使っていて、リモートでも欲しいと思っていた Spawn Task が、リモートでも使えるようになっていた。それでも、乗り換えなかった。

欲しかったものが来たのに戻らなかったのはなぜか。振り返ると、「AI ベンダーの機能にどこまで乗るか」という、わりと汎用的な話に行き着いたので残しておく。

ローカルでは Spawn Task に慣れていた

もともと別の環境ではローカル開発が主体で、そこでは Spawn Task をよく使っていた。

Spawn Task は、Claude が作業中に「これは別タスクにした方がいい」と判断したものを提案カードとして積み、人がそのカードをクリックすると新しいセッションとして起動する仕組みだ。Claude は提案するだけで、起動するかどうか・いつ起動するかは人が決める。

この「1 つのセッションから、複数のセッションを気軽に生やせる」感覚に慣れていた。

リモートでは、長文をコピペしていた

一方、この開発環境はリモート（Claude Code on the web）が主流で、当時は Spawn Task が使えなかった。

セッションを分けること自体はしていた。ただしやり方は、親セッションの Claude に「子セッションへの起動文言」を書かせ、それを自分でコピーして、新しいセッションに貼り付けるというものだった。

これが煩わしかった。1 つのセッションから複数のセッションを立ち上げたい場面がそれなりにあり、そのたびに長文をコピペして回る。1 回ならまだしも、何本もやると普通に面倒だ。

代わりに見つけた create_session と、思い描いた理想

Claude には「Spawn Task ってまだリモートで使えないよね」という相談を何度かしていた。そのうちの 1 回で、「チップを出す運用はできないけど、セッションを Claude 側で作る機能ならある」と提案された。リモート環境の Claude が持っている create_session というツールだ。

Spawn Task とはまったく別のツールなので、何ができるのかは未知数だった。最低要件は「子セッションを Claude に立ち上げさせられること」。そこさえ満たせれば、コピペ地獄からは抜けられる。

期待としてはもう少し欲張っていた。一番の理想はこうだ。

• 親から子へ、追加の指示をそのまま出せる
• 子から親へ、完了報告を上げられる
• 私は一番上で管理に専念し、必要に応じて子セッションの様子を見に行ったり、口を出したりする

つまり、Claude だけで上司と部下のタスクの委譲が完結していて、人間はさらにその上にいる、という形だ。

ここで「それならサブエージェントでいいのでは」という疑問が出る。Claude Code には、親が子の AI を起動して作業を任せるサブエージェントの仕組みもある。違いは私が介入できるかどうかだ。サブエージェントは走り出したら人が口を挟めない。セッションなら、子が判断に迷ったとき私に直接聞いてくれるし、セッション一覧で「今なにが動いているか」を目視できる。この 2 点が大きかった。

理想は、わりとすぐ崩れた

実際にどこまでできるのかは、ユースケースを説明したうえで、検証そのものを Claude に任せた。手段の探索も試行も Claude 自身にやってもらい、私は結果を受け取る側だった。この日は検証のために時間を取りつつ、並行して通常の案件も回していた。

結果は、理想とはだいぶ違った。

• 親から子への追い指示が届かない。Claude Code のエージェント間でメッセージを送る SendMessage は、クラウドのセッション同士では相手が見つからず、届かなかった。最初に分かったのはこれだった。
• 子から親に返るのは、1 行の状態ラベルだけ。子が長い説明を書いても、親から取れるのはハーネスが付ける 1 行の要約で、中身はプロンプトで制御できない。やり取りするユースケースを考えるほど、この 1 行がネックになった。
• 遠回りの追い指示には罠があった。スケジュール実行（Routine）経由で子の会話を継続させる手はあるが、数分の遅延がある。即時発火させる手段は、親子関係を無視して別セッションを立て、モデルまで変わってしまった。

つまり、親から子に渡せるのは起動時の一度きりで、子の中身は親から読めない。上司と部下の往復は成立しない。

仕方なく決めた形：子は人に聞く、受け渡しは Issue

そこで、運用の形を次のように決めた。

• 子セッションが判断に迷ったら、親ではなく人（私）に聞く
• セッション間の成果物の受け渡しは、GitHub の Issue / PR / ブランチを経由する
• 起動プロンプトには、子が自力で辿り着けない情報だけを書く（親で人と合意したがまだ Issue に書いていないこと、スコープの境界、人に聞くべき判断の種類）

正直に言うと、これは制約があるから「仕方なく」選んだ形だった。

ただ、運用としてはかなりスムーズになった。もともとセッションをまたぐ運用はしていたので、コピペがなくなって取りまとめ役の親セッションがぐっと楽になった。スキルやドキュメントを整えた段階ですぐ実運用に乗せ、今のところ失敗はない。「これで良かった」と感じる場面ばかりだ。

「仕方なく」が「正解」に変わった理由

今は、この形が正解だったと思っている。理由は、Claude の機能に頼りすぎていないからだ。

もし理想どおり、親子の往復を Claude の機能だけで完結させていたら、運用の中核が特定のベンダーの、特定の機能に乗ることになる。そう考えると、少し怖い。

• この開発はもともと GitHub Copilot Agent で回していて、そこから Claude に乗り換えた経緯がある。AI エンジンは乗り換えるものだ。
• 2026 年 6 月には、公開直後の Claude Fable 5 が、米国の輸出規制の指示を受けて一時的に全ユーザーで使えなくなった（6/9 公開、6/12 停止、6/30 復旧）。特定のモデルや機能は、自分の都合と関係なく止まりうる。
• そもそも Claude の機能は、アップデートでどんどん変わる。今回の Spawn Task のように、増えることもあれば、仕様が変わることもある。

一方、今の形で親子をつないでいるのは Issue / PR / ブランチ、つまり GitHub だ。ここに状態があれば、AI エンジンを乗り換えても運用は崩れないし、途中で人間が作業を引き取ることもできる。制約から逆算した形が、結果的に「ベンダー機能には薄く乗る」設計になっていた。

そして、Spawn Task がリモートに来た

そんな中で、リモートでも Spawn Task が使えるようになった。

気づいたきっかけが面白くて、サブエージェントが勝手に Spawn Task を使っていたのを見たからだ。戻りたいという気持ちより、まず驚きが勝った。

とはいえ、「Spawn Task でもいけるのでは」と改めて考え直しはした。起動のタイミングを人が握れるのは、実は今の運用の「合意してから子を立てる」というルールとも相性がいい。

それでも乗り換えなかった。

• 今、困っていない。安定して回っている運用で、大きな舵を切る必要がない。
• 起点のブランチを指定できない。create_session なら「どのブランチから始めるか」を API のパラメータで確実に渡せるが、Spawn Task はプロンプトしか渡せない。この開発では、子セッションを「完成前の変更を組み立てる作業ブランチ」から始めることが多く、ここを取り違える事故を仕組みで防げなくなる。
• モバイル等でどう見えるかが分からない。提案カードがどの画面に出るのか、まだ確かめていない。
• もともとローカル限定の機能だった。リモートでの挙動がどこまで安定しているかは、まだ様子を見たい。

結論として、Spawn Task は「選択肢としてはあるが、現時点では非推奨」と運用ルールに書いた。前提が変われば再評価する。

おわりに

振り返ると、最初に欲しかったものは後から届いた。でも届いたときには、制約の中で選んだ別の道の方が、自分の運用に合っていた。

AI ツールの新機能は次々に来る。そのたびに乗り換えたくなるが、判断の軸は「新しいかどうか」ではなく、今困っているかと、その機能に運用の中核を預けて大丈夫かの 2 つでいいと思っている。状態はベンダーの外（今回なら GitHub）に置き、AI の機能には薄く乗る。そうしておけば、機能が増えても、止まっても、乗り換えても、運用は崩れない。