ADR-0048: ドキュメントインベントリ管理・カバレッジ追跡方針の再起案（ADR-0046 を退役して再構成 + パイプライン投入テスト題材化）

• Status: Accepted
• Mode: Standard
• Kruchten Type: Property/Executive
• Scope: platform
• Implementation Status: In Progress
• Supersedes: ADR-0046
• 起案者: [email protected]
• 起案日時 (JST): 2026-05-16
• 承認日時 (JST): 2026-06-21
• Deciders: [email protected] (単独)

本 ADR の位置付け: ADR-0046 を Supersede 退役して再起案する。決定内容そのもの (5 施策) は引き継ぎ、PR #771 の差し戻し対応 (数値根拠 / 評価軸 6 軸 / 撤退手順表 / 工数以外コスト) を本文に取り込んだ統合版とする。加えて本 ADR は body-generation プロンプトパイプライン (ADR-0042 lifecycle) のテーブル簡略化テスト題材を兼ねる。詳細は §9 パイプライン投入テスト計画。

決定の早わかり（Y-statement）

本節は ADR-0140 の touch-time 運用により 2026-06-12 の改訂 (決定②・ADR-0145 による正式改訂) と同一 PR で追加された本文の要約で、新しい意味は加えていない (意思決定内容は本文が正)。「文脈で問題に直面し、対抗案でなくこの案を選び、目的のため代償を受け入れる」と読む。詳細はコンテキスト以降の本文に展開する。

• 文脈: ADR-0045 で docs/_internal/ のディレクトリ構造と frontmatter 基本方針を確立した。docs/ 配下には 412 本のファイルがあり、nav 未登録の orphan が 19 本蓄積していた。
• 問題: 「どのドキュメントがどこにあるか分からない」(発見可能性) と「書いたつもりで書いていない」(カバレッジギャップ) の 2 問題が未解決。Claude Code が中身のないスタブを実在の内容として扱う幻覚リスクも未対処だった。
• 問題点と課題（直せる原因 → 発生を止めるためにやること）:
  • nav 登録漏れを機械検出する仕組みがない → orphan 検出スクリプトを新設し CI に組み込む。
  • status 値域が暫定で運用ルールが未定義 → 5 値に確定し全 docs ファイルへ適用する。
  • 意図的な未記録と偶発的な未記録を区別できない → known-unknowns 一覧 (COVERAGE_GAPS.md) を新設して可視化する。
• 前提（解決を課題に立てない与件）: ソロ〜2 人体制の低コスト運用 (週 60 分以内)。_config.json の nav 配列を SSOT として維持する。
• 決定（対応策）: MkDocs --strict 移行 (案 B)・Obsidian (案 C)・現状維持 (案 D) でなく、案 A = 5 施策 (① status 5 値確定 ② COVERAGE_GAPS.md 新設 ③ nav 検証スクリプト + CI ④ CLAUDE.md status 規約 ⑤ PR テンプレのドキュメント確認チェックボックス) を 3 Phase で段階導入する。
• 目的: orphan 0 の常時維持と known-unknowns の可視化により、ドキュメントの発見可能性と AI 幻覚抑止を確立する。
• 代償: 既存 412 本への frontmatter バルク付与 (約 1h + 200K tokens)・例外リスト管理の継続コスト・ADR 二重メタ管理の lint 依存。
• 決定②の改訂: known-unknowns の SSOT は 2026-06-12 に ADR-0145 で TODO_future.md へ移った (詳細は決定②の改訂注記)。
• 詳細は本文の影響・撤退条件セクションを参照のこと

1. コンテキスト

1.1 背景 (Background)

ADR-0045 で docs/_internal/ のディレクトリ構造（番号付きサブディレクトリ）と YAML frontmatter の基本方針（type/status/audience 必須）を確立した。しかし以下の 2 問題が未解決のまま残っている。

