← ADR 一覧へ残タスク一覧へ最終更新: 2026/06/22 20:19

commonid: adr-0049type: adrstatus: accepted

pagemode: Standardkruchten: Propertyscope: platformimplementation_status: In Progressproposed_at: 2026-05-17 12:30approved_at: 2026-06-21deciders: [email protected] / Consulted: Clau…business: meta

型付き辺: 出 15 / 入 1

ADR-0049: ADR Scope 分類軸の 4 層化 (Corporate / Platform / Product / Ops)

Status: Accepted
Mode: Standard
Kruchten Type: Property
Scope: platform
Implementation Status: In Progress
起案者: [email protected] ([email protected])
起案日時 (JST): 2026-05-17 12:30
承認日時 (JST): 2026-06-21
Deciders: [email protected] / Consulted: Claude Opus 4.7, Gemini 2.5 Pro Deep Research, GPT-5 Deep Research (RQ-050 並列調査)

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

本節は ADR-0140 の方針で遡及追加された本文の要約で、新しい意味は加えていない (意思決定内容は不変)。「文脈で問題に直面し、対抗案でなくこの案を選び、目的のため代償を受け入れる」と読む。詳細はコンテキスト以降の本文に展開する。

文脈: 既存 48 件の ADR は ADR-0020 の Mode (Light/Standard/Critical) 軸でのみ分類済み。RQ-050 の 3 モデル並列調査で 4 階層 Scope の業界類例と採用根拠が確定した。
問題: Corporate / Platform / Product 領域の決定が同一採番系列・同一ディレクトリに混在し、Scope 別の検索が困難。性質の異なる決定を同じ重さで扱う運用になっている。
問題点と課題（直せる原因 → 発生を止めるためにやること）:
- 決定の影響範囲 (Scope) を表す軸がない → Scope 軸を 4 階層で導入し、Mode × Scope の直交 2 軸メタデータ運用を確立する。
- AI Agent がコンテキスト読み込み時にどの Scope の決定か判別できない → frontmatter に scope: 列挙型フィールドを追加し adr-lint で検証する。
前提（解決を課題に立てない与件）:
- ADR-0022 (プラットフォーム/テナント 2 層) は否定せず Refines として継承する。
- 既存 48 件への破壊的変更 (一括書き換え) は Bezos Type 1 リスク回避のため不可。
決定（対応策）: 3 階層案・5 階層以上・ADR-0022 完全置換でなく、4 階層 Corporate / Platform / Product / Ops を採用する。新規 ADR から Scope: 必須、既存 48 件は Phased Backfill で遡及付与する。
目的: Scope 別の検索と AI Agent のフィルタ読み込みを可能にし、「税理士相談が必要な決定」と「AI Agent 主導で進められる決定」の運用フローを分離する。
代償: 48 件の遡及工数 (推定 4 時間) が 12 か月以内に発生する。起案時に Scope 判定の認知負荷が加わる。MADR 4.0.0 に scope: が未定義のため独自拡張になる。
詳細は本文の影響・撤退条件セクションを参照のこと

1. コンテキスト

1.1 背景 (Background)

2026-05-17 セッションで「ADR-0020 で確立した Mode (Light/Standard/Critical) 軸だけでは、決定の影響範囲 (Scope) が表現できず、新規セクション追加時の判断軸不足」が顕在化。RQ-050 として 3 モデル並列調査 (Claude / Gemini / GPT Deep Research) を実施した結果、4 階層 Scope の業界類例と採用根拠が確定した。

1.2 現状 (Current State / As-Is)

既存 48 件の ADR は ADR-0020 の Mode 軸でのみ分類済み。ADR-0022 で「プラットフォーム / テナント」の 2 層分離は確立しているが、法人運営 (Corporate) と運用統制 (Ops) を独立軸として扱う仕組みはない。

1.3 課題 (Problem)

ADR-0001 (Product 領域: SSOT INV) / ADR-0019 (Platform 領域: Decision Pipeline) / ADR-0009 (Corporate 領域: GCP 組織分離) が同一採番系列・同一ディレクトリに混在し、Scope 別の検索が困難
「税理士契約」「Decision Pipeline 構成」「仕訳エンジン仕様」「月次決算 playbook」を同じ重さで扱う運用になっている
AI Agent (Claude/Gemini/GPT) が ADR をコンテキスト読み込み時に「どの Scope の決定か」を判別できない

1.4 制約・要件 (Constraints & Requirements)

