最終更新: 2026/06/22 18:56
commonid: rq-087-decision-ui-synthesistype: research-synthesisstatus: active
pageauthor: [email protected]audience: agent

RQ-087 Synthesis: 意思決定確定・記録 UI/IA のベストプラクティス（3 モデル突合）

調査: 2026-06-02 / OpenAI o3-deep-research・Gemini deep-research・Claude research の 3 モデル並列（合計 ~$5.39）。 入力: tmp/deep-research/rq-087/{openai,gemini,claude}_20260602T012509.md。確度順: Claude（生 URL・wireframe・閾値）> OpenAI（画面遷移ナラティブ）> Gemini（理論・AI 統合視点だが生 URL 不明＝redirect）。

エグゼクティブ・サマリ（bizlp 推奨）

3 モデルは「専用 Accept 画面を持つ既製 ADR ツールは存在せず、status フィールド編集 + git/PR merge が事実上の sign-off」「catalog = 単一 corpus の保存済みフィルタービュー」「AI は advisory・人間が override-with-rationale で 最終確定」で一致。bizlp の DPJ-001（確定 + 記録）を完遂する最小 UI は次の 4 画面に集約する:

  • Compose（既存 /chat 拡張）+ Review（審査可視化）+ Decide ★新（Accept/迂回 modal）+ Corpus ★新（ADR 一覧）。
  • 確定は Decide 画面の Accept modal（status Proposed→Accepted + who/when/basis 自動 capture + override 時 rationale 必須）。
  • 記録は MADR YAML + Confirmation セクション（既存 ADR-0023/0024 と整合）を真実の源とし、Accept 後の本文編集を tool 側でブロック（MADR 単体は immutability 非保証＝監査要件で必須の補強）。
  • 一覧は status group-by board + 保存ビュー 4 本（Proposed/Accepted/Stuck/All）+ time-in-status による停滞検知。 これは本セッションで確証した Cross-Val 過剰審査で Proposed に滞留する ADR を 1 フィルタで可視化する着地点でもある。

Q1-Q5 突合（要点）

設問3 モデル合意（design 確度高）bizlp への含意
Q1 確定 UI専用 Accept 画面は無い / status field が sign-off の実体 / 監査は git/PR history / override に理由必須 / supersede は双方向リンク付き status 遷移Decide modal で status 遷移 + who/when/basis 自動記録。MADR 4.0 Confirmation セクションを監査スロットに
Q2 一覧 UIcatalog=保存済みフィルタービュー / group-by-status / saved view で認知コスト排除 / 停滞は time-in-status / 矛盾の自動検出は既製品に無く手動 linkCorpus に保存ビュー 4 本 + Linear time-in-status 相当で Proposed 滞留検知。矛盾は当面 supersede 手動リンク
Q3 MVPMust=one-click Accept+自動 timestamp/user / 監査証跡 / catalog list / filter・search / 可視 status。multi-user 不要下記「MVP」表に集約。tag filter は corpus が増えるまで後回し
Q4 IAdraft→review→decide(単一 transition)→record/catalog の 4 段。Accept を独立画面/modal に分離Compose→Review→Decide→Corpus に直接対応。Accept は Review 画面ヘッダと Corpus 行の両方から起動
Q5 AI 審査の可視化AI は hard gate でなく advisory / override は first-class gesture / 理由記録必須 / 非収束は人間介入で break / AI feedback は既存 channel に統合severity tier(red/yellow/gray) で提示。非収束(過剰審査)は Decide の迂回 Accept へ誘導（Cross-Val 過剰審査 systemic fix の Part2 escalate の UI 着地）

MCDA: 対立論点の裁定（bizlp の n=1・監査・認知負荷最小 制約下）

