RQ-050 ADR Scope 多階層分類業界ベストプラクティス調査（GPT-5 Deep Research 結果）

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

業界では、意思決定やアーキテクチャ文書を複数階層で分類する例がいくつか見られます。主なものを挙げると：

IASA Global BTABoK（Business Transformation Architecture Body of Knowledge） – 決定スコープを6層で定義（Ecosystem, Enterprise, Value Stream, Solution, Product/Service, Module）【17†L176-L184】。大規模組織向け（公共・大企業）。例：国や業界全体（Ecosystem）→企業レベル（Enterprise）→事業部門→ソリューション→製品/サービス→個別モジュール。
英国政府ADRフレームワーク – 4層（Team/Working Group, Cross-team/Programme, Department/Strategic, Cross-government/National）【45†L229-L237】。政府機関向け。2018年頃から策定、最新版公開2025年。例：単一チーム内→複数チーム／プログラム→省庁横断→国家レベル。
TOGAF v10（The Open Group） – 3層：Enterprise, Segment, Capability Architecture【35†L2953-L2956】【38†L2712-L2715】。大企業のエンタープライズアーキテクチャ向け。公開2022年（v10）。例：全社戦略（企業全体）→各事業部門や事業機能（セグメント）→個別機能／プロジェクト（能力）アーキテクチャ。
C4モデル（Simon Brown） – 4階層：System Context, Containers, Components, Code【31†L46-L53】。ソフトウェアシステム設計向け。サイズを問わず利用可（主に開発チーム向け）。例：システムと外部の文脈図→システムを構成するアプリ/コンテナ図→コンテナ内モジュール図→コードレベル詳細。2011年提唱、継続更新。
その他：アーキテクチャ分野ではArchiMate（Business/App/Technologyの3層）や各社クラウドフレームワークなどもあるが、ADRのスコープ分類と直接対応する例は限られます。

これらは正式資料に基づき、組織規模や策定時期も様々です（例：IASAは2020年代にBTABoK発行【17†L176-L184】、TOGAF v10は2022年版【35†L2953-L2956】など）。いずれも大規模組織向けの分類が多い点に留意が必要です。

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

TOGAF v10: Enterprise（企業全体）／Segment（事業部門）／Capability（機能）アーキテクチャ【35†L2953-L2956】【38†L2712-L2715】。Enterprise層には企業戦略や組織全体の方針が含まれ、Segment層は特定事業部門やドメイン単位の詳細設計、Capability層は個別プロジェクトや機能の実装設計を扱います。境界条件は「企業横断か部門横断か局所か」で判断します。例えば全社ERP選定はEnterprise、営業部門専用システムはSegment、特定機能選定はCapabilityとなります。越境アンチパターンとして、局所の技術選択を企業全体方針として扱ったり（Capability→Enterpriseの混合）、逆に全社方針を局所問題として下位で議論することが挙げられます。
C4モデル: System Context（システム全体と外界）、Containers（システム内のアプリ/サービス/DBなど）、Components（コンテナ内のモジュール）、Code（ソースコード）【31†L46-L53】。各層は階層的に詳細化を進めます。境界は明確で、Context図には内部構造を含めず外部連携を示し、Container図にはコンテナ間の連携を、Component図にはコンテナ内の部品構造を示します。アンチパターンは、Context図に細部（クラス図等）を入れすぎたり、逆に詳細化図に不要な外部アクターを含める等、レイヤー混在による複雑化です。
AWS Well-Architected Framework: 層構造は明示されておらず、セキュリティ・信頼性・コストなど5つの柱（Pillars）による考え方です。スコープとしては、AWS Organizationsを用いた企業レベルのポリシーと各アカウント（ワークロード）レベルでの設計を意識します。例えば組織単位でセキュリティ基準を定め（企業層）、ワークロード単位で具体設計を行う（アプリ層）といった区分です。アンチパターンには、組織階層を使わずに各アカウントを独立運用したり（企業ガバナンス欠如）、柱を無視してコスト・性能などの観点を抜きに設計することがあります。
Azure Cloud Adoption Framework（CAF）: Platform層とApplication層の考え方があります。最近の用語では、Platform Landing Zone（全社共通インフラ／管理グループ配下、テナント直下まで）とApplication Landing Zone（各ワークロード用サブスクリプション）とを区別【77†L81-L89】。境界は管理グループ／サブスクリプションレベルで、Platform層は組織基盤（ID管理、課金、ネットワーク等）を担い、Application層は個別アプリやサービスに対応します。アンチパターンは、ワークロード専用リソースをPlatformに混在させたり、逆に共通リソースを個別サブスクリプションにばらまくことです。
Google Cloud Architecture Framework: Well-Architected Frameworkは柱と視点ベースであり、明示的な階層構造は持ちません【83†L831-L839】。組織（Organization）→フォルダ→プロジェクトというGCPリソース構造がスコープの実質的な境界になります。すなわち、組織レベルでIAMや組織ポリシー、プロジェクト単位でアプリケーションリソースを管理します。アンチパターンは、1つのプロジェクトに複数ワークロードを詰め込んだり、組織レベルのポリシーを無視してサブスクリプションレベルで無秩序に設定することです。

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