ADR-0022 (プラットフォーム/テナント 2 層) を否定しない (Refines として継承)
既存 48 件への破壊的変更 (一括書き換え) は Bezos Type 1 リスク回避のため不可
MADR 4.0.0 標準には scope: フィールドが未定義のため独自拡張になる
1 人法人スケールで運用可能な粒度に留める (5 階層以上は過剰)

1.5 目標 (Goals / To-Be)

ADR を Scope 軸で 4 階層分類し、Mode × Scope の直交 2 軸メタデータ運用を確立する。Non-Goals: 既存 48 件の即時遡及、ディレクトリ物理分離、採番分離。

2. 判断基準 (Decision Drivers)

業界類例との整合性: TOGAF / C4 Model / AWS WAR / Azure CAF / GCP AF / MADR との対応関係が説明可能か
1 人法人スケールでの実用性: 各階層に最低 3 件以上の ADR が分布する見込みがあるか
既存 ADR-0022 との後方互換: Supersede ではなく Refines で継承可能か
AI Agent 分類精度: Claude / Gemini に Scope を聞いて 70%+ で同じ判定が出るか
可逆性 (Bezos Type 2): 後で階層名変更や統合・分解が可能な設計か

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

案 A: 4 階層 Corporate / Platform / Product / Ops を採用 (RQ-050 で 3 モデル合意)
- Good, because RQ-050 で Claude/Gemini/GPT 3 モデルが独立に同じ結論に到達し合意形成済み
- Good, because C4 Model / AWS WAR / Azure CAF / GCP AF いずれも 4 階層を採用しており業界類例多数
- Good, because 既存 ADR を分類した際に各階層に最低 3 件以上が割り当てられる見込み (Phase 2 audit 予定)
- Bad, because Ops を独立 Scope 化する業界事例は少数派 (concern として扱う事例が多い)
- Bad, because Mode × Scope の 2 軸メタデータ化を実装している大規模 OSS / 企業事例が verbatim 確認できず bizlp フロントランナーになる
案 B: 3 階層 (Corporate / Platform / Product、Ops は Product 内に統合)
- Good, because GPT が「1 人法人なら 3 階層でも可」と評価
- Good, because Ops 独立化の業界標準性が低いリスクを回避できる
- Bad, because 月次決算 playbook / ITGC 統制と仕訳エンジン仕様が同じ Scope に混在し、検索性低下
- Bad, because 1 人法人で開発と運用が不可分という特性を活かせない
案 C: 5 階層以上 (例: + Data 層)
- Good, because IASA BTABoK の 6 層モデルに近づく
- Bad, because 48 件規模で 5 階層以上は過剰、AI Agent 分類精度低下
- Bad, because RQ-050 でいずれのモデルも 5 階層を推奨せず
案 D: ADR-0022 を Supersede し新規 2 層 (Platform / Tenant) → 4 層に完全置換
- Good, because 履歴が clean
- Bad, because ADR-0022 の「プラットフォーム/テナント」概念が消える
- Bad, because 既存 ADR-0022 を参照する他 ADR との整合性が壊れる

4. 決定 (Decision Outcome)

採用: 案 A (4 階層 Corporate / Platform / Product / Ops)。理由: RQ-050 の 3 モデル並列調査で合意形成済みであり、業界類例の網羅性・1 人法人スケールでの実用性・ADR-0022 との後方互換性すべてを満たす唯一の選択肢。

4.1 階層定義

階層	対象	業界類例
Corporate	法人運営・組織・人事・税務・契約 (GCP 組織構成、税理士契約、雇用、就業規則)	TOGAF Enterprise / Azure CAF Strategy
Platform	全プロダクトに影響する基盤 (Decision Pipeline、ADR 制度、docs サイト、CI/CD、AI Agent オーケストレーション)	Spotify Backstage Platform / DDD Supporting Subdomain
Product	管理会計プロダクト固有 (SSOT INV、仕訳エンジン、データマート、FP&A、UC スライス)	TOGAF Capability / C4 Container / DDD Core Subdomain
Ops	日々の業務オペ・統制 (ITGC、月次決算、障害対応、playbook)	AWS WA OpEx Pillar / Azure CAF Manage

4.2 frontmatter 拡張

MADR 4.0.0 frontmatter に scope: 列挙型フィールドを追加 (新規 ADR から必須):

- **Scope**: corporate | platform | product | ops

4.3 ADR-0022 との関係

ADR-0022 を Status=accepted のまま保持し、本 ADR を Refines ADR-0022 として位置付け。ADR-0022 の「プラットフォーム」は本 ADR の Platform に、「テナント」は Product に対応する。

4.4 既存 48 件の遡及戦略 (Phased Backfill)

