RQ-052 GPT Deep Research 結果: MCDA フレームワーク調査と Synthesis 標準テンプレート

Q1. MCDA主要フレームワーク一覧

以下は代表的な多基準意思決定(MCDA/MCDM)フレームワークの一覧です。想定される適用領域や組織規模も併記しました。

（注）「想定規模」は一般的な適用例であり、実際の組織や文脈による相違あり。一次資料は代表的な論文・資料を示しています。【83†L351-L360】【76†L206-L214】【79†L38-L46】【81†L57-L63】【92†L164-L172】などは該当フレームワークの情報源です。

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

以下に主要フレームワークの評価軸（Criteria）選定と重み付けの特徴をまとめます。

• 補足:
  • 階層間の境界は、通常ドキュメント・アーキテクチャ全体(Enterprise) vs 部分的構成(Segment/Service) vs 個別機能/モジュール(Code)などで規定されます。例えば「どの階層で課題を見るか」は影響範囲や責任分界で区別します。
  • 階層を跨いだ変更では「領域をまたぐべきではない」アンチパターン（過剰分散設計）とみなすことがあります（例: プラットフォームの変更で個別機能のみ影響すると想定すると齟齬）。
  • フレームワークによっては事例特有にクリテリアを選定する場合と、業界標準セットから選ぶ場合があります（表参照）。

Q3. ソフトウェアアーキ評価事例の評価軸

ソフトウェアアーキテクチャ評価手法では、通常以下のような品質属性（Performance, Security, Cost, Maintainabilityなど）が評価軸（Drivers/Criteria）となります。代表例ごとに典型的な軸や特徴を示します。

• SAAM: シナリオ（例：新規機能追加、負荷変動時の応答性、障害時復旧など）を評価軸とする。これらはモディファイアビリティ、信頼性、性能、安全性、使い勝手など、3～5個程度の品質特性に相当。シナリオの重要度は関係者の優先度で重み付け【52†L25-L34】。
• ATAM: ビジネスゴールから導かれる品質属性（例：性能、スケーラビリティ、安全性、可用性）。通常4～8種程度を検討。重みはステークホルダーの相対重要度（ユーティリティツリー上での優先順位）で扱う【43†L36-L45】。
• CBAM: コスト、ベネフィット、リスク、スケジュール影響など経済面の軸。各代替案のコストと品質改善効果を評価。軸数は比較的少数（3～5）で、重みはビジネス価値を基に算出する。
• Zimmermann (SOAD/ADMentor): サービス指向アーキテクチャでは、機能パターンやプラットフォーム利用度などが軸。ADMentorでは代替案の利点やトレードオフをモデル化するが、定量評価ではなく意思決定フローに組み込む形式。
• arc42: 「Decision Drivers」として、要件・制約（例：セキュリティ要件、レガシーマイグレーション、パフォーマンス必要条件など）を列挙。通常3～6項目。定性的に重要度を記載し、明示的な重み付けはしない。
• MADR (Markdown ADR): 各ADRの「Decision Drivers」セクションで挙げるのは、設計決定に影響する要因（例：既存システムとの整合性、コスト要素、ユーザ要望、安全要件など）。通常2～5個を短文で列挙【51†L286-L294】。重み付けはなく、単に考慮事項の羅列となる。

Q4. ADR/Synthesis事例の評価軸運用

