Claude Code の並行セッションを、PC の再起動から2回の操作で戻す — 難しかったのは「戻す」より「落としていいか」の判定だった

Windows Terminal のタブを6枚ほど開いて、それぞれ別のプロジェクトで Claude Code を並行で動かしている。PC を再起動するたびに、それを全部元に戻すのが面倒だった。そこで、再起動の前に1回押す「保存」と、立ち上げた後に1回押す「復元」を作った。

結論を先に書く。

• 戻すこと自体は簡単だった。Claude Code は --resume にセッションIDを付ければ会話を再開できる。要るのは「どのタブで・どのフォルダで・どのセッションが動いていたか」の対応表と、それを1回で開き直すコマンドだけだ

• 難しかったのは、保存する瞬間に「このセッションは今、落としてよいか」を決めることだった。分からないものは動いているとみなし、確実に動いているものは止め、疑わしいものは材料を画面に出して私が y/N で決める。この2段にした

• 単体テストも、2〜4タブでの実機確認も全部通っていたのに、本当の再起動では5本中2本が戻らなかった。復元は「複数のタブが同じ瞬間に起動する」唯一の場面で、そこでだけ同じログファイルへの書き込みが衝突した。直してからもう一度再起動したら、5本とも戻った（ただし条件は1回目と少し違う。後で書く）

土台は、前に記事に書いた「セッションの自動切替」と同じ、自作の起動スクリプト（ラッパー）だ。

自動切替は、Claude Code の会話（コンテキスト）が決めた量を超えたら、引き継ぎ資料を書かせてから claude を終わらせ、同じタブで新しい claude を立ち上げて資料を読ませる仕組みだ。AI は自分で /clear を押せないので、ラッパーがプロセスごと入れ替える。入れ替わるたびにセッションIDは新しくなるが、タブとフォルダはそのまま残る。この記事で「自動切替」と書いたら、この入れ替えのことだ。

何が面倒だったか

再起動の前に、私は毎回こうしていた。

1. 全部のタブを目で見て、Claude Code が返事の途中でないか確かめる

2. 全部のセッションに /rename で名前を付ける

3. 再起動する

4. タブを1枚ずつ開いて元のフォルダに移動し、/resume の一覧から名前で探して選ぶ

名前を付けるのは、/resume の一覧で見分けるためでしかない。本当に要るのは「タブとフォルダとセッションIDの対応表」だけで、それは機械が覚えておける。

作ったもの

ボタンは、タスクバーのアイコン2つにした（ピン留めは最初に手で1回だけ）。

• 保存：落とす前に1回押す。動いている Claude Code のセッションを全部調べて、落としてよければ対応表を保存する

• 復元：立ち上げた後に1回押す。保存した対応表から、各タブを元のフォルダ・元の会話で開き直す。ウィンドウの位置と大きさも戻す（これは後から足した）

やらないことも決めた。

• 電源操作はしない。保存した後の再起動は自分でやる。そのため、保存してから再起動するまでの間に始めた作業は、保存した記録に入らない。保存は再起動の直前に押す

• ログインした時の自動復元はしない。押した時だけ動く

• ラッパーを通さずに起動した素の claude は戻さない。見つけたら、数だけ警告する

記録係は hook 3本

対応表は、Claude Code の hook で作っている。

• SessionStart：セッションが始まったら、そのタブの記録を作る（フォルダ・セッションID・プロセスID・起動時刻・起動フラグ）

• UserPromptSubmit：プロンプトが送られたら「動いている」にする

• Stop：返事が終わったら「待っている」にする

記録の鍵は、セッションIDではなく、ラッパーがタブごとに振るIDにした。自動切替が働くとセッションIDは変わるが、タブは同じだからだ。

生きているかどうかは、プロセスIDと作成時刻の両方が一致するかで見る。プロセスIDだけだと、番号を再利用した別のプロセスを「生きている」と読んでしまう。ラッパー自身のプロセスIDも記録する。自動切替の途中には、claude は終わっているがラッパーは生きている隙間があるからだ。

作る前に測ったこと

hook がいつ来て、いつ来ないかは、作る前に手で確かめた（Claude Code 2.1.301）。設計に効いたのは次の4つだ。

• Esc で返事を中断すると、Stop は来ない。このままだと「動いている」のまま残る。そこで、会話ファイルの最後の会話の行が中断の記録（Request interrupted by user）なら「待っている」とみなすことにした。ただし、ファイルの物理的な最後の行は、会話ではなくタイトルなどのメタ情報の行であることが多い。会話の行だけを拾って判定する

