RQ-050 管理会計SaaSプロジェクトにおけるADR Scope多階層分類の業界ベストプラクティス調査報告書（Gemini 2.5 Pro Deep Research 結果）

アーキテクチャの意思決定記録（ADR: Architecture Decision Record）は、システムの現在の形状がどのように、そしてなぜそのようになったのかを記録する重要な成果物である。ソフトウェアの複雑性が増し、AIエージェントが開発プロセスに深く関与する現代において、ADRは単なる人間向けの備忘録から、AIやCI/CDパイプラインが解釈可能な機械可読制約（Machine-readable constraints）へと進化を遂げつつある。本報告書では、1人法人（Solo Founder）およびAIエージェントによる共同運用を前提とした管理会計SaaSプロジェクトにおいて、ADRを「Scope（影響範囲）」の軸で多階層分類するための業界ベストプラクティスを網羅的に調査・分析する。既存の重要度（Tier）分類および2層構造（プラットフォーム/テナント）を拡張し、AIネイティブな開発環境に最適化されたメタデータ設計とアーキテクチャガバナンスの推奨案を提示する。

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

アーキテクチャの意思決定やシステム設計を「Scope（影響範囲）」の軸で多階層に分類するアプローチは、エンタープライズアーキテクチャ（EA）やクラウドインフラ設計、そして近年のArchitectural Knowledge Management（AKM）の領域において広く採用されている。意思決定が組織全体に影響するのか、特定の製品・領域に留まるのか、あるいは単一のコードやリソースに限定されるのかという境界を定義することは、意図しない依存関係の発生を防ぐために不可欠である。以下に、業界を代表するフレームワーク、OSS事例、および学術論文におけるScope多階層分類の事例を網羅する。

これらのフレームワークの分析から浮かび上がる共通のテーマは、システムの複雑性を管理するために「ビジネス境界」「インフラ境界」「アプリケーション境界」を明確に分離している点である。例えば、TOGAFはビジネス戦略の観点からエンタープライズ全体と個別のケイパビリティを分け、C4 Modelはソフトウェア設計の観点からシステム全体と内部モジュールを分ける。また、主要なパブリッククラウドプロバイダーは、請求やセキュリティポリシーの継承という観点から一様に4階層前後のリソース階層を提供している。Olaf Zimmermannの学術的研究に基づくフレームワークでは、技術の抽象度（概念的パターンか、特定のベンダー製品か）に基づいて意思決定のスコープを分類しており、これは知識の陳腐化を防ぎ、再利用性を高めるための工夫であると評価されている。

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

業界を代表するアーキテクチャフレームワークにおいて、各Scope階層がどのような境界条件（Boundary conditions）によって定義されているかを比較整理する。階層間の境界を明確にすることは、意思決定がどこに属するかを判定する上で極めて重要であり、越境時のアンチパターンを理解することでアーキテクチャの劣化を防ぐことができる。

TOGAF v10

TOGAFは、ビジネスの目的とITの実行を合致させるためのエンタープライズアーキテクチャ手法である。そのスコープはビジネス価値の範囲に基づいて3つのレベルに分類される。最上位の「Enterprise Architecture」は、企業全体の戦略的視点を提供し、全社的なIoTプラットフォームの導入や全社データセキュリティ基準の策定など、組織全体にまたがる共通基盤や標準を定義する層である。中間層の「Segment Architecture」は、産業用製造クライアント部門や商用オフィス部門など、特定の事業領域やポートフォリオに焦点を当てる。最下層の「Capability Architecture」は、異常検知アルゴリズムやリアルタイム監視プロセスなど、単一のビジネス機能を実現するための詳細なリソース要件を定義し、開発スプリントに直接落とし込まれる粒度を持つ。これら隣接階層の境界条件は、影響が全社に及ぶか（Enterprise）、特定の事業部門に閉じるか（Segment）、あるいは単一のビジネス価値提供に限定されるか（Capability）という点にある。典型的なアンチパターンとしては、Segment（事業部）が自部門の要件を優先するあまり、Enterprise（全社戦略）で定められたデータガバナンス基準を無視して独自のシャドーITやサイロ化されたシステムを構築してしまうことが挙げられる。

