契約ひな形に
バージョン番号と改訂履歴を付ける方法

契約ひな形と周辺用語

契約ひな形とは、NDA、業務委託契約、売買契約、ライセンス契約、共同開発契約、利用規約、覚書、注文書約款など、反復利用される契約文書の標準様式です。最終的に相手方と締結される個別契約そのものではなく、個別契約を作成するための社内標準文書として扱います。

次の比較表は、契約ひな形を3種類に分け、それぞれの管理上の注意点を整理したものです。種類ごとに旧版誤使用、専門レビュー、派生関係のリスクが異なるため、自社のひな形を分類してから管理項目を決めることが重要です。読者は、どの種類が最も多く、どこに重点管理を置くべきかを読み取ってください。

バージョン番号は契約ひな形の版を識別する番号です。例として、v1.0.0、v2.1、2026.05.01、JP-NDA-B2B-v3.2.1があります。改訂履歴は、変更後の版番、改訂日または施行日、変更者、承認者、変更箇所、変更理由、影響範囲、置き換え対象の旧版、関連資料やチケット番号などを記録した表またはログです。

リリースは、契約ひな形を社内で正式に利用可能な状態にすることです。草案作成、コメント、外部専門家の確認はまだリリースではありません。リリースには、承認、公開、周知、旧版の廃止または利用制限が含まれます。

旧版は、単に削除する対象ではありません。過去の契約審査、交渉方針、締結済み契約の背景を説明する証跡になり得るため、廃止済み、非推奨、限定利用可などの状態を付けて、誤使用を防ぎながら保存します。正本管理場所は、組織内で唯一の正本として扱う管理場所であり、事業部門のローカルPCやメール添付を正本にしないことが重要です。

法的・制度的な位置づけ

次の比較表は、契約ひな形の版管理が、契約成立、文書管理、内部統制、情報システム統制、公的文書管理の考え方とどのように関係するかを整理したものです。各根拠は直接の義務だけを意味するのではなく、実務設計の参照軸になります。読者は、契約の有効性と、後日の説明・監査可能性を分けて把握してください。

契約ひな形の管理では、誰が閲覧できるか、誰が編集できるか、誰が承認できるか、変更ログが残るか、旧版を復元できるか、承認前の草案が誤って利用されないか、異動者や退職者の権限が削除されているか、重要変更時に関係部門へ通知されるかを確認します。

契約ひな形では、ソフトウェア開発の考え方をそのまま導入する必要はありません。ただし、MAJOR.MINOR.PATCHの3区分は、変更の重大性を番号で表すために有用です。次の比較表は、どの変更で番号を上げるかを示し、誤字修正とリスク配分変更を同じ扱いにしないための基準になります。

番号の例は、v1.0.0を初版、v1.1.0を個人情報委託条項の選択肢追加、v1.1.1を誤記および条番号修正、v2.0.0を損害賠償責任制限条項の基本方針変更といった形で整理できます。

法改正や年度運用が重要な企業では、日付型も有効です。2026.05.01、2026.05.01-1、2026.05.01-approvedのようにリリース時期が分かります。ただし、日付だけでは変更の重大性が分かりにくいため、重要ひな形ではJP-NDA-B2B-MUTUAL_v2.1.0_2026-05-01_approvedのように、ID、意味を持つ版番、日付、状態を組み合わせます。

次の判断の流れは、変更内容を見たときにMAJOR、MINOR、PATCH、または正式版番を上げない作業ファイルに分ける考え方を示します。分岐は権利義務やリスクへの影響を中心に読むと、形式的な修正に大きな承認を求め過ぎる一方で重要変更を軽く扱う失敗を避けられます。

バージョン番号を上げないことがある作業

検討中のコメントを追加しただけ、内部レビュー用の一時メモを入れただけ、既存版を案件用に個別修正しただけ、相手方修正案との比較ファイルを作っただけの場合は、正式な契約ひな形の版番を上げないことがあります。ただし、正式版ファイルそのものに手を入れるなら、軽微でもPATCHを上げるのが原則です。

