verはversion（バージョン）、revはrevision（リビジョン）の略で、どちらも文書や製品の版を区別するために使われます。
verは版や状態、revは改訂の段階を表す場面でよく見かけますが、「大きな変更ならver、小さな変更ならrev」という共通規則はありません。
仕事で迷ったときは、その製品・職場の番号の付け方と、今回使ってよい承認済みの版を先に確かめます。
数字が大きいファイルを選ぶだけでは、編集中の案を正式版と取り違えることがあるためです。
この記事では、ソフトウェア、図面、業務文書での違いを具体例で説明します。
すでにあるファイルを読む場合と、これから管理ルールを作る場合を分けると、表記の意味を実際の判断へつなげやすくなります。
revとverは何が違う？まず「何の番号か」を見る
| 表記 | 基本の意味 | 使われる例 | 番号だけでは分からないこと |
|---|---|---|---|
| ver／Ver. | version。ある時点の版・状態 | アプリのVer1.2.3、マニュアルのVer2.0 | 変更の規模、互換性、承認状態 |
| rev／Rev. | revision。改訂の段階・識別 | 図面のRevB、文書のRev03、機器の基板改訂 | 変更内容、最初の番号、通算の修正回数 |
たとえば「図面A RevB」は、図面Aのどの改訂を指すかを区別する表示です。
そのBが寸法変更なのか、注記の修正なのかは、図面の改訂履歴を読まなければ分かりません。
Rev03も、必ず「作成後に3回だけ修正した」という意味ではなく、その組織で定めた改訂記号として読みます。
一方、ソフトのVer2.0は版を示しますが、その数字だけで「大幅に機能が増えた」とまでは決められません。
番号の意味を定めた仕様や、公開時に変更点を説明するリリースノートと組み合わせて初めて、何が変わったか判断できます。
英語の意味からrevとverの傾向を知ることは役立ちます。
ただし、実際にファイルを使う場面では、一般的な言葉の意味よりも、そのファイルに適用される管理ルールが優先されます。
ソフトウェアでは、小さな修正もversionで表せます
1.0.0の数字には、採用したルールが必要です
ソフトウェアの版の付け方の一つに、Semantic Versioning（セマンティック バージョニング、SemVer）があります。
公開API、つまり外部のプログラムが利用する機能や呼び出し方を定め、その互換性を基準に「メジャー.マイナー.パッチ」の3つの数字を使う方式です。
| 変更の例 | SemVerを採用した場合の例 | 数字を変える理由 |
|---|---|---|
| 互換性を保った不具合修正 | 1.0.0 → 1.0.1 | パッチを増やします |
| 互換性を保った機能追加 | 1.0.1 → 1.1.0 | マイナーを増やし、パッチを0に戻します |
| 公開APIの互換性がない変更 | 1.1.0 → 2.0.0 | メジャーを増やし、残りを0に戻します |
この方式では、誤りを直す小さな変更もversionの一部です。
「軽微な変更だからRev1にする」と置き換えると、利用者が期待する番号の読み方と食い違います。
また、Ver2.4.1のような3つの数字を見たからといって、その製品がSemVerに従っているとは限りません。
互換性が重要なライブラリの更新なら、提供元の番号規則と変更履歴を読み、既存の呼び出し方を変える必要があるかまで調べます。
0から始まる版と、数字の比較で気をつけること
SemVerの0.y.zは初期開発を表し、公開APIは安定しているとは扱いません。
1.0.0は公開APIを定義する版です。
したがって「どのソフトも最初はVer1.0」「0は正式な番号ではない」とは言えません。
数字の各部分は小数ではありません。
SemVerなら1.9.0より1.10.0が後です。
ファイル名を文字列として並べた順序と、版の大小が一致しないこともあるので、ダウンロード画面や変更履歴の掲載順も併せて見てください。
revisionがversionの中に含まれる仕組みもあります
.NETのSystem.Versionでは、Major、Minor、Build、Revisionという構成要素を使えます。
MajorとMinorが必要で、BuildとRevisionは任意の要素です。
これは.NETの仕組みの説明で、すべての製品の番号が4つに分かれるという意味ではありません。
この例からも、versionとrevisionを完全に別のものとして二者択一にする必要はないと分かります。
自分が扱うソフトの仕様にrevisionという項目があれば、その項目の意味に従ってください。
近い言葉のreleaseは公開・提供されたものを扱う文脈で、editionは用途や構成の異なる版を区別する文脈で使われます。
これらも製品ごとの名称を読み、単に「新旧の順番」を示す番号と混同しないようにします。
図面のrevは、変更履歴と使用可能な状態を一緒に読む
図面では、同じ図面番号の中で改訂を区別するためにRevを使うことがあります。
RevA、RevBのようなアルファベット、Rev01、Rev02のような数字など、表し方は運用によって異なります。
Autodesk Fusionの改訂履歴表でも、文字、数字、カスタムの番号方式を選べます。
図面のRev欄だけで判断せず、図面番号、対象の部品や製品、改訂内容、承認・発行の状態を合わせて読みます。
別の図面のRevCとRevBを比較しても、どちらが新しいかを決める材料にはなりません。
たとえば、同じ部品のRevBが製造用として承認され、RevCは検討中という場合、実際の製造に使うのは指定されたRevBです。
これは説明のための例ですが、「番号が進んでいること」と「今使うことが許されていること」を分ける必要がある場面を示しています。
取引先から届いた図面の改訂記号を、自社の付け方に合わせて勝手に変更しないでください。
図面番号と改訂記号の組が相手の記録と一致しなくなるためです。
不明なら、発行元や図面管理担当へ、対象の図面番号と手元のRevを伝え、今回使用する版を照会します。
機器のRevと、ソフトのVerは別々に合わせます
ハードウェアのRevは、同じ型名の中の基板などの改訂を指す場合があります。
GIGABYTEの案内では、マザーボードの基板に「REV: 1.0」のような番号が印刷されています。
こうした機器のドライバーやBIOSを探す場合は、型名だけでなく、製品の改訂とメーカーが示す対象を合わせます。
「ソフトのVerが新しいから、どのRevの機器にも使える」とは限りません。
表示場所が分からなければ、その機種の説明書やサポートを使い、番号を読むためだけに無理な分解をしないことも大切です。
文書では、版番号と日付と履歴の役割を分ける
マニュアルや業務資料にVerを使うかRevを使うかは、所属先の規程や管理システムに合わせます。
どちらの表記も使えますが、同じ文書の途中で役割を決めずに混ぜると、並べたときに関係が分からなくなります。
たとえば、同じマニュアルに「Ver3」「Rev3」「最新版」「最終修正版」が並んでいたら、名前だけで正式版を選べません。
最初に管理台帳や共有先の正式版を探し、分からなければ管理担当へ問い合わせます。
既存のファイル名を一斉に変えて解決しようとせず、対応関係を確認することから始めます。
新しくファイル名を決める場合の例
次は、番号の付け方を説明するための運用例です。
文書の大きな改定と小さな修正の区別を採用する場合も、その基準を職場で決めておきます。
ソフトウェア向けのSemVerが、文書にも自動的に適用されるわけではありません。
- 版で管理する文書：sales_manual_Ver1.0.pdf → sales_manual_Ver1.1.pdf → sales_manual_Ver2.0.pdf
- 改訂番号で管理する図面：drawing_A_Rev01.pdf → drawing_A_Rev02.pdf → drawing_A_Rev03.pdf
- 配布した日も区別したい文書：manual_Ver1.3_2026-10-31.docx
ファイル名の日付は、作成日、改訂日、配布日のどれを表すかを決めます。
日付が新しいだけでは、内容や承認状態が新しいとは限りません。
また、Rev01のようなゼロ埋めは図面ファイルを一定の桁で並べる運用例であり、SemVerの数字へ先頭の0を付ける説明ではありません。
「最新版」は次の版ができると意味が変わり、「最終2」は元の最終との関係が伝わりにくくなります。
版番号を一つに決め、変更した箇所と理由を履歴へ残すと、受け取った人が内容を確かめられます。
Ver2.0とRev03を併記してよい場合
外部へ配布する版をVer、社内で追跡する改訂をRevとして「Ver2.0／Rev03」のように併記する方法も考えられます。
ただし、これは役割を分けた運用例であり、一般に義務づけられた書式ではありません。
併記するなら、何を変更したときにどちらを増やすか、外部配布時に内部のRevをどう扱うか、履歴の保管先まで決めます。
一つの番号で必要な追跡ができるなら、二つに増やす必要はありません。
OneDriveなどの履歴があるなら、名前だけで管理しない
OneDriveやSharePointに保存したファイルは、利用環境の設定により、バージョン履歴から以前の内容を確認・復元できます。
この履歴と、配布資料に印字する版番号は別の役割です。
保存するたびに履歴が増えても、その都度、社外向けの版を発行したとは限りません。
まず履歴を残す場所を共有先にそろえ、正式に配布した版と変更の内容がたどれるようにします。
システムの履歴とファイル名の連番を二重に増やす前に、何を区別したいのかを確かめると、管理する番号を減らせます。
以前の版を戻すときは、復元した後まで見る
- OneDriveのWeb画面で対象ファイルを選び、右クリックして「バージョン履歴」を開きます。
- 変更日時などを手掛かりに戻したい版を特定します。
必要なら内容を確認し、現在の作業を残す必要がないか共同編集者とも調整します。 - 対象の版の「…」から「復元」を選びます。
- ファイルを開き直して、戻したかった本文や表が現在の版になったか確かめます。
誤った版を選んだ場合は、履歴を開き直し、復元前に現在だった版を選んで戻します。
復元では、選んだ過去の内容が現在の版になり、それまでの現在の版は履歴に残ります。
ただし、職場・学校のアカウントでは管理者がバージョン管理を無効にしている場合があります。
履歴がない、必要な版が残っていない、操作権限がない場合は、管理者や文書の所有者へ相談してください。
迷った場面での判断順と、確認に使える文例
手元の番号を読むときは、次の順で対象を絞ります。
全部を新しく決め直すのではなく、すでにある規則を見つけるための順序です。
- ソフト、図面、文書、機器のどの番号なのかを特定します。
- 製品の仕様、社内規程、図面の改訂履歴、管理システムの説明を探します。
- 同じ対象の番号かを合わせ、変更内容と承認・配布状態を読みます。
- 使う版が決まらなければ、発行元や管理担当に今回の用途を伝えて確認します。
- 受け取った版の番号と中身を照合し、作業者や共有先も同じ版を使う状態にします。
たとえば「図面番号A-001のRevBとRevCがあります。
今回の製造には、承認済みのどちらの版を使いますか。
使用版と、適用開始日をご教示ください」と伝えれば、単に「最新版をください」よりも確認する対象が明確になります。
番号と用途は実際の内容に置き換えます。
これからルールを作る側なら、開始番号、番号を進める条件、変更履歴の場所、承認者、旧版の保管方法を決めます。
古い版を使わせないための管理と、過去の内容を追跡するための保存は両方必要なので、削除することだけを解決策にしないでください。
まとめ
verは版・状態、revは改訂を表す場面で使われますが、大きい変更と小さい変更を一律に分ける印ではありません。
ソフトの番号規則、図面の改訂履歴、文書の管理ルールによって意味が決まります。
いま使うファイルに迷ったら、番号の大小より先に、同じ対象か、何が変わったか、今回使える承認済みの版かを確かめます。
その確認先と履歴を共有しておけば、次に受け取る人も同じ版を選べます。
関連記事
- メールに添付ファイルがないときの返信例文｜取引先へ角を立てず再送を頼む書き方：必要な資料が届かない場合や別のファイルが届いた場合に、対象を明確にして再送を頼む文例を紹介します。
参考資料
- Semantic Versioning 2.0.0 日本語仕様：公開APIと互換性、メジャー・マイナー・パッチ、初期開発版の意味を確認しました。
- Microsoft Learn「System.Version」：versionの構成要素にRevisionが含まれる.NETの例を確認しました。
- Autodesk Fusion「Create a revision history table」：図面の改訂履歴表と番号方式を確認しました。
- GIGABYTE「同じモデルの異なるリビジョンの見分け方」：基板に記載された改訂番号の例を確認しました。
- Microsoft「OneDriveに保存されているファイルの以前のバージョンを復元する」：履歴からの復元操作と、管理者設定による条件を確認しました。
