Node.js の10月セキュリティ更新と漏えいした中間CA証明書に2台のPCで対応した日

朝に書いた Node.js の記事には、同梱ライブラリの更新として「ルート証明書（eMudhra の中間 CA 侵害への対応を含む）」という一行がある。 書いた時点では、表の下を通り過ぎる一項目でしかなかった。 その名前が、夕方には自分で貼ったテストサイトの画面として戻ってきた。

この日は、2台のPC（Windows と Mac）の脆弱性対応が二つ重なった。 Node.js の10月セキュリティリリースと、漏えいした eMudhra の中間CA証明書である。 その合間に、朝から止まっていたブログの本番デプロイを再開した。

朝、メモリが足りずにデプロイを止めた

朝のセッションで、ブログの本番デプロイを始めていた。 デプロイ前の確認で未 push のコミットが32件あると分かり、先に push してもらった。 OG 画像を返す Worker を先に出して本番で確かめ、続けて Pages のデプロイを本番向けに走らせた。

ビルドが進むあいだに、メモリがほぼ埋まった。 不要なプロセスを消しておいてほしいと頼み、/procs を回してもらった。 Claude Code は deploy-lock をまだ取っていないことを確かめてから、デプロイの親プロセスを子プロセスごと止めた。 空きメモリは 1.1GB まで落ちており、止まったのはプリレンダーの初期化の段階だった。

進捗は全体計画に書き戻してコミットし（push はしていない）、引き継ぎをテキストファイルに書いてもらった。 06:40、デプロイを途中で切り上げて、再起動の準備に入った。 止めたデプロイが今日のうちに本番へ出せるかは、この時点では分からなかった。

Node.js の10月リリース、2台とも修正前の版だった

08:19 からのセッションで、Node.js の10月セキュリティリリースについて、手元が対象かを調べてもらった。 Windows は対象だった。 Mac も、Homebrew の Node 26.5.1 で対象だった。 2台とも、修正前の Node が動いている。 調べた内容は記事にまとめた（Node.js 2026年10月のセキュリティリリース：自分の環境が対象か調べて更新する手順）。

更新には、すぐには手を付けなかった。 慎重にやったほうがよさそうに思えたので、先に計画書を作ってもらった。 計画書は Codex のレビューにかけ、3回目で承認が出た。 判断事項4件は決裁フォームで答え、4件とも推奨の A を選んだ。

途中で、見覚えのない呼び名に引っかかり、何それ、と聞き返した。 Claude Code が勝手に付けた略称だった。 正体は、Windows のタスクスケジューラに登録してある、ポートフォリオ記録の定期タスクである。 決裁4件のうち1件は、この定期タスクが使う Node の版番号を 22.23.4 に書き換えるものだった。 略称は、そのままでいいと返した。

ほかのセッションが動いたままでも大丈夫かを尋ねてから、Windows 側の Phase 1 と Phase 2 を進めてもらった。 Phase 1 のあと、node -v は v22.23.4 を返した。 古い 22.22.2 と 24.12.0 は消さずに残してある。 Phase 2 では定期タスクを手動で起動し、新しい版（v22.23.4）で動き出すことを確かめた。

ここで Claude Code が、自分の説明を一つ訂正した。 先に「今朝の定期タスクは 404 で失敗している」と説明していたが、実際はデータの更新まで最後まで済んでいた。 404 は代わりの取得先へ切り替えたことを知らせる警告で、処理は止まっていなかった。 成功を記録するファイルも、07:16 に今日の日付へ更新されていた。 それでも終了コードが1になった理由は、まだ分かっていない。 別の日には「ログファイルが使用中」（EBUSY）で落ちた跡もあった。 どちらも Node の版とは関係がないので、別件として issue に分けてもらった。

途中でログインし直してから続けてもらい、3つのリポジトリでコミットまで済ませた。 push はしていない。

最後に、今日シャットダウンして明日立ち上げ直せば Node も新しくなるのかを聞いた。 答えは、なる、だった。 Windows の PATH から見える node は mise の shim だけで、shim は起動のたびに mise の設定を読んで既定の版を選ぶ。 既定はもう 22.23.4 なので、次に立ち上げれば dev サーバーも MCP（chrome-devtools）も 22.23.4 で起動する。 いま古い版で動いている20本は、今朝 7:01〜8:42 に起動したもので、PC を落とせば全部消える。 デプロイしていいとも伝えて /deploy を打ったが、Claude Code はこのセッションではデプロイを実行せずに止めた。

午後、引き継ぎから再開したデプロイ

14:36、朝の引き継ぎファイルを開いて、いまどうなっているかを聞いた。 引き継ぎの Step 1〜5 は、まだ一つも手を付けていなかった。 確認を済ませて4コミットを push してもらい、事前検査も3本とも通った。

本番デプロイの起動は、Claude Code の自動許可の判定に「本番デプロイ」として止められた。 Claude Code は迂回せずに止まり、実行するコマンドを1行で示した。 それを ! 付きでプロンプトに貼り、自分で起動した。