• 権限の確認を待っている間も、Stop は来ない。これは「動いている」のままで正しい

• 作業の途中で cd が残ると、hook に渡るフォルダもそれに追従する。フォルダは SessionStart の時のものだけを記録し、上書きしない

• 考えている途中に打った2つ目のプロンプトは同じターンに取り込まれ、UserPromptSubmit だけが来る。間に Stop は挟まらない

ほかに、resume してもセッションIDは変わらないこと、設定に足した hook は既に開いているセッションにも効くこと、hook 1回の処理がプロセス一覧の取得込みで0.6〜1.2秒で済むことも確かめた。

いちばん難しかったのは「落としていいか」

保存ボタンの仕事の大半は、対応表を書くことではない。書いてよいかを決めることだ。返事の途中のセッションを保存して再起動すれば、その作業は途中で消える。

判定は2段にした。

• 確実（止める）：返事の途中、自動切替の途中、記録が無い・読めない。分からないものは動いているとみなす

• 疑い（私が決める）：claude の子孫に残っている背景のシェル（裏で走らせたコマンドなど）と、どのタブにも属さない宙に浮いたシェル。どのタブか・プロセスID・起動時刻・コマンドラインを画面に出し、保存するかを私が y/N で決める。既定は「保存しない」

y/N の画面には、「保存しても、この仕事は止めない。再起動で消えて、復元しても戻らない」と出す。y を押した後にもう一度全部を見直し、押す前から状態が変わっていたら保存しない。実機で試した時は、y を押すまでに私が約1分半かけていた。私が迷っている間にも、ほかのタブの状態は変わる。

y で保存した背景の仕事は、保存した記録にメモしておく。復元の時に「再起動の前、このタブでこれが動いていた」と出す。自動で再実行はしない。

ほかに、保存の対象が0件なら保存しない（再起動の直後にうっかり押して、空の表で上書きしないため）、保存は10世代まで残す、も入れた。

なぜ全部止めないのか

疑わしいものも全部止めれば、判定は1段で済む。そうしなかったのは、自動切替のログを全期間数えたからだ。

自動切替も、入れ替える前に同じことを確かめている。裏で走っている作業があるのに claude を終わらせると、その作業も一緒に消えるからだ。見つけたら、その回の入れ替えは見送る。

その見送りの理由を数えると、1位は裏で走っている作業（61回）だった。2位の「会話がまだ決めた量に届いていない」（51回）より多い。中身を見ると、同じプロセスが別々のタブで犯人扱いされた例が7個あった。あるプロセスは、1日に4つの別のタブの切り替えを止めていた。マシン全体から宙に浮いたシェルを拾う判定が、無関係なタブにまで効いていたのだ。

保存ボタンで同じことをすると、どこかに野良のシェルが1個あるだけで、毎回保存できなくなる。毎回止まるボタンは、すぐに信用されなくなる。だから、確実に動いているものだけを止め、残りは材料を画面に出して、保存するかを自分で決めることにした。

復元は wt でタブを開き直す

復元では、Windows Terminal のコマンド wt で、保存したタブを新しいウィンドウに開き直す。最初の形は、wt を1回だけ呼んで全タブを1つのウィンドウに開くものだった（ウィンドウの位置を戻すようにしてからは、元のウィンドウごとに1回ずつ呼んでいる。後で書く）。1回分の形はこうなる。

wt -w new new-tab -p PowerShell -d <フォルダ> --title <名前> pwsh -NoExit -File <タブ用スクリプト> <引数…> ; new-tab -p PowerShell -d <フォルダ> --title <名前> pwsh -NoExit -File <タブ用スクリプト> <引数…> ; …

タブ用スクリプトは、ラッパーを通して claude を --resume で起動する。元の起動フラグ（--model など）も付け直す。起動の記録154件を見ると、使われていた起動フラグは --model の3件だけだったので、今はそれで足りている。

• 既に生きているセッションは飛ばす。同じ会話を2枚開かない

• 戻したタブは入力待ちで止まる。プロンプトを自動で送らない

PowerShell から wt に渡すところで、2つ踏んだ。

• wt は、引数の要素の中にあるセミコロンを、タブの区切りとして読む。フォルダ名などの値にセミコロンが入っていると、そこでタブが割れる。値の中のセミコロンは、前にバックスラッシュを付けて逃がす