• Spotify (RFC→ADR): 公式に明示された評価軸は少ないが、ADR投稿のガイドとして「**重大な影響(＝Significant impact)**がある決定はADRに記録すべき」としています【54†L61-L64】。つまり「影響度・重要度」が主要な判断軸です。
• GitLab Handbook (Engineering decisions): GitLabは社内価値（特に「成果(Results)」）を最高位に置く価値階層を設定し、これが意思決定の指針となっています【57†L66-L74】。つまり、「バリューへの合致度」を軸に決定を下す文化です（具体的な数値基準より、価値観による判断）。
• ThoughtWorks Technology Radar: 4つのリング（Assess/Trial/Adopt/Caution）で技術アイテムを評価。各リングへの分類基準は、チームの「実運用経験と成熟度（他社での利用実績）」によります【61†L298-L307】。たとえば「Adopt」は実用例多数で推奨レベルを示します【61†L298-L307】。
• AWS Well-Architected Framework: 6本柱（Operational Excellence, Security, Reliability, Performance Efficiency, Cost Optimization, Sustainability）を評価軸に使用【63†L12-L16】。各柱に関するチェックリストの達成度を評価し、総合的な健全性を判断します【63†L12-L16】。
• Google Cloud Architecture Framework: 5本柱（Operational Excellence, Security/Privacy, Reliability, Cost Optimization, Performance Optimization）を評価軸とします【68†L55-L61】。AWSと同様に各柱に沿ったベストプラクティスの実施状況から設計品質を判断します【68†L55-L61】。
• Anthropic/OpenAI LLM 評価軸:
  • Anthropic: モデル設計の柱として「Helpfulness, Honesty, Harmlessness (HHH)」を掲げ、安全・整合性評価の基本軸としています【71†L39-L45】。
  • OpenAI/Anthropic Safety Tests: 共同評価では「命令階層 (Instruction Hierarchy)」「Jailbreaking 抵抗性」「Hallucination（幻覚）回避」「Scheming（悪用耐性）」といった基準でモデル出力を検証しています【74†L1-L4】。

Q5. 軽量フレームワーク比較

• 適用場面: DACI/RACIはチーム・ステークホルダー管理向け、CBAは複数案の比較、Wardley/Cynefinは戦略・複雑系対応。
• 1人法人適用度: DACI/RACIは多数メンバー前提で基本不要、Cynefin/Wardleyは大局的フレームワークで大企業向け。CBAは比較的軽量ですが、フル活用はやや大げさなので中程度評価。
• LLM親和性: 役割フレームワークはLLM評価軸になりにくい。CBAや戦略マッピング系は、LLMを使って代替案の利点やマップ描画を補助できるため中程度の親和性。

Q6. LLM多数出力突合向け評価法

• LLM-as-Judge (G-Evalなど): LLM自身に対して「正答性」「一貫性」「文体」「安全性」などカスタム基準で採点させる手法【86†L187-L194】。例：G-Evalは「Answer Correctness, Coherence, Tonality, Safety」等のメトリクスで出力を評価【86†L187-L194】。
• Multi-Agent Debate: 複数のLLMエージェントが交互に意見を出し合い、互いの出力を検討・修正する枠組み。Du et al. (2024) らは「Multi-Agent Debate」により各モデルの回答をブラッシュアップし、最終的な結論を得る手法を示している【92†L164-L172】（Liang et al. 2024 では役割分担も拡張）。
• Ensemble Decision Making: 複数モデルの回答を集約（多数決や重み付き平均）して最終出力を決定する手法。例えば複数回答の「もっともらしさ」を統計的に処理する。Wang et al. (ICLR2024) など研究も進む概念。
• LangGraph型マルチエージェント: 複数専門エージェント（例：要件専門、実装専門）が並列動作し、インタラクティブに結論を統合するパターン。bizlpのLangGraphはシステム構成をモデル化し、各モデルの出力を組み合わせる手法と親和性高い。
• AutoGen GroupChat/Critic: Microsoft AutoGenの「Group Chat」機能ではエージェント間対話でタスクを処理でき、特にCritic役割のエージェントを設けて他のエージェントの出力を検証・修正できる【95†L13-L20】。これを活用して複数LLMからの案を検証させる運用が可能。

以上から、bizlpの3モデル評価→Synthesisパイプラインでは、「LLMジャッジ」(例:G-Eval)や「マルチエージェントディベート」(例:Du et al.)がそのまま適用可能なパターンです。AutoGenのCriticも類似の役割を果たします。

Q7. 重み付け手法とアンチパターン

