最終更新: 2026/06/22 18:56
commonid: synthesis-anti-patternstype: how-tostatus: active
pageaudience: agent

Synthesis よくある誤り集 (Anti-Patterns)

読者: Synthesis 執筆者 (代表取締役氏 + 将来の経営層 + AI Agent) 使い方: Synthesis 提出前のセルフ点検、または定期的に読み返す 更新: 新たな誤り事例は振り返り (3/6/12 ヶ月) で集約してここに追加

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

1. 評価軸選定のアンチパターン

1.1 Post-hoc rationalization (事後合理化) ⚠️ 最重要

何が起きるか: 段階 2 で 3 モデル結果を読んでから「この案を採用したい」と内心思い、 そのために有利な評価軸を後付けで段階 1 の Driver に追加する。

なぜ起きるか:

  • 認知バイアス (motivated reasoning)
  • 「自分は中立だから大丈夫」と自覚なくやれる
  • 「より良い軸を見つけた」という自己説明で正当化

自覚するためのチェック:

  • 段階 1 PR の確定後に軸を追加・変更していないか
  • 「実は X 軸も重要」と段階 2 結果を読んでから気づいた場合、 それは confirmation bias の兆候
  • 同じ軸セットで「逆の結論」が出せるか? 出せないなら post-hoc

修正方法:

  • 段階 1 PR で軸を確定したら 絶対に変更しない
  • 段階 2 後に軸を変えたい場合は、別 PR で Driver 改訂を起案 (履歴を残す、隠さない)
  • それでも変えたい場合は段階 1 に完全戻し、再起案

bizlp 事例: PR #814 (RQ-051 Synthesis, close) で「MVP 即時実装可能性」「将来の拡張性」 「AI Agent 解釈性」「既存 ADR 整合性」を評価軸としたが、業界フレームワーク 未照合で、代表取締役氏の「ソースは?」に答えられず close。RQ-052 で根本対応。

1.2 Confirmation bias (確証バイアス)

何が起きるか: 採用案を支持する証拠だけを軸として採用、反証可能な軸を排除する。

なぜ起きるか:

  • Primacy effects (初頭効果)
  • 「自分の判断が正しい」と感じたい
  • 採点時に都合のいい解釈を選ぶ

自覚するためのチェック:

  • §7.2 Negative が書けるか (書けない案 = confirmation bias の可能性)
  • §9.3 で「採点を逆方向にしても結論が変わらない」確認したか
  • 他の評価者 (AI Agent) に Critic 役を頼んで反論を出せるか

修正方法:

  • Devil's advocate 役を意識的に設定 (AutoGen Critic / Multi-Agent Debate)
  • すべての案で「弱み」を最低 2-3 個挙げる強制ルール
  • 採点で「全案 5 点」「全案 1 点」のような分散ゼロを避ける

1.3 Analysis paralysis (分析麻痺)

何が起きるか: 軸を増やしすぎて、評価マトリクスが肥大化し、結論が出せなくなる。

なぜ起きるか:

  • 「全部重要だから全部評価したい」
  • ISO 25010 のような網羅的 spec を全部取り込もうとする
  • 完璧主義

自覚するためのチェック:

  • 軸数が 5 個を超えていないか (ADR-0050 規約違反)
  • Miller 7±2 の認知負荷上限を超えていないか
  • 採点に 1 件 2 時間以上かかっていないか (Standard 想定の 2 倍)