C4 Model

ソフトウェアアーキテクチャの視覚化に特化したC4 Modelは、異なるオーディエンスに向けて抽象度を変える「ズームイン」のメタファーを採用している。最上位の「System Context」は、対象となるソフトウェアシステムを中心に置き、それを利用するユーザー（アクター）や、システムが依存する外部システム（Google WorkspaceやStripeなど）との関係性を示す。次にズームインした「Container」は、サーバーサイドのWebアプリケーション、シングルページアプリケーション、データベース、S3バケットなど、個別にデプロイおよび実行可能なプロセスやデータストアの境界を定義する。「Component」はそのコンテナ内部に存在する論理的なモジュール（例: 認証コントローラーや仕訳エンジン）であり、「Code」はクラスや関数レベルの最も微細な実装詳細を示す。隣接階層の境界条件として、Contextは自チームが所有権を持たない外部システムを包含する境界であり、Containerは独立してデプロイ可能なプロセス境界、Componentはコードベース内での論理的な関心事の分離境界となる。階層越境時の典型的なアンチパターンは、System Contextのレベルにおいて、外部連携先システムの内部コンポーネントまで詳細にモデリングしてしまうことである。外部システムの内部仕様が変わるたびに図や意思決定記録の更新を強いられ、メンテナンスコストが破綻する原因となる。

AWS Well-Architected Framework

AWSのマルチアカウント戦略に基づくスコープ階層は、セキュリティ上の影響範囲（Blast Radius）と請求の分離に主眼を置いている。最上位の「Organization」は、複数のAWSアカウントを一元管理する請求とガバナンスのルートである。「Organizational Unit (OU)」は、セキュリティや運用要件が類似するアカウントを束ねる論理的なグループであり、ここにサービスコントロールポリシー（SCP）が適用される。「Account」は、リソース、IAM権限、および課金における最も強力な分離境界であり、事実上のコンテナとして機能する。最下層の「Workload」は、EC2インスタンスやRDSデータベースなど、特定のビジネス価値を共同で提供するリソースの集合体である。境界条件として、Accountは物理的かつ完全な分離境界であり、Workloadはそのアカウント内部で稼働する論理的な機能単位であると定義される。ここで発生しやすいアンチパターンは、機密性の高い顧客データを扱う本番環境のWorkloadと、開発者が自由にテストを行うSandboxのWorkloadを、同じAccount（スコープ）内に同居させてしまうことである。これにより分離境界が曖昧になり、設定ミスによる情報漏洩リスクが極大化する。

Azure Cloud Adoption Framework

Azureのエンタープライズ向け階層モデルは、ポリシーとアクセス権の継承構造を厳格に定義している。「Tenant Root Group」は、Azure Active Directory（Entra ID）に基づくID管理の頂点であり、その直下に配置される「Management Group」は、プラットフォーム共通基盤や特定の事業領域（Landing Zones）ごとにポリシーとアクセス制御（RBAC）をまとめて適用するための論理階層である。「Subscription」は、Azureにおける課金単位であり、同時にリソースのスケール限界（クォータ）を決定する境界となる。最下層の「Resource Group」は、同じライフサイクルを共有し、同時にデプロイまたは削除されるリソースのまとまりである。これらの境界条件は、Management Groupが「組織的なガバナンスとポリシーの継承単位」、Subscriptionが「予算管理とスケーラビリティの境界」、Resource Groupが「運用ライフサイクルの境界」という役割の違いによって明確に区別される。典型的なアンチパターンは、組織全体に影響を及ぼす過剰な権限設定をTenant Root Groupに対して直接行ってしまうことである。この設定は下位のすべての階層に強制的に継承されるため、特定の事業領域で必要となる柔軟な構成を阻害し、アーキテクチャ全体を硬直化させてしまう。

Google Cloud Architecture Framework

