← ADR 一覧へ残タスク一覧へ関連RQ:RQ-101 へ 最終更新: 2026/06/22 20:32
commonid: adr-0151type: adrstatus: accepted
pagemode: Standardkruchten: Existence/Executivescope: platformimplementation_status: Not Startedproposed_at: 2026-06-14 22:40approved_at: 2026-06-14 23:00approver_role: platformapprover_who: [email protected]driver: [email protected]consulted: Decision Pipeline AI 審査 (Gate 0-4)business: drp

ADR-0151: 横断的関心 (concern) タグと必須レビュアー発火条件

  • Status: Accepted
  • Mode: Standard
  • Kruchten Type: Existence/Executive
  • Scope: platform
  • Implementation Status: Not Started
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-06-14 22:40
  • 承認日時 (JST): 2026-06-14 23:00
  • Approver Role: platform
  • Approver Who: [email protected]
  • Driver: [email protected]
  • Consulted: Decision Pipeline AI 審査 (Gate 0-4)

コンテキスト

§1.1 背景

ADR-0141 (承認者体系・Accepted 2026-06-12) は単一 Approver と Scope を frontmatter 化したが、security/legal は Non-Goals と §1.4 で「ドライバー・検証 KPI が分かれる別決定」として意図的にスコープ外にした。その行き先が本起案 (= DOC-OPS-26)。ADR の意思決定で security / legal のような 横断的関心 (cross-cutting concern) を、決定ごとに漏れなく拾う仕組みが無い。

§1.2 現状 (As-Is)

現状 concerns: 相当のキーはスキーマに無く、使用 ADR は 0 件。security/legal の観点は本文へ場当たり的に書かれるだけで、横断検索も必須レビューの発火もできない。

§1.3 課題

  • ①チーム化後に「この決定は security レビューを通したか」を追えない。
  • ②監査 (J-SOX / ISO 27001) が要求する関心ごとの追跡可能性を満たせない。
  • ③高リスク決定 (顧客データ・電帳法・外部露出 = JTBD-012 / ADR-0118・0126) が無審査で通る経路が残る。

§1.4 制約・要件

  • ADR-0141・0049 (Scope は所有・承認軸) と整合。concern を Scope 層に足さない。
  • ソロ期 (= Approver = 起案者) では独立検証が成立しない (ADR-0109 ②) ため、ソロ期に hard fail を強制しない。
  • registry の owner = platform Approver、更新トリガー = 人員変更時 + 四半期棚卸し。
  • 監査照会 (ADR-0137 枠組み) で補償統制の妥当性を確認できる形式で記録を残す。
  • 既存規制 (J-SOX / ISO 27001 / GDPR / EU AI Act / APPI) との整合。

§1.5 目標 (To-Be)

横断的関心を独立 concerns: タグで持ち、タグの存在で必須レビューを発火させる。タグの付け忘れ・形骸化・registry 破綻まで lint で機械的に守る。Non-Goals: Scope 層の拡張、既存 ADR への自動遡及付与の即時実施。

決定

横断的関心を Scope 層に足さず、独立した concerns: タグ (frontmatter・enum 配列) で持たせ、タグの存在で必須レビューを発火させる。初期値域は security / legal / privacy / financial-reporting / external-exposure の 5 個。ソロ期はゲートを warning (dry-run) で運用し、チーム化 (独立 named reviewer が 1 名以上 registry に登録された時点) で enforce へ昇格する。タグの「付け忘れ」「形骸化」「registry 破綻」「ソロ期の独立性偽装」「enum 硬直化」「空節 merge」「誤発火計測」の各盲点に対応する lint ルール (a)〜(f) を本決定の実装範囲に含める。

判断基準 (Decision Drivers)

3.1 評価軸

#軸重要度 (係数)案件特有の解釈
1#reliable[Must] (×2.0)監査追跡可能性 (J-SOX / ISO 27001 が要求する concern ごとの追跡)。タグ付け忘れ・registry stale に対する fail-safe 挙動。
2#flexible[Must] (×2.0)チーム化耐性。人を後から割当・過去 ADR を書き直さずに enforce へ昇格できる。enum 拡張が ADR 不要の fast-track。
3#maintainable[High] (×1.0)registry owner と更新トリガーが定義され、stale 検知が自動化される。
4#usable[High] (×1.0)ソロ運用の認知負荷。起案時にタグ 1 フィールド + 自己チェックリストのみ。
5#secure[High] (×1.0)高リスク決定 (顧客データ・電帳法・外部露出) の無審査 merge を抑止。