業務上のADR運用例からスコープ扱いを調査しました：

Spotify Engineering Blog (Decision Log): ADRは技術ブログ記事として公開【49†L61-L69】。形式はMarkdown（ウェブ記事）で、YAML等のメタデータは使用しません。「重要な影響があればADRを書くべき」といった指針のみが示される【49†L61-L69】。したがってスコープの項目はなく、内容は自由記述です。専用CI/adr-lintによる検証はなく、レビュープロセスやチーム内合意で運用されています。
GitLab Handbook (Engineering decisions): GitLabではADRをハンドブックのMarkdownページとして管理し、設計文書からリンクします【53†L7-L11】。ここでも専用のscopeフィールドはなく、ADRは「Context, Decision, Consequences, Alternatives」等のセクション構成で記述されます【53†L7-L11】。公式に10日間のレビュー期間を設けるプロセスはあるものの【53†L19-L26】、メタデータの自動検証ルールは公開されていません。スコープはプロジェクトやプロダクトごとに暗黙的に区分される程度で、明示管理は行っていません。
ThoughtWorks Tech Radar: 企業や組織向け技術導入判断の資料であり、ADRフォーマットではありません。「Adopt/Trial/Hold」など採用度合いを示すものの、個別プロダクト意思決定ドキュメントではありません。スコープメタデータの指定はなく、組織規模別のアドバイスも特に分けていません（スコープベース運用例は見当たりません）。
MADR v3以降 (Markdown ADR): Michael NygardらによるMarkdown ADRテンプレート【56†L23-L30】。メタデータはYAML前文を推奨【56†L23-L30】し、標準項目としてStatus, Decision Maker(s), Dateなどが利用されます（必要に応じてcategoryやタグも設定可能）。scope専用フィールドはなく、カテゴリ（例：frontend/backendなど）も運用者依存です。adr-lint的にはMarkdownLintの設定例が提供されており【58†L13-L17】、フォーマットの一貫性を自動チェックできます。運用上の課題としては、YAML前文がMarkdown標準外であることや、カテゴリ管理方法の議論（YAML vs フォルダ分け）があります【60†L99-L107】【60†L119-L127】。
Olaf Zimmermann's Decision Capture Framework: Olaf Zimmermann氏らの提唱する設計意思決定ガイドラインでは、ADRの対象を「ソフトウェア設計以外にも組織的・運用的決定まで拡張すべき」と論じられますが、メタデータフォーマットの具体例は示していません【62†L39-L49】。独自のY文やスコープ分類はなく、むしろ記録の重要性や基準に重きを置いた理論的枠組みです。
その他大規模ADRリポジトリ: 例えば「structured-madr」（GitHub Action付きMADR拡張）ではYAMLメタデータを細かく定義し、CIでJSONスキーマ検証を行えます【87†L359-L367】【87†L529-L538】。ここではcategoryやtagsなど自由記述のタグ・列挙を使いますが、運用コストが高く批判されています（スタートアップやソロには過剰）【87†L359-L367】【87†L529-L538】。10,000★超のプロジェクトで明確なスコープ管理例は少なく、一般には上述のようにMarkdownベースで軽量化するケースが多いようです。

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