GCPのリソース階層は、ファイルシステムのようなツリー構造を持ち、上位ノードから下位ノードへとIAMポリシーが継承される。ルートノードである「Organization」は企業全体を表現し、「Folder」は事業部、部門、あるいは開発・本番といった環境を論理的に分離するために使用される。「Project」はGCPを利用するための絶対的な基本単位であり、すべてのリソース（コンピュート、ストレージなど）は必ず1つのProjectに属する。ProjectはAPIの有効化、課金、および権限管理の基本的な信頼境界（Trust Boundary）となる。境界条件として、Organizationは企業という単一のエンティティ、Folderは共通のポリシーを適用するためのグループ化境界、Projectは実際のサービスやアプリケーションを稼働させる独立した境界である。よくあるアンチパターンとしては、企業のビジネス構造（事業部や子会社など）を無視して、最上位のFolder階層を単に「開発環境」「本番環境」という軸だけで分割してしまうことである。これにより、特定のビジネスユニットごとに固有のIAMポリシーやセキュリティ要件を継承させることが極めて困難になる。

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

実際のエンタープライズ開発現場や大規模なオープンソースプロジェクトにおいて、ADRや意思決定ログがどのようにScopeメタデータとして実装・運用されているかを調査した。最新の動向では、ADRは人間が読むための静的なドキュメントから、CI/CDやAIエージェントがプログラム的に解釈できる動的なアーキテクチャ制約へと役割を変えつつある。

Spotify Engineering Blog (Decision Log)

Spotifyは、大規模でアジャイルな組織構造（Tribe, Squadモデル）に合わせてADRを活用し、エンジニアリングのベストプラクティスやシステム設計の決定を記録している。意思決定はRequest for Comments（RFC）プロセスを経て合意に至り、Markdown形式のドキュメントとして残される。興味深いのは、製品決定やA/Bテストにおけるメトリクスをスコープとして高度に分類している点である。同社の実験プラットフォームでは、メトリクスを「Success」「Guardrail」「Deterioration」「Quality」などのカテゴリに厳密に分類し、複数の指標が絡むテストにおいて偽陽性・偽陰性のリスクを統計的に制御する意思決定ルールを標準化している。また、「Experiments with Learning (EwL)」という概念を導入し、成功しなかった実験であっても、十分な検出力を持ち中立的な結果を得た場合は価値ある学習として記録・分類している。運用上の課題としては、数百のチームが独立して意思決定を行うため、特定の技術（例えばReact Hooksの導入など）に関する決定が他のチームのアーキテクチャに波及する際の影響範囲の特定と、チームメンバーの入れ替わりに伴う意思決定コンテキストの移譲（Ownership Handover）が挙げられている。

GitLab Handbook (Engineering decisions)

GitLabは「Handbook First」という徹底した企業文化を持ち、アーキテクチャの意思決定もすべて公開されたハンドブックとDesign Documentの中で行われる。彼らは「Design as Code」というワークフローを採用しており、ADRや設計変更の提案はGitリポジトリ上のMerge Request（MR）として提出され、レビューと承認を経てMarkdown形式のサブページとしてマージされる。GitLabのScope運用における特徴は、影響範囲に応じた承認プロセスの厳格な制御である。SaaS全体（Instance）や顧客のデータ構造（Organization）に関わるような、複数部門の調整が必要な変更やシステム安定性に影響を与える決定については、Principalクラス以上の「Coach Engineer」の関与が義務付けられている。一方で、依存パッケージのバージョンアップや軽微なリファクタリングなど、スコープが限定的でチームが十分な経験を持つタスクについては、形式的なADRプロセスを免除する例外規定を設けている。これは、厳格なドキュメント化プロセスがもたらすオーバーヘッドと、ナレッジ共有のメリットとのバランスを取るための現実的なアプローチである。

ThoughtWorks Technology Radar (scope-based Adopt)

ThoughtWorksが定期的に発行するTechnology Radarは、技術やアーキテクチャの採用状況をスコープベースで分類するための強力な業界標準モデルとなっている。このレーダーは、技術的要素を4つのリング（Adopt, Trial, Assess, Hold）に分類する。このリングの概念は、ADRにおける意思決定のスコープとステータス管理に直接的な影響を与えている。「Adopt」は業界として、あるいは企業全体として全面的に採用すべき技術であり、「Trial」はリスクを許容できる限定的なプロジェクトスコープで試行すべきもの、「Assess」は企業にどのような影響を与えるか評価段階にあるもの、「Hold」は採用を見合わせるべきものを示す。このメタデータは列挙型（Enum）として機能し、意思決定の採用範囲を明確に定義する。組織内のアーキテクチャ審査ボードなどは、この分類を用いて「どの技術がどのスコープのプロジェクトで利用可能か」というガバナンスルールを構築している。

