Node.jsの脆弱性にどう対応するか｜公式のセキュリティリリースをClaude Code・Codexに読ませて自作アプリを更新した手順

Node.jsの脆弱性への対応とは Node.jsの脆弱性への対応は、Node.js公式のセキュリティリリース告知を一次情報として読み、手元のPC・プロジェクトのバージョン指定・本番環境の3か所で使っているNode.jsのバージョンを確かめ、影響があれば今使っているメジャーバージョンの修正版（2026年10月21日の告知ならv26.12.1・v24.22.1・v22.23.4以上）へ更新して、テスト・ビルド・動作確認をする作業です。Vercelのような管理型の本番環境では、マイナー・パッチの配布はプラットフォーム側が行うため、自分で上げる範囲と、反映を待って確かめる範囲を分けます。

Claude Code・Codexで業務アプリやホームページを自作して公開している経営者・個人事業主・士業・会社員にとって、「Node.jsにセキュリティリリース」「PHPに重大な脆弱性」というニュースは、作って終わりではないと気づく最初の場面です。放置するのも、よく分からないまま最新版へ上げてアプリを壊すのも、せっかく作ったものがもったいない。やることは決まっているので、順番だけ押さえましょう。なお、ここに書くのは2026年10月時点で公式に確認できた範囲と、みやっち🧑‍💻の自社環境での実施記録です。どの環境でも同じ結論になる手順ではありません。

2026年10月21日に何が公表されたのか

Node.js公式は2026年10月21日に、2026年10月のセキュリティリリースを公表しました。対象は26.x・24.x・22.xの3系列で、修正版はv26.12.1・v24.22.1・v22.23.4（以上）です。

公式ページでは、今回修正された問題の最高深刻度はHIGH（高）とされ、DNS（dns.resolve がNUL文字を含む名前を切り詰める）、TLS（証明書のホスト名検証を回避できる）、Brotli（デコーダの範囲外書き込みで遠隔のコード実行につながりうる）など10件のCVEが並んでいます。

同じ日にPHP公式も、2つの重大な脆弱性を修正する版（PHP 8.5.12・8.4.27・8.3.36・8.2.35）を公式のセキュリティ告知で公開し、すべてのPHP利用者に直ちに更新するよう呼びかけました。WordPressはPHPで動くので、こちらは後半で触れます。

自作アプリのNode.jsは3か所で動いている

「Node.jsのバージョンを確認する」と聞くと手元のPCだけを思い浮かべがちですが、公開しているアプリでは少なくとも3か所を見ます。

1. 手元のPC: ターミナル（黒い画面）で node -v を実行すると表示されます。Node.js公式のコマンドライン一覧で「Print node’s version.」と説明されているオプションで、--version と同じです。
2. プロジェクトのバージョン指定: .nvmrc や package.json の engines に「このプロジェクトはこの版で動かす」と書いてあることが多く、CI（自動テスト）やホスティング側がこれを参照します。AI Crew HP（このサイト）の package.json は node >=22.12.0 です。
3. 本番環境: Vercelなどの管理型サービスでは、利用者が決められる範囲が手元と違います（後述）。

依頼文の2番目のステップに「Docker、CI/CD、本番環境なども確認できる範囲で」と入れてあるのは、この3か所目を忘れないためです。

Claude Code・Codexに貼る依頼文（原文）

みやっち🧑‍💻が2026年10月21日にDiscordで配った依頼文がこれです。Claude Code・Codexのどちらに貼っても使える書き方にしてあります。URLの部分を、そのとき出た公式告知に差し替えて使ってください。

以下のNode.js公式セキュリティリリースを確認し、現在の開発環境および管理しているプロジェクトへの影響を調査してください。

https://nodejs.org/en/blog/vulnerability/october-2026-security-releases

実施してほしいこと

1. 公式リリースの内容を読み、今回修正された脆弱性と影響を受けるNode.jsのバージョンを把握してください。

2. 現在のPC、開発環境、各プロジェクトで使用しているNode.jsのバージョンを調査してください。Docker、CI/CD、本番環境なども確認できる範囲で対象に含めてください。

3. 今回の脆弱性の影響を受ける環境があるか確認し、リスクの大きさと対応の優先順位を判断してください。

4. アップデートが必要な場合は、既存のプロジェクトへの互換性を考慮し、原則として現在使用しているメジャーバージョンの修正版へ更新してください。

5. 更新後はテスト、ビルド、動作確認を実施し、問題が発生していないか検証してください。

6. 最後に、調査結果、実施した変更、残っているリスク、追加対応が必要な事項を日本語で簡潔に報告してください。

注意事項

- Node.js公式情報を一次情報として参照してください。
- 必要のないメジャーバージョンアップは行わないでください。
- 既存のアプリケーションや開発環境を壊さないことを優先してください。
- 本番環境へのデプロイやサービス再起動など、影響の大きい操作は事前に確認を取ってください。
- アクセスできない環境については、確認済みとせず、未確認として報告してください。

