---
type: guideline
title: 第1章 なぜテキストを正本とするのか
source: デジタル庁
profile: mrlgss-doc/0.1
category: data-interop
status: draft
updated: 2026-06-16
---

# 第1章 なぜテキストを正本とするのか

## 1.1 正本（しょうほん）とは何か

本書でいう**正本**とは、「複数の表現形（PDF・HTML・Word・告示・データベース定義等）のうち、相互に
食い違いが生じたときに最終的に正しいとみなす、唯一の権威ある表現」をいう。

現状、標準仕様書の正本は Word／Excel ファイルであり、掲載用の Markdown／PDF はその派生物である。
本書が提案するのは、この関係を逆転し、**テキスト（Markdown／YAML）を正本とし、Word・PDF・告示・
データベース定義をそこからの派生物（projection）とする**ことである。

## 1.2 テキストを正本とする利点

1. **差分とレビューが仕様の改訂プロセスになる**。Git の行単位差分で「どの規定がどう変わったか」が
   機械的に追える。Word の変更履歴や Excel のセル比較に頼らず、プルリクエストでレビューできる。
2. **人・AI・プログラムが等価に扱える**。同じファイルを、人間は読み、AI は検索・要約し、プログラムは
   パースして型定義・告示・帳票を生成できる。変換の往復で情報が失われない。
3. **構造と意味を明示できる**。型・桁数・コード参照・出力条件・上位規範への根拠といった、Word／Excel
   では暗黙だった情報を、機械可読な形で本文に埋め込める（第5章・第6章）。
4. **正本性を検証できる**。テキストであれば、適合性（スキーマ適合）・トレーサビリティ（参照解決）・
   告示との byte 一致を CI で機械検証できる（第9章）。

## 1.3 「機械可読」の三層モデル

本書のフォーマットは、1 つのファイルの中に表現力の異なる三層を同居させる。

| 層 | 表現するもの | 担い手 | 主な読み手 |
|---|---|---|---|
| 索引層 | 文書の種別・識別子・タイトル・上位規範への参照 | frontmatter（YAML） | 検索・RAG・カタログ |
| 知識層 | 規定の趣旨・解説・図表・規範文 | Markdown 本文 | 人間・AI |
| 正本層 | 型付きの厳密なデータ（項目・コード・条件） | payload（```yaml``` フェンス） | プログラム |

索引層だけを持つ「軽い」文書（解説・ガイドライン本文）と、正本層まで持つ「重い」文書（データリスト・
連携仕様・コード一覧）が、同じディレクトリに共存する。文書の性格に応じてどの層まで書くかを選ぶ
（第3章・第5章）。

## 1.4 適用範囲

本書は次のいずれの文書にも適用できる。

- **規範文書**（Normative）: 標準仕様書本体、データ要件・連携要件、コード一覧、帳票要件、告示・省令。
- **参考文書**（Informative）: 解説書、実践ガイドブック、技術レポート、用語集。

規範文書は正本層（payload）と規範文の byte 保持（第4章）が要となり、参考文書は索引層＋知識層で足りる。
本書自体は参考文書（実は Normative な記述規約）であり、payload を持たず索引層＋知識層で書かれている。

## 1.5 実例

本書は全編にわたり、**住民記録システム標準仕様（業務コード 001）**を実例として参照する。住民記録は
機能要件（仕様書本文）・データ要件（基本データリスト 1027 項目）・連携要件（機能別連携仕様 23 連携）・
文字要件（行政事務標準文字）の四要件がそろった、本書フォーマットの完全な適用例である。