Phase 1 (即時): 新規 ADR-0049 以降は Scope: 必須化、adr-lint で検証
Phase 2 (1-2 か月): 既存 Critical Mode ADR (推定 10 件) から優先的に Scope: を付与
Phase 3 (12 か月以内): 残りは supersede / amend 時に併せて付与

4.5 Mode × Scope 運用ルール

Corporate × Critical は Bezos Type 1 (一方向ドア) として正式 review 必須 (税理士・監査人への相談含む)
その他の × Critical は通常 Critical フロー (3 モデル並列レビュー)
Standard / Light は 1 day 内決定可 (AI Agent 主導)

5. 影響 (Consequences)

5.1 正の影響 (Good)

Good, because 検索性が向上し、AI Agent (Claude/Gemini/GPT) が Scope 別に ADR をフィルタしてコンテキスト読み込みできる
Good, because 「税理士相談が必要な決定 (Corporate × Critical)」と「AI Agent 主導で進められる決定 (Product × Light 等)」の運用フローを明確に分離できる
Good, because 外部レビュアー (税理士・監査人) に対し「これは Corporate の決定です」と説明性が向上
Good, because RQ-050 で 3 モデル合意済みのため、起案根拠が学術・実装事例の両面で堅牢

5.2 負の影響 (Bad)

Bad, because Phased Backfill による 48 件の遡及工数が 12 か月以内に発生 (推定: 1 件 5 分 × 48 件 = 4 時間、ただし新規優先で漸進)
Bad, because Scope 判定の認知負荷が新規 ADR 起案時に追加される (4 択 + 判定フローチャートで緩和)
Bad, because MADR 4.0.0 標準には scope: フィールドが未定義のため、将来 MADR が公式 scope フィールドを追加した場合に再調整が必要

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

Neutral, because Mode × Scope の 2 軸メタデータ化を業界先行事例なしで実装するため、bizlp フロントランナー位置付け (12 か月後 Confirmation で振り返り)
Neutral, because Ops 層独立化の業界標準性が低い (concern として扱う事例が多い) が、1 人法人で開発と運用が不可分な特性を活かす判断

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

再評価トリガー:
- 階層名 (Corporate / Platform / Product / Ops) のいずれかが 12 か月以内に空 (ADR 0 件) のまま推移
- Scope 判定で AI Agent (Claude/Gemini) の合意率が 70% 未満に低下
- MADR が公式 scope: フィールドを追加した場合の互換性検証
判定タイミング: 6 か月後 / 12 か月後の 2 回
判定主体: 代表取締役
撤退オプション: frontmatter scope: フィールドを削除 (adr-lint スクリプトの逆操作で復元可能、Bezos Type 2)

Confirmation (準拠確認 / Fitness Function)

検証手段:
1. adr-lint.mjs に scope: 必須化 + enum 検証ルール追加 (ADR-0050 想定)
2. adr-lint stats で Scope × Mode の組合せ件数を出力するコマンド追加
3. 12 か月後の audit: 全 ADR の scope カバレッジ ≥ 95% を確認
実行頻度: PR ごと (adr-lint CI) / 月次 (stats レポート) / 12 か月後 (Confirmation audit)
違反時の対応: adr-lint が scope: 未設定の新規 ADR で fail / Phase 2 期間中の Critical Mode 未付与は月次レビューで集計し起案者に通知

7. 参照 (References)

関連 ADR:
- ADR-0020 (Triage 基準) — Mode 軸の根拠、本 ADR は Scope 軸を直交追加
- ADR-0022 (Policy Alignment + プラットフォーム/テナント 2 層) — 本 ADR が Refines
- ADR-0023 (ADR ドキュメント構造) — Nygard + MADR 4.0 ミニマル統合フォーマット
- ADR-0030 (Kruchten 3 分類) — Existence / Property / Executive 軸 (Scope と直交)
- ADR-0036 (Confirmation セクション) — fitness function 自動検証
- ADR-0038 (adr-lint メタデータ規約) — 本 ADR の Confirmation 実装基盤
- ADR-0039 (arc42+C4+MADR+feature-folder 採用) — C4 Model 採用済で親和性◎
関連 PR: #805 / #807 / #808 (RQ-050 パイプライン段階 1-3)
関連 RQ: RQ-050 (ADR Scope 分類軸の業界ベストプラクティス調査)
外部資料:
- TOGAF Standard, 10th Edition (Enterprise / Segment / Capability): https://www.opengroup.org/togaf
- C4 Model (Simon Brown): https://c4model.com/
- MADR 4.0.0: https://adr.github.io/madr/
- sventorben/decider (CodeOps 統合の将来オプション): https://github.com/sventorben/decider