ADR-0010: プロセスデータと規程本文の正本を要素ごとに分担し結合点を識別子に限定する

ステータス

採用(2026-08-05)

コンテキスト

src/data/processes/integrated.yaml とフェーズ4の本文には、同じ事実が2か所に存在する。

重複する内容	データ側	本文側
ゲートの判定基準	gates[].criteria	第4章の判定チェックリスト
ゲートの承認者	gates[].approver	第4章の見出し
ロールの責務	roles[].responsibility	第3章の任命基準・RACI
成果物の説明	workProducts[].description	第6章の様式

どちらが正本かが定義されていないため、片方だけを更新すると乖離が発生する。今後も両者への追記が続くため、先に結合の規則を決める必要がある。

なお「同じ事実を1か所にしか書かない」構成は、本プロジェクトでは成立しない。データは構造を表現し、本文は判断の根拠を表現しており、両者に必要な粒度が異なる。

決定

1. 要素ごとに正本を定める。重複そのものは許容し、更新時にどちらへ書くかを一意にする
   • 要素の存在・識別子・関係(フェーズ、ゲート、ロール、成果物、タスク、順序、参照関係)の正本は integrated.yaml
   • 判定基準の内容・閾値・期限・様式・例外の扱いの正本はフェーズ4の各章
   • 用語の定義の正本は第1章 1.4
2. 結合点を識別子に限定する。本文からデータを参照する場合は id(例: g-ship)またはラベル(例: G-7)を用い、名称や説明文の一致を前提としない。ラベルと id の対応は gates[].label が唯一の翻訳層である
3. データから本文への参照はスラッグまでとし、見出しアンカーへ張らない。見出しは改訂で変わるため、アンカー参照は壊れやすい
4. データ側の判定基準に閾値・数値・期限を書かない。これらは組織ごとに変わるため、本文およびテーラリング規則が保持する
5. 構造の変更はデータから行う。データ変更 → npm run check → 本文更新の順とし、逆順を禁止する。本文が先行すると、データに存在しない要素が標準として流通する
6. ロールおよび成果物にも href を設ける。ゲートには既に存在したため、要素間で表現を揃え、データから所管の章へ到達できるようにする

検討した選択肢

• データから本文を生成する — 乖離は原理的に消えるが、判断の根拠・背景・例外の記述は構造化に馴染まず、生成された文書は規程として読めない。API 仕様からリファレンスを生成する構成とは要件が異なる
• 本文から重複を削除しデータへの参照のみとする — 本文が読めなくなる。監査時に提出するのは本文であり、単独で理解できる必要がある
• 正本を本文に一本化しデータを廃止する — プロセス提案ツール(M7)がデータを前提としており、ADR-0007・ADR-0008 の決定と矛盾する

影響

• 更新の判断が機械的になる。構造を変えるならデータ、基準を変えるなら本文
• ラベル体系(G-1〜G-8)の変更は gates[].label の更新を伴う。マクロライフサイクルの設計でラベル体系を見直す場合、この対応表が変更の起点になる
• 識別子参照の整合検査(activities[].roles が実在する roles[].id を指すか、本文のラベルがデータに存在するか)は未実装であり、フェーズ5の CI 設計で扱う
• スキーマは schemaVersion: 0 のまま。追加した href は任意項目であり後方互換である
• 調査根拠は research/phase4-standard/098-data-doc-interface.md に記録した