問題①（発見可能性）: 「どのドキュメントがどこにあるかわからない」。現在 _config.json の nav 配列がインベントリとして機能しているが、nav 登録漏れ（orphan ファイル）をシステム的に検出する仕組みがない。

問題②（カバレッジギャップ）: 「書いたつもりで書いていない」。会話の中で口頭決定したこと、検討途中で保留になったことが文書化されず、後から「あれどこに書いてあったっけ？→書いてなかった」が繰り返し発生。意図的な未記録（口頭で済む些末事項）と偶発的な未記録の区別ができていない。

また、ADR-0045 が規定した status フィールドの値域は暫定的であり、実用的な最小値域と各値の運用ルールが未定義だった。さらに Claude Code が「未着手ドキュメント」を読んだとき、その内容を存在するものとして扱ってしまう（幻覚）リスクが未対処だった。

1.2 現状 (Current State / As-Is)

• docs/ 配下に 412 本のファイルが存在する (うち nav 登録 388 本 / orphan 19 本: daily_log 9 / templates 4 / ADR-0009 関連 2 / トップレベル 3 / その他 1)。
• frontmatter を持つファイルは現時点でほぼゼロ。
• _config.json の nav 配列が事実上の唯一のインベントリだが、nav 未登録を検出する CI がなく、orphan ファイルが蓄積している。
• ADR-0045 は status フィールドを必須化したが、値域（planned / draft / active / deprecated / superseded）の定義と運用ルールが本 ADR まで defer されていた。
• COVERAGE_GAPS.md に相当するファイルが存在せず、「意図的な未記録」と「偶発的な未記録」が区別できない。
• CLAUDE.md の status 言及がなく、Claude Code は status: planned のスタブファイルの内容を捏造するリスクがある。
• 未記録事例 (体感値): 直近 1 ヶ月のソロ開発で「未記録だった」が週 1〜2 回発生。Claude 幻覚事象は直近 1 ヶ月で planned スタブ内容を「存在する」と誤認した観測 2 件。いずれも客観計測ベースライン未整備のため起案者体感値であり、Phase 1 完了後に観測ログを開始する。

1.3 課題 (Problem)

1. orphan ファイルの蓄積: nav に登録されないファイルがサイレントに増え、静的サイトビルドでもエージェント検索でも到達できない。現在 19 本が蓄積。
2. スタブ墓場化: スタブを作ったまま放置すると、あたかもコンテンツが存在するかのように見える誤解を生む。
3. カバレッジ不可視: 「書いていないこと」が明示されないため、ユーザーが Claude Code に質問したとき幻覚回答が発生する。
4. status 値域の曖昧さ: active vs stable、deprecated vs archived の使い分けが不明確で誤運用が発生しやすい。

1.4 制約・要件 (Constraints & Requirements)

• ソロ〜2 人体制で継続可能な低コスト運用に限定する（週 60 分以上のランニングコストは不可、撤退判定は月 90 分超 × 3 ヶ月連続）。
• ADR-0045 の frontmatter 基本方針（type/status/audience 必須）と整合すること。
• _config.json の nav 配列を引き続き「唯一の真実（Single Source of Truth）」として使用する（bizlp の静的サイトビルドは scripts/docs-build.mjs が _config.json を読むため）。
• CI（GitHub Actions）への依存は最小限にとどめ、まず「COVERAGE_GAPS.md 手動管理 + 月次目視棚卸し」で運用し、必要に応じて CI 自動化を追加する（段階的導入）。
• CLAUDE.md は 200 行以内（Anthropic 公式推奨）を維持すること。status 規約の追加は既存行を圧縮して吸収する。

1.5 目標 (Goals / To-Be)

