← ADR 一覧へ残タスク一覧へ関連RQ:RQ-101 へ最終更新: 2026/06/22 20:32

commonid: adr-0141type: adrstatus: accepted

pagemode: Standardkruchten: Executive/Propertyscope: platformimplementation_status: Done (sub = PRproposed_at: 2026-06-12 02:41approved_at: 2026-06-12 03:09deciders: [email protected] (単独)business: meta

型付き辺: 出 10 / 入 0

ADR-0141: ADR 承認者体系 — 単一 Approver(Scope 由来)の frontmatter 構造化と受理 PR 層の機械検査

Status: Accepted (PR #1831 merge = 受理の規約により 2026-06-12 受理・代表取締役判断)
Mode: Standard
Kruchten Type: Executive/Property
Scope: platform
Implementation Status: Done (sub = PR #1858: スキーマ 3-way + 起案テンプレ 4 欄 + 役割割当レジストリ + glossary / main = PR #1875: adr-lint 静的 3 ルール + CI merge 者一致 + 生成プロンプト v2.0.0)
起案者: [email protected]
起案日時 (JST): 2026-06-12 02:41
承認日時 (JST): 2026-06-12 03:09
Deciders: [email protected] (単独)

コンテキスト

§1.1 背景

検査 5 層モデル(構造正典 §G)の下流ガバナンス 4 つ(可逆性・ドライバー・承認者・検証 KPI)のうち、承認者(Deciders)だけ機械検査がどの層にも存在しない(§G-2・残論点台帳 Q1)。現状の deciders 欄は自由記述で、人・AI モデル・調査名が 1 つの文字列に混在し、「誰がこの決定の最終責任者か」が構造化されていない。

§1.2 現状 (As-Is)

deciders 欄は自由記述リスト。現在 115 本(本 ADR では既存 115 本を変換対象として参照する一方、コスト試算の backfill 対象母数は ADR-0137 Phase 2 と整合する 134 本)の ADR が自由記述形式のまま蓄積されており、人・AI モデル・調査名が混在している。

§1.3 課題

実害は 3 つ。

監査立証が機械的にできない: J-SOX・ITGC・COSO は「名前のある承認者・帰属可能で改ざん耐性のある証跡・職務分掌(SoD)」を要求し、ISO/IEC/IEEE 42010 は architecture description の必須識別情報に approving authority を含める(RQ-101)。自由記述からはいずれも機械検査で立証できない。
単一責任の不変量が検査できない: RACI・RAPID・DACI の 3 フレームワークに共通する不変量は「決定ごとに Accountable は 1 人」(RQ-101 で 3 フレームワーク一致)。自由記述リストでは複数人併記や人と AI の混在が検出されない。
チーム化の受け皿がない: Jr 採用後の決定権限委譲時、役割の単位が定義されていないため、過去 ADR の書き直しか属人的な引き継ぎが必要になる。

§1.4 制約・要件

検査は ④ 受理 PR 層に 1 本化する(§G の規律。検査を複数層に分散させない)
起案時の記入負担は frontmatter 2〜4 行・1 分未満
既存 ADR の破壊的変換を伴わない(deprecated 経過期間を設ける)
ADR-0137(frontmatter 原本化)・ADR-0123(frontmatter 3 層モデル)・ADR-0049(Scope 4 階層)と整合
スコープ外項目(concern タグ設計)は受理後 30 日以内に DOC-OPS backlog 起票

§1.5 目標 (To-Be)

承認者を構造化された frontmatter として記録し、単一性・帰属・SoD(または補償統制)を ④ 受理 PR 層で機械検査可能にする。役割(role)と人(who)を分離し、チーム化時の役割再割当が過去 ADR 書き直し不要で済む状態を目指す。

Non-Goals: concern タグ設計と必須レビュアー発火条件(別決定)・Scope 軸自体の見直し(ADR-0049 所有)。

決定

frontmatter に approver: {role, who}(ちょうど 1 つ)を追加し、role を Scope(corporate/platform/product/ops)から導出する 4 役割に固定する。併せて driver:(進行役)・consulted:(拒否権なし・責任なし)・informed:(任意)を併設し、既存 deciders: 欄は新規で廃止・既存分は backfill で 4 欄へ分解する。検査は ④ 受理 PR 層が所有し、静的 3 点(approver 単一性・role enum・scope→role 整合)を adr-lint、merge 実行者と approver.who の一致を CI workflow が担う。role と人の対応は履歴付きレジストリを docs/_internal に正典として置く。SoD 不能(1 人法人)の補償統制は「DRP の独立 AI 審査+Git 不変履歴」を起案テンプレ監査注記に明示する。

設計の中身は次の 7 点。

frontmatter に approver: {role, who} を追加する。ちょうど 1 つ(単一 Accountable の不変量)。role は Scope 由来の 4 役割 = corporate→Corporate 責任者(代表取締役)/ platform→Platform 責任者 / product→Product 責任者 / ops→Ops 責任者。現在は 4 役割すべてを齋藤達希が兼任するが、役割(role)を記録して人(who)と分離しておく。役割を抽象定義し人を後から割り当てる方式のため、チーム化時も過去 ADR の書き直しは発生しない(RQ-101 設問 5)。
driver:(起案・実装の進行役 = SoD の requester/implementer)、consulted:(外部専門家・AI critic・3 モデル調査。拒否権なし・責任を負わない)、informed:(任意)を併設する。
承認の不変証跡は従来どおり Git/PR merge(④ 層の人間 merge = 受理)。文書側 approver と merge 実行者の一致を検査し、文書と履歴を一致させる(AWS 流単一 ADR owner + Nygard 流 Git 承認の併用)。
検査の所有: ④ 受理 PR 層(adr-lint + CI workflow)が所有する。静的 3 点(approver の単一性・role enum・scope→role 整合)= adr-lint、merge 実行者と approver.who の一致 = CI workflow(GitHub の merge 文脈が必要で、ファイル静的検査の adr-lint では書けないため)。① 作成時はテンプレ既定値によるセルフチェック版のみ。本番検査は 1 層に置く(§G の規律)。受理により §G-2 の「承認者: 検査なし」が「④ 受理 PR」で埋まる。
- CI workflow の前提条件(盲点 1 への対応): 使用 API = GitHub REST GET /repos/{owner}/{repo}/pulls/{pull_number} の merged_by.login(pull_request_target ではなく pull_request クローズ済みイベントで取得)。必要 permission = pull-requests: read・contents: read。bot/代行 merge 時の fallback = github-actions[bot]/dependabot[bot] が actor の場合は「Approve レビュー実行者と approver.who の一致」へフォールバック、それ以外の bot は FAIL。実装 PR には golden-path テストとして「意図的に別人が merge した場合に CI が FAIL すること」を必須含有する。PoC で実現可能性を確認してから K.O. 基準達成を最終判定する。
役割→人の割当レジストリ: role と人の対応は履歴つきの対応表(role / who / 開始日 / 終了日)を docs/_internal に正典として置く。監査の「承認時点でその権限を持っていたこと」の立証は、ADR の approved_at とレジストリの期間照合で行う。
- approved_at の正本(盲点 2 への対応): 正本 = merge commit の GitHub タイムスタンプ(GitHub API pulls/{n}.merged_at)。frontmatter の approved_at は merge 後の post-merge workflow が自動書き込みする。force-push 禁止のブランチ保護(main + docs/adr/**)を前提条件として有効化する。レジストリ期間照合は CI が自動実行する。
既存 deciders: 欄の処遇: 新規 ADR では deciders を廃止し 4 欄(approver/driver/consulted/informed)へ分解する。既存分は backfill 時に deciders 文字列を 4 欄へ変換して deciders を削除する。frontmatter スキーマでは経過期間中 deciders を deprecated(warn)として残し、backfill 完了で削除する(ADR-0137 の同期 lint・スキーマ 3-way 同期と整合)。
SoD: 1 人法人では approver.who = driver が常態で職務分掌が成立しない。COSO の補償統制として「DRP の独立 AI 審査+Git 不変履歴」を明示し、起案テンプレの監査注記に記載する。
- 補償統制の証跡所在(盲点 4 への対応): DRP 独立 AI 審査の実施記録は docs/_internal/drp-reviews/YYYY-MM/ADR-XXXX.md に保存。実施頻度 = Standard/Critical の全 ADR で起案時 1 回必須。独立性の定義 = 起案者(driver)と異なるプロンプト環境・異なる AI モデルを 1 つ以上含む 3 モデル調査を実施したこと。EU AI Act 第 14 条適合の根拠は consulted 欄記載ではなく DRP 独立 AI 審査手順書(別文書・本 ADR 受理前に作成必須)である旨を起案テンプレ監査注記に明記する(盲点 3 への対応)。

判断基準 (Decision Drivers)

3.1 評価軸

#	軸	重要度 (係数)	案件特有の解釈
1	`#reliable`	Must (×2.0)	承認者の単一性・帰属・SoD(または補償統制)が機械検査で立証可能になる
2	`#maintainable`	High (×1.0)	チーム化時の役割再割当が過去 ADR 書き直しなしで成立する
3	`#usable`	Medium (×0.5)	起案時の記入負担が小さい(frontmatter 2〜4 行・1 分未満)・solo 運用で形骸化しない
4	`#efficient`	Medium (×0.5)	検査は静的 lint+CI のみで LLM 追加コストゼロ

K.O. criterion: #reliable (Must) score < 3 は不採用。具体的には「④ 層(adr-lint + CI workflow)で検査を実装できない」場合は不採用。

3.2 評価軸 × 案スコア表

軸	係数	採択案 (Scope 由来 4 役割 + 4 欄構造化)	案 A (現状維持: deciders 自由記述)	案 B (RACI 採用)	案 C (RAPID 採用)	案 D (Git merge 履歴のみ)
#reliable (Must)	×2.0	5	1	3	4	2
#maintainable (High)	×1.0	5	2	3	3	3
#usable (Medium)	×0.5	4	5	3	2	5
#efficient (Medium)	×0.5	5	5	4	4	5
加重和 (正規化)		0.967	0.483	0.617	0.667	0.583
K.O. 通過 (Must ≥3)		✓	❌	✓	✓	❌

検討した代替案 (Alternatives Considered)

案 A (現状維持: deciders 自由記述): 自由記述リストを継続 — 単一 Accountable 不変量が検査不能・監査立証不能のまま。実害 1〜3 が解消しない。K.O. 不通過。
案 B (RACI 採用): RACI フレームワークを採用 — Accountable が「タスクの sign-off 所有者」で「誰が決めるか」と混同が起きる(McKinsey が同理由で決定特化の DARE を提唱)。タスク管理用であって決定用でない。
案 C (RAPID 採用): RAPID フレームワークを採用 — Agree(拒否権)分離は強力だが、1 人法人には重い(Bain 自身が小規模・低リスクには過剰と注記)。複数拒否権が必要な稀な Critical 決定向け将来オプションとして温存し、既定にはしない。
案 D (承認 = Git merge 履歴のみ・Nygard 流): 不変証跡は得られるが「どの役割として」承認したかが残らず、Scope 由来の役割検査と ISO 42010 の approving authority 記録ができない。文書側 approver との併用として部分採用。

影響 (Consequences)

§5.1 正の影響 (Good)

§G-2 の承認者空白が ④ 層で埋まり、下流ガバナンス 4 つすべてに機械検査の所在が揃う
監査(J-SOX・ITGC・ISO 42010)へ ADR 単位で立証可能になる
チーム化の権限委譲が役割再割当で済む(過去 ADR 書き直し不要)

§5.2 負の影響 (Bad)

frontmatter スキーマ・adr-lint・CI・起案テンプレ・パイプライン生成テンプレ・構造正典 §G-2 の改訂が必要
既存 ADR は approver 欠落のまま段階移行になり、deciders→4 欄の変換 115 本が backfill 範囲に加わる
CI workflow の GitHub API 権限・トークン設計の調査が必要で、PoC 結果次第で実装コストが 1〜2 人日増加する可能性(盲点 6)

§5.3 中立・トレードオフ (Neutral / Trade-offs)

solo では approver=driver の同一人記載が続き形式化しうる → 補償統制(DRP 独立 AI 審査+Git 不変履歴)の明示と月次の記入率集計で観測する。adr-lint は「approver=driver 兼任」自体は検査対象外とし、補償統制の存在で代替する
backfill を改訂時 touch-time に委ねると superseded/deprecated ADR は永久未変換となる懸念(盲点 5) → 完了期限 = 受理後 6 ヶ月以内・superseded/deprecated ADR は変換対象から除外(approver 欠落のまま deprecated 欄に固定文言を入れる)。lint KPI のカウント対象は「新規 ADR のみ」と明示し、backfill 未完了 ADR の warn を KPI から分離する

撤退条件 (Rollback Plan)

lint enforce 後 3 ヶ月(2026-09 末まで)の新規 ADR で approver 記入率が 90% 未満(回避・形骸化が常態)なら設計を見直す
Scope 由来の 4 役割で割り当てられない決定が 3 件以上発生したら role 体系を再設計する(Scope 軸自体の見直しは ADR-0049 の所有で、本 ADR では扱わない)
CI workflow の SoD 代替検査が bot merge や権限不足で実質無効化していると PoC で判明した場合、K.O. 基準達成を否認して再設計する
ロールバック手順: adr-lint ルールを error→warn に降格し、CI workflow(merge 者一致)は required check から外す(スキーマと記録済みデータはそのまま残り、破壊的変更なし)
変換済み deciders の復元手順: backfill 変換は ADR 単位の機械変換 PR で行い、元の deciders 文字列は git 履歴(変換 PR の diff)に残る。復元は該当変換 PR の revert で行う。経過期間中はスキーマが deciders を deprecated(warn)で受理するため、revert 後も lint は壊れない

コスト試算

実装(sub): frontmatter スキーマ拡張(3-way 同期)+起案テンプレ改訂+役割割当レジストリ新設+構造正典 §G-2/残論点台帳の反映+glossary 追補で 0.75 人日
実装(main): adr-lint 静的 3 ルール+CI workflow(merge 者一致)+パイプライン生成テンプレ・プロンプトへの approver 欄追加(prompt + output_schema + golden eval を同一 PR で・ADR-0138 で確立した実装パターン)で 1〜1.5 人日
GitHub API 権限調査(追加計上・盲点 6): PoC で permission スコープ・bot fallback・force-push 禁止ブランチ保護設定の検証で 0.5〜1 人日(PoC 結果次第で main コストが 1〜2 人日増の可能性)
DRP 独立 AI 審査手順書作成: 受理前に別文書として作成 0.25 人日(盲点 3 への対応)
移行: 新規 ADR から必須(全 Mode)。既存 ADR(本 ADR の deciders→4 欄変換対象は 115 本、ADR-0137 Phase 2 全体は 134 本)の変換は ADR-0137 Phase 2 と改訂時 touch-time に併せて行う(専用一括 PR は作らない・ADR-0049 の Phased Backfill 方式を踏襲)。完了期限 = 受理後 6 ヶ月(superseded/deprecated は除外)
運用: 起案ごと frontmatter 2〜4 行の記入(1 分未満)。検査は静的 lint+CI で LLM 追加コスト 0 円。DRP 独立 AI 審査は Standard/Critical 起案時 1 回必須(既存の 3 モデル調査で代替・追加コスト 0 円)

合計見積もり: 2.5〜3.5 人日(PoC 結果の上振れ含む)

Confirmation

検証手段:
- adr-lint(CI)が全 PR で新規 ADR の approver 単一性・role enum・scope→role 整合を検査
- CI workflow が merge 実行者と approver.who の一致を検査(bot fallback ルール込み)
- golden-path テスト「意図的に別人が merge した場合に CI が FAIL する」を実装 PR に必須含有
- 月次で新規 ADR の記入率・lint 誤検知件数・backfill 進捗(新規 ADR のみカウント)を集計
- スコープ外項目(concern タグ設計)の DOC-OPS backlog 起票を受理後 30 日以内に初回月次集計で確認
実行頻度: CI = PR ごと / 集計 = 月次 / backfill 進捗確認 = 受理後 6 ヶ月で完了判定
違反時対応:
- KPI = 新規 ADR の approver 記入率 100%(enforce 後)・lint 誤検知 月 2 件以下
- 記入率 90% 未満または誤検知が月 3 件以上で撤退条件評価
- 30 日以内に concern タグ backlog 未起票なら Confirmation 違反として扱う(ADR-0130 パターン)
- PoC で CI workflow の SoD 代替検査が実質無効化と判明した場合、受理を保留し再設計

Review After

次回レビュー: 2026-12-01(lint enforce 後 3 ヶ月 KPI の確定と、backfill 完了期限〔受理後 6 ヶ月〕の中間点検が揃う時期)
レビュー主体: approver(platform 役割の保持者・役割割当レジストリの現任者が実施。現任 = 代表取締役)
前倒しトリガ: ① Jr 受け入れ等で役割の人格分離が実際に発生した時(SoD 補償統制の要否を再評価) ② PoC で CI workflow の SoD 代替検査が実質無効化と判明した時(撤退条件と連動) ③ Scope 由来 4 役割で割り当てられない決定が発生した時

参照 (References)

関連 ADR:
- ADR-0049: Scope 分類軸の 4 層化 — 依存(Approver の role は Scope から導出。Scope 軸の見直しは 0049 の所有)
- ADR-0123 / ADR-0137: frontmatter 3 層モデル・メタデータ frontmatter 移行 — 補完(approver の置き場は 0137 の frontmatter 原本化と同じ・スキーマ拡張は 0123 の正典に従う)
- ADR-0038: adr-lint メタデータ規約 — 補完(④ 層検査ルールの実装基盤)
- ADR-0109: 過剰審査ループの bounded rounds — 整合(escalate の終端 = ④ 層の人間判断。その人間が「どの役割として」決めるかを本決定が定義)
- ADR-0130: 索引・カタログの自動生成 — 並立(スコープ外項目の行き先解決パターン〔起票義務+期限〕の参照元)
- ADR-0138: prompt + output_schema + golden eval 同一 PR 実装パターン — 参照(パイプライン生成テンプレ改訂の実装方式)
関連 PR/Issue: -
外部資料:
- ISO/IEC/IEEE 42010 (architecture description の approving authority 要件)
- J-SOX / ITGC / COSO(承認者・改ざん耐性証跡・SoD 要件)
- EU AI Act 第 14 条(人間監督要件)
- RACI / RAPID / DACI / DARE 3 フレームワーク比較(RQ-101)
- Bain RAPID 適用ガイド(小規模・低リスクは過剰)
- Nygard ADR / AWS prescriptive guidance(単一 ADR owner)