本記事はAIを利用して作成した技術解説・実装例です。掲載するコードや手順は一次情報を基に構成していますが、筆者による実機での動作確認は行っていません。環境やバージョンによって動作が異なる場合があります。
GitHub Changelogにて公開された「Multiple trusted publishing configurations for npm」に関する公式情報をベースに、npmの信頼済みパブリッシング（Trusted Publishing / OIDC）機能におけるアップデート内容を整理します。
一次情報では、メンテナーからのフィードバックを受けて、npmの信頼済みパブリッシングをよりスムーズにするための3つのアップデートが一般提供（General Availability）開始されたことが説明されています。本記事では、それぞれの構成要素と利用時のポイントについて詳細を読み解きます。
複数設定のサポートと背景
これまでのnpmパッケージの信頼済みパブリッシングでは、1つのパッケージにつき維持できるOIDC（OpenID Connect）構成は1つのみという制限がありました。そのため、安定板（stable）、プレリリース（prerelease）、ステージング（staging）などの異なるワークフローを分離したい場合、メンテナーはワークフロー側で何らかの回避策を講じるか、OIDCがカバーしきれないパスのために長期トークンを維持する必要がありました。
今回のアップデートにより、1つのパッケージに対して複数の信頼済みパブリッシング構成を紐付けられるようになりました。これにより、ワークフローごとの柔軟な分離が可能になります。
独立した追加型の構成モデル
各構成は独立しており、それぞれが独自の対象リポジトリ、ワークフロー、および環境の基準（criteria）を持つ追加型（additive）の仕組みとして動作します。
パッケージの設定ページから、これらの構成の追加、一覧表示、削除を行うことができます。入力されたOIDCトークンがいずれか1つの構成に一致していれば、パブリッシングまたはステージングが承認されます。
構成同士が互いを制限することはありません。また、評価順序（evaluation order）は保証されていないため、特定の構成が先に一致することを前提とした依存ロジックを構築しないよう注意が促されています。
ステージングと直接パブリッシングの挙動
すべての信頼済みパブリッシング構成は、デフォルトでパッケージをステージング（staging）できるようになっています。一方、直接パブリッシング（direct publishing）は構成ごとにオプトイン（明示的な有効化）が必要です。
公式情報では、構成をステージング専用に維持することが推奨されています。ステージングされたパブリッシングには、バージョンが一般利用可能になる前に人間の承認ステップが挟まるため、万が一ワークフローが侵害された場合でも、レジストリへ直接プッシュされるリスクを防ぐことができます。
マルウェアスキャンと承認ボタンの制御
公開時マルウェアスキャン（publish-time malware scanning）の導入以降、パッケージは利用可能になる前にスキャンが実行されます。
ステージングされたパブリッシングのキューにおいて、パッケージがまだスキャン中の間は承認ボタンが無効化されます。スキャンが完了すると、ボタンが有効化されて操作可能になります。なお、ページ側のステータスは1分ごとに自動更新される仕組みになっています。
パッケージバージョンタブにおける履歴表示
npmjs.comのバージョン（versions）タブにおいて、それぞれのメンテナーに対して各バージョンの詳細な履歴が表示されるようになりました。
この履歴には、そのバージョンが承認されたのか、拒否されたのか、あるいは現在もステージング中であるのかといったステータスが含まれており、管理者が状況を把握しやすくなっています。
公式情報から読み解く利用時の注意点
一次情報から確認できる内容を整理すると、複数のOIDC構成を運用する際は以下の点に留意する必要があります。
1つのパッケージに複数の構成を登録可能ですが、評価順序に依存したロジックは避ける。
デフォルトではステージングとして動作し、直接パブリッシングはオプトインで構成する。
マルウェアスキャンの完了状態に応じて承認ボタンの有効・無効が切り替わるため、ステータスの更新タイミングに配慮する。
【実機確認前】実際のGitHubリポジトリ設定画面やnpmの設定画面、API/CLIを利用した具体的な確認手順については、今後検証環境が整った段階で改めて整理します。
