bizlp Synthesis 評価軸選定: 業界 MCDA フレームワーク調査と標準テンプレート提言

TL;DR

• bizlp の Multi-LLM Synthesis では、ATAM/CBAM (SEI) + MADR Decision Drivers + LLM-as-a-Judge (G-Eval) の 3 系統をハイブリッド適用し、固定軸 5 個 + 案件軸 0–3 個・5 段階スコア・加重和集約・低信頼時 LLM Critic 検証という標準テンプレートを採用すべきである。
• AHP/TOPSIS/PROMETHEE の数学的厳密手法は 1 人法人スケールでは過剰であり、Equal Weight + 重要度ラベル (Critical / High / Medium) で十分。pairwise comparison は 4 軸超で組合せ爆発するため省略可。
• RQ-050 / RQ-051 の遡及検証は「軸の業界対応表」を後付けで作成し、決定そのものは維持 (Backward-compatible enrichment)。今後の RQ-053 以降は標準テンプレートを強制適用する。

Key Findings

1. MCDA 系 (AHP/TOPSIS/PROMETHEE/ELECTRE/MAUT/WSM) は数学的厳密性が高いが、1 人法人の Synthesis では Weighted Sum Model (WSM) 程度に簡略化するのが現実的。
2. ソフトウェアアーキテクチャ専用 (SAAM/ATAM/CBAM) は SEI Carnegie Mellon が標準化しており、特に ATAM の Utility Tree (品質属性ツリー) と CBAM の ROI 評価 が bizlp の Standard/Critical 区分にマッチする。
3. ADR 系 (MADR 4.0.0 / Zimmermann SOAD / arc42) には「Decision Drivers」セクションが共通標準として存在し、これが評価軸の業界共通アンカーとなる。arc42 公式は明示的に「top three (max five) quality goals」を推奨 (docs.arc42.org/section-1/)。
4. Multi-LLM 系 (G-Eval / LLM-as-a-Judge / Multi-Agent Debate / LLM-Blender / AutoGen) は 2023年3月〜2024年2月の 12 か月間に集中的に整備された (G-Eval arXiv:2303.16634 2023-03、Du et al. arXiv:2305.14325 2023-05、MT-Bench arXiv:2306.05685 2023-06、LLM-Blender arXiv:2306.02561 2023-06、AutoGen arXiv:2308.08155 2023-08、More Agents arXiv:2402.05120 2024-02)。G-Eval は SummEval ベンチマークで人間判定との Spearman 相関 0.514 を達成し、 coherence/consistency/fluency/relevance の 4 軸全てで既存ベースラインを上回った (Liu et al. 2023, arXiv:2303.16634)。
5. 軽量フレームワーク (DACI/RACI/CBA/Wardley/Cynefin) はステークホルダー多数を前提とし、1 人法人では DACI/RACI は不要、Cynefin と Wardley は補助的に使用可能。
6. 重み付けは Equal Weight + 重要度ラベルで十分。AHP pairwise は n≥5 で組合せ数が爆発 (n=5 で 10 比較、n=7 で 21 比較) し、bizlp スケールでは Analysis Paralysis を招く。
7. アンチパターンとして post-hoc rationalization, confirmation bias, analysis paralysis が確認されており、bizlp PR #811/#814 close 経緯はまさにこの 3 つに該当する可能性が高い。

Q1. 多基準意思決定分析 (MCDA) の主要フレームワーク網羅

Q2. 各フレームワークの評価軸選定アプローチ比較

Q3. ソフトウェアアーキテクチャでの MCDA 適用事例

SAAM (Kazman 1994, ICSE-16)

• 評価軸の典型例: Modifiability, Portability, Reusability (シナリオを通じて評価)
• 軸数の典型: シナリオベースで 5–20 個 (軸そのものより衝突シナリオ数が重要)
• 重み付けの慣習: シナリオ優先度ベース (直接 / 間接の二段階)
• 一次資料: Kazman, Abowd, Webb (1994) DOI 10.1109/ICSE.1994.296768

ATAM (Kazman, Klein, Clements 1998, CMU/SEI)

