pnpm v11のminimumReleaseAgeでDependabotのCIが落ちる ─ 原因・回避策・upstream状況まとめ

はじめに

pnpm v11にアップグレードしたプロジェクトで、Dependabotが作成したPRのCIが突然失敗するようになりました。

[ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION] 1 lockfile entries failed verification:
  caniuse-lite@1.0.30001802 was published at 2026-07-06T04:58:52.000Z,
  within the minimumReleaseAge cutoff (2026-07-05T09:23:26.106Z)

直接依存しているパッケージではなく、推移的依存（transitive dependency） の caniuse-lite が「公開されて間もない」と判定されてインストールが拒否されています。

これはpnpm v11で導入されたサプライチェーン保護機能 minimumReleaseAge が原因です。本記事では、なぜこれが起きるのか、どんな回避策があるのか、そしてupstreamでの議論状況を調べてみました。

前提・環境

• pnpm: v11（minimumReleaseAge デフォルト有効）
• CI: GitHub Actions（pnpm install --frozen-lockfile）
• 依存管理: Dependabot（version updates）
• 問題のパッケージ: caniuse-lite（browserslist 経由の推移的依存、ほぼ毎日新バージョンが公開される）

minimumReleaseAgeとは

pnpm v11で導入されたサプライチェーン攻撃の緩和機能です。公開から一定時間が経過していないパッケージのインストールを拒否します。

• デフォルト値: 1440分（24時間）
• 目的: 悪意あるパッケージは公開後数時間以内に検知・削除されることが多いため、「冷却期間」を設けることで被害を防ぐ
• 設定場所: pnpm-workspace.yaml（pnpm v11では .npmrc のpnpm固有設定は読み込まれない）

# デフォルトは1440（分）。0で無効化
minimumReleaseAge: 1440

なぜDependabotで問題になるのか

発生の流れ

1. Dependabotが直接依存パッケージの新バージョンを検知し、PRを作成
2. PR作成時に pnpm install でlockfileを再生成 → 推移的依存が最新版に解決される
3. たまたまその時点で caniuse-lite の最新版が数時間前に公開されたばかり
4. 生成されたlockfileには「公開されたばかり」のバージョンが記録される
5. CIで pnpm install --frozen-lockfile → lockfile検証 → ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION

根本的な設計上の問題

ここが核心です。pnpmの minimumReleaseAge は verify-after-resolve（解決後に検証） の設計になっています。

つまり、リゾルバが「新しすぎる」と判定したバージョンの代わりに、条件を満たす古いバージョンにフォールバックしないのが問題です。

--frozen-lockfile のもう一つの罠

--frozen-lockfile はlockfileの内容を検証するだけで、再解決は行いません。Dependabotのランナー環境で生成されたlockfileに新しすぎるバージョンが含まれていれば、CI側では何もできません。フォールバックの余地がそもそもない検証専用のコードパスです。

回避策の比較

1. minimumReleaseAgeExclude（最も実用的）

pnpm-workspace.yaml で特定パッケージをポリシーから除外します。

minimumReleaseAgeExclude:
  - caniuse-lite

caniuse-lite はほぼ毎日更新され、Can I Use のデータベースなのでサプライチェーン攻撃のリスクは低いです。ピンポイントで除外するのが現実的な落としどころです。

ただし根本解決ではありません。 今日は caniuse-lite で踏みましたが、明日は別の高頻度更新パッケージで同じことが起きる可能性があります。

2. Dependabot cooldown 設定

updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "weekly"
    cooldown:
      default-days: 3
      semver-patch-days: 2

Dependabotが新バージョン検知後、一定期間待ってからPRを作成します。ただし、これは直接依存のPR作成タイミングを遅らせるだけです。PR作成時の pnpm install で推移的依存が最新版に解決される問題は解決しません。

3. pnpm-exclude-newer

pnpm-exclude-newer は、ローカルにレジストリミラーを立ち上げ、カットオフ日以降に公開されたバージョンを隠した状態でlockfileを生成するツールです。uvの --exclude-newer に相当する機能をpnpmに提供します。

pnpm dlx pnpm-exclude-newer

推移的依存を含むすべての依存で年齢制限が効く唯一のツールですが、Dependabotはカスタムの install コマンドを実行できないため、Dependabotのワークフローに組み込むのは実質的に不可能です。

4. 待って再実行

minimumReleaseAge のデフォルトは24時間ですが、Dependabotがlockfileを生成した直後にパッケージが公開された場合、CIが実行されるまでのタイムラグ（PR作成待ち、キュー待ち等）を加味すると、公開から最大48時間程度待つ必要があるケースもあります。時間が経てば自然に通ります。

upstreamの状況

関連Issue

修正されたもの vs 未修正のもの

#10100（メジャーバージョン跨ぎ）は v10.20.0 で修正されました。例えば lodash@5.0.0 が新しすぎる場合に lodash@4.17.21 にフォールバックする動作です。

しかし #11203（同一レンジ内）は未修正です。lodash@4.18.1 が新しすぎる場合、同じレンジ内の lodash@4.18.0 にフォールバックすべきですが、現状はより古い lodash@4.17.23 に戻ってしまいます。#10100の修正の自然な拡張として対応できるはずですが、まだ誰もPRを出していません。

PRを出す価値はあるか

リゾルバの修正（同一レンジ内フォールバック）は #10100 の既存修正を参考にでき、変更範囲も限定的です。ただし --frozen-lockfile の検証パスは別のコードパスなので、こちらの対応は別途検討が必要です。

Issueにコメントして、メンテナーの方針を確認してからPRに着手するのが良さそうです。

まとめ

• pnpm v11の minimumReleaseAge は重要なサプライチェーン保護機能だが、推移的依存のフォールバックが未実装という設計上の穴がある
• Dependabotとの組み合わせで、ユーザーが制御できない推移的依存（caniuse-lite など）が原因でCIがランダムに失敗する
• 当面の回避策は minimumReleaseAgeExclude で高頻度更新パッケージを除外するのが最も実用的
• 根本解決はpnpm側でリゾルバのフォールバック実装が必要（#11203）
• 同様の問題に遭遇した方は、Issueに 👍 やコメントを追加してupstreamでの優先度向上に貢献できます

参考リンク

• pnpm Settings — minimumReleaseAge
• pnpm 11.0 リリースノート
• pnpm-exclude-newer
• Dependabot cooldown設定
• Configuring minimum release age across npm, pnpm, and yarn