Claude Code のセッション引き継ぎを全自動にする — AIは /clear を押せないので、プロセスごと入れ替えた

Claude Code で長い作業をしていると、会話がどんどん膨らむ。私はこれまで、キリのいいところでAIに引き継ぎ資料を書かせ、自分の手でセッションを終了し、新しいセッションを立ち上げて「この資料を読んで続きから」と指示する、という作業を繰り返してきた。

ある日ふと、これはアナログすぎると思った。この一連の流れを全自動にしたい。

結論から書くと、AI（Claude Code）は自分で /clear も /exit も押せない。そこで、セッションをプロセスごと終了させて、外側のスクリプトが「資料を読んで再開して」という指示つきで起動し直す形にした。使い捨ての検証（スパイク）で、引き継ぎ資料を書くところから新しいセッションが資料を読んで再開するところまで、端から端まで通っている。

この記事では、その仕組みと、作る途中で踏んだ3つの落とし穴を書く。

• hook から起動したプロセスが、hook の終了と一緒に消される（Windows）

• 「ターンの終わり」は、自律作業ではほとんど来ない

• 別のモデルにレビューさせたら、安全装置の大半がAIの自己判断頼みだった

なぜセッションを切るのか

目的は2つあった。

• 会話の記録は全部残したい

• コンテキストを短くして、トークン消費を減らしたい

2つ目の理由ははっきりしている。AIは1ターンごとに、それまでの会話全体を読み直している。キャッシュが効くので毎回の料金は定価より安いが、読む量そのものは会話の長さに比例する。長いセッションほど、1ターンが重くなる。

実際、この仕組みを設計していたセッション自体が、設計書を書き始める直前の時点で約17万トークンに達していた。会話の最後の応答に付いている使用量（入力・キャッシュ作成・キャッシュ読み込みの合計）を足すと、今どれだけ読み直しているかが分かる。

import json, sys

last = None
for line in open(sys.argv[1], encoding="utf-8"):
    try:
        o = json.loads(line)
    except ValueError:
        continue
    u = (o.get("message") or {}).get("usage") if o.get("type") == "assistant" else None
    if u:
        last = u

keys = ("input_tokens", "cache_creation_input_tokens", "cache_read_input_tokens")
print(sum((last or {}).get(k) or 0 for k in keys))

引数には、Claude Code が書き出している会話ファイル（JSONL）を渡す。

会話の記録は、もう残っていた

1つ目の目的は、調べたら追加の作業が要らなかった。

Claude Code は、セッションごとに会話を JSONL ファイルに書き出している。手元を数えたら、約3ヶ月分で1,205本・1.9GBあった。セッションを切っても前の会話のファイルは消えないし、自動の要約（compact）が走ってもファイルの中身は畳まれない。畳まれるのはAIが読む文脈のほうだけだ。

ただし、古いファイルは設定した日数（cleanupPeriodDays）で自動的に消える。私の環境では90日にしていて、いちばん古いファイルがちょうど90日前のものだった。消えるのはもう始まっていたわけだ。永久に残したいなら、別の場所へのバックアップが要る。私は毎朝バックアップを取っているので、そちらで足りていた。

ここで判断が1つ変わった。引き継ぎ資料は「記録」のために書く必要がない。資料の役目は「再開を速くすること」だけに絞れる。これで設計がかなり軽くなった。

AI は /clear を押せない

次に、公式ドキュメントで「AIや hook からセッションを切り替える手段」を探した。結果は、無かった。

• /compact などの組み込みコマンドは、スキル経由でも呼べないと明記されている

• hook の出力で /clear や /compact を起動する項目は無い。compact の直前に鳴る hook は、compact を止めることしかできない

• セッション開始時の hook には「最初のユーザー発言」を差し込む項目（initialUserMessage）があるが、-p（非対話モード）専用で、対話セッションでは使えない

つまり、今のセッションを内側から入れ替えることはできない。残る道は、外側からプロセスを終了させて、外側から起動し直すことだった。

仕組み：終了させて、起動し直す

全体の流れはこうだ。

1. Claude Code を、自作の起動スクリプト（ラッパー）経由で立ち上げる

2. コンテキストが一定量を超えたら、AIが作業のキリで引き継ぎ資料を書き、「切っていい」という目印のファイルを置いて、返事を終える

3. 返事が終わった時に鳴る hook（Stop hook）が目印を見つけて、Claude Code のプロセスを終了させる

4. ラッパーは、Claude Code が終了したのを見て目印を確認し、あれば「この資料を読んで再開して」という最初の指示つきで Claude Code を起動し直す

Claude Code は、起動時に文字列を渡すと、それを最初の指示として対話セッションを始める。initialUserMessage の代わりにこれを使う。ラッパーの芯を簡略化して書くと、次のようになる（検証で使ったものから、ログ出力などを省いた）。

