RQ-107 Synthesis — 組織における意思決定 Role 構造のベストプラクティス(大企業→中堅→1人企業+AI agent)

調査: 2026-06-18、OpenAI o3-deep-research / Gemini deep-research-preview-04-2026 / Claude opus-4-7(managed-agent)。3 社並行。総コスト $6.79(OpenAI $3.44 / Claude $2.23 / Gemini $1.12)。所要 13 分(並列実行)。生結果は rq-107-result-claude.md / rq-107-result-gemini.md / rq-107-result-openai.md。 問い: 大企業の意思決定 Role 構造(DACI/RAPID/RACI/Bezos Type-1/Type-2/Holacracy/Sociocracy 3.0/Spotify/J-SOX/OECD CG)はどう分解されるか。中堅→1 人+AI agent に圧縮する時、どこを崩してよく、どこは崩せないか。 検証方針: 「3 モデル合意」と括った主張を 3 件すべての本文で逐語照合。確定度を ◎ 3 モデル合意 / ○ 2 モデル明示 / △ 1 モデル独自 にランク付け。

0. 結論(先に要点)

19 Role 草案(R1.a/b・R2.1-10・R3・R4.a-c・R5-R8)は粒度として過剰ではない。3 モデルすべてが「全 Role がいずれかの framework で名前が付く」ことを裏付けた。以下を採用する。

1. 新規 R9 Recaller(proactive 想起者)を追加。業界全体でこの actor が staff されていないことが横断的に判明。bizlp の最大ギャップ。doc clone を演者に充てる。
2. R2.10 policy_alignment を score → veto に昇格(R2.11 Compliance Veto)。3 モデル合意。SOX/J-SOX/ISO 27001 環境で hard requirement。
3. R3 Type-1 ADR で fresh-context AI second-review を強制(24-48h hold)。n=1 + AI の compensating control の核。
4. AI Provenance を telemetry に明示化。clone-ID + model-version + prompt-hash + fresh-context flag。tamper-evident audit trail。
5. R6 施行確認者を formal role 化。drp-ops Skill に観測手順を格上げ。

採用後の DRP 19 Role 草案への反映は §4 表、優先順は §6。bizlp 固有の compression は §5(R9 Recaller を独立 gate / Type-1/Type-2 を triage で明示)。

1. ◎ 3 モデル合意(確定的に採用してよい)

1.1 Universal robust roles(6 役)

3 framework 以上で名前が付き、3 モデルすべてが core と認定した役割。

出典: rq-107-result-openai.md(cross-framework table の標準形)/ rq-107-result-claude.md(15 行 Role table)/ rq-107-result-gemini.md(Foundations 章)。

1.2 Hard separation rule(3 件 unanimous)

3 モデルすべてが明示的に「崩してはならない」と書いた分離。

• Single Decider per decision — 1 決定に Approver は 1 名のみ。DACI/RAPID/RACI すべてが明示。
• Proposer ≠ Decider — 起案者と承認者は別 actor。これを崩すと DACI で「slow single-approver bottleneck」、RAPID で「Multiple D's = no decision」になる。
• AI Self-review 禁止 — Generator と Verifier は context を分離する。同一 context window でモデルが自分の出力を review すると、起案時の前提が review に持ち込まれる(Claude 引用)。独立 context での review でだけ self-review trap を回避できる。
• High-stakes では Compliance/Veto 独立 — RAPID "Agree"(legal/security/financial-control の narrow veto)は SOX/J-SOX/ISO 27001 環境で hard requirement。

出典: rq-107-result-claude.md(AI Self-review trap の論述)/ rq-107-result-gemini.md(J-SOX compensating controls 節)/ rq-107-result-openai.md(audit-driven separation 表)。

1.3 n=1 + AI compensating controls(3 件合意)

ソロ作り手 + AI clone で Proposer/Reviewer/Decider を兼任する場合の compensating control。

• 時間差 review — 同一 Decider が兼任する時、fresh-context AI second-review を時間差で挟む。Claude は「24-48h hold + fresh-context AI review」を推奨。
• Tamper-evident attribution log — AI vs Human の分担を audit trail で識別する。clone-ID + model-version + prompt-hash + fresh-context flag を記録。
• External sign-off — Type-1 ADR(irreversible)は外部 advisor / board member の formal sign-off で 4-eye 相当を確保する(3 件合意)。
• Type-1 / Type-2 二分 — Bezos one-way / two-way doors を判定軸にする。Type-1 のみフル Role 適用、Type-2 は collapse 許可(3 件で繰り返し言及)。

2. ○ 3 モデルの独自貢献(採用推奨)

2.1 Claude — Recaller の不在が最大ギャップ

業界横断で見ると、過去の関連 ADR を proactive に提示する actor はほぼ staff されていない。名前は付くが(Reader / Informed のサブ)、proactive に動く actor が居ない。Claude が「the single highest-leverage addition for an n=1 + multi-clone pipeline」と評価。bizlp は doc clone を Recaller に充てられる位置にある。詳細は rq-107-result-claude.md。

DRP 既存 13 gate には R2.8 consistency があるが、これは「整合性チェック」で「proactive surface」ではない。新規 R9 Recaller を gate として独立配置する。

2.2 Gemini — Bar Raiser / Compensating Controls の運用パターン

