ADR-0125: JTBD-012 証憑管理を汎用版・本番アーキの自社 dogfood で先行する

• Status: Accepted
• Mode: Critical
• Kruchten Type: Existence/Executive
• Scope: product
• Implementation Status: Not Started
• Supersedes: ADR-0080 (JTBD-012 の Phase 位置づけを前倒し)
• 起案者: [email protected]
• 起案日時 (JST): 2026-06-08 12:05
• 承認日時 (JST): 2026-06-08
• Deciders: [email protected] (単独・撤退判定は顧問税理士〔公認会計士〕を外部判定者 P4 に指名)

1. コンテキスト

1.1 背景

電子帳簿保存法の「電子取引データ保存」(③) が 2024-01 から義務化され、自社にも適用される。要件は「すみやか保存」(取引日から概ね 7 営業日以内のタイムスタンプ付与) と 3 要素検索 (取引年月日 / 金額 / 取引先) だが、自社はいずれも未対応である。JTBD-012「帳票保存・証憑管理」は B2B SaaS プロダクト化へ方針転換したが、計画が大きく (ADR-A〜E / RQ-088〜093)、着手順が未確定である。

1.2 現状 (As-Is)

帳票要件カバレッジは 36% (RQ-061、実装 18/50 種)。電帳法③のすみやか保存・3 要素検索ともに未対応。JTBD-012 の着手スコープと順序が未確定のため、下流の個別アーキ決定 (保存基盤・認証・取込・データモデル) を起案できない状態にある。

1.3 課題

「建設業特化を先に作るか、汎用を先にやるか」「自社利用をどう位置づけるか (使い捨てプロトタイプか本番アーキか)」が決まらない。③ は法的義務で取りこぼし 0 が要求され、保存漏れは青色申告承認取消しの対象となり得る (国税庁 FAQ 令和5年度版 問42)。本 ADR はこの「着手スコープと順序の未確定」を解消する。

1.4 制約・要件

• 法令期限: 電帳法③義務 (2024-01 から既に適用中) の取りこぼし 0。
• 個人開発リソース: 構築規模が個人開発で現実的に収まること。
• dogfood の二重用途リスク: 法令本番と本番アーキ検証を同時に担うため、取りこぼし・障害が即・法令違反に直結する一方通行構造を排除すること。
• 本番データ保護: tenant-0 の本番③証憑に対する破壊的スキーマ変更を禁止すること。
• 監査証跡: dogfood 期間を含む全期間で、保存の成否・取込ジョブのタイムアウト・手動補正を改ざん不能な監査ログに記録し、税務調査に提出可能な形式で保持すること。
• 製品化方針との整合: 外部 SaaS への正本依存を恒久化しないこと。

1.5 目標 (To-Be)

JTBD-012 を、建設業特化より前に「汎用 証憑プロダクトを顧客向けと同一の本番アーキで構築し、自社を最初のテナント (tenant-0) として dogfood する」スコープで先行着手する。最初の機能スライスは電帳法③電子取引とし、②スキャナ保存・①優良電子帳簿・建設業特化は後続の機能スライスとして Defer する。Non-Goals: 保存基盤・認証・データモデル等の個別アーキ選定は本 ADR では行わず、下流 ADR (D2〜D9) に委ねる。

2. 決定

JTBD-012 を「汎用 証憑プロダクトを顧客向けと同一の本番アーキで構築し、自社を最初のテナント (tenant-0) として dogfood する」スコープで先行着手する。最初の機能スライスは電帳法③電子取引に限定し、②①建設業特化は後続スライスへ Defer する。本スコープは次の 3 前提条件のもとで成立させる。これは #suitable (Must) の「③適合を構造的に担保し取りこぼしを防ぐ」核心前提を、dogfood の二重用途 (法令本番 × アーキ検証) が一方通行リスクにならない形で守るためである。