版番はファイル名だけに置くのではなく、本文、文書プロパティ、台帳、必要に応じてフッターにも残します。次の一覧は、運用媒体ごとの入れ方と注意点をまとめたものです。媒体ごとの読み取り方を押さえると、社内検索と相手方提示の両方で情報漏えいを防ぎやすくなります。

本文冒頭の記載例

秘密保持契約書（双方向・国内B2B）
テンプレートID ― JP-NDA-B2B-MUTUAL
バージョン ― v2.1.0
ステータス ― Approved
施行日 ― 2026-05-01
文書オーナー ― 法務部 契約法務チーム
承認者 ― ゼネラルカウンセル
置換対象 ― v2.0.0
次回レビュー期限 ― 2027-05-01
利用対象 ― 国内B2B案件。消費者向け、海外案件、個人情報処理を主目的とする案件には別ひな形を使用。

YAMLフロントマターの例

テキスト形式やナレッジベースで管理する場合は、YAMLフロントマターを使うと検索や自動処理に使いやすくなります。項目名を統一しておくことで、台帳、CLM、文書管理システムとの突合もしやすくなります。

template_id: JP-NDA-B2B-MUTUAL
template_name: 秘密保持契約書（双方向・国内B2B）
version: 2.1.0
status: approved
effective_date: 2026-05-01
owner: 法務部 契約法務チーム
approved_by:
  - ゼネラルカウンセル
  - 個人情報保護責任者
supersedes: 2.0.0
next_review_due: 2027-05-01
risk_level: medium
jurisdiction: Japan
language: ja

ひな形の改訂履歴と、個別契約の交渉履歴は分けます。たとえばJP-NDA-B2B-MUTUAL v2.1.0からA社向けNDAを作り、交渉で損害賠償条項を変えた場合、その変更は直ちに標準ひな形の改訂ではありません。標準ひな形として反映する意思決定がある場合に限り、次のv2.2.0またはv3.0.0として改訂します。

契約ひな形の改訂理由は、契約類型によって大きく異なります。次の一覧は、代表的な契約類型ごとに、どの条項が版管理上の重点になるかを整理したものです。読者は、自社でよく使う契約類型に近い項目から、MAJOR変更になりやすい論点を読み取ってください。

NDAのテンプレートIDは、たとえばJP-NDA-B2B-MUTUAL、JP-NDA-B2B-ONEWAY-DISCLOSER、JP-NDA-B2B-ONEWAY-RECIPIENTのように分けます。英文契約では、JP-MSA-SERVICES-CUSTOMER_v2.0.0、EN-MSA-SERVICES-CUSTOMER_v2.0.0、US-MSA-SERVICES-CUSTOMER_v1.3.0、SG-MSA-SERVICES-CUSTOMER_v1.2.0のように、言語・国別版の関係を台帳上で追えるようにします。

既存ひな形を移行する際は、いきなりファイル名を変えるのではなく、社内に散在するファイルを棚卸しして正本を決めます。次の時系列は、移行作業の順番を示しています。各段階で、正本以外をどう扱うか、事業部門へ何を伝えるかを読み取ってください。

次の比較表は、改訂後に旧版を使えるかどうかの移行ルール例です。旧版を全面禁止するだけでは進行中案件が混乱することがあるため、相手方提示の有無、交渉段階、法令違反リスクの有無で対応を分けて読み取ります。

旧版を例外的に使う場合は、案件名、取引先、使用する旧版、旧版利用理由、新版との差異、リスク評価、承認者、承認日、有効期限を記録します。これにより、旧版利用が統制外の抜け道ではなく、例外として管理されます。

プレイブック・代替条項との連携

契約ひな形だけを改訂しても、交渉現場で使うプレイブック、FAQ、チェックリスト、研修資料、代替条項が古いままでは統制が崩れます。たとえば、JP-NDA-B2B-MUTUAL プレイブック v1.4.0をJP-NDA-B2B-MUTUAL v2.1.0に対応させます。代替条項もALT-NDA-TERM-001 v1.0やALT-LIABILITY-CAP-001 v2.0のようにIDと版番を付けます。