上記フレームワーク・事例について、1人法人（Solo Founder＋AIエージェント）規模での適用性を検討します：

TOGAF v10 – スコア:2/5。大企業前提で専門チーム向け【35†L2953-L2956】。知識が豊富だが1人開発には過剰です。簡易化案としては、企業全体を自身とみなしSegment/Capabilityを事業/プロジェクトに簡素化する程度です。
C4モデル – スコア:5/5。開発者向けで軽量【31†L46-L53】。視点分けが明快で小規模プロジェクトにも使いやすい。過剰設計にならないため、1人体制で即実践可です。
AWS Well-Architected – スコア:3/5。AWS前提で規模を選ばないが、組織ガバナンスやリソース管理の複雑さは企業向け要素も含む。1人なら主要な柱（セキュリティ、コスト）に集中し、オーガナイズ機能は最小化可能です。
Azure CAF – スコア:2/5。Landing Zoneや管理グループなど企業クラウド向け設計。1人法人ではAzureテナント規模も小さいため、プラットフォーム層の多重構成は過剰です。簡略化例としては、シンプルにサブスクリプションをひとつ用意し、ワークロードごとにプロジェクト分けする程度で十分です。
Google Cloud Architecture – スコア:3/5。基本的にはガイドライン群だが、組織運営やプロジェクト管理機能は企業並みに用意されている。1人の場合はOrganization→Projectの基本階層だけ使い、深いフォルダ階層やSSO統合は利用しなくて可。
Spotify ADR的アプローチ – スコア:4/5。ブログ記事に書くスタイルは極めて軽量。ガイドも「重大な決定時にADRを書く」というシンプルさ【49†L61-L69】。ただし形式化がないのでドキュメント粒度の判断が難しい点には注意。
GitLab Handbook方式 – スコア:3/5。内製プロセスが整っており信頼性は高い【53†L7-L11】【53†L19-L26】。しかしレビュー期間やページ管理は1人で維持するには手間です。サイズに応じてドラフト運用とするなど簡素化が必要です。
MADR v3 – スコア:5/5。Markdown + YAML前文で柔軟【56†L23-L30】。必要最小限のテンプレートで済むため、フットワーク軽く導入可能です。
Structured MADR – スコア:2/5。YAML前文＋JSONスキーマ＋リスク評価と非常に詳細【87†L359-L367】【87†L529-L538】。コンプライアンス用途には有用ですが、1人の管理会計プロダクトには過剰設計です。

総評：大企業向けのTOGAF/Azureは1人で使うには不向きで低評価です。一方、C4やMADRのような「現場で使える軽量なもの」は高評価です。過剰設計を避ける基準としては「階層やフィールドの追加に必要以上の手間がかかるか」を見ると良いでしょう【60†L99-L107】。Soloでは「Corporate＝法人全体」ではなく経営者自身の判断とほぼ重なるため、この層の扱いは簡易化できます。

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

Tier（重要度/緊急度）とScope（影響範囲）の2軸マトリクスをADR管理に用いる事例は、明確な公開例は見当たりませんでした。たとえばIASA BTABoKはスコープ層を示します【17†L176-L184】がTierとのマトリクス化はせず、Tier相当の概念（例えば発生事態の深刻度）も別枠です。またGitLabやSpotifyの例ではTier（Light/Standard/Critical）とScope（チーム/事業部等）は独立したパラメータとして扱われています。実際、Scopeが大きくなるほど一般にTierも高くなりやすい（企業全体の方針変更はクリティカル傾向）が、必ずしも完全に連動するわけではなく、軽微な企業施策（Corporate×Light）のような組み合わせが理論上はあり得ます。したがって二軸は独立して運用し、Tierごとの意味合いをScope別に使い分ける設計が現実的です。

