RQ-050 実投入プロンプト: ADR Scope 分類の業界ベストプラクティス調査

使い方: 以下の本文を ChatGPT (Deep Research) / Claude.ai (Research) / Gemini Deep Research に そのまま投入する。3 モデル並列で実施し、結果はそれぞれ RQ-050_adr_scope_classification_result_gemini.md / _result_claude.md / _result_gpt.md に保存する。

あなたの役割

あなたはエンタープライズアーキテクチャと意思決定文書管理の専門家です。 1 人法人 (Solo Founder) が運用する管理会計 SaaS プロジェクトにおいて、 ADR (Architecture Decision Record) を Scope (影響範囲) 軸で分類する業界ベストプラクティスを調査し、推奨設計を提示してください。

プロジェクト前提

規模: 1 人法人 (代表取締役氏)、AI Agent (Claude / Gemini / GPT) 併用
既存 ADR 数: 48 件
既存分類: Tier (Light / Standard / Critical) のみ
既存 Scope 概念: ADR-0022 で「プラットフォーム / テナント」2 層のみ
プロダクト: Google Apps Script + Google Sheets ベースの管理会計 ERP
業界: 日本の中小企業向け SaaS / 管理会計・FP&A

調査タスク

以下の 7 つの研究課題に順番に回答してください。

Q1. ADR Scope 多階層分類の業界事例の網羅

ADR や意思決定文書を Scope 軸で多階層分類している業界フレームワーク・OSS 事例・論文を網羅的に調査してください。それぞれについて以下を含めること:

フレームワーク / 事例の正式名称
階層数と各階層の名前
一次資料 (URL or 論文タイトル + DOI)
想定する組織規模 (大企業 / 中規模 / スタートアップ / 個人)
公開年と最新更新年

Q2. 主要フレームワークの Scope 階層定義

以下のフレームワークそれぞれについて、Scope 階層の境界条件を比較整理:

TOGAF v10 (Enterprise / Segment / Capability Architecture)
C4 Model (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)
上記に該当しない実用フレームワークがあれば追加

各階層について以下を含めること:

何がその階層に含まれるか (例)
隣接階層との境界条件 (これは Platform、これは Product と判定する基準)
階層越境時の典型的な anti-pattern

Q3. 実装事例での Scope メタデータ運用

以下の OSS / 企業事例における ADR / Decision Log の Scope 運用を調査:

Spotify Engineering Blog (Decision Log)
GitLab Handbook (Engineering decisions)
ThoughtWorks Technology Radar (scope-based Adopt)
MADR v3+ (Markdown ADR Records)
Olaf Zimmermann の Decision Capture Framework
他に大規模リポ (10,000+ stars) で ADR を運用し scope メタデータを採用している事例

各事例について以下を含めること:

メタデータフィールドの形式 (YAML / JSON / Markdown)
Scope の値域 (列挙型 or 自由記述)
adr-lint / CI での検証ルール
実運用上の課題・批判

Q4. 1 人法人スケールでの適用可能性

上記フレームワーク (Q2) と事例 (Q3) について、 1 人法人 (Solo Founder + AI Agent) スケール での適用可能性を評価:

大企業前提のものはどれか (理由付き)
小組織でも使える簡略化パターン
1 人法人での "Corporate" の意味 (法人全体 vs 経営者個人)
過剰設計 (over-engineering) を避けるための判定基準

スコアリング: 各フレームワーク 1〜5 点 (5=即適用可、1=不適合)

Q5. Tier × Scope の 2 軸運用の業界実装

bizlp は ADR-0020 で Tier (Light/Standard/Critical) を既に運用しています。これに Scope 軸を加えると 2 軸マトリクスになります。

2 軸マトリクスを ADR で運用している業界事例は存在するか
Scope 別に Tier の意味が変わるケース (例: Corporate × Light は実在するか?)
2 軸の 直交性 は保たれるか、それとも相関するか
2 軸運用の成功例・失敗例

Q6. bizlp の 4 段階提案の妥当性検証

bizlp が提案している以下の 4 段階分類を業界標準と照合し評価:

Corporate: 法人運営・組織・人事・税務・契約
- 例: GCP 組織構成、税理士契約、雇用、就業規則、経費規程
Platform: 全プロダクトに影響する基盤
- 例: Decision Pipeline、ADR 制度、docs サイト、CI/CD、Vertex AI 集約
Product: 管理会計プロダクト固有
- 例: SSOT INV、仕訳エンジン、データマート、FP&A、UC スライス
Ops: 日々の業務オペ・統制
- 例: ITGC、月次決算、障害対応、playbook

評価軸:

業界類例との整合性 (◯/△/×)
階層名の妥当性 (Corporate vs Enterprise? Platform vs Foundation?)
過不足判定 (5 段階以上 or 3 段階以下が良いケースはあるか)
1 人法人スケールでの実用性

Q7. ADR-0022 からの拡張経路

bizlp は ADR-0022 で「プラットフォーム / テナント」2 層分離を確立済みです。 4 層 (Corporate / Platform / Product / Ops) への拡張について:

2 層 → 4 層への業界標準的な拡張パターン
ADR-0022 を Supersede すべきか、Implements/Extends すべきか
拡張時に既存 ADR (48 件) を遡及で再分類するか、新規にのみ適用するか
拡張に伴うリスク (Bezos Type 1 か Type 2 か)

出力形式

各 Q への回答は H2 見出し (## Q1. xxx) で開始
一次資料は 必ず URL or DOI で明示 (リンク切れでも構わない)
表形式が適切な場合は Markdown テーブルを使用
最終セクションで「bizlp 採用推奨案」を 300 字以内で結論

結論には以下を含むこと:

推奨 Scope 階層 (4 段階を採用 or 修正案)
各階層の名前 (英語 + 日本語)
実装方法 (frontmatter / ディレクトリ / 採番)
ADR-0022 との関係 (Supersede / Extends / Replaces)
ADR Tier との連動方法

制約

ChatGPT / Claude / Gemini の Web 検索機能を積極的に使用してください
一次資料がなく憶測で書く場合は [要追加調査] と明示
1 人法人スケールでの実用性を重視
学術的厳密性 > 実装速度だが、過剰設計は避ける
既存 bizlp ADR-0020 / ADR-0022 の方針を否定しない範囲で拡張提案

参考情報 (bizlp 既存決定)

ADR-0020: Triage Tier の 4 カテゴリ (対象外 / Light / Standard / Critical) の学術根拠
- Light = Kruchten property decisions 軽量版 / MADR minimal / Y-Statements
- Standard = Nygard structure + interfaces / Chen et al. ASR
- Critical = Nygard 5 領域全該当 / Zimmermann 5+2 / Bezos Type 1 / Chen compliance audit
ADR-0022: Policy Alignment + プラットフォーム/テナント 2 層分離
ADR-0039: arc42 + C4 + MADR + feature-folder 採用済 (C4 Model は既知概念)