次の比較表は、契約ひな形の運用を測るKPIです。導入して終わりではなく、旧版利用、未使用、改訂速度、レビュー遵守、逸脱承認、差戻し、監査指摘、利用者評価を追うことで、リスク低減と事業スピードの両方を読み取れます。

Q1. 契約ひな形にバージョン番号がないと、契約は無効になりますか。

一般的には、契約ひな形にバージョン番号がないこと自体が契約の無効原因になるわけではないとされています。ただし、契約類型、締結方法、証拠関係、社内規程、電子契約の利用状況によって説明上の重要性は変わります。具体的な契約の有効性や証拠関係は、資料を整理したうえで弁護士等の専門家へ相談する必要があります。

Q2. 改訂履歴は契約書の本文に残すべきですか。

一般的には、社内管理用の契約ひな形には残す運用が有用とされています。ただし、相手方に提示する契約ドラフトや締結版に社内用履歴を残すと、内部事情や交渉方針が露出する可能性があります。具体的な開示範囲は、契約類型、交渉状況、情報管理方針により変わるため、専門家や関係部門と確認する必要があります。

Q3. Wordの変更履歴機能だけで足りますか。

一般的には、Wordの変更履歴は特定ドラフト内の編集差分を確認する補助機能と位置づけられます。正式な版番、承認、施行日、旧版の扱い、変更理由、影響範囲を体系的に管理するには、改訂履歴台帳と承認手順を併用する必要があります。具体的な管理水準は、ひな形の重要度や監査要件によって変わります。

Q4. v1.0とv1.0.0のどちらがよいですか。

一般的には、厳密な運用ではv1.0.0のようにMAJOR、MINOR、PATCHの3区分を使う方法が分かりやすいとされています。小規模企業ではv1.0でも運用可能な場合がありますが、将来の拡張性や変更理由の説明性を考えると、3区分の採用を検討する価値があります。

Q5. 日付だけのバージョンでよいですか。

一般的には、日付型だけでも運用できる場合があります。ただし、日付だけでは変更の重大性が分かりにくいことがあります。重要契約ひな形では、v2.1.0_2026-05-01のように、意味を持つ番号と日付を併用する設計が候補になります。具体的には、法改正対応の頻度や社内検索の方法に応じて検討します。

Q6. 旧版はいつまで保存すべきですか。

一般的には、契約類型、関連法令、訴訟リスク、監査要件、社内規程により保存期間は変わります。少なくとも、そのひな形から作成された契約が存続し、紛争や監査で参照される可能性がある期間は保存を検討します。具体的には、文書管理規程、契約管理規程、税務・会計文書の保存ルール、訴訟ホールドの有無と整合させる必要があります。

Q7. 外部専門家が作ったひな形にも社内バージョンを付けるべきですか。

一般的には、社外で作成されたひな形でも、社内でいつ承認し、いつから利用し、どの旧版を置き換えたかは会社側で管理する必要があります。作成日や助言内容は重要ですが、社内標準としての利用開始・承認・旧版処理は別の記録として残すことが望ましいとされています。

Q8. 改訂履歴を監査役や内部監査に見せる必要がありますか。

一般的には、会社の統制設計によって範囲は変わりますが、重要契約ひな形については内部監査や監査役が運用状況を確認できる状態が望ましいとされています。上場会社、上場準備会社、規制業種、個人情報や知財を多く扱う会社では、契約ひな形の統制が確認対象になり得ます。具体的な開示範囲は社内規程と監査計画に沿って整理します。

法令・公的資料

• e-Gov法令検索「民法」
• e-Gov法令検索「民事訴訟法」
• e-Gov法令検索「電子署名及び認証業務に関する法律」
• デジタル庁「電子署名」
• 金融庁「財務報告に係る内部統制の評価及び監査の基準並びに実施基準の改訂について」
• 内閣府「行政文書の管理に関するガイドライン」

記録管理・システム統制・版管理

• ISO 15489-1 Information and documentation ― Records management
• NIST SP 800-53 Rev. 5 Security and Privacy Controls for Information Systems and Organizations
• Semantic Versioning 2.0.0
• Calendar Versioning
• Git Documentation「git-tag」