文書のバージョン名を決める：最終版をいくつも作らないためのルール

ファイルの順番を当てるゲーム

架空の会議文書4件を、日付の新しいものから選んでください。日付が同じ場合は、v01よりv02を先に選びます。実際のファイルを開いたり整理したりするゲームではありません。

YYYY-MM-DDと2桁のバージョン番号を使う、この例だけに適用するルールです。日付が新しいというだけで、承認済みの最終文書になるわけではありません。

フォルダーに「報告書 最終」「報告書 最終2」「報告書 本当の最終」が一緒にあると、最も新しいファイルを選んでも、どの内容が承認されたのか分かりにくくなります。保存時刻が遅いことと、承認された内容であることは別です。文書のバージョン管理は、名前を長く付ける技術というより、変更の順序と状態を分けるためのルールです。この記事では、個人の作業や小規模な共同作業で使えるルールの例を提案し、クラウドのバージョン履歴とファイル名の役割も説明します。

1. 文書の識別情報、バージョン、状態を分けて考える

文書の識別情報とは、どの業務のどの文書なのかを示すものです。バージョンは内容がどの順番で変わったかを示し、状態は下書きなのか、レビュー中なのか、承認済みなのかを示します。ファイルの更新時刻は保存した時点です。この4つを「最終」という一語で代用すると、異なる情報が混ざります。名前には短い識別情報を含め、変更理由や承認記録は別の履歴に残す方法のほうが管理しやすくなります。

米国国立公文書記録管理局のNARAによるファイル名のガイドは、一貫した構成、意味のある名前、日付やバージョンなどの位置を決める原則を示しています。この記事のルールは、その原則を個人の文書作業に応用した例です。米国政府の記録に関する技術指針が、韓国のすべての個人ファイルに義務として適用されるという意味ではありません。会社の文書管理規程や共同作業システムがある場合は、まずそのルールを確認し、個人のルールをそれに合わせる必要があります。

2. まず1行で表せる命名ルールを決める

説明用の名前は、YYYYMMDD_문서명_vNNN_상태.확장자という形で作れます。この例では、日付を「文書の対象となる業務の日付」と定めます。最後に保存した日付を入れる方法も可能ですが、2つの意味を混ぜないことが大切です。文書名には作業を識別する短い語を使い、バージョンには3桁の数字を使います。状態は、まずdraft・review・approvedの3種類から始めます。

20261010_report_v001_draft.docx
20261010_report_v002_review.docx
20261010_report_v003_approved.docx

上の名前は、架空の報告書ファイルの例です。v003に承認済みという名前を付けても、誰かが実際に承認した事実が生まれるわけではありません。承認記録と名前が一致するように管理する必要があります。拡張子はプログラムが扱う実際のファイル形式と結び付いているため、名前を整理する際に勝手に変更しません。DOCXをPDFに変換するには、そのプログラムのエクスポート機能で実際にその形式を作る必要があります。

構成要素	ルールの例	混同を減らせる理由
日付	業務の基準日 YYYYMMDD	業務の日付と保存日を混ぜない
文書名	reportなど、一貫した識別語	同じ文書のファイルをまとめて見つけられる
バージョン	v001, v002, v003	数字の桁数をそろえて順番を読み取る
状態	draft, review, approved	内容変更の順序と承認の有無を分ける
拡張子	実際の形式 .docx, .pdf	名前の変更と形式の変換を区別する

3. どのような変更でバージョンを上げるか決める

この例では、他の人に新しい内容を伝える変更が生じたら、バージョン番号を1つ上げます。例えば、v001の下書きに表の項目を追加し、説明を修正してレビューを依頼したらv002になります。単にファイルを開いて閉じたり、保存だけを行ったりした場合に、業務上のバージョンを必ず上げる必要はありません。逆に、数字や結論が変わった場合は、文字数が少なくても重要な変更になり得ます。判断基準は変更量ではなく、受け取る人が新しい内容として区別する必要があるかどうかです。