• Amazon Bar Raiser: 採用面接で proposer(hiring manager)と独立した bar-raiser を別 actor として置く慣行。decision pipeline に応用すると「特定 ADR の起案チーム外の clone を bar raiser として常設」できる。
• J-SOX compensating controls の具体的設計: ①logged break-glass account、②management 月次 review、③automated alert、④independent third-party verification。小規模組織でも regulator が受容する 4-eye 代替の標準形。
• Immutable AI audit trail: tamper-evident log + version pinning は EU AI Act 対応に必須。DRP の telemetry_records はすでに近い構造(Verdict / run_id / confidence)で、追記項目を明確化すれば対応可能。詳細は rq-107-result-gemini.md。

2.3 OpenAI — org-size × industry のクロス詳細

• Startup(<50)/ Mid(50-500)/ Large(500-5k)/ Multinational(5k+) の 4 段階で Role 数・分離度・delegation pattern が階段的に変動する。
• SaaS / SI / Finance / Manufacturing / Healthcare の 5 業種で強制分離ポイントが大きく違う。
• bizlp = SaaS スタートアップ <50 + 監査要件(顧客が会計データ)のクロスは「SaaS の自由度をベースに、Finance の Compliance Veto を 1 点だけ強制する」パターンが最近接。DRP 現状の policy_alignment gate と方向性一致。詳細は rq-107-result-openai.md。

3. MCDA 加重和 — 3 モデル比較(RQ-052 採用方針)

採用判断は意思決定への informed extension の大きさ(bizlp 適用性)と裏取りの強さ(逐語証拠)で重み付け。

3 モデル全体で 採用すべき独自貢献は 3 件。

• Claude → R9 Recaller の独立 gate 化(最大インパクト)
• Gemini → Compensating controls 4 項目 + Immutable AI trail
• OpenAI → SaaS+Finance クロスの compression 戦略 + org-size 階段

4. DRP 19 Role 草案への反映表

19 Role 草案を 3 モデル知見で再分配。

4.1 新規追加すべき Role

4.2 既存 Role の再分類

4.3 削除/降格候補

なし。3 モデル合意で「全 Role がいずれかの framework で名前が付く」ことが判明。19 Role 草案は粒度として過剰ではない。

5. bizlp informed extension(採択)

3 モデル知見の上に、bizlp 固有の制約(n=1 + 4 clone + 会計監査要件)を informed extension として乗せる。

• R9 Recaller を R2. と独立に配置(triage 直後・abc_screen 前)。R2. は「現 ADR の品質審査」、R9 Recaller は「過去 ADR の想起」で目的が違う。R2.* に内包すると context が太り、self-review trap に近づく。
• Type-1 / Type-2 分類を triage に明示。triage_verdict に door_type: type-1 | type-2 を加える。Type-1 のみ §1.3 の compensating controls(24-48h hold / external sign-off / fresh-context second-review)を強制起動する。Type-2 は現行の単線 collapse のまま。
• AI Provenance を telemetry_records に追加。clone_id / model_version / prompt_hash / fresh_context: bool / door_type の 5 カラム。EU AI Act / J-SOX の Immutable AI audit trail に直結する基盤を先回りで張る。

6. 優先順(DRP 反映の Must / Should / Nice)

Must-have(audit exposure 前にやる・Jr 入社 2026-10 前を目標)

1. R9 Recaller gate の新規導入(doc clone が citation set 生成)— Claude 最大ギャップ指摘
2. R2.10 policy_alignment を score → veto に昇格(Compliance Veto)— 3 件合意・SOX/J-SOX 対応の唯一の必須項目
3. R3 Type-1 ADR で fresh-context AI second-review を強制(24-48h hold)— n=1 + AI の compensating control の核
4. AI Provenance を telemetry_records に明示化(clone_id + model_version + prompt_hash + fresh_context + door_type)— Gemini の Immutable AI audit trail 推奨
5. R6 施行確認者を formal role 化(drp-ops Skill に観測手順を格上げ)— 3 件合意

Should-have(6 ヶ月以内)

6. R0 Sponsor / R1.b Drafter の rename + JTBD 改訂(DPJ-001 の Job executor 節)— Sponsor と Drafter の分離は 3 件合意
7. R10 Bar Raiser 常設配置(起案チーム外 clone を indirection)— Gemini 推奨
8. R7 Reader の UI 整備(RQ-087 Corpus 画面の早期実装)— Reader role を staff 化するには UI 必要
9. Type-1 / Type-2 分類を triage に明示化 — Bezos 引用が 3 件で繰り返される

Nice-to-have(Jr が定着後 or 監査要件が現実化したら)

10. R4 Recorder 統合(slug + numbering を 1 gate に集約)— 副次的整理
11. R2.7 / R2.9 の context isolation 検証(実測で self-review trap を起こしていないか確認)
12. External advisor 連携の formal 化(Type-1 ADR の外部 sign-off slot)— 監査要件が現実化したら

実装着手は別ハンドオフ(handover_2026-06-19_rq107-must-have-implementation_to_main.md)で main 役割に委譲済み。doc 反映と独立して進む。

7. 参照

• 3 モデル生結果: rq-107-result-claude.md / rq-107-result-gemini.md / rq-107-result-openai.md
• prompt: RQ-107_organizational_decision_roles_prompt.md
• 改訂対象 JTBD: _builder_jtbd_list.md(DPJ-001 Job executor 節)
• 隣接 RQ: RQ-052(MCDA = 採用方針)/ RQ-086(JTBD landscape)/ RQ-087(Decision Pipeline UI/IA)/ RQ-106(problem-worth-rating)