Claude Codeの並行セッションがメモリを取り合った日：devサーバーの停止、テストの絞り込み、Macへの引き継ぎ

この日も、Excel 講座の再現動画を複数の Claude Code セッションで並行して作っていた。 CF精算表の Step 6 と Step 7、それに関数の章の組み直し（functions-restructure）が、同じ Windows 機の上で同時に動いていた。

朝8時半ごろ、Step 7 を担当するセッションから「PC のメモリが足りず、裏の作業が Claude Code に止められた」と報告が来た。音声合成も、テストも、dev サーバーも、同じメモリを使っている。 1台の Windows にどこまで載せられるのかは、この時点ではまだ分からなかった。

3000番台と3200番台の dev サーバーを全部止めた

自分は Step 7 のセッションに、3000番台と3200番台の dev サーバーを全部止めてよいと伝えた。「一旦私見ないようにしとくんで」と添えた。ほかの Claude Code が立ち上げようとすると干渉しあって進まなくなるので、立ち上げないようほかのセッションにもメッセージを送ってもらった。

Step 7 のセッションは、08:36 に 3000、3001、3200、3204、3206、3207 番をすべて止め、各セッションへ「しばらく dev サーバーを新しく立てない」と送った。セッション間メッセージ（cross-session-message）が、ここから一日の連絡網になった。 Step 6 のセッションは 08:37 に 3206 番を立て直していたが、知らせを受けて 08:38 に止めた。別件（音声合成サービスの比較）で動いていた mdx-playground 側のセッションにも届き、「dev サーバーが要る作業になったら先に確認する」と返ってきた。

とはいえ、プレビューを見るには dev サーバーが要る。 08:42 に、3200 番だけは立ててよいことにした。この許可も、Step 7 のセッション経由でほかのセッションへ伝えてもらった。

Step 6 を 3200 番で見られないか

CF精算表の Step 6 は、前日に書き出した引き継ぎプロンプトのテキストファイルから始めた。「多分未着手だと思う」と渡したら、やはり未着手で、Claude Code は計画書を書くところから始めた。 Codex のレビューを通し、判断フォームで5項目を選んだ。 5つとも推奨案にした。

本人の声の合成は 6a が188秒、6b が234秒で終わった。ところが、仕上げに dev サーバーが要るので、Step 6 はそこで止まっていた。「3206 番を立て直してよいか」と聞かれたので、「普通に3200でやればいいんじゃないですか？」と返した。

Claude Code の答えは、3200 番では Step 6 が映らない、というものだった。 3200 番は main の作業ツリーを配信していて、Step 6 の台本も画面もまだブランチにしか無い。映すには main へ合流させる必要がある。ただ、main の作業ツリーでは別のセッションが共有ファイル（シーン一覧）を編集中だった。

自分は、一旦待つことにした。ほかのセッションがテストを流したり書き出したりしているので、多分メモリがいっぱいだろうと思ったからだ。

合成が始まらない理由

関数の章のセッションは、前のセッションが書き出した引き継ぎ4から始まった。午前中に、組3b の4本を合成の手前まで進めていた。

自分は「合成立てちゃっていいよ」と言ったあとで、「メモリ使っちゃうから落ちちゃうってことなのかな」と聞いた。 Claude Code の説明では、合成が止まっていたのはメモリのせいではなかった。合成は、この PC では同時に1本しか走らせない。 GPU（8GB）を2本で取り合うと両方止まるので、以前からロックで順番待ちにしてある。そのとき合成していたのは Step 7 のセッションだった。

それなら、合成している側に「終わったら教えて」と頼んでおけばいい。そう伝えてもらうと、Step 7 のセッションから「残り3本、1本あたり約7分」と返事が来た。 09:15 に Step 7 の合成が終わった。

組3b の4本は、合成のあと MP4 まで書き出した（102秒、196秒、136秒、130秒）。単体テストは 88/88 で通った。続く組3c では、空きメモリが 2.7GB まで減っていた。調べると、そのセッション自身が立てた 3200 番の dev サーバーが 2.6GB を使っていた。ポートでそのプロセスだけを止めると、空きは 7GB に戻った。