• Start-Process の -ArgumentList は、引数の配列を1つの文字列に潰すので、空白や日本語を含むフォルダ名の引用が崩れる。.NET の ProcessStartInfo.ArgumentList で、1要素ずつ渡す

$psi = [System.Diagnostics.ProcessStartInfo]::new('wt.exe')
foreach ($a in $wtArgs) { $psi.ArgumentList.Add($a) }   # 1要素ずつ。引用は .NET に任せる
[System.Diagnostics.Process]::Start($psi) | Out-Null

戻した claude が、会話を保存しなかった

作っている途中で、いちばん気づきにくかったのがこれだ。Claude Code の中から（AI に Bash で）復元を試したら、戻したタブの claude が次の警告を出し、会話を保存しなかった。

⚠ Transcript saving is off — inherited CLAUDE_CODE_CHILD_SESSION marker

wt は、呼び出し元の環境変数を新しいタブにそのまま渡す。Claude Code の中から呼ぶと、子のセッションであることを示す印（CLAUDE_CODE_CHILD_SESSION=1）が渡り、戻した claude は自分を子だと思って会話を記録しなかった。ほかにも、元のセッションのIDやプロセスID、内部の通信用の値が渡っていた。

タブ用スクリプトの最初で、ユーザーとマシンの永続の環境変数に無い Claude 系とラッパーの変数（と GIT_EDITOR）を、そのプロセスから消すようにして解消した。タスクバーのアイコンから押す普段の経路は、親が Explorer なので起きない。AI に頼んで試した時だけ壊れる道だった。

2〜4タブの実機確認は通った

hook と判定を作った後、2〜4タブで実機確認をした。

• 返事の途中で保存を押すと、確実のほうで止まった

• 裏で sleep を走らせて保存を押すと、疑いのほうで y/N が出て、N で保存されなかった

• y で4件を保存した。セッションIDの重複は0、日本語と空白を含むフォルダ名もそのまま入った

• 2タブを閉じてから復元すると、元のフォルダ・元の会話で入力待ちになった。開いたままの2件は飛ばされた

ずれも4件見つかり、直して確かめ直した。

• /exit で claude を終えても、タブのシェル（＝ラッパー）は残る。これを「自動切替の途中」と判定して確実のほうで止め、待っても外れなかった。自動切替の手順は、claude が終わってから新しい claude が載るまで、どの瞬間も印のファイルが1つ以上ある作りになっている。そこで、印が無ければ「claude を終えたタブ」とみなし、保存の対象から外して1行知らせるようにした

• Claude in Chrome の常駐ホスト（claude.exe を --chrome-native-host で起動したもの）を、ラッパーの外の claude と数えていた。除外した

• 背景の仕事1つが、Git Bash の包みのせいで3〜4行の長い表示になっていた。プロセスの木の葉だけを1行で出すようにした

• 上に書いた、y/N を待っている間の状態の変化

本当の再起動で、5本中2本が戻らなかった

ここまで全部通ったので、本当に PC を再起動した。5タブを保存し、再起動して、復元を押した。3本は戻った。残りの2本のタブには、こう出ていた（一部を省略）。

"3" 個の引数を指定して "AppendAllText" を呼び出し中に例外 … log.jsonl because it is being used by another process

原因は、5本のラッパーが同じ瞬間に、同じログファイルへ1行ずつ書いたことだった。ログには、0.005秒の間に書かれた3行だけが残っていた。

PowerShell から .NET の AppendAllText で追記すると、ファイルは「他のプロセスには読むことしか許さない」共有モードで開かれる。先に開いた1本が書いている間、残りは開けずに例外になる。ラッパーはエラーで止まる設定（$ErrorActionPreference を Stop）で動いていたので、例外でそのまま終了した。それも、claude を起動した直後にだ。claude 本体は裏で生き残り、どのタブにも繋がっていない状態になった。

その場では、生き残った claude を止めて（会話の記録の時刻を見て、入力が無いことを確かめてから）、1本ずつ開き直して戻した。

共有で開くだけでは、行が消えた

素直な直しは、他のプロセスにも書き込みを許す共有モード（ReadWrite）で開くことだ。これで例外は出なくなる。だが、5プロセスから100行ずつ同時に書かせると、500行のはずが423行しか残らず、2行が壊れていた。

