デプロイ21分44秒の半分はDefender、残る5倍差はCPUのJS実行速度だった

このサイトのデプロイ（pnpm generate からアップロードまで）は、Macだと4分40秒で終わる。 同じ処理がWindowsだと20分を超えていた。 2026-08-18から2日がかりでこの差を切り分け、今朝決着したので記録しておく。

結論を先に書く。 犯人は2つあり、半分はWindows Defenderのリアルタイムスキャン、残りはCPUの素のJavaScript実行速度だった。 前者は除外設定で解決済みで、後者は設定では縮まらない。

犯人1: Defenderがファイルアクセスの全部に割り込んでいた

Nuxtの静的生成は、とにかく大量にファイルを開け閉めする。 Viteのビルドに続いて7,800ルート超を書き出し、最後にdistを総なめする検証スクリプトが走る。 Defenderのリアルタイムスキャンは、その1ファイルごとに割り込んでいた。

リポジトリのパスと node.exe と pnpm.exe の3つを除外しただけで、合計は21分44秒から11分30秒になった。 効いたのはファイルを大量に触る工程で、Viteビルドは約2倍、dist検証は5〜10倍速くなった。 一方で、記事のプリレンダー本体は16%しか縮まなかった。 段階別の数字は前日の計測記事にまとめてある。

Defenderを疑ったのは正解だったが、それだけでは説明がつかない差が残った。 プリレンダーはMacの75.7秒に対してWindowsは383.4秒で、まだ5倍の開きがある。

犯人2: 1記事のSSRを単体で測ったら4.75倍差だった

プリレンダーの遅さには、並列数、メモリ圧、SQLite、JS実行と容疑者が多い。 そこで層を分離するため、プリレンダー用バンドルのlocalFetchを直接呼んで1記事のSSRだけを測るハーネスを用意した。 同じ記事300本を同一シードで選び、NODE_ENV=production で逐次レンダリングして統計を取る。 Mac側でも同じハーネスを走らせて、条件をそろえて比べた。

事前に決めた判定基準は「4倍以上ならJS実行速度そのもので決着」だった。 4.75倍なので、並列数やヒープ設定の条件差ではなく、CPUがJavaScriptを回す速さの差だと確定した。

--cpu-prof の内訳もこれを裏付けた。 SQLite（node:sqlite）の読み出しは両OSとも1記事あたり約6msとほぼ同じで、差のほとんどはJavaScriptの実行部分だった。

プリレンダーは1ルートごとにシングルスレッドのJSを回す。 だから並列数を増やしても1記事あたりの時間は縮まず、この差は設定では詰められない。

2020年のCPUは、2026年の新品からどれだけ離されたか

Windows機は2020年に組んだ自作デスクトップで、CPUはRyzen 7 5800Xである。 発売当時は上位のCPUだったが、6年でどれだけ離されたのか。 Geekbenchのチャート平均（2026-08-20取得）で並べてみた。

2026年8月時点でWindowsデスクトップを普通に組むなら、CPUはZen 5世代のRyzen 9000か、IntelのCore Ultra 200Sが定番になる。 次世代のZen 6デスクトップは、報道ベースでは2027年へ延びる見込みだ（→ VideoCardz の報道（2026-07））。 つまり今30万円級で組み直しても、シングルコアはいまの1.4〜1.45倍にしかならない。 しかもチャート上のApple M5は、その新品からさらに2割強上にいる。

注意したいのは、ベンチの倍率と実ワークロードの倍率が一致しなかったことだ。 チャート上のM5は5800Xの1.78倍だが、実測したSSRの差は4.75倍、JS部分だけなら約7倍あった。 この開きの原因は特定できていない。 メモリ帯域やキャッシュ構成の差が効いている可能性はあるが、測っていないので推測の域を出ない。 確かなのは、ベンチの倍率から実ワークロードを外挿すると大きく外れることがある、という実測結果だけである。 だから買い替えの効果も、ベンチ比の1.4倍前後と見込むより、同じハーネスを新しい機材で走らせて確かめるほうが確実だ。

チャートの出典は次の4本である。 → Ryzen 7 5800X / → Core Ultra 9 285K / → Ryzen 7 9800X3D / → Macチャート（M5）

実務の答えと、切り分けの型

実務の答えは単純で、急ぐデプロイはMacから打つ。 Windows機の11分30秒はハードの上限に近い数字で、今朝の本番デプロイでも11分29秒と再現した。

2日間の切り分けを型にすると、次の3手だった。

1. 条件を1つだけ変えて、全体を測り直す（Defender除外の前後で21分44秒が11分30秒に）
2. 残った差は、層を分離する単体ベンチで測る（1記事SSRだけを300本、同一シードで）
3. 内訳はプロファイラで確かめる（--cpu-prof でSQLiteとJSを切り分け）

犯人が複数いる遅さは、全体の再測定だけでは決着しない。 どの層が何倍遅いかを1つずつ固定していくと、設定で直る分と直らない分が分かれて、打ち手が決まる。