npm staged publishing GA｜2FA承認フローと --allow-remote 追加で CI/CD をどう見直すか

先に結論

npm の今回の更新で大きいのは、publish と install の両方に人間の確認点を増やせるようになったことです。

判断を急ぐなら、順番はこうです。

1. CI の publish job を stage queue へ送れるか確認する
2. trusted publisher の allowed actions が publish-only のままか見る
3. install job で remote tarball や local path をどこまで禁止できるか試す

つまり、npm publish をそのまま安全にする話ではありません。

npm stage publish でいったん止める運用 と、--allow-remote などで依存取得経路を絞る運用 をセットで考える更新です。

何が変わったのか

GitHub Changelog で 2026-05-22 に案内された更新は2本です。

1つ目は、staged publishing の一般提供 です。

npm CLI 11.15.0 以降では、npm publish の代わりに npm stage publish を使えます。ここで package はすぐ公開されず、stage queue に送られます。最後は maintainer が CLI か npmjs.com で確認し、2FA 付きで approve してから registry に出ます。

2つ目は、install source を制御する allowlist の拡張 です。

既存の --allow-git に加えて、次の3つが入りました。

• --allow-file
• --allow-remote
• --allow-directory

これで npm install は、registry 以外の取得経路を source ごとに止めやすくなります。

staged publishing は誰に効くか

一番相性がいいのは、CI から npm publish しているが、最後の人間確認は残したいチーム です。

たとえば GitHub Actions の tag publish をそのまま本番公開に直結させると、workflow が通った瞬間に package が出ます。そこへ staged publishing を入れると、CI は build、test、署名、provenance 生成まで進めつつ、公開だけは別の確認点で止める ことができます。

この変更が効くのは、ミス防止だけではありません。

npm の説明では、staged publishing は non-interactive CI/CD や OIDC trusted publishing で始まる publish にも、proof of presence を入れ直す ための仕組みです。つまり、OIDC にして token を減らしたあとでも、最後の release 判断は人間が持てます。

先に知っておくべき前提

staged publishing は便利ですが、何でもそのまま置き換えられるわけではありません。

まず、npm CLI 11.15.0 以上 が必要です。npm docs では、Node 22.14.0 以上 も前提です。

次に、2FA が有効な npm account が必要です。stage する段階では 2FA 不要ですが、approve のときに必要になります。

もう1つ重要なのが、すでに registry に存在する package だけが対象 だという点です。brand-new package の初回公開には使えません。

つまり、社内 package 全部を一括で npm stage publish へ置き換える前に、

• npm と Node の更新条件
• 既存 package か初回公開か
• maintainer の 2FA 運用

を先に分けておく必要があります。

trusted publishing との関係で何を見直すべきか

今回いちばん見落としやすいのは、trusted publisher の allowed actions です。

npm docs では、trusted publisher を設定するときに、workflow ごとに npm publish、npm stage publish、または両方 を許可できます。

ここで大事なのは、既存設定は自動で stage-only へ変わらない ことです。

docs では、2026-05-20 より前に作られた trusted publisher 設定は npm publish only のままだと案内されています。つまり、すでに OIDC trusted publishing を使っている repo ほど、「もう安全化できている」と思ったまま direct publish を続けやすいです。

見直し順は単純です。

• package settings で trusted publisher の allowed actions を確認する
• 可能なら stage-only に寄せる
• workflow 側の npm publish を npm stage publish に替える
• approve を誰がどこで行うか決める

GitHub Actions 側の保護も見直すなら、GitHub Actions security roadmap 2026 で何が変わるか も合わせて見ると流れをそろえやすいです。

install 側は --allow-remote から点検すると早い

publish 側だけ直しても、install 側が無制限なら supply-chain の見直しは半分で止まります。

今回の追加で、npm は non-registry source を source ごとに許可制へ寄せやすくなりました。

• --allow-file: local file path と local tarball
• --allow-remote: https tarball など remote URL
• --allow-directory: local directory
• --allow-git: git source 全般

各 flag は all か none を取れます。

しかも npm docs では、CLI flag だけでなく .npmrc や package.json config にも置けます。これはかなり実務的です。

たとえば、最初の一歩はこう切れます。

• CI だけ allow-remote=none にする
• 開発環境はまだ緩めに残す
• 壊れた install job から remote tarball 依存を洗い出す
• 次に allow-file と allow-directory を締める

特に --allow-remote=none は、気づかないうちに URL install が残っていないか を見る入口として使いやすいです。

AppSec 観点で周辺の選択肢まで広げるなら、Codex Security vs Snyk vs Semgrep vs GitHub Advanced Security【2026年版】AI時代のAppSecはどれを選ぶべきか も参考になります。

いまの CI/CD をどう切り分けるべきか

一度に全部変えるより、job を3つに分けて考えるほうが安全です。

1. build と test

ここは今まで通り自動で流して構いません。

むしろ staged publishing を使うなら、approve 前に何が終わっているべきか を明確にする意味が強くなります。

2. stage publish

ここで npm stage publish を使います。

trusted publishing を使うなら token ではなく OIDC を維持したまま、package を queue へ上げられます。

3. final approve

最後は maintainer が CLI か npmjs.com で approve します。

このステップは非効率に見えますが、release の責任境界を見える形で残せる のが利点です。AI coding agent や自動化 job から repo を触る運用が増えているなら、GitHub Agentic Workflows vs Copilot coding agent vs OpenClaw cron｜継続的な repo 自動化はどこに置くべきか のように、自動化の責務分割と一緒に整理したほうがぶれません。

すぐやるチェックリスト

今日やるなら、見る場所は多くありません。

publish 側

• runner の npm が 11.15.0 以上か
• Node が 22.14.0 以上か
• trusted publisher の allowed actions が publish-only になっていないか
• npm publish を使う workflow を何本持っているか
• approve を誰が担当するか

install 側

• remote tarball install が残っていないか
• local file、directory install を CI で本当に使っているか
• .npmrc と package.json に source control を置く余地があるか
• allow-remote=none を先に CI へ入れて壊れないか

この順なら、公開停止の設計 と 依存取得の締め方 を同じ runbook に載せやすいです。

どこから着手するのが安全か

最初から stage-only を全 package に強制すると、古い workflow や初回公開 package で詰まりやすいです。

だから現実的には、次の順が向いています。

1. 既存 package で OIDC trusted publishing を使っている repo を洗い出す
2. その中で release 事故コストが高い package から stage-only を試す
3. install job に allow-remote=none を入れて壊れる repo を特定する
4. 壊れた repo だけ remote tarball や local path の依存理由を潰す

このやり方なら、ルールを増やす前に どの repo が新運用に耐えられるか が分かります。

まとめ

npm staged publishing GA は、単に publish コマンドが1つ増えた話ではありません。

CI でどこまで自動化し、どこで人間が止めるかを再設計できる更新 です。

同時に、--allow-remote などの追加で、install 時の supply-chain policy も source 単位で締めやすく なりました。

いま優先すべきなのは、npm publish を全部置き換えることではありません。

• trusted publisher の allowed actions を確認する
• stage-only に寄せられる package から始める
• allow-remote=none で install 側の棚卸しを始める

この3つから入るのが、いちばん事故が少ない進め方です。