ソフトウェアアーキテクチャ意思決定における多基準評価フレームワークと複数LLM集約(Synthesis)に関する包括的調査報告

現代のソフトウェアアーキテクチャ設計において、複数の相反する要件（パフォーマンス、コスト、保守性など）を調和させる意思決定は極めて高度な分析を要求される。特に、1人法人（Solo Founder）が自律型AIエージェント（LLM）と協働してシステムを構築する最先端のパラダイムにおいては、AIの出力をいかに客観的かつ再現性のある形で集約（Synthesis）するかが、プロジェクトの成否を分ける。本報告書は、オペレーションズ・リサーチにおける多基準意思決定分析（MCDA）の基礎理論から、ソフトウェアエンジニアリング特有の評価体系、さらには近年のマルチエージェントディベート手法に至るまでを網羅的に調査し、管理会計SaaSプロジェクト「bizlp」における最適なArchitecture Decision Record (ADR) の評価軸選定アプローチを提示するものである。

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

多基準意思決定分析（MCDA: Multi-Criteria Decision Analysis / MCDM）は、単一の指標（例えば利益の最大化のみ）ではなく、経済性、社会的影響、技術的実現可能性など、複雑に絡み合う複数の評価基準を構造化し、透明性の高い評価を可能にする手法群である 。この領域は歴史的に「アメリカ学派（効用関数ベース）」と「ヨーロッパ学派（アウトランキングベース）」に大別され、さらに近年ではソフトウェアアーキテクチャやAIエージェントに特化した派生フレームワークが誕生している 。以下に業界で確立された主要フレームワークを網羅する。

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

MCDAの根幹は、設定された評価軸に対してどのような数学的・論理的処理を施すかに依存している。古典的なMCDAから最新のLLMアンサンブルに至るまで、評価軸の選定、重み付け、スコアリング、および集約の数学的手法には明確な設計思想の違いが存在する 。

これらの比較から示唆されることは、厳密な数学的処理（AHPの行列計算やTOPSISの距離空間演算）は完全な情報と高い計算リソースを前提としており、不確実性の高いアジャイルなソフトウェア開発には過剰であるということだ。一方で、ATAMやCBAのような定性・定量ハイブリッドアプローチは、意思決定の「理由（Rationale）」を記録する上で優れた適応性を示す。

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

ソフトウェアアーキテクチャにおける意思決定は、機能的要件だけでなく非機能要件（品質特性）間のトレードオフを解決する行為である。この領域では、純粋な数学的MCDAを適用するのではなく、ドメインに特化した定性的な評価軸を用いて論理的帰結を導く手法が標準となっている。

1. SAAM (Software Architecture Analysis Method) と ATAM (Architecture Tradeoff Analysis Method)

カーネギーメロン大学のソフトウェア工学研究所（SEI）によって開発されたこれらの手法は、アーキテクチャ評価の金字塔である 。SAAMは主にシステムの「変更容易性（Modifiability）」などをシナリオを用いて検証する初期手法であった。これが発展したATAMでは、評価軸としてPerformance（性能）、Security（セキュリティ）、Maintainability（保守性）、Availability（可用性）といった品質属性（Quality Attributes）が用いられる。

ATAMの最大の特徴は、評価軸をトップダウンで押し付けるのではなく、Quality Attribute Utility Treeと呼ばれる構造を用いて、一般的な品質属性をプロジェクト固有の「シナリオ」に落とし込む点にある。軸数は通常、ツリーから抽出された最優先の3〜5個に絞り込まれる。重み付けはステークホルダーによる「High/Medium/Low」の投票（Priority）という簡素な慣習が採られている 。

2. CBAM (Cost-Benefit Analysis Method)

ATAMが技術的リスクの特定に優れている反面、経済的合理性の観点が欠如している点を補完したのがCBAMである 。CBAMは、ATAMで導出されたアーキテクチャ決定に対して、コスト（開発費・運用費）とベネフィット（ビジネス価値）、およびROI（投資対効果）という強力な経済的評価軸を導入する 。ここでの重み付けは、実態としての「金額」や「期待リターン」という絶対的指標に収束する。

3. ADMentor における意思決定モデリング

