npm Stage-only TokenはAI Agentにパッケージを公開できるか？2026年の受け入れ判定

対象読者
AI Coding Agent、GitHub Actions、または遠隔Macでnpmパッケージを構築する開発者向けです。Agentの作業範囲を狭めたいパッケージ維持担当者、長期トークンとOIDCを見直すプラットフォーム担当者、macOS固有の成果物を扱うセキュリティ・リリース担当者にも適しています。

最初の判定: Stage-only Tokenは「直接公開を止める制御」であり、「Agentに残る書き込み権限を消す制御」ではありません。npmはこのトークンでもdist-tagの移動やバージョンの非推奨化など、公開後のパッケージ状態に影響する操作を残しています。詳細はnpmのアクセストークン権限説明で確認できます。

12026年9月の判断：暫定公開と正式承認を分ける

npmのStage-only Tokenは、Agentが作成したパッケージを確認待ちの状態へ送るためのトークンです。GitHubの公式変更記録では、Read and write（stage only）権限を持つトークンによる直接のnpm publishは拒否され、最終的な公開には維持担当者の2FAが必要と説明されています。Stage-only Tokenに関する公式変更記録とnpm staged publishingの仕様を、導入前の基準文書にしてください。

ただし、暫定領域へ入ったことは、内容が安全であることを意味しません。承認者はバージョン番号、tarballの内容、生成元コミット、依存関係、変更範囲を別の視点で確認し、Agentの報告だけで公開しないことが必要です。npm発行の運用を見直す際は、vpstixの技術記事一覧も参照し、Agentの実行環境と発行承認を別の管理対象として整理してください。

npmの公式ドキュメントにはアクセストークンの作成方法と権限区分が掲載されています。導入時はトークン作成と確認の公式手順を確認し、Stage-only Tokenを通常のRead and write Tokenと同じ扱いにしないでください。

2AI Coding Agentの範囲：コード生成から暫定公開まで

AI Coding Agentに与える役割は、コード生成、テスト、パッケージ生成、暫定公開までに限定します。正式な2FA認証情報、維持担当者のセッション、広い範囲のnpm管理権限は、Agentのプロンプト、ツール設定、環境変数、子Agentのコンテキストに渡してはいけません。

ここで見落としやすいのが、npm publishの拒否だけを確認して合格にしてしまうことです。Stage-only Tokenが直接公開を止めても、スクリプトやツール経由でdist-tagを変更したり、別バージョンを非推奨にしたりできるなら、パッケージ利用者への影響は残ります。

npm staged publishingとTrusted Publishingの選び分け

短期的に既存の自動化を維持したい場合は、Stage-only Tokenを使ってAgentの公開を暫定段階へ閉じ込める構成が現実的です。一方、CI/CDの実行基盤がnpmのTrusted Publishing対応条件を満たすなら、OIDCによる短期的な本人確認を優先して検討します。npm Trusted Publishingの対応範囲と前提では、ワークフローの身元、CI/CDの種類、パッケージ単位の設定を確認する必要があります。

Trusted Publishingに移行しても、承認不要になるとは限りません。OIDCは長期トークンの保管を減らす仕組みであり、成果物のレビュー、発行条件、実行Runnerの隔離、誤ったワークフロー変更への対策まで代替するものではありません。GitHub Actionsを使う場合も、ワークフローの変更権限と公開ジョブの実行条件を別々に監査してください。

npmが示す、bypass-2FAトークンによる直接公開機能の廃止目標は2027年1月です。ただし、これは公式の計画時期であり、変更されない保証ではありません。将来の移行日だけを理由に急いで切り替えず、Stage-only Tokenの権限変更やOIDC対応範囲の拡大も再確認してください。

3セキュリティ担当者の受け入れ検査：拒否だけで合格にしない

第一段階：Agentの権限境界を固定する

作業ごとに独立したワークスペースを作り、対象リポジトリのコミット、生成されたtarball、暫定公開の記録を関連付けます。共有ディレクトリや前回ジョブのキャッシュをそのまま使うと、別パッケージの成果物や古い認証情報が混ざるため、タスク終了後の削除まで運用に含めます。

