止まったセッションを履歴から復元し、デプロイと dev サーバーの掃除まで通した日

図解を2枚作らせている途中で、画面が動かなくなった。 「ごめん、これ進んでますか？」と打ったが、返事は来ない。

その少し前に、セッションの上限に達したという表示が出ていた。 そのあと続きを頼み、図解の作成には入っていた。 そこから先が動かない。

手元から見えるのは止まった画面だけで、記事がどこまで書けているのかは分からない。 書き上がっているのか、見出しだけなのか。

昼に追いかけていたもの

課税事業者届出書は消費税法57条1項が提出を義務づけている。 義務だと条文に書いてあるなら、破ったときの罰則もどこかにあるはずだ。 それを探すところから始めた。

条文の確認、実務論点の整理、X検索を並行で回させた。 X検索は最初、要約の前置きだけを返して本文を出さなかった。 そこで投げ直させた。

手が止まったのは、以前ChatGPTと話した内容を確認させたときだった。 出典が国土交通省になっている箇所がある。 消費税の話で国交省が出てくる道理がない。 そこから主張を1つずつ一次資料に当て直させた。 核心の論点であるインボイス登録事業者の届出要否は、国税庁のQ&Aと通達まで戻って確定させた。

記事に載せる数値も、書き始める前に全部裏を取らせた。 そこまで進んだところで止まった。

条文と通達をどう追ったかは、課税事業者届出書を出さないと何が起きるか に書いた。

コミットではなく履歴を見せた

新しいセッションを開いて、まず今どういう状況なのかを教えてほしいと頼んだ。

このときgitを見せても意味がない。 記事の分をまだコミットしていないので、履歴には前日までの姿しか残っていない。 どこまで進んだかを持っているのは、止まったセッションのログのほうだ。

そこで「さっきのセッション履歴を見て、途中からやって。ただ、まず計画書と進捗を比べて」と指示した。 どこまで終わったかを自己申告させるのではなく、記録と計画を突き合わせさせたかった。

返ってきた答えは拍子抜けするものだった。 記事本体は止まる前に完成していて、残っていたのは図解2枚が記事に貼られていないことだけだった。 図解を埋め込ませ、lintを通し、表示を確認して終わった。

コミットを3本に分けて押し、origin/master と同期させた。

デプロイの時間はどこで食われたか

デプロイの前に /procs を回させた。 空きメモリが5.6GB、走っているプロセスが9個だった。 余裕があるので、掃除せずそのまま進めた。

/deploy はローカルでビルドしてCloudflare Pagesへ直接上げる。 15時25分に開始した。

内訳を追っていくと、時間の食い方がはっきり分かれていた。 1,881記事のコンテンツ解析が42.3秒。 クライアントビルドが6,761モジュールで約1分40秒、サーバービルドが5,130モジュール。 プリレンダーは7,953ルートを379秒で、ここだけで6分を超える。 仕上げの postgenerate は10ステップで57.1秒。

サーバービルドのところだけは、通過を確かめさせた。 ここは tsconfig を dev サーバーと共有する唯一の場所で、走りっぱなしの dev サーバーがあると競合する。 今回は出なかった。

R2に置いた画像は2,139件をHEADで全件当てさせた。 本番側では buildId を照合し、JavaScriptのチャンク1,354個を検査させた。 最後にR2を同期し直し、cache-bust を付けてもう一度2,139件を検証させて終わった。

「直したらしい」を自分で確かめた

デプロイの最中に通知が出た。 中身を読むと、こちらの変更への指摘ではなく、セキュリティレビュー用フックのスクリプト自体が壊れているというエラーだった。

このフックは別のところで直したと聞いていた。 ただ、聞いただけだ。 デプロイが終わってから、実際にPythonが起動するところまで確認させた。

エラーが指していた括弧は88行目で、is_sdk_compatible() の case 文だった。 修正はすでに入っていて、起動も通った。 同じエラーは再現しない。

「直っているらしい」で止めると、次にこのフックが黙って死んでいても気づけない。 まして壊れていたのはセキュリティレビュー用のフックだ。 黙って死なれると困る。

走りっぱなしの dev サーバー3本

セッションを閉じる前に、余っているプロセスを掃除させた。

数えさせたら dev サーバーが3本立っていた。 3本ともポートを掴んでいる。 掃除ツールの list-dev-procs.py は一部を「ポートなし」と報告していたが、実際には掴んでいた。 検出漏れだ。

止めてよさそうな3件を落としたところ、9プロセス3,869MBが6プロセス1,278MBまで下がった。 空きメモリは5.4GBから8.0GBに戻った。

残した2本のうち、3100は蔵書ナレッジベース、3200は別リポジトリのサイトだった。 どちらもChromeにタブを開いたままだったので、一度は残させた。 ただ、3100はもう使わないので落とすことにした。 3200は使うので残す。 応答が返ることを確認させてから終わった。

最後に残ったのは dev サーバー1本と chrome-devtools MCP 4件だった。

残っている引っかかり

後から引っかかったのは、掃除ツールの報告が実態とずれていたことだ。 「ポートなし」と出ていたプロセスが、ポートを掴んでいた。

今回は3本しかなく目視で追えたから気づいた。 これが10本あったら、気づかずに、使っているサーバーまで巻き込んで落としていたかもしれない。

検出のロジックは、まだ見ていない。