AI時代のソフトウェアプロダクトのアーキテクチャを考える連載企画の第2回です。2回目にして番外編ですが今回はバージョニング。
まず結論としてですが、カレンダー・バージョニングを推します。
セマンティック・バージョニングとその課題
現在バージョニング界隈（？）でデファクトスタンダードとなっているのがセマンティック・バージョニングです。
Tom Preston-Wernerこれはもう本当にありふれているので解説は割愛するのですが、1.5.2 のような . で区切られる3つの数値を扱い、それぞれ MAJOUR.MINOR.PATCH という意味を付与することにより、数値以上のコンテクストを伝える手法です。先頭の数値、メジャーバージョンが上がった場合、なんらかの破壊的変更がある（場合がある）ことをことを伝えることができます。
セマンティック・バージョニングは世界中で運用されているのですが、問題があるとすると、下記の3つが考えられます。
- マイナーやパッチバージョンが上がりすぎる問題
- リリースの時期とバージョンが紐付かない問題
- モノレポでバージョンよく分からなくなる問題
いちおう、メジャーバージョンをアップするのは、大きな新機能が追加されるか、後方互換性が大きく壊れる場合に適するとされています。とすると、日々の機能追加やバグ修正はマイナーやパッチで行われることがほとんどです。その場合、マイナーおよびパッチ・バージョンをリセットするタイミングがないので結果 1.5.121 といった大きなバージョンになりがちです（stable リリース前によくあるのが、 0.9.148 みたいな...）。
バージョンはただの数値なので、識別できれば大きくても問題ないといえばないのですが、あわせて、リリースの時期とバージョンが紐付かない問題とセットにすると、「1.5.135 からCVRが改善していて...」みたいな会話をするときにそれリリースしたのいつだっけ？といういつだっけ問題（直球）が生じます。これを解決できるのがカレンダー・バージョニングです。モノレポのバージョニング問題もあるのですが、このままカレンダー・バージョニングに話を進めます。
カレンダー・バージョニングとは
カレンダー・バージョニングは、その名前のとおり、2026.03.17 のように、リリース日をそのままバージョンとしてしまう手法です。これもあたらしい発明ではなく古典的に用いられてきた手法ではあったりします。YYYY.MM.DD 形式ですね。
カレンダー・バージョニングの最大のメリットは、セマンティック・バージョニングで生じる「リリースしたのいつだっけ問題」が生じないことです。なにしろ日付がそのまま書いてありますから。
ソフトウェアのリリースが数ヶ月に一度、数週間に一度の頻度であった時代は、年月、年月日までの指定でなんら問題なかったのですが、1日に何度もリリースをするというのが現代のソフトウェア開発です。そのような場合、末尾に数値を増やし、同日のリリース回数で数値をインクリメントします。
こんな感じです :
2026.03.17.02（3月17日の2回目のリリース）
APIの互換性を重視する公開ライブラリの場合、セマンティック・バージョニングを採用したほうがよいと思います。カレンダー・バージョニングをオススメする範囲は、自社アプリとして完結しているリポジトリであったり、公開範囲が限定的な共有ライブラリである場合を前提としています。
モノレポとバージョニング
本連載の1回目でモノレポに触れたのですが、モノレポの場合、単一のリポジトリに複数のアプリやライブラリが混在することになるので、リポジトリ全体のリリースバージョンと個別のバージョンを一致させる、ということができません。
Takahiro Ikeuchi
AIコーディングエージェントに多くのコンテクストを渡すためにモノレポがいいよという話をしました。これは弊アプリ・クロノックの例なのですが、以下の方針で運用しています。
- カレンダー・バージョニングを採用
- リポジトリとして同日何回目のリリースかによって、末尾のバージョン
2026.03.17.02でいうところの02を決める - 変更が含まれる範囲の
package.jsonのみバージョンを更新する。package.json 中のバージョンの不揃いはありえる - GitHubのタグ付けは都度行う
ルールが面倒に思うかも知れませんが、エージェントスキルを用意しておけばリリース作業はAIがやってくれるため人間が手作業でやることは特にないです。
モノレポのバージョニング戦略として、他の選択肢としては、admin-app-1.2.3 のようになんらかのprefixをつけて運用する方法もあるようです。例えば複数のnpmライブラリをモノレポで管理しているTanStack/routerのリポジトリでは、次のようなバージョニング規則で運営されているようです。
- @tanstack/solid-start-server@1.166.12
- @tanstack/solid-start-client@2.0.0-alpha.3
これはこれで分かりやすく、プラクティスのひとつと言えそうです。prefixとカレンダー・バージョニングを組み合わせるパターンもありそうですね。
今回のまとめ
- セマンティック・バージョニングはよいものだが、カレンダー・バージョニングという方法もある
- カレンダー・バージョニングはリリース日とバージョンが一致するため、（何を認知したいかにもよるが）認知負荷が低い
- モノレポのバージョニング戦略は決定打はないが、カレンダー・バージョニングやprefix方式（またはその複合など）で運用ができる
AIにコードを書かせる時代、簡単な修正だと少数のチームでも1日に何度もリリースできるようになっているので、リリース作業にまつわる人間の認知負荷を軽減させることが大事になります。
ということで、カレンダー・バージョニングの紹介でした。