依頼文の肝は注意事項の側にあります。「同じメジャーの修正版」「壊さないことを優先」「影響の大きい操作は事前に確認」「アクセスできない環境は未確認と報告」の4つが、AIの作業範囲を決めています。

依頼文の6ステップに沿って、自社で実際に起きたこと

みやっち🧑‍💻は2026年10月21日、公式告知のURLを添えて「これ対応必要だったら対応してください」とCodexに頼みました。上の依頼文をDiscordへ配ったのは、その対応が済んだ同じ夜です。Codexが自社プロダクト「AIチャットつくーる」で実施した内容を、依頼文の6ステップに当てはめて書きます。

1. 公式告知を読む: 告知の本文と、修正版v24.22.1のリリース情報を確認。対象に24.x系が含まれ、DNS・TLS・BrotliのHIGHが入っていることを把握しました。
2. バージョンを調べる: プロジェクトのバージョン指定ファイル .nvmrc は24.22.0で、CI（自動テスト）がこのファイルを参照していることも確認しました。
3. 影響と優先順位を判断する: 24.22.0は影響を受ける版です。自社プロダクトでは、新しい版が出てから24時間は様子を見てから入れる運用にしていて、セキュリティ修正はその例外と決めてあります。HIGHを含む今回の修正版は待たずに入れました。
4. 同じメジャーの修正版へ更新する: .nvmrc を24.22.0から24.22.1へ変更。手元のMacではバージョン管理ツール（nvm）で公式バイナリを入れ、SHA256（ファイルが改ざんされていないか照合するハッシュ値）の一致を確認してから、既定の版を24.22.1にしました。npmは公式同梱の版を使い、依存ライブラリの一覧（manifest・lockfile）とアプリの実装は変えていません。
5. テスト・ビルド・動作確認: 24.22.1でテスト・lint・型検査・ビルドを実行。さらに今回の修正点に対応する確認として、DNSのNUL入力が拒否されること、非正規な表記（全角数字を含む）のIPアドレスを名乗るTLS証明書が拒否されること、Brotliの圧縮・展開、公式サイトへのHTTPS通信を確かめました。
6. 日本語で報告する: 実施した変更と、残っているリスク（本番の反映は未確認）を分けて報告。この「未確認」を未確認のまま書かせるのが、依頼文の最後の注意事項です。

ここまでで変えたのはNode.js本体の版まわりだけで、アプリの実装と依存ライブラリは触っていません。本番へのデプロイやサービスの再起動は事前に確認を取らせる設計で、承認の仕組みそのものはClaude Codeのpermissions設定にまとめています。

本番がVercelなら「自分で上げるもの」と「待つもの」を分ける

自社の4サイトはすべてVercelで動いています。Vercelの公式ドキュメント「Supported Node.js versions」には、利用者が選べるのはメジャーバージョンだけ（2026年10月時点で26.x・24.x・22.x）で、セキュリティ問題の修正などで必要なときはVercelがマイナー・パッチ更新を自動で配布する、と書かれています。

つまり手元の .nvmrc を24.22.1にしても、本番の関数が24.22.1で動くかどうかはVercel側の配布次第です。APIで取れる現行デプロイの設定値も「nodejs24.x」というメジャー指定までで、個々の関数がどの版で動いているかは別に確かめる必要がありました。

ここで気をつけたいのが、再デプロイが「Ready」になった、HTTPの応答が成功した、だけを「修正版が当たった」と読み替えないことです。翌日（10月22日）の記録では、関数の起動時にNodeの版を記録するよう自社で仕込んだログに出る版はまだ配布前のままで、「配布待ち」として起動ログを見る扱いにしました。公式ドキュメントにも、ビルドと関数の実行環境とで細かい版が違いうると書かれているので、関数側は process.version（起動ログ）で確かめます。本番の反映には自分で操作できない範囲があり、確認して待つのが正しい対応でした。

Vercelは公式の告知ページで、22.x・24.xの利用者はVercelがパッチの版を管理するためバージョン設定の変更は不要なこと、既存プロジェクトは再デプロイすると暫定的な保護（関数からの外向き通信でBrotli応答の処理を止める）が有効になること、10月28日午前11時（太平洋時間）以降の新規デプロイは修正版のNode.jsを使うことを案内しています。自社プロダクト（AIチャットつくーる）でも10月27日に、コードや設定は変えずに同じ内容を再デプロイして暫定保護の対象になるようにしました。そのうえで、修正版が当たったかどうかはReadyやHTTPの成功ではなく起動ログの版で確かめる、という扱いは変えていません。告知には、サポート終了の20.xは修正されないので22.xか24.xへ変えて再デプロイするように、とも書かれています。

Vercelの公式ドキュメントも、デプロイのNode.jsの版を確かめる方法として、ビルドコマンドで node -v を実行するか process.version をログに出す方法を案内しています。VercelとCloudflareのような置き場ごとの違いはVercelとCloudflareの違いに書きました。

WordPressのホームページを持っている人は何をするか

