ブログのセキュリティ強化

　この記事では、

• 🔗ブログのコード修正

のその後について述べます。

サイバー攻撃対策で、Cloudflare Pages ビルドシステム V3 へ移行した件

• 🔗相次ぐサイバー攻撃や情報漏えいにどう備える？専門家が語る個人や企業の対策
• 🔗【解説】世界のサイト7割で使用「PHP」に重大な脆弱性――AIが発見　急がれる『バグマゲドン』への備え

というようなニュースが連日流れています。

　特に、ハダノのように自分のドメインを持ちサイト管理をしている者にとって、セキュリティ強化は急務です。賃貸より持ち家の方が、防犯防災などの安全対策が重要となるのと同じです。

ブログを更新しようとしたらエラーだと？

　10月になり、ブログを更新しても反映されなかったので Cloudflareダッシュボード を開いてみたら、ビルドエラーで止まっていました。

　調べてみると、Cloudflare Pages のビルドシステムが変わったことが原因でした。

📌背景：Cloudflare Pages V3 強制移行のセキュリティ的意義

　2026年9月15日、Cloudflare Pages は従来の V1 ビルドシステムを廃止し、V3 ビルドシステム（ベースOS: Ubuntu 22.04、デフォルトNode.js: v22）への完全強制移行を実施しました。

　この移行は開発者に互換性対応のコストを強いる一面もありますが、近年のサプライチェーン攻撃の激激化を踏まえると、極めて重要なセキュリティ上の防衛策です。

• アタックサーフェス（攻撃面）の縮小: 脆弱な古いビルドイメージをプラットフォームから一掃する。
• EOL（サポート終了）環境の排除: セキュリティホールの温床となる古い Node.js バージョンの利用を強制的にリセットする。
• 認証情報・トークン盗難の防御: サプライチェーン攻撃による環境変数やデプロイトークンの漏洩リスクをインフラレベルで低減する。

🛑 今回直面したトラブルと、泥沼化した「4つの罠」

　Nuxt 3（静的サイト生成: npx nuxt generate）で構築されたブログ（kyodx.com）において、移行直後にビルドクラッシュが発生。解決を試みる中で、インフラ、モジュール、Git、ローカル環境の 4 つのレイヤーでトラップが連鎖し、問題が複雑化しました。例によって、 Gemini の助けを借りながら取り組んでいきました。

罠①：依存パッケージ（chokidar）のバージョン不一致

　ビルド環境が新しくなったことで、プロジェクトが要求する Node.js バージョンとのミスマッチが発生。さらに、最新のパッケージ（[email protected]）が要求する Node.js バージョン（>= 20.19.0）に対し、既存設定の古いバージョン（20.11.0）が読み込まれたため、パッケージインストール（yarn install）の段階でビルドが即時クラッシュしました。

罠②：GitHubの特定コミットへの固定（Cloudflare Pages の検知バグ）

　環境変数を wrangler.toml やダッシュボードで NODE_VERSION = "22" に修正したにもかかわらず、Cloudflare 側がいまだに古い 20.11.0 を読み込み続ける怪現象が発生しました。

• 原因: Cloudflare Pages が GitHub の特定の古いコミットハッシュに固定された状態（スタック）になり、ローカルからいくら修正をプッシュしても、バグが起きている過去のコードを何度も繰り返しダウンロードしてビルドを回していたことが判明しました。

罠③：Nuxt SEOモジュール群（@nuxtjs/seo / nuxt-schema-org）の内部クラッシュ

Node.js のバージョン問題をクリアした直後に発生した、第 2 のビルドクラッシュ：

[error] [GET] "/sitemap.xml": 500 Server Error

• 原因:パッケージを最新化（yarn upgrade）した結果、@nuxtjs/sitemap や @nuxtjs/seo が新環境（Node.js 22 / 最新の Nitro）の内部構造と互換性を保てず、自動プリレンダリング処理（サイトマップ生成）の段階で内部インスタンスを見失い自爆していました。さらに、nuxt-schema-org も内部的なエイリアス（#site-config）の解決順序の変更に伴い、Vite/Rollup のインポート経路の解決に失敗していました。

罠④：ローカル環境（Gitキャッシュ）への「バグの残骸」の混入

　Cloudflare 上で Git 連携の切断・再接続を行っても、再び上記サイトマップのエラーが再発しました。

• 原因: 本来 .gitignore に指定されるべき自動生成フォルダ（.nuxt）内の、過去の壊れた中間コンパイル成果物（nitro.mjs など）が、誤ってローカルの Git 管理（リポジトリ内）に含まれてしまっていたため、プッシュするたびに「バグの塊」が Cloudflare に強制同期されていました。

🛠️ 泥沼を突破した「完全解決へのシーケンス」