修正方法:

  • ADR-0050 §4.2 の「軸数 5 個推奨」を厳守
  • 関係軸を 5-7 個に絞った後、トレードオフ軸を残す Step を経る
  • 「迷ったら subsume」(synthesis_rationale.md#subsume-patterns)

1.4 Spurious quantification (見せかけ定量化)

何が起きるか: 定性的な比較を無理に 1-5 数値に押し込み、3 と 4 の差の意味が 曖昧なまま結論を出す。

なぜ起きるか:

  • 数値が客観的に見える錯覚
  • LangGraph 自動化のために定量化したい誘惑
  • Suhr (1999) の CBA 批判「judges の思考停止を招く」状態

自覚するためのチェック:

  • 採点根拠を備考列で言語化できているか
  • 「Coherence Claude=5, Gemini=3 の差」を 1 文で説明できるか
  • 同じ案件を 1 週間後に再採点して点数が一致するか (再現性)

修正方法:

  • 採点根拠を 必ず備考列に記載 (ADR-0050 規約)
  • 数値で迷ったら CBA の Advantage 抽出に立ち返る
  • Critical 案件では K.O. 判定が支配的、加重和はタイブレーク用

2. [Must] / K.O. のアンチパターン

2.1 K.O. インフレ ([Must] 全部にする)

何が起きるか: 5 軸全部を [Must] にしてしまい、K.O. 判定で全候補が落ちる (または全候補が通過) → K.O. 機能不全。

なぜ起きるか:

  • 「全部譲れない」と代表取締役氏が感じる (経営判断の幅広さ)
  • [Must] の意味を誤解 ([Must] = 重要 ではなく、満たさないと除外)

自覚するためのチェック:

  • [Must] が軸数の半分以下か (5 軸→ 2-3 個、4 軸→2 個、3 軸→1-2 個)
  • K.O. 通過案がゼロまたは全部になっていないか
  • 「絶対譲れない」と「重要」を区別できているか

修正方法:

  • [Must] を絞り込む際は「これがなくても案件は成立するか?」で判定
    • Yes → [Must] ではなく High に降格
    • No → [Must] として残す
  • 段階 1 PR で [Must] 上限を pre-register、変更には別 PR

2.2 K.O. 通過ゼロ時の緊急採択

何が起きるか: 全案が Must を満たさない時、「とりあえず一番マシ」を採択して ADR 起案を進める。

なぜ起きるか:

  • 締切プレッシャー
  • 「判断不能」を認めたくない
  • ループに戻る作業を避けたい

自覚するためのチェック:

  • §6 で「REQUIRES_REPROPOSAL」を明示せず採択していないか
  • [Must] を緩めて (Must → High に変更) 通過させていないか
  • Critical 案件で緊急採択していないか (絶対禁止)

修正方法:

  • Standard: ループ 3 回までトライ、3 回で Critical 自動格上げ
  • Critical: 必ず段階 1 戻し、追加調査を実施、緊急採択禁止
  • 「判断不能」を正直に認めることが代表取締役の役割

2.3 K.O. 判定基準の事後緩和

何が起きるか: 通過案がゼロ時、「実は #maintainable は部分通過でも OK」と判定基準を 事後に緩める。

なぜ起きるか:

  • 採択したい案を通すための後付け正当化
  • Post-hoc rationalization の典型

自覚するためのチェック:

  • §4.x の K.O. 判定基準が段階 1 PR と一致しているか (v2 順序、ADR-0050 §4.1 v2 改訂注)
  • △ (部分通過) の運用ルールを事前に決めているか
  • 「部分通過 → 通過扱い」が結論を変えているか

修正方法:

  • △ (部分通過) の扱いを段階 1 PR で pre-register
  • 事後緩和を発見したら、それは別 PR で Driver 改訂すべき事案

3. 案の評価のアンチパターン

3.1 二重カウント (Pros/Cons)

何が起きるか: 「案 A はコストが高い」を Cost 軸でマイナス計上し、同時に 「案 B はコストが安い」を別案でプラス計上 → 同じ事実を二回数えている。

なぜ起きるか:

  • Pros/Cons リストの論理的欠陥
  • CBA (Suhr 1999) が指摘した古典的問題

自覚するためのチェック:

  • 各案の §3.x で「強み」のみ列挙、「弱み」は他案の長所の裏返しに なっていないか
  • Evaluation Matrix の備考列で「他案より優れている」のような 相対記述ばかりになっていないか

修正方法:

  • CBA 形式に従う: 各案は 自分の Advantage (絶対的強み) のみ列挙
  • 短所 (Disadvantage) は記載禁止 (他案の Advantage 抽出で十分)
  • §3.x の「弱み」は「この案単独の限界」に絞る

3.2 全案高得点 (差別化不能)

何が起きるか: すべての軸ですべての案が 4-5 点で、加重和スコアの差が出ない。

なぜ起きるか:

  • 軸選定で対立軸を残せていない (Step 2 の軸絞り込み不足)
  • 採点が甘い (3 点を付けにくい)

自覚するためのチェック:

  • 採点の分散がゼロまたは極小になっていないか
  • 「これは差別化軸」と言える軸が 1 つでもあるか
  • 加重和の正規化値が全案 0.7+ に集中していないか

修正方法:

  • 軸選定で意図的に対立軸を残す (一方が高得点なら他方が低得点になる軸)
  • 採点で 1-2 点を恐れず付ける (差別化のため)
  • 全案 4-5 点なら段階 1 に戻して軸再選定を検討

3.3 採点根拠の不在 (備考列が空)

何が起きるか: Evaluation Matrix に数値だけあり、なぜその点数なのか記述がない。

なぜ起きるか:

  • 「点数だけで自明」と感じる
  • 備考を書く工数を惜しむ

自覚するためのチェック:

  • §5 Evaluation Matrix の表の備考列がすべて埋まっているか (v2 順序、ADR-0050 §4.1 v2 改訂注)
  • 6 ヶ月後にこの Synthesis を読んで採点理由が再現できるか
  • 別の評価者が同じ採点に到達できるか

修正方法:

  • ADR-0050 規約に従い、採点根拠は必須
  • 短くて良いので 1-2 文の理由を書く
  • 「他案より X が優れている」より「この案は X が優れている」と絶対記述

4. 省略軸 justification のアンチパターン

4.1 形骸化 ("無関係" テンプレ化)

何が起きるか: 省略軸 justification がすべて「該当案件には無関係」のようなテンプレ 記述になり、真剣な省略判断ができていない。

なぜ起きるか:

  • 4-6 軸分の justification の作業量負担
  • 「無関係」が最も書きやすい逃げ道

自覚するためのチェック:

  • 標準化理由カテゴリ 7 種から選択しているか (synthesis_rationale.md 参照)
  • 同じ案件で複数の省略軸に「無関係」が連続していないか
  • Critical 案件で 1 段落の補足が形骸化していないか

修正方法:

  • 7 種から選択を強制 (1. ドメイン外 / 2. 既存基盤 / 3. 固定要件 /
    1. 破壊操作なし / 5. subsume / 6. 影響軽微 / 7. 別案件で扱う)
  • 6 ヶ月振り返りで「実は省略すべきでなかった軸」を発見したらここに追記

4.2 「省略しやすい軸」を意識的に選ぶ (逆 confirmation bias)

何が起きるか: 軸選定時に「説明しにくいから省略」と判断し、本来重要な軸を採用軸から外す。

なぜ起きるか:

  • justification を書く工数を避けたい
  • 不確実性の高い軸を扱いたくない

自覚するためのチェック:

  • 省略軸が「説明しにくいから」という理由で選ばれていないか
  • 案件特性で省略軸を選んでいるか、自分の都合で選んでいないか
  • 採用軸 5 個が「最も評価しやすい軸」になっていないか

修正方法:

  • 軸選定の Step 1 (関連軸の識別) を厳格に: トレードオフの可能性で判断
  • 「省略しやすい軸を選ぶ」誘惑が出たら、それは avoidance bias の兆候

5. Critic Agent のアンチパターン (段階 7 実装後)

5.1 Critic agent の盲信

何が起きるか: Critic agent の K.O. 判定結果を読まずに採用する。

なぜ起きるか:

  • 「自動化されたから正しい」という錯覚
  • 確認作業を省略したい

自覚するためのチェック:

  • Critic 結果の cited_advantage を確認したか
  • reason が Must driver と直接関係しているか
  • 同じ案件 2 回実行で結果が同じか (Self-Consistency)

修正方法:

  • ADR-0050 規約: Critic 結果は必ず代表取締役氏が批判的に確認
  • 異議があれば手動上書き + 理由ログ
  • Critical では 3 ラウンド (Self-Consistency) で多数決

5.2 Critic が yes-man になる

何が起きるか: Critic agent が Proposer の出力を「だいたい正しい」と判定しまくる。

なぜ起きるか:

  • 同じモデルファミリ (Claude vs Claude) で confirmation bias
  • system prompt の指示が弱い

自覚するためのチェック:

  • Critic が PASS を連発していないか
  • Critic と Proposer が異なるモデルファミリか
  • system prompt で negative role を強制しているか

修正方法:

  • Critic を別モデル (Gemini や GPT) に変更
  • system prompt: 「Critic. Double check ... provide feedback.」
  • Multi-Agent Debate (Du et al. 2023) で複数モデル対立構図に

5.3 Critic が過剰批判

何が起きるか: Critic agent が些末な点まで批判して全 fail を出し、K.O. 通過ゼロ状態が 連発する。

なぜ起きるか:

  • 「批評しろ」と指示すると過剰反応する LLM の特性
  • temperature が高すぎる

自覚するためのチェック:

  • K.O. 通過ゼロが頻発していないか (Standard で月 3 回超は異常)
  • Critic の reason が Must driver と直接関係しているか
  • 過剰批判が同じパターン (例: 常に「証拠不十分」) を示していないか

修正方法:

  • system prompt で「Must driver に直接関わる点のみ批評」と明示
  • temperature を 0.0-0.3 に下げる
  • 過剰批判が続く場合は temperature 調整 + system prompt 修正

6. プロセス全体のアンチパターン

6.1 段階順序の逆転

何が起きるか: 段階 2 並列調査結果を読んでから段階 1 の Driver を作る。

なぜ起きるか:

  • 結果を見ないと軸を決められないと感じる
  • pre-registration の意義を理解していない

自覚するためのチェック:

  • 段階 1 PR の確定日時 < 段階 2 結果の取得日時 か
  • PR 履歴で段階 1 → 段階 2 → 段階 3 の順序が明確か
  • 段階 2 後に Driver を変更していないか

修正方法:

  • パイプライン (ADR-0019) の段階順序を厳守
  • 段階 1 PR が merged してから段階 2 を実行
  • 段階順序の逆転を発見したら全部やり直し

6.2 「3 モデル並列レビューを評価軸にする」誤解

何が起きるか: G-Eval 4 軸 (Coherence/Consistency/Fluency/Relevance) や「3 モデル合意度」を Q42 タグに加えて評価軸として採用する。

なぜ起きるか:

  • Multi-LLM 評価のフレームワークと Synthesis 評価軸を混同
  • 横断プロセスと案件評価軸の区別がついていない

自覚するためのチェック:

  • §2 Decision Drivers が Q42 9 タグだけになっているか
  • G-Eval / AWS Pillars / DACI 等の業界 FW を直接軸にしていないか

修正方法:

  • 3 モデル並列調査は 横断プロセス (writing_guide §3) として規定済
  • 評価軸は Q42 9 タグ完全固定 (ADR-0050 §4.2)
  • 補助 FW は subsume または rationale.md の参考扱い

6.3 振り返りの省略

何が起きるか: Synthesis を完成させた後、3 ヶ月/6 ヶ月/1 年の振り返りを実施しない。

なぜ起きるか:

  • 振り返りの工数を惜しむ
  • 「次の案件で忙しい」
  • 過去案件への関心低下

自覚するためのチェック:

  • Critical 案件の Synthesis ファイルに「§11 振り返り」セクションが 追記されているか
  • 振り返り時期 (3/6/12 ヶ月) のリマインダーを設定しているか

修正方法:

  • Critical 案件は振り返り必須 (ADR-0050 §4.3)
  • 振り返り時期をカレンダー登録
  • 振り返り結果を本ファイル (anti_patterns.md) に集約 → 教材化

7. 新規アンチパターンの追加方法

運用中に新たな誤りパターンを発見した場合:

  1. 発見: 振り返り (3/6/12 ヶ月) または日常運用で誤り事例を特定
  2. 記録: 元の Synthesis ファイルの「§11 振り返り」に記述
  3. 集約: 6 ヶ月ごとに本ファイル (anti_patterns.md) に新セクション追加
  4. 教材化: 新規参加者向け教材として ADR-0050 補遺で参照

追加時のテンプレート:

### X.Y <アンチパターン名>

**何が起きるか**: <症状>
**なぜ起きるか**: <原因>
**自覚するためのチェック**: <チェックリスト>
**修正方法**: <対処法>
**bizlp 事例** (該当する場合): <PR 番号 or RQ 番号>

8. 参照

  • ADR-0050 (Synthesis 標準テンプレート) — 規約
  • synthesis_writing_guide.md — 手順
  • synthesis_rationale.md — 設計根拠
  • Suhr (1999) The Choosing By Advantages Decisionmaking System — Pros/Cons 二重カウント問題の古典的指摘
  • Du et al. (2023) arXiv:2305.14325 — Multi-Agent Debate
  • Wang et al. (2023) arXiv:2203.11171 — Self-Consistency