• AHP (ペアワイズ比較): メリットは「一貫した比較から厳密に重みを算出できる」点【96†L7-L11】。デメリットはペア数が増えすぎると手間が膨大になることと、一貫性指標チェックが必要で人手の根気を要すること。
• 等ウェイト: 手法は単純で実装容易。全評価軸を同等に扱うが、軸の重要度が実際と異なる場合に不整合になる（過小評価・過大評価リスク）。
• 直感的重み付け: 専門家の経験や勘に頼る方法で速いが、バイアス（confirmation bias）や後付けの根拠作りに陥りやすい。重み付けの妥当性を客観的に検証しにくい。
• データ駆動法 (DEA, エントロピー法): 可能なら客観性が増す。例えば評価データからエントロピー法で重みを算出し、主観を排除する。ただし1人法人では十分なデータが得にくく、処理過剰になる場合もある。

アンチパターン:

• 重み付け根拠を後付けする(post-hoc rationalization)：評価後に自分に都合よい重み付けを正当化しないこと。
• コンファメーションバイアス：既に支持したい結果に合うような評価軸・重みづけを選ぶことを避ける。
• 分析麻痺：評価軸を増やしすぎ、重み付けや集計に時間がかかりすぎて決定が遅れること。小規模プロジェクトでは3～5軸程度に絞るのが経験則。

Q8. 1人法人＋AI規模で省略可項目

1人＋AIワークフロー向けには、以下のような過剰な手法・項目が省略可能です。

• 大企業前提項目: DACI/RACIのような多人数協調前提の責任分担マトリクス。社内役割固定が少人数では不要です。
• 大規模ケース向け項目: AHPのペアワイズ行列（基準が多いと平方級に増える）、ELECTREの多段階比較ルール、TOPSIS/PROMETHEEの複雑な数理モデル等。1人＋AIでは数軸程度に絞れば充分で、これらの重厚な手続きをスキップできます。
• 学術的厳密さ重視項目: PROMETHEEの閾値設定やELECTREの詳細ルール、CCE演習等（教育目的の詳細式）。実務的には単純な加重平均や効用関数で代用可能です。

bizlpのMVP必須項目例 (5–10個程度):

• 明文化した評価軸リスト（例：影響度, 効率性, コスト/工数, 安全性, 将来性）
• 軽量な重み付け (例：高/中/低 等で段階評価)
• 簡易スコアリング (1–5の定性評価)
• 集計手法の記述 (加重平均や多数決)
• 前提条件・制約の明示 (範囲や対象バウンダリの定義)

省略可能項目:

• 細かいバージョン管理上の移行ガイドライン（大規模組織向け）
• ステークホルダーワークショップの実施手順（1人法人では代替のAIレビューフローで十分）
• 複数ケースに共通化するための体系的ドキュメンテーション（MVPでは不要）

Q9. RQ-050/051の評価軸再検証

手順: 前回独自定義した評価軸を、今回選定したフレームワークやMCDA指針に照らして吟味します。具体的には：

• RQ-050（Scope分類）: 提案した4層（Corporate/Platform/Product/Ops）の決定根拠を評価軸に対応付け。例えば「企業全体への影響度」「共通基盤 vs 個別製品の区分」などAHP的に評価して、各層設定の妥当性を数値的に検証。もし新基準（例：ステークホルダー視点、コスト影響、運用頻度）で既存の判定が合致するかを見る。必要あればフレームワークに沿った判定基準を追加・修正します。
• RQ-051（Lint規約構造）: 採用した「7節構造」「5カテゴリ」「6メタ項目」の選定根拠をMCDA基準（例：網羅性、可読性、保守性）で再評価。たとえば各章の重要度をAHPで重み付けし、本来もっと重要視すべき要素（例：例示の有無）を取りこぼしていないかを検討。フレームワークで不足があれば補強し、それでも大きく外れる場合は再検討します。

判断基準: 以上の再評価で「既存軸で合理的か」「見落としなし」「1人法人規模で簡便か」を確認。根本的に不十分であれば修正案を検討しますが、業界標準との整合や既存ADR方針を尊重しつつ必要最小限に留めます。

