意思決定支援ツールの JTBD landscape — 既存ツールは「どんな job」に仕えているか (3モデル Deep Research)

調査日: 2026-06-01 調査者: [email protected] 調査モデル: OpenAI o3-deep-research / Gemini deep-research-preview / Claude Opus 4.7 (Managed Agents) — 同一プロンプト 個別結果: OpenAI / Gemini / Claude コスト: OpenAI $2.28 / Gemini $1.12 / Claude $1.65（合計 ~$5.1）。OpenAI は無指定で TPM 200k 超過により3回失敗 → OPENAI_MAX_TOOL_CALLS=20 で再実行成功（→ 既定 25 化 PR #1271）。

0. 調査の動機

Decision Pipeline (ADR 起案を半自動化する LangGraph TS on Cloudflare Workers) は本番稼働しているが、 「意思決定」という job を誰が何のために雇うか＝JTBD が未定義。JTBD SSoT (_jtbd_list.md, ADR-0043 標準) は JTBD-001〜012 すべて会計ドメインのエンドユーザー job で、Decision Pipeline 自身が仕える job は空白。この空白が「MVP exit 基準が決まらない／現ドラフトの必須・後回しが切れない」根因。本 RQ は JTBD 定義の前段として、既存ツールが「どんな job」に仕えているかの landscape を 3 セグメント（ソロ作り手 / チーム・SaaS / 汎用ナレッジワーカー）で撮る。 先行 RQ-058（JTBD 完了の定量評価）/ RQ-062（意思決定品質データ戦略）/ RQ-064（意思決定バイアス）は前提とし再調査しない。

1. サマリー（3モデル統合結論）

3モデルが強く一致した中核命題:

ADR ツールは decision memory（記録・ガバナンス）を売っており decision making ではない。 adr-tools / Log4brains / MADR は「なぜその技術選択をしたか」を保存し将来の盲目的な反転・再議論を防ぐのが job。 どの選択肢が最適かの評価は明示的にスコープ外で、人間が判断する前提（3モデル一致）。
意思決定の job は 3 つの軸に分かれ、単一ツールが全部を覆っていない（Claude の整理）:
- memory（記録・traceability）= ADR ツール
- alignment（合意形成・可視性）= Loomio / Confluence / DACI / Log4brains
- quality（分析・スケール）= Decision Intelligence Platform（DIP, エンタープライズ）
セグメントで job が質的に変わる（OpenAI の matrix が最も明快）:
- ソロ作り手 = 速度・低摩擦。「決めた理由を素早く記録し開発を止めない」。memory 中心。
- チーム/SaaS = 合意・traceability・onboarding・accountability。rigor 高め。
- 汎用ナレッジワーカー = 後悔しない・説明できる選択。MCDA（1000minds 等）で構造化。
ソロ作り手の "意思決定そのものを下す" job が最も未充足。 ADR ツールは「もう決めた」前提で記録するだけで、選択肢の評価を導く専用ツールは事実上無い。ソロは汎用 LLM を ad-hoc な "virtual co-founder / sparring partner" として使っている（Gemini）。 → 「making + recording を統合した、ソロから始めてチームへスケールする意思決定ログ」が市場の空白（OpenAI が明示し「これはまさに我々のパイプラインが進む軌道かもしれない」と指摘）。
AI-native シフトが job 境界を上下に広げている: ADR ツールは下流の enforcement（ADR Kit が ADR を lint ルール化し drift 防止）へ、 copilot は上流の option 生成/ドラフト（ChatPRD・architecture copilot）へ。ただし最終判断は人間に残る（ADR Kit「agents make smart decisions, tools handle reliable automation」）。

2. 設問別の突合

Q1 ツール landscape と job framing

カテゴリ	代表ツール	中核 job	明示的スコープ外
ADR / decision-record	adr-tools, Log4brains, MADR, ADR Kit	技術選択の rationale を保存し将来の盲目的反転・再議論を防ぐ	選択肢の評価・最適解の算出。人間が決める
Decision Intelligence / 支援	Gartner DIP, Peak, Cloverpop, Teradata, 1000minds, Wizer	データ/分析/AI で意思決定の質・効率を上げる（スケール）	goal 設定・最終承認・accountability は人間
AI copilot	ChatPRD, architecture copilot, ADR Kit (AI), 汎用 LLM	ドラフト生成・option 提示・速度（augmentation）	文脈・nuance の最終判断。human oversight 必須

