メインコンテンツにスキップ
自媒科技企業向けAI・開発から導入まで
日本語JA
プロジェクト相談

企業AIプロジェクトWiki · 環境・バージョン・リリース

バージョン番号

別名Version number · ソフトウェアバージョン · 版番号 · Version identifier

定義

バージョン番号とは、変化する対象の特定状態を区別、参照、順序付け、他状態と関連付けるため、合意された規則に従って付与する識別子です。有効な案件バージョン番号は、明確な対象と変更記録へ遡れなければなりません。同じ番号が別内容を指したり、番号変更と対象を結び付けられなければ、配備、検収、Rollback、障害調査を支える識別子ではなく表示文字にすぎません。

バージョン番号は品質判定ではなく識別子

顧客の不具合報告、テスト結果、Pipeline配備、運用Rollbackが同じ対象を参照できるよう、「どの状態か」を答えるものです。安定した識別子がなければ「最新版」は時刻、環境、話者により別内容になります。

大きい数字は安定、安全、検収済みを証明しません。`2.0.0`が未試験候補で、`1.8.12`が本番稼働版の場合もあります。公開、検収、本番状態には別の試験、承認、配備証拠が必要です。

意味はVersion Policyから生まれます。同じ`X.Y.Z`でも、一方は公開API互換性のSemantic Versioning、他方は社内Milestoneかもしれません。形だけで変更規模を推定できません。

主なVersion方式

Semantic Versioning

公開APIを宣言した上で`MAJOR.MINOR.PATCH`を使い、非互換API変更、後方互換機能、後方互換修正を表します。Pre-release識別子と、優先順位に影響しないBuild Metadataも定義します。

連番Release

`v17`や`release-42`は順序が明確ですが、互換性や変更種類は表さないためChange Logが必要です。

Calendar/Cycle Version

`2026.08`のように年、月、四半期、Iterationを表します。公開時期は伝えても互換性は示さず、Backportや同期間の複数Build規則が別途必要です。

Platform固有Version

Major、Minor、Build、Revisionの四部構成などがあります。.NETにはPackage、Assembly、File、Informational Versionがあり、利用者とRuntimeへの効果が異なります。

Pre-release

`alpha`、`beta`、`rc.1`は通常版前を示します。SemVerでは同じ三部番号の通常版より優先順位が低く、案件は進入可能な環境も定義します。

Product/Composite Version

顧客向け製品版は複数Componentを代表できますが、Frontend、Backend、DB、Model、設定の実版へ対応するManifestが必要です。

他の識別子が証明するもの

識別子分かること/分からないこと
バージョン番号宣言規則に沿って状態を呼び分けます。対象へBindingされて初めて具体内容を証明します。
Build番号CI/CDの一回のBuildやPipeline実行を区別します。一つの製品Versionに複数Buildがあり得ます。
Git Commit ID不変なSource Commitと履歴を識別しますが、Build環境、依存解決、設定、DB、外部Modelまでは含みません。
Artifact DigestBinary、Image、Manifestが同一Byte内容か検証します。人には読みにくく、業務互換性は表しません。
Tag/Alias`latest`、`stable`、`production`のような可動参照です。移動後は別対象を指すため、単独では履歴証拠になりません。
Release日/名称外部公開EventやMarketing名です。複数Versionを含むことも、BuildされたVersionが公開されないこともあります。

