Claude Code のセッション自動切替を実装した — テストは全部通ったのに、動かしたら穴が2つ出た

自動で切り替わった新しいAIが、作業を1手だけ進めて、黙って私の返事を待っていた。

前回の記事で、Claude Code のセッションをプロセスごと入れ替えて、引き継ぎを全自動にする仕組みを書いた。使い捨ての検証で、端から端まで1回通した段階だった。

今回はそれを本実装して、実際に長い作業を任せて動かした。単体テスト77本、本物のプロセスを使う結合テスト10本、起動スクリプトのテスト24本は、全部通っていた。それでも、実際に動かしたら穴が2つ出た。

• 切り替わった後のAIが、自走をやめる

• 「会話が続くかどうか」の印を、別の場所で読んでいた

どちらも、設計書にもテストにも、別のモデル3つによるレビューにも出てこなかった。この記事では、この2つと、実装の途中で見つけた「落としたのに再起動しない」経路を書く。

仕組みのおさらい

AI（Claude Code）は自分で /clear も /exit も押せない。だから、外側から入れ替える。

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

2. コンテキストが閾値を超えると、ツールを呼ぶたびに鳴る hook がAIに「次のキリで引き継いで」と知らせる

3. AIがキリで引き継ぎ資料を書き、「切っていい」という目印のファイルを置いて、返事を終える

4. 返事の終わりに鳴る hook（Stop hook）が、別プロセスの「終了係」を起こす。終了係は条件を確かめ直してから Claude Code を終了させる

5. ラッパーが「この資料を読んで再開して」という指示つきで Claude Code を起動し直す

Windows では、hook から起動したプロセスは hook の終了と一緒に消される。だから終了係は WMI 経由で起動している。ここまでは前回書いたとおりだ。

作る前に、前提を撃った

設計は「環境変数がこう引き継がれるはず」「hook の知らせがAIに届くはず」という前提の上に立っていた。本体を書く前に、これを実際の Claude Code で確かめた。確かめ方は、答えを知っている仕掛けを入れて、それが出てくるかを見る形にした。

たとえば「hook の知らせがAIの文脈に届くか」は、hook の出力にランダムな合言葉を入れて、AIにその合言葉を答えさせた。知らせを出さない回も作り、そちらでは合言葉が出ないことも確かめた。

いちばん効いたのは、プロセス番号の確認だった。この仕組みは「どの Claude Code を落とすか」を、環境変数に入っている Claude Code 自身のプロセス番号で決めている。ところが、Claude Code の中から別の Claude Code を起動した場合、子が親の番号をそのまま引き継いでいたら、子が置いた目印で親が落とされる。

そこで、子を起動する前に環境変数へ偽の番号（1）を入れておき、子の中でその番号が見えるかを確かめた。見えなかった。今回確かめた起動の仕方では、子は自分の番号で上書きしていた。加えて、落とす直前には番号だけでなくプロセスの作成時刻も照合し、ラッパーが起動した時刻より前に置かれた目印は使わないようにしている。番号が再利用されていても、古い目印が残っていても、別のプロセスは落とさない作りだ。

この確認で、道具の側の落とし穴も1つ踏んだ。PowerShell で環境変数を消すつもりで次のように書くと、変数は消えずに空の文字列として残る。

[Environment]::SetEnvironmentVariable('MY_TEST', $null)   # 消えない。空文字で残る
Remove-Item Env:MY_TEST -ErrorAction SilentlyContinue      # こちらは消える

PowerShell が $null を空の文字列に変えて渡すためだ。「変数が無いこと」を確かめる対照群で、無いはずの変数が空で届いて、判定が落ちた。テストが落ちた時は、まず道具を疑う。今回はそれで正しかった。

「落としたのに再起動しない」経路

実装がひととおりできた段階で、また別のモデルにレビューさせた。DeepSeek V4.1 Flash に「操作の順番と、取り返しのつかない操作」、Kimi K2.7 に「途中で落ちた時に残る状態」、Claude Sonnet 5 に「Windows のプロセスの前提」を見てもらった。

3本が、別々の角度から同じ場所を指した。終了係が Claude Code を落とした後に、再起動の情報を書く前に何かが失敗すると、Claude Code は死んだまま再起動されない。