$prompt = $null
while ($true) {
    if ($prompt) { & claude $prompt } else { & claude }
    $req = Join-Path $stateDir 'restart.requested.json'
    if (-not (Test-Path $req)) { break }   # 目印が無ければ普通の終了
    $handoff = (Get-Content $req | ConvertFrom-Json).handoff_path
    Move-Item $req (Join-Path $stateDir 'done') -Force
    $prompt = "引き継ぎ資料 $handoff を読んで、続きから再開して"
}

実際には、再起動の暴走を止める回数制限や、次の節で書く「切断の結果を待つ」処理が入る。

落とし穴1：hook から起動したプロセスが消える

最初の検証は失敗した。AIが目印を置き、hook は鳴り、ログにも「終了させる係を起動した」と残っている。なのに、Claude Code はいつまでも終了しなかった。

hook の中で Claude Code を即座に終了させると、同じタイミングで走っている他の hook まで道連れにしてしまう。そこで「5秒待ってから終了させる係」を、hook から切り離したプロセスとして起動していた。Python の DETACHED_PROCESS を付け、標準入出力もすべて切り離したものだ。

その係が、仕事をする前に消えていた。原因を確かめるために、「3秒後にファイルを1つ書くだけ」のプロセスを2通りの方法で起動して比べた。

• 切り離して起動したもの：ファイルが書かれなかった

• WMI 経由で起動したもの：ファイルが書かれた

Claude Code は、hook やツールの実行が終わると、そこから生まれたプロセスをまとめて片付けているように見える（Windows のジョブ機能と推定している。挙動から推定しただけで、ジョブそのものは調べていない）。WMI 経由で起動したプロセスは WMI 側のサービスの子になるので、この片付けの外に出られる。

import base64, subprocess

killer = f"Start-Sleep 5; taskkill /PID {pid} /T /F"
encoded = base64.b64encode(killer.encode("utf-16-le")).decode("ascii")
cmdline = f"powershell -NoProfile -WindowStyle Hidden -EncodedCommand {encoded}"
res = subprocess.run(
    ["powershell", "-NoProfile", "-Command",
     f"(Invoke-CimMethod -ClassName Win32_Process -MethodName Create "
     f"-Arguments @{{CommandLine='{cmdline}'}}).ReturnValue"],
    capture_output=True, text=True,
)
# PowerShell の終了コードと、WMI が返す ReturnValue（0 が成功）を別々に見る
if res.returncode != 0 or res.stdout.strip() != "0":
    raise RuntimeError(f"killer not started: rc={res.returncode} wmi={res.stdout.strip()!r}")

引用符の入れ子を避けるために、実行したい PowerShell を UTF-16LE の Base64 にして -EncodedCommand で渡している。また taskkill の出力はそのままだとログで文字化けしたので、UTF-8 で書き出すように直した。

hook から「後で何かをさせる」処理を切り離して起動すると、Windows では静かに消える。ログには「起動した」と残るので、気づきにくい。

本当に壊れないか確かめた

プロセスを外から強制終了するのは、公式ドキュメントに載っている使い方ではない。なので、壊れていないかを数えて確かめた。

• 会話ファイルは欠けていなかった。すべての Stop hook の完了記録（6本・エラー0）と、そのターンの所要時間の記録が、終了させる約5秒前には書かれていた。終了させなかった回のファイルと比べて、行数も末尾の形も同じだった

• 最後の返事から約7秒で、新しいセッションが立ち上がった

• 新しいセッションは、ダミーの引き継ぎ資料に書いた合言葉を正しく答えた

• 終了させたプロセスの子で、取り残されたものは無かった

ただし、これは同じ日に同じPCで1回通しただけの結果だ（Windows 11・Claude Code 2.1.281）。仕組みが正しいことの証明ではなく、「この道は通れる」という確認にとどまる。

落とし穴2：「ターンの終わり」は思ったより来ない

最初の設計では、返事が終わるたびに鳴る Stop hook でコンテキストの量を測り、閾値を超えたらAIに「切り替えて」と知らせるつもりだった。

これを見て、ふと疑問に思った。私の使い方では、AIは私と会話せずに延々と作業を進める。そもそもターンの終わりはいつ来るのか。

Stop hook が鳴るのは、AIが返事を書き終えて入力待ちになった時と、裏で走らせた作業の完了通知で起こされて、その作業を終えた時だけだ。自分の過去の記録を数えたら、直近120セッションの28%で、私からの1つの指示に対して、ツールの呼び出しが50回以上続いていた。最大は2,122回で、その間に自動の要約が4回挟まっていた。

Stop hook だけで見張ると、一番膨らむ場面を丸ごと見逃す。そこで役割を分けた。

• 見張り：ツールを呼ぶたびに鳴る hook（PostToolUse）で測る。作業の途中でも知らせが届く

• 切断：Stop hook のまま。落としてよいのは返事の区切りだけだからだ