Olaf Zimmermannによって提唱されたADMentor（SOADフレームワークの一部）は、アーキテクチャ意思決定を「再利用可能な資産（Reusable Design Assets）」として扱う 。評価軸の典型例としては、クラウド移行時の「トランザクション境界」や「サービス粒度」といった極めて具体的な技術基準が用いられる。ADMentorでは、重み付けの数値計算よりも、メタ情報（Owner RoleやViewpoint）による検索性と、QOC（Question-Option-Criteria）ダイアグラムを用いた論理的なトレーサビリティの確保が慣習となっている 。

4. arc42 における Quality Model (Q42) と Decision Drivers

アーキテクチャドキュメントの標準テンプレートであるarc42は、ISO 25010のような複雑な階層型品質モデルを実用的に再構築した「Q42品質モデル」を提供している 。Q42では、200以上の伝統的な品質特性をたった9つの形容詞タグ（#reliable, #flexible, #maintainable, #efficient, #usable, #operable, #suitable, #secure, #safe）に集約し、これらを評価軸として用いる。プロジェクト開始時にトップ3〜5個の品質目標（Quality Goals）を選択し、その後のアーキテクチャ決定（セクション9）において、これらのタグがDecision Driversとして機能する。重み付けは、シナリオの優先度として定性的に記述される 。

5. MADR (Markdown ADR) の Decision Drivers セクション

軽量なADRフォーマットであるMADRでは、## Decision Drivers というセクションが設けられ、直面している懸念事項や技術的制約が箇条書きで定義される 。軸数は通常3〜5個程度であり、重み付けは暗黙的なものが多く、「K.O. criterion（ノックアウト基準：これを満たさない選択肢は直ちに排除される）」といった強い制約として記述される慣習がある 。

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

業界を牽引するテクノロジー企業は、意思決定のスピードとドキュメントの品質のバランスを取るため、厳密なMCDAよりも独自の評価軸（Pillars）や実用的なテンプレートを好んで採用している。これらの事例は、LLMを用いたSynthesisにおいて「どのような評価軸を与えるべきか」の優れた指針となる。

Spotify Engineering の意思決定プロセス

Spotifyでは、システム設計やエンジニアリングのベストプラクティスに関連する決定をRFC (Request for Comments) で議論した後、ADRとして記録する 。彼らの評価軸は固定のフレームワークに縛られることなく、案件固有のコンテキスト（例：React Hooks採用によるコードの可読性や保守性の向上）に基づいて抽出される。この運用の主たる選定根拠は「オンボーディングコストの削減」と、アジャイルな組織変更に伴う「システムのオーナーシップ引き継ぎ」におけるコンテキスト喪失を防ぐことにある 。

GitLab Handbook のアーキテクチャデザインワークフロー

GitLabは完全な非同期・リモートワーク組織であり、「Design Document」をソースコードと同様にMerge Request上で管理する「Design as Code」のワークフローを確立している 。評価軸としては、複数チームへの影響度、システムの全体的な安定性、可用性、パフォーマンス、そして運用負荷が重視される。特にセキュリティは強力な評価軸として機能し、影響が懸念される場合は事前の脅威モデル（Threat Model）の作成が義務付けられる。10日間という明確なレビューのタイムボックスを設けることで、分析麻痺を防いでいる 。

ThoughtWorks Technology Radar

ThoughtWorksは定期的にTechnology Radarを発行し、技術の採用段階を「Adopt, Trial, Assess, Hold」の4象限で評価する。ここでのAdopt（採用推奨）の判断軸は、単なる技術の新しさではなく、エンタープライズ規模での実績、エコシステムの成熟度、そしてテスト容易性やデプロイの安定性といった実運用上の堅牢性に基づく。

AWS Well-Architected Framework の 6 Pillars

Amazon Web Services (AWS) が提唱するこのフレームワークは、クラウドアーキテクチャの評価において事実上の業界標準となっている。評価軸は以下の6つのPillar（柱）に固定されている。

1. Operational Excellence（運用上の優秀性）
2. Security（セキュリティ）
3. Reliability（信頼性）
4. Performance Efficiency（パフォーマンス効率）
5. Cost Optimization（コスト最適化）
6. Sustainability（サステナビリティ）

これらの柱は、Amazon自身の長年の大規模分散システム運用経験から演繹された普遍的な評価軸であり、あらゆる意思決定の根底に流れる制約条件として機能する。

Google Cloud Architecture Framework の 5 Pillars

Google CloudもAWSと極めて類似したアプローチを採っており、以下の原則を固定軸としている。

1. Operational excellence
2. Security, privacy and compliance
3. Reliability
4. Performance
5. Cost Optimization