Q10. Synthesis標準テンプレート案

推奨フレームワーク: AHP風の重み付け＆加重評価、または簡易なWeighted Scoring法。bizlp規模に合わせて軸固定と簡易化を両立します。

標準テンプレート（章構成・記載例）:

# Synthesis: [課題名]

## 1. 評価基準の選定
- **基準1**（例: 影響度）: [説明]
- **基準2**（例: 実装工数）: [説明]
- **基準3**（例: 安全性/品質）: [説明]
- （計5–7個推奨、明確な定義）

## 2. 重み付け
基準ごとの重要度を [高/中/低] または数値 (合計10 or 1.0) で割当て。
例: 影響度(3), 工数(1), 安全性(2) → 合計=6。

## 3. 代替案とスコアリング
| 代替案             | 基準1 | 基準2 | 基準3 | ... | 合計スコア |
|----------------|:----:|:----:|:----:|:---:|:------:|
| 案A: パターンX採用   | 5    | 3    | 4    | ... |  (計算) |
| 案B: パターンY採用   | 3    | 5    | 2    | ... |  (計算) |
> スコアは1–5段階。合計スコア = Σ(基準スコア×重み)。

## 4. 判定と選択
- **最終候補**: 合計スコア最大の案を推奨。閾値（例: 7点以上）を定義し、合格ライン未満なら再検討。
- **ロジック**: 加重平均で判断。点数が接近する場合は重要度の高い基準で選択。

## 5. Caveats / 限界
- 選定軸はbizlpプロジェクト特有のもの。大規模組織では追加基準が必要になる可能性がある。
- 重みは暫定的なものであり、必要に応じてレビュー・調整する。
- LLM評価支援: 各基準の詳細説明をシステムプロンプトに含め、モデルの採点一貫性を高める工夫が有効【86†L187-L194】。

（例: 「ADR-Lint規約のSynthesis」では、基準に「記述例の有無」「自動修正可否」「整合性チェック容易性」などを設定し、前述のテンプレ構造で採点・比較するイメージです。） 関連ADRには本文中に【ADR-0020】【ADR-0049】のようにリンクし、関連する方針や用語に注釈を付けて紐付けます。changelog/deprecation枠は今回は不要と判断します。

bizlp採用推奨案（結論、400字）

推奨フレームワーク：軽量版AHP/Weighted Scoring（固定5–7基準）を採用。固定軸で簡便に扱い、必要時のみカスタマイズします。 章構成：①評価基準定義、②重み付け、③代替案とスコア表、④判定・結論、⑤限界・注意。各節はMarkdownテーブルと箇条書きで明瞭化します。 必須項目（各基準ごと）: 条件/説明、重み、スコア例、合計計算（計3–5要素）。省略可能: 詳細なペア比較結果や廃止履歴ログなど大規模組織向け項目。Rationalやfixable詳細は短文要約程度に留めます。 rationale/examples：簡潔な1–2文説明とBefore/Afterコード例（必要あれば）を併用推奨。LLM判定のしやすさ重視で、明示的命名や箇条書き形式を使います。 AI Agent対応：各基準はフロントマターやメタデータとしても読めるよう統一書式（例：「weight: 3」）で提示し、LLMプロンプトで評価時に利用します。コードブロック形式で評価手順を要約することで、ChatGPT系のプロンプトにも適合します。 ADR-0022との関係：Scope分類はADR-0022の「Platform/Tenant」の下位に位置づけ（Extend）し、拡張版としてCorporate/Product/Ops層を追加。既存ADRは参照しつつ、新分類軸で再整理します。 Tier連動：Tier (Light/Standard/Critical) はScopeと直交可能なまま保持し、必要に応じCritical案のみ各Scope層で厳格評価します。Industry文献と照合し不要な過剰設計を避けつつ、1人法人規模で実用的な2軸マトリクス運用とします。