npmのOIDC公開元を最大10件に、長期トークンを減らせる

GitHubは2026年9月3日、同じnpmパッケージに複数のTrusted Publishing設定を登録できる機能を一般提供した。GitHubの変更履歴 によれば、安定版、プレリリース、ステージングを別々のリポジトリ、ワークフロー、環境に割り当てられるほか、マルウェアスキャン中はステージ版を承認できない仕組みも同時に一般提供された。

2026年9月3日の更新により、1パッケージへ登録できるOIDC公開元は最大10件となった。単一設定では扱えなかった公開経路も短期資格情報へ移しやすくなり、CI/CDに保存する長期書き込みトークンを減らせる。ただし、複数設定は互いを制限しないため、直接公開を許可した経路の扱いが安全性を左右する。

複数設定はすべて独立した許可経路になる

Trusted Publishingの複数設定は、条件を順番に重ねる仕組みではない。各設定は独立して加算され、受け取ったOIDCトークンがいずれか1件の条件を満たせば、その設定で認められたpublishまたはstage操作が許可される。評価順序も保証されない。

GitHub Communityのnpm告知 も、設定には拒否規則や優先順位がなく、1件の一致だけで認可されること、上限がパッケージ当たり10件であることを説明している。したがって、production環境を条件にした厳格な設定を追加しても、環境指定のない既存設定の範囲は狭まらない。

例えば、安定版用のrelease.ymlだけに直接公開を許し、プレリリース用のprerelease.ymlと検証用のstage.ymlをステージング専用にする構成は可能だ。ただし、後者に承認工程を設けても、release.ymlに一致する処理は独立して直接公開できる。確認すべき対象は設定一覧のうち最も厳しい項目ではなく、公開を認可できるすべての経路である。

GitHub Actions、GitLab、CircleCIで登録値を分ける

npmのTrusted Publishing文書 では、対応環境をGitHub-hosted runner、GitLab.com shared runner、CircleCI cloudとしている。セルフホスト型runnerは未対応で、Trusted Publishingにはnpm CLI 11.5.1以降とNode.js 22.14.0以降が必要だ。設定はnpmjs.comの対象パッケージにあるSettingsから追加する。

• GitHub Actions：organizationまたはuser、repository、workflow filenameを登録する。ファイル名には.ymlまたは.yamlを含め、リポジトリの.github/workflows/に存在するファイル名だけを入力する。ワークフローにはid-token: writeが必要で、GitHub Environmentを使う場合はenvironment nameも条件にできる。
• GitLab CI/CD：namespace、project name、トップレベルのCI file pathを登録する。パイプラインではid_tokensにNPM_ID_TOKENを定義し、audをnpm:registry.npmjs.orgに設定する。GitLab Environmentの名前は任意条件として追加できる。
• CircleCI：organization ID、project ID、pipeline definition ID、VCS originを登録する。必要ならcontext IDで対象を絞り、ジョブで取得したCircleCIのOIDCトークンをNPM_ID_TOKENへ設定すると、npm CLIが短期の公開資格情報へ交換する。

安定版とプレリリースが同じGitHubリポジトリにあっても、release.ymlとprerelease.ymlを別の接続として登録できる。さらにGitLabやCircleCIのパイプラインを別経路として加えることも可能だ。登録値は大文字と小文字を含めて実際のOIDC claimと一致させる必要があり、npmは保存時に設定内容を検証しないため、誤りは公開を試した時点で判明する。

ステージングと直接公開は接続ごとに選ぶ

2026年9月3日より後に作成した設定では、npm stage publishが標準で許可され、npm publishによる直接公開は接続ごとに追加で選択する。ステージング専用にすれば、CI/CDが投入したバージョンは直ちに公開されず、メンテナーの確認と2FAによる承認を待つ。

npmのstaged publishing手順によると、npm stage publishにはnpm CLI 11.15.0以降とNode.js 22.14.0以降が必要で、ステージング自体では2FAを要求されない。一方、公開レジストリへ昇格させる承認では、CLIとnpmjs.comのどちらを使っても2FAが必要になる。新規パッケージはステージングできず、すでにレジストリに存在するパッケージが対象だ。

検証用やプレリリース用の接続をstage-onlyにし、即時配布が必要な安定版の接続だけに直接公開を許す設計はできる。全自動経路に人の確認を入れるなら、すべてをstage-onlyにする。直接公開を選んだ場合は、そのワークフローを変更できる権限やリポジトリ、Environmentの保護が、そのまま公開可否の境界となる。

プロベナンスの生成はCI/CDによって異なる

Trusted Publishingで公開すると、GitHub ActionsとGitLab CI/CDではプロベナンス証明が既定で生成され、publishコマンドへ--provenanceを加える必要はない。ただし、自動生成の対象は公開リポジトリから公開パッケージを配布する場合に限られ、private repositoryには適用されない。

CircleCIのTrusted Publishingはプロベナンスの自動生成に対応していない。このため、OIDCによって長期書き込みトークンを外せる点は3環境で共通していても、公開物に付く来歴証明は同じではない。複数のCI/CDを併用する場合、どの経路から公開した版に証明が付くかを分けて扱う必要がある。

既存接続は編集せず、追加後に切り替える

既存のTrusted Publishing接続は編集できない。providerと必須フィールドは作成時に固定されるため、repository、workflow filename、CI file pathなどを変更するには、接続を削除して作り直す必要がある。移行前に古い設定を削除すると公開経路が途切れる可能性があるため、新しい接続を追加して動作を確かめてから不要な接続を外す順序が適している。

1. 現在のTrusted Publishing接続、公開用npmトークン、実際に動くワークフローを対応付ける。
2. 安定版、プレリリース、検証用の各経路について、provider、repositoryまたはproject、workflowまたはpipeline、environment、許可する操作を決める。
3. 新しい接続を追加し、ステージングを使う経路ではnpm stage publishと承認までを確認する。
4. 直接公開が不可欠な接続だけnpm publishを許可し、広すぎる接続や古い接続を削除する。
5. OIDC経路の稼働後、Publishing accessで従来型トークンによる公開を禁止し、不要なautomation tokenを失効させる。

削減できるのは主に公開用の長期資格情報であり、npmの認証すべてではない。private dependencyをnpm ciで取得する工程では読み取り専用トークンが必要になる場合がある。OIDCが対応する操作もnpm publishとnpm stage publishに限られ、stageの一覧表示、確認、承認、拒否には対話的な認証が必要だ。

今回の一般提供で、単一設定に収まらなかった公開パイプラインもOIDCへ分離しやすくなった。一方、古い接続や直接公開権限は、新しいstage-only設定を追加しても自動では無効にならない。セルフホスト型runnerと追加のCI/CD providerは今後の対応対象とされているが、提供時期は示されていない。