Googleのフレームワークは、サイトリライアビリティエンジニアリング (SRE) やBeyondCorp（ゼロトラストセキュリティモデル）といった、Google独自のエンジニアリング文化と運用プラクティスが強く反映されている点が特徴である 。

LLM-as-a-Judge における評価軸

Anthropic, OpenAI, Googleなどが主導するLLM自体の評価（AlpacaEval, MT-Bench等）においては、評価軸はプロンプト内のルーブリックとして明示的に与えられる。典型的な評価軸は「Coherence（一貫性）」「Accuracy（正確性）」「Relevance（関連性）」「Helpfulness（有用性）」などである 。これらは、人間の専門家による多面的な評価（Multi-dimensional human evaluation）をAIエージェントに模倣させるために意図的に設計されている 。

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

1人法人（Solo Founder）とAIエージェントの協働というスケールにおいては、複雑な組織力学やマルチステークホルダー間の合意形成を前提とする重厚なフレームワークは排除されなければならない。軽量・ビジネス戦略フレームワークの適用領域と、1人法人スケールにおける有用性を比較する。

分析の結論:

DACIやRACIのような「誰が決定するか」を問う調整型フレームワークは、1人法人体制においてはノイズとなる。一方で、Choosing By Advantages (CBA) のアプローチは特筆に値する。一般的なPros/Consリストでは、「ある案の短所」が「別の案の長所」として二重にカウント（Double counting）されるという致命的な論理的欠陥が生じやすい 。CBAはこの二重カウントを排除し、「オプション間の実質的な違い（Advantages）」のみを評価する。この論理構造は、複数LLMの出力を突合する際、LLMが陥りやすい「矛盾した利点の合成」を防ぐためのプロンプト設計基盤として極めて優秀である。

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

Bizlpパイプラインにおいて既存の課題であった「複数モデル（Claude / Gemini / GPT）の相違点を集約する際の評価軸のブレ」を解決するためには、近年のLLMエージェント評価、特にマルチエージェントディベートとアンサンブル学習の先行研究を紐解く必要がある。

1. LLM-as-a-Judge の基本パラダイム

LLM自身を評価者として用いるパラダイムは、スケーラブルな自動評価の標準となりつつある 。

• Pointwise評価: 各モデルの出力に対して、与えられた基準（Coherence等）に基づき独立して絶対的なスコアを付与する手法 。
• Pairwise評価: 2つの出力を比較し、どちらが優れているかを相対的に判定する手法 。
• Checklist評価: 複雑な評価タスクを詳細な基準駆動型のチェックリストに分解し、透明性の高い評価を行う手法 。

2. MAJ-Eval (Multi-Agent-as-Judge Debate Evaluation)

単一のLLMによる評価の限界（特定のバイアスへの偏り）を克服するため、複数のペルソナを持つエージェントを協調させる枠組みがMAJ-Evalである 。

• Phase 1 (Individual Agent-as-a-Judge): 自動生成された異なるステークホルダーペルソナ（例：セキュリティ専門家、コストアナリスト）を持つ各エージェントが、独立して出力内容を評価する。
• Phase 2 (Multi-Agent In-Group Free Debate): エージェント間でオープンのディベート（フリーフォームの議論）を実施し、互いの評価を検証・洗練させる 。
• Phase 3 (Aggregation): 最後にモデレーター（Aggregator）が、各エージェントのディベート後の定性的なフィードバックを統合要約し、定量スコアを平均化して最終結果を出力する 。

3. Ensemble Decision Making (LLM Ensemble)

WangらによるICLR 2024の調査は、複数のLLMの回答を合成する手法を体系化している 。

• Routing / Cascade: 出力の品質を逐次評価し、一定基準（確信度など）に満たない場合は、より大規模で強力なモデルに推論を委譲する手法。
• Selection-then-Regeneration: 複数モデルから得られた回答候補を、評価モジュール（PairRanker等）が評価軸に基づいて選択・ランク付けし、その上位結果をプロンプトに組み込んで最終的なGeneratorモデルが新たな回答を再生成・合成する手法 。

Bizlpパイプラインへの適用パターン抽出

「3モデル並列調査 → Synthesis」というBizlpのLangGraph TSパイプラインにおいては、アンサンブル学習における Selection-then-Regeneration と、前述の CBA (Choosing By Advantages) を高度に融合させたアプローチが最適解となる。