当時の順番はこうだった。

1. 条件を確かめる

2. Claude Code を落とす

3. 本当に消えたかを確かめる

4. ラッパーとの間で「どちらがこの切り替えを担当するか」を取り合う

5. 再起動の情報を書く

ラッパーは Claude Code が終了すると目を覚まし、30秒待っても結果が出なければ「諦めた」として印を片付ける。その片付けが4番より先に来ると、終了係は取り合いに負ける。負けるのは、もう落とした後だ。

直し方は、順番を入れ替えることだった。

1. 条件を確かめる（直前にもう一度）

2. 取り合いを済ませる。負けたら、落とさずに終わる

3. 再起動の情報に必要なものを、全部読んでおく

4. Claude Code を落とす

5. 再起動の情報を1回書く

取り合いは、ファイルの名前を変える操作1回で決めている。名前の変更は、先に成功した側だけが勝つからだ。

import os

def claim(src, dst):
    """src を dst へ改名する。先に取った側だけが True を得る"""
    try:
        os.rename(src, dst)   # Windows では dst が既にあると失敗する
        return True
    except (FileNotFoundError, FileExistsError, PermissionError):
        return False

前回の記事で「取り返しのつかない操作の直前には、機械が同じ条件を確かめ直す」と書いた。今回はそれに1つ足す。取り返しのつかない操作の後に残す仕事は、できるだけ小さくする。

正直に書くと、ゼロにはできていない。落とした後の「再起動の情報を1回書く」は残っていて、ここでディスクの書き込みが失敗したり、終了係が異常終了したりすれば、再起動はされない。その場合も引き継ぎ資料は残っているので、手で新しいセッションを立ち上げて資料を読ませれば続きから再開できる。落とす前に書いておき、ラッパーが「落とされた」ことを見分けて再起動する形にすればこの穴も塞げるが、普通に終了した時に誤って再起動しないこととの両立が要るので、次の課題にしている。

実走で出た穴1：切り替わったAIが、1手で止まる

テストが全部通ったので、実際に動かした。ダミーの作業を用意して、閾値を11万トークンに下げ、「最後まで自走して」と指示した。作業は「設計書を全文読んで、カウンターを1つ増やす」の繰り返しで、6に達したら完了とした。

切り替えそのものは、設計どおりに動いた。

• 閾値を越えた直後に、AIに知らせが届いた

• AIは「1周が終わったこの瞬間がキリ」と判断して、資料を書き、目印を置き、自分で返事を終えた

• 目印から約5秒で Claude Code が落ち、0.4秒後に新しいセッションが立ち上がった

• 新しいセッションは資料を読み、「手順2の続き」から正しく再開した

そして、1周だけ進めて、返事を終えた。カウンターは2から3になったところで止まり、私の返事を待っていた。

私が「続けて」と打つと、また閾値まで回って、また自分で引き継いだ。そして3つ目のセッションも、1周で止まった。2回とも同じ形で止まった。

原因は、最初の指示にあった。最初のセッションは「最後まで自走して」と言われて始まっている。ところが、切り替わった後のセッションが受け取るのは「資料を読んで、次の一手から再開して」だけだ。資料には「次に何をするか」は書いてあったが、「私の返事を待たずに続けるのか」は書いていなかった。新しいAIは、真面目に1手やって報告した。

直し方は2か所だった。

• 引き継ぎ資料に「進め方」を必ず1行書かせる。「自走（返事を待たずに完了まで続ける）」か「対話（1手ごとに報告して待つ）」のどちらか

• 再開の指示に「資料の進め方に従うこと」を足す

直してからもう一度動かすと、一度も口を挟まずにカウンターが6まで進み、その間に2回切り替わった。

振り返ると、引き継ぐべきものは「作業の中身」だけではなかった。人が同僚に仕事を渡す時、「急ぎで、終わるまで進めておいて」と「区切りごとに相談して」は、作業の中身と同じくらい大事な情報だ。AIどうしの引き継ぎでも、それは変わらない。

実走で出た穴2：差し戻しの印は、別の場所にあった

