RQ-101: ADR 意思決定の役割・承認者体系 — 3モデル synthesis

調査対象は「ADR の決定権と説明責任モデル」。ソロ法人が監査要件下で複数役員体制へスケールする前提で、誰が単一の accountable approver か、各決定まわりの関係者役割をどう定義するかを問う。

3 モデル: Claude deep-research (2026-06-08) / OpenAI o3-deep-research (2026-06-09) / Gemini deep-research-preview (2026-06-09)。 生結果は claude / openai / gemini。

結論（先に）

本プロジェクトの草案は 3 モデルとも強く支持した。採用してよい。補正は語彙と監査上の位置づけの 2 点だけ。

草案（検証対象）:

• 決定ごとに Accountable は 1 人。Scope がどの役割を accountable にするか決める。
• Responsible/executor と accountable/decider を分ける。決定は executor 境界でなく accountable 境界で割る。
• 外部専門家（税理士・弁護士）と AI レビュアーは Consulted。accountable には絶対しない。
• security / legal は Scope 層に足さず、横断的関心として必須レビューを発火させる。

補正 2 点:

1. 語彙は RACI でなく DACI 寄りにする。RACI の "Accountable" は「誰が決めるか」と「誰が承認するか」を混同するため。
2. decider≠executor を「粒度の話」でなく 監査統制（職務分掌 SoD） として位置づける。ソロでは SoD が成立しないので補償統制で代替する。

3 モデル合意マトリクス

注: Gemini は RACI を前提に「ARB / CTO が Accountable」とする。DACI を名指ししないが、「決定ごとに単一 Accountable」という不変量は共有する。Claude・OpenAI はともに RACI より DACI が ADR に適合と明言。語彙の差であり、結論は衝突しない。

設問別 synthesis

Q1. 決定権限フレームワーク

3 モデル共通の不変量は「決定ごとに Accountable / Approver / Decide は 1 人」。

• DACI を既定にする（Claude・OpenAI 一致）。Driver と Approver を分離し、Contributor は声はあるが票はない。ADR/decision テンプレに直接使われる実績がある。
• RACI はタスク実行向けで、決定では "Accountable" が decider と承認者を混同する。RACI を使うなら必ず DACI への写像表を添える。
• RAPID は重い。複数の拒否権（Agree）が要る稀な Critical 決定だけのオプション。
• 最小形として Apple の DRI（1 人に唯一の説明責任）も同じ思想。

Q2. ADR への accountability 記録

• ADR 原典（Nygard）は承認欄を持たない。承認は Git の merge 権限 で表現し、PR merge で Status→Accepted。承認者は履歴に残る。
• 監査ありなら「記録に単一 approver を明記（AWS の ADR owner / DACI の 1-Approver）＋ Git/PR の不変承認」で文書と commit 履歴を一致させる。
• 監査レジーム（J-SOX / COSO / ITGC / ISO 27001 A.8.32 / ISO 42010）は一致して、承認証跡に「帰属可能・時刻付き・改ざん耐性・権限を持つ名前付き承認者」を要求する。
• ISO/IEC/IEEE 42010 は architecture description の必須項目に "approving authority" を含む。frontmatter に approver を持つ根拠になる。

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

横断的関心として扱うのが決定的に標準。Scope 層に足さない。3 モデル一致。

• 根拠: TOGAF「Security as a Cross-Cutting Concern」/ arc42 の品質タグ / ISO 25010 のトップレベル品質特性 / AWS Well-Architected の Security 柱（全 workload に適用するレンズ）。
• 運用: 関心タグ（リスク・データ分類・外部露出・規制範囲）→ 必須レビュアー＋ゲート発火。threat-model ゲート、DPIA ゲートが代表例。GDPR DPIA は高リスク閾値超過時のみ必須＝タグがレビューを起動する。
• Gemini は ARB（Architecture Review Board）を SoD・データ保護・J-SOX 適合を検証する「コンプライアンス・ゲートウェイ」として描く。将来の役員体制ではレビュー機構の置き場として参考になる。

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

外部専門家も AI critic も Consulted/Input。最終 accountable は内部の名前付き 1 人のまま。3 モデル一致＝草案と完全一致。

• 説明責任は委譲不可。doing は第三者・自動化へ委譲できるが、outcome の所有は内部に残る（FCA のアウトソーシング指針）。
• EU AI Act 第 14 条は高リスク AI に人間が解釈・無視・上書き・停止できる設計を要求。AI 出力は助言、最終決定は人間。自動化バイアス対策も義務。
• Gemini が補強する実装観点: AI は「高速ドラフト・分析エンジン」、最終結論は人間が検証・所有する Human-in-the-Loop。監査証跡は AI 生成物と人間の独立 sign-off を明確に分離して記録する。
• Gemini の「AI Decision Trail」「マルチモデル合意 → 信頼度低下時に人間へ自動エスカレーション」は、本プロジェクトの審査パイプライン（3 モデル並列レビュー）そのものの監査的正当化に使える。

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