15:35 に始まった再開後の1回目は、朝に止めた段階を越えた。 空きメモリは 5.7GB あり、朝の 1.1GB より余裕があった。 15:43 にプリレンダーの初期化が終わり、15:48 にプリレンダーも終わった（7,135 ルート、約382秒）。 ところが、そのすぐあと 15:48 にデプロイは止まった。 止まった工程はリダイレクトの生成（generate-redirects）で、本番は 10-21 の版のままだった。 原因の修正は、非公開にした記事を指す手動リダイレクト6件を外すコミットとして入れてもらった。

15:53 に始めた2回目は、16:04 にプリレンダーを終えた（7,135 ルート、約359秒）。 今度は generate-redirects を通り、サイトマップの生成と検査3つも通った。 deploy-lock を取ったあと、R2 へ画像 2,304 件をコピーし（約6秒）、配信先で 2,304 件すべてが取れることも確かめた。

途中で、ずいぶん時間がかかっていないかと聞いた。 返ってきたのは、ここまで約13分で、手順書の目安（約12〜20分）の範囲内だという答えだった。 アップロードは 16:06:46 に終わった。 そのあと、本番の主要ページと JavaScript 1,394 本が新しいビルドのものかを検査し、R2 の同期と画像の再取得の確認も通った。 デプロイは所要14分で終わった。

デプロイ後の確認では、非公開にしたはずの記事のうち3本が、まだ本番で見えていた。 cf CLI を直してからキャッシュを消すよう頼んだが、3本はキャッシュを消しても 200 を返し続けた。 次の手として Claude Code が勧めた案は、コミットのときに Codex のレビューで止まった（判定は critical）。 Claude Code も、その勧めの前提が甘かったと認めた。 そこで案を選び直し、WAF のルールで遮断する方を取った。

WAF ルールの追加も、自動許可の判定に「共有リソースの変更」として止められ、コマンドを自分で貼って実行した。 1回目は何も起きなかった。 Claude Code が渡したコマンドに、rules create には無い --force が付いていて、「Unknown argument: force」でヘルプを出して終わっていた。 --force を外して打ち直すと、3本は 403 になり、対照に選んだ公開ページ5件は 200 のままだった。

旧デプロイの URL でも同じ記事がまだ読めたので、Access のアプリを1つ作って閲覧を制限した。 WAF ルールの撤去（10-29）は Google タスクに入れた。 最後に、確認を求めるはずの git stash list がプロンプトなしで通った件を調べてもらった。 プロジェクトで ask にしている17件のうち7件は、ユーザー設定の allow にも入っていた。 ただ、公式ドキュメントどおりならプロンプトは出ていたはずで、原因はまだ特定できていない。

夕方、漏えいした中間CA証明書（eMudhra）

eMudhra 社の中間CA証明書が漏えいした件で、確認用のテストサイトの画面を貼り、どういう状況かを聞いた。 Claude Code の判定では、使っているブラウザは漏えいした証明書をもう信頼していなかった。 ただし表の半分は判定できておらず、時間を置いて「Run again」を押せばはっきりする、という説明だった。 次に貼った画面では、DidNotConnect になっていた。

ほかに調べることはあるかと聞くと、Claude Code はこのPCで実際に接続テストをした。 相手は、テストサイトが用意している2つのサイト（G3 経由と AAA 経由）である。 Python、Java、git の3つは、漏えいした証明書のサイトにまだ普通につながった。

直しておいてほしい、と頼んだ。 Windows では git と Python の requests を直してもらい、テスト用サイト2つで結果を確かめてもらった。 Mac については、cross-machine-message で Mac 側のセッション（claude2）に調査と修正を頼んだ。

Java と Python の扱いを重ねて聞き、世の中がどう対応しているかも調べてもらった。 Java は自動では更新できなかった。 Python の標準ライブラリは、待つしかない。 Claude Code のまとめでは、ブラウザと OS はほぼ自動で済み、ブラウザ以外のプログラムは利用者が自分で更新している、という状況だった。

Mac 側の claude2 は 17:23 に作業を終えていたが、こちらへの返信は届いていなかった。 Mac の受信サーバーが応答しなくなっており（node server.mjs が2つ動いていた）、claude2 の画面は SSH で直接読んでもらった。 claude2 は、Mac の画面で自分が2行打つのを待っていた。

学び

• ブラウザのテストで DidNotConnect が出ても、同じPCの Python、Java、git は漏えいした証明書のサイトにまだつながった。ブラウザの結果だけで、PC 全体を大丈夫とは判断できない
• Windows の node は mise の shim 経由なので、既定の版を上げておけば、再起動のあとに起動するプロセスは新しい版でそろう
• 空きメモリ 1.1GB で止めたデプロイは、5.7GB の状態でプリレンダーの初期化を越えた。再開後の1回目が止まった原因は、メモリではなくリダイレクトの生成だった

朝の記事で一行だけ名前の出た eMudhra は、夕方の接続テストで Python、Java、git を引っかけた。 Windows の git と requests は直った。 Mac の画面では、まだ2行が打たれるのを待っている。