バージョン番号を上げない小さな修正もあり得ますが、その基準について合意しておく必要があります。例えば、共有前の個人の下書きの誤字は同じバージョン内で直し、レビュー依頼後の内容修正は新しいバージョンにする、と決められます。これは普遍的な標準ではなく、作業に合わせた選択です。「内容を変更したのに同じ名前で上書きしてよいか」を先に決めておくと、共有後の混乱を減らせます。

メジャー・マイナー番号が必ず必要なわけでもありません。細かいルールを決めずにv1.2.3のような複雑な数字から使い始めると、人によって番号を上げる基準が異なることがあります。小規模な作業なら、v001から順番に上げて変更履歴を残す方法で十分な場合があります。作業規模が大きくなり、別のルールが必要になった時点で、番号の意味を拡張してください。番号そのものが品質の点数や承認の順位を示すわけではありません。

4. レビューと承認の状態を実際の記録に結び付ける

draftは作成中、reviewはレビューを依頼した状態、approvedは定められた承認手続きを終えた状態、と定義できます。大切なのは、その定義が実際の作業と一致することです。レビュー担当者が意見を残したからといって、すべてが承認されたわけではありません。また、承認後に内容を修正した場合、再度のレビューが必要かどうかを決める必要があります。承認済みファイルを修正しながら、名前だけをapprovedのままにしておくと、受け取る人が承認範囲を誤解する可能性があります。

説明用の流れは「v001の下書きを作成 → v002のレビューを依頼 → 意見を反映してv003を承認」です。実際にはv002の内容のまま承認された場合、名前の状態だけを変え、同じ内容であることを記録に残す方法も可能です。どの方法を選んでも、内容の変更と状態の変更を区別してください。必ずバージョンを上げる方法と、状態だけを更新する方法が混在すると、番号の意味を理解しにくくなります。

承認記録には、対象バージョン、確認した人または手続き、日付、残っている条件などを記載できます。個人の文書なら「提出前の確認完了」のように、実際に行った状態を書けばよいでしょう。会社の文書で承認を受けていないのに、自分だけでapprovedという名前を付けてはいけません。名前は状態を示す表示であり、その状態が実際に成立したことを確認できる根拠は、履歴や共同作業システムに残す必要があります。

5. 変更履歴は1行ずつでも十分に役立つ

ファイル内の最初のページや別の一覧に、「バージョン・日付・変更内容・状態」を記録します。例えば「v002, 2026-10-10, 比較表に条件列を追加, レビュー依頼」と書けば、なぜ番号が変わったのか分かります。「複数箇所を修正」より、どの部分の意味が変わったのかを書くほうがよいでしょう。すべての文章の差分を履歴にコピーする必要はありませんが、結論や主要な数値の変更は漏らさないようにします。

複数の人からレビューの意見が届いた場合は、まず基準となるファイルのバージョンを確認してください。v001に付いた意見をv003に適用するときは、既に反映されているか、新しい内容と矛盾しないかを確認します。「最新版にすべて貼り付ける」だけでは、古い表現が再び入ったり、表の条件が元に戻ったりすることがあります。変更履歴は、どの意見をどのバージョンに反映したかを追跡するためにも使えます。

複数のファイルの内容が異なる場合、更新時刻だけで直ちにどれを採用するか決めてはいけません。各ファイルの履歴と実際の差分を比較し、必要な変更を1つの基準版にまとめてから、新しいバージョンとして保存します。レビュー前のコピーは残しておいてください。基準版を決めたら、現在の作業場所を1か所に集約し、以前のファイルは別の保管場所に置くと、検索結果から両方を選んでしまうことを減らせます。

6. クラウドのバージョン履歴は命名ルールを補完する

Microsoftは、OneDriveやSharePointに保存したファイルのバージョン履歴を確認し、以前のバージョンを復元する機能を案内しています。Web上で対象ファイルのメニューや右クリックメニューにあるバージョン履歴を開くと、以前の項目を確認できます。学校や会社のアカウントでは管理者が機能を無効にしている場合があり、実際に利用できる履歴の範囲は環境に応じて確認する必要があります。すべてのローカルファイルに、自動的に同じ履歴が作られるわけではありません。