実行可能なVersion Policyに必要な事項

  1. Version対象は何か

    製品、Service、API、DB Schema、設定Package、App、Modelのどれかを明記し、Lifecycleが違う対象へ無理に同じ番号を付けません。

    記録:対象、Owner、保管先、適用範囲。

  2. 書式と増分の意味は何か

    Field、文字、順序、Major/Minor/PatchまたはCalendarの意味、Zero版、Branch、緊急修正を定義します。

    記録:有効・無効例付きPolicy。

  3. いつ付与・固定するか

    開発中、候補、検収、正式公開で番号を作る時点と、内容変更時の新番号要否を決めます。

    記録:生成Event、Freeze Gate、変更規則。

  4. 不変対象へどうBindingするか

    Source Commit、Build Run、Lockfile、Artifact URI・Digest、DB Migration、設定Baselineを結び付けます。

    記録:機械可読Version/Release Manifest。

  5. 互換性とSupportをどう表すか

    API、Format、Client互換を約束するなら、対象面、廃止期間、Upgrade経路、Support期限を定義します。

    記録:互換表、Breaking Change、Support Policy。

  6. 誰が正式版・Aliasを変更できるか

    正式版作成、Tag再設定、Artifact上書き、`stable`移動を制限し監査します。

    記録:Repository保護、署名、承認、Tag Log。

  7. 利用者がどこで確認するか

    画面、API、Log、Health Endpoint、Support資料から十分な版情報を確認でき、機密内部情報は露出させません。

    記録:版確認・問い合わせ手順。

案件での使い方

  1. 製品・Component層を決める

    顧客向け製品版と、独立追跡するApp、Service、DB、設定、Contentを決めます。

  2. 対応表を自動生成

    Build時にVersion、Commit、Build番号、依存、Digestを書き込み、文書への手コピーを避けます。

  3. 同一Artifactを昇格

    テスト、UAT、ステージング、本番へ同じ不変Artifactを進めます。再Buildなら表示Versionが同じでも新Build・Digestにします。

  4. 試験証拠をBinding

    Case、不具合、性能、安全Scan、受入判断へVersion、Build、環境を記録し、修正後は新対象として再テストします。

  5. 配備状態をBinding

    環境ごとに製品・Component版、時刻、実施者、設定、Migration、Digestを保存します。

  6. Rollback対象を保持

    旧Artifact、設定、Migration互換条件、復旧説明を保持します。番号だけで内容を再取得できない状態を避けます。

企業AIに複合Version Manifestが必要な理由

Application・Orchestration

Frontend、Backend、Workflow、Agent Graph、Tool定義、業務規則を記録します。Tool引数やOrchestrationだけでも結果は変わります。

Model Version/Snapshot

Provider、Model ID、固定Snapshot/Registry版、Region、Deployment名を記録します。`latest`、`default`、`stable`は可動のため、その時点の具体版も保存します。

Prompt・Safety Policy

System Prompt、Template、Output Schema、Filter、Guardrail、人の承認規則を個別にVersion管理します。

Knowledge・Retrieval

Source Batch、権限Snapshot、清掃、Chunk、Embedding Model、Index Build、Retrieval、Rerankingを記録します。File名やIndex名だけでは再現できません。

評価Set・Scorer

Sample、正解、Rubric、評価者Calibration、自動Judgeも変化します。System版と評価版の両方を結果へ付けます。

外部Service・実行設定

Model Parameter、Tool API版、第三者規則、Feature Flag、重要環境設定を含めます。固定不能な托管依存は観測時刻、変更方針、再評価Triggerを記録します。

バージョン番号と混同しやすい概念

関連概念違い
Version対象の具体的状態です。Version番号はその状態へ付与する識別子で、Versionには内容とMetadataも含まれます。
BuildSourceと依存からArtifactを作る過程・結果です。同じ表示Versionでも再試行、Platform、依存差で別Buildになります。
Release特定Versionを利用者へ提供する業務・技術Eventです。番号があっても公開済みとは限りません。
検収版正式な受入対象に指定された完全Baselineです。番号は一つの識別子で、単独では検収範囲を定義できません。
本番版本番で実際に稼働する対象です。数値順ではなく配備状態から確認します。
Change LogVersion間で何を、なぜ変更し、何に影響するかを説明します。番号は参照点だけです。

出典と適用範囲

本項目は、Software、Service、設定など変化する対象の状態を識別するバージョン番号を説明します。全案件にSemantic Versioningを要求せず、Build番号、Release日、Git Commit、Artifact Digest、Tag、Release名、検収版、現在の本番版と同一視しません。書式と増分の意味は、Teamが規則を宣言し一貫して運用した場合にだけ成立します。