知らせを受けたAIは、キリのいいところで資料を書き、自分から返事を終える。そこで Stop hook が鳴って切り替わる。つまり、切れるかどうかは最終的にAIが返事を区切るかどうかに懸かっている。区切らないまま走り続けた場合の最後の網は、自動の要約になる。ツールの実行中に外から強制終了する案も考えたが、実行中の作業と会話ファイルの完了記録を壊すので採らなかった。

落とし穴3：安全装置の大半が、AIの自己判断だった

設計書ができた段階で、別のモデルにレビューさせた。DeepSeek V4.1 Flash に観点を変えて2回、Claude Sonnet 5 に1回だ。観点は「途中で失敗した時にどうなるか」「どの安全装置が機械で強制されていて、どれがAIの判断に任されているか」「Windows のプロセスの前提は正しいか」の3つにした。

3本とも、別々に同じ所を突いてきた。AIが目印を置いた瞬間から、機械は何も確かめずにプロセスを落とす。

設計書には「迷ったら切らない」と書いてあった。「答えを待っている時は切らない」「裏で作業が走っている時は切らない」という条件もあった。ところが、その条件を判断するのはAIだけだった。AIが一度でも見落とせば、裏で走っていたビルドごと落とされる。

そこで、落とす直前に機械が7つを確認し、1つでも外れたら切らない形に変えた。

1. ラッパー経由で起動したセッションで、しかも自分が起動したプロセスと一致するか

2. 引き継ぎ資料が存在して、空でないか

3. 自動で切る時は、コンテキストが本当に閾値を超えているか

4. 裏の作業が走っていないか

5. 落とす相手のプロセス番号が、待っている間に別のプロセスに再利用されていないか

6. 短時間に何度も切っていないか（超えたら、再起動だけでなく切ること自体を止める）

7. そのターンの完了記録を待ったか（前のターンの記録で早とちりしていないか）

4番目は、完全には機械で確かめきれない。当初は「Claude Code の子にシェルが残っていないか」で見るつもりだったが、記事の下書きをさらに別のモデル（Codex）に読ませたところ、シェルが先に終わって孫のビルドだけが動き続けている場合や、シェルを通さずに起動した処理を見逃すと指摘された。そのとおりなので、判断できない時は切らない側に倒すことにして、見分け方は本実装で詰める。

他にも、「落とすのを諦めた時に目印が残り、後で普通に終了した時に意図せず再起動する」経路が見つかった。これは、再起動の目印を落とすのに成功した後にだけ書くことで塞いだ。ただしそうすると、今度はラッパーが先に目を覚まして、目印が書かれる前に「普通の終了だ」と判断してしまう恐れがある。そこで、切断が始まった時点で「切断中」の印を別に置き、ラッパーはその印があれば、成功か失敗かの結果が出るまで待つようにした。

振り返ると、最初の設計は「AIに判断させる」ことと「AIの判断を信じる」ことを区別していなかった。判断はAIに任せてよい。ただし、取り返しのつかない操作の直前には、機械が同じ条件を確かめ直す。この線を引けたのが、レビューでいちばん大きな収穫だった。

いつ切るか：15万トークンという目安

閾値は、まず15万トークンから始める。根拠はざっくりした見積もりで、料金ではなく「1ターンごとに読み直す量」だけで考えている。

• 新しいセッションは、ルールやメモリの読み込みだけで約3万トークンから始まる。引き継ぎ資料を読むと、再開直後はおよそ5万トークンになる

• 15万で切れば、その次のターンから1ターンあたり約10万トークン、読み直す量が減る

• 一方で、切り替えには資料を書く出力と、新しいセッションの読み込み（キャッシュの作り直し）がかかる。これらは読み直しとは単価が違うので、単純な足し引きでは損益を言えない

細かく切りすぎると、この床と切り替えの手間で損をする。どこが最適かは使い方で変わるので、動かしてから種類別の使用量を記録して直すつもりだ。

いまの状態と、この先

いまは、スパイクで仕組みが通ることを確かめ、レビューを反映した設計書ができた段階だ。本実装はこれからで、最初にやるのは次の確認になる。

• ツールのたびに鳴る hook の知らせが、本当にAIの文脈まで届くか

• ラッパーで設定した環境変数が、hook のプロセスまで引き継がれるか

• 裏の作業とそれ以外の子プロセスを、正しく見分けられるか

うまくいけば、長い自律作業が、私が一度も触らないまま何度でも繋がるようになる。実際にどれだけトークンが減ったかは、動かしてから改めて書く。

追記（2026-09-25）：実装して動かした結果、「いつ切るか」の節の数字を2つ訂正する。新しいセッションは約3万トークンからではなく、約8万トークンから始まっていた（ルールとメモリのほかに、システムの指示・ツールの定義・スキルの一覧も最初から載っている）。そのため閾値は15万から20万に上げた。