npm trusted publishingの未検証設定は48時間で失効？再作成手順とissue_comment禁止の対応を一次情報で解説（2026年10月2日発表）

AI開発ツールアップデート料金改定npmGitHubセキュリティ

GitHub が npm の信頼済みパブリッシング（trusted publishing）で、検証されていない設定を作成から48時間で失効させる仕様に変更しました。失効した設定の再作成手順、issue_comment イベント禁止への対応、設定数上限の扱いを一次情報で整理します。

結論から言うと、npm の信頼済みパブリッシング（trusted publishing）のうち、まだ一度もパブリッシュが成功していない「検証されていない（unvalidated）設定」は、作成から48時間で失効して使えなくなります。あわせて、GitHub Actions の issue_comment イベントから発行されたトークンは受け付けなくなりました。設定が失効したら npmjs.com で設定を作り直し、 issue_comment を使っているワークフローは push・release・workflow_dispatch など許可されたイベントへ移行します（出典: GitHub Blog Changelog「Unvalidated npm trusted publishing configurations now expire」2026年10月2日・2026年10月6日取得）。

2026年10月2日、GitHub は npm の信頼済みパブリッシングに関する2つの仕様変更を発表しました。（1）検証されていない trusted publishing 設定は作成から48時間で失効し、以後パブリッシュの承認に使えない。（2）GitHub Actions の issue_comment イベントから発行された信頼済みパブリッシング・トークンを npm が拒否する（以前から制限されている pull_request_target に追加の形）。いずれも、リポジトリやプロジェクト名の所有権が移ったあとに設定を悪用されるリスクを抑えるのが目的です。

本稿では、48時間の検証ウィンドウの仕組み、失効した設定の扱い、issue_comment からの移行先、設定数の上限を、公式の一次情報だけから整理します。本文中の値はすべて出典付きで、取得日は 2026年10月6日です。

npm trusted publishing の48時間失効とは何か

検証されていない（unvalidated）trusted publishing 設定は、作成から48時間で失効し、パブリッシュの承認に使えなくなります（出典: GitHub Blog Changelog 2026年10月2日・2026年10月6日取得）。trusted publishing は GitHub Actions などの CI から OIDC トークンで直接公開する仕組みで、npm Docs によれば設定を保存した時点では npm 側の検証は行われず、設定とワークフローの一致判定は初回の公開時に行われます（出典: npm Docs「Trusted publishing」2026年10月6日取得）。

「検証済み」になるのは、その設定を使ったパブリッシュが最初に成功したときです。検証済みになった設定は失効対象外になり、通常の編集で48時間の期限がリセットされることもありません。

• 失効した設定は、信頼済みパブリッシャー設定の画面に表示され続けます。
• 失効した設定は、パッケージごとの設定数の上限にはカウントされません（上限はパッケージあたり最大10個。出典: npm Docs 2026年10月6日取得）。
• 同じパッケージの他の有効な設定には影響しません。
• リポジトリ名やプロジェクト名など識別情報を変えた場合は、新しい信頼関係の構築が必要で、新しく48時間の検証期間が始まります。

なぜ48時間で失効するのか（対象と目的）

GitHub が挙げているのは、リポジトリやプロジェクト名の所有権変更を悪用されるリスクです。削除したリポジトリと同名のリポジトリを別の人が作る、組織の移転で名前が再利用される、といったケースで古い trusted publishing 設定が残っていると、新しい所有者がその設定を使えてしまう恐れがあります。作成から48時間の検証ウィンドウを設けることで、使う意図のない設定が蓄積しても悪用の窓口にならないようにしました。

あわせて、GitHub Actions の issue_comment イベント（コメントをトリガーに動くワークフロー）から発行されたトークンを npm が拒否するようになりました。issue_comment はフォーク元リポジトリの書き込み権限を持つコードが動く経路になりやすく、以前から制限されていた pull_request_target と同様の扱いです（出典: GitHub Blog Changelog 2026年10月2日・2026年10月6日取得）。

失効したとき・issue_comment を使っているときの対応手順

1. npmjs.com のパッケージ設定で「Trusted Publisher」の設定を作り直します。作り直すと新しい48時間の検証ウィンドウが始まります（出典: GitHub Blog Changelog 2026年10月2日）。
2. 作り直した設定で最初のパブリッシュを成功させ、設定を「検証済み」にします。検証済みになれば失効対象外です。
3. ワークフローを issue_comment で起動している場合は、push・release・workflow_dispatch など許可されたイベントに移行します。npm Docs によると workflow_dispatch や workflow_call を使う場合、検証されるのは発行コマンドを含むワークフローではなく呼び出し元ワークフローの名前です（出典: npm Docs 2026年10月6日取得）。

よくある質問

Q. 失効した設定は削除が必要ですか？

失効した設定は画面に表示され続けますが、パブリッシュには使えず、設定数の上限にもカウントされません。削除しなくても他の設定の利用には影響しません（出典: GitHub Blog Changelog 2026年10月2日・2026年10月6日取得）。

Q. 48時間以内にパブリッシュできなかったらどうなりますか？

設定は失効して承認に使えなくなります。対応は設定の再作成で、再作成時点から新しい48時間の検証ウィンドウが始まります。検証済みになった設定は失効しないため、公開頻度が低いプロジェクトほど初回公開を48時間以内に通す必要があります（出典: 同上）。

Q. issue_comment の代わりにどのイベントを使えばよいですか？

GitHub は push、release、workflow_dispatch など許可されたイベントへの移行を挙げています（出典: GitHub Blog Changelog 2026年10月2日）。コメントで起動する手動実行は workflow_dispatch に寄せられますが、workflow_dispatch・workflow_call では検証対象が呼び出し元ワークフローの名前に変わる点に注意してください（出典: npm Docs 2026年10月6日取得）。

Q. stage-only トークンなどの別の公開方法と併用できますか？

できます。npm Docs によると、trusted publishing を使った CI でも npm stage publish（ステージングへの送信）は常に許可され、メンテナーが npm stage approve で2FA承認する流れと組み合わせられます（出典: npm Docs「Trusted publishing」2026年10月6日取得）。stage-only トークンの作り方と使い方は当サイトの stage-only npm トークンまとめ（2026年9月19日公開）にまとめています。

AI開発ツール速報（当サイト）は、GitHub・npm・Cursor・VS Code など開発ツールの仕様変更や料金改定を、公式発表への出典付きで最速でお届けする速報メディアです。トークンや公開フローの変更はセキュリティ設定にも波及するため、発表日の当日に一次情報で確認できるようにしています。

この記事は AI が一次ソースを読んで執筆しました。数値と日付は出典に記した公式情報の執筆時点の値です。誤りを見つけたら訂正の窓口へお知らせください。確認のうえ本文を直し、訂正履歴に残します。編集方針