第二段階：直接公開と残存操作を別々に試す

次の確認は、同じトークンでまとめて実施しないでください。

• 直接のnpm publishが拒否されること
• 対象外パッケージへ書き込めないこと
• dist-tagを意図せず移動できないこと
• 既存バージョンを非推奨にできないこと
• 失敗した公開処理が再試行で別の状態を作らないこと

直接公開の拒否だけが確認できても、残りの操作が制御されていなければ受け入れ不可です。Stage-only Tokenは、最小権限、通信先制限、ログ監査、トークンの失効を置き換えません。

第三段階：秘密情報の露出経路を確認する

トークンがCIログ、キャッシュ、ワークスペースのスナップショット、デバッグ出力、Agentの会話履歴、子Agentの入力へ入っていないかを調べます。npmのトークン文書に沿って作成者、対象、利用期間、失効方法を記録し、漏えいを想定した撤回と再発行の手順を実際に実行できる状態にします。

不合格にする条件: 直接公開が拒否されても、誰が2FA承認したかを追跡できない、tarballを再現できない、またはトークンを含む作業環境を消去できない場合は、Agentによる暫定公開を開始しないでください。

4遠隔Macの役割：構築ホストと承認者を分ける

macOS固有のネイティブ依存関係、クロスプラットフォームのバイナリ、Apple向けツールチェーンを含む場合、遠隔Macは構築と検証のために使います。そこへ維持担当者の2FAや正式公開用の長期認証情報を保存しないでください。Macの隔離は実行環境の境界を強くしますが、npmアカウントの権限や成果物の出所を自動的に正しくするものではありません。

構築前にコミットIDと依存関係を固定し、構築後にtarballのファイル一覧、テスト結果、署名または生成情報を保存します。Agentが「成功」と報告しただけで承認せず、実際のログと成果物が同じコミットから作られたことを確認してください。遠隔Macを組み込む場合は、vpstixのMac環境案内を確認したうえで、組織で定めた接続経路、作業領域、廃棄手順を優先して文書化してください。

5リリース責任者の判定：限定導入か、移行か、保留か

導入判断はパッケージの影響範囲で分けます。利用者が限られ、失敗時に撤回と再公開を検証できるパッケージなら、Agentによる暫定公開と維持担当者の2FA承認を限定的に始められます。広く利用されるパッケージや重要な依存関係では、独立した再テストと複数人の承認を追加してください。

受け入れ時には、次のチェック項目を保存可能な証跡として残します。

• [ ] 直接の正式公開が拒否されたログを保存した
• [ ] Stage-only Tokenで残るdist-tag・非推奨化権限を確認した
• [ ] Agent、構築担当、2FA承認者の役割を分離した
• [ ] コミット、tarball、テスト結果、暫定公開記録を関連付けた
• [ ] トークンがログ、キャッシュ、スナップショットに残らないことを確認した
• [ ] 遠隔Macの作業領域と認証情報をタスク終了後に消去した
• [ ] OIDC対応条件とTrusted Publishing移行可否を確認した
• [ ] 失敗時の失効、撤回、再構築、再承認を実行できる

判定は、条件付きの限定導入、Trusted Publishingへの移行を前提にした二軌道運用、または手動公開の継続のいずれかに明文化します。隔離された作業環境を用意できないチーム、成果物の出所を復元できないチーム、承認者の責任を記録できないチームは、Stage-only Tokenを発行しても運用を開始しない方が安全です。

現在の長期書き込みトークン運用は、AgentやRunnerの侵害時に影響範囲が広く、ログやキャッシュに残った資格情報の回収も難しくなります。反対に、Stage-only Tokenだけへ置き換えても残存するパッケージ書き込み権限、手作業の2FA、構築環境の混在という弱点は消えません。macOSの構築や一時的な発行検証が必要なら、構築と承認を分けられるvpstixのMac環境を候補に含め、本文の証跡条件を満たせるか確認してから小さく試すのが適切です。長期的な高負荷発行や物理デバイス依存の作業では、自社管理のMacや専用環境の方が適する場合もあります。