最終更新: 2026/06/22 18:56
commonid: rq-101-result-claudetype: research-resultstatus: active

RQ-101: ADR 意思決定の役割・承認者体系 — Claude deep research 結果

調査: 2026-06-08、Claude deep-research（5 アングル並列・WebSearch ベース）。OpenAI / Gemini 分は別途実行し synthesis で突合する（本ファイルは Claude 単独の生結果）。 検証上の注意: 本環境では WebFetch が全 URL で 403。各 claim は WebSearch が返す権威ソースの引用スニペットに基づく（全文 fetch ではない）。正式採用前に一次資料の verbatim 確認を推奨（特に J-SOX FSA PDF / IIA Three Lines / ISO 42010）。

Executive Summary（5 key findings）

  1. 決定には RACI より DACI/RAPID が適合。RACI の "Accountable" は「タスクの sign-off 所有者」で、「誰が決めるか」と「誰が承認するか」を混同する（McKinsey が同理由で決定特化の DARE を提唱）。3 フレームワーク共通の不変量＝「Accountable/Decide/Approver は決定ごとに1人」。
  2. ADR 形式は「誰が責任者か」を意図的に薄くしか書かない。Nygard=記載なし（Git の merge 権限＝承認）、MADR=decision-makers（任意・複数リスト＝関与者）。監査向けには AWS 流「単一 ADR owner」＋ Git/PR の不変承認が defensible。
  3. 監査レジーム（J-SOX/COSO/ITGC/COBIT/ISO）は一致：承認証跡は帰属可能・時刻付き・改ざん耐性を持ち、**権限を持つ“名前のある承認者”**を特定すること。かつ 職務分掌（SoD）＝起案者≠承認者≠実装者。accountability は単一かつ委譲不可。
  4. security / legal は「層」でなく「横断的関心」が決定的に標準（ISO25010 品質特性・arc42 #secure/#safe・TOGAF「security as a cross-cutting concern」・AWS security pillar＝レンズ）。運用は関心タグ（リスク/データ分類/外部露出/規制）→ 必須レビュアー＋ゲート発火（threat-model ゲート・DPIA ゲート）。
  5. 外部専門家・AI は Consulted/Input（拒否権なし・責任を負わない）。EU AI Act 第14条が「人間が解釈・無効化・停止できる」設計を要求＝AI は助言、責任は人間/組織。ソロ→チームは「役割を抽象定義し人を後から割当」＝過去決定の書き直し不要。

→ 会話で立てた草案（単一 Accountable／decider≠executor／外部・AI は Consulted／security・legal は concern）は業界照合で強く支持される。主な補正は2点：(a) 語彙を RACI より DACI 寄りに、(b) decider/executor 分離を 監査統制（SoD）として位置づけ、ソロでは補償統制で代替。

設問別分析

Q1. 決定権限フレームワーク（RACI / RAPID / DACI / 他）

  • RACI の核は "A" は1人（"the buck stops there"）。最頻の失敗は A を複数置くこと（責任の拡散）[Wikipedia RAM; CIO.com]。
  • RACI はタスク用で、決定では "Accountable"（sign-off 所有）と "誰が決めるか" がズレる。McKinsey は決定特化の DARE（Deciders/Advisors/Recommenders/Execution）を提唱 [McKinsey "limits of RACI"]。
  • RAPID（Bain）：D=Decide は単一の説明責任点、集団なら tie-break を事前合意。Agree（拒否権）と Input（助言）を分離し「全員決定（麻痺）」「誰も決めない（漂流）」を防ぐ。ただし小規模・低リスク・時間制約では重すぎ [Bain; ExpertPM; Plan.io]。
  • DACI（Atlassian）：Approver はちょうど1人、Driver（プロセス進行）と分離、Contributor は「声はあるが票はない」。決定用に設計され ADR/decision テンプレに直接使われる（Confluence DACI テンプレ） [Atlassian Team Playbook; project-management.com]。
  • 単一オーナー系の最小形：Apple DRI（1人に唯一の説明責任）[growthwise/productive.io]。
  • 実務指針：実行＝RACI / 重要決定＝DACI / 稀な高リスク全社決定＝RAPID [Centercode; Routine]。

→ ADR 向け推奨：DACI（または1行 DRI）。RAPID は複数拒否権が要る稀な決定だけ。 不変量は常に「決定ごとに単一の accountable decider」。