Structured MADR (Markdown ADR Records)

MADR（Markdown Architectural Decision Records）は、ADRをバージョン管理システム内でコードとともに管理するための軽量フォーマットであり、Structured MADRはその進化形として機械可読性を大幅に強化したものである。Structured MADRの最大の特徴は、ドキュメントの先頭にYAML形式のFrontmatterを配置し、メタデータを厳格に定義している点である。このFrontmatterには、category（文字列）、tags（配列）、project（プロジェクト識別子）、technologies（関連技術）、およびstatus（proposed, accepted, deprecated, superseded）などのフィールドが含まれる。さらに、relatedというフィールドを用いて、他のADRのファイル名を明示的に指定することで、ファイルシステム上のディレクトリ構造に依存せず、型付けされたリンク（Typed links）によって意思決定間のネットワークを構築する。この構造化されたメタデータにより、check-jsonschemaやajv-cliといったツールを用いて、CIパイプライン上でADRのメタデータが指定されたJSON Schemaに準拠しているかを自動検証（Linting）することが可能となっている。

Olaf Zimmermann の Decision Capture Framework (ADMentor / SOAD)

Olaf Zimmermannによるアーキテクチャ意思決定モデリングの研究は、意思決定を再利用可能な資産として扱うための学術的な基盤を提供している。彼のADMentorやSOAD（Service-Oriented Architecture Decision Modeling）フレームワークでは、意思決定を「Problem Space（解決すべき課題のモデル）」と「Solution Space（実際のプロジェクトでの決定）」に分離して管理する。Scopeのメタデータ運用において特筆すべきは、意思決定の陳腐化を防ぐために抽象度を3つのレベルに分類していることである。すなわち、技術に依存しない「Conceptual/Patterns」レベル、特定の技術基盤に関する「Platform/Technology」レベル、そして具体的な製品選定に関わる「Vendor/Product」レベルである。さらに、各意思決定にはUMLのタグ付き値としてメタ情報が付与され、関係性、時系列、ステークホルダー、影響力などの観点から整理される。実運用上の課題としては、これらの厳密なモデリング手法は高度な専門知識を要求するため、導入障壁が高く、アジャイルな開発現場においてはプロセスが重すぎると批判されることがある。

sventorben/decider と CodeOps の実例

近年、ADRのScopeメタデータをAI開発エージェントやCI環境と直接統合し、アーキテクチャ制約をコードベースに強制する「CodeOps」の事例が登場している。GitHub上で注目を集めるツール decider は、このパラダイムを体現している。このツールでは、ADRのYAML Frontmatter内に scope.paths というフィールドを設け、対象となるスコープをリポジトリ内の具体的なファイルパスを示すGlobパターン（例: src/db/, migrations/）として配列で記述する。CIパイプラインで decider check diff コマンドが実行されると、現在のブランチで変更されたファイルがADRで定義されたGlobパターンのスコープと一致するかどうかが自動的にチェックされ、一致した場合はそのADRの制約が適用される。さらに重要なのは、Claude CodeやGeminiなどのAIコーディングエージェントがこのメタデータをクエリし、「今から編集するファイルにはどのようなアーキテクチャ上の制約があるか」を事前にコンテキストとして読み込む統合機能（ADR Steward agent）が存在することである。これにより、ADRは単なる事後報告の文書から、AIの出力をガイドする事前制約へと昇華されている。

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

本プロジェクトのアーキテクチャにおいて最も特異かつ重要な前提条件は、「1人法人（代表取締役氏）＋AIエージェント（Claude / Gemini / GPT）」というハイブリッドな運用体制である。前述した業界の重厚なフレームワークや先進的な事例が、この極小規模かつAIネイティブなスケールにおいてどの程度適用可能であるかを評価し、スコアリングする。

