RQ-050 ADR Scope 分類軸 Synthesis（3 モデル突合 + bizlp 採択方針）

作成日: 2026-05-17 / 依頼者: bizlp / 代表取締役氏 目的: Claude Opus 4.7 / Gemini 2.5 Pro Deep Research / GPT-5 Deep Research の 3 モデル並列調査結果を突合し、ADR-0049 (Standard 想定) 起案のための bizlp 採択方針を確定する。

エグゼクティブ・サマリ（300 字以内）

3 モデルとも独立に 4 階層 Scope (Corporate / Platform / Product / Ops) を推奨、ADR-0022 を Extends / Refines（Supersede 不要）、MADR frontmatter に scope: 列挙型必須を提案し合意。bizlp はこれを採択し、ADR-0049 (Standard) として起案する。既存 48 件は 段階的遡及（Phased Backfill） で対応、新規 ADR からは scope: 必須。Tier × Scope は 直交 2 軸運用し、Corporate × Critical は Bezos Type 1 として review 必須化。Caveat: 「Tier × Scope の 2 軸メタデータ化」を明示的に実装している大規模 OSS / 企業事例は確認できず、bizlp はフロントランナーとなる。

1. 3 モデル合意点（Strong Consensus, 3/3 モデル）

以下の論点で 3 モデルすべてが独立に同じ結論に到達：

2. 3 モデル中程度合意（2/3 モデル）

3. 3 モデル相違点・対立点

3.1 階層数

→ bizlp 判断：4 階層採用。Claude/Gemini の合意理由（業界類例多数 + 4 段階で網羅性確保）が GPT の「3 でも可」より強い根拠を持つ。Ops を独立化することで「日次運用 vs 製品設計」の境界が ADR 上で明確化される 1 人法人特有の価値。

3.2 業界事例の網羅性

3 モデルが言及した独自事例の補完関係：

→ 3 モデルの調査範囲はおおむね補完的。Gemini が言及した「GitLab Handbook の Corporate/Product/Instance/Organization の 4 階層」は bizlp 提案 4 層命名 (Corporate/Platform/Product/Ops) に最も近い類例だが、Claude は verbatim 確認できずと Caveat。追加調査余地あり [要追加調査]。

3.3 階層名の細部

3 モデルとも 4 階層採用には合意したが、命名の微妙な違い：

→ bizlp 採用：Claude/Gemini と完全一致。GPT の "Enterprise が業界定番" 指摘は事実だが、1 人法人で「Enterprise」は過大表現。Corporate のほうが法人格を強調できる利点を採用。

3.4 遡及対応戦略

→ bizlp 採用：Claude の Phased Backfill。理由：

• 一括書き換えは Bezos Type 1（履歴の不可逆改変）リスク
• 新規のみは Gemini が指摘する「スプリットブレイン」で AI 検索精度低下
• Phased Backfill は Type 2 を維持しつつ段階的にカバレッジ向上、最も安全

3.5 CodeOps 統合（paths Glob）

Gemini のみが言及した sventorben/decider の scope.paths Glob パターン統合：