• P1 (外部 SaaS シャドー → cutover): Phase 0 の電帳法③の法的正本は、自社システムが受入基準 (§Confirmation の KPI) を満たすまで外部 SaaS (freee 等) に置き、自社システムはシャドー運用で並走検証する。受入基準を満たした後に正本を自社へ cutover する。これにより dogfood の取りこぼし・障害が即・法令違反になる一方通行構造を排除する (検知後の事後縮小ではなく、違反前に外部正本へ依存できる)。外部 SaaS への正本依存は最長 12 ヶ月を許容上限とし、これを超えて cutover できない場合は「外部 SaaS 恒久化＝製品化方針違反」とみなして本 ADR を再起案する (無自覚なロックイン恒久化を防ぐ)。
• P2 (本番データ保護): dogfood 期間中、tenant-0 の本番③証憑に対する破壊的スキーマ変更を禁止する。スキーマ変更は expand-contract 方式 (新旧併存 → 移行 → 旧廃止) とし、変更前バックアップ・ドライラン・移行後の件数および金額合計ハッシュ照合を必須とする。
• P3 (全期間の監査証跡): dogfood 期間を含む全期間で、保存の成否・取込ジョブのタイムアウト・手動補正を改ざん不能な監査ログに記録し、税務調査に提出可能な形式で保持する。下流 D7 の策定を Phase 0 の実装開始より前に完了させることをゲート条件とし、D7 で国税庁 FAQ の改訂追跡担当者・改訂検知の頻度・形式変更時の対応フロー (新旧形式の併存期間など) を明示する。

3. 判断基準 (Decision Drivers)

ADR-0050 で確立した arc42 Q42 9 タグ + WSM + K.O. criterion を適用。

3.1 評価軸

