セッションを閉じたら次のセッションが自分から再開するようにする（2つの届け方と、その限界）

これは何を解決するか

コーディングエージェント（Claude Code 等）で「1セッション=1目的」を守ると、セッションを閉じる回数だけ「次を開いて引き継ぎコマンドを打つ」手作業が増える。引き継ぎ票（前セッションが残す申し送りファイル）まで自動化しても、最後の「開いて /session-start と打つ」だけが人に残りやすい。

この指示書は、その最後の1手を機械化する2つの届け方と、どちらでもゼロにはできない理由をまとめたものである。先に限界を知らないと、実現不可能な方式に時間を溶かす。

前提: 引き継ぎ票と 開始/終了スキルは既にある想定（無ければ先にそちらを作る）。ここで足すのは「次を開く」部分だけ。

---

0. 先に知るべき限界（ここを飛ばすと必ず遠回りする）

エージェント CLI の外から次の2つはできない（2026-08 時点の Claude Code で実測）。

1. 走っている会話を外部から /clear（新セッション化）できない。 セッション終了フック（SessionEnd）は発火するが、その標準出力は仕様として無視される。コンテキストを注入できるのは開始側（SessionStart）など一部のイベントだけ。
2. エディタ拡張のパネルに外から新しい会話を開かせられない。 拡張は URI ハンドラを持たず、エディタのコマンドも外部プロセスからは起動できない。

したがって取りうる形は次の2つしかない。どちらを選ぶかは「ウィンドウが増えてよいか」で決まる。

mode	何が起きるか	人の操作	向いている環境
window	新しいターミナルウィンドウで CLI を起動し、初期プロンプトに開始コマンドを渡す	ゼロ（初回だけ信頼ダイアログ）	窓が増えてよい
inline	窓を開かず予約だけ置く。次に開いたセッションが自分から開始スキルを実行する	新セッション化の1打鍵だけ	同じ窓で作業を続けたい

両方を実装して設定で選べるようにするのが正解。 片方だけ作ると、必ずもう片方が欲しい機体が出てくる。

---

1. window モード（新しいウィンドウを開く）

終了処理の最後に、CLI を新しいターミナルで detach 起動し、初期プロンプトに開始コマンドを渡す。

実装で踏む罠:

• 親プロセスの環境変数をそのまま渡してはいけない。 エージェント CLI は自分のセッションID・IPC ソケットのパスを環境変数で持っている。継承すると、新しいセッションが今のセッションの子として立ち上がり、別会話にならない。^CLAUDE（自分の製品名の接頭辞）で始まる変数は、明示的に残したいもの以外全部落とす。
• ターミナルの実行ファイルを existsSync で探さない。 Windows Terminal は WindowsApps の実行エイリアス（reparse point）で、fs.existsSync / statSync が EACCES で false を返す。親ディレクトリの readdir に名前が含まれるかで判定する。
• バージョン付きディレクトリから CLI を選ぶときは数値比較。 辞書順だと 2.1.99 > 2.1.250 になる。
• 信頼ダイアログ（「このフォルダを信頼しますか」）を自動で押さない。 これはセキュリティの同意ゲートであり、人が1回押す前提で案内する。

---

2. inline モード（窓を開かず予約を置く）

発想: 終了側は「次のセッションへの予約」をファイルに置くだけ。開始側フックがそれを読んで、エージェント自身に「まず開始スキルを実行せよ」と指示するコンテキストを注入する。人がやるのは新セッション化の1打鍵だけ。

2-1. 状態ファイル

<設定ディレクトリ>/session-relaunch.json:

{ "enabled": true, "armed": { "at": "<ISO8601>", "sessionId": "<閉じた本人のID>", "cwd": "<作業ディレクトリ>" } }

書き込みは必ず一時ファイル → rename。途中で壊れた JSON を残すと、以後フックが毎回黙って死ぬ。

2-2. 予約する（終了スキルの最後）

<tool> --arm --session <このセッションのID> --cwd <作業ディレクトリ>

閉じた本人のセッションIDを必ず記録する。 これが無いと、同じセッションに注入し返して自分自身をループさせる。

2-3. 消費する（開始フック）

セッション開始イベントのフックとして登録し、標準入力の JSON（session_id と source が入っている）を読んで判定する。

注入する条件（全部満たすときだけ）:

• 予約がある / 機能が無効化されていない
• 予約からの経過が 0 以上、上限（例: 7日）以下
• session_id が取れており、予約に記録した本人と違う
• source が startup / clear / fork のいずれか

resume と compact を必ず除外すること。 過去セッションを開き直しただけ・文脈圧縮が走っただけで「引き継ぎ票の別目的を始めろ」と言われると、作業が横取りされる。

注入する本文（コンテキストとして返す）には最低限これを入れる:

• 前セッションが正しく閉じられた事実と日時・作業ディレクトリ
• 「このセッションの最初の行動として開始スキルを実行し、引き継ぎ票から目的を1件だけ確定してから着手せよ」
• 「ユーザーが既に別の依頼を書いている場合はそちらを優先し、この自動再開は無視してよい」（これが無いと、人が別件を頼んだのに勝手に前回の続きを始める）
• 止め方のコマンド1行

出力より先に予約を落とす。 順序を逆にすると、書き込みに失敗した回が二重注入になる。

2-4. フックの鉄則

• 何があっても本体をブロックしない。 全体を try/catch で包み、例外を握って終了コード0で抜ける。
• 標準入力が来なくてもハングしない。 タイマー（2秒程度）を張り、時間切れなら読めた分で進む。フックのタイムアウトでエージェントの起動が毎回遅れるのは体感で効く。
• 条件に合わないときは何も出力しない（空の JSON も出さない）。

---

3. 暴走を止める設計（ここを緩めると無限に自走する）

「閉じたら次が始まる」は、条件を間違えると閉じても閉じても新しいセッションが立つ状態になり、人が終われなくなる。次のどれかを必ず入れる。

• 予約は「終了処理を最後まで通した時」だけ置く。 単に窓を閉じただけでは置かれない＝自走しない。これが一番効く。
• 短命セッションの連鎖を止める（起動から N 秒未満で閉じたら再起動しない）
• 直近 N 秒以内に起動済みなら二重起動しない（window モードのデバウンス）
• 無人実行（CI / headless 環境変数）では起動しない
• 人が上書きできるコマンドを必ず用意する: 状態表示 / 今回の予約だけ取消 / 恒久的な停止と再開

---

4. 検証（ここまでやって「動く」と言える）

純関数（判定ロジック）と実プロセスを分け、判定側は全部ユニットテストにする。

• 予約あり × startup / clear / fork → 注入する
• 予約あり × resume / compact / 不明 → 注入しない
• 自分自身のセッションID → 注入しない
• 予約なし / 無効化中 / 期限切れ / 時計が巻き戻った未来日時 → 注入しない
• window モードで spawn が呼ばれ、inline モードで呼ばれない（spawn を注入してカウントする）
• 実機: 予約 → フックを実際の標準入力で起動して注入 JSON が出る → 2回目は無出力
• 実機: 標準入力を与えずに起動してもハングせず終了コード0
• フック登録スクリプトを再実行して重複登録されない

---

5. 完了報告の書き方

「手作業ゼロ」と書かない。残った操作を正直に1行で書く。

セッションを閉じると予約が入る → 新セッション化の1打鍵だけで、あとは自分から引き継ぎ票を読んで再開する。外部から新セッション化を発火させる公式手段が無いため、この1打鍵は原理的に残る。

限界を隠して「完全自動」と言うと、次にこの仕組みを触る人（や AI）が「壊れている」と誤診して作り直す。