各LLM（Claude, Gemini, GPT）が出力したアーキテクチャ案を、単純な「Pros/Consの箇条書き」として独自合成するのではなく、Aggregator Agent（LangGraph上の合成ノード）に対して、「3つの案を比較し、それぞれが持つ『客観的に有利な差異（Advantages）』のみを抽出し、事前定義された評価軸（後述のarc42 Q42タグ等）に照らして最も重要なAdvantageを持つ案を一つ再生成せよ」 という厳格なプロンプトを与える。これにより、モデル間の矛盾した主張をそのまま混ぜ合わせるハルシネーションを防ぐことが可能となる。

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

アーキテクチャの意思決定において、評価軸の重み付け（Weight Assignment）は結果を恣意的に操作し得る最も脆弱なプロセスであり、認知バイアスが介入しやすい。

重み付け手法の比較と限界

• AHP Pairwise Comparison (一対比較)
  • メリット: 基準間の相対的な重要度を総当たりで比較し、固有ベクトルを計算するため、人間の主観的な判断を数学的かつ一貫性のある重み（ウェイト）に変換できる強固な理論的基盤を持つ 。
  • デメリット: 評価軸の数（n）が増えると、比較回数（n(n-1)/2）が爆発的に増加する。アジャイルな開発や1人法人スケールでは、このマトリクス構築の労力自体が意思決定のボトルネックとなる。
• Equal Weighting (均等重み付け)
  • メリット: 手続きが極めて単純であり、LLM-as-a-Judgeにおける初期設定としても多用される。
  • 限界: 現実のシステム設計において、「開発コスト」と「致命的なセキュリティリスク」が常に等価であることはあり得ない。均等重み付けは現実のトレードオフを覆い隠してしまう。
• データ駆動的手法 (Entropy method / Standard Deviation)
  • 適用可能性: データ群の分散や情報エントロピーに基づき、選択肢間で差異が大きい基準に自動的に高い重みを付与する手法 。AIによる完全自動スコアリングとは相性が良い。しかし、ビジネス上の「戦略的意図（例：今はパフォーマンスを犠牲にしてでも開発速度を取りたい）」が全く反映されないという致命的な欠点がある。

意思決定におけるアンチパターンと認知バイアス

ソフトウェアエンジニアリングの意思決定に関する実証研究では、人間の思考プロセスや認知バイアスが結果に重大な悪影響を及ぼすことが確認されている 。

• Post-hoc Rationalization (事後合理化)
  • 意思決定者（またはプロンプトを記述するエンジニア）が、心の中で既に採用したい技術やツールを決めており、その特定の選択肢が勝者となるように、後付けで評価軸を調整・選定する行為。MCDAの客観性を根本から破壊する。
• Confirmation Bias (確証バイアス)
  • 新しい情報を受け取った際、自らの既存の信念や初期の仮説に合致する情報を過大評価（過剰重み付け）し、相反する証拠を無視する心理的傾向 。知覚的意思決定の研究によれば、これは「初頭効果（Primacy effects）」を引き起こす主要因であり、近似的な階層推論のバグとも言える 。LLMもプロンプトの文脈によってこの確証バイアスを容易に引き継ぐ。
• Analysis Paralysis (分析麻痺)
  • 厳密性を求めるあまり、ISO-25010のような数十項目に及ぶ評価軸を全て網羅しようとし、マトリクスが肥大化して最終的な決定が下せなくなる状態 。

アンチパターン回避戦略

これらのバイアスを防ぐためには、評価軸の選定と重み付けを「選択肢を評価する瞬間」に行うのではなく、AWSの6 Pillarsやarc42の9 Dimensionsのように事前に固定された上位の概念群（Decision Drivers）を用意しておき、そこから案件に必要なものをトップダウンで3〜5個選定するという制約を設けることが極めて有効である 。

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

エンタープライズアーキテクチャ向けの重厚なMCDAフレームワークから、Bizlpの実運用（1人法人代表取締役氏 + LangGraph）に最適化するため、過剰な設計要素を大胆に削ぎ落とす必要がある。

省略可能・過剰な項目リスト

1. マルチステークホルダー間の合意形成・権限調整プロセス
   • DACIやRACIに見られる「誰が承認者（Approver）か」「誰が助言者（Consulted）か」という役割分担。ステークホルダーが1人＋AIの環境下では、すべての意思決定責任はソロファウンダーに帰着するため、記録の無駄である。