• 評価軸の典型例: SEI 公式定義として「modifiability, security, performance, availability」 が中核。これに reliability, usability, testability を追加することが多い。
• 軸数の典型: Utility Tree のトップノードで 4–7 個
• 重み付けの慣習: 各シナリオに (Importance, Difficulty) を H/M/L で付与。重みではなく risks / sensitivity points / tradeoff points の識別を重視。
• 一次資料: CMU/SEI ATAM Collection, https://www.sei.cmu.edu/library/the-architecture-tradeoff-analysis-method/

CBAM (Kazman, Asundi, Klein 2002)

• 評価軸: ATAM の品質属性 + 経済性 (cost, benefit, schedule)
• 軸数: ATAM と同じ 4–7 軸 + cost/benefit/ROI
• 重み付け: utility curve (benefit を 0–100 で正規化) + cost を別系統で計測 → ROI ランキング
• 一次資料: CMU/SEI-2002-TR-035, https://resources.sei.cmu.edu/library/asset-view.cfm?assetid=5785

Zimmermann ADMentor / SOAD (2009/2015)

• 評価軸: Problem-Option-Outcome モデルで、Problem ごとに固有の Decision Drivers を持つ。
• 軸数: Problem ごとに 2–6 個
• 重み付け: 暗黙 (Problem の階層的優先度)
• 一次資料: Zimmermann (2015) “Architectural Decision Guidance across Projects”, WICSA, https://ozimmer.ch/assets/admentor-wicsa2015ubmissionv11nc.pdf

arc42 Quality Goals

• 評価軸: 「top three (max five) quality goals」が arc42 公式の推奨数
• 軸数: 3–5 個 (公式推奨)
• 公式 quote (docs.arc42.org/section-1/): “The top three (max five) quality goals for the architecture whose fulfillment is of highest importance to the major stakeholders. … Don’t confuse them with project goals.”
• Tip 1-16 quote: “Here, in section 1.2, you describe only a handful (top 3-5) of these requirements. Use brief explanations with scenarios.”
• 重み付け: 暗黙 (top-3 の順序)

MADR Decision Drivers (Kopp/Armbruster/Zimmermann 2018, v4.0.0 2024-09-17)

• 評価軸: Decision Drivers (optional) で「force, concern」を列挙
• 軸数: 通常 2–5 個
• 重み付け: ラベル方式が一般的 (Primary / Secondary)
• 一次資料: https://adr.github.io/madr/decisions/adr-template.html

Q4. ADR / Synthesis における評価軸選定の業界事例

評価軸の出典・選定根拠の共通点:

1. ATAM/CBAM の品質属性 (modifiability/security/performance/availability) が SaaS 業界で広く流用されている
2. AWS/GCP Pillar は クラウドアーキテクチャレビュー に特化した「業務分割型」軸
3. ThoughtWorks Radar の “Trial 入りには production usage が必須” という基準は 証拠基準 の好例 (Adopt はさらにその上)
4. LLM 評価では G-Eval の 4 軸 + MT-Bench 8 カテゴリが事実上の標準

Q5. 軽量フレームワークの適用領域比較

結論: 1 人法人 + AI Agent スケールでは Cynefin (状況判定) + Choosing By Advantages (Synthesis 集約) が最も親和性が高い。DACI/RACI は不要。

Q6. 複数 LLM の出力突合 (Multi-Model Synthesis) に特化した評価軸選定

関連先行研究と評価軸選定パターン

bizlp の「3 モデル並列調査 → Synthesis」に適用可能な評価軸選定パターン (抽出)

1. 固定 4 軸 (G-Eval 由来): Coherence / Consistency / Fluency / Relevance
2. bizlp 特化 1 軸: ADR-0020 Triage 適合度 (Light/Standard/Critical に整合しているか)
3. 集約手法: 上位 K (=2) を pairwise で比較し、Synthesis 後に Critic agent が再検証 (Du et al. 2023 + AutoGen Critic の組合せ)
4. Fallback: 3 モデル間で不一致が大きい場合 (entropy 高)、Multi-Agent Debate を 1 ラウンド起動

Q7. 評価軸の重み付け手法とアンチパターン

主要手法の比較