K.O. criterion: Must 軸 (#reliable, #flexible) の score < 3 は不採用。

3.2 評価軸 × 案スコア表

軸係数採択案 (concern タグ + dry-run→enforce)案 A (やらない)案 B (Scope に security/legal を足す)
#reliable×2.0412
#flexible×2.0421
#maintainable×1.0432
#usable×1.0452
#secure×1.0413
加重和 (正規化)0.8000.3570.271
K.O. 通過 (Must ≥3)✓❌❌

(満点 = 5、Σ係数 = 7、加重和 = Σ(score×係数)/(5×7))

検討した代替案 (Alternatives Considered)

  • 案 A (やらない・現状維持): security/legal を本文へ自由記述。Must 両軸で K.O. — チーム化で漏れる、横断追跡不可、監査要件未達。
  • 案 B (Scope 層に security/legal を足す): 却下 — RQ-101 の 3 モデル全員一致で「横断的関心は層でない」(TOGAF / arc42 / ISO 25010 / AWS Well-Architected)。Scope は所有・承認軸、concern は直交する品質・規制軸。混ぜると両方壊れる (#flexible K.O.)。
  • 案 C (タグだけ付けゲートを作らない): 部分採用 = ソロ期 dry-run。値域・registry を先に整え enforce はチーム化で。

影響 (Consequences)

§5.1 正の影響 (Good)

  • 横断的関心が frontmatter で機械検索可能になり、監査 (J-SOX / ISO 27001) の追跡可能性要件を満たす素地ができる。
  • 高リスク決定 (JTBD-012 / ADR-0118・0126) が tag→reviewer 対応で必須レビューに乗る経路を確立できる。
  • Scope (所有・承認軸) と concern (品質・規制軸) を直交に保つことで、ADR-0049・0141 のモデルを壊さずに拡張できる。

§5.2 負の影響 (Bad)

  • ソロ期は dry-run のため独立検証が成立しない (盲点3 / ADR-0109 ②)。solo_self_review:true の sign-off は warning で警告するが、形式統制としては不完全。
  • ヒューリスティック (a) は表記揺れ・間接表現に対し false-negative を出す (盲点1)。Confirmation 条件 4 に定量目標 (月次サンプリング 20 件中 false-negative ≤ 2 件) を組み込むが、目標達成までの期間は検出漏れが残る。
  • J-SOX 実地審査で「設計上の統制欠陥」と判定されるリスク (盲点2)。OQ-2 の監査照会完了まで Accepted 移行を保留する。
  • 既存 約 150 本への遡及付与は本決定では実施せず、EU AI Act (2026-08 段階施行) 等の施行前期間に証跡空白が残る (盲点6)。

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

  • enum 初期 5 個 + fast-track 拡張は ADR 軽量化と registry 肥大化のトレードオフ。未知値は warning 止まりで merge を止めない (盲点4)。
  • 「チーム化」の判定権者がソロ期は起案者自身となり利益相反構造になる (盲点3)。「独立した named reviewer が 1 名以上 registry に登録された時点」という定量定義を Confirmation 条件 3 に組み込み、自動トリガー化する。
  • registry stale 由来 warning とヒューリスティック誤検知 warning は (f) の集計スクリプトで種別分離し、撤退条件の「誤発火」カウントから前者を除外する (盲点4)。
  • 将来 SLSA L2 以上の準拠が求められた場合、ソロ期 dry-run 設計の再構築が必要になる (盲点7)。OQ-2 の確認対象に SLSA / SSDF 整合を追加する。
  • 手続き的合理性バイアス (タグ付け = 安全管理と誤信) のリスク (盲点5)。(e) の lint ルールを拡張し、最低記載要件 (security なら脅威シナリオ 1 件以上・対策 1 件以上) を強制する。

撤退条件 (Rollback Plan)

  • ソロ期に dry-run warning が誤発火 (起案者が false-positive とマークした件数、registry stale 由来分は除外) 月 3 件超になれば、warning も無効化し「タグ定義 + 横断集計のみ」へ縮退 (フラグ 1 つ)。計測は (f) のスクリプトで行う。
  • enforce 昇格はチーム化 (独立した named reviewer が 1 名以上 registry に登録された時点) が実際に起きてからのみ。
  • OQ-2 (J-SOX 監査照会) の結果が「dry-run では設計上の統制欠陥」と判定された場合、本 ADR の Accepted 移行を保留し、enforce 前倒し or 別統制への切替を判断する (ADR-0137 枠組み)。

コスト試算

  • 初期: スキーマ 0.25 + lint (a)〜(e) 1.0 + registry 0.25 + 集計スクリプト (f) 0.25 + docs 0.5 = 約 2.25 人日。
  • 運用: 起案時にタグ 1 フィールド。ソロ期はゲート=自己チェックリスト + 四半期棚卸しのみ。
  • 既存 ADR 遡及付与: 既存 約 150 本への遡及タグ付与は チーム化時の enforce 昇格条件に「過去 ADR 一括付与完了」を含めるか、遡及しない場合の監査リスク許容を明示的に決定として記録する (遡及する場合 概算 0.5〜1.0 人日)。
  • registry stale 検知 (last_reviewed_at 90 日超で warning): 集計スクリプト (f) に内包 (追加コスト 0)。

Confirmation

#検証手段実行頻度違反時対応
1adr-lint が concerns: の値域 (enum) を検証。未知値は warning 止まり (d)。PR ごと (CI)warning → registry PR で enum 拡張 (fast-track)。
2CI が concern 付き ADR の registry reviewer 定義を検査。未定義は warning (b)、solo_self_review:true の sign-off も warning (c)。PR ごと (CI)warning → registry 更新 (owner = platform Approver) または独立 reviewer 割当。
3チーム化判定: 独立した named reviewer が 1 名以上 registry に登録された時点で enforce 昇格を自動トリガー。solo_self_review フラグ除去と独立 reviewer sign-off が Git/PR 証跡に残る。registry 更新時 (CI)enforce 昇格未実行が 1 サイクル続けば platform Approver へエスカレーション。
4タグ付け忘れヒューリスティック (a) と本文セクション存在検査 (e) が warning。月次サンプリング 20 件中 false-negative ≤ 2 件 (≤ 10%) を定量目標とする。(e) は最低記載要件 (security: 脅威シナリオ 1 件以上 + 対策 1 件以上) を含む。月次 (手動 QA)目標超過時は辞書更新 + 縮退動作 (より広い warning 範囲) を発動。
5外部規制 (EU AI Act / APPI 改正 / SLSA / SSDF 等) の年 1 回定期レビューで enum の陳腐化を点検。年 1 回 (手動)enum 拡張 (fast-track) + 既存 ADR バックフィル要否を registry PR に記録。
6registry の last_reviewed_at が 90 日超で CI warning。PR ごと (CI)warning → 四半期棚卸し実行・platform Approver が更新。

参照 (References)

  • 関連 ADR:
    • ADR-0141 (承認者体系・分離元): depends_on。Non-Goals / §1.4 で concern を別決定とし、受理後 30 日以内の DOC-OPS 起票を Confirmation 要件にした (= DOC-OPS-26)。
    • ADR-0049 (Scope 4 層): relates_to。concern が Scope でない根拠。
    • ADR-0109 (escalate/HITL): relates_to。自己 sign-off が独立検証にならない限界の出典。
    • ADR-0115 (知識レイヤ): タグ定義・registry の配置層。
    • ADR-0118 / 0126 (JTBD-012): relates_to。security/legal/privacy concern の実需先。
    • ADR-0137 (監査照会枠組み): OQ-2 の J-SOX 照会で参照。
    • follows_up_on: ADR-0141 (frontmatter 型付き辺に明記)。Supersede なし。
  • 関連 PR/Issue: DOC-OPS-26 (起票元) / DOC-OPS-29 (CV 由来タスク文脈)。
  • 外部資料:
    • docs/research/rq-101-synthesis.md Q3 (横断的関心・3 モデル一致) / Q4 / 合意マトリクス。
    • docs/_internal/06_ops/adr_approver_role_registry.md。
    • TOGAF Security as a Cross-Cutting Concern / arc42 品質タグ / ISO 25010 / AWS Well-Architected (Security 柱)。
    • GDPR DPIA / EU AI Act 第 14 条 (2026-08 段階施行) / ISO 27001:2022 §6.1.2 (対象の識別) / J-SOX 金融庁 実施基準 II-2-3。
    • SLSA (Supply-chain Levels for Software Artifacts) / NIST SSDF (将来要件としての参照)。
    • Zampetti et al., 2019 (静的 lint の false-negative 率) / Hales & Pronovost, BMJ 2006 (手続き的合理性バイアス) / Google SRE Workbook §8 (オーナー未明記タスクの放置) / ENISA SME ガイド 2023 (曖昧移行条件の未執行事例)。