JTBD-012 論点整理（Decision Inventory）

ステータス: 起票 (2026-07-01) 本ドキュメントは JTBD-012 帳票・証憑管理 SaaS の未確定論点を、arch 側の 塊 (D1〜D10) を土台に、RQ-117 Synthesis の 119 items を再構造化した「論点の landscape 俯瞰」の SSoT。arch と役割を分けて運用する: arch はモジュール構成 (層/責務) の正典、本ページは意思決定項目 (論点) の正典。

代表取締役の週次集中判断 (30-60 分/週) のための地図として機能する。個別 draft ADR は本ページ §Wave 別 順序で drp KV へ投函し、審査後 rendered ADR (docs/adr/) を canonical 化する。

このドキュメントは何か

立ち位置

• arch (arch_jtbd012_voucher_saas_draft.md) = モジュール構成 (層 ①〜⑤ + 塊 D1〜D10) の SSoT。2026-06-08 起票 (Cloudflare 前提のまま stale)。別 PR で ADR-0179 反映 amend が必要。
• 本ページ = 意思決定項目 (論点) の SSoT。arch の 塊 D1〜D10 構造を土台に、RQ-117 Synthesis の 119 items を再構造化。ADR-0179 (Phase 0-1 GCP 単一) を反映。
• RQ-117 Synthesis = 119 items の詳細・Tier 分類・Top 10 スコアリング。本ページはその要約 + 塊 axis での再構造化。

想定読者と使い方

• 代表取締役 ([email protected]): 週次 30-60 分の集中判断で「今週どの 論点 を落とすか」を選ぶ。本ページ §Wave 別 順序 と §塊 状態集計 が入口。
• Claude Code (vlt / drp / main セッション): 開幕時に本ページ §塊 別 詳細 を読み、未確定論点の draft ADR 起票候補を認識する。ADR 受理時は本ページの状態列を書換する (updates 対象)。
• Jr 入社時 (2026-10 想定): JTBD-012 SaaS の設計全体像を「塊 × 論点」の 2 軸で把握するための入口。

スコープと非スコープ

状態凡例

arch 層 × 塊 × 論点 分布

arch (arch_jtbd012_voucher_saas_draft.md) の層構成図 (①〜⑤ + 横断) と塊 (D1〜D10) の対応関係を axis に、Wave 1 主要論点を層ごとに配置する。

読み方:

• Wave 1 Top 10 は 層 ③ (5 items) + 層 ④ (3 items) + 層 ⑤ (1 item) + 層 ②（1 item） に分布 = 層 ③・④ が critical path の主戦場
• 層 ① UI 系論点は Wave 1 にゼロ = Phase 0 は最小 UI で走り、UI 設計は Phase 1 GA 前判断に defer
• 層 ⑤ 基盤の K1 (region) 確定が 全層のデプロイ先を規定 = 他 3 items (A1 · M3 · R1) と並行だが最軽量 (1PD) で先落とし可能
• 層 ③ の 5 items は Route #3 真実性 4 要素 (ADR-0175) の実装配線 = A2 (append-only) · F1 (訂正削除) · R1 (TSA) · M3 (JIIMA) · P2 (事務処理規程) が対

塊 × RQ-117 カテゴリ Cross Matrix (詳細集計)

各セルは Tier 1 items 数 (該当なしは -)。Total = 119 items (Tier 1 = 83 + Tier 2 = 36)。

読み方: D2 正本 (12 items) と D3 基盤 (16 items) と D10 暗号化 (14 items) が Tier 1 の 50% を占め、Phase 0 の実装工数の主軸を成す。D7 真実性 (11 items) は Route #3 (訂正削除履歴 · ADR-0175 確定) の実装配線に集中。

信頼境界別 論点越境

arch の信頼境界・配置図 (Mermaid) で示された 5 境界 (顧客テナント / 自社 SaaS / ハイパースケーラ / 第三者 SaaS / 自社内部) と、論点がどの境界を越えるかの対応。

読み方:

• 契約 lead time 制約 = 第三者境界の R1 (TSA) と M3 (JIIMA) は自社決定だけでは動かせない外部制約で、Phase 1 GA 遅延の主因
• 一度決めたら変更困難な決定 = 自社 SaaS 境界の A1 (schema) と A2 (append-only) は事後変更コストが極大 (one-way door)
• 顧客側変更に耐える設計要 = 顧客テナント境界の B1/N1 は「顧客 IdP 変更に耐える pluggable 設計」(ADR-0127) を守る