2. 複雑な数学的正規化とマトリクス演算
   • TOPSISにおける正規化決定行列の生成や、AHPの大規模な一対比較マトリクス計算 。LLMは複雑な行列の数値計算プロセスにおいてハルシネーションを起こすリスクがあり、また人間がその計算過程を直感的に検証しづらいため排除する。
3. 厳密な財務・経済的ROIモデルの構築
   • CBAMが要求するような、中長期的な収益予測に基づく精緻な財務モデル構築 。スタートアップにおいては仮説の不確実性が高すぎるため、定性的な「コスト効率の良さ」程度に留めるべきである。

bizlp MVP (Minimum Viable Product) 必須項目リスト

MADRの簡潔さとCBAの論理性を組み合わせ、LLMが確実に集約・生成できる以下の項目を必須（MVP）とする。

1. Context (背景と問題提起): なぜこの意思決定が必要か、どのような制約があるか。
2. Decision Drivers (評価軸の選定): 事前定義されたフレームワーク（例：arc42のタグ）から、本件に適用される3〜5個の軸を抽出。
3. Considered Options (検討した選択肢): 3つのLLM（Claude/Gemini/GPT）から提案されたアーキテクチャ案。
4. Extracted Advantages (CBAに基づく優位性の抽出): 各選択肢が、他の選択肢と比較して「明確に優れている点」のみのリスト（短所は裏返しであるため記載しない）。
5. Decision Outcome (採用案): 最終的な結論。
6. Justification (重み付けと採択理由): 最も優先度が高いDecision Driverに対して、どの案のAdvantageが最も決定的な寄与（K.O. criterion等）をしたかという論理的説明 。
7. Caveats / Consequences (影響とトレードオフ): 採用案によって生じる副作用や受け入れた妥協点。

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

過去にPR #811 / #814でクローズされた「RQ-050（ADR Scope分類）」および「RQ-051（Lint規約）」のSynthesisは、評価軸が「業界フレームワーク未照合の独自合成」であったことが問題視された。これらを新フレームワーク（MVPリストとCBA原則）で遡及検証（Retroactive validation）する手順を示す。

RQ-050 Synthesis (ADR Scope 4階層分類) の遡及評価

• 既存事象: Corporate / Platform / Product / Ops の4階層を採用した根拠が、明確な外部フレームワークに基づかない独自合成であった。
• 遡及検証手順:
  1. Driverの再定義: arc42のQ42タグから、ADR管理に関連する評価軸をトップダウンで選定する。例えば #maintainable（保守性：ADRの管理・検索のしやすさ）と #suitable（適合性：Bizlpの1人法人＋エージェントという構造への適応度）をDriverとする。
  2. CBA（優位性）の抽出: 過去のLLM出力を再評価し、「3階層案」「4階層案」「5階層案」について、それぞれの「明確なAdvantage」のみをリストアップする。
  3. 判断基準: 4階層案が持つAdvantage（例：「PlatformとProductを分離することで、AIエージェントに与えるコンテキスト境界を明確に分離できる」等）が、Bizlpの #suitable に対して最も影響力が大きいと論理的に証明（Justification）できれば、既存決定を 維持（Confirmed） とする。証明できなければ再検討する。

RQ-051 Synthesis (Lint規約ドキュメント) の遡及評価

• 既存事象: 7節構造 / 5カテゴリ / 6メタ項目 といった複雑な構造の採用根拠が、不明瞭な独自評価軸であった。
• 遡及検証手順:
  1. Driverの再定義: Lint規約は日々の開発体験に直結するため、#operable（運用性：CI/CDでの回しやすさ、エージェントの読み取りやすさ）と #reliable（信頼性：ルールの逸脱のなさ）をDriverに設定する。
  2. バイアス検証: 「確証バイアス」や「事後合理化」が働いていないかを検証する。「最初からなんとなく詳細な7節構造が良いと思っていた」ために、他のシンプルな案（例：3節構造）が持つAdvantage（例：学習コストの低さ、プロンプトトークン量の削減）を軽視・無視していなかったかを、各モデル（Claude/Gemini/GPT）の生出力に立ち返って再評価する。
  3. 判断基準: もし「軽量な運用（#operable）」を最上位Driverに据えた場合、7節構造がオーバースペックであり、「分析麻痺（Analysis Paralysis）」の兆候であったと判明したならば、既存決定を 覆し（Superseded）、より軽量な構造を採用案として更新する。

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

