覚えのないデプロイの犯人は自分の別セッションだった — Claude Codeマルチセッション運用の落とし穴

開発claude-code-tools

覚えのないデプロイの犯人は自分の別セッションだった — Claude Codeマルチセッション運用の落とし穴

朝7時7分と7時52分

朝、eurekapu-nuxt4のセッションで画像1,800枚あまりのアップロード完了を待っていた。待ち時間にここまでの作業を整理してもらっていたら、報告の中に本番デプロイの記録が2件混じっていた。今朝の7時7分と7時52分。

時刻を二度見した。やってない。少なくともこのリポジトリでは、今朝そんな操作をした覚えがない。

「覚えてないんですけど。このeurekapu-nuxt4ではやってないと思うんですけどね」。そう返しながらも、言い切る自信はなかった。並行で複数のセッションを走らせている朝で、どこで何を承認したか、全部は思い出せない。

ただ、デプロイは本番を書き換える操作だ。実行元が分からないまま流すわけにはいかない。アップロードの監視はそのまま続けさせて、誰が・何がデプロイを走らせたのかの調査を任せた。

その朝、手元で何が並行して走っていたか

このeurekapu-nuxt4のセッションでは、進行中だった画像の一括再生成が明け方に完走して、1,837枚のアップロードが淡々と進んでいた。進捗の見張りは自動通知に任せて、自分は節目の報告を受け取るだけの時間帯だった。

一方で、別ウィンドウにはwordpress-migrationフォルダで開いたセッションがいた。WordPressで作っていたクイズをEurekapuに移植する作業をさせていたやつだ。同じ朝にこの2本が走っていたことが何を意味するか、このときの自分はまだつかんでいない。

実行元は自分のもう一つのセッションだった

ほどなくして「実行元が確定しました」と返ってきた。デプロイを走らせたのは、自分のもう一つのClaude Codeセッションだった。

根拠として挙がってきたのは、次の2点だ。

  • そのセッションはwordpress-migrationフォルダで開かれているが、この朝の作業対象はeurekapu-nuxt4のクイズページだった
  • 7時7分と7時52分の2回のデプロイは、そのクイズページ作業の流れで実行されていた

外部からの侵入でも、事故でもない。指示を出したのは自分だった。

「このディレクトリの話をしてるんじゃなかったの?」

ところが、この報告を聞いた時点ではまだ腑に落ちていなかった。

「ごめん、eurekapu-nuxt4のディレクトリだけの話をしてるんじゃなかったんですか?」と聞き返している。WordPress移行のフォルダで別セッションを動かしていることは知っている。でも、いま話しているのはこのディレクトリで起きたデプロイのはずで、なぜ別フォルダのセッションが犯人になるのか。

話が噛み合わないまま、しばらく往復した。

返ってきた説明で、止まっていた頭が動いた。話は最初から「このeurekapu-nuxt4リポジトリで起きたデプロイ」のこと。ただし、WordPress移行セッションはwordpress-migrationフォルダで開かれているだけで、作業対象はeurekapu-nuxt4リポジトリだった。

「WordPressのクイズをEurekapuに移植する」という流れの中で、あのセッションの作業対象はいつの間にか移植先のリポジトリに移っていた。移植とは移植先を書き換える作業だから、当然そうなる。

あー、そういうことか、と声が出た。

自分はセッションを「開いたフォルダの名前」で認識していた。wordpress-migrationで開いたセッション=WordPress側をいじっているセッション、という等式が頭の中にあって、そのセッションがこっちのリポジトリを書き換えてデプロイまでしている可能性を、最初から選択肢の外に置いていた。

フォルダ名はセッションのラベルであって、作業範囲の境界ではない。

切り分けを速くしたのは記録だった

実行元がすぐ確定したのは、突き合わせられる記録が両側に残っていたからだ。デプロイ側にはwranglerのデプロイ履歴が時刻付きで残る。手元には各セッションのログが残る。

7時7分・7時52分という時刻を持って各セッションのログに当たれば、その時間帯にデプロイを走らせていたセッションは一つに絞れる。

記憶は「やってないと思う」までしか言えなかった。記録は実行元まで言い切った。

学びメモ

  • セッションを開いているフォルダと、実際の作業対象リポジトリは一致しない。「AをBに移植する」型の作業では、A側のフォルダで開いたセッションがB側のリポジトリを書き換え、デプロイまで実行する
  • 複数のClaude Codeセッションを並行で走らせる運用では、フォルダ名でセッションを認識していると作業対象を見誤る。今回は「移植」という、作業対象が途中でもう一方のリポジトリへ移る種類のタスクで表面化した
  • デプロイのような対外操作は、実行元を突き止められるログ(wranglerのデプロイ履歴・各セッションのログ)があると切り分けが早い
  • セッションの見分け方は、フォルダ名ではなく「いまどのリポジトリを書き換えうるか」で持つ。並行本数が増えるほど、この一覧を頭に置いておく必要がある
  • 記憶を疑う前に記録を引く。「やってないと思う」は半分だけ正しかった — この画面で承認した覚えがないのは事実だったが、自分の指示から派生した操作までは記憶がカバーしていなかった

並行セッションは今後も増える。フォルダ名で見分ける癖が抜けたかというと、まだ怪しい。次に「覚えのない操作」が出たとき、真っ先に自分の別セッションを疑えるかどうかで、この日の学びが本物だったか分かる。

#Claude Code#マルチセッション #デプロイ #運用