postcss-selector-parser

Dependabot の通知を、32リポジトリぶん追えなくなった。AIと作った「依存の見回り TL;DR 個人で32リポジトリを持っている。棚卸ししたら、15リポジトリに high 以上の Dependabot アラートが合計345件あった（アラートは脆弱性ごと・ファイルごとに1件なので、パッケージの数よりずっと多い）。Dependabot は入っていた。通知も来ていた。追いきれていなかった 足りなかったのは通知ではなく、「全リポジトリを横断した一覧」と「どれから直すかの順番」だった clone せずに API だけで全リポジトリを週1回見回り、P1〜P3 の順位をつけて、P1 があるときだけ知らせる仕組みにした。件数を数える部分は32リポジトリで約50秒 AI にコードを書かせるときは、版を AI の記憶から書かせない。入れる直前に最新を確かめる そして、この記事を書いている途中で、自分がその罠を踏んだ。記憶の経験則（「Node の奇数の版は短命」）で決めた設定が、もう古かった Dependabot のメジャー更新の PR より小さい直し方があったこと、件数を数えるスクリプト、優先度の決め方、踏んだ落とし穴5つを置いておく。 プレビューが落ちた。原因は tailwind 4 だった 10月24日、Vercel から「プレビューのビルドに失敗」と通知が来た。半年以上触っていない個人アプリのリポジトリだ。 コードは何も変えていない。来ていたのは、Dependabot の PR だった。tailwindcss を 3 から 4 に上げる PR で、そのプレビューが落ちていた。 原因はすぐわかった。postcss.config.js が tailwindcss: {} を直接読んでいる。v4 では PostCSS のプラグインが @tailwindcss/postcss という別のパッケージになった（Tailwind CSS の移行ガイド）。 わからなかったのは、なぜメジャー更新の PR が来たのかだ。版の更新の設定（dependabot.yml）は入れていない。このリポジトリで動いているのは、脆弱性を直すための「セキュリティアップデート」だけのはずだった。 調べたら、こういうことだった。 postcss-selector-parser に脆弱性が公表された（GHSA-rj75-hqrm-r3gf、2026年10月5日、深刻度は moderate）。アドバイザリの記録では、対象は < 7.1.6、修正版は 7.1.6 tailwind 3 は postcss-selector-parser の 6 系（^6.1.2）を指定している だから Dependabot は「tailwind ごと 4 に上げる」PR を出した セキュリティアップデートでも、メジャー更新の PR は来る。 中の部品を直すために、外側のパッケージが丸ごと上がることがある。マージする前に気づけたのは、プレビューが落ちてくれたからだ。 しかも、続きがあった。postcss-selector-parser のリリースを見ると、10月19日に 6.1.5 が出ていて、同じ脆弱性の修正が 6 系にもバックポートされていた。6.1.5 は tailwind 3 の指定範囲に入る。つまり、tailwind を 3 のまま直せた。アドバイザリの記録がまだ 6.1.5 を修正版として載せていないので、Dependabot は大きいほうの直し方を出してきた、ということだ。 Dependabot が出した直し方が、いちばん小さい直し方とは限らない。 メジャー更新の PR が来たら、上げる前に、その部品のリリースノートでバックポートが出ていないかを見る。 ここで嫌な予感がした。半年触っていないリポジトリでこれなら、ほかはどうなっているのか。 棚卸ししたら、345件あった Claude Code に、自分の GitHub の全リポジトリを棚卸ししてもらった（数字は2026年10月24日時点）。アーカイブとフォークを除いて32個。 見たもの 結果 high 以上の Dependabot アラートがあるリポジトリ 15個（合計345件） 開きっぱなしの Dependabot の PR 53本 サポートが終わったランタイムに上げようとしている PR 4本 台帳に載っていない（存在を忘れていた）リポジトリ 5個 345件は「直すべきパッケージの数」ではない。Dependabot のアラートは、脆弱性ごと・ファイルごとに1件になる。1つのパッケージだけで、アラートが30件以上あったこともある。それでも、多いことには変わりない。 Dependabot は入っていた。アラートのメールも来ていた。でも、リポジトリごとにバラバラに届くので、「どれが本番で、どれが危ないか」を毎回頭の中で組み立てないといけない。32個になると、それはもうやらない。 通知が来ていることと、見ていることは違う。 最後の行も地味に効いた。台帳から漏れていたリポジトリは、見回りの対象からも漏れる。その中には、本番で動いているアプリも含まれていた。 clone しないで、全リポジトリを見回る やりたいことはシンプルにした。 全リポジトリについて「使っているパッケージ」「脆弱性」「ランタイム」「止まっている PR」を1つのファイルにまとめる 優先度をつけて、上から順に直せるようにする 週1回、自動で回して、P1 があるときだけ通知する 読む先は API だけ（clone しない） 最初は全リポジトリを clone して npm audit を回していた。32個 clone して、npm ci して……は重い。 GitHub には、clone しなくても読める情報がそろっている。 知りたいこと 読む先 脆弱性（深刻度・直接か間接か・実行時か開発用か・直る版） Dependabot alerts の REST API 実際に入っている版（lockfile から GitHub が作ったもの） SBOM の REST API 止まっている PR gh pr list --app dependabot 最新版 npm / PyPI の公開 API ランタイム Dockerfile の FROM と .nvmrc（contents API で読む） GitHub 以外に読むのは、最新版（npm / PyPI）とランタイムのサポート予定（endoflife.date）の公開 API だけだ。 まず、自分にどれだけ溜まっているかを見る 件数を数えるだけなら、これで足りる。 deps-alerts.sh #!/bin/bash 使い方: deps-alerts.sh <owner> リポジトリ（アーカイブ・フォークを除く）ごとに、 開いている Dependabot アラートの critical / high の件数と、Dependabot の PR の本数を出す。clone はしない 読めなかったリポジトリ（権限がない・Dependabot alerts が無効など）は 0 ではなく「?」と出す 要るもの: gh（gh auth login 済み）・jq。確認した環境: bash 3.2 / gh 2.103 / jq 1.7 set -uo pipefail owner="${1:?owner を渡す}" printf '%-36s %8s %5s %4s\n' repo critical high PR for repo in $(gh repo list "$owner" --limit 200 --no-archived --source --json name --jq '.[].name'); do if sev=$(gh api --paginate "repos/$owner/$repo/dependabot/alerts?state=open&per_page=100" \ --jq '.[].security_advisory.severity' 2>/dev/null); then crit=$(grep -c '^critical$' <<< "$sev"); high=$(grep -c '^high$' <<< "$sev") else crit='?'; high='?' fi prs=$(gh pr list -R "$owner/$repo" --app dependabot --state open --json number --jq length 2>/dev/null || echo '?') printf '%-36s %8s %5s %4s\n' "$repo" "$crit" "$high" "$prs" done | sort -k2,2nr -k3,3nr 動かし方： chmod +x deps-alerts.sh ./deps-alerts.sh <自分のユーザー名か org 名> 出力はこうなる（名前は伏せた）。critical が多い順に並ぶ。自分の32リポジトリでは、約50秒かかった（2026-10-24〜25 に計測）。 repo critical high PR repo-a 7 41 3 repo-b 3 20 5 repo-c 0 1 1 repo-d 0 0 0 注意が3つある。 「?」は「読めなかった」で、0件ではない。権限が足りない（管理者でない org など）か、Dependabot alerts が無効になっている。リポジトリの Settings → Advanced Security（Code security）で Dependabot alerts を有効にする 最初のバージョンは、読めなかったリポジトリを 2>/dev/null で捨てていて、0件と表示していた。セキュリティの道具で「読めなかった」を「きれい」に見せるのが、いちばん危ない 修正をマージしても、アラートが閉じるのは GitHub が数え直してから。直後に数えると、件数は変わっていないことがある 優先度は「本番で、実行時に使うか」で決める 件数だけ並べても、345件は直せない。順番が要る。 優先度 当てはまるもの いつまでに P1 critical の脆弱性／本番のあるリポジトリで、実行時に使うパッケージの high／本番のあるリポジトリで、サポートが終わったランタイム 見つけた週のうちに PR P2 開発用だけ・本番のないリポジトリの high／本番のあるリポジトリで、LTS でない Node 次にそのリポジトリを触るとき P3 moderate／メジャー版の遅れ／サポート終了まで90日以内のランタイム／14日以上止まっている Dependabot の PR 月1回まとめて 「実行時か開発用か」は、アラートの dependency.scope に runtime / development で入っている。値が入っていない（null）こともあるので、そのときは実行時として扱う（甘いほうに倒さない）。 「本番があるか」は API ではわからない。自分のリポジトリの台帳（どれが本番で、どこにデプロイしているか）を Markdown の表で持っていて、そこから読んでいる。台帳が見回りの対象を決めるので、台帳に載っていないリポジトリも一覧の上に出すようにした。 | repo | 役割 | 本番 | |------|------|------| | my-app | 家計のアプリ | Cloud Run | | my-tool | 手元の道具 | — | 週1回、P1 があるときだけ知らせる 自分の環境では、毎週日曜の朝に Mac mini の定期実行（LaunchAgent）で回し、結果を Markdown に書き出している。cron でも GitHub Actions の schedule でも同じことができる。 通知（自分は ntfy でスマホへ）は P1 があるときだけ。P2・P3 だけの週は送らない。毎週「P3 が40件あります」と来たら、3週目には見なくなる。それでは Dependabot のメールと同じだ。 通知にはこう出す。 依存の更新: P1 が 6 リポジトリ （リポジトリ名）：（パッケージ名）（直接）の脆弱性 critical ×N → X.Y.Z 以上に上げる（全部直る版） ... 一覧: ~/.local/state/.../inventory.md 「何が・何件・どうすればいいか」まで書く。自分の場合、最後は Claude Code に「依存の P1 を直して」と頼むだけになっている。 作るときに、古いものを入れない 見回りは「入ってしまった古いもの」を見つける仕組みだ。もう一つ、入口も閉じた。 AI にアプリを作らせると、AI が覚えている版で package.json を書くことがある。学習した時点では最新でも、書いている今は古い。古いリポジトリの package.json を参考にさせても同じことが起きる。 新しいリポジトリを作るときの雛形に、こう書いた。 版は記憶や古いリポジトリから写さない。入れる直前に最新の安定版を確かめる（npm view <名前> version、公式ドキュメント） 雛形（create-next-app など）は @latest で作る Node は LTS の版を使う。どれが LTS かは、記憶で決めず Node.js のリリース予定で確かめる lockfile をコミットし、npm ci で入れる .github/dependabot.yml を最初から入れる 最初の PR で npm audit --audit-level=high が 0 件 Node の行は、最初はこう書いていた。「偶数の版を使う。奇数の版は短命なので使わない」。これが間違いだった話は、落とし穴の最後に書く。 全部は直さない、と先に決めた 345件を直すにあたって、ルールを決めた。 セキュリティ修正（P1・P2）が先。マイナー・パッチの更新はまとめて1本。メジャー更新は1パッケージ1本で、公式の移行ガイドを読んでから 各 PR で install → lint → typecheck → test → build を全部通す。Vercel などのプレビューも通す 見た目が変わっていないことを機械で確かめる。main とブランチのビルドを並べて、主要画面を 1280px と 320px で撮り、ピクセル単位で比べる 置き換えた Dependabot の PR は、新しい PR にリンクしてから閉じる 半年以上触っていないリポジトリは、脆弱性の修正だけ。ふだんのメジャー更新はしない。ただし、脆弱性を直すのにメジャー更新が要るなら、それは上げる。上げられないなら公開を止める ビルドが通らない更新は無理に直さない。原因と選択肢を書いて止まる 3 は思ったより効いた。依存を上げると、JS のファイル名（ハッシュ）は全部変わる。差分を目で見ても「変わった」としか言えない。スクショのピクセルが一致すれば、少なくともその画面は変わっていないと言える。 ひとつ引っかかったのは、アニメーションのあるページだ。そのままだと main 同士で撮っても一致しない。アニメーションを止めてから撮り、「止めた状態なら main 同士は一致する」ことを先に確かめてから比べた。 5 は、全部を最新にしようとすると終わらないからだ。半年触っていないアプリを React 19 と tailwind 4 と vite 8 に上げる作業は、ほぼ作り直しになる。公開しているなら脆弱性だけは直す。それ以上は、そのアプリをまた触るときにやる。 この線引きで、Claude Code に8リポジトリぶんの PR を並行で作ってもらい、自分が見てマージした。 踏んだ落とし穴5つ 1. 「直る版」は、いちばん新しい修正版を見る あるライブラリについて、最初の棚卸しで「次のマイナー版に上げれば直る（メジャー更新はいらない）」と判断した。Dependabot は次のメジャー版への PR を出していたので、「メジャーを避けられる」と思った。 間違いだった。 アラートを1件ずつ見ると、同じライブラリに、修正版の違うアラートが混ざっていた。 アラート 直る版 一部 次のマイナー版 残りの大半 次のメジャー版 マイナー版で直るのは一部だけ。同じパッケージに複数のアラートがあるとき、全部直るのは「各アラートの直る版のうち、いちばん新しいもの」。見回りの一覧では「○○ 以上に上げる（全部直る版）」と、この値を出すようにした。 2. dependabot.yml の ignore は、セキュリティ修正の PR にも効く 「当面メジャー更新しないもの」を Dependabot に伝えるのは ignore だ。ただ、GitHub の設定リファレンスでは、ignore はセキュリティアップデートの PR にも影響する設定として印がついている。 雑にパッケージを丸ごと ignore すると、そのパッケージに脆弱性が出たときの修正 PR まで止まる。だから範囲を絞る。 version: 2 updates: - package-ecosystem: docker directory: / schedule: interval: weekly Node 25 までの奇数の版（23・25）は LTS にならないので上げない 出典: nodejs/Release%EF%BC%882026-10-25 確認） 見直す日: 2027-10-20 ignore: - dependency-name: node versions: [">= 23, < 24", ">= 25, < 26"] それでも、脆弱性のアラートは ignore と関係なく届く。止まるのは PR だけだ。見回りはアラートを読むので、ignore したパッケージに脆弱性が出ても P1 には上がってくる。 ignore には必ず「理由」「出典」「見直す日」を書く。書かないと、半年後に誰も外さない。 3. ほかの部品が「その版ちょうど」を指定していることがある あるリポジトリで、テスト用の部品（miniflare）が alpha 版に固定されていて、その中の部品（undici・sharp）に high の脆弱性があった。npm audit の提案は「miniflare を安定版の 4 系にする」。alpha の 5 系から見ると、版を戻すことになる。 調べると、Cloudflare の wrangler（使っていた 4.135.0）が、その alpha 版をちょうど指定していた。miniflare を動かすと wrangler と食い違う。 こういうときは外側を動かさず、package.json の overrides で中の部品だけを直る版に寄せた。 "overrides": { "undici": "7.30.1", "sharp": "0.35.5" } undici は同じ 7 系のマイナー、sharp は 0.35 系のパッチなので、ビルドとテストが全部通ることを確かめて入れた。overrides は便利だが、外し忘れると今度はそれが古くなる。PR に理由を書いておく。 4. 使っていない依存は、上げるより消す 半年触っていないアプリに、@vercel/node が開発用の依存として入っていた。中の部品に high があり、直すにはメジャー更新が要る。 コードを探したら、どこからも使われていなかった。api/ フォルダも vercel.json もない。上げるのをやめて、消した。 いちばん安全な依存は、入っていない依存だ。 5. 経験則も古くなる：Node 27 は奇数でも LTS になる Dependabot が、Docker のベースイメージを node:22-alpine から node:25-alpine に上げる PR を4本出していた。Node 25 は奇数の版で、LTS にならず、2026年6月1日にサポートが終わっている。上げる理由はない。 ここまではよかった。そこで自分（と Claude Code）は、「Node の奇数の版は短命」という覚え方のまま、23・25・27 を ignore する設定を4リポジトリに入れ、規約にも「奇数の版は使わない」と書いた。 翌日、この記事の事実確認を別の AI にやらせたら、指摘が来た。Node.js のリリース予定では、v27 からすべての版が Alpha → Current → LTS になる。27 が LTS になる予定日は 2027年10月20日。奇数が LTS にならないのは 25 までの話で、27 を ignore すると、将来の LTS への更新を止めてしまうところだった。 同じ日に、Python 3.10 のサポート終了日も1か月ずれていたのが見つかった（正しくは 2026年10月1日）。 AI が古くなるのは、版の数字だけではない。「いつもこう」という方針の覚え方も古くなる。 直したのは3つだ。 ランタイムのサポート予定を手書きの表で持つのをやめ、見回りのたびに endoflife.date の API から取る ignore には「理由・出典・確認日・見直す日」を必須にし、抜けや期限切れを一覧に出す 版や ignore の方針を決める PR は、実装した AI とは別の AI に一次ソースと照合させてからマージする 最後のものが、今回いちばん効いた。自分で決めたことを自分で確かめても、同じ記憶で確かめるだけだった。 結果 8リポジトリに、脆弱性の修正の PR を出してマージした。npm audit の high 以上は、この8リポジトリで計97件 → 4件。残った4件は、直すのにメジャー更新が要るもの（冒頭の345件は Dependabot アラートの件数で、数え方が違うので並べて比べない） Node 25 への PR は4本とも閉じ、ignore を「23・25 だけ」に直して入れた 台帳から漏れていた5リポジトリを台帳に戻し、見回りの対象にした 本番で動いていて、直すのにメジャー更新が要る critical が1つ残っていた。Next.js 14 の画像最適化 API で、認証なしでコードを実行される脆弱性だ（14 系には修正版がない）。「手間が大きい」と後回しにしていたのを、この記事の公開前チェック（攻撃者の目で読ませる係）に指摘された。Next.js 15 に上げてデプロイしてから、この記事を出している ほかのメジャー更新が要るものは、1パッケージ1本で、移行ガイドを読みながら進める 全部が片付いたわけではない。ただ、どこに何が残っているかを、毎週わかる仕組みにした。 自分の現場に持ち帰るなら 上のスクリプトで、自分のリポジトリにどれだけ溜まっているかを見る。「?」が出たら、まずそこを読めるようにする 件数の多い順ではなく、「本番で、実行時に使うもの」から直す 版・サポート期間・ignore は、記憶ではなく一次ソースで決める。決めた PR は、別の目（人でも AI でも）に照合させる Dependabot は便利だ。でも、Dependabot が教えてくれるのは「このリポジトリに何があるか」までで、「32個の中でどれから直すか」は教えてくれない。そこを決めるのは、自分の台帳だった。 nekoai-lab.github.io