← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 18:56
commonid: adr-0163type: adrstatus: proposed
pagemode: Standardkruchten: Executive/Propertyscope: platformimplementation_status: Not Startedproposed_at: 2026-06-22 12:59approved_at: -approver_role: platformapprover_who: [email protected]driver: [email protected]consulted: Decision Pipeline AI 審査 (Gate 0-4)business: drpreview_after: 2026-09-22
型付き辺: 出 11 / 入 0
関連: ADR-0030 ADR-0032 ADR-0049 ADR-0107 ADR-0137 ADR-0144 ADR-0149 ADR-0156 ADR-0159 ADR-0162 ADR-0164全体は INDEX →

ADR-0163: ADR の事業軸ドメイン分類基準 4 種 (Corp/MAS/DRP/Meta) を明文化する

  • Status: Proposed
  • Mode: Standard
  • Kruchten Type: Executive/Property
  • Scope: platform
  • Implementation Status: Not Started
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-06-22 12:59
  • 承認日時 (JST): -
  • Approver Role: platform
  • Approver Who: [email protected]
  • Driver: [email protected]
  • Consulted: Decision Pipeline AI 審査 (Gate 0-4)

コンテキスト

§1.1 背景

ADR の事業軸ドメイン (Corp/MAS/DRP/Meta) は 2026-06-12 の内容ベース分類導入 (scripts/lib/business.mjs による nav→ドメイン fallback) 以降、frontmatter business を原本としつつ、ドメイン定義そのものが ADR で明文化されていない。起案者の暗黙判断と nav 推定の合議で決まっており、再現性が担保されていない。

§1.2 現状 (As-Is)

  • 全 161 本中 business: corp が 68 本存在し、サンプル 25 本目視で 24 本 (96%) が「ADR/docs 制度系」=メタ軸相当と判定された
  • DRP の決定 (Pipeline 挙動を変える) が business: corp のまま残っている例が INDEX.md 上で複数観測される
  • ADR 制度・docs サイト基盤を改善する ADR (ADR-0030, ADR-0032, ADR-0107, ADR-0137, ADR-0144, ADR-0149, ADR-0162 等) が「事業判断」と同じ corp ドメインに混在している
  • doc クローンと drp クローンの担当境界 (workspace_rules.md) と分類が連動していない

§1.3 課題

  • 起案時に「これは Corp か DRP か」を起案者が毎回判断するため再現性が低く、PR レビュー時のオーナーシップが不明瞭
  • 経営者が事業 ADR だけを抽出しにくい (Corp が実質「経営判断」と「メタ運営」の混在状態)
  • 同じ判断ばらつきが新規 ADR でも再発する構造

§1.4 制約・要件

  • frontmatter business を一次原本とする現行運用は維持 (破壊的変更を避ける)
  • ドメイン SSoT は本 ADR (定義) + scripts/lib/business.mjs (コード) の 2 か所に集約
  • 5 クローン体制 (doc/mas/ocr/drp/main) での並行起案で drift しない仕組みが必要
  • 全 161 本の棚卸し PR を 1 回で実施 (差分テーブルベース)
  • 経営者向け早わかり (ADR-0107) の読み分け軸との整合を保つ

§1.5 目標 (To-Be)

4 ドメイン (Corp/MAS/DRP/Meta) の定義・境界判定ルール・拡張基準・クローンとの関係・SSoT 同時更新手順を ADR で明文化し、棚卸し PR で全 ADR の business を一巡させる。Non-Goals: ドメインの自動分類 (LLM)・track キー追加 (案 Y)・新ドメイン即時切り出しは本 ADR の範囲外。

決定

ADR (Standard) として 4 ドメイン (DRP / MAS / Corp / Meta) の定義・境界判定ルール・拡張基準・クローンとの 2 軸独立関係・SSoT 同時更新手順を明文化する。frontmatter business を一次原本としつつ、business.mjs を fallback とする現行運用を維持。Meta ドメイン定義にはサブカテゴリ (meta-infra / meta-governance) と「経営者レビュー必須フラグ」を併記する。境界判定ルールには tie-break 手順と NG 例 3 件以上を含め、SSoT drift と分類ばらつきを CI で検知する仕組みを完了条件に含める。

判断基準 (Decision Drivers)

3.1 評価軸