小組織でも使える簡略化パターン

大企業向けのエンタープライズアーキテクチャを1人法人に適用する場合、階層の深さを「人間の認知限界」と「AIのコンテキストウィンドウ長」の最適値に合わせる必要がある。無数に存在する抽象的な階層は避け、「経営・法人（ビジネス）」「共通基盤（システムプラットフォーム）」「製品機能（アプリケーション）」「日々の運用（オペレーション）」という、物理的な境界やライフサイクルが明確に異なるレベルへとシンプルに圧縮するアプローチが推奨される。

1 人法人での "Corporate" の意味

一般的なエンタープライズフレームワークにおける「Corporate」や「Enterprise」レイヤーは、複数の事業部を横断する全社共通ルールやガバナンス基準を指す。しかし、1人法人において「Corporate」スコープは全く異なる意味を持つ。それは、**「法人格としての運用と、経営者個人の行動規範の同一化」**である。管理会計SaaSのソースコードには直接現れないが、法務方針、税理士との契約基準、就業規則や経費規程、GCP組織の契約主体、事業継続計画（BCP）など、SaaSの基盤を根底で支える意思決定がここに該当する。1人法人においては、経営者の意思決定が直ちにプロダクトの制約となるため、これらの非技術的な意思決定を「Corporate」スコープのADRとして残すことは、将来的にAIエージェントに「法人の意思決定コンテキスト全体」を学習させる上で極めて有効な手段となる。

過剰設計 (over-engineering) を避ける判定基準

1人法人におけるメタデータ運用の過剰設計を避けるためには、以下の2つの明確な判定基準を用いて意思決定の粒度をコントロールする必要がある。

1. 機械可読性のテスト: 「そのScope分類は、AIエージェント（Claude等）やCI/CDスクリプトが読み取って、何らかの自動化やコンテキストのフィルタリングに直接利用できるか？」という問いである。答えがNoであり、単に人間が情報を整理した気分になるだけの分類であれば、それは過剰設計である。
2. BezosのType 1 / Type 2 テスト: Amazonの創業者Jeff Bezosが提唱した意思決定モデルに基づく。Type 1は不可逆的で重大な決定（例: コアデータベースの選定）、Type 2は可逆的で元に戻せる決定（例: 一時的なツールの導入）である。Scope分類の枠組み自体を変更することや、メタデータのタグを付け替えることは、スクリプトで容易に修正可能なType 2の決定に属する。したがって、最初から完璧な分類設計を目指して議論を停滞させる（Analysis Paralysis）ことはアンチパターンであり、迅速に導入してAIとの親和性をテストするアジャイルなアプローチが求められる。

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

bizlpプロジェクトは、ADR-0020において既に「Tier（Light / Standard / Critical）」という重要度軸に基づく運用を確立している。ここに新たに「Scope（影響範囲）」の軸を加えることで、意思決定記録は2次元マトリクスとして管理されることになる。この2軸運用の妥当性と業界における実装事例を検証する。

2 軸マトリクスを ADR で運用している業界事例

重要度（Tier / Risk）と影響範囲（Scope / Boundary）を掛け合わせた2軸マトリクスの運用は、特に高度なガバナンスやセキュリティが要求される領域で強力なベストプラクティスとして実在している。

• US DoD (DoDAF): 米国防総省のアーキテクチャフレームワークでは、アーキテクチャの変更要求を「Tier（影響レベル）」と「Scope（適用範囲）」の2軸で評価し、必要な分析の深さや審査プロセスの重さを決定している。
• OWASP Secure-by-Design: ソフトウェアセキュリティのフレームワークにおいて、「Tier-1 Impact（データやビジネスに対する重大な影響）」という重要度と、「Trust Boundaries（システムの境界、すなわちScope）」の2軸を掛け合わせ、セキュリティアーキテクチャレビューの必要性と強度を判定している。
• Supplier Governance Engines: 企業のサプライヤー管理において、サプライヤーがもたらすリスクの「Tier」と、提供する業務の「Scope」のマトリクスを用いて、必要な監視やガバナンスのレベルを動的に調整するモデルが採用されている。