以上の広範な業界調査、MCDA理論、およびマルチエージェント集約手法の分析を踏まえ、bizlpが今後のSynthesis（RQ-053以降）において採用すべき標準テンプレートを以下に提示する。

このテンプレートは、MADR（Markdown ADR）の簡潔な構造をベースとしつつ 、arc42のQ42タグ（固定語彙の評価軸） と CBAアプローチ（優位性の定性的評価）をハイブリッドで組み込んだものである。

設計意図 (論理構造と閾値)

• 評価軸選定セクションの構造: ゼロから評価軸を創作する「独自合成」を防ぐため、評価軸はarc42の9つのタグ（#reliable, #flexible, #maintainable, #efficient, #usable, #operable, #suitable, #secure, #safe）という固定語彙から、案件ごとに3〜5個を選択する形とする 。
• 重み付けの記述方法: 複雑なマトリクス数値は用いず、Driverの「リスト記載順（[Must] /のラベル付き）」をそのまま重要度の順位付けとする。
• スコアリングの粒度: 1-5などの定量スコアは排除し、CBAアプローチによる「Advantage（有利な差異）の定性的な言語化」のみに絞る 。
• 採択判定の論理構造: 「最も優先度の高いDriverに対して、最もクリティカルなAdvantageを提示したオプション」を勝者とする（単純な利点の数合わせ＝加重和の否定）。

Bizlp Standard Synthesis Template (Markdown 構造例)

# ADR-0053: [決定のタイトルを端的に記載]

## Status
Proposed / Accepted / Deprecated / Superseded

## Context

## Decision Drivers (評価軸)
> ※ arc42の9品質タグから3〜5つを選択し、優先度順に記載。

1. **[Must] #maintainable**: AIエージェントがコードを解析・変更しやすい構造であること。
2. **#flexible**: 将来的なマルチテナント化に容易に対応できること。
3. **#efficient**: クラウドリソース（推論トークン消費等）のコスト効率が良いこと。

## Considered Options & Extracted Advantages (CBA分析)
> ※ 複数LLMの出力を突合し、各案の「他に対する明確な有利な点(Advantages)」のみを抽出。Pros/Consの二重カウントを禁止。

* **Option A**: [Claude提案モデル: マイクロサービス分割案]
  * *Advantage 1*: Option Bと比較して、単一機能の変更時の影響範囲(Blast radius)が狭い (#maintainableに寄与)
* **Option B**: [Gemini提案モデル: モジュラモノリス案]
  * *Advantage 1*: 既存のLangGraphステートとの結合度が低く、環境移行が容易 (#flexibleに寄与)
* **Option C**:
  * *Advantage 1*: キャッシュの積極利用によりトークン消費コストが最小 (#efficientに寄与)

## Decision Outcome (採択決定と集約論理)
* **Chosen Option**: **Option A**
* **Justification (選定根拠)**:
  最優先のDecision Driverである #maintainable に対して、Option Aの「影響範囲の極小化によるAIエージェントの解析負荷低減」というAdvantageが、Bizlpの現フェーズにおける開発速度維持において決定的に重要(K.O. criterion)であると判断したため。他案のAdvantageはこの恩恵を上回らない。

## Caveats / Consequences (限界条件と影響)
* Option Aを採用したことで、インフラレイヤーでのトークン消費効率(#efficient)についてはOption Cに劣るというトレードオフを受け入れる。将来的にAPIコストが許容閾値を超えた場合、本ADRは見直されるものとする。

bizlp 採用推奨案 (結論)

推奨フレームワーク: MADR (簡潔な記述), arc42 Q42 (固定評価軸タグ), CBA (優位性比較)の3点統合。

標準テンプレート構成: Context, Decision Drivers (評価軸), Considered Options (CBA分析), Decision Outcome, Caveats。

評価軸数と重み付け: Q42の9タグ（#maintainable等）から案件ごとに3〜5個を抽出し、リスト順で重要度を定義。複雑な数値演算は排除。

集約手法: 3LLMの提案をCBA思考で突合し、短所の議論を防ぎ「各案の確実な長所」と最優先軸をマッチングして採択案を決定。

遡及適用方針: RQ-050/051は新基準で「事後合理化」有無を検証し、最優先軸とAdvantageの論理が合致すれば維持、矛盾すれば改訂する。