• _config.json orphan 検出スクリプトを CI に追加し、nav 未登録ファイル = 0 を常時維持。
• status 5 値の定義と運用ルールを確定し、全 docs/ ファイルに適用（移行は AI 活用で実施）。
• docs/COVERAGE_GAPS.md を新設し、「意図的な未記録」と「偶発的な未記録」を区別する。
• CLAUDE.md に status 規約と AI-first nav 読み取り順序を追記し、Claude Code が status: planned を「未着手」として認識できるようにする。
• status: planned のまま 30 日超のスタブを検出する CI スクリプトを追加し、スタブ墓場化を抑止する。
• Pull Request テンプレートにドキュメント更新確認のチェックボックスを追加し、実装変更時のドキュメント更新漏れをレビュー時に検出する。

Non-Goals: mkdocs --strict への移行（bizlp は独自ビルドを使用）、MkDocs / Docusaurus への移行、GitBook 導入、ADR 以外のドキュメントへの supersededBy 強制。

2. 判断基準 (Decision Drivers)

評価軸 6 軸 (PR #771 差し戻し対応で明示化):

3. 検討した代替案 (Considered Options)

3.1 案 A: 本案 (5 施策 + COVERAGE_GAPS.md 手動管理 + 段階的 CI 導入)

• Good, because _config.json 直接検証で orphan 検出精度が高い (C1 ◎)
• Good, because status: planned 規約で Claude の幻覚を抑止できる (C2 ◎)
• Good, because Phase 分割で月 60 分以内に収まる (C3 ◎)
• Good, because 既存 scripts/docs-build.mjs を非破壊で利用できる (C4 ◎)
• Bad, because 例外リスト管理 (research_prompts/*.md 等) が継続的に発生し、肥大化リスクがある (C6 △)
• Bad, because frontmatter SSOT (冒頭メタ) と frontmatter ミラーの二重管理が adr-lint.mjs 同期チェックに依存する

3.2 案 B: MkDocs 移行 + --strict

• Good, because --strict で orphan / broken link が確実に検出される (C1 ◎ / C2 ◎)
• Bad, because bizlp は独自の scripts/docs-build.mjs + Cloudflare Pages を使用しており、ビルドパイプライン全体の刷新が必要 (C4 ×)
• Bad, because 移行コストが大きく、ソロ運用の月 60 分制約を超える (C3 △)
• Bad, because 段階的導入が困難 (一括移行) (C5 ×)

3.3 案 C: Obsidian グラフビューによる可視化

• Good, because グラフビューで構造を直感的に把握できる
• Bad, because エディタ依存で CLI 作業時・CI では機能しない (C1 △ / C4 △)
• Bad, because Claude Code はグラフビューを持たないため AI 幻覚抑止に寄与しない (C2 △)
• Bad, because Obsidian 導入・習慣化コストが発生 (C3 △)

3.4 案 D: 現状維持

• Good, because 追加コストゼロ (C3 ◎)
• Bad, because orphan ファイル (現在 19 本) が蓄積し続ける (C1 ×)
• Bad, because Claude Code の幻覚リスクが増大する (C2 ×)
• Bad, because 「書いていないこと」が永遠に明示化されない (問題② 未解決)

3.5 案 E: GPT 提案の _manifest.yaml 別ファイル管理 — 不採用

• Bad, because _config.json nav という既存 SSOT と二重管理になる (C1 ×)
• Bad, because scripts/docs-build.mjs が _manifest.yaml を読まないため別途同期 CI が必要 (C4 ×)

3.6 案 F: Gemini 提案の docs/archive/ 物理ディレクトリによる旧文書分離 — 不採用 (将来再検討)

• Good, because nav から外しても明示的にアーカイブ済みと示せる (C1 ○)
• Bad, because ADR 100 本未満の現状ではフォルダ移動コストがメリットを上回る (C3 △)
• 再評価トリガー: ADR 通し番号 100 本到達時 / Review After 時に orphan アーカイブ候補 ≥10 本

3.7 軸別評価表

4. 決定 (Decision Outcome)

採用: 案 A (5 施策)。RQ-046 で Claude / GPT / Gemini 3 モデル合意 + bizlp 採択方針 (Synthesis) に基づく。

決定①: status 値域を 5 値に確定する

planned    スタブ。中身がない。作る予定だけある。
draft      書き始めたが未完。レビュー不要。
active     現行ドキュメント。Claude Code が信頼してよい。
deprecated 古い。新規参照非推奨だが履歴として残す。
superseded 完全に置き換えられた。supersededBy フィールドで後継を指す。

ADR ファイルに限り、status: proposed | accepted | rejected も使用可（MADR 4.0 互換）。active の代わりに accepted を使い分ける。archived は当面導入しない（deprecated と運用差がなく、値域が増えると迷いコストが上回る）。

frontmatter スキーマ（全 docs/*.md 共通）:

---
type: adr | spec | runbook | guide | reference | onboarding | research
status: planned | draft | active | deprecated | superseded  # ADRは proposed|accepted|rejected も可
audience: developer | operator | future-self
owner: "@t_saitoh"
created: YYYY-MM-DD
updated: YYYY-MM-DD
supersededBy: ADR-NNNN    # status: superseded のときのみ必須
planned_for: YYYY-MM-DD   # status: planned のときのみ推奨
---

例外: README.md、SUMMARY.md、COVERAGE_GAPS.md、MEMORY.md は frontmatter 不要。

ADR ファイルの二重メタ運用: docs/adr/*.md は冒頭の - **Status**: Proposed 行（MADR 4.0 慣習）を SSOT とし、frontmatter status フィールドはそのミラーとする。両者が不一致のときは冒頭行を正とし、adr-lint.mjs で同期チェックする（ADR-0045 Confirmation 要件に追加）。accepted / active の使い分け: ADR ファイルは accepted、それ以外の docs/*.md は active を使う（MADR 慣習を尊重）。

決定②: COVERAGE_GAPS.md を新設してカバレッジギャップを可視化する

docs/COVERAGE_GAPS.md を「known-unknowns（意図的な未記録）一覧」として維持する。記載内容は:

• 口頭で決まったが文書化されていない事柄
• 検討中・保留中の事柄
• 将来 ADR 化を予定している事柄（ADR 番号予約含む）

Claude Code は本ファイルを参照し、ギャップ事項について質問されたら「文書化されていません。ユーザーに確認してください。」と回答する（幻覚禁止）。

運用パターン（Gemini: Backlog パターン）: CLAUDE.md には COVERAGE_GAPS.md へのポインタ 1 行のみを記述する。ギャップリストの全文は CLAUDE.md に書かず本ファイルで管理する。これにより CLAUDE.md のコンテキスト肥大化を防ぎつつ、Claude Code が必要時に詳細を参照できる構造を維持する。

改訂 (2026-06-12・ADR-0145 による正式改訂・amended_by 辺で宣言済): COVERAGE_GAPS.md は handover 残タスク一覧の自動生成ページへ転用した。これに伴い本決定②の役割は次のとおり変わる:

• known-unknowns (意図的な未記録) の新 SSOT = docs/_internal/02_project/TODO_future.md。記載対象 3 種 (口頭決定・検討中保留・将来 ADR 化予定) は同ファイルの該当節 (§7.2 改善案バックログ等) に DOC-OPS 等の ID 付きで記録する。
• 旧 COVERAGE_GAPS.md の生存項目は転用と同一 PR で DOC-OPS-27 (ADR-0039 残作業) / DOC-OPS-28 (本 ADR Phase 3-4 の fitness function 未実装分) として移送した。
• 旧「Accepted ADR の未着手一覧」節は、ADR INDEX の Status×Impl warn lint (PR #1800) と ADR-0144 実装フォローアップ検知が役割を代替するため廃止した。
• Backlog パターン (ポインタ 1 行参照) は TODO_future.md への参照として維持する。Claude Code の幻覚禁止ルール (ギャップ事項は「文書化されていません」と回答) も移送先で不変。

決定③: _config.json nav 検証スクリプトを導入して orphan を防ぐ

既存の scripts/adr-lint.mjs を docs/_internal/ 対応に拡張する（ADR-0045 の Confirmation 要件）。加えて:

• docs/ 配下の .md ファイルで _config.json の nav に未登録のものを orphan として検出するスクリプト scripts/docs-nav-lint.mjs を新設する。
• CI（GitHub Actions）の docs ジョブに組み込み、orphan 検出時は PR をブロックする（warn ではなく error）。
• 例外リスト: README.md、COVERAGE_GAPS.md、_internal/01_discovery/research_prompts/*.md（研究メモは nav 登録不要）。
• Phase 3 に status: planned のまま 30 日超のスタブを検出する scripts/check_stale_stubs.py を追加する（Claude + Gemini 合意）。検出時は CI warning（error にしない: 計画スタブが即 PR ブロックにならないよう）。

決定④: CLAUDE.md に status 規約を追記する

CLAUDE.md に以下を追加し、Claude Code が文書の状態を正しく認識できるようにする（200 行上限内に収める）:

## Documentation status conventions
**IMPORTANT**: If a doc has `status: planned`, treat its content as nonexistent — do NOT infer or invent.
- `planned`: stub, no content yet → ask the user
- `draft`: partial, verify with user before relying
- `active`: trusted, up-to-date
- `deprecated`: historical context only
- `superseded`: follow `supersededBy` field
Unknown status → ask user. See `docs/COVERAGE_GAPS.md` for known-unknowns list.

AI へのドキュメント提示順序（GPT 提案）: Claude Code が調査を開始する際は、個別ファイルを読む前に必ず _config.json の nav 構造を確認することで、到達可能なドキュメントの全体像を把握してから詳細調査に入る。このパターンにより「存在しないドキュメントへの問い合わせ」が減り、幻覚リスクを軽減する。CLAUDE.md の「Progress tracking」セクションに追記する。

決定⑤: Pull Request テンプレートにドキュメント更新チェックボックスを追加する

.github/PULL_REQUEST_TEMPLATE.md に以下のチェックボックスを追加し、実装変更に伴うドキュメント更新漏れをレビュー時に検出できるようにする（Gemini 提案）:

## ドキュメント確認
- [ ] 関連ドキュメントを更新した、または `status: planned` スタブをコミットした
- [ ] 更新不要の場合はその理由を PR 説明に記載した

このチェックボックスは強制ではなく（CI ブロックしない）、レビュアーへの注意喚起を目的とする。スタブ追加だけでも OK とすることで「とりあえず planned で登録する」習慣を促進し、カバレッジギャップの偶発的な発生を抑制する。

4.1 Phase 構成（段階的導入）

CI 実行コストは GitHub Actions 無料枠 (2,000 分/月) 内で吸収可能。

5. 影響 (Consequences)

5.1 正の影響 (Good)

• Good, because Claude Code が status: planned を認識することで、スタブを「存在するドキュメント」として扱う幻覚を防止できる。
• Good, because COVERAGE_GAPS.md により「意図的な未記録」が明示化され、ユーザーが「書き忘れたのか・意図的か」を区別できる。
• Good, because orphan 検出 CI により、nav 登録漏れによる到達不能ファイル (現在 19 本) の蓄積を防止。
• Good, because frontmatter スキーマの統一により、将来的な「status: planned 30 日超スタブ検出 CI」の実装が容易になる。
• Good, because PR テンプレートのドキュメント確認チェックボックスにより、実装変更時のドキュメント更新漏れをレビュー段階で検出可能になり、偶発的なカバレッジギャップ発生を抑制できる。

5.2 負の影響 (Bad)

• Bad, because 既存 412 本への frontmatter バルク付与 (Phase 2) に約 1 h + Claude 200K tokens の実装コストが発生。誤分類リスクのため事前サンプリング検証が必要。
• Bad, because docs-nav-lint.mjs の例外リスト管理が継続発生 (research_prompts/*.md / daily_log / _meta/templates 等)。肥大化リスクあり。
• Bad, because CLAUDE.md への追記で 6〜8 行を消費。現在の CLAUDE.md 行数によっては既存記述の圧縮が必要。
• Bad, because ADR 冒頭メタ SSOT + frontmatter ミラーの二重管理は adr-lint.mjs 同期チェックに依存し、スクリプト保守自体が将来的な技術的負債となるリスクがある。

5.3 中立 / トレードオフ (Neutral / Trade-offs)

• Neutral, because archived の将来導入: ADR が 100 本を超えた場合や Jr. エンジニア参加後に再検討する。その際は本 ADR を supersede する新 ADR を起案する。
• Neutral, because planned_for フィールドは義務化せず「推奨」とする。スタブの滞留を強制的に管理したい場合のオプト・イン。
• Neutral, because 3 モデル合意の確認: Claude / GPT / Gemini の 3 モデルで調査を実施し Synthesis を作成 (docs/_internal/01_discovery/research_prompts/RQ-046_synthesis.md)。GPT 提案の _manifest.yaml 別ファイル案は bizlp の _config.json アーキテクチャと非整合のため不採用。Gemini 提案の docs/archive/ 物理ディレクトリ分離は将来再検討 (5.3 archived 将来導入と同期)。

Status / Mode / Scope は 2026-06-11 に遡及追加 (ADR-0031 corrigendum パターン)。出典: Status = 旧形式「## ステータス」節の機械転記 / Mode = 旧 README §既存 ADR 一覧の推定値 (git 履歴) / Scope = ADR-0049 4 層分類の遡及付与 (PR レビューで確定)。

6. 撤退条件 / 再評価トリガー (Rollback Plan / More Information)

6.1 撤退判定指標

6.2 施策別撤退手順

6.3 Phase 別撤退コスト

• Phase 1 撤退: 1〜2 h (3 ファイル削除 + CLAUDE.md 巻き戻し)
• Phase 2 撤退: frontmatter 残置・必須化を緩和する新 ADR のみ (412 本のロールバックは行わない / 誤った status 値が残るリスクは緩和 ADR で個別対応)
• Phase 3 撤退: 1 h (CI ジョブから 2 スクリプト削除 + git rm)

6.4 再評価トリガー

• 再評価タイミング: 2026-08-15 (Phase 3 完了から約 2 ヶ月後)
• 判定主体: [email protected]
• 観点: CI orphan 検出の偽陽性件数 / status: planned 30 日超スタブ件数 / COVERAGE_GAPS.md の実際の利用状況 / archived 導入要否 / Jr. 参画想定での運用負荷

7. Confirmation (準拠確認 / Fitness Function)

Review After 2026-08-15 (Phase 3 完了から約 2 ヶ月後):

• CI orphan 検出の偽陽性件数確認
• status: planned 30 日超スタブ件数 (スタブ墓場リスク評価)
• COVERAGE_GAPS.md の実際の利用状況確認
• archived 導入要否の判断

8. 参照 (References)

• 関連 ADR:
  • ADR-0046: 本 ADR が Supersede する旧版 (Proposed 段階で退役)
  • ADR-0045: frontmatter 基本方針の前提
  • ADR-0042: 本 ADR §9 パイプライン投入テストの対象プロンプト管理方針
  • ADR-0039: docs/ 全体構造の前提
  • ADR-0028: ステージ番号整合性
• 関連調査:
  • docs/_internal/01_discovery/research_prompts/RQ-046_result_claude.md
  • docs/_internal/01_discovery/research_prompts/RQ-046_result_gpt.md
  • docs/_internal/01_discovery/research_prompts/RQ-046_result_gemini.md
  • docs/_internal/01_discovery/research_prompts/RQ-046_synthesis.md (Synthesis: 3 モデル合意 + bizlp 採択方針)
• 関連 PR (退役対象):
  • PR #771 (差し戻し対応 — 数値根拠/評価軸/撤退手順/工数以外コスト): 本 ADR §1.2 / §2 / §6 / §4.1 に統合済み
  • PR #772 (v2 差し戻し対応版を ADR-0047 として新規追加): 番号衝突 + 退役で close 予定
  • PR #778 (A/B test baseline v1.0.0、ADR 番号衝突で close 済 / 2026-05-16): §9 パイプラインテストで baseline データを再利用予定
• 外部資料:
  • MADR 4.0: https://adr.github.io/madr/
  • Diátaxis: https://diataxis.fr/
  • Anthropic CLAUDE.md ベストプラクティス (200 行上限)
  • ETH Zurich: "Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?" arXiv:2602.11988 (2026-02-13)

9. パイプライン投入テスト計画 (本 ADR 独自セクション)

本 ADR は意思決定の記録だけでなく、body-generation プロンプトパイプライン (ADR-0042 lifecycle) のテーブル簡略化テスト題材を兼ねる。

9.1 テストの目的

本 ADR 本文には以下の構造化情報が含まれる:

• テーブル 5 つ: §2 評価軸 6 軸 / §3.7 軸別評価表 / §4.1 Phase 構成 / §6.1 撤退判定指標 / §6.2 施策別撤退手順 / §6.3 (実質含む) / §7 Confirmation
• コードブロック 3 つ: §4 決定① status 5 値 / §4 決定① frontmatter スキーマ YAML / §4 決定④ CLAUDE.md 追記 / §4 決定⑤ PR テンプレ追記

パイプラインで再生成した出力でこれらがどれだけ保持されるかを計測する。

9.2 テスト手順

1. 本 ADR-0048 を「人手 baseline」として固定する
2. prompts/production/body-generation/ の v1.0.0 プロンプトに本 ADR の context を投入 → 出力 ADR を prompts-eval/datasets/body-generation/adr-0048-output-v1.0.0.md に保存
3. 同じく v1.0.1 プロンプトに投入 → prompts-eval/datasets/body-generation/adr-0048-output-v1.0.1.md に保存
4. baseline (本 ADR) と各出力で以下を比較:
   • テーブル数の保持率 (5 個 → 何個残ったか)
   • テーブル列数の保持率 (例: §6.1 撤退判定指標 3 列が 2 列に圧縮されていないか)
   • コードブロック数の保持率 (3 個 → 何個残ったか)
   • 箇条書きの bullet 数の保持率 (各セクション内の項目数比較)
5. PR #778 で close 済の 0047-a-b-test-baseline-body-generation-v1-0-0.md (130 行) を「v1.0.0 既存サンプル」として比較データに追加 (ブランチ adr/0047-a-b-test-baseline-body-generation-v1-0-0 に残存)

9.3 合否基準

• ✅ 合格: テーブル数保持率 100% / コードブロック数保持率 100% / テーブル列数欠落 0 件
• ⚠️ 要改善: いずれかの保持率 ≥80% かつ <100% (v1.0.1 で改善試行)
• ❌ 不合格: いずれかの保持率 <80% (パイプライン非経由で本 ADR 草案を直接 Accepted にする)

9.4 テスト結果に基づく後続アクション

• 合格時: 本 ADR-0048 をパイプライン出力で置き換えるかは選択肢を残す。出力比較レポートを prompts-eval/datasets/body-generation/REPORT_adr-0048.md に残し、ADR-0042 prompt lifecycle の運用根拠とする。
• 要改善時: v1.0.1 (#776 で改修中の「表・詳細保持ルール追加」版) の追加改修ポイントを特定し、v1.0.2 起案を検討。
• 不合格時: 本 ADR-0048 草案 (人手版) を Accepted として確定し、当面 ADR 本文生成はパイプライン非経由 (Claude 直書き or 手書き) を継続。プロンプト改修 (v2.0.0) の起案を検討。

9.5 テスト実施スコープ

本 ADR の Accepted 化までに §9.2 ステップ 1〜4 を完了する。テスト結果は本 ADR §9 末尾に追記する形で更新する (誤字修正範疇 / ADR-0031 先例)。