Next.jsの脆弱性に5週間気づかなかった｜コードを書かない私がAIの点検で見つけ、更新で塞いだ記録

結論: 公開したサイトの脆弱性は、頼まないかぎり誰も拾わない

先に結論から。
このサイト（AI道具箱）はNext.jsという部品で作っていて、そのバージョン16.2.4が、深刻度critical（最も高い区分）の脆弱性2件の対象だった。
1件目が公表されたのは2026年8月25日。
私が気づいたのは10月1日の夜で、約5週間、対象のバージョンのまま公開していたことになる。

見つけたのは、AIにサイト全体を点検させたときだ。その夜のうちに16.3.8へ更新し、本番で表示を確かめた。
更新のコミットの時刻は20時49分。サイトの設定まわりの直し6件のうちの3件目だった。

私はコードを書かない。このサイトもAIに作らせている。
だからこそ書き残しておきたいのは、AIで作ったサイトでも、公開したあとの脆弱性は自分から点検を頼まないかぎり誰も拾わない、ということだ。
以下、対象だった2件、気づいた経緯、更新の中身、残したものの順に書く。

対象だった2件（2026年10月9日にGitHubで確認）

どちらも、GitHubのセキュリティアドバイザリ（脆弱性の公式の告知）に載っている。2026年10月2日と、この記事を出す10月9日に、対象バージョンと修正版を見直した。

16.2.4は、どちらの範囲にも入っている。このバージョンは、2026年6月26日にサイトの土台を作ったときから一度も変えていなかった。

自分のサイトの使い方も照らし合わせた。
画像最適化の機能（next/image）は、記事のページやカードなど4か所で使っていた。
一方、2件目の next/og は、コードのどこにも使っていなかった。
ただ、どちらにしても対象のバージョンで動いていたことは変わらない。実際に外から狙えたのかどうかは、私には判断できない。
だから「使っていなかったから大丈夫」とは書かないでおく。

気づいた経緯——AIに「サイト全体の点検」を頼んだ夜

10月1日、このサイトをAI（Claude Code）に全面的に点検させた。
本文の事実、内部リンク、SEOの技術面、表示の速さ、読み上げへの配慮、コードなど11の観点に分けて、複数のAIに並行して調べさせ、出てきた指摘をまとめると改善の候補は88件。
そのうち72件を採用した。Next.jsの更新は、その中の1件だった。

AIが挙げた脆弱性を、そのまま信じて更新したわけではない。AIはそれらしいIDや対象範囲を書いてしまうことがある。
そこで、更新の前に2つのIDがGitHubのアドバイザリに実在するか、対象の範囲が合っているかを確かめさせ、結果をコミットのメッセージに残した。
上の表の数字は、そのとき残した記録と、翌日と10月9日に開き直した公式の記載が一致したものだ。

更新の中身——Next.jsだけでは済まなかった

更新は、当時同じ16の中で最新だった16.3.8にとどめた。
メジャーバージョンを上げると、書き方の変更に付き合う必要が出やすいからだ。
ところが、Next.jsだけを上げて終わり、とはいかなかった。

このサイトは、Next.jsで作ったものをCloudflareの上で動かしている。
その橋渡し役の部品も最新にそろえると、今度はそれがCloudflareの道具（wrangler）の新しい版を求め、wranglerがさらに型定義の新しい版を求める、という連鎖で、結局5つを上げることになった。
最後の型定義は、古いままだと npm がインストールの途中で止まったので上げている。
こういう連鎖は、AIが1つずつほどいて報告してくれた。

更新のあとに通した確認は次のとおり。

• 記事の一覧の生成、型チェック、lint、本番用のビルドが通る
• Cloudflare向けのビルドが手元で通る
• 更新を1つのコミットにまとめ、ほかの直しとは分けて公開する（問題が出たら、そのコミットだけ戻せるように）
• 公開後、本番の表示を確かめる

数で見る前後——critical 1・high 11 から critical 0・high 3

サイトを動かすのに使う部品（開発用を除いた分）について、npm audit の結果を更新の前後で比べた。

critical の1件がNext.jsだ。更新でNext.jsは一覧から消え、highも11件から3件に減った。
更新前のmoderateは記録に残していないので「—」にしてある。10月3日の行は、次の節に書く。

残したもの——その夜に直さなかったこと

更新のあとも、highが3件、moderateが1件残った。
どれもNext.jsではなく、ほかの道具の中で間接的に使われている部品（ファイル名の展開、フォームの送信、YAMLの読み込みなど）だ。
どこで使われていて、このサイトの公開中の動作に関わるのかを確かめてから直す、として、その夜は手を付けなかった。

この4件は、2日後の10月3日に片づけた。
サイトの部品の一覧（package.json）は変えず、部品の版を固定しておくファイル（package-lock.json）の5項目だけを新しい版にした。
AIの確かめでは、どれもビルドやデプロイのときに使う部品で、公開中のサイトの動作には載らないものだった。
直したあとの npm audit（開発用を除いた分）は0件になった。

もう1つ、もっと大きな宿題がある。脆弱性の知らせを、自分から探しに行かなくても受け取れる仕組みだ。
今回は点検を頼んだから見つかったが、頼まなければ今も16.2.4のままだったはずだ。
公表から約5週間という数字は、その仕組みが無いことの結果だと受け止めている。この仕組みは、まだ入れていない。

ついでに直したこと

同じ夜、Next.jsの更新の前後で、サイトの設定まわりの直しを公開した。
下の表の①〜④は1件ずつ、残り2件はまとめて公開した。
脆弱性とは別の理由で入れたものだが、守りに関わるものもあるので並べておく。

20時36分の画像の変更は、配信の流れを単純にするのが目的で、脆弱性への対策として入れたものではない。ただ結果として、このサイトは画像最適化の機能を使わなくなった。

まとめ: AIで作っても、公開後の点検は自分で頼む

AIに作らせたサイトでも、公開したあとに出た脆弱性は、自分から点検を頼まないかぎり残り続ける。
このサイトのNext.js 16.2.4は、critical の脆弱性2件の対象のまま、1件目の公表から約5週間動いていた。
AIにサイト全体を点検させて気づき、同じ16の中の16.3.8へ更新して塞いだ。
npm audit はcritical 1・high 11からcritical 0・high 3になった。

更新そのものより、学んだのは2つだ。AIが挙げた脆弱性は、IDと対象範囲を公式で照合してから動くこと。
そして、知らせを受け取る仕組みが無いかぎり、気づくのは次に点検を頼んだときになること。
後者は、まだ私の宿題として残っている。

このサイトをAIだけで作ってきた過程はバイブコーディングの始め方に、作業を任せているClaude CodeについてはClaude Codeのレビューに書いている。