Synthesis 設計根拠 (Rationale)

読者: 設計判断の Why を知りたい執筆者 + 将来の経営層 使い方: 規約 (ADR-0050) を読んで「なぜそうするか」が気になった時に参照 更新: ADR-0050 v2 改訂時に追従

本ドキュメントは 設計根拠 (Explanation)。手順は synthesis_writing_guide.md、 誤り回避は synthesis_anti_patterns.md 参照。

1. なぜ案 C ハイブリッドを採用したか

詳細議論は RQ-052 Synthesis (RQ-052_mcda_for_adr_synthesis_synthesis.md) および議事メモ (RQ-052_mcda_for_adr_synthesis_stage3_preparation_memo.md) 参照。要点のみ:

• 案 A (純粋加重和): 速度・自動化親和性は最強だが、Suhr (1999) の 「judges の思考停止を招く」批判が該当、代表取締役氏の「意思決定の質を上げる」 方針と矛盾
• 案 B (純粋 CBA): 学術的厳密性最強だが、1 件 1-2 時間で年 50 件規模では 運用負荷大、LangGraph 自動化困難
• 案 C (ハイブリッド): 3 案の Advantage を統合し、bizlp 特性 (1 人法人 + AI Agent + 既存 ADR 資産 + 将来の経営層拡大) に最適化した informed extension

長期的には案 B 移行を視野 (組織成熟度ベース、ADR-0050 §4.8)。

2. arc42 Q42 9 タグ — bizlp 解釈表

arc42 Q42 は ISO 25010 (200+ の品質特性) を 9 個の形容詞タグに圧縮した 業界標準。公式: https://quality.arc42.org/articles/arc42-quality-model

2.1 #reliable (信頼性 — 拡張解釈: 事業継続性)

informed extension 根拠:

• 代表取締役氏の経営判断: 「財務の健全性がないと功利主義になってセキュリティ・ 安全性が疎かになる」
• dependability hierarchy という業界既存概念に類似
• bizlp 1 人法人 + AI Agent 構成という識別可能な特徴に紐付け

2.2 #flexible (柔軟性)

2.3 #maintainable (保守性)

2.4 #efficient (効率性 — 技術リソース)

2.5 #usable (使用性)

2.6 #operable (運用性)

2.7 #suitable (適合性)

2.8 #secure (セキュリティ)

2.9 #safe (安全性)

3. Subsume パターン (頻出 10-15 件)

Q42 9 タグ完全固定の中で、具体的な bizlp 関心事を より広い概念に 帰属させる ルール。

3.1 subsume の意味

「A subsumes B」= A は B を包含する (A が上位)。Q42 9 タグは抽象的なので、 具体的な関心事を 9 タグのどれかに帰属させる必要がある。

3.2 頻出 subsume パターン

3.3 subsume ルールの運用

• 軸選定時、具体的関心事を 9 タグに帰属させる
• 同じ関心事を複数案件で扱う場合、subsume 先を一貫させる
• 上記の表に未収載のパターンは、半年振り返りで追加する

3.4 subsume できない関心事の扱い

万一 9 タグのどれにも帰属させられない関心事を発見した場合:

1. まず本ファイルの 3.2 表を再確認
2. 該当する Q42 タグの定義を本ファイル §2 で再確認
3. それでも帰属困難なら、informed extension として #reliable のような 解釈拡張を検討 (新規 RQ で 3 モデル並列調査 → ADR-0050 v2)
4. ad-hoc に新規軸を作るのは禁止 (Q42 完全固定の規約)

4. 重要度ラベル係数の根拠

4.1 係数値 (v1 暫定)

Must (K.O.)  ×2.0
High         ×1.0
Medium       ×0.5

4.2 なぜこの値か

• Must vs High が ×2 倍差 で Must の優先度がはっきり
• Medium ×0.5 で「参考扱い」を明確化
• 案件間比較のため 正規化 (案件素点満点で割る) を組み合わせ

4.3 v1 暫定の意味

Synthesis 累計 20-30 件 or 半年経過時点で振り返り、ADR-0050 v2 で改訂検討:

• Must が強すぎて他軸の評価が無効化されていないか
• High と Medium の差 (×1.0 vs ×0.5) が判断に効いているか
• 正規化スコアが案件間で比較可能になっているか

4.4 検討した他の選択肢

ADR-0050 RQ-052 議事メモで以下を検討:

• 選択肢 A: Must ×2.0 / High ×1.5 / Medium ×1.0 — 差別化が緩やか
• 選択肢 B: Must ×3.0 / High ×2.0 / Medium ×1.0 — Must が圧倒的
• 選択肢 C (採用): Must ×2.0 / High ×1.0 / Medium ×0.5 — Medium が「参考扱い」
• 選択肢 D: Must ×2.0 / Other ×1.0 — 単純化 (2 段階)、濃淡が表現しづらい

5. 省略軸 justification の理由カテゴリ (7 種)

採用軸 (3-5 個) 以外の省略軸 (4-6 個) の justification で使う標準化 カテゴリ。形骸化 (「無関係」テンプレ化) を防ぐため、必ず 7 種から選択する。

5.1 理由カテゴリ一覧

5.2 Triage 別の補足粒度

Light:    省略軸 4-6 個を列挙、理由カテゴリのみ (1 行 / 軸)
Standard: 省略軸 4-6 個 × 理由カテゴリ + 一文補足 (1-2 行 / 軸)
Critical: 省略軸 4-6 個 × 理由カテゴリ + 詳細補足 (1 段落 / 軸)

5.3 形骸化を防ぐ仕組み

• 7 種から選択を強制 (「無関係」と書く代わりにカテゴリから選ぶ)
• 同じカテゴリが同案件で連続するのは違和感の兆候
• 半年振り返りで「省略すべきでなかった軸」を発見したら anti_patterns.md に追記

6. LLM Critic Agent の System Prompt 詳細 (段階 7 実装用)

6.1 基本テンプレート

You are an architecture decision Critic for the bizlp Synthesis pipeline.

Your role: Given a Must Decision Driver (= K.O. criterion) and 3 candidate
options with their Advantages, determine which options satisfy the K.O.
criterion.

Strict rules:
1. Do NOT propose new options. Only evaluate the given ones.
2. Do NOT consider non-Must drivers. Focus exclusively on the Must driver.
3. For each option, output PASS or FAIL with a 1-sentence justification.
4. If the option's Advantages do not explicitly address the Must driver,
   output FAIL.
5. Cite the exact Advantage text you are evaluating against.
6. Flag any Advantages that conflict with the Must driver (FAIL with reason).

Output format (strict JSON):
{
  "evaluations": [
    {"option": "Claude", "ko_judgment": "PASS",
     "cited_advantage": "...", "reason": "..."},
    {"option": "Gemini", "ko_judgment": "FAIL",
     "cited_advantage": "...", "reason": "..."},
    {"option": "GPT", "ko_judgment": "FAIL",
     "cited_advantage": "...", "reason": "..."}
  ]
}

Do not output anything outside the JSON.

6.2 業界事例 (一次資料)

• AutoGen (Wu et al. 2023, arXiv:2308.08155): GroupChatManager + Critic agent パターン。Critic system prompt verbatim:

  "Critic. Double check plan, claims, code from other agents and provide feedback. Check whether the plan includes adding verifiable info such as source URL."

• Multi-Agent Debate (Du et al. 2023, arXiv:2305.14325): Society of Minds、複数モデルが相互批評
• Self-Consistency (Wang et al. 2023, arXiv:2203.11171): 複数 reasoning path をサンプリングし多数決

6.3 失敗モード対策

6.4 Critical 案件での Self-Consistency

// 擬似コード
const rounds = 3;
const results = await Promise.all(
  Array(rounds).fill(0).map(() => criticAgent.evaluate(input))
);
// 1 票でも fail なら fail 扱い (厳しめ)
const consensusKO = consolidateByMajority(results, { strictness: "any-fail" });

7. なぜ規約と教育を分離するか (Diátaxis 原則)

7.1 代表取締役氏の指摘

「規約に教育情報含めると規約の遵守率が下がると思うので、規約は規約で 教育情報は別ファイルにしたい」

7.2 Diátaxis フレームワーク

bizlp が docs/_internal/05_how-to/ で採用している分類体系:

7.3 分離の効果

混ぜると「すぐ規約を確認したい人」も「Why を理解したい人」も両方損する。

8. なぜ informed extension (独自合成) が legitimate か

8.1 二種類の「独自合成」

8.2 informed extension の 3 つのテスト