昔作ったホームページやブログを自社でWordPressで運用している場合、動いているのはNode.jsではなくPHPです。PHP公式は2026年10月21日に、2つの重大な脆弱性を修正する版（8.5.12・8.4.27・8.3.36・8.2.35）を公開し、すべての利用者に直ちに更新するよう呼びかけています。

制作会社やサーバー会社に管理を任せているなら、連絡が来ていることが多いので、その案内に沿って必ず対応してください。士業・一人社長で自分で管理しているなら、使っているPHPの版を確かめ、公式のリリース情報を一次情報にして更新します。みやっち🧑‍💻がDiscordで書いたのも「必ず対応してくださいね」の一言で、Node.jsと同じく「公式を読む→自分の版を確かめる→修正版へ」の順です。

なぜこの作業をClaude Code・Codexに任せるのか

対応の前後で、自作アプリのオーナーの状態はこう変わります。

• これまで: ニュースを見ても自分の環境が対象か分からず放置する。あるいは不安になって最新版へ上げ、別の不具合を出す
• 依頼文で任せると: AIが公式ページを読み、3か所の版を調べ、同じメジャーの修正版で止め、テストまで回し、確認できなかった環境は「未確認」と報告してくる。自分がやるのは、報告を読んで本番への操作を承認するかどうかの判断（自社の対応も、公式URLを添えた一行の依頼からこの順で進みました）

この作業は「公式ページの読解」「複数環境の調査」「更新」「テスト」「報告」が1つながりで、どれも手順は決まっているのに、手でやると順番を飛ばしやすい。Claude Code・Codexは自分のPCで動き、ファイルを読み、コマンドを実行し、その結果を読んで次へ進むので、この1つながりの作業を依頼文1つで通せます。

チャット画面だけのAIに同じ依頼文を貼っても、返ってくるのは一般論までで、自分のPCの版の調査・更新・テストは自分の手で打つことになります。ただし条件があります。①依頼文に「同じメジャー」「壊さない」「影響の大きい操作は確認」を書くこと、②報告の「未確認」をそのままにせず、自分で確かめるか待つかを決めること、の2つです。

そして、ここまでの手順はみやっち🧑‍💻の自社環境での記録であって、「これだけやれば大丈夫」という閉じた手順ではありません。本番のホスティング契約、社内の運用ルール、扱うデータの重さによって、「配布を待つ」でよいのか「止めてでも先に上げる」なのかは変わります。判断に迷う箇所は、開発会社や情報システム担当、セキュリティの専門家に相談してください。

公開前のデータベース設定はSupabaseのセキュリティ設定、Claude Code自体の安全性はClaude Codeのセキュリティ、そもそもどの技術で作るかは個人開発の技術選定で扱っています。

よくある質問

Node.jsのバージョンはどこで確認しますか

手元のPCはターミナルで node -v を実行します。みやっち🧑‍💻のMacでは2026年10月31日時点で v24.22.1 と表示されます。ただし、それはPCの版であって、プロジェクトの .nvmrc や package.json の engines、本番環境の版は別に確かめます。Vercelならビルドコマンドで node -v を実行するか、process.version をログに出す方法が公式ドキュメントに載っています。

いっそ最新のNode.js 26に上げたほうがいいですか

修正版が同じメジャーに出ているなら、同じメジャーの修正版を選びます。メジャーを上げるのは互換性の確認が要る別の作業で、脆弱性の対応と一緒にやると、不具合が出たときにどちらが原因か分からなくなります。Node.js公式のリリース一覧では、本番アプリはActive LTSかMaintenance LTSだけを使うべきとされ、2026年10月末時点で26.x・24.x・22.xがいずれもLTS、18.xや20.xがサポート終了（EOL）です。EOLの系列は、公式告知にあるとおりセキュリティリリースのたびに常に影響を受けます。サポートが終わっているので修正版も出ません（Vercelの告知も、20.xは修正されないとしています）。その場合だけメジャーアップが必要で、互換性のテストも合わせて計画します。

npm auditは何をするコマンドですか

npm公式によると、npm audit はプロジェクトの依存ライブラリの情報をレジストリに送り、既知の脆弱性の報告を受け取るコマンドです。Node.js本体の脆弱性とは別の層で、アプリが使っているライブラリ側を調べます。npm audit fix は修正を適用しますが、メジャーバージョンが変わる修正には --force が要り、公式はその意味が分からないなら使わないよう強く勧めています。

更新したのに node -v が古い版を表示します

すでに起動しているターミナルやClaude Code・Codexは、動き始めたときのNodeを使い続けるので、既定の版を変えても遡って効きません。ターミナルを開き直す、Claude Code・Codexを起動し直す、で新しい既定が取り込まれます。それでも古いままなら、プロジェクトの .nvmrc が別の版を指していないか確かめます。

自作アプリは、公開した日からこうした更新と付き合うことになります。この依頼文も、講座のDiscordで受講生に配ったものです。講座では、Claude Code・Codexにアプリを作らせるところだけでなく、GitHubをコードの正本にしてVercelで公開する本番運用の構成まで扱っています。公開後の更新も、同じように依頼文で任せられます。まず無料セミナーでお会いしましょう。