最終更新: 2026/06/22 18:56
commonid: rq-087-decision-ui-meta-prompttype: promptstatus: draft
pageauthor: [email protected]audience: agent

RQ-087 メタプロンプト: Decision Pipeline の意思決定確定・記録 UI/IA のベストプラクティス調査

本メタプロンプトは scripts/deep_research_meta_prompt.md（RQ-063 Universal BP）の生成ルールに準拠して 最終調査プロンプト RQ-087_decision_ui_prompt.md を生成するための RQ 固有ブリーフ。

1. 背景

承認済み JTBD DPJ-001（重要な意思決定を盲点を潰して下し、監査可能な ADR として確定・記録する）の ゴール軸は「ADR が Accepted 確定し記録された」。しかし現行の Decision Pipeline chat UI（/chat）は 起案 → 審査 → 差し戻し対応までしか担っておらず、ゴール側の ①確定（Accept / sign-off）画面 ②記録の 一覧・想起（ADR カタログ）画面が存在しない。JTBD の完了アウトカムを UI が支えていない。

加えて 2026-06-02、Cross-Validation ゲートの過剰審査ループ（多重却下 ADR が収束不能）が実データで確証され、 人間が「過剰審査と判断して迂回 Accept する」運用が属人的に発生。その判断・迂回 Accept・監査注記を載せる UI 面 （Decide / Review）も未整備であることが顕在化した。本 RQ は親調査 RQ-086（意思決定支援ツール JTBD landscape） の next layer（landscape → UI/IA 設計）。

2. 調査の目的

  1. 意思決定の確定（Accept/sign-off）UI と記録の一覧・想起（ADR カタログ）UI のベストプラクティスを特定（主眼）
  2. ソロ作り手（n=1）・監査要件あり・認知負荷最小化（探す/迷うコストの排除）制約下での MVP 必須要素 vs 省略可の線引き
  3. 現 /chat（起案〜審査）からの 4 画面 IA（Compose→Review→Decide→Corpus）拡張パスの明確化

3. 調査論点 (Research Questions)

#調査論点期待アウトプット（measurable）
Q1（主眼）意思決定の「確定（Accept / sign-off / curation）」UI の業界パターン。誰が・何を見て確定し、監査証跡（誰が・いつ・何を根拠に）をどう残すかツール別（Log4brains/adr-tools/adr-kit/Backstage/MADR/decider）の確定フロー・状態遷移・監査記録の比較マトリクス + 一次資料 URL
Q2（主眼）「決定の一覧・カタログ・停滞検知」UI（ADR catalog / issue tracker）の表現。Status / フィルタ / 詰まった案件の可視化事例マトリクス（カラム・フィルタ・stuck 表現）+ Status×Mode×score×churn を一覧化する具体パターン
Q3（主眼）確定 + 一覧 UI のうち n=1 運用で MVP 必須 vs 省略可 の線引きmust / should / nice の 3 分類（各項目に根拠）
Q4Compose→Review→Decide→Corpus の状態モデル（draft/run/ADR）と画面遷移の事例状態 × 画面マッピング表 + 遷移図
Q5想起 / 整合チェック（新規起案時に関連・矛盾する過去決定を提示）の手法手法比較（全文検索 / タグ / decision graph / 埋め込み類似）+ UI 着地点（Compose 補助 or Corpus）
Q6AI レビュー結果・差し戻し理由・過剰審査（収束不能）を人間に促す UXAI レビュー提示 UI 事例（Graphite/CodeRabbit/Devin/Cursor）+ escalation / 迂回 Accept パターン

4. 調査対象（最低限カバー）

  • ADR / decision-record ツール: Log4brains / adr-tools / adr-kit / Backstage ADR plugin / MADR / Olaf Zimmermann Decision Capture / sventorben decider
  • 一覧・カタログ・承認 UI: Linear / Jira / Notion DB / GitHub Projects / Atlassian DACI
  • AI レビュー提示 UI: Graphite / CodeRabbit / Devin / Cursor
  • UX 原則: Nielsen Norman Group（dashboard / approval / status 表現）/ Diátaxis（カタログ閲覧の情報設計）