論点の依存関係

「何を先に決めないと、他が決まらないか」の SSoT。RQ-117 Synthesis の Critical Path 分析を可視化。

依存関係グラフ (Wave 1-4 · 主要 24 items)

flowchart TB
  classDef l0 fill:#fff3bf,stroke:#f08c00,color:#663c00,font-weight:bold;
  classDef l1 fill:#d3f9d8,stroke:#2f9e44,color:#1b4332;
  classDef l2 fill:#e7f5ff,stroke:#1c7ed6,color:#0b4a8b;
  classDef l3 fill:#fff0f6,stroke:#c2255c,color:#7d1a3b;
  classDef l4 fill:#f1f3f5,stroke:#868e96,color:#343a40;
  classDef ext fill:#ffe8cc,stroke:#e8590c,color:#7f4700,stroke-dasharray:5 5;

  %% Level 0 (最初 · 何にも依存しない)
  K1["K1: GCP region
(⑤基盤・1PD)"]:::l0
  A1["A1: schema 基礎
(④正本・3PD)"]:::l0
  M3["M3: JIIMA cert track
(③真実性・5PD)"]:::l0
  R1["R1: TSA provider
(③真実性・5PD・外部契約)"]:::l0

  %% Level 1 (Level 0 決定後に着手)
  A2["A2: append-only
(③④・5PD)"]:::l1
  H1["H1: 3 要素索引
(②・5PD)"]:::l1
  F1["F1: 訂正削除履歴
(③・8PD)"]:::l1
  O1["O1: RPO 目標
(④・3PD)"]:::l1
  O4["O4: cross-region replica
(④・5PD)"]:::l1
  P2["P2: 事務処理規程 template
(③・3PD)"]:::l1
  M4["M4: JIIMA 予算
(③・2PD)"]:::l1

  %% Level 2
  G1["G1: TSA Strategy interface
(③・4PD)"]:::l2
  O3["O3: PITR retention
(④・2PD)"]:::l2
  B1["B1: API 認証
(②・3PD)"]:::l2
  Q3["Q3: 認証取得順序
(③・2PD)"]:::l2

  %% Level 3
  N1["N1: MFA policy
(②・2PD)"]:::l3
  N3["N3: SIEM
(⑤・4PD)"]:::l3
  N6["N6: IR runbook
(⑤・3PD)"]:::l3

  %% Level 4
  J1["J1: dogfood go/no-go
(全体・2PD)"]:::l4
  L1["L1: multi-tenant 判断
(横断・Phase 1)"]:::l4

  %% 外部 spike (RQ 待ち · 破線)
  RQ088["RQ-088: D7 真実性 spike"]:::ext
  RQ091["RQ-091: D9 年限 spike"]:::ext
  RQ098["RQ-098: D10 TEE spike"]:::ext
  RQ099["RQ-099: D4b IdPBroker spike"]:::ext

  %% 依存辺
  K1 --> A1
  K1 --> O1
  K1 --> O4
  A1 --> A2
  A1 --> H1
  A1 --> F1
  A1 --> O1
  A1 --> B1
  A1 --> J1
  A2 --> F1
  F1 --> G1
  R1 --> G1
  M3 --> P2
  M3 --> M4
  M3 --> Q3
  O1 --> O3
  O4 --> O3
  B1 --> N1
  B1 --> N3
  N3 --> N6
  N6 --> J1
  J1 --> L1

  %% spike の効き先
  RQ088 -. 実装先送りリスク .-> F1
  RQ091 -. 実装先送りリスク .-> O1
  RQ098 -. 実装先送りリスク .-> N3
  RQ099 -. 実装先送りリスク .-> B1

Critical Path Level 別 一覧

Level 0 = 何にも依存しない (最優先 · Phase 0 開始と同時に確定要)

Level 1 = Level 0 のいずれかに依存 (PR-5/6/7 merge 前必達)

Level 2 = Level 1 のいずれかに依存

Level 3-4 = Phase 0 中盤〜終盤

• Level 3: N1 (needs B1) · N3 (needs B1) · N6 (needs N3)
• Level 4: J1 dogfood pilot go/no-go (needs N6, A1) · L1 multi-tenant (needs J1)

各 Wave 1 論点の前提と下流

決定順序の 3 原則

論点順を「何から決めるか」で迷ったら、次の 3 原則で判断する:

1. 外部リードタイム逆算 (calendar-driven)
   • M3 JIIMA (3 ヶ月) · R1 TSA (数週間) は外部機関・ベンダー依存で、先送りするほど Phase 1 GA が遅れる
   • 内部決定より優先させて Wave 1 の週 1-2 に置く
2. one-way door 優先 (irreversibility-driven)
   • A1 schema (id 型 + content_hash) · A2 append-only · F1 訂正削除履歴 は事後変更コスト極大
   • 実装着手前に凍結 = Wave 1 の週 1-3 に集中
3. 依存グラフ Level 順 (topological)
   • Level 0 (K1/A1/M3/R1) を確定してから Level 1 に進む
   • Level 0 内でも 4 items 並行 (代表取締役の週 30-60 分判断 × 3-4 週で完遂)

実務推奨 (代表取締役の週次判断 × 12 週での配分):

RQ-118 (SaaS 一般化フレームワーク) との整合

本ページの Wave 順序を RQ-118 Synthesis (2026-07-01 · 3 モデル $7.25) の一般化 7 phase model で照らし直した結果、次の対応が確認できる:

一般化 Phase と JTBD-012 Wave 1 論点のマッピング

読み替え: Wave 1 Top 10 は phase −1 (M3/R1) + phase 0 (A1/K1) + phase 2 (残 6) の混合で、Phase 1 (identity/tenancy) は Wave 2 に defer した構造。Compliance-first の phase 順序と整合。

RQ-118 が明示化した gap (RQ-117 Level 0 に未反映の 3 件)

3 モデル DR で「一般化 Phase 0 に含まれるべき」と特定されたが RQ-117 で明示されていない 3 論点。2026-07-02 に Wave 2 リストへ反映済 (次セッション以降で新規 ID 発行 + RQ-117 Synthesis 側追記へ拡張予定):

決定順序 3 原則の RQ-118 補強

RQ-118 が定量化した failure pattern top 10 (中央値 5 EM / top-3 平均 9 EM) を根拠に、既存 3 原則が実測で正当化された:

1. 外部リードタイム逆算 (calendar-driven) — JIIMA 3-8mo · SOC 2 II 6-15mo · ISO 27001 6-10mo の実測 lead time 表 (RQ-118 §4) が根拠
2. one-way door 優先 (irreversibility-driven) — failure pattern #1-3 (database tenancy 6-12EM · auth-before-tenancy 12+EM · region-before-residency 3-9EM) の 3 モデル合意が根拠
3. 依存グラフ Level 順 (topological) — RQ-118 の phase −1 → 0 → 1 → 2 が Level 0-2 topology で一致

Wave 1: 最初の 3 週間 (Top 10 · Score 順)

運用ルール (RQ-117 Synthesis §Question 4 より):

• 週次 1-2 draft ADR (代表取締役の集中判断 30-60 分/週)
• 最初の 3 週間で Top 10 制覇 (30-60 分 × 3 週 = 1.5-3 時間 × 集中判断)
• Wave 1 の 4 items (A1 · K1 · M3 · R1) が Critical Path Level 0 = PR-4 merged 前に必ず確定
• Wave 1 の 6 items (A2 · H1 · F1 · P2 · O1 · O4) が Level 1 = PR-5/6/7 merged 前に必ず確定
• RQ-118 補完 3 論点 (KMS custody 方針 / Identity boundary / Network boundary VPC-SC) は Wave 2 に組込済 (詳細は §RQ-118 gap 表)。Phase 1 GA 前確定必達 = Wave 2 完遂前に方針レベルで確定する

Wave 1 #2 起票候補の 3 択 quick reference (2026-07-02 追記)

Wave 1 #1 (A1 = receipts + audit_log schema 基礎) は PR #3541 で起票済。次に起票する #2 は R1 / K1 / M3 のいずれか (Critical Path Level 0 · A1 と並列)。代表取締役の週次判断 (30-60 分/週) の入口として、3 択の性質を 1 表にまとめる:

判断のフレーム (代表取締役向け · 「今週どれを落とすか」):

• 時間圧力優先 → M3 (JIIMA 3ヶ月 lead) or R1 (TSA 契約 lead)
• 判断負荷最小 → K1 (方針既確定 · 詳細のみ · 30 分)
• 下流波及最大 → M3 or K1 (共に Blocks 3)
• Score 最高 → M3 (11.5)

いずれの候補も PR-4 merged 前に確定必須 (Critical Path Level 0)。3 択を代表取締役が選択後、tasks/prompts/draft_adr_*.md に起案 → drp KV 投函の順で進める。

Wave 2: Phase 0 中盤 (rank 11-30 · 20 items + RQ-118 補完 3 論点)

G1 TSA Strategy interface (D7) · N1 MFA policy (D10) · N3 SIEM / log aggregation (D10) · N6 Incident response runbook (D10) · M4 JIIMA 手数料予算 (D7) · Q3 認証取得順序 (D7) · N5 Pen test 範囲 (D10) · N7 Breach determination log (D10) · M1-M2 JIIMA トラック詳細 (D7) · M5 マニュアル整備責任者 (D7) · O2 RTO 目標 (D9) · O5 DR runbook rehearsal (D9) · P4 ダウンロードの求め SLA (D7) · A3-A8 schema 詳細 (D2 · 5 items) · B1 API 認証モデル (D4b)

+ RQ-118 補完 3 論点 (2026-07-02 追加 · 詳細は §RQ-118 gap 表):

• KMS custody 方針 (D10 · Wave 2 前半) — customer-managed vs platform-managed の方針だけ確定 · 実装は RQ-098 spike (Wave 3) に defer
• Identity boundary (D4b · Wave 2 前半 · B1 前) — user ∈ org ∈ workspace のモデルを B1 API 認証モデル定義より前に確定 · Phase 1 GA 前 multi-tenant retrofit を予防
• Network boundary VPC-SC (D3 · Wave 2 後半) — private endpoints / perimeter 方針を K2/K3 (region) と並列に確定 · Phase 1 GA 前 multi-tenant 化前必達

Wave 3: Phase 0 終盤 (rank 31-83 · 53 items)

残 Tier 1 items = 主に C (security 5 items) + D (SLO 3 items) + I (照合 3 items) + J (運用 5 items) + B (API 4 items) + K2-3 (region 2 items) + N8 (D10) + Q1-2 (D7) 等。Phase 0 完了時 Tier 1 の 60% (50 items) 確定を目標。

Tier 2 (36 items): draft ADR 化しない

対応する scope doc (pr4-endpoint-schema.md / pr5-search-endpoint.md / pr6-correction-deletion-history.md / pr7-tsa-strategy.md) or 開発仕様書 (docs/dev/dev_*.md) 内で決定。scope docs に「本項は ADR 化せず本 doc で決定」注記を追加 (別 PR)。

• B2 GET /receipts response contract
• B3-B8 API design detail (pagination · rate limit 等)
• C7-C8 security tuning
• D4-D6 SLO tuning
• E1-E8 CI/CD detail
• G2-G6 TSA impl detail (fake provider · retry · cache)
• H2 search API pagination model
• I4-I6 Reconciliation tuning
• J2-J8 Ops detail (on-call · runbook stubs)
• K3 data residency detail
• L2-L4 expansion (pricing / plan tiers)
• M6-M9 JIIMA 派生
• N2 / N4 / N8 security ops
• O3 PITR retention window
• P1 / P3 / P5 顧問税理士 連携詳細
• Q1-Q2 セキュリティ資料

塊 別 詳細 (D1-D10)

D1 商品スコープ (product scope)

D2 正本 (RecordStore · ADR-0126 ✅ 確定)

責務: 証憑本体 = GCS Object Retention Lock · 台帳 = Cloud SQL · 索引 = 補助 (H1 で戦略決定)。

D3 基盤 (Platform · ADR-0179 ✅ 確定 = GCP Cloud Run + Cloud SQL + GCS + BigQuery + Vertex)

責務: SaaS 実行環境 · 監視 · 認証基盤 · CI/CD。Cloudflare は明示的に不採用 (ADR-0179 §3.4)。

D4a テナント分離 (TenantContext · 🔴 RQ-092 spike 待ち)

責務: multi-tenant 化 (Phase 1 GA 以降) 時のテナント境界強制。

D4b 認証 (AuthGateway · ADR-0127 ✅ 部分確定 = M365 day-1 pluggable)

責務: 顧客の M365 / Google などの IdP でログインを可能にする。

D5 取込 (IngestAdapter · ADR-0127 ✅ 部分確定 = M365Adapter day-1)

責務: 証憑ソース (Outlook/OneDrive · Gmail/Drive) からの受領。Phase 0 dogfood では manual upload 主体。

D6 データモデル (VoucherLedger + SearchIndex · A1 に依存)

責務: 証憑台帳の schema と検索索引の設計。

D7 真実性 (IntegrityGuard + ImmutableStore · ADR-0175 ✅ Route #3 確定)

責務: 3 号真実性ルート 4 要素 (訂正削除履歴 + 事務処理規程 + JIIMA cert + TSA 認定) を全て実装配線。

D8 自動化 (OcrExtractor + AutomationGate · Phase 0 spike 待ち)

責務: OCR + LLM で 3 要素抽出 + 信頼度ゲート。

D9 保存年限 (RetentionManager · 🔴 RQ-091 spike 待ち)

責務: 電帳法 保存年限 (最長 10 年) の自動管理 + 期限後廃棄。

D10 暗号化 (KeyManager · 🔴 RQ-098 spike 待ち)

責務: テナントごと envelope 暗号化 + 鍵エスクロー + TEE (機密計算) 判断。

塊 状態集計

「部分」= 塊レベルでは ADR 受理済だが 論点 個別は未消化 (例: D2 は ADR-0126 で正本 = 自社集約 案 B 確定だが、A1-A8 の schema 詳細は未着手)。

次段 (2026-07-01 時点)

1. Wave 1 Top 10 の順次起票: 週次 1-2 draft ADR ペース · 最初の 3 週間で完遂目標。A1 (shipped) → R1 → K1 → M3 の Level 0 を優先。
2. arch 側 amend PR: arch_jtbd012_voucher_saas_draft.md の Cloudflare 記述を ADR-0179 (GCP 単一) に置換 · 塊 D3 の基盤層 Cloud Run + Cloud SQL + GCS + BigQuery + Vertex 追記。Wave 1 起票と平行実施可能。
3. spike 4 件の Deep Research 起票: RQ-088 (D7 真実性) · RQ-091 (D9 年限) · RQ-092 (D4a 分離) · RQ-098 (D10 暗号) · RQ-099 (D4b IdPBroker)。Phase 0 中盤までに 1-2 件消化目標。
4. 本ページの updates: draft ADR 受理ごとに §Wave 別 順序 と §塊 別 詳細 の状態列を書換。Auto-sync CI 化候補 (別 PR で検討)。
5. RQ-118 反映 (新規追加 · 2026-07-01):
   • KMS custody 方針を Wave 1 or 2 前半で確定 (実装は RQ-098 spike 継続)。失敗パターン #9 予防 (3-6 EM)。
   • Identity boundary (org model) を Wave 1 or 2 に新規 論点として追加検討。B1 (Rank 15) より上流。Slack Unified Grid 予防 (12+ EM)。
   • Network boundary (VPC-SC) を Phase 1 GA 前 (Wave 2 後半) に確定明示。
   • ADR 起案候補「SaaS 開発の決定順序フレームワーク採択」(ADR-0021 の refinement/amend 相当 · 1 論点 = compliance-constrained phase −1 to 2 anchor の明文化)。

参照

• arch_jtbd012_voucher_saas_draft.md — arch (層 ①〜⑤ + 塊 D1〜D10) SSoT (Cloudflare 記述は 2026-07-01 時点で stale)
• RQ-117 Synthesis — 119 items 詳細 + Top 10 スコアリング + JIIMA coverage matrix
• ADR-0125 — JTBD-012 dogfood 先行方針
• ADR-0126 — 正本 = 自社集約 (案 B)
• ADR-0127 — 認証 = M365 pluggable day-1
• ADR-0175 — Route #3 真実性 4 要素
• ADR-0179 — Phase 0-1 GCP / Phase 2B AWS · Cloudflare 不採用
• ADR-0181 — vlt クローン設立

改訂履歴