MP4 はいつ書き出すのか

Step 7 のセッションが MP4 を書き出しているのに気づいたのは、そのころだった。 3200 番のプレビューはブラウザの中で画面と音声を合わせて再生するので、確認に MP4 は要らない。自分は書き出しを止めてもらった。途中までに、7a、7b、7c の3本が書き出されていた。

止めたうえで、流れも決め直した。合成したら 3200 番のプレビューで自分が確認し、直してから最終版だけ MP4 にする。自分が見る前の MP4 は、時間がかかるうえ、直せば作り直しになる。メインの計画書がこの流れになっているかも確かめてもらった。

この指示は 09:46 付けで、Step 7 のセッションからほかのセッションへ回った。 Step 6 のセッションはまだ1本も書き出しておらず、計画書の順番だけを直した。関数の章のセッションも、組3c の手順を同じ形に書き換えた。

同じ指示は、午後にもう一度出すことになる。 Mac に作業を渡したあと、Mac 側とメモリを食う作業の分担をやり取りしていたところで、「MP4の書き出しはやらなくていいっすよ。最終版だけやればいいんで」と改めて伝えた。

同じ重いテストを何本も流す必要はあるのか

昼前、関数の章は引き継ぎ5のセッションに移っていた（組4）。このセッションの合成と全単体テストは、メモリ不足で Claude Code に止められた。

Step 6 のセッションは、合流の前に全コマハッシュのテストを流し始めていた。前回は23分かかったテストである。あわせて関数の章のセッションに、main の共有ファイルをコミットしたら知らせてほしいと頼んでいた。返ってきたのは、「コミットする前に、こちらも全単体テスト（約18分）を流す必要がある」という答えだった。 Step 6 のセッションは、自分のテストを止めて相手に先を譲ろうと提案してきた。

ここで引っかかった。「このテストってセッションごとに流すっていうことはできないんでしたっけ？」と聞いた。何回も同じテストを回す必要はない気がした。

回帰テストはシーンごとに分かれていて、-t で名前を指定すれば、そのシーンだけ流せるという答えだった。 Step 6 のセッションは全コマハッシュのテストを止め（11:20）、残っていた vitest のプロセス2つも止めた。空きメモリは約7.4GB になった。

関数の章のセッションには、「あなたが修正したところだけテストを流してくれればいい」と伝えた。変えたのは再現エンジンの2ファイルだけだったので、その部分の単体テストに絞らせた。加えて、書き出し済みの組3b の4本は、全コマの指紋が変わっていないかを確かめさせた。コミットが済むと、関数の章のセッションから Step 6 のセッションへ「コミットした」と知らせが届いた。

Step 6 のセッションは rebase して main へ早送りで合流した。合流はその前に一度、権限の確認で止まっていたが、自分が許可を出してあった。 3200 番が応答しなかったので、立ててよいかを聞かれ、「y」と返した。 6a（3:08）と 6b（3:54）が、3200 番のプレビューで映るようになった。

3200 番は、この日何度も落ちた。 11:06 に立ち上がった 3200 番は、起動元が Windows Terminal の PowerShell だった。 Step 7 のセッションは手で立てられたものと見なし、止めないよう関数の章のセッションに返した。組5 の作業中には、JavaScript のメモリ上限に当たり、起動から約3分で落ちたこともあった。関数の章の組5 は、8本のうち本人の声が2本しか終わらず、残り6本はまたメモリ不足で止められた。

引き継ぎ6は Mac の Claude Code へ送った

関数の章の引き継ぎは、4→5→6 と一日で2回つながった。区切りのたびに計画書の進捗を更新させ、次のセッション向けのプロンプトをダウンロードフォルダのテキストファイルに書き出させた。午前の区切りでは、再現動画37本のうち22本が台本と本人の声まで済み、残り15本は手つかずだった。

引き継ぎ6は、Windows ではなく MacBook の Claude Code に渡すことにした。 Windows でやると、メモリが落ちてうまくいかないことが多いからだ。

