ADR-0126: 法的保存記録の正本を自社集約ストレージに置く

• Status: Proposed
• Mode: Critical
• Kruchten Type: Existence/Executive
• Scope: product
• Implementation Status: Not Started
• 起案者: [email protected]
• 起案日時 (JST): 2026-06-08 16:16
• 承認日時 (JST): -
• Deciders: [email protected] (単独)

コンテキスト

§1.1 背景

JTBD-012(電子帳簿保存法対応の証憑管理 SaaS)を自社 = tenant-0 として dogfood し、汎用版・本番アーキで構築する方針が ADR-0125 で確定した。残る load-bearing な未決事項が「法的保存記録(国税関係書類)の正本をどこに置くか」である。選択肢は案 B = 自社集約ストレージ(freee/Money Forward/弥生型)vs 案 A = 顧客の Microsoft 365 テナント(SharePoint/OneDrive)保存。

RQ-094(3 モデル Deep Research synthesis、PR #1434 マージ済)で判定 2 モデル(claude/openai)が案 B で一致。

§1.2 現状 (As-Is)

JIIMA 認証は「製品のマニュアル等のみで評価し認証する」制度で、認証基準・機能チェックリスト(令和5年改正版)が公開されている。認証製品一覧(公開)を突合すると、freee・マネーフォワード(クラウド Box 等5サービス)・弥生・バクラク・TOKIUM・Bill One・楽楽精算等が 案 B のパターン(ベンダークラウドにマルチテナントで集約・ベンダーがタイムスタンプ付与・検索要件を自動充足)で電子取引/電子帳簿の認証を取得済み。逆に顧客テナント(案 A)を正本とする認証製品は突合 8 社で 0 件、JIIMA FAQ は「ユーザー側の運用に依存する製品」を認証対象外と明記。SharePoint ごみ箱は既定 93 日・M365 データ損失の 70% はユーザー操作起因。

§1.3 課題

電帳法の 7 年(最長 10 年)保存の器として、顧客 M365 テナントは構造的に脆弱である。一方、自社集約に倒すと「他社の機微データを預かる責任の確定」「マルチテナント越境バグの全顧客同時影響」「単一障害点化」「dogfood 段階の第三者性欠如」等の固有リスクが生じ、いずれを正本レイヤとするかを load-bearing に確定する必要がある。

§1.4 制約・要件

• JIIMA 認証パスが存在する保存方式であること(Must、K.O. 軸)
• 顧客側の恒常的 IT 運用作業ゼロ(Must、K.O. 軸)
• テナント分離・国内保存・データ越境禁止(論理分離選択時は越境防止メカニズムを必須化)
• **電帳法施行規則第 4 条「速やかな提示・提出義務」**を税務調査時に充足できる可用性
• 総務省認定第三者 TSA 利用(dogfood 段階含む)

§1.5 目標 (To-Be)

法的保存記録の正本を自社集約ストレージに置き、JIIMA 認証パスを確保しつつテナント分離原則・国内保存・第三者 TSA・DR 要件を本方針で固定する。Non-Goals: テナント分離方式(silo/pool/bridge)の最終選定、コンピュート基盤選定、規模実測(いずれも RQ-092 後続の実装 ADR で確定)。

決定

法的保存記録の正本を自社集約ストレージに置く(案 B)。顧客テナント(SharePoint/OneDrive)には正本を置かない。あわせてテナント分離の原則を「全データにテナント ID スコープを貫通させる論理分離 + 国内リージョン保存 + テナント越境禁止」として固定する(方式 silo/pool/bridge の選定と規模実測は RQ-092 の調査後に実装 ADR で確定)。将来オプションとして「顧客テナントへのミラー/エクスポート(正本は動かさない複製)」を Phase 後期候補として記録し、ベンダーロックイン懸念への回答とする。

#suitable(JIIMA 認証パス存在)は採択前に公開情報で一次確認する: ①公開の機能チェックリスト(令和5年改正版)に自社設計を当てて適合マトリクスを作成し保存方式起因ブロッカー 0 件を確認、②認証製品一覧で案 B パターンの認証実績を引用。JIIMA は完成品をマニュアルで審査する制度でありアーキ構想への事前裁定は出さないため、書面照会をハードゲートにはしない。案 A(顧客テナント + Purview)の認証適否という案 A 固有の論点のみ JIIMA 事務局へ書面照会し、年次レビューで継続監視する。dogfood 段階では tenant-0=自社のため保存義務者とベンダーが同一であり後述の法的非対称リスクは当面顕在化しないが、第三者性・可用性・越境防止は本番顧客を待たず設計段階で固定する。

判断基準 (Decision Drivers)

3.1 評価軸

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

3.2 評価軸 × 案スコア表

加重和は K.O. 通過候補のタイブレーク用。案 D は 0.864 で案 B を僅差上回るが、初期スコープでは設計・運用複雑度が過剰のため将来オプションへ縮退(§4 参照)。

検討した代替案 (Alternatives Considered)

• 案 A(顧客 M365 テナント保存・ベンダーはインデックスのみ): JIIMA 認証パス不在(Must①、突合 8 社で顧客テナント正本の認証 0 件)+ 顧客側 IT 運用作業の恒常要求(Must②)で二重 K.O.。gemini が示した「Microsoft Purview 保持ラベルで 7〜10 年のシステムレベルロックは技術的に可能」は事実だが、保持ポリシー自体が顧客テナントの管理権限下にあるため「製品が独立に法的要件充足を保証する」構造にならず、認証パス不在の結論を覆さない(RQ-094 synthesis §4 に決着記録済)。
• 案 C(GAS 単体で開始→後で SaaS へ全面載せ替え): 却下済。稼働中顧客の電帳法保存データを後から引き剥がす移行が青色申告承認取消リスクを生む。記録として残す。
• 案 D(ハイブリッド: 正本自社 + 顧客テナントへ常設ミラー): 加重和 0.864 で案 B を僅差上回るが、初期スコープでは設計・運用複雑度が過剰。将来オプション(本方針の将来注記)に縮退して部分採用。

影響 (Consequences)

§5.1 正の影響 (Good)

• JIIMA 認証パスの確保(案 B パターンの認証実績で裏付け済)。
• 営業説明「サインインは御社の M365、データは国内の認証取得済み当社クラウドで法令準拠を自動化」が成立。
• GAS は社内・プロトタイプ用途に専念。
• テナント分離原則・国内保存・第三者 TSA・DR 要件を本方針で固定したことで後続実装 ADR の設計空間が明確化。

§5.2 負の影響 (Bad)

• 他社の機微データ(証憑・会計)を預かる責任が確定 → ISMS(ISO/IEC 27001)/P マーク等の第三者認証取得が信頼の前提。初回取得は審査申込から 6〜12 か月、準備期間込みで中小 SaaS では 18 か月超になるケースもある。取得完了前のリリース可否を撤退条件で拘束する(取得前に契約を受ける場合の代替保証 = SOC 2 Type I・ペネトレーションテスト報告書の開示で補完。ただし SOC 2 Type I は Point-in-time の設計評価で運用有効性は保証しない)。
• 保存義務者(顧客)と保存場所管理者(自社)の法的分離による責任非対称: 電帳法において国税関係書類の保存義務者は課税事業者(顧客)であり、委託しても義務は移転しない(国税庁 Q&A 問 42)。案 B では自社がストレージの可用性・完全性・アクセス制御を一元管理するため、障害・サービス終了・アカウント停止のいずれの場合でも「顧客が保存義務を履行できない状態」を自社判断で作り出せる構造になる。「税務調査対応時の証憑提示 SLA」「自社事業継続不能時の第三者エスクロー or 顧客データ移管義務」「保存期間中の一方的サービス条件変更の制限」を標準契約書のドラフト要件として法務レビュースコープに含める(盲点 #4)。
• ISMS 取得審査中に大口顧客が ISO/IEC 27001 取得済みを契約条件として要求し、例外承認上限 2 回消費後に新規受注が事実上停止するリスク(SOC 2 Type I は point-in-time 評価のため運用有効性継続保証を求める顧客には不十分・盲点 #8)。

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

リスク(緩和機構を本方針に内包):

• マルチテナント論理分離のバグ → クロステナント漏洩(電帳法違反 + 個情法違反の同時成立)。緩和: テナント ID フィルタを DB 層(RLS 等)で強制するか silo 方式でスキーマを物理分離するかを実装 ADR 起案前に確定し、論理分離選択時はクロステナントクエリ自動テストを CI/CD 必須要件とする。
• 自社集約の単一障害点化。インフラ障害・ランサムウェアが全顧客に同時波及するブラストラジウスは案 A より大きく、電帳法施行規則第 4 条「速やかな提示・提出義務」が税務調査と重なると顧客が義務を履行できない。AWS us-east-1 の 2017 年 2 月 S3 障害(約 4 時間)、GCP 2023 年 5 月マルチリージョン障害では冗長構成済 SaaS でも復旧まで 4〜8 時間を要したケースが報告されている(盲点 #1)。緩和: RTO 4 時間以内・RPO 1 時間以内を最低目標とし冗長構成(マルチ AZ・クロスリージョンレプリカ等)を実装 ADR の DR 設計でブロッカー要件とする(値・法的根拠は実装 ADR 起案前に法務レビューで精緻化)。
• 証憑-仕訳紐付けインデックス破損による全顧客同時の電帳法施行規則第 4 条違反(盲点 #6)。緩和: 実装 ADR 起案前に「正本ファイル書き込みとインデックス登録を同一トランザクション境界で保証する方式(例: Saga 補償トランザクション・Outbox パターン)」を設計必須要件として明記し、インデックス-ファイル整合性の自動検証ジョブを CI/CD および日次バッチで実行することを Confirmation 項目に追加(§Confirmation ⑥)。
• 第三者 TSA API 長時間停止によるタイムスタンプ付与待ち証憑の「保存要件未充足」滞留(電帳法は「受領後速やかに(概ね 2 営業日以内)」のタイムスタンプ付与を要求、総務省認定 TSA は国内数社に集中・2023 年セイコーソリューションズ仕様変更例あり・盲点 #7)。緩和: 実装 ADR に「TSA 障害時のフォールバック TSA 自動切替」「タイムスタンプ付与待ち queue 滞留件数アラート(閾値: 受領から 24 時間超)」「顧客向け障害通知 SLA の定義」を必須設計要件として追記し、TSA 契約を複数社と締結することを調達要件に加える。
• 国内リージョン保存の設定ミスで海外複製 → 個情法 24 条違反。緩和: 国内リージョン固定の技術的制御(SCP によるリージョン制限・バケットポリシー・レプリケーション無効化)と監査ログ取得を RQ-092 完了を待たず本方針で実装必須要件とする。
• dogfood 段階の第三者性欠如(保存義務者 = 自社 = タイムスタンプ付与者)で正本の証拠能力を争われるリスク。緩和: dogfood 段階でも証憑のタイムスタンプ付与は総務省認定の第三者 TSA 経由に固定し、第三者性を JIIMA チェックリスト(Confirmation ①)の必須確認項目とする。
• ISMS 取得遅延時の例外承認常態化。緩和: 例外承認の累計発出上限を 2 回までとし、例外承認後 30 日以内に取得見通しを取締役会へ報告する義務を撤退条件で明文化。
• PoC 環境への本番証憑誤投入で ISMS 未取得状態の正本保管が発生し撤退条件と矛盾。緩和: PoC 環境に本番証憑投入を検知・ブロック/管理者アラートする技術的ゲート(ファイルメタデータ・取引日付検査等)を実装必須とし、誤投入時の法務エスカレーションをフェーズ別保全表に追加。
• 「案 A 前例ゼロ」根拠の陳腐化 + サンクコスト確証バイアスで方針転換が阻害される。緩和: 年次レビューの実施責任者を代表取締役とし、再評価判断時に「既存投資額」を判断材料に参照することを明示的に禁止する。
• 撤退条件「ISMS 取得前リリース禁止」発動時の顧客データ返却手順の不在(案 C 却下理由と対称)。緩和: フェーズ別保全手順を本方針で拘束 — ①PoC 中(本番証憑投入前)はテストデータのみで通常削除 ②パイロット中(本番投入後)は電帳法準拠形式(原本 + メタデータ + タイムスタンプ)でフルエクスポート → 受領確認書面取得後に削除 ③本番後は同手順 + 撤退前 90 日の事前通知 + 移行先選定支援。「ISMS 取得断念」シナリオは法務レビューの上、実装 ADR で確定。
• GAS の 6 分実行時間制限による dogfood 段階の証憑取込・月次バッチ強制終了(PropertiesService は 1 プロパティ 9KB・全体 500KB 上限・盲点 #2)。緩和: dogfood 段階で GAS が実行するバッチ処理の最大件数・最大実行時間を実測し 6 分制限抵触シナリオを洗い出し、抵触確認時は Cloud Run Jobs 等への切替判断基準を実装 ADR 起案前に明文化(Confirmation ⑦)。
• Cloudflare Workers の 30 秒 wall time / 50 件 subrequest 上限による証憑保存フロー打切り(PUT → TSA → DB INSERT → インデックス → 監査ログの 5 ステップ連鎖・盲点 #3)。緩和: コンピュート基盤候補に Workers が含まれる場合、証憑保存フローの最大 subrequest 数・最大 wall time を設計段階でカウントし制限値との比較表を RQ-092 成果物に含める(Confirmation ⑧)。
• JIIMA 認証取得後のアーキ変更(保存先・TSA・テナント分離方式)による認証失効リスク(取得後に方式変更 → 再審査 → 不合格となれば既存顧客契約の表明保証違反が生じうる・盲点 #5)。緩和: JIIMA 認証維持要件(変更時の再審査トリガ条件)を JIIMA 事務局への書面照会スコープに追加し、テナント分離方式の確定(RQ-092)を JIIMA 認証申請の前提条件として撤退条件に明記。
• 案 B パターン認証実績への帰納的根拠過信による個別機能ブロッカー発見遅延(認証は「マニュアル等のみで評価」のため通過要因が「保存方式」か「個別機能実装」かを区別不能・先行各社は長期運用実績を経て認証取得・盲点 #9)。緩和: JIIMA 機能チェックリスト全項目に対して「設計レベルで適合」「実装で証明が必要」「未確認」の 3 段階で分類した適合マトリクスを作成し、「実装で証明が必要」項目を実装 ADR のブロッカー要件として明示(Confirmation ① 完了条件)。工数見積は 0.5 人日から最低 2 人日に見直す。

撤退条件 (Rollback Plan)

• JIIMA 認証申請で保存方式起因の不適合が 2 回連続 → 保存方式を再評価する ADR を起案(本方針を Supersede)。
• JIIMA 審査基準改訂で「顧客テナント保存(Purview Compliance Lock 等)」が審査対象として認められた場合 → 案 A 系の再評価 ADR を起案(年次レビューで継続監視)。
• 初期顧客(PoC 含む)5 社中 2 社以上が「自社テナント保存が契約必須条件」と要求 → 案 D(ミラー)の前倒し実装を判断。
• 自社集約ストレージ + 監査ログ基盤の月額実費が顧客単価の 30% を超過 → アーキテクチャ再評価。
• ISMS または同等の第三者認証(代替保証含む)の整備完了前に電帳法対応機能を本番顧客へリリースしない。例外承認は代表取締役および法務責任者の書面承認なしに発出不可、累計発出上限 2 回まで、例外承認後 30 日以内に取得見通しを取締役会へ報告する。
• 例外承認 2 回消費後 60 日以内に ISMS 取得見通しが取締役会で確認できない場合 → リリーススコープを縮小する(電帳法対応機能を除外した SaaS 部分のみ先行提供)。ISMS 取得ロードマップを本 ADR 採択後 30 日以内に別文書で確定する。
• 国内リージョン制御(SCP・バケットポリシー・レプリケーション無効化)の監査ログで越境複製が 1 件でも検出 → 即時インシデント対応とアーキテクチャ再評価。
• 年次レビュー実施責任者(代表取締役)が「案 A 前例ゼロ」根拠の変化(大手 SaaS の案 A 系製品投入等)を検出 → 既存投資額を判断材料に含めず再評価 ADR を起案。
• RTO 4 時間以内が電帳法「速やかな提示義務」を満たすと判断した法的根拠を実装 ADR 起案前に法務レビューで確定すること。法務レビュー未了のまま本番リリースに進まない。
• JIIMA 認証取得後にテナント分離方式・保存先・TSA を変更する際は、再審査要否を JIIMA 事務局へ事前照会した結果を取締役会に報告するまで変更着手不可。

コスト試算

• ストレージ実費(概算): 証憑 500 枚/月・平均 500KB/枚 → 1 社 250MB/月 → 100 社 × 5 年で ~1.5TB。S3/R2 系オブジェクトストレージで月 **$25 規模**(オーダーマグニチュード推定)。保存実費は顧客単価設計の制約にならない水準。
• 冗長構成・DR サイト・監査ログ基盤の月額実費は撤退条件「顧客単価の 30% 超過」と連動して測定(具体額は実装 ADR で確定)。
• ISMS 初回取得: 審査申込から 6〜12 か月(外部基準・文献値)。準備期間込みで中小 SaaS では 18 か月超になるケースあり。SOC 2 Type I でも審査着手〜報告書発行に 3〜6 か月。
• 本方針確定が生む初期作業:
  • 公開機能チェックリストへの自己適合マトリクス作成 ~0.5 人日 → 最低 2 人日に見直し(盲点 #9 反映)。
  • RQ-092(規模・マルチテナント・DRP データの個情法分類)Deep Research ~0.5 人日 + LLM ~$6。
  • 撤退時データ保全手順の法務レビュー ~0.5 人日。
  • 標準契約書ドラフト(税務調査対応 SLA・事業継続不能時のエスクロー/データ移管・サービス条件変更制限)の法務レビュー(工数は実装 ADR で確定)。

Confirmation

• 検証手段:
  • ① 公開の JIIMA 機能チェックリスト(電子取引・電子帳簿の令和5年改正版)に本保存方式を当てて適合マトリクスを作成し、保存方式起因のブロッカー件数を測定。スコープに「証憑-仕訳紐付けインデックスの設計」「取引年月日・金額・取引先による 3 秒以内表示の実測計画」「第三者 TSA 利用の確認」を明示的に含める。あわせて認証製品一覧で案 B パターンの認証実績(参照製品)を記録する。完了条件: 全項目を「設計レベルで適合」「実装で証明が必要」「未確認」の 3 段階に分類し、「実装で証明が必要」項目を実装 ADR のブロッカー要件として列挙(盲点 #9)。
  • ② 案 A(顧客テナント + Purview Compliance Lock)の認証適否、および JIIMA 認証取得後の再審査トリガ条件(保存先・TSA・テナント分離方式変更等) を JIIMA 事務局へ書面照会し回答を記録(案 A 再評価トリガ・案 B 認証維持要件の年次監視用。案 B 採択のブロッカーではない・盲点 #5)。
  • ③ 撤退時データ返却手順(フェーズ別保全表)が実装 ADR / 法務レビューで文書化されていること。
  • ④ クロステナントクエリ自動テスト(論理分離選択時)および国内リージョン固定の監査ログが CI/CD で恒常実行されていること。
  • ⑤ PoC 環境の本番証憑誤投入検知ゲートの作動ログをパイロット移行前にレビュー。
  • ⑥ 正本ファイル書き込みとインデックス登録の整合性自動検証ジョブ(CI/CD + 日次バッチ)の合格率(盲点 #6)。
  • ⑦ dogfood 段階の GAS バッチ最大件数・最大実行時間の実測ログ。6 分制限抵触シナリオの洗い出し結果(盲点 #2)。
  • ⑧ コンピュート基盤候補に Cloudflare Workers が含まれる場合、証憑保存フローの最大 subrequest 数・最大 wall time と制限値の比較表が RQ-092 成果物に含まれること(盲点 #3)。
• 実行頻度: 本 ADR 採択前(①)/ JIIMA 申請前(①)/ 実装 ADR 起案ごと(③・⑥)/ CI/CD 毎回(④・⑥)/ パイロット移行前(⑤・⑦)/ RQ-092 完了時(⑧)/ 年 1 回(②・JIIMA 基準改訂レビュー・案 A 前例の再確認・撤退トリガ照合)。
• 違反時対応: §撤退条件の該当項目を発動。① の適合マトリクスで保存方式起因ブロッカーが検出された場合は実装前に設計を是正。⑥ の整合性検証で不一致が検出された場合は即時インシデント対応と当該テナントの提示準備状況を法務に報告。
• KPI: 保存方式起因の JIIMA ブロッカー 0 件 / 自社集約ストレージ月額実費が顧客単価に占める比率 30% 以下 / クロステナント越境検出 0 件 / 国内リージョン外への複製検出 0 件 / インデックス-ファイル整合性検証合格率 100% / TSA 付与待ち滞留(受領から 24 時間超)0 件。

参照 (References)

• 関連 ADR:
  • ADR-0125: JTBD-012 を汎用版・本番アーキの自社 dogfood で先行 — 補完(本方針はその記録正本レイヤを確定)。
  • ADR-0118(取下げ済): 共通基盤を 5 決定の束で起案していたものを RQ-097 粒度原則で分解。本方針はその決定①(法的正本)+ ④(テナント分離原則)+ ⑤(ミラー将来注記)を継承。
  • ADR-β(顧客 M365 ネイティブ統合): 並立(認証・取込レイヤを別決定として分離)。
• 関連 PR/Issue:
  • PR #1434(RQ-094 synthesis、マージ済)
  • RQ-092(silo/pool/bridge 方式選定・規模・DRP データの個情法分類の前提調査、本 ADR 後続)
  • RQ-094(記録保存方式の synthesis、案 B 確定の一次裏取り)
• 外部資料:
  • JIIMA 認証基準・機能チェックリスト(令和5年改正版)
  • JIIMA 認証製品一覧(freee・マネーフォワード クラウド Box 等・弥生・バクラク・TOKIUM・Bill One・楽楽精算)
  • JIIMA FAQ(「ユーザー側の運用に依存する製品」認証対象外)
  • 国税庁 電子帳簿保存法 Q&A 問 42(保存義務者は課税事業者)
  • 電帳法施行規則第 4 条(速やかな提示・提出義務)
  • 個人情報保護法 24 条(越境移転)
  • AWS us-east-1 S3 障害(2017 年 2 月、約 4 時間)/ GCP マルチリージョン障害(2023 年 5 月)
  • セイコーソリューションズ TSA サービス変更(2023 年)

Known Limitations / Escalated Residual Risks (HITL ratification required)

本 ADR は Cross-Validation で goalpost ループ検知 (2 連続却下・却下盲点が毎回移動) のため、自動審査を打ち切り「残余リスク付き Accept」として起票された (ADR-0109 Part4)。以下の未解決 critical 盲点は、人間レビュー (この PR の merge = 受理 / close = 却下) で最終判断すること。LLM critic による反復審査では収束しないと判定されたものであり、PR レビューが外部検証器となる。

未解決 critical 盲点:

• 自社集約ストレージが長時間インシデントに陥ると、全顧客が税務調査への証憑提出義務を同時に履行できなくなる
• 証憑-仕訳紐付けインデックスが破損すると、税務調査時に「速やかな提示・提出」が不可能になり電帳法施行規則第4条違反が全顧客同時に成立する
• 第三者TSAのAPIが長時間停止すると、タイムスタンプ付与待ちの証憑が電帳法上の「保存要件未充足」状態で滞留し、顧客が気づかないまま7年保存義務が開始される