最終更新: 2026/06/22 18:56
RQ-050 メタプロンプト: ADR / 意思決定の Scope 分類軸の業界ベストプラクティス調査
1. 背景
bizlp-gas-accounting プロジェクトでは ADR (Architecture Decision Record) を運用しているが、 現状 48 件の ADR は「決定の重さ」(ADR-0020 で確立した Triage Tier: Light / Standard / Critical) でのみ分類されており、「決定の影響範囲 (Scope)」軸での分類が未整備。
例えば:
- ADR-0001 (SSOT INV) は管理会計プロダクト固有の決定
- ADR-0019 (Decision Pipeline LangGraph) は ADR 制度自体に関する横断インフラ決定
- ADR-0009 (環境分離戦略) は GCP 組織レベルの法人全体決定
これらが同じディレクトリ・同じ採番系列に混在し、Scope 別の検索・統治が困難。 ADR-0022 (Policy Alignment + プラットフォーム/テナント層分離) で 2 層分離思想は確立しているが、 4 段階 (Corporate / Platform / Product / Ops 等) への拡張は未調査。
2. 調査の目的
- ADR / 意思決定文書を Scope (影響範囲) 軸で分類する業界ベストプラクティス を特定する
- 特に 1 人法人 (Solo Founder / Tiny Org) スケール で適用可能な分類軸を見極める
- bizlp の既存運用 (ADR-0020 Tier + ADR-0022 プラットフォーム/テナント 2 層) との 整合性・拡張パス を明確化する
3. 調査論点 (Research Questions)
| # | 調査論点 | 期待アウトプット |
|---|---|---|
| Q1 | ADR を Scope 軸で多階層分類する業界事例・公式フレームワークは実在するか | 網羅リスト + 一次資料 URL |
| Q2 | 主要フレームワーク (TOGAF / C4 Model / AWS WAR / Azure CAF / GCP AF) における Scope 階層定義と境界条件 | 比較マトリクス |
| Q3 | ADR 実装事例 (Spotify / GitLab / ThoughtWorks / MADR / Zimmermann) での Scope メタデータ運用 | フォーマット・lint ルール・実運用上の課題 |
| Q4 | 1 人法人 (Solo Founder / Tiny Team < 5 人) スケールでの適用可能性 | フレームワーク別スコアリング 1〜5 点 |
| Q5 | ADR Tier (Light/Standard/Critical) と Scope の直交性検証 (2 軸マトリクス) | 業界実装事例 + 成功・失敗例 |
| Q6 | bizlp の 4 段階提案 (Corporate / Platform / Product / Ops) の妥当性検証 | 整合性評価 + 改善提案 |
| Q7 | ADR-0022 (プラットフォーム / テナント 2 層) からの拡張経路 | Supersede vs Extends の判断 |
4. 調査対象フレームワーク（最低限カバー）
- TOGAF v10 — Enterprise / Segment / Capability Architecture
- C4 Model (Simon Brown) — System Context / Container / Component / Code
- AWS Well-Architected Framework — Portfolio / Workload / Component
- Azure Cloud Adoption Framework — Governance / Landing Zone / Workload
- Google Cloud Architecture Framework — Foundation / Application
- MADR v3+ (Markdown ADR Records) —
scope:フィールドの仕様 - ThoughtWorks Technology Radar — "Adopt by scope" 運用
- Spotify Engineering Blog — Decision Log の scope 運用
- GitLab Handbook — Engineering Decisions の scope 軸
- Olaf Zimmermann — Decision Capture Framework / Y-Statements
- (追加調査) OSS 大規模リポ (10,000+ stars) で ADR scope メタデータを採用している事例
5. 期待するアウトプット形式
- エグゼクティブ・サマリ (200 字以内): bizlp が採用すべき Scope 分類の推奨
- 業界事例マトリクス: フレームワーク名 / 階層名 / 階層数 / 出典 (URL or 論文) / 適用業界
- 1 人法人での適用可能性スコアリング (各フレームワーク 1〜5 点)
- bizlp の 4 段階提案 (Corporate / Platform / Product / Ops) への評価
- 推奨実装パターン: frontmatter / ディレクトリ / 採番のいずれか
- 未解決リスク / 追加調査が必要な領域
6. 制約・スコープ外
- 個別の ADR ツール (adr-tools, log4brains, MADR-tools) の機能比較は対象外 (それは RQ-038 で別途実施)
- Decision Pipeline の自動化ツールチェーンは対象外 (それは RQ-019 / ADR-0019 で既出)
- 学術的厳密性 > 実装速度 (bizlp の 1 人法人スケールでは過剰でも構わない)
7. 期待する調査深度
- ADR-0020 (Triage 基準) と同等の学術根拠付き調査
- 各フレームワークの一次資料 (公式ドキュメント・論文) を最低 1 件は引用
- 3 モデル並列での得意領域:
- Gemini Deep Research: 最新事例・グローバル業界動向・OSS リポ事例
- Claude Research: 論理整合性・bizlp 既存 ADR との接続・反論ステアリング
- GPT Deep Research: 実装観点・YAML/コード例・frontmatter スキーマ設計
8. 後続アクション (Post-Synthesis)
3 モデルの調査結果を RQ-050_adr_scope_classification_synthesis.md にまとめ、
ADR-0049 (仮): ADR Scope 分類軸の確立 (Corporate/Platform/Product/Ops 4 段階の採用)
の Standard ADR 起案インプットとする。ADR-0022 を Supersede するか、 Implements/Extends するかは Synthesis で決定。
9. 推奨実行モデル
| モデル | 役割 | 期待 token 量 |
|---|---|---|
| Gemini 2.5 Pro Deep Research | グローバル一次資料調査・最新業界事例 | 20,000+ |
| Claude Opus 4.7 Research | bizlp ADR-0020 / 0022 との整合性チェック・反論検証 | 15,000+ |
| GPT-5 Deep Research | YAML スキーマ・frontmatter 設計サンプル | 10,000+ |
10. 関連 ADR / RQ
- ADR-0020 (Triage 基準): Light / Standard / Critical の根拠 → Tier 軸
- ADR-0022 (Policy Alignment + プラットフォーム/テナント 2 層): 拡張元
- ADR-0023 (ADR ドキュメント構造): Nygard + MADR 4.0 統合
- ADR-0030 (Kruchten 3 分類): Existence / Property / Executive 軸 (Scope とは別)
- ADR-0039 (arc42+C4+MADR+feature-folder): C4 Model 採用済み
- RQ-041 (ADR リポ構造): ディレクトリ構造調査済 (部分的に Scope に言及)
- RQ-043 (ADR content essentials): scope: フィールドの例示あり (主軸ではない)