1. Pre-registration: 業界調査を結論より先に行ったか
2. Explicit grounding: どの業界フレームワークを基礎に、どこを自社特色で 拡張したかを明示しているか
3. Justification: 自社特色での拡張は、自社の識別可能な特徴に 紐付いているか

3 つすべて満たせば legitimate、どれか欠ければ ad-hoc invention に堕ちる。

8.3 業界フレームワーク自体が informed extension の積み重ね

• ISO 25010 → arc42 Q42 9 タグへの圧縮 = informed extension
• Nygard ADR + Zimmermann SOAD → MADR への統合 = informed extension
• bizlp ADR-0020 (Triage) = Kruchten / Zimmermann / Bezos Type 1/2 の informed extension (代表取締役氏が既に実施済)

8.4 bizlp の主要な informed extension

1. #reliable の事業継続性拡張 (代表取締役氏指摘):

   • 基礎: arc42 公式定義 (fault tolerance / availability)
   • 拡張: 財務基盤・LLM トークンコスト・Time-to-market を含む
   • Justification: 1 人法人 + AI Agent 構成、代表取締役の経営判断

2. Triage × Scope 直交運用:

   • 基礎: ADR-0020 (Triage) + ADR-0049 (Scope) + GPT 提案
   • 拡張: 12 セルマトリクスで運用差別化
   • Justification: bizlp 既存資産の実運用化、AI Agent パイプライン分岐

3. 案 C ハイブリッド構成:

   • 基礎: MADR + arc42 Q42 + WSM (Fishburn 1967) + CBA (Suhr 1999)
   • 拡張: 加重和 + K.O. の 2 段構成、Triage 連動運用差分
   • Justification: 代表取締役氏「組織意思決定インフラ構築」志向、ADR-0019/0020/0049

9. 数値スコアと CBA の関係 (上位/下位層の役割分担)

9.1 なぜ 2 段構成か

数値層 (加重和) と論理層 (K.O.) を 直列に並べる ことで:

• 数値層: 機械集約可能、案件間比較可能、新規参加者の学習補助輪
• 論理層: 二重カウント排除、Must driver の論理性を強制、説明責任を担保

両方とも単独では弱点があるが、組み合わせると弱点を相互補完できる。

9.2 矛盾時の裁定 (Triage 連動)

加重和首位案 ≠ K.O. 通過案 の場合:

Light:     K.O. 判定なし → 加重和最高を採択
Standard:  K.O. 通過案中で加重和最高 (K.O. 通過ゼロは段階 1 戻し)
Critical:  K.O. 絶対、通過案中で加重和タイブレーク

Critical では「数値で勝った案を K.O. で落とす」ことが頻発する想定。 これは normal、論理層の本領発揮。

9.3 数値層の長期廃止可能性 (案 B 移行)

組織成熟度が育てば数値層を廃止し、純粋 CBA (案 B) へ移行可能。 ADR-0050 §4.8 のトリガー条件を参照。

10. 参照

bizlp 内部

• ADR-0050 (Synthesis 標準テンプレート) — 規約
• synthesis_writing_guide.md — 手順
• synthesis_anti_patterns.md — 誤り集
• docs/_meta/templates/synthesis.md — Synthesis ひな形

RQ-052 成果物

• RQ-052_mcda_for_adr_synthesis_synthesis.md — Synthesis 草案
• RQ-052_mcda_for_adr_synthesis_stage3_preparation_memo.md — 議事メモ
• RQ-052_mcda_for_adr_synthesis_result_{claude,gemini,gpt}.md — 3 モデル結果

業界フレームワーク (一次資料)

• MADR 4.0.0: https://adr.github.io/madr/
• arc42 Q42: https://quality.arc42.org/articles/arc42-quality-model / https://docs.arc42.org/section-1/
• WSM: Fishburn (1967) "Additive Utilities with Incomplete Product Set", Operations Research
• CBA: Suhr, J. (1999) The Choosing By Advantages Decisionmaking System, HRD Press
• ATAM/CBAM: CMU/SEI, https://www.sei.cmu.edu/library/the-architecture-tradeoff-analysis-method/
• AHP: Saaty, T.L. (1980) The Analytic Hierarchy Process, McGraw-Hill
• AutoGen Critic: Wu et al. (2023) arXiv:2308.08155
• Multi-Agent Debate: Du et al. (2023) arXiv:2305.14325
• Self-Consistency: Wang et al. (2023) arXiv:2203.11171
• Diátaxis Framework: https://diataxis.fr/