各プロセスは、開いた時に知っている末尾に書く。別のプロセスが先に書き足していても、それを知らずに同じ位置へ書き、上書きし合う。例外が出なくなっただけで、黙って行が消える壊れ方に変わった。

直しは3つ重ねた。

• 名前付きの mutex（プロセスをまたぐ鍵）で、書く順番を1本ずつにする

• 共有モードで開き、書く直前に末尾へ移動（Seek）してから書く

• 書けなくても落ちない。何度かやり直して駄目なら諦め、「書けなかった」と1行出して続ける。このログは診断用なので、1行欠けるより、ラッパーが落ちて claude が宙に浮くほうがずっと困る

芯の部分を簡略化すると、こうなる（実物は、これをファイルが使用中の時だけ数回やり直し、駄目なら1行知らせて続ける）。

$m = [Threading.Mutex]::new($false, 'Local\session-log')
$acquired = $false
try {
  try { $acquired = $m.WaitOne(2000) } catch [Threading.AbandonedMutexException] { $acquired = $true }
  if ($acquired) {   # 鍵が取れなければ書かずに諦める（鍵なしで書くと、また上書きし合う）
    $fs = [IO.FileStream]::new($logPath, [IO.FileMode]::Append, [IO.FileAccess]::Write, [IO.FileShare]::ReadWrite)
    try { $null = $fs.Seek(0, [IO.SeekOrigin]::End); $fs.Write($bytes, 0, $bytes.Length) } finally { $fs.Dispose() }
  }
} catch {
  # 読み取り専用・権限の拒否なども含めて、ここでは落とさない
} finally {
  if ($acquired) { $m.ReleaseMutex() }
  $m.Dispose()
}

ただし、この鍵に入っているのは PowerShell で書いたラッパー側の書き手だけだ。同じログに書くもう1つの書き手（Python で書いた側）は、まだ入っていない。

テストは3本足した。他の書き手と共有して書けること、ロックされたままでも落ちないこと、5プロセスが同時に書いて500行が1行も欠けないこと。直す前のコードで落ちるのを確かめてから直した。

別のモデルのレビューが、さらに2つ見つけた

直した後、別のモデル（DeepSeek V4.1 Flash）にレビューさせたら、2件出てきた。

• 最初の直しは、mutex を2秒待って取れなくても、鍵なしで書いていた。これでは、混んでいる時ほど上書きし合う。取れなければ書かずに諦めるようにした（上のコード片はこの後の形）

• IOException しか捕まえていなかった。ファイルが読み取り専用だったり、権限が拒否されたりすると、別の種類の例外でラッパーごと落ちる。IO 以外の例外でも諦めるようにした

この2件にもテストを足した（別のプロセスが鍵を握ったまま放さない／ファイルが読み取り専用）。直す前のコードで、2本とも落ちるのを確かめた。

テストが全部通っていたのに、なぜ漏れたか

単体テストには、複数のプロセスが同じファイルに同時に書く場面が無かった。実機確認では復元で2タブを同時に開いていたが、2本では当たらなかった。5本で初めて当たった。

普段は、タブは私が手で1枚ずつ開くので、ラッパーが同じ瞬間に起動することはない。復元は、複数のタブが同じ瞬間に起動する唯一の場面で、それはこの道具が存在する理由そのものだ。道具の目的が、それまで一度も起きなかった衝突を作った。

今は、5プロセス同時のテストがこの衝突の番人になっている。N 本を同時に起こす道具を作るなら、N 本同時のテストは最初に置いておくべきだった。

直してから、もう一度再起動した

2回目の再起動の前に、もう1つ足していた。ウィンドウの位置と大きさの復元だ。最初の形では、元が何枚のウィンドウに分かれていても、全タブが1つの新しいウィンドウにまとまって開く。私はウィンドウを画面に横に並べて使っているので、これでは並べ直しの手間が残る。

タブから、それを載せているウィンドウを引く

保存の時に、各タブの claude がどの Windows Terminal のウィンドウに載っているかを調べる。Windows Terminal のウィンドウは claude とは別のプロセスのものなので、claude のプロセスIDから探しても見つからない。そこで、コンソールを経由する。

• claude のプロセスのコンソールにつなぐ（AttachConsole）

• そのコンソールの窓を取る（GetConsoleWindow）

• その窓の持ち主を根元までたどる（GetAncestor に GA_ROOTOWNER）。すると、そのタブを載せている Windows Terminal のウィンドウに着く。同じウィンドウの2タブからは、同じウィンドウが返った