Scope 別に Tier の意味が変わるケースと直交性

Tier（重要度・不可逆性）とScope（影響範囲）の2つの軸は、論理的には完全に独立した**直交性（Orthogonality）**を保つ。しかし、Scopeの文脈が加わることで、Tierの持つ具体的な意味合いやリスクの質が変化する。

• Corporate × Light: この組み合わせは現実に存在する。例えば、経費精算用のSaaSツールの選定や、社内Wiki（Notionなど）のドキュメントテンプレート構造の決定などである。法人全体の運用（Corporate）に関わる決定であるが、後から容易に別のツールに乗り換えたり構造を変更したりできるため、不可逆性が低く事業への致命的な影響がない（Light）と判定される。
• Product × Critical: 管理会計SaaSの仕訳エンジンのコアアルゴリズムの変更や、データマートのスキーマ再設計などが該当する。特定の一つのプロダクト（Product）の内部に閉じた決定ではあるが、データの整合性に直結し、一度デプロイすると修正が極めて困難になる不可逆性の高い決定（Critical）である。
• Platform × Standard: CI/CDパイプラインツールの移行や、ドキュメント生成エンジンの変更などが該当する。全プロダクトの開発基盤（Platform）に影響を及ぼす広範な決定だが、業界標準のツールへの移行であり、リスクは予測可能かつ管理可能であるため、重要度は標準的（Standard）と評価される。

2軸運用の成功例と失敗例

• 成功例: AIエージェントにこの2次元メタデータを与え、ワークフローを自動化（CodeOps）したケースである。例えば、「CriticalなADRを変更する際は、必ず事前に影響分析スクリプトを実行する」「CorporateスコープのADRは、コード生成時ではなく、システム設計の初期プロンプトのコンテキストにのみ含める」といったように、TierとScopeの組み合わせに基づく決定論的なルーティングメカニズムを構築できる。
• 失敗例: 軸の定義が曖昧なまま運用を開始し、特定の意思決定がどの象限に属するかで迷う時間（Analysis Paralysis）が生じることである。これを防ぐためには、各象限に対する明確な具体例や判定フロー（Playbook）をADRのテンプレート内に明記し、分類作業の認知負荷を下げる工夫が不可欠である。

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

bizlpが提案している「Corporate」「Platform」「Product」「Ops」の4段階分類について、これまでの業界調査の結果と照らし合わせ、その整合性と妥当性を評価する。

過不足判定と1人法人スケールでの実用性

• 階層数の評価: 提案されている4段階の分類は理想的である。C4 Model（4階層）やAWS Well-Architected（4階層）、Azure CAF（4階層）など、業界の多くの堅牢なフレームワークが「4階層」を人間の認知限界とシステム境界のスイートスポットとして採用している。もし3段階以下であれば、SaaSにおいて不可欠な「共通基盤（Platform）」と「製品機能（Product）」の分離、あるいは「開発（Product）」と「運用（Ops）」の分離が表現できず、コンテキストが混在してしまう。逆に5段階以上に細分化すると、1人法人のメンタルモデルを不必要に圧迫し、分類作業自体が目的化するオーバーエンジニアリングのリスクが急激に高まる。
• 実用性: この提案の最も優れている点は、単なる「ソフトウェアシステム」のアーキテクチャにとどまらず、「法人経営（Corporate）」や「日々の業務運用（Ops）」という非技術的レイヤーをスコープに含めている点である。これは、Solo FounderによるSaaSプロジェクトの現実（ビジネスの意思決定とテクノロジーの実装が完全に融合している状態）を正確にモデリングしており、AIエージェントにプロジェクトの全体像を学習させるためのコンテキスト設計として、極めて実用性が高いと評価できる。

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

bizlpは、過去のADR-0022において既に「プラットフォーム / テナント」という2層の分離構造を確立している。この既存の構造から、新たに提案された4層（Corporate / Platform / Product / Ops）の多階層モデルへと移行するための、業界標準に則った拡張経路と移行戦略を提示する。

2 層 → 4 層への業界標準的な拡張パターン