　これらの連鎖するトラップを、以下の手順で完全にリセット・解決しました。

1. ローカルのバグキャッシュを Git から徹底排除（VS Code ターミナル）

　Windows（PowerShell）環境において、Git に誤って追跡されていた .nuxt の残骸をインデックスから削除し、物理フォルダもクリアしました。

# Gitの追跡からキャッシュフォルダを除外
git rm -r --cached .nuxt

# ローカルの物理キャッシュフォルダを強制削除（Windows環境用コマンド）
Remove-Item -Recurse -Force .nuxt

2. 競合モジュールの無効化（コメントアウト）

　根本的な原因である @nuxtjs/sitemap や、それを裏で勝手に自動展開する親玉モジュール @nuxtjs/seo を nuxt.config.ts から完全にコメントアウト（無効化）しました。

　これにより、Google AdSense（@nuxtjs/google-adsense）など大切な機能の有効状態を維持したまま、エラーを出す処理だけを完全にバイパスさせました。

3. 【究極の解決策】別名によるプロジェクトの「完全新規作成」

　既存プロジェクトにロックされていた古いインフラキャッシュや Wrangler 設定の影響を 100% 遮断するため、現在のプロジェクトを一度置き、Cloudflare 上に nuxthblog2 という別名で完全に新しい Pages プロジェクトを作成（Continue with GitHub ➔ Pages ワークフロー）しました。

• Build command: npx nuxt generate
• Build output directory: dist
• Environment variables: NODE_VERSION = 22（後に 24 へ統一）

　これで、過去の残骸が一切ないクリーンなサーバー空間に、修正済みの最新コードがロードされ、Nuxt の本番ビルド・デプロイが完全に成功しました。

4. ローカル環境の近代化

　最新のパッケージ構成に引きずられ、ローカルでの npm run dev 起動時に styleText（node:util 内の最新API）が見つからずクラッシュする現象（SyntaxError）が発生。

• 対応: PCの Node.js を公式サイトから最新の長期サポート版である v24.21.0 LTS へアップデート。VS Code を再起動したことで、ローカルの開発・下書きモードも正常化しました。

5. 古いプロジェクトの安全な隠居とカスタムドメインの引っ越し

　新旧 2 つのプロジェクトが同時に走るのを防ぐため、古い nuxthblog の「Git統合（Git integration）」から接続を Disconnect（連携解除） しました。

　その後、独自ドメインが古いプロジェクトに掴まれたままだったため、以下のステップでカスタムドメイン（kyodx.com）の安全な引っ越しを行いました。

1. 古いプロジェクトの「Custom domains」から対象ドメインを Remove（削除）。
2. 新しい nuxthblog2 の「Custom domains」に同ドメインを 再登録（検証・初期化を経てアクティブ化）。

【まとめ】Cloudflare Pages ビルドシステム V3 への移行は骨が折れるが、安全には代えられない

　これが、今回のビルドシステムの移行顛末です。

　サーバーサイド言語としてのシェア7～8割のPHPを、教育DXブログは使っていません。シェア1割前後のNode.jsを使っているから大丈夫……とは言い切れません。JavaScript系のNode.js、Vue、Nuxtだっていつ危うくなるやもしれません。可能な限り、システムを最新のものにアップデートしたいものです。

　攻撃側がAIを活用してくるなら、防御側もAIを活用すべきです。

　ビルドシステムの移行作業はたいへんですが、AIの助けがあれば恐れることはありません。エラーログをもとに質問することで、必ずやりとげられます。

💡 同じ問題で苦しむ人への教訓

1. Cloudflare Pages で設定がどうしても反映されない時: 　それはコードやダッシュボードのミスではなく、 インフラ側が古いコミットやビルドキャッシュを強力に掴んで離さないバグである可能性を疑うべきです。その場合、「プロジェクトを別名で新規作成し直す」 のが最も手っ取り早く、100% 確実な解決策になります。
2. モジュールのバグに引きずられない: 　@nuxtjs/sitemap などの外部モジュールが Nitro や Nuxt のコアアップデートの過渡期に 500 エラーを吐く場合、インフラ側の設定（ignore）で耐えようとせず、nuxt.config.ts の modules 配列からコメントアウトして完全に黙らせる べきです。Google 広告（AdSense）モジュールが独立していれば、SEOモジュールを一時的に切っても広告配信や検索ロボットのクローリング（自動巡回）に致命的な悪影響はありません。
3. Gitの管理範囲に注意: 　自動生成ファイル（.nuxt など）が一度でも Git 追跡に紛れ込むと、ローカルの壊れた環境がクラウドへ永久に同期され続けます。git rm -r --cached での定期的なお掃除が有効です。

←前へ　ブログのコード修正