#軸重要度 (係数)案件特有の解釈
1#maintainable[Must] (×2.0)起案者が毎回ばらつきなく分類でき、定義が長期に保守可能か
2#suitable[Must] (×2.0)経営者向け早わかり (ADR-0107) と PR オーナーシップの両方に適合するか
3#operable[High] (×1.0)SSoT 2 か所の drift を CI で検知でき、棚卸し運用が回るか
4#flexible[High] (×1.0)新ドメイン (例: 将来の OCR / PPT 自動生成) 追加に耐えるか
5#efficient[Medium] (×0.5)棚卸し・運用コストが許容範囲か

K.O. criterion: Must 軸 (#maintainable / #suitable) の score < 3 は不採用。

3.2 評価軸 × 案スコア表

軸係数採択案 (4 ドメイン明文化)案 B (棚卸しのみ)案 C (分類廃止)案 D (LLM 自動)案 Y (track キー追加)
#maintainable (×2.0)2.042224
#suitable (×2.0)2.042134
#operable (×1.0)1.043423
#flexible (×1.0)1.042134
#efficient (×0.5)0.534522
加重和 (正規化)0.7860.4430.4140.5000.757
K.O. 通過 (Must ≥3)✓❌❌❌✓

採択案と案 Y が K.O. 通過。差分は 0.029 で僅差だが、案 Y はコード変更が広範 (frontmatter スキーマ拡張 + adr-index.mjs 2 列化 + business.mjs 拡張) かつ即時の filter 拡張ニーズが顕在化していないため、本案 (Meta を business 値集合に追加する 1 キー方式) を採用。案 Y は撤退条件発火時の有力候補として記録する。

検討した代替案 (Alternatives Considered)

  • 案 B (棚卸しのみ・基準明文化なし): business.mjs の nav→ドメインマッピングを改善して再分類する — 基準が暗黙のまま新規 ADR で同じばらつきが再発する。Must 軸 #maintainable=2 で K.O.
  • 案 C (ドメイン分類自体を廃止): INDEX.md のドメイン列を削除し nav グループだけで分類 — ADR-0107 経営者向け早わかりの読み分け軸を失う。PR オーナーシップ判断軸も消失。
  • 案 D (LLM 自動分類): 起案時に LLM が business を自動判定し frontmatter 注入 — 明文基準なしでは LLM の参照基準自体がブラックボックス化。基準 ADR (本案) を先に置く必要がある。
  • 案 Y (business + track の 2 キー方式): 事業軸とメタ軸を独立した 2 キーで保持 — スコア差 0.029 で僅差だが、コード変更範囲 (frontmatter スキーマ・adr-index.mjs の 2 列化・テンプレ・棚卸し) が本案より大きく、即時の filter 拡張ニーズが未顕在。本案で経営者向け filter は同等に達成可能。撤退条件発火時に再評価する候補として保持。

影響 (Consequences)

§5.1 正の影響 (Good)

  • ドメイン分類の再現性が確立し、新規起案で business 判断のばらつきが減る
  • 経営者が事業 ADR (Corp) と Meta を分離して読める
  • PR レビュアー指定 (workspace_rules.md) との連動が明確化
  • メタ ADR 群 (ADR-0030/0032/0107/0137/0144/0149/0162 等) が独立して索引化される
  • 新ドメイン拡張の判定基準が明文化され、軽率な分類軸増殖を防げる

§5.2 負の影響 (Bad)

  • 棚卸し PR で business: corp 68 本のうち推計 64 本 (~96%) が Meta に flip するため、経営者向け早わかり (ADR-0107) の Corp 件数が急減し「重要な意思決定が急減した」と誤認されるリスク → 棚卸し PR マージ前に Corp 件数変化と理由を説明する変更告知ドキュメントを doc クローンで作成する手順を完了条件に追加
  • 境界判定ルール 2.2 の「主目的」概念は主観依存で、複数ドメイン同時適合 ADR (例: MAS の承認フローに直接依存する DRP gate 変更) で誤分類が起きうる → tie-break 手順と NG 例 3 件以上を ADR 本文に追加 + cross-domain ADR は reviewers: frontmatter で MAS owner を明示するルールを併記
  • Meta ドメインに ADR 制度・docs 基盤・workspace 規約・ガバナンスが一括収容されると経営者が「Meta = 読み飛ばし」と一括スキップし、operator_guide 等の経営者関与必須ガバナンス ADR が埋没するリスク → Meta 定義表に executive_review: required|optional 列とサブカテゴリ (meta-infra / meta-governance) を併記
  • SSoT 2 か所 (本 ADR + business.mjs) の drift を規約だけで防ぐのは 5 クローン並行体制で形骸化リスク → CI で business.mjs のドメイン値集合と本 ADR の定義表を機械比較するチェックスクリプトを完了条件に追加

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

  • クローン軸 (5: doc/mas/ocr/drp/main) と ドメイン軸 (4: Corp/MAS/DRP/Meta) は独立 2 軸として確定。1 クローン↔複数ドメイン、1 ドメイン↔複数クローンを許容
  • 案 Y との僅差 (0.029) は filter 拡張性を捨てるトレードオフ。撤退条件発火時に再評価
  • 起案テンプレに business 必須欄追加 (~1 分/ADR 増)

撤退条件 (Rollback Plan)

6.1 撤退判定 (発火条件)

  • ① 棚卸し PR で 50% 超のドメインが flip し、かつそのうち 20% 以上が起案者レビューで「定義に当てはまらない」と判定された場合: 定義そのものを全面改訂してから案 D (LLM 自動分類) を補助ツールとして導入検討
  • ② 受理後 3 ヶ月以内に lint スクリプトが複数ドメイン同時適合フラグを月 1 件以上自動起票した場合: 境界判定ルール 2.2 を revise
  • ③ 受理後半年以内に新ドメインが 2 つ以上追加要件として顕在化した場合: 案 Y (business + track 2 キー方式) への移行を再検討
  • ④ Confirmation §5 の Meta 比率が 60% を超えて 1 ヶ月以上維持した場合: Meta のサブカテゴリ分割 (meta-infra / meta-governance / meta-pipeline 等) を別 ADR で起案
  • 検知: いずれも lint スクリプト + GitHub Issue 自動起票 (担当者の能動報告に依存しない)

6.2 発火後の復旧手順 (どう戻すか)

撤退条件 ①〜④ が発火したときの一括ロールバック手順を以下に固定する。手順は機械再現可で、判断者は起案者 ([email protected]) 1 名で完結する。

  1. 棚卸し PR の一括 revert: 棚卸し PR (1 本想定) を GitHub の Revert ボタンで逆 PR 起票し再マージ。全 ADR の frontmatter business 値が棚卸し前の状態に戻る (1 PR で完結)
  2. business.mjs 参照コメント / テンプレ更新の巻き戻し: 本 ADR §2.1 定義表と同 PR で更新した scripts/lib/business.mjs 参照コメント・docs/_internal/04_specs/adr_template_*.md の business 必須欄を、棚卸し revert と同 PR にまとめて revert (SSoT 同時更新原則の対称適用)
  3. CI スクリプトの取り外し: 本 ADR §Confirmation で導入した 3 種の lint (business-required / drift 検知 / 複数ドメイン適合) を .github/workflows/ で disable し、再導入は revise PR 経由のみとする
  4. 影響範囲の自動確認: revert 後の INDEX.md ドメイン列で Corp/MAS/DRP 件数が pre-flip 値に戻ったことを node scripts/adr-index.mjs --check の diff zero で確認 (人手目視に依存しない)
  5. 経営者向け変更告知の再発信: 棚卸し PR マージ時に doc クローンで作成した「Corp 件数急減の説明告知」を、撤退決定時に「Corp 件数復旧の説明告知」として再発信 (経営者が ADR-0107 経由で見たときに誤認しないよう)

復旧の Time-to-Restore 目安: 手順 1〜4 で 1 営業日以内、手順 5 含めて 3 営業日以内 (棚卸し PR は 1 本想定のため逆 PR も 1 本で済む)。

コスト試算

項目工数
ADR-0163? 起案・受理0.5 人日
棚卸し PR (差分テーブル作成 + frontmatter 一括更新)1.5 人日 (LLM で suggested 列を生成 → 起案者レビュー → 差分のみ frontmatter 編集)
ADR テンプレ更新 (business 必須欄)0.1 人日
business.mjs 参照コメント追加0.1 人日
CI drift 検知スクリプト実装 (本 ADR 定義表 ↔ business.mjs 整合)0.5 人日
複数ドメイン適合 lint + Issue 自動起票0.5 人日
経営者向け変更告知ドキュメント作成0.2 人日
合計~3.4 人日

運用コスト: 起案時に business 必須欄を埋める手間 ~1 分/ADR。

棚卸し PR 1 本 3 分レビューでの誤分類懸念に対しては、LLM suggested 列 + tie-break 手順 + NG 例の存在により判定根拠コメントが frontmatter に自動付与される (上記 CI/lint 工数で吸収)。

Confirmation

  • 検証手段:
    1. adr-lint に business-required ルールを追加し、frontmatter business 欠落時に CI fail
    2. CI drift 検知スクリプト: 本 ADR §2.1 定義表 ↔ scripts/lib/business.mjs のドメイン値集合を機械比較し、不一致で CI fail
    3. 複数ドメイン同時適合 lint: 本文キーワード解析で複数ドメイン候補を検出した ADR に GitHub Issue を自動起票
    4. 棚卸し PR マージ後 3 ヶ月間、新規 ADR の business 値について起案者とレビュアーの判定一致率をサンプル調査
    5. Meta 件数比率モニタ: 全 ADR 中 business: meta の比率を月次集計し、60% を超えたら GitHub Issue を自動起票 (Meta が過度に肥大化して経営者が「Meta = 読み飛ばし」と一括スキップする長期負債化リスクの早期検知)。閾値根拠: 棚卸し直後の想定 Meta 比率は約 40% (corp 64 本 flip + 既存 meta 0 本 / 161 本) であり、その 1.5 倍を上限目安とする
  • 実行頻度: 1〜3 は全 PR (push/PR トリガー)、4 は四半期サンプル調査 (受理後 3/6/9/12 ヶ月)、5 は月次
  • 違反時対応: 1〜2 は CI fail で PR ブロック (例外承認は doc クローンオーナー)、3 は Issue を週次トリアージで処理、4 で一致率 < 90% なら境界判定ルール 2.2 を revise PR で改訂、5 で 1 ヶ月以上 60% 超が継続したら撤退条件 ④ 発火 (Meta サブカテゴリ分割の別 ADR 起案)

Review After (再評価期日)

  • 2026-09-22 (受理後 3 ヶ月): 最初のチェックポイント。①棚卸し PR の flip 率実測 ②複数ドメイン適合 lint の起票件数 ③Meta 比率を一括確認し、撤退条件 ①②④ への該当を判定
  • 2026-12-22 (受理後 6 ヶ月): ③新ドメイン要件の顕在化 (撤退条件 ③)・サンプル調査一致率 (検証手段 4) を判定
  • 以降は半年ごと (2027-06-22, 2027-12-22, ...) に Meta 比率・新ドメイン要件を確認

参照 (References)

  • 関連 ADR:
    • ADR-0030 (Kruchten 3 分類): 同種のメタ ADR (決定対象の分類基準)。本 ADR は事業軸版 — 準拠
    • ADR-0049 (Scope 4 層化): ADR の分類軸を増やす ADR。scope 軸と独立な事業軸を扱う — 準拠
    • ADR-0156 (sub→doc 命名統一): ワークスペース命名と分類軸の概念差を明示。クローン軸とドメイン軸を独立 2 軸として正式化 — 準拠
    • ADR-0159 (mas クローン分割): 5 クローン体制と本 ADR の MAS/DRP/Corp 定義は整合 — 準拠
    • ADR-0107 (経営者向け早わかり): ドメイン列を経営者向け読み分け軸として参照 — 準拠
    • ADR-0032 (Implementation Status 6 値): 同型 (frontmatter 規格化メタ ADR) — 準拠
    • ADR-0137 (frontmatter 移行): 本 ADR が business フィールドを規定する前提 — 準拠
    • ADR-0144 (followups schema): Meta ドメインに分類される代表例 — 準拠
    • ADR-0149 (SSoT ページ): Meta ドメインに分類される代表例 — 準拠
    • ADR-0162 (impl_detail 正式化): 既存 frontmatter フィールドの定義 SSoT 化という点で本 ADR と同型 — 準拠
  • 関連 PR/Issue: 全 161 本棚卸し PR (本 ADR 受理後に別 PR)
  • 外部資料: scripts/lib/business.mjs (nav→ドメインマッピング fallback)、docs/_internal/04_specs/adr_template_*.md、workspace_rules.md