#対立採択（bizlp）根拠
C1真実の源 = git/PR か in-app かハイブリッド: Decide(in-app)で status/監査を権威的に記録 → docs/adr/ に publish して immutable な公式記録にbizlp は KV/Pipeline + docs/adr/ を既保有。Accept は UI、確定物は git の両取り
C2矛盾検出の深さ当面 supersede 手動リンク + 全文検索。semantic-similarity 提案は Should（近接時期）Claude=「~120 件で必須」。bizlp は既に ADR ~104 件で閾値接近 → 全 RAG/CASCADE は過剰だが類似提案は near-term 価値
C3override UI 粒度free-text rationale 必須 + 任意のカテゴリタグ（incorrect assumption / outdated / intentional / hallucinated）Gemini の 4 分類は過剰審査の継続改善ループ（なぜ人間が override したか）に直結＝Cross-Val telemetry と接続
C4MADR の immutabilityAccept 後の本文編集を tool 側でブロック（必須）Claude 指摘=MADR 仕様は immutability 非強制。bizlp 監査要件では落とせない
C5format = MADR vs Y-StatementMADR + Confirmation を継続（ADR-0023/0024 と整合）Y-Statement は body template として内包可。新規約不要
C6stacked PR / 3-panel cohort review不採用solo の review 規模に過大（Gemini 単独推奨・他 2 モデル非言及）

過剰設計の線引き（n=1 で避ける / 採るべき）

  • 避ける: multi-approver・approval-path policy（3 モデル合意で n=1 不要）/ RAG+CASCADE 矛盾検出 pipeline（現状 overkill）/ stacked PR + 3-panel review / tag・category filter（corpus が ~100 件超で再検討）。
  • 採る（認知負荷最小に直結）: 保存ビュー 4 本 / Cmd-K command palette / Progressive Disclosure（AI の reasoning は toggle 裏）/ group-by-status で未決一望 / status badge を「これは done か?」の即答装置に。齋藤の意思決定軸（探す・迷うコストの排除）に 最も整合するのは「sidebar 4 ビュー + time-in-status 1 フィルタ」。

推奨 MVP（must / should / nice）

  • Must: ①Decide の Accept modal（status 遷移 + who/when/basis 自動 + override checkbox + rationale 必須）②MADR YAML + Confirmation ③Corpus の 1 テーブル + 保存ビュー 4 本（Proposed/Accepted/Stuck/All）④全文/facet 検索 ⑤可視 status badge ⑥Accept 後 body 編集ブロック（監査）。
  • Should: ①override の severity tier 表示 + Why tooltip ②group-by-status board ③supersede 双方向リンク ④Cmd-K palette ⑤AI score snapshot を Accept 時に監査記録へ ⑥semantic-similarity の関連/矛盾提案。
  • Nice: ①changelog/RSS ②静的サイト公開 ③category タグ運用（≥100 件で）。out-of-scope: multi-approver。

各モデルの固有貢献（一次採用の所在）

  • Claude（実装・一次資料を一次採用）: MADR 4.0 Confirmation スロット / Linear time-in-status / Triage Intelligence(semantic 類似) / Accept modal wireframe / MS Playbook PR-merge convention / 過剰設計の閾値（tag≥100・multi-approver out-of-scope）/ MADR immutability gap。
  • OpenAI（画面遷移ナラティブ）: 6 状態 × 画面マッピングと ADR-012 の walkthrough / GitHub code-scanning「Dismiss with reason」の override 転用。
  • Gemini（AI 統合・理論）: ADR を AI の active constraint として AGENTS.md/.cursorrules に注入する視点 / 矛盾検出の技術分類 (lexical / embedding / CASCADE 8-type) / automation bias の理論的裏付け / override の 4 カテゴリ分類。 ※ Gemini の引用は全て Vertex AI Search の redirect URL で生 URL は要別途取得（下記 References は Claude/OpenAI の生 URL を採用）。

Open Questions（UI/IA ADR で確定）

  1. Decide(in-app) と docs/adr/ publish の同期方式（webhook / 手動 push / Pipeline 連携）— C1 の実装詳細。
  2. semantic-similarity 関連提案の着手トリガ（corpus 件数閾値・埋め込み手段）— C2。
  3. Corpus の score×churn×Implementation Status カラムの具体表示（既存 D1 telemetry を読むか）。
  4. 過剰審査(goalpost)の Review 画面表示と Decide 迂回 Accept の連携（本セッションの Cross-Val fix Part2 と統合）。

次工程

本 Synthesis を入力に decision-pipeline UI/IA ADR（Decide/Corpus 画面の新設 + 4 画面 IA + MADR Confirmation + 監査ガード）を 起案する。MVP exit 基準（mvp_exit_criteria.md）の入力にもなる。※その ADR は decision-pipeline 自体の話題＝Cross-Validation 過剰審査リスクに注意（迂回前提・Cross-Val 過剰審査 systemic fix 参照）。

References（主要一次資料・Claude/OpenAI の生 URL）