RQ-052 実投入プロンプト: アーキテクチャ意思決定における多基準評価フレームワーク調査
使い方: 以下の本文を ChatGPT (Deep Research) / Claude.ai (Research) / Gemini Deep Research に そのまま投入する。3 モデル並列で実施し、結果はそれぞれ
RQ-052_..._result_gemini.md/_result_claude.md/_result_gpt.mdに保存する。
あなたの役割
あなたはソフトウェアアーキテクチャ意思決定と多基準評価分析 (MCDA) の専門家です。 1 人法人 (Solo Founder) が運用する管理会計 SaaS プロジェクトにおいて、 ADR (Architecture Decision Record) の Synthesis ドキュメントで「複数 LLM の出力を bizlp 採用方針に集約する際の評価軸選定」 を業界ベストプラクティスに沿って確立するための調査を実施してください。
プロジェクト前提
- 規模: 1 人法人 (代表取締役氏)、AI Agent (Claude / Gemini / GPT) 併用
- 既存 ADR 数: 49 件 (ADR-0049 まで)
- 既存 Decision Pipeline: ADR-0019 で LangGraph TS 採用
- 既存 Triage 基準: ADR-0020 で Light / Standard / Critical の 3 段階確立 (学術根拠付き: Kruchten / Zimmermann / Bezos Type 1 等)
- 問題: RQ-050 / RQ-051 Synthesis で 3 モデル相違点を集約する際の評価軸が業界フレームワーク未照合の独自合成だった (PR #811 / #814 close 経緯)
調査タスク
以下の 10 の研究課題に順番に回答してください。
Q1. 多基準意思決定分析 (MCDA) の主要フレームワーク網羅
業界で多基準意思決定分析 (MCDA / MCDM) として確立されたフレームワークを網羅:
- フレームワーク名
- 提唱者・初公開年
- 適用領域
- 一次資料 (URL or 論文 DOI)
- 想定組織規模
最低でも以下を含めること:
- AHP (Saaty 1980), TOPSIS, PROMETHEE, WSM, WPM, ELECTRE, MAUT
- SAAM (Kazman 1994), ATAM, CBAM (SEI Carnegie Mellon)
- Zimmermann's ADMentor / SOAD
- DACI (Atlassian), RACI, Choosing By Advantages (Suhr), Wardley Mapping, Cynefin
- LLM-as-a-Judge, Multi-Agent Debate, Ensemble Decision Making (LLM 系)
Q2. 各フレームワークの評価軸選定アプローチ比較
Q1 の各フレームワークについて、以下の観点で比較:
- 評価軸 (Criteria) の選定方法 (固定 vs 案件ごと vs ハイブリッド)
- 重み付け (Weighting) の手法 (pairwise comparison / equal weight / AHP eigenvector / 直感)
- スコアリングの粒度 (1-5 / 1-10 / qualitative)
- 集約 (Aggregation) の数学的手法 (加重平均 / 幾何平均 / ベクトル距離 等)
Markdown テーブルで網羅すること。
Q3. ソフトウェアアーキテクチャでの MCDA 適用事例
ソフトウェアアーキテクチャ意思決定で MCDA を適用した事例を調査:
- SAAM (Kazman 1994) — シナリオベース評価
- ATAM (Architecture Tradeoff Analysis Method) — 品質属性ベース
- CBAM (Cost-Benefit Analysis Method)
- Zimmermann's ADMentor における意思決定モデリング
- arc42 における Decision Drivers の使い方
- MADR (Markdown ADR) の Decision Drivers セクション
各事例について以下を含めること:
- 評価軸の典型例 (Performance / Security / Cost / Maintainability 等)
- 軸数の典型 (3-5 個 / 5-10 個 / それ以上)
- 重み付けの慣習
Q4. ADR / Synthesis における評価軸選定の業界事例
以下の業界実装事例における Synthesis / Decision の評価軸運用を調査:
- Spotify Engineering (RFC → ADR の意思決定プロセス)
- GitLab Handbook (Engineering decisions の評価軸)
- ThoughtWorks Technology Radar の Adopt 判断軸
- AWS Well-Architected の 6 pillar (評価軸として機能)
- Google Cloud Architecture Framework の 5 pillar
- Anthropic / OpenAI / Google の LLM 評価軸
各事例での「評価軸の出典・選定根拠」を中心に整理。
Q5. 軽量フレームワークの適用領域比較
DACI / RACI / Choosing By Advantages / Wardley Mapping / Cynefin について:
- 適用領域 (誰が・どのフェーズで使うか)
- 評価軸の数 (典型値)
- 1 人法人スケールでの適用可能性 (1〜5 点)
- LLM Synthesis との親和性
Q6. 複数 LLM の出力突合 (Multi-Model Synthesis) に特化した評価軸選定
近年の Multi-Agent / Multi-LLM 評価の先行研究を調査:
- LLM-as-a-Judge (G-Eval, MT-Bench, AlpacaEval 等)
- Multi-Agent Debate (Du et al. 2023 / Liang et al. 2023)
- Ensemble Decision Making (Wang et al. ICLR 2024)
- LangGraph の Multi-Agent Synthesis パターン
- AutoGen の GroupChat / Critic パターン
特に「3 モデル並列調査 → Synthesis」のような bizlp パイプラインに適用可能な評価軸選定パターンを抽出。
Q7. 評価軸の重み付け手法とアンチパターン
評価軸の重み付け (Weight Assignment) について:
- AHP pairwise comparison のメリット・デメリット
- Equal weighting の単純さと限界
- 主観的重み付けのバイアス
- データ駆動 (DEA / Entropy method) の適用可能性
アンチパターン:
- 重み付け根拠の事後合理化 (post-hoc rationalization)
- Confirmation bias (採用したい案に有利な軸を選ぶ)
- Analysis paralysis (軸が多すぎて決定不能)
Q8. 1 人法人 + AI Agent スケールでの省略可能項目
業界フレームワークの中で、1 人法人 + AI Agent 併用スケールで「省略可能」「過剰」と判定される項目:
- 大企業前提項目 (ステークホルダー多数前提の DACI / RACI 等)
- 多数案件向け項目 (AHP の pairwise matrix が大規模化)
- 学術的厳密性のための項目 (TOPSIS / PROMETHEE の数学的処理)
bizlp の MVP 必須項目リスト (5-10 個程度) と 省略可能項目リスト を提示。
Q9. RQ-050 / RQ-051 Synthesis への遡及適用案
bizlp の既存 Synthesis (RQ-050 ADR Scope 分類 / RQ-051 Lint 規約) で使われた独自評価軸を、新フレームワーク (案 Q1-8 の結論) で遡及検証する手順:
- RQ-050 Synthesis の評価軸 (4 階層採用 / Phased Backfill / CodeOps 統合 等の判定根拠) を再評価
- RQ-051 Synthesis の評価軸 (7 節構造 / 5 カテゴリ / 6 メタ項目 等の判定根拠) を再評価
- 既存決定を覆すか維持するかの判断基準
Q10. bizlp Synthesis 標準テンプレートの推奨
以上の調査を踏まえ、bizlp が今後の Synthesis (RQ-053 以降) で採用すべき標準テンプレートを提示:
- 評価軸選定セクションの構造 (固定軸 vs 案件ごと)
- 重み付けの記述方法 (テーブル / 重要度ラベル / 数値)
- スコアリングの粒度 (1-5 / qualitative)
- 採択判定の論理構造 (集約手法 + 閾値)
- Caveats / 限界条件の明示
具体的な Markdown 構造例を 1 件分提示してください。
出力形式
- 各 Q への回答は H2 見出し (
## Q1. xxx) で開始 - 一次資料は 必ず URL or DOI で明示
- 表形式が適切な場合は Markdown テーブルを使用
- 最終セクションで「bizlp 採用推奨案」を 400 字以内で結論
結論には以下を含むこと:
- 推奨フレームワーク (1-3 個)
- bizlp Synthesis 標準テンプレートの章構成
- 評価軸の必須項目数
- 重み付け手法
- RQ-050 / RQ-051 への遡及適用方針
制約
- ChatGPT / Claude / Gemini の Web 検索機能を積極的に使用してください
- 一次資料がなく憶測で書く場合は
[要追加調査]と明示 - 1 人法人 + AI Agent スケールでの実用性を重視
- 学術的厳密性 > 実装速度 だが、過剰設計は避ける
- bizlp 既存 ADR-0019 / 0020 の方針を否定しない範囲で拡張提案
参考情報 (bizlp 既存)
- ADR-0019: Decision Pipeline LangGraph TS 採用
- ADR-0020: Triage 基準 4 カテゴリ (対象外 / Light / Standard / Critical) の学術根拠 (Kruchten / Nygard / Zimmermann / Bezos / Chen et al.)
- RQ-050 Synthesis: ADR Scope 4 層 (Corporate/Platform/Product/Ops) 採用、評価軸独自合成
- RQ-051 Synthesis (close): Lint 規約ドキュメント 7 節構造採用、評価軸独自合成
- PR #811 / #814 が業界調査未実施で close した経緯