「役割を抽象定義し、人を後から割当」が durable なパターン。3 モデル一致＝草案と一致。

• 創業者は複数役割を兼任し、成長とともに専門役員へ束を分割する。これは役割の 再割当であって過去 ADR の rewrite ではない。
• 組織設計の原則として、役割を個人と切り離して定義すると、構造変更が「人格の問題」にならない。
• 現在は approver.who と driver が同一でも role を必ず記録する。将来 who を分離した時点で監査単位が成立する。

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

3 モデルの提案を統合した最小セット。Claude の表を基に OpenAI の frontmatter 例で具体化した。

ADR frontmatter の例（OpenAI 案を本プロジェクトの語彙に寄せたもの）:

adr: 0045
title: Use PostgreSQL for Audit Logging
scope: Platform
status: Accepted
date: 2024-01-10
approver:                         # 単一・Scope 由来
  role: CTO
  who: t_saitoh
driver: t_saitoh                  # 現状は approver と同一。role は必ず残す
consulted:                        # 責任なし・拒否権なし
  - "Security Officer: t_saitoh"
  - "External CPA: (外部税理士)"
  - "AI critic: 3-model review"
informed: []
concerns: [secure, legal]         # タグ→必須レビュー発火

ポイント:

• approver は Scope（Corporate / Platform / Product / Ops）から導出する。草案を維持。
• 承認の不変証跡は Git/PR merge。frontmatter の approver と commit 履歴を一致させる。
• ソロの現在は approver.who = driver でも role を記録する。SoD 不能は補償統制（AI 審査・不変 Git 履歴・外部監査）で明示的に埋める。

RACI vs RAPID vs DACI（ADR 用途）

優先度ランキング

Must-have（監査の最低ライン）

• ADR ごとに単一 Approver（Scope 由来）を記録し、Git/PR の不変承認と一致させる。
• 外部専門家・AI critic は Consulted（責任なし）。最終 accountable は内部の名前付き 1 人。
• security/legal は concern タグ→必須レビュー・ゲート。Scope 層に足さない。
• SoD を明示し、ソロでは補償統制（AI 審査・不変履歴・外部監査）で代替する。
• 承認後の ADR は不変。変更は supersede（新 ADR）で行い履歴を残す。

Should-have

• 語彙を DACI 寄り（Approver / Driver / Contributor / Informed）にし、RACI 写像表を残す。
• concerns: と必須レビュー発火条件（データ分類・外部露出・規制範囲）を定義する。
• 役割を抽象定義し人を後から割当てる移行規約。過去 ADR を書き直さない。
• concern が Yes の ADR は該当レビュアーの sign-off 無しに承認できない自動ゲート。

Nice-to-have

• RAPID 形式（Agree=拒否権）は複数拒否権が要る稀な Critical 決定だけのオプション。
• ISO 42010 "approving authority" 準拠を frontmatter スキーマに明記。
• DPIA / threat-model ゲートの軽量チェックリスト。
• 役割の時系列マッピング（誰がいつどの役割か）を ADR ログの付録に持つ。

相違点・注意

• DACI vs RACI の語彙差: Claude・OpenAI は DACI 推し、Gemini は RACI 前提。不変量（単一 Accountable）は共有するので結論は衝突しない。本 synthesis は DACI を採用。
• Gemini のトピックドリフト: Gemini 後半「Predictive Medical AI」節は ADR を Adverse Drug Reaction（薬害）と取り違えている。本 RQ（Architecture Decision Record）と無関係なので不採用。
• 検証の前提: Claude 分は WebFetch が 403 で、引用は WebSearch のスニペット基準（全文 fetch でない）。正式採用前に一次資料の verbatim 確認を推奨。特に J-SOX FSA PDF / IIA Three Lines / ISO 42010。
• Gemini の付加価値: 決定権タクソノミーへの直接性は弱いが、J-SOX / ITGC / 電帳法・AI Decision Trail・マルチモデル合意の監査的正当化で独自の厚みがある。本プロジェクトの審査パイプラインを「監査統制」として位置づける素材になる。

次アクション（提案）

• 本 synthesis を入力に、役割/説明責任レイヤーの ADR を起案する（DRP triage 経由）。
• frontmatter スキーマに approver / driver / consulted / informed / concerns を追加する設計判断は別 ADR。
• concern ゲート（security/legal の必須レビュー発火）の実装は別 ADR。

References

主要出典は各生結果ファイルの References を参照:

• rq-101-result-claude.md — フレームワーク・監査・横断的関心・スケールの一次リンク集
• rq-101-result-openai.md — DACI 比較表・ADR メタデータ写像・優先度
• rq-101-result-gemini.md — J-SOX/ITGC・電帳法・AI Decision Trail