• frontmatter に scope.paths: [src/db/**, migrations/**] を記述
• CI で decider check diff を実行し、変更ファイルが ADR の Glob と一致したら制約適用
• Claude Code / Gemini が編集前に「該当 ADR の制約」をコンテキストとして読み込む

→ bizlp 判断：将来オプションとして検討。理由：

• 即時導入は ROI が見えない（48 件遡及作業が前提）
• sventorben/decider は新興ツール、エコシステムが未成熟
• まずは MADR scope: 列挙型を導入し、6 か月運用してから検討

4. bizlp 採択方針（確定）

4.1 階層構造

Corporate （法人）
  └ 法人運営・組織・人事・税務・契約
     例: GCP 組織構成、税理士契約、雇用、就業規則、経費規程

Platform （基盤）
  └ 全プロダクトに影響する基盤
     例: Decision Pipeline、ADR 制度、docs サイト、CI/CD、Vertex AI 集約、AI Agent 併用ワークフロー

Product （製品）
  └ 管理会計プロダクト固有
     例: SSOT INV、仕訳エンジン、データマート、FP&A、UC スライス

Ops （運用）
  └ 日々の業務オペ・統制
     例: ITGC、月次決算、障害対応、playbook

4.2 ADR メタデータ拡張

MADR 4.0.0 frontmatter に scope: 列挙型必須フィールドを追加：

---
adr_id: 0049
title: <短い決定タイトル>
status: accepted
mode: Standard  # ADR-0020 で確立済の Tier 軸
scope: platform  # 新規追加: corporate | platform | product | ops の 4 択
date: 2026-05-17
decision_makers: [代表取締役氏]
related:
  refines: [ADR-0022]
  related: [ADR-0020, ADR-0023, ADR-0039]
---

4.3 ADR-0022 との関係

Refines（または Extends）として位置付け。ADR-0022 (「プラットフォーム / テナント」2 層) を Supersede せず、status="accepted" のまま保持。新規 ADR-0049 が ADR-0022 を細分化する形。

具体的な対応：

• ADR-0022 「プラットフォーム」 → ADR-0049 Platform（そのまま継承）
• ADR-0022 「テナント」 → ADR-0049 Product に再定義（顧客テナント = 1 プロダクト境界）
• 新規追加：Corporate（ADR-0022 では扱えなかった法人運営層）
• 新規追加：Ops（ADR-0022 では扱えなかった運用統制層）

4.4 既存 48 件の遡及戦略

Phased Backfill 3 段階（Claude 案採用）：

12 か月以内に全 48 件 + 新規分のカバレッジ 100% を目標。

4.5 Tier × Scope の 2 軸運用

運用ルール：

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

4.6 adr-lint 拡張

ADR-0038 で確立済の adr-lint.mjs に以下のルールを追加：

1. scope 必須化（新規 ADR から）
2. enum 検証：scope の値は corporate | platform | product | ops のいずれか
3. Phase 2/3 警告：既存 Critical ADR で scope 未設定の場合 warning（fail にしない）
4. scope-tier 組合せの統計：adr-lint stats で各組合せの件数を出力

5. ADR-0049 起草インプット

タイトル案

「ADR Scope 分類軸の確立（Corporate / Platform / Product / Ops 4 層採用）」

ADR メタデータ

adr_id: 0049
title: ADR Scope 分類軸の確立 (Corporate/Platform/Product/Ops)
status: proposed → accepted
mode: Standard
kruchten_type: Property
scope: platform  # この ADR 自体は ADR 制度=Platform scope
implementation_status: planned
related:
  refines: [ADR-0022]
  related: [ADR-0020, ADR-0023, ADR-0030, ADR-0036, ADR-0038, ADR-0039]

Context（5 サブセクション、RQ-042 適用）

1. 背景：48 件の ADR が Tier 軸のみで分類されており、Scope 軸が未整備
2. 現状：ADR-0022 で「プラットフォーム / テナント」2 層分離だが、4 段階拡張は未検討
3. 課題：ADR-0001 (Product) と ADR-0019 (Platform) と ADR-0009 (Corporate) が混在し検索性低下
4. 制約・要件：1 人法人スケール、Bezos Type 1 化を避ける（既存 ADR の破壊的変更不可）
5. 目標：Scope 軸メタデータ追加、AI 検索精度向上、ADR-0022 を Refines

Decision

1. 4 階層 (Corporate / Platform / Product / Ops) を採用
2. MADR frontmatter に scope: 列挙型必須フィールドを追加
3. ADR-0022 を Refines（Supersede しない）
4. 既存 48 件は Phased Backfill 3 段階で遡及
5. Tier × Scope の直交 2 軸運用、Corporate × Critical のみ追加 review 要件

Consequences（3 サブセクション、RQ-042 適用）

• 正：検索性向上、AI Agent コンテキスト精度向上、外部レビュアー（税理士・監査人）への説明性向上
• 負：48 件の遡及工数（Phased Backfill 12 か月）、scope 判定の認知負荷
• 中立：MADR 標準には scope: フィールドが未定義のため bizlp 独自拡張

Confirmation（ADR-0036 適用）

• adr-lint で scope: 必須化と enum 検証を CI 化
• 12 か月後に「全 ADR の scope カバレッジ ≥ 95%」を fitness function として測定
• Phase 2 完了時に「Critical Tier の scope カバレッジ = 100%」を確認

6. 未解決リスク・追加調査が必要な領域

6.1 Tier × Scope の業界先行事例不足

3 モデルとも「Tier × Scope の 2 軸を明示的にメタデータ化している大規模 OSS / 企業事例」は verbatim 確認できなかった。bizlp はフロントランナー位置付けになる。 → 対策：12 か月運用後に振り返り、Confirmation で問題があれば改訂

6.2 Ops 層の業界標準性

GPT が指摘するとおり「Ops は scope より concern」と扱う事例が多い。1 人法人での独立 scope 化は実用判断。 → 対策：Phase 2 終了時に「Ops scope の ADR 件数」を audit し、5 件以上あれば妥当性確認

6.3 GitLab Handbook の 4 階層命名の検証

Gemini が「GitLab は Corporate/Product/Instance/Organization 4 階層」と言及したが、Claude は verbatim 確認できずと Caveat。 → 対策：ADR-0049 起草時に GitLab Handbook の公式ドキュメントを再確認、Caveat として明記

6.4 sventorben/decider CodeOps 統合のタイミング

新興ツールで成熟度に懸念。 → 対策：6 か月運用後、paths: Glob 統合の ROI を再評価

6.5 Scope と Tier の相関による予測力

Claude が指摘する「Corporate は Critical 寄り、Ops は Light/Standard 寄り」の相関。完全直交ではない。 → 対策：運用上はピボット集計用途のみ、Scope→Tier の予測には使わない

7. 後続アクション

Appendix A. 3 モデル定量比較