Q2 セグメント別の job 差

ソロ: 速度 > rigor、コラボ機能不要、audit は「半年後に自分が理由を思い出せる」程度。job=個人の記憶と継続。
チーム/SaaS: コラボ・レビュー/承認・version control・onboarding・accountability。rigor 高、alternatives/consequences を要求。
汎用ナレッジワーカー: 構造化思考（MCDA・pros/cons・意思決定キャンバス）、bias 低減、説明可能性。標準手法が無く道具が断片的。

Q3 outcome / "decision done" シグナル

traceability（rationale 記録）/ onboarding 速度短縮 / 合意・sign-off / decision latency 短縮 / regret 最小化（"decisions you can trust"）/ ビジネス KPI（DIP）。 具体メトリクス例（Claude）: Cloverpop 28日→7日、Aera 40%作業削減・70%採用、Catio アーキ80%改善、ChatPRD ドラフト80%短縮、Copilot 55%生産性。

Q4 gap / 未充足

ソロの making 誘導（記録でなく「どう決めるか」）が未充足 → AI-native decision guide の機会。
汎用意思決定の統一解が無い（spreadsheet/slide に逃げる）。
ソロ→チームのスケール経路（軽量に始めて多人数 KB へ滑らかに育つ意思決定ログ）が未提供 ← 我々の射程と最も合致。
decision→outcome のフィードバックループ（決めた後の結果を学習に戻す）がほぼ未対応。

3. セグメント別 job-statement 候補（landscape 由来・descriptive）

既存ツールが framing している job の記述であり、我々の確定 JTBD ではない（次タスクで ADR-0043 の 3軸テストに通す）。

ソロ作り手: 「一人で開発中に重要な技術判断をしたとき、理由を軽量に素早く記録し、開発フローを止めずに後から参照・自信を持って次の判断ができるようにしたい」
チーム/SaaS: 「チームが重要な判断をするとき、共有・構造化されたプロセスで評価・記録し、全員が rationale を理解し、再議論や矛盾する選択を避け、新メンバーが素早くキャッチアップできるようにしたい」
汎用ナレッジワーカー: 「複雑・高 stakes な判断をするとき、一貫した基準で選択肢を比較する仕組みで思考を構造化し、後悔せず他者に説明できる選択をしたい」

4. 市場での job 定義の明確さ

最も明確: 開発者向け ADR（「アーキ判断を将来参照のため記録する」= Nygard/Fowler 以来の確立した実務。境界も既知）。
最も曖昧: 汎用ナレッジワーカーの意思決定（支配的フレーム/成果物が無く、ツールが断片的。"decision tool" で検索されない）。
中間（形成途上）: チーム/エンタープライズ（"Decision Intelligence" で結晶化を試みるが概念が広く vendor ごとに位置づけが割れる）。

5. 我々への含意（JTBD 定義への接続）

我々の幹は「ソロ作り手の making+recording 統合」= 市場の空白かつ最も射程に合う。 ADR ツール（memory のみ）でも DIP（エンタープライズ）でもない。 Decision Pipeline は triage→盲点検出→本文生成→採点→検証→…→採番で「下す」を支援しつつ ADR に「記録」する = making と recording を1動作で繋ぐ点が差別化。
**将来 SaaS は「ソロ→チームへ滑らかにスケールする意思決定ログ」**として、未充足のスケール経路を埋める方向が landscape と整合。
**AI-native の境界拡張（enforcement = ADR Kit 的 lint 化 / option 生成）**は現ドラフト（entry-unification, review-tiering 等）の位置づけにも効く。enforcement・drift 検知は ADR-0098（verified-as-of）と接続。
定義の難所: 汎用セグメントは曖昧 → そこを狙うなら市場教育が要る。ソロ/開発者セグメントの確立した ADR job に寄せるほど positioning は明確。

6. 次アクション

本 RQ を入力に 意思決定の JTBD を ADR-0043 の 3軸テストで起案（making+recording 統合 / ソロ→SaaS スケール経路を中核仮説に）。
JTBD 確定 → MVP exit 基準を定義 → 現ドラフト（entry-unification / review-tiering / ADR-0095 Phase B 等）を必須 vs v1.1に仕分け。
Q4「ソロの making 誘導が薄い」が顕著なら、そのセグメントだけ後追い RQ で深掘り（段階方針）。