Q2. ADR への accountability 記録

  • Nygard 原典＝Title/Status/Context/Decision/Consequences の5節のみ、deciders/approver 欄なし。承認は Git の commit/merge 権限＝PR merge で Status→Accepted、承認者は履歴に残る [cognitect; Fowler]。Accepted は不変、変更は supersede [Fowler]。
  • MADR＝decision-makers（旧 deciders）は任意・リスト＝「関与者」。consulted/informed も任意（RACI の C/I 相当だが単一 A の枠はない）。YAML front matter 採用（ADR-0013）[adr.github.io/madr]。
  • Y-Statements＝6要素、deciders 要素なし（根拠を残すもので説明責任は記録しない）[olzzio]。
  • Structured MADR (zircote)＝deciders 欄を捨て 必須 author + 本文 Audit 節（compliance status・findings table）[smadr.dev]。
  • 実務は二分：単一オーナー（AWS "ADR owner"・DACI 1-Approver）vs 合議（Spotify RFC→ADR・PMD maintainer consensus・EdgeX TSC vote）。合議は buy-in を得るが個人の説明責任が拡散する [InfoQ; shortform]。

→ 監査ありなら「記録に単一 accountable approver を明記（AWS/DACI 流）＋ Git/PR の不変承認」で文書と commit 履歴を一致させる。 関与者は consulted/informed として任意列挙。

Q3. 横断的関心（security / legal）

  • 横断的関心＝logging/security/error 等、複数コンポーネント・層に跨る側面 [Wikipedia; GfG]。security は古典的な横断的関心 [GfG microservices]。
  • TOGAF は明示的に「Security as a Cross-Cutting Concern」と題し、Business/Data/Application/Technology の4ドメインを横断して informする（層の1つではない）[OpenGroup TOGAF]。
  • arc42 Q42 は ~200 品質を9次元に圧縮し #secure/#safe 等のタグで付与（層でなく要求・approach に貼る）。ISO/IEC 25010 は Security/Safety をトップレベル品質特性として定義 [quality.arc42; iso25000]。
  • AWS Well-Architected は Security を6 柱の1つ＝全 workload に適用する原則／レンズ（"defense in depth … all layers"）[AWS WA]。NIST CSF 2.0 は Govern を横断 function に昇格 [MSSP/NIST]。
  • 運用パターン＝関心属性でゲート発火：データ分類・外部露出・規制範囲の質問票 → threat-model 要件・レビュー checkpoint を割当（Microsoft SDL）。threat modeling は設計フェーズのゲートで Privacy-by-Design を内包。Security Champions（OWASP/SAFECode）は埋め込みレビュアー役（別ドメインでない）。GDPR DPIA は高リスク閾値超過時のみ必須＝データ分類タグがレビューを起動 [MS SDL; approach-cyber; OWASP; IAPP]。

→ security/legal は「concern タグ → 必須レビュアー/ゲート発火」で扱うのが決定的に標準。Scope 層に足さない。 唯一の留保：TOGAF の「Security Architecture」discipline は存在するが、それも4ドメインを上書きする位置づけ。

Q4. 外部専門家・AI レビュアー

  • RACI で外部 SME（法務・財務顧問）は Consulted＝事前に意見を求めるが説明責任は持たない・拒否権なし [umbrex; triaster]。accountability は委譲不可（doing は委譲可、outcome 所有は不可）[Atlassian RACI]。
  • RAPID で助言者・専門家は Input（拒否権なし）、Decide は単一の上級内部者 [Bain; umbrex]。
  • EU AI Act 第14条：高リスク AI は人間が監視・解釈・介入・停止できる設計必須。14(4) は人間が AI 出力を不使用/無視/上書き/反転できることを要求＝最終決定権は人間。14(4)(b) は自動化バイアス対策を義務化（AI 出力は助言）[euaiact; artificialintelligenceact.eu; arXiv]。CI/CD でも AI ゲートは**advisory（非ブロッキング）**が基本、重大点は人間承認（SR 11-7 等）[augmentcode]。

→ 外部専門家・AI critic はともに Consulted（責任を負わない）。最終 accountable は内部の名前付き1人のまま。 これは前提と完全一致。

Q5. ソロ→チームのスケール

  • 創業者は複数役割を兼任（CEO+CFO+Product+CMO）し、成長（Series A 付近）で専門役員へ押し下げ＝束の分割 [medium gostartup]。
  • 組織設計の原則：役割を個人と分けて定義（役割を先に定義し人を割当）＝構造変更が「人格の問題」にならない [organizationdesign.net]。
  • RAPID/RACI は1人が複数役割を持つことを許容しつつ Decide/Accountable は単一に保つ。成長で役割の再割当（過去の書き直しでない） [asana; leantime]。

→「役割を抽象定義し人を後から割当」が durable パターン。creator の束を CTO/CFO 等へ割るのは再割当であって過去 ADR の rewrite ではない。 前提と一致。

