バージョン付き仕様書の合意版— 台帳に残す欄

1. 「最終」ファイル名が失敗する理由

1-1. 主観ラベルは検索不能

「最終」は作成者の意図であり、相手合意の事実ではありません。
合意版は版番号と合意日の組み合わせでしか一意に決まりません。

1-2. リンク先の上書き

同じURLの上に新版を置く運用は、過去の合意内容を消滅させます。
合意時点のPDFを別ファイルとして固定保存してください。
正本データの考え方は複数ツール併用時の正本データを参照してください。

1-3. 台帳とファイルの不一致

現場はv3で作業しているのに台帳はv1のまま、というズレが支払・検収トラブルの温床です。
台帳更新を版上げの完了条件にします。

2. 台帳に設ける欄（最小セット）

2-1. 必須4欄

「合意版番号」「合意日」「保管パスまたは文書ID」「相手確認手段（メール／署名／チャットPDF）」の4欄を必須にします。
任意欄として「前版番号」「差分要約」があると変更監査が楽になります。

2-2. 版番号の付番規則

`vメジャー.マイナー`（例: v2.1）とし、報酬・納期に影響する変更はメジャー、文言修正はマイナーと定義します。
付番権限は購買または契約管理に限定します。

2-3. 注文書との相互参照

注文書本文に合意版番号を記載し、仕様書表紙に発注番号を記載して双方向参照にします。
3条明示との接続は発注書面の3条明示を確認してください。

3. 合意版を確定するゲート

3-1. 相手確認の証拠

メール返信、電子署名、チャット確認のいずれかが無い版は「作業ドラフト」扱いとします。
チャット確認ならPDF化し5条フォルダへ（保存は5条書類の保存形式）

3-2. 社内承認

メジャー版上げは社内承認後に相手へ送付する順序を守ります。
先に相手へ送り後から社内承認、という逆転を禁止します。

3-3. 電子署名セット

重要案件は注文書＋仕様書合意版を1つの署名パッケージにします。
サービス運用は電子契約サービスへの対応と電子署名と書面交付の証跡を参照してください。

4. 週次・月次の点検

4-1. 空欄抽出

合意版番号または保管パスが空の進行中案件を週次で一覧化します。
発注コンプライアンスのチェックリストに「合意版欄」を追加します。

4-2. パス疎通確認

月次でランダムに10件、保管パスが開けるか・版番号がファイル名と一致するかを確認します。
リンク切れはバックアップ・引き継ぎ手順（発注データのバックアップと引き継ぎ）で是正します。

4-3. 記載事項との突合

合意版の成果物定義が、交付済み書面の記載事項と矛盾していないかを点検します。
記載事項のテンプレートを使って差分を可視化します。

5. FAQ

Q. マイナー修正も相手確認が必要ですか

誤字修正でも検収基準に影響するなら確認を取ります。
影響なしと判断した理由を台帳の差分要約に残します。

Q. Gitで管理している仕様は

コミットハッシュを合意版IDとして台帳に転記し、タグ付けしたスナップショットをPDFまたはアーカイブで保存します。
リポジトリ権限が変わっても読める形を残してください。

Q. チャットだけで版合意した場合は

Slack・Teamsでの発注書面化の手順でPDF化し、合意版欄にパスを入れます。
口頭だけの版指定は口頭・緊急発注の書面化で当日中に文書化します。

6. 具体シナリオ：「最終2」問題

6-1. 事象

デザイナーが `仕様_最終2.pdf` を共有し、エンジニアは古い `仕様_最終.pdf` で実装していました。
検収時に画面項目が足りず、どちらが合意版か説明できない状態になりました。

6-2. 是正

ファイルを `PO-2210_仕様_v2.1_合意20260901.pdf` に改名し、台帳の合意版欄へ転記しました。
相手に「v2.1を合意版とする」メールを送り、確認返信を.eml保存しています。
以後の版上げは承認ゲートなしに共有できないようDrive権限を変更しました。

6-3. 台帳運用の定着

合意版空欄の案件はステータスを「条件未確定」にし、検収依頼ボタンを押せないようにしました。
月次でパス疎通を10件サンプリングし、リンク切れをバックアップ手順で回復しています。
参照:発注データのバックアップと引き継ぎ

6-4. 会話例

QA「最終2と最終、どっちでテストしますか」
購買「台帳の合意版v2.1だけが正です。最終というファイル名は使わないでください」
主観ラベルを禁止し、台帳の版番号だけを通すと混線が止まります。

7. 週次オペレーションと命名規則の強制

ファイル名に「最終」「latest」「new」を含むアップロードを拒否する運用（または発見時の即リネーム）を導入します。
週次で合意版空欄・パス空欄を抽出し、空欄のまま検収依頼が出ていないかを確認します。
メジャー版上げのたびに、注文書側の版参照文も更新されているかを差分チェックします。
Git管理案件はタグ名と台帳の合意版IDの対応表をINDEXに残し、リポジトリ権限変更後も読めるアーカイブを併置します。
相手確認がチャットだけの場合はSlack・Teamsでの発注書面化でPDF化し、確認手段欄に「chat-pdf」と記入します。
口頭で版を指定された場合は当日中に文書化し、口頭・緊急発注の書面化のチェックを通します。
合意版欄は「任意の便利欄」ではなく、検収・支払の前提条件である、と経理向け説明会で共有してください。

8. 合意版IDの読み方を統一する

台帳の合意版番号は「相手が確認した版」だけを入れ、社内レビュー中の版はドラフト欄かコメントに分離します。
読み手が迷わないよう、画面ヘルプに「合意版＝対外確認済み。ドラフトは作業用」と一行で書きます。
検収・支払・監査の担当者が同じ定義を共有できて初めて、版管理が機能します。
定義が部署ごとに違う場合は、最初に用語集で揃えてから欄を増やしてください。

現場への一言

版番号はファイル名の飾りではなく、検収と支払の前提条件です。
合意版欄が空のまま作業が進む組織は、必ずどこかで衝突します。
空欄を止めるゲートを先に置き、その後で便利な共有を許してください。
合意版のパス疎通確認を月次10件やるコストは、検収やり直し1件よりはるかに小さいです。
『最終』というファイル名を見つけたら、その日のうちに合意版IDへリネームする係を決めておきます。
ドラフトと合意版を同じフォルダに置くなら、ファイル名プレフィックスで必ず分けます。
版上げ承認ログが無い共有は、合意版として扱わないでください。
用語が揃うまで欄を増やさない、が混乱を防ぎます。

まとめ

• 「最終」ファイル名をやめ版番号＋合意日で一意化
• 台帳に合意版番号・合意日・パス・確認手段を必須化
• 相手確認が無い版はドラフト扱い
• 週次で空欄、月次でパス疎通を点検

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク（torikaku） の機能説明を含みますが、法的助言ではありません。
個別の契約内容・取引実態については専門家にご確認ください。