復元する際は、まず対象ファイルとバージョンの内容を確認してください。公式の案内によると、選択した以前のバージョンが現在のバージョンになり、それまでの現在のバージョンは履歴の以前の項目として残る仕組みです。共同作業中なら、他の人が現在の内容を見ている可能性があるため、基準版を元に戻すことを共有する必要があります。重要な変更を保全する必要がある場合は、復元前に現在の内容を別のコピーとして残す方法を検討できます。

クラウド内部のバージョンと、ファイル名に付ける業務上のバージョンは、同じ番号体系ではない場合があります。プログラムの自動保存によって履歴が何度も作られていても、業務上のレビュー依頼は1回だけということがあります。逆に、ファイルを新しい名前でコピーした場合は、以前のファイルの履歴をそのまま引き継いで見る方法とは異なることがあります。内部履歴は復旧や変更の追跡に、業務上のバージョン名は共有や承認状態の区別に使う、といった役割を定めてください。

7. 配布版と編集版を同じバージョンに結び付ける

承認済みのDOCXをPDFにエクスポートした場合は、名前の日付、バージョン、状態をそろえられます。架空の20261010_report_v003_approved.docxと20261010_report_v003_approved.pdfが同じ承認内容を示すように管理します。ただし、名前が同じというだけでは、実際の内容が同じである証拠にはなりません。PDFを作成したら、ページの欠落、表の切れ、フォント、リンクなど、配布に必要な項目を確認する必要があります。

PDFを作成した後にDOCXの内容を再び変更した場合は、PDFも新しい基準版から作り直す必要があります。古いPDFを同じ名前で渡すと、編集版と配布版の対応関係が失われます。履歴にはエクスポートの基準となったバージョンを記載し、渡すファイルを別の配布場所に集める方法を使えます。バージョン名の目的は、この対応関係を人が素早く確認できるようにすることです。

共有する際は、「最終ファイルを添付」とだけ書くよりも、文書名、バージョン、状態を一緒に記載してください。「報告書v003の承認済みPDFをお送りします。以前のv002のレビュー版は使用しません」のように、具体的に案内できます。共有リンクを使う場合も、どの基準版を指しているか確認します。リンク先が内容の変わり続ける作業ファイルなのか、提出用に固定したファイルなのかを区別すると、受け取る人の期待が明確になります。

8. ルールを複雑にしすぎないためのチェックリスト

• ファイルの日付が何を意味するか、1つに定めたか？
• 同じ文書に同じ識別語を使っているか？
• バージョン番号の桁数をそろえたか？
• 内容の変更とレビュー・承認の状態を区別したか？
• 共有後の変更では新しい基準版を残しているか？
• 変更理由と承認範囲が履歴に記載されているか？
• 編集版とPDFの基準バージョンが対応しているか？
• クラウドで復元する対象と現在の作業版を確認したか？

最初からすべての情報をファイル名に入れようとすると、名前を読んだり維持したりするのが難しくなります。短い識別情報は名前に、詳しい理由と承認記録は履歴に置いてください。1行のルールと4項目の履歴だけでも、「本当の最終」を何度も付け足す状況から抜け出せます。大切なのは長い名前ではなく、チームや将来の自分が同じ基準版を選べる一貫性です。

公式情報源と執筆方針

• NARA：ファイル名を決める基本原則
• NARA：一貫したファイル名の構成に関する案内
• Microsoft：OneDriveファイルの以前のバージョンの復元

資料確認日：2026-10-10。実際に開いて確認した公式資料に基づき、AIが作成した説明です。別途示した計算・コード・確認の事例は説明用であり、ユーザー環境で直接試験した結果や実測値ではありません。公開日には、機能や資料に変更がないかを再確認します。