アンチパターン (bizlp PR #811/#814 に直接該当)

1. Post-hoc rationalization (事後合理化): 既に採用したい案がある状態で、その案に有利な評価軸を後付けで作成する。RQ-051 の 7 節構造選定で疑われる。
2. Confirmation bias: 採用案を支持する証拠だけを軸として採用。
3. Analysis paralysis: 軸が多すぎて決定不能。Miller (1956) の 7±2 ルールに基づき AHP も 7 軸前後を上限とするのが通例。
4. Spurious quantification: qualitative な比較を無理に数値化 (CBA の Suhr が批判する weighting-and-rating の典型問題)。

対策

• Pre-registration of criteria: 評価軸は 代替案リストを見る前に確定する (Bezos Type 1/2 区分に類似)
• Devil’s advocate: AutoGen Critic / Multi-Agent Debate の “negative role” を活用
• 5 軸上限: arc42 の “max 5 quality goals” を bizlp Synthesis にも適用

Q8. 1 人法人 + AI Agent スケールでの省略可能項目

bizlp MVP 必須項目リスト (8 項目)

1. Context & Problem Statement (MADR 必須)
2. Decision Drivers = 評価軸 (3–5 個、arc42 推奨)
3. Considered Options (3 モデルの並列出力)
4. Evaluation Matrix (option × criteria、5 段階スコア)
5. Decision Outcome (chosen option + reasoning)
6. Triage 整合性チェック (ADR-0020 Light/Standard/Critical)
7. Consequences (positive / negative / neutral, MADR v4.0.0)
8. Confirmation (検証方法、MADR v4.0.0 optional だが Standard/Critical では必須化)

省略可能項目リスト

Q9. RQ-050 / RQ-051 Synthesis への遡及適用案

手順

1. 業界対応表の作成: RQ-050/051 の独自評価軸を、Q1–Q3 のフレームワーク軸 (ATAM 品質属性、MADR Decision Drivers、G-Eval 4 軸) に 後付けでマッピング。
2. マッピング不能軸の特定: 業界標準にない軸が見つかった場合、その軸の正当性を Critical 度合いで判定。
3. 覆すか維持か: 既存決定は Backward-compatible enrichment とし、ADR 本体は維持。「Synthesis Addendum」で評価軸の業界対応表を追記する形を推奨。

RQ-050 (ADR Scope 4 階層: Corporate/Platform/Product/Ops) の再評価

• 既存独自評価軸 (推定): 階層粒度、組織責任分界、CodeOps 統合容易性、phased backfill 可能性
• 業界対応:
  • 階層粒度 → arc42 section 9 (Architecture Decisions の粒度) と整合
  • 組織責任分界 → AWS Well-Architected “Operational Excellence” pillar に対応
  • CodeOps 統合 → ThoughtWorks Tech Radar “Trial 入りには production usage が必須” 基準と整合
  • phased backfill → ATAM sensitivity point の概念に対応
• 判定: 4 軸とも業界標準に対応物あり → 既存決定維持、Addendum 追加

RQ-051 (Lint 規約 7 節構造 / 5 カテゴリ / 6 メタ項目) の再評価

• 既存独自評価軸 (推定): 構造の網羅性、カテゴリ分割の粒度、メタ項目の運用負荷
• 業界対応:
  • 7 節構造 → MADR 4.0.0 の section 構造 (status, context, drivers, options, decision outcome, consequences, confirmation, more information の 8 セクション) と類似 — 1 節差は許容範囲
  • 5 カテゴリ → AWS 6 pillars / arc42 quality goals top-5 と整合
  • 6 メタ項目 → MADR YAML frontmatter (status, date, deciders, consulted, informed) と類似
• 判定: 業界標準と整合可能 → 既存決定維持、Addendum 追加。ただし「メタ項目 6 個」は arc42 推奨の “max 5” を 1 つ超えており、運用負荷を再評価する余地あり。

既存決定を覆す判断基準

• 業界標準に対応物が 複数フレームワークで皆無 の場合 → 独自軸の正当性を再検証 (Critical Reopen)
• ATAM sensitivity point / tradeoff point に対応する軸が欠落している場合 → 追加検討
• アンチパターン (post-hoc rationalization 等) が明確に該当する場合 → 軸を業界準拠で 置換

遡及適用方針

• RQ-050/051 は Backward-compatible enrichment (Addendum 形式) で維持。
• RQ-053 以降は新標準テンプレート (Q10) を強制適用。
• ADR-0019/0020 を否定する変更は行わない。

Q10. bizlp Synthesis 標準テンプレートの推奨

標準テンプレート構造 (Markdown 例)

---
id: RQ-053-synthesis
status: proposed  # proposed | accepted | superseded
date: 2026-05-17
triage: Standard  # Light | Standard | Critical (ADR-0020 準拠)
deciders: [代表取締役]
models_consulted: [Claude, Gemini, GPT]
---

# RQ-053 Synthesis: {決定タイトル}

## 1. Context & Problem Statement
{問題の背景、なぜ意思決定が必要か}

## 2. Decision Drivers (評価軸)
本 Synthesis では以下の **固定 5 軸 (G-Eval 由来 4 軸 + bizlp Triage 整合性 1 軸)** + **案件固有軸 (0–3 個)** で評価する。

### 2.1 固定軸 (Mandatory)
| 軸 | 出典 | 重要度ラベル |
|---|---|---|
| Coherence (出力の論理整合性) | G-Eval (Liu et al. 2023, arXiv:2303.16634) | High |
| Consistency (事実整合性、bizlp 既存 ADR との一貫性) | G-Eval + arc42 section 9 | Critical |
| Fluency (実装可能性、技術的妥当性) | G-Eval | Medium |
| Relevance (bizlp スコープ適合) | G-Eval | High |
| Triage 整合性 (ADR-0020 Light/Standard/Critical 区分) | bizlp ADR-0020 | Critical |

### 2.2 案件固有軸 (Optional, 0–3 個)
- {例: Cost Optimization (AWS Well-Architected 対応)}
- {例: Modifiability (ATAM 対応)}

## 3. Considered Options
### 3.1 Claude 出力
{要約 + 主要主張}
### 3.2 Gemini 出力
{要約 + 主要主張}
### 3.3 GPT 出力
{要約 + 主要主張}

## 4. Evaluation Matrix
| 軸 (重要度) | Claude (1–5) | Gemini (1–5) | GPT (1–5) | 備考 |
|---|---|---|---|---|
| Coherence (High) | 4 | 5 | 3 | |
| Consistency (Critical) | 5 | 4 | 4 | |
| Fluency (Medium) | 4 | 4 | 5 | |
| Relevance (High) | 5 | 5 | 4 | |
| Triage 整合性 (Critical) | 5 | 5 | 5 | |
| **加重和** (Critical=×2, High=×1.5, Medium=×1) | **31.0** | **31.5** | **28.0** | |

## 5. Decision Outcome
**Chosen option**: Gemini ベース + Claude の補強 (Consistency 軸が同点最高、加重和最高)
**Reasoning**: ...

## 6. Consequences
- Positive: ...
- Negative: ...
- Neutral: ...

## 7. Confirmation (Standard/Critical 必須)
- 実装確認方法: ...
- レビュー期日: ...

## 8. Caveats / 限界条件
- 評価軸は事前登録 (pre-registration) 済み。Confirmation bias 回避のため代替案生成前に軸を確定。
- 加重和は Equal weight 寄りの簡略版。Critical 案件では AHP-express の検証を別途実施。
- Multi-Agent Debate を実施した場合の disagreement 度合いを記録。

## 9. References
- ADR-0019 (LangGraph TS), ADR-0020 (Triage 基準)
- MADR 4.0.0: https://adr.github.io/madr/
- G-Eval: Liu et al. 2023, arXiv:2303.16634
- ATAM: CMU/SEI, https://www.sei.cmu.edu/library/the-architecture-tradeoff-analysis-method/

テンプレートの設計原則

1. 固定軸 5 個 + 案件軸 0–3 個 で arc42 推奨の “max 5” + 補助軸数本に収める
2. 5 段階スコア + 重要度ラベルで AHP の数学的厳密性を回避しつつ重み付けを実現
3. 加重和集約 (WSM) を採用、Critical=×2 / High=×1.5 / Medium=×1
4. Critical 案件のみで AHP-express / Multi-Agent Debate を追加実施
5. Caveats セクションでアンチパターン (post-hoc rationalization, confirmation bias) への対策を明示

bizlp 採用推奨案 (400 字以内)

推奨フレームワーク (3 系統ハイブリッド): (1) MADR 4.0.0 をテンプレート構造の骨格に、(2) ATAM/arc42 の Quality Goals (top 3–5) を Decision Drivers の業界アンカーに、(3) G-Eval 4 軸 (Coherence/Consistency/Fluency/Relevance) を Multi-LLM Synthesis の固定評価軸に採用する。

標準テンプレート章構成: Context → Decision Drivers (固定 5 + 案件 0–3) → Considered Options (3 モデル並列) → Evaluation Matrix → Decision Outcome → Consequences → Confirmation → Caveats → References の 9 節構造。

評価軸の必須項目数: 固定 5 軸 (G-Eval 4 軸 + bizlp Triage 整合性) + 案件固有 0–3 軸 = 計 5–8 軸 (arc42 推奨範囲内)。

重み付け手法: Equal Weight + 重要度ラベル (Critical ×2 / High ×1.5 / Medium ×1) の加重和。AHP pairwise は Critical 案件で AHP-express のみ任意適用。

RQ-050/051 への遡及適用方針: Backward-compatible Addendum 形式で「業界対応表」を追記し、既存決定は維持。ADR-0019/0020 を否定しない範囲での拡張適用とする。RQ-053 以降は新標準テンプレートを強制適用。

Recommendations

1. 即時 (RQ-053 から): 上記 9 節 Markdown テンプレートを bizlp Synthesis 標準として導入。Light 案件は Evaluation Matrix 省略可、Standard/Critical では必須。
2. 1 週間以内: RQ-050/051 の Synthesis Addendum を作成、業界対応表を記録。
3. 1 か月以内: LangGraph (ADR-0019 採用済) 上に Synthesis ノードを実装し、AutoGen 風 Critic agent (system prompt: “Double check plan, claims, code from other agents and provide feedback”) を Standard 以上で起動するパイプラインを構築。
4. 検討トリガー: Synthesis 数が累計 100 件超 → Entropy method 等のデータ駆動重み付けへの移行を検討。3 モデル不一致率が 30% 超 → Multi-Agent Debate (Du et al. 2023, arXiv:2305.14325) を標準フローに組込み。

Caveats

• bizlp は 1 人法人 + AI Agent 併用スケールであり、本提言は中〜大規模組織のベストプラクティスを 意図的に軽量化 している。学術的厳密性 (AHP/TOPSIS の数学的精度) と実装速度のトレードオフで後者を優先した結果である。
• G-Eval 4 軸は元来 NLG 評価用 (SummEval ベンチマークで Spearman 相関 0.514) であり、 ADR Synthesis への流用は 筆者の判断による拡張適用。Coherence/Consistency/Fluency/Relevance の解釈を bizlp 文脈に合わせて再定義している点に注意。
• タスクで言及された「Wang et al. ICLR 2024 / Ensemble Decision Making」に厳密一致する論文は特定できなかった。最も近い候補は (i) Wang et al. “Self-Consistency Improves Chain of Thought Reasoning in Language Models” ICLR 2023, arXiv:2203.11171 (sampling + majority vote)、または (ii) Li et al. “More Agents Is All You Need” TMLR 2024, arXiv:2402.05120 (sampling + cumulative similarity ranking)。ICLR 2024 採択の特定論文を意図していた場合は [要追加調査]。
• GitLab Handbook の Engineering decisions プロセスについては、明示的な評価軸ドキュメントを発見できず詳細は [要追加調査]。一般論として「公開議論プロセス重視」と推定。
• ThoughtWorks Tech Radar の Trial 入り基準 (“production usage” 必須) と Adopt 入り基準 (“not using them would be irresponsible”) は別物である点に注意。本報告書では Q4 表内で明示的に区別済み。
• 本テンプレートは 試行版 であり、RQ-053–055 程度で運用検証後に v2 へ更新することを推奨する。Synthesis 累計 100 件時点で重み付け方式の見直し (Entropy method 導入検討) をトリガーとする。