監査要件（Q2/Q3 を貫く横断発見）

  • J-SOX（FIEL 内部統制）＝承認/権限付与を中核 control activity とし、統制の文書化＋有効運用の証跡保持を CPA 監査・FSA 監督下で要求 [FSA PDF; EisnerAmper]。
  • COSO 原則10/11（control activities・technology general controls）、SoD＝承認と記録の分離、不可能なら補償統制 [legalclarity; Deloitte]。
  • ITGC/SOX 監査＝変更の requester / approver / implementer の SoD を検証、誰が要求・承認・実施・検証したかを記録。監査証跡は改ざん耐性・時刻付き・名前付きユーザに帰属、承認者は当時その権限を持っていたこと [complyfactor; yhb; kissflow]。
  • COBIT 2019 の RACI は objective ごとに Accountable は1つ [ISACA]。IIA Three Lines ＝統治体が監督の単一説明責任点で委譲不可 [CharteredIIA]。
  • ISO/IEC 27001:2022 A.8.32＝変更は適切な権限者が承認・記録保持。ISO/IEC/IEEE 42010＝architecture description の必須識別情報に "approving authority" を含む [isms.online; iso-architecture]。
  • 規制総意：アウトソースしても説明責任はアウトソースされない（FCA 等）。doing は第三者/自動化へ委譲可だが、最終 accountable は内部に残る [FCA; Lexology]。

→ 監査は「名前付き承認者＋改ざん耐性証跡＋ SoD」を要求。decider≠executor は粒度の話だけでなく“監査統制”でもある。ソロは SoD 不能 → COSO の補償統制（AI 審査・不変 Git 履歴・外部監査）で代替するのが筋。

推奨役割タクソノミー → ADR メタデータ写像

役割（抽象・DACI 寄り）定義ADR メタデータ監査上の意味
Approver（=Accountable・単一）決定の最終責任。Scope が決めるapprover: { role, who }（1つ）名前付き承認者・SoD の "approver"
Driver（=起案・実装/ executor）プロセス進行・実装。Rdriver: who / Git authorSoD の "requester/implementer"（approver と分離）
Contributors（=Consulted）助言（拒否権なし）。外部専門家・AI critic・3モデルconsulted: [...]助言者。責任を負わない
Informed事後通知informed: [...]（任意）—
横断的関心（concern）security/legal/privacy/costconcerns: [secure, legal, ...]タグ→必須レビュアー/ゲート発火
  • Approver は Scope（Corporate/Platform/Product/Ops）から導出（会話の設計を維持）。
  • 承認の不変証跡は Git/PR merge（Nygard 流）＝文書の approver と commit 履歴を一致させる。
  • ソロの現在：approver.who と driver が同一でも role を記録 → 将来 who 分離で監査単位成立。SoD 不能を補償統制（AI 審査＋不変履歴）で明示。

RACI vs RAPID vs DACI（ADR 用途比較）

観点RACIRAPIDDACI
設計対象タスク/成果物重要・全社決定決定（ADR 向き）
単一説明責任A は1人D は単一（集団は tie-break）Approver 1人
拒否権の分離なしあり（Agree）なし（Contributor は票なし）
軽さ（小規模）中（語の混同あり）重い軽い
決定 vs 実行の分離弱い（A が混同）明確明確（Approver≠Driver）
ADR テンプレ実在——あり（Atlassian）
推奨用途実行作業稀な高リスク多拒否権決定既定の ADR 決定

優先度ランキング

Must-have

  • ADR ごとに 単一 Approver（Scope 由来） を記録＋ Git/PR の不変承認で一致
  • 外部専門家・AI critic = Consulted（責任なし）、最終 accountable は内部
  • security/legal = concern タグ → 必須レビュアー/ゲート（Scope 層に足さない）
  • SoD の明示と、ソロでの補償統制（AI 審査・不変履歴・外部監査）

Should-have

  • 語彙を DACI 寄り（Approver/Driver/Contributor/Informed）に。RACI からの写像表を残す
  • concerns: と必須レビュー発火条件（データ分類・外部露出・規制範囲）の定義
  • 役割を抽象定義し人を後から割当（過去 ADR を書き直さない移行規約）

Nice-to-have

  • RAPID 形式（Agree=拒否権）は「複数拒否権が要る稀な Critical 決定」だけのオプション
  • ISO 42010 "approving authority" 準拠を frontmatter スキーマに明記
  • DPIA/threat-model ゲートの軽量チェックリスト（OWASP ASVS 等）

References（主要・3モデル synthesis 前の Claude 分）

決定権限フレームワーク

ADR への記録

監査・ガバナンス

横断的関心 / ゲート

外部専門家・AI

スケール

注: WebFetch 403 のため上記は WebSearch 引用スニペット基準。OpenAI / Gemini の生結果を加えた synthesis（rq-101-...-synthesis.md）で 3 モデル合意度を確定する。