終了係には「落とさない条件」がいくつかある。その1つが、同じタイミングで別の hook がターンを差し戻したら落とさない、だ。Stop hook は返事の終わりを止めて、AIに作業を続けさせることができる。その時に落とすと、続くはずの会話を殺してしまう。

判定には、Claude Code が Stop hook の後に会話ファイルへ書く記録を使っている。項目の名前から、差し戻された時は preventedContinuation が true になると読んで作っていた。

実走の最後に、ちょうどその場面が起きた。見張りの hook が返事の終わりを差し戻して、AIに知らせを届けたのだ。その回の記録を見ると、こうなっていた。

{"type": "system", "subtype": "stop_hook_summary",
 "preventedContinuation": false,
 "hookErrors": ["（差し戻しの理由の文面）"],
 "hasOutput": true}

会話は続いたのに、preventedContinuation は false だった。差し戻しの理由は hookErrors という欄に入っていた。私の判定は、本物の差し戻しを素通りしていた。今回は、見張りの hook が「切り替えの目印がある時は黙る」作りだったので、実害は出ていなかった。ただ、差し戻す hook を別に置いた日には、続くはずの会話を落としていた。

1件だけで判定を変えるのは危ないので、手元の会話ファイルを14日分さかのぼって数えた。この記録は1,424回あった。

• どの欄も空だった回：1,419回。どれも会話は続いていない

• hasOutput だけが true だった回：4回。どれも会話は続いていない（差し戻さない hook が何かを出力しただけと見られる）

• hookErrors に文面が入っていた回：1回。これが今回の差し戻しで、会話は続いた

hasOutput は、差し戻さない hook が何か出しただけでも true になる。だから判定には使わない。hookErrors は差し戻しの理由が入るが、別のモデルに確かめさせたところ、hook の異常終了でも入る作りのようだった。こちらは、入っていたら念のため切らない側に倒すことにした。間違えた時の損が、切り替えを1回逃すだけで済むからだ。14日間で、差し戻し以外の理由で入っていた回は0回だった。

項目の名前を信じて作ると、こういう所で外す。名前ではなく、実際に起きた時の記録で確かめる。

数字の訂正：新しいセッションは8万から始まる

前回、「新しいセッションは約3万トークンから始まる」と書いた。実測すると、約8万トークンだった。ルールとメモリのほかに、システムの指示、ツールの定義、スキルの一覧が最初から載っている。2回の切り替えとも、再開直後は約8.2万だった。

この差は大きい。閾値を低く置くと、切り替えた直後に、また切り替わってしまう。テストで閾値を8万ではなく11万にしたのは、このためだ。本番の閾値は、15万から20万に上げた。

では、何万で切るのがいいのか。切り替えるたびにかかる手間（資料を書く出力と、新しいセッションのキャッシュの作り直し）を O、1回のツール呼び出しで増える量を g、新しいセッションの床を F とすると、合計の読み直しがいちばん少なくなる閾値は、ざっくり次のあたりになる。

閾値 ≈ F + √(2 × O × g)    （O は読み直しの単価に換算した量）

キャッシュの作り直しは、読み直しより単価がずっと高い。手元の概算を入れると18万前後になるが、O も g もまだ当て推量だ。20万で1週間動かして、切り替えごとの「減った読み直し」と「切り替えの手間」を記録から数えてから決め直す。

いまの状態と、この先

いまは、実際の長い作業で、私が一度も触らないまま2回切り替わって完了まで進む状態になった。途中で /clear をしてもプロセス番号は変わらないこと、Esc や Ctrl+C で生成を中断しても外側のラッパーが巻き込まれないことも確かめた（/clear は1回、中断は3回の確認）。

ただし、Windows で、私の環境で動かしただけだ。自動で切り替わるのも、hook を登録したこの1台だけになっている。

今回いちばん大きかったのは、テストの数ではなかった。テストは「私が思いついた失敗」しか確かめない。思いついていなかった失敗は、実際に動かした時にしか出てこなかった。自走が引き継がれないことも、差し戻しの印の場所も、仕様を読んで想像していた形と、実物の形が違っていた。

トークンがどれだけ減ったかは、1週間分の記録を数えてから書く。