---
type: guideline
title: 第8章 改訂と版管理
source: デジタル庁
profile: mrlgss-doc/0.1
category: data-interop
status: draft
updated: 2026-06-16
---

# 第8章 改訂と版管理

テキストを正本とする最大の実務的利点は、**Git による版管理がそのまま仕様の改訂プロセスになる**こと
である。本章は版・改訂の記載規約を定める。

## 8.1 版は Git とメタデータの二層で持つ

- **Git**: 行単位の改訂履歴・差分・レビュー・分岐は Git が担う。「いつ・誰が・どこを・なぜ変えたか」は
  コミット履歴とプルリクエストに残る。仕様書の改訂作業はプルリクエストのレビューとして行う。
- **メタデータ**: 告示・配布物に印字される正式な版番号は frontmatter の `version`・`spec_date` に持つ。
  Git のコミットハッシュは版番号ではない。両者は役割が異なる（Git＝作業履歴、`version`＝公示版）。

## 8.2 改訂履歴の記載

各文書（特にガイドライン・仕様書）は末尾または index に**改定履歴表**を持つ。原本の改定履歴を踏襲し、
改定年月日・改定箇所・改定内容の 3 列で書く。

| 改定年月日 | 改定箇所 | 改定内容 |
|---|---|---|
| 2025年5月27日 | 第1章3. | セキュリティ・バイ・デザイン実施に関する記載を追加 |

> 改定履歴はあくまで人間可読の要約である。正確な差分は Git が持つので、改定履歴に全変更を網羅させる
> 必要はない。公示・配布の単位で意味のある変更を記載する。

## 8.3 識別子は版をまたいで安定させる

第4章・第6章で述べたとおり、機能 ID・項目 ID・URN・章節番号は参照キーである。改訂で内容が変わっても、
**同一概念の識別子は版をまたいで温存**する。

- 項目を新設するときは新しい ID を採番する。既存 ID を使い回さない。
- 項目を廃止するときも ID を欠番として残し、別の項目に再割り当てしない。
- 版番号（`第2.4版`→`第4.1版`）が変わっても、ファイル名・URL・URN は変えない（第2章 §2.4）。

## 8.4 「変更箇所記載版」の差分は構造化する

原本には改訂の差分を色分け・取消線で示した「変更箇所記載版」がある。テキスト正本では、この差分は
**Git の差分**が担うのが本筋である。さらに意味的な差分（追加・修正・廃止）を明示したい場合は、
項目に `change` のような注記を構造化して持たせることを推奨する（具体的キーは別途定義）。色や取消線の
ような視覚表現を本文に直書きしない。

## 8.5 草案の明示

確定前の文書は frontmatter に `status: draft` を付し、本文冒頭にもドラフトである旨を明記する。
本書（DS 番号未採番、仮置き `ds-4xx`）自体がその例である。確定時に `status` を外し、正式な `ds_code` を採番する。