Claude Code は Wi-Fi 越しに Mac のファイル受け取りサーバーへ繋ぎ、コミット80件を bundle で同期した（origin への push はしていない）。未コミットの変更52件は、作業ツリーへの直接展開が権限判定で止められたので、Mac の受け取りフォルダへ tar で置くだけに切り替えた。合成とプレビューに要る大物も送り、約8.4GB が2分半ほどで届いた。

最初、Claude Code は Mac の状態をまとめてチャットの本文に出してきた。自分は「Macに貼るの難しい」と止めた。テキストファイルにして送るか、Wi-Fi で直接メッセージを送れないのか、と聞き直した。 Claude Code は指示書のテキストファイルを Mac の受け取りフォルダに置いた。 claude.ai 経由の直接送信は失敗したが、Mac の tmux で動く Claude Code へ疎通テストを送ると、「受信OK」の返事が返ってきた。そのころには、自分がリモートセッションに貼った指示で、Mac 側が同期を始めていた。二重にならないよう、tmux 側には同期に手を付けないよう伝えてもらった。

1台に載せきる方法は、この日は見つけていない。引き継ぎ6ごと Mac へ渡し、重い合成をそちらで回したのが、この日の答えだった。

Mac の入力欄に残っていた一文

関数の章の組6（3本）は、エンジンと台本を Windows で書き、合成と静止画を Mac に任せた。やり直しの依頼を Mac に送る段になって、送信が止まった。 Mac の Claude Code の入力欄に「はみ出しの画像を見せて」という送信前の文字が15分以上残っていて、ブリッジは打ちかけの文字を上書きしない作りだったからだ。 Claude Code は裏で再送を繰り返していたが、その再送も、Windows のメモリが足りなくなって止められた。

Claude Code は、入力欄の文を自分が打ったものと考え、SSH から消してよいか確認してきた。自分は打っていない。「多分Claude Codeの予測なんで、私がまだ打ったやつじゃないんですよ」と答えた。

灰色で出る入力の予測を、ブリッジが打ちかけの文字と取り違えていた。 Claude Code はブリッジを直し、予測の文字は無視するようにした。長い貼り付けは [Pasted text #1 +N lines] という表示になるので、それまで無視して本物の貼り付けを見落とさないよう、ガードも付けた。 Mac でもテストを通してブリッジを再起動すると、依頼が届いた。

組6の3本も本人の声まで終わり、再現動画37本がすべて、台本、実物の Excel での一致、本人の声の3段まで済んだ。残りは、自分のプレビュー確認と、そのあとの最終版の MP4 と Web への組み込みである。 Web への組み込みはプレビュー確認のことかと聞いたら、別の工程だと説明された。

翌日へ積んだもの

計画書の進捗を更新させ、続きは翌日（9/26）の Google タスクに登録してもらった。

そのあと、Windows のプレビューで何本かが「音声なし」になっているのに気づいた。 8本は、Mac で合成したため音声ファイルが Mac にしか無かった。 Mac から約300MB を取り寄せてもらった。 text-comment の1本だけは、12:39 の合成がメモリ不足で途中で止まり、Windows には途中のファイルしか残っていなかった。 14:00 に Mac で仕上がっていた音声を取り寄せると、112秒の本人の声で流れた。

プレビューを見ていて気づいたカメラの直し（表が全部入る動画はズームをやめて固定する）も、翌日のタスクに別に積んだ。 Step 4 のセッションは、作業と音声がすべて main に入っていることを確かめてから閉じた。

学び

同じ重いテストを、セッションの数だけ流す必要はない。回帰テストがシーンごとに分かれていれば、-t で自分の担当分だけ流せる。変えたファイルの単体テストと、既存動画の全コマの指紋で影響が無いことを示せば足りた
合成が進まない理由は、メモリ不足とは限らない。この日は GPU のロックでの順番待ちだった。止まっている理由を聞いてから手を打つほうが早い
作業を別の機械へ移すと、成果物もそちらに残る。Mac で合成した音声は、取り寄せるまで Windows のプレビューでは「音声なし」と出ていた