5. 期待するアウトプット形式

  1. エグゼクティブ・サマリ（200 字以内）: bizlp が採るべき Decide/Corpus UI の推奨
  2. 画面別ベストプラクティス・マトリクス（確定 / 一覧 / 想起 / 審査可視化）
  3. n=1 MVP の must / should / nice 分類（確定・一覧の最小集合）
  4. 4 画面 IA（Compose→Review→Decide→Corpus）の推奨遷移・状態モデル
  5. 監査証跡パターン（Accept / 迂回 Accept + 注記の記録方法）
  6. 未解決リスク / 追加調査が必要な領域

6. 制約・スコープ外

  • 実装技術（React / Cloudflare Workers / SPA フレームワーク）の詳細選定は対象外（別途・RQ-034 で Chat UI 技術は既出）
  • Cross-Validation ゲートのアルゴリズム的 fix は対象外（別 plan の systemic fix で扱う。本 RQ は「その結果を UI でどう見せるか」のみ）
  • フルチーム多段承認ワークフロー（DACI 複数 approver 等）は n=1 では参考程度に留める
  • 学術的厳密性より実装速度（1 人法人スケールで過剰なら省く）

7. 期待する調査深度（最終プロンプト生成は deep_research_meta_prompt 準拠）

  • 各ツール/パターンの一次資料（公式ドキュメント・GitHub・UX 論文/ガイド）を最低 1 件引用
  • 最終調査プロンプト生成時の必須遵守（scripts/deep_research_meta_prompt.md）: 1 テーマ厳守 / 設問は 3-5 個に蒸留 （Q1〜Q3 を主軸、Q4〜Q6 は従）/ 全体 1500-2500 字 / Context 300-500 words / ペルソナ指定・leading question 禁止 / scope 制限（Gemini タイムアウト対策）/ 各設問に measurable な回答基準
  • 3 モデル並列での得意領域:
    • Gemini Deep Research: 最新ツール事例・OSS リポ・グローバル UI 動向
    • Claude Research: bizlp DPJ-001 / 認知負荷軸との接続・反論検証（過剰設計の指摘）
    • GPT Deep Research: 画面ワイヤー記述・状態モデル・実装観点

8. 後続アクション (Post-Synthesis)

3 モデルの調査結果を RQ-087_decision_ui_synthesis.md にまとめ、decision-pipeline UI/IA ADR（Decide/Corpus 画面の 新設 + 4 画面 IA）の起案インプットとする。その ADR は decision-pipeline 自体の話題＝Cross-Validation 過剰審査リスクに 注意（迂回前提）。MVP exit 基準（mvp_exit_criteria.md）の入力にもなる。

9. 推奨実行モデル

モデル役割期待 token 量
Gemini 2.5 Pro Deep Research最新ツール/UI 事例・OSS リポ・一次資料20,000+
Claude Opus ResearchDPJ-001 / 認知負荷軸との整合・過剰設計の反論検証15,000+
GPT-5 Deep Research画面ワイヤー・状態モデル・実装観点10,000+

10. 関連 ADR / RQ

  • RQ-086（意思決定支援ツール JTBD landscape）: 親・本 RQ の前提 landscape
  • DPJ-001（make + record 統合 JTBD）: ゴール = Accepted 確定 + 記録
  • RQ-034（GAS Web App 上の Chat UI 設計）: UI 技術選定の隣接調査（本 RQ は技術でなく IA/UX）
  • ADR-0052（retroactive validation mode）/ ADR-0035（chat UI draft load）: 既存 UI 機能の前例
  • Cross-Validation 過剰審査 systemic fix（別 plan）: P3 設問（過剰審査の可視化）の UI 着地先