アーキテクチャの進化において、初期の粗い粒度のレイヤーを、システムの成長に伴ってより専門的で細かなレイヤーに分解する（Refactoring coarse-grained layers）ことは、極めて一般的な拡張パターンである。

• 既存の**「プラットフォーム（共通基盤）」**層は、純粋な技術的基盤としての Platform と、法務・契約・組織ルールなど非技術的・法人レベルの前提条件である Corporate の2つに明確に分解される。
• 既存の**「テナント（顧客向け領域）」**層は、ソフトウェアの機能やデータモデルとしての Product と、それを安全に稼働させ維持するための業務プロセスやモニタリングである Ops の2つに分解される。

ADR-0022 との関係性 (Supersede vs Extends)

ADRの運用において、過去の決定をどのように扱うかは重要な論点である。過去の決定が明らかに誤りであったり、根本的な方針転換（例えば、リレーショナルデータベースからNoSQLへの完全な移行など）を伴ったりする場合は、新しいADRが古いADRを Supersedes (取って代わる／無効化する) というステータスを使用する。

しかし今回の場合、ADR-0022が定めた「共通基盤とテナントの分離」というアーキテクチャの大原則自体は全く間違っておらず、新提案はその原則を維持したまま粒度を細分化したものに過ぎない。このようなケースでは、過去のコンテキストを保護するために、新しいADRはADR-0022を Extends (拡張する) または Amends (修正・補足する) という位置づけで発行するのが業界のベストプラクティスである。

拡張に伴う既存ADRの遡及分類戦略

現在、48件の既存ADRが存在する。新しい4階層分類を新規のADRにのみ適用した場合、システム内に古い2層分類と新しい4層分類のメタデータが混在する「スプリットブレイン状態」に陥る。これは、AIエージェントがYAML Frontmatterを読み取って過去の意思決定を検索・フィルタリングする際の精度を著しく低下させる。

AWSのADRプラクティスガイダンスにおいても、「利用可能なデータがある場合、既知の過去の決定に基づいてADRを遡及的に生成・更新すべきである」と推奨されている。

推奨アプローチ: 既存の48件のMarkdownファイルを手動で修正するのではなく、ClaudeやGeminiなどのLLMを活用して移行スクリプトを作成させる。LLMに各ADRのテキストを読み込ませ、新しい4つのScope（Corporate, Platform, Product, Ops）のいずれかに自動判定させ、YAML Frontmatterの scope: フィールドを一括で書き換えるバッチ処理を実行する。48件程度であれば、この移行作業は極めて低コストかつ短時間で完了する。

拡張に伴うリスク評価 (Bezos Type 1 vs Type 2)

Jeff Bezosの意思決定フレームワークに照らし合わせると、メタデータのタグ付けルールの変更や分類階層の拡張は、典型的な Type 2（可逆的な意思決定） である。仮に4階層分類で運用を開始した後に、特定の階層が機能しない、あるいはAIエージェントの解釈に不都合が生じると判明した場合でも、上記と同様のスクリプト処理によって、いつでも元の2階層に戻すか、別の分類体系に再編成することが可能である。

したがって、この拡張に伴うリスクは極めて低い。事前の過剰な分析や完璧なルールの策定に時間を費やすのではなく、直ちにADRを発行して新しいメタデータ運用を開始し、AIエージェントとの実際のインタラクションを通じて分類の親和性を継続的にテスト・調整するアジャイルなアプローチが強く推奨される。

bizlp 採用推奨案

推奨Scope階層: 提案の4段階を採用する。

階層名: Corporate(法人/組織), Platform(全社基盤), Product(製品固有), Ops(運用統制)。

実装方法: YAML Frontmatterに category: <Scope> と物理影響範囲 paths: [glob] を記述しAIのコンテキスト制御に直結させる。採番は連番を維持。

ADR-0022との関係: 方針を否定しないため「Extends」とする。既存48件はAIスクリプトで遡及的に再分類しメタデータを統一する。

Tier連動: Scope×Tierの直交2軸マトリクスとし、SaaS全体への影響度と不可逆性を動的に評価する。