（参考：英国ADRフレームワークは階層別決定レベルのみ示し【45†L229-L237】、Tier×Scope併用例は見当たりませんでした。）

Q6. bizlp提案4段階分類の妥当性

bizlp案（Corporate/Platform/Product/Ops）の各層名と対応性を業界標準と照合します：

Corporate（法人運営・組織）: 一般的に「Enterprise/Organization」層に相当し、TOGAFなどでも組織全体アーキテクチャを扱います【17†L176-L184】。bizlpの「Corporate」表現はやや俗語ですが意味は合致します（○）。ただし「Enterprise Architecture」という用語が定番です。
Platform（基盤・共通基盤）: クラウドCAFのプラットフォーム層【77†L81-L89】や基盤アーキテクチャに近く整合性があります（○）。名称としては「Infrastructure/Foundation」層とも呼び換え可能です。
Product（プロダクト固有）: ソリューションやアプリケーションレイヤーに当たり、典型的な製品/サービス開発の範囲なので問題ありません（○）。
Ops（日常運用・統制）: 一般のEAでは「運用プロセス」「ガバナンス」的に扱われますが、独立層とする例は少ない（△）。運用・保守作業の扱いとしては、プロダクトやビジネスプロセス層に含まれることも多いからです。
階層数: 4層は中規模組織向けとして妥当です。大企業ならさらに細分化（>5層）、小規模なら3層（たとえばCorporate+Platform+ProductでOpsを含める）でも運用可能でしょう。1人法人なら3層でも十分ですが、4層にしておけば「法人運営」と「プロダクト技術」を明確に分けられる利点があります。

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

ADR-0022の「Platform/Tenant（二層）」から4層への拡張は、業界標準の決定ルールは無いものの、一般的には次のように実施します。元の「Tenant」をBizlpのProduct（製品/サービス固有）層に再定義し、「Platform」を基盤層として維持、その上位に「Corporate（組織・法人）」層、下位に「Ops（運用・統制）」層を追加します。例：UK政府のADRレベルがTeam→Dept→政省横断→全国レベルの4層になっているように【45†L229-L237】、元2層を4層に細分化します。ADR-0022との関係は**"Extends（実装拡張）"**とするのが適当です。つまり、ADR-0022は共通基盤vsプロダクトの区分を示す規約として残しつつ、新たに4層対応の規則を別ADRで定義します。既存48件のADRについては、過去情報を逐次書き換えるより、新規作成分から順次新体系を適用する運用が実用的です。拡張作業自体は内部文書ルールの変更に過ぎないため、意思決定としては取り消し可能なタイプ（「Type 2」）と考えられます。誤りがあっても後から修正可能です。

bizlp 採用推奨案

4層階層構成を基調に、やや名称を補正して採用します。具体的には Corporate (企業/組織層)、Platform (共通基盤層)、Product (プロダクト層)、Ops (運用層) と命名します（英語/日本語併記）。実装方法としては、各ADRのYAMLフロントマターやファイルパスに scope: フィールドを追加し、上記4つから1つを選択する運用を推奨します。例：scope: Corporate など。ディレクトリ分け（例: adr/corporate/001-*.md）や識別子付与も併用可です。ADR-0022は本案にExtendsされる形とし、既存ADRは従来分類のまま残して新規から4層を適用します。Tier（Light/Standard/Critical）はScopeとは別の属性として保持し、両者を組み合わせて使い分ける方針とします。これにより、法人運営から技術実装まで各層で一貫したドキュメント管理が可能となります。