K.O. criterion: Must 軸 (#suitable) の score < 3 は不採用。

3.2 評価軸 × 案スコア表

4. 検討した代替案 (Alternatives Considered)

1. (採用) 汎用版を本番アーキで先行・自社 dogfood (前提 P1〜P3 つき)。
2. 案 A: 使い捨て GAS プロトタイプで先行 (ロジック検証のみ) — GAS は顧客基盤 (Microsoft 365) に載らず、学習・コードが SaaS 本実装へ移植できない。二度手間で #maintainable に反するため却下。
3. 案 B: 建設業特化 SaaS をいきなり構築 — 汎用基盤 (保存・認証・取込) が固まらないまま縦に深掘りし、手戻りリスクが大きい。市場検証前の過剰投資のため却下。
4. 案 C: 外部 SaaS (freee / マネーフォワード / 弥生) を恒久採用し自社対応のみ済ます — 製品化という戦略目的を放棄し本番アーキの学習も得られないため、恒久採用としては却下。ただし前提 P1 の一時的な法的正本 (シャドー期間のフォールバック) としては採用する。

5. 影響 (Consequences)

5.1 正の影響 (Good)

• 電帳法③義務を、前提 P1 により法令違反リスクを負わずに自社で達成できる。
• 本番アーキを実地検証 (dogfood) でき、顧客提供時のリスクを下げられる。
• 下流 ADR (D2〜D9) の前提スコープが固定され、着手順が定まる。

5.2 負の影響 (Bad)

• 使い捨てプロトタイプより初期構築が重い (実アーキを最初から立てる)。前提 P1 のシャドー並走で外部 SaaS 費用も一時的に発生する。
• 既存 GAS 会計 (自社会計 SSoT) と新設 Workers 証憑プロダクトの連携境界の設計が新たに必要。
• 自社=単一テナントでも、マルチテナント分離を最初から設計する負担が生じる。単一テナント運用では分離バグが原理的に再現しないため、確証バイアスのリスクがある → §Confirmation (e) で CI 機械検証。
• (盲点1: 課金モデル超過リスク) Cloudflare Workers 有料プラン ($5/月) では 1,000 万リクエスト/月超で $0.30/100万リクエストの従量課金が発生し、R2 は Class B (GET) が 100 万回超で $0.36/100万回、D1 は 25 億行読取超で $0.001/100万行が加算される。月次証憑 100〜数百件規模でも、毎営業日突合パイプライン・死活監視ポーリング・CI/CD デプロイが重なると月数十万リクエストに達し得る。OCR/LLM 従量 ($5〜20) と合算すると月 $200 上限を恒常的に上回るシナリオが容易に描ける。下流 D5 で課金モデルを想定リクエスト数で試算し、上限超過時の段階的対処 (上限引き上げ → ADR 再起案 → 外部 SaaS 恒久化) のフローチャートを ADR に追記する。
• (盲点4: Workers Cron 構造制約) Cloudflare Workers Cron は wall time 上限 30 秒、1 リクエストあたりサブリクエスト (fetch) 上限 50 件。証憑 1 件あたり OCR/LLM・R2 書込み・D1 書込み・監査ログ書込みで最低 4 サブリクエスト要するとすると、1 Cron で最大 12 件しか処理できない。月 100〜数百件が月末に集中すると 7 営業日カウントの後半に取込集中するリスクがある。サブリクエスト上限は非同期化 (Queues 等) でも 1 メッセージ=1 Worker 起動の制約として残る → 下流 D5 への入力条件として「Queues 分割必須かどうかの判定基準」と Queues 追加コスト ($0.40/100万メッセージ) を月 $200 上限試算に含める。
• 取込ジョブの無音障害 (Cloudflare Workers Cron は最大 2 回再試行後はログのみ・アラート未発報) で 7 営業日カウントが進行し得る → §Confirmation (d) の死活監視で検知。Workers CPU 上限超過時の非同期化判断は下流 D5・D7 の入力とする。
• (盲点6: 突合パイプライン自体の無音停止) 突合パイプライン自体が Workers Cron で動く場合、Workers 既知挙動により停止が Slack 通知されない。パイプライン停止中は差分が常に 0 と見え、KPI (a) が「正常」を示し続けたまま 7 営業日経過で違反確定するリスクがある。突合パイプライン自体の死活を監視する watchdog を独立ランタイム (GitHub Actions scheduled workflow または cron-job.org) で実装し、最終成功タイムスタンプが 2 時間以上更新されない場合にアラート発報する仕組みを Phase 0 開始時の必須実装とする。
• GAS→Workers のデータ移送はフィルタ再評価で行ずれが起き得る (Google Issue #36763062) → 下流 D3 で「append / batchUpdate 単一リクエスト限定、または移送後ハッシュ照合必須」を入力条件とする。
• GAS↔Workers 連携は GAS 同期ポーリング (GAS 実行時間 6 分上限に抵触し仕訳が半書込みになるリスク) を避け、Workers→GAS の Webhook 受信型に限定する → 下流 D3 の入力条件とする (前提 P2 とは別論点)。
• (盲点2: GAS 送信側制約) GAS→Workers 送信 (UrlFetchApp) は同期呼び出しであり、Workers 応答遅延・タイムアウトが GAS 実行時間 (6 分) を圧迫する。月末・決算期で複数トリガー並走時、GAS は同一スクリプトの並列実行を保証せず後続トリガーがキューされず 7 営業日カウントが消化される。スクリプトプロパティ (1 プロパティ 500KB・合計 9MB) に取込済み ID や突合ハッシュを蓄積すると数ヶ月で枯渇し書込み失敗する → 下流 D3 の入力条件として、UrlFetchApp 呼び出しを同期/非同期どちらで実装するか明示し、GAS 実行時間上限・並列実行制限・プロパティ上限それぞれの上限値と月次最大件数での余裕を試算する。
• (盲点5: Jr 引き継ぎコスト) Cloudflare Workers/D1/R2/KV の組み合わせ・expand-contract 方式スキーマ管理・テナント分離ファジングテストは、バックエンド経験が浅い Jr にとって習得に 6〜12 ヶ月を要する技術スタック。Review-After (2026-12) は入社 2 ヶ月後にあたり評価が早すぎる。引き継ぎ困難判明時には電帳法③の 7〜10 年保存義務期間が進行中で、リファクタコストが初期構築コストを上回り得る → §3.1 の #maintainable に「Jr 習得コスト上限 (入社 3 ヶ月以内に単独で取込ジョブ障害対応・スキーマ変更・監査ログ提出が実施できること)」を定量基準として追記し、D2〜D9 の技術選定レビュー時に必須チェック項目とする。
• (盲点7: 国税庁 FAQ 改訂リスク) 国税庁は電帳法関連 FAQ を毎年度改訂しており、過去にも「訂正・削除履歴の記録範囲」解釈が拡張された実績がある。P3 の「提出可能な形式」具体要件を下流 D7 に委ねているため、D7 策定前に実装が先行すると後から形式変更が必要になる。監査ログは append-only 設計のため遡及修正が原理的に困難 → 下流 D7 の策定を Phase 0 実装開始前に完了させることをゲート条件とし、改訂追跡担当者・改訂検知頻度・形式変更時の新旧併存期間を明示する。
• 月 100〜数百件の二重取込 (freee と自社の両系統) の経路設計と、長期 TCO (7〜10 年保存ストレージ・監査ダウンロード帯域) は、それぞれ下流 D5・D9 の入力条件とする。
• (盲点9: 帳票カバレッジ確証バイアス) 現在の帳票要件カバレッジは 36% (18/50 種) であり、自社テナントが③最小スライスのみで dogfood 完走しても検証できる帳票種別は限定的。dogfood の成功体験が「本番アーキで動いた」という強い証拠として認知され、未検証 32 種 (残 64%) のリスクが過小評価される確証バイアスのリスクがある → Review-After の必須成果物として「dogfood でカバーした帳票種別数と、顧客向け建設業特化スライスで必要な帳票種別との差分マップ」を追加し、カバレッジ残課題を可視化した上でマルチテナント移行可否を判定するゲートを設ける。

5.3 中立・トレードオフ (Neutral / Trade-offs)

• 過去 ADR との関係
  • ADR-0080 (JTBD スコープ定義) — Supersede。「JTBD-012 実装状況 = Not Started・年次/低優先」を「Phase 0 着手・最優先 (電帳法③)」へ上書きする。
  • ADR-0121 (意思決定パイプライン製品化 / Entra OIDC / Cloudflare 基盤) — 補完 (共通基盤を継承)。
  • ADR-0108 (M365 / Entra 顧客アクセス) — 補完。
  • 下流 (本 ADR が前提スコープを与える): D2 記録正本 / D3 基盤・会計境界 / D4a テナント分離 / D4b 認証 / D5 取込抽象 / D6 データモデル / D7 ③真実性 / D8 取込オートメーション / D9 保存年限。
• Review-After: dogfood 開始 6 ヶ月後 (目安 2026-12) に、マルチテナント本番移行の可否と自社③ cutover 状況、および帳票種別カバレッジ差分マップを再評価する。

コスト試算

• 意思決定コスト: 本 ADR 起案〜承認に約 0.5 人日。
• Phase 0 dogfood 構築 (下流 D2〜D8 実装、③電子取引の最小通し):
  • 従来 (手実装前提): 概算 40〜60 人日 (個人開発)。
  • 生成 AI 活用前提 (Claude Code 等でペアプロ実装): 概算 15〜25 人日。圧縮率約 1/2〜1/3。開発支援 LLM 利用料が月 約 $100〜300 別途発生。
  • 法令仕様確定フェーズ (国税庁 FAQ 解釈を要する真実性確保まわり) は圧縮なし前提で独立工数 10〜20 人日 (下流 D7 で精緻化)。
  • マルチテナント分離の設計レビュー・自己ペネトレーション相当の検証は独立工数 5〜10 人日 (下流 D4a)。手戻り最悪ケースは現見積の 2 倍で再試算。
• 運用: Cloudflare Workers + R2 / D1 / KV を自社 1 テナントで月 約 $20〜50。OCR/LLM (下流 D8) 従量が月 約 $5〜20。前提 P1 の外部 SaaS シャドー並走 (約 3 ヶ月) が月 約 ¥3,000〜5,000。
• 定常運用 (dogfood 期間中の毎営業日突合確認・例外バッチ対応・監視): 月 約 1〜2 人日。
• 撤退判定の基準「合意見積」: Phase 0 開始時に 1 本へ確定。暫定値「生成 AI 前提の構築 25 人日 ＋ 法令仕様確定 20 人日 ＋ 分離検証 10 人日 = 計 55 人日」。
• 数値は粗い初期見積であり、下流 ADR で精緻化する。

6. 撤退条件 (Rollback Plan)

前提 P1 により、自社システムの取りこぼし・障害は即・法令違反にはならない (外部正本が違反を防ぐ)。この上で次のいずれかでスコープを縮小・見直す (例: 自社③を Defer し外部 SaaS 正本を継続、または建設特化先行へ切替)。

1. シャドー運用 3 ヶ月で自社システムが受入基準 (§Confirmation の (a)(c)) を満たさない (cutover できない)。→ cutover を保留し外部 SaaS 正本を継続、自社③着手を見直す。
2. 自社の証憑自動確定率が 3 ヶ月で 50% 未満 (工数削減が成立しない)。
3. Phase 0 構築工数が合意見積 (暫定 55 人日) の 2 倍 (110 人日) を超過、または自社システムの運用が月 $200 を超過 (Workers / R2 / D1 / KV / OCR・LLM の自社費を指し、前提 P1 の外部 SaaS 並走費 月 約 ¥3,000〜5,000 は別枠で本判定に含めない)。→ cutover せず外部 SaaS 正本を継続するため、法令期限の縛りは生じない。
4. 外部 SaaS への正本依存が 12 ヶ月を超えても cutover できない (P1 の許容上限超過)。→ 外部 SaaS 恒久化＝製品化方針違反として本 ADR を再起案する。
5. (盲点8追加) 外部 SaaS 並走費が月 ¥10,000 を超えた場合は撤退条件 3 の判定に含めて再評価する。外部 SaaS の契約変更・プラン廃止を検知したタイミングで即時に撤退判定を実施する。

判定プロセス (盲点3対応): 撤退条件 1〜5 それぞれについて「誰が・何を根拠に・いつまでに」判断するかを明記する。個人開発のサンクコスト・確証バイアス (Drummond 1996, Escalation of Commitment: 自己完結型意思決定者は外部レビュアー不在時にサンクコスト効果が 1.5〜2 倍強まる) を防ぐため、外部レビュアーを判定者に指名し、判定会議の日程を Phase 0 開始時に予約することを前提条件 P4 (外部判定者の事前指名) として追加する。外部判定者には 顧問税理士 (公認会計士) を充て、Phase 0 開始時に判定会議の定例日程を確定する。撤退条件 1〜4 の「見直す」結果として許容される選択肢 (Defer・建設特化先行・外部 SaaS 一時延長) を判定会議で明示的に選択し、「もう 1 ヶ月」のドリフトを構造的に防ぐ。

7. Confirmation

• 検証手段: 自社テナントで③電子取引をシャドー運用し、(a) 取込→保存→3 要素検索の成立率 (併せて外部 SaaS と自社システムの保存件数・金額合計ハッシュを毎営業日自動照合し、不一致を Slack 通知するパイプラインを Phase 0 開始時の必須実装とする)、(b) 手作業確認の割合、(c) 取引日→保存タイムスタンプの営業日数 を計測するダッシュボード。加えて (d) 取込ジョブの死活監視 (1 時間以上無応答、または「投入件数と処理完了件数の前後差分が非ゼロ」でメール / Slack 発報)、(e) tenant-0 のデータが tenant-1 のクエリで取得されないことを検証する CI テスト＋並行テナント負荷下のテナント ID ランダム混入ファジングテスト、(f) 突合パイプライン自体の watchdog (盲点6) を独立ランタイム (GitHub Actions scheduled workflow または cron-job.org) で実装し、パイプライン最終成功タイムスタンプが 2 時間以上更新されない場合にアラート発報。
• 実行頻度: (a)〜(c) 月次 (dogfood 期間)・(a) 突合は毎営業日、(d) リアルタイム、(e) CI 毎実行 (PR 単位)・ファジングは顧客テナント追加前と月次、(f) 2 時間粒度の常時監視。
• 違反時対応: KPI 未達のとき撤退条件に照らしスコープを再評価する (判定は §6 の外部レビュアーが行う)。突合不一致は 2 営業日以内に原因特定・是正する。(c) が基準内かつ (a) 100% を満たすまで自社への cutover を行わない。(e) 静的 CI < 100% またはファジング不合格なら顧客テナント追加を凍結する。(f) watchdog アラート発報時は即時に突合パイプラインを復旧し、停止期間中の差分を遡及照合する。
• 観測可能 KPI: (a) 保存・検索成立率 100% かつ外部 SaaS との突合差分 = 件数 0・金額合計ハッシュ一致 (手動補正記録が紐づくもの・OCR ばらつきや丸め起因で補正記録により説明可能なものは突合対象から除外) / (b) 手作業確認 ≤ 20% (工数 8 割減) / (c) タイムスタンプ ≤ 7 営業日 / (d) 取込ジョブ無応答・件数差分アラート 0 件 / (e) テナント分離 CI 合格率 100% ＋ ファジング合格 / (f) watchdog アラート 0 件 (停止検知時は遡及照合完了まで cutover 凍結)。

8. 参照 (References)

• 関連 ADR: ADR-0080 (Supersede 対象), ADR-0121 (補完), ADR-0108 (補完), 下流 D2〜D9 (本 ADR が前提スコープを与える)
• 関連 PR/Issue: RQ-061 (帳票要件カバレッジ 36%), RQ-088〜093 (JTBD-012 計画群), Google Issue #36763062 (GAS フィルタ再評価行ずれ)
• 外部資料: 国税庁 電子帳簿保存法 FAQ 令和5年度版 問42 / Cloudflare Workers Pricing (Workers / R2 / D1 / Queues) / Drummond (1996) Escalation of Commitment 研究