社内の共通UIや設定をモノレポで持ち、Changesetsでバージョンを付けていると、共通パッケージに新しいプロパティを足した（minorの変更）だけで、それをpeerDependenciesに書いている周辺のパッケージ（以下、参照側）がまとめてメジャーに上がります。Changesets v2の既定の挙動です。
メジャーが上がれば、参照側のパッケージを使う人は、実際には何も壊れていなくても、リリースノートを読み、動作を確かめ、場合によっては承認を取り直すことになります。共通部品に手を入れるたびにこの手間がついてくるのは、保守の負担として小さくありません。
v3で何が変わったか
Changesetsは2026年8月11日にv3を公開しました。npmでは同日に3.0.0が公開され、9月26日時点の最新は9月14日公開の3.0.3です。
公式ブログは、peer依存の扱いの変更を、長年もっとも要望の多かった変更だと説明しています。v2では、peer依存として参照されているパッケージがminorで上がると、使い方が壊れていなくても参照側をメジャーで上げていました。v3では、peer依存の更新で参照側に付く上げ幅はpatchになります。参照側が新しい版と本当に合わなくなる場合は、changesetを書く人が参照側にmajorを明示する、という分担に変わりました。
手元で確かめた、上がる条件
公式の説明だけでは、参照側がいつ上がるのかまでは読み取りにくいため、2026年9月26日に検証用の最小構成で動かして比べました。共通パッケージ（1.0.0）と、それをpeerDependenciesに^1.0.0で書くパッケージ、1.0.0（完全一致）で書くパッケージを用意し、共通パッケージにpatch・minor・majorのchangesetを置いて、それぞれchangeset versionを1回実行しています。環境はNode.js 22.22.2とnpm 10.9.7のワークスペースで、設定は変更履歴の生成を切った以外は既定のままです。
| 共通パッケージの変更 | 参照側のpeer指定 | v2（2.31.1）での参照側 | v3（3.0.3）での参照側 |
|---|---|---|---|
| patch（1.0.1へ） | ^1.0.0 | 上がらない | 上がらない |
| patch（1.0.1へ） | 1.0.0 | patch | patch |
| minor（1.1.0へ） | ^1.0.0 | major（2.0.0） | 上がらない |
| minor（1.1.0へ） | 1.0.0 | major（2.0.0） | patch |
| major（2.0.0へ） | ^1.0.0 | major（2.0.0） | patch（指定は^2.0.0に） |
| major（2.0.0へ） | 1.0.0 | major（2.0.0） | patch（指定は2.0.0に） |
読み取れることは3つです。
- v2では、共通パッケージのminorの変更だけで、指定した範囲（
^1.0.0）に収まっていても参照側がメジャーに上がっていました。冒頭の手間の出どころはここです。 - v3では、peer依存も通常の依存（dependencies）と同じ扱いになりました。新しい版が指定の範囲から外れるときだけ参照側がpatchで上がり、範囲内なら上がりません。比較のためdependenciesに
^1.0.0で書いたパッケージは、v2・v3とも、minorでは上がらず、majorでpatchでした。 - 共通パッケージがmajorで上がると、v3では参照側のpeer指定が
^2.0.0に書き換わるのに、参照側の上げ幅はpatchにとどまります。参照側を使う人が共通パッケージを1系のまま使っていれば、このpatchは実質的に影響のある更新です。移行ガイドのとおり、changesetを書くときに参照側を見直し、合わなくなるならmajorを明示します。
pnpmのワークスペースでworkspace:^とworkspace:*を指定した場合も、それぞれ^1.0.0、完全一致と同じ結果でした（pnpm 10.33.0）。範囲から外れたときだけ上げるのは、実験的な設定updateInternalDependentsの既定値（"out-of-range"）による動きです。"always"にすると、v3でもminorの変更で^1.0.0の参照側がpatchで上がりました。いずれも最小構成での確認で、実際のリポジトリの移行は行っていません。
同時に変わった前提
ただし、上げるだけで済む更新ではありません。同じリリースで前提条件が変わっています。
| 項目 | v3での条件 |
|---|---|
| モジュール形式 | 全パッケージがESM専用 |
| Node.js | 22系は22.11以上、24系、26以降（^22.11・^24・>=26）。23系と25系は対象外 |
| パッケージマネージャ | pnpm 10.0.0以上 / npm 10.9.0以上 / Yarn 4.5.2以上。Yarn Classicは非対応 |
| GitHub Actions | changesets/action@v2が必要。v1はChangesets v2でしか動かない |
リリース対象が無いときのchangeset version | 終了コード1で終わる（v2は0） |
| インストールサイズ | 16.1MB → 2.1MB（約87%減） |
| 依存の数 | 95 → 39 |
公式の移行ガイドは、これより古いNode.jsやパッケージマネージャについて、動く場合もあるがテストもサポートもしない、としています。
インストールサイズと依存の数は公式ブログの数値で、約87%は16.1MBと2.1MBから編集部が計算しました。9月26日に空のディレクトリへnpmで入れて比べたところ、3.0.3のnode_modulesは約2.1MB・依存39個で、公式の数値と同じでした。v2系の2.31.1は約17.6MB・依存100個です。公式ブログは、比較に使ったv2の版を示していません。
上げる前に確認する順番
保守している案件でこれを上げるかどうかは、次の順で確認すると判断しやすくなります。
- モノレポ内でpeer依存を使っているか。 社内パッケージをpeerDependenciesに書いていなければ、今回の目玉の恩恵はありません。上げる動機は、インストールの軽さなどに限られます。
- CIと開発環境のNode.jsが対象の版か。 22.11未満のほか、23系・25系も対象外です。外れていれば、Node.jsの更新が先に立ちます。
- Yarn Classic（1系）を使っていないか。 v3は対応していないため、使っている場合はパッケージマネージャの移行が前提になります。
- Changesetsのパッケージを自前のスクリプトから直接読み込んでいないか。 移行ガイドによれば、package.jsonのscriptsやCIから
changesetコマンドを呼ぶだけなら、対応するNode.jsにすれば他の変更は要りません。@changesets/get-release-planなどを直接使っている場合や、設定で@changesets/changelog-githubなどを指定している場合は、移行ガイドの対応表に沿って版を上げ、各パッケージのCHANGELOGで破壊的変更を確かめます。 - CIの定義と設定ファイルを直す。
changesets/actionをv2に上げ、入力名の変更（version→version-script、publish→publish-script、commit→commit-message、title→pr-title）に合わせます。リリース対象が無いとchangeset versionが失敗扱いになるため、無条件に実行している箇所を見直します。このほか、changeset tagはchangeset git-tagに、--sinceMasterは--sinceに変わり、baseBranchの既定値はmainになりました。privateなパッケージは既定でバージョンが付かなくなり、prettierの設定はformatに置き換わっています。
1番目を先に見てもよいところです。恩恵が無いなら、条件をそろえる作業をいま急ぐ理由は小さくなります。v2系はnpmの保守用タグ（maintenance-v2、7月15日公開の2.31.1）が残っていますが、保守をいつまで続けるかは、今回確認した公式資料には書かれていませんでした。
リリース権限の設計は別問題
バージョンの上げ方が変わっても、「CIが通れば公開される」構造そのものは変わりません。共通部品のリリースを誰がどの段階で承認するかは、ツールの設定とは別に決める必要があります。npmの段階公開（staged publishing）について、Changesetsの公式ブログは対応を進めていて次の機能更新に入れるとしており、9月26日時点の3.0.3までには入っていません。公開の手前に人の承認を挟む形の整理はnpmの段階公開にまとめました。
依存の更新をどこまで自動で取り込むかも、あわせて見直す時期です。上の表のとおり、v3では共通パッケージのmajorの変更が、参照側にはpatchとして出ることがあります。書き手がmajorを明示しなければ、patchを自動で取り込む設定の利用者には、影響のある更新がpatchとして届きえます。パッケージマネージャ側の既定で取り込みを遅らせる考え方はpnpmの「1日遅延」既定を参照してください。
次にやること
保守しているリポジトリのうち、Changesetsを使っているものについて、CIのNode.jsの版、パッケージマネージャとその版、changesets/actionの版、peer依存の使い方を一覧にしてください。v3の条件を満たしているものと、満たすために作業が必要なものに分かれます。
条件を満たしているものから先に上げ、peer依存の上がり方が上の表のとおりに変わることを自分たちのリポジトリでも確かめてから、残りの計画を立てるのが現実的です。
2026年9月26日に、Changesetsの公式ブログ（v3の告知、2026年8月11日付）、v2からv3への移行ガイド、設定ファイルのドキュメント、@changesets/cliのCHANGELOG、npmレジストリの公開日時と
enginesの記載を確認しました。peer依存の上がり方とインストールサイズは、同日に検証用の最小構成（npmとpnpmのワークスペース、Node.js 22.22.2）で@changesets/cli 2.31.1と3.0.3を動かして確かめたものです。実際のリポジトリの移行、changesets/action@v2を使ったCIの動作、npmへの公開は行っていません。InfoQの2026年9月22日付の記事は報道として参照しました。
モノレポのリリース設計や、保守案件の依存更新の方針づくりは、グリームハブへご相談ください。