着いたウィンドウのクラス名が Windows Terminal のもの（CASCADIA_HOSTING_WINDOW_CLASS）かも確かめてから、位置・大きさ・最大化かどうかを記録に足す。取れなかったタブは足さないだけで、保存は止めない。

芯の部分はこうなる（Win32 の宣言と、失敗した時の後始末は省略）。

[void][Win32]::FreeConsole()                     # 自分のコンソールを外してから
if ([Win32]::AttachConsole($claudePid)) {        # claude のコンソールにつなぐ
  $con = [Win32]::GetConsoleWindow()
  $wtWindow = [Win32]::GetAncestor($con, 3)      # 3 = GA_ROOTOWNER
  [void][Win32]::FreeConsole()                   # 次のタブの前に外す
}

1つ落とし穴があった。つないでいる間に何かを出力すると、それはつないだ先のタブの画面に流れる。調べる側は何も出力せず、結果はファイルに書いて、保存の本体がそれを読む形にした。

復元はウィンドウごとに wt を呼ぶ

復元では、元のウィンドウごとに wt を1回ずつ呼ぶ。呼ぶ前に Windows Terminal のウィンドウの一覧を撮り、呼んだ後に増えたウィンドウが1枚に絞れた時だけ、それを元の位置へ動かす（SetWindowPos）。絞れなければ、別のウィンドウを動かしてしまうより、位置を戻さないほうを選ぶ。wt がウィンドウを開き切る前に動かすと位置が届かないことがあるので、少し待って確かめ、ずれていれば一度だけ掛け直す。

結果

2回目の再起動では、5本とも戻った。5本とも保存したセッションIDの --resume で起動して、入力待ちで止まった。勝手に動き出したタブも、同じ会話が2枚開いたタブも無かった。4枚のウィンドウの位置と大きさも、保存した値と完全に一致した。

ログには、5本とも起動の行が残った。同じウィンドウに戻した2タブは、0.0048秒差でほぼ同時に書き、2行とも残った。鍵が効いている。

ただし、これは1回目と同じ条件の再現ではない。ウィンドウを1枚ずつ開くようにしたので、同じ瞬間に起動したのは、同じウィンドウの中の2本だけだった。1回目に当たった「5本が同じ瞬間に起動する」場面は、直した後の本当の再起動では、まだ起きていない。そこを守っているのは、今も5プロセス同時のテストだ。

ターミナルは選び直さなかった

再起動で消えるのは claude のプロセスなので、どのターミナルを使っても、--resume で起こし直す手間は残る。ターミナルに要るのは「コマンド1発で複数のタブを開ける」ことだけだ。いくつか見たうえで、Windows Terminal のままにした。

• WezTerm：復元の機能はあるが部分的

• Warp：機能の一部がクラウド前提

• Claude のデスクトップアプリ：ラッパーが載らない。Windows の再起動でセッションが一覧から消えるという報告もある（anthropics/claude-code の issue 54759）

先行例として、GitHub gist の「Restore-Claude」も見た。SessionStart hook で記録して wt の new-tab で開き直す骨格は同じだが、生きているか・動いているかの確認が無く、自動切替も考えていない。今回の手間の大半は、その2つにあった。

まだ確かめていないこと

• 5本が同じ瞬間に起動する場面は、直した後の本当の再起動では、まだ起きていない（ウィンドウごとに開くようにしたため）。今はテストが番人だ

• ログを書くもう1つの書き手（Python で書いた側）は、まだ mutex に入っていない。同時に書く窓は小さいが、0ではない

• 私の1台・私の使い方での話だ。普段は6タブ前後、Windows 11 と PowerShell 7、Claude Code 2.1.301 で確かめた

まとめ

Claude Code の並行セッションを再起動から戻すのに要るのは、「タブとフォルダとセッションIDの対応表」と、それを1回で開き直すコマンドだけだった。そこは hook 3本と wt で済む。

手間がかかったのは、保存の瞬間に「落としてよいか」を決めるほうだった。分からないものは動いているとみなし、確実なものだけ止めて、疑わしいものは材料を画面に出して自分で決める。全部止めるボタンは、野良のシェル1個で使えなくなる。

そして、テストが全部通っていても、本番の再起動で5本中2本が戻らなかった（直してからの再起動では、5本とも戻った）。複数のタブが同時に起動するのは、この道具が働く時だけだ。道具が作る状況は、道具を作る前には一度も起きていない。