関連ADR:ADR-0126 へ 最終更新: 2026/06/22 18:56
commonid: rq-094-record-storage-modeltype: researchstatus: active

RQ-094 Synthesis: 電帳法保存記録の置き場所 — 顧客 M365 テナント vs 自社集約（3 モデル突合）

エレベーターピッチ

  • これは何？　　: 電帳法で保存する証憑データを「顧客の Microsoft 365 の中」と「自社のクラウド」のどちらに置くべきかの調査まとめです。
  • だれのため？　: JTBD-012（証憑管理 SaaS）と管理会計プロダクトの基盤を決める人（ADR-B の判断材料）。
  • なにが起きる？: 3 つの AI が別々に調査 → 判定を出した 2 つが「自社クラウド」で一致 → 反対方向の材料も突合して決着。
  • 譲れない一線　: 顧客の業務負荷を増やさない（工数 8 割減）。顧客側に IT 設定作業を求める方式は採れない。
  • だから　　　　: 「記録の正本は自社集約（案 B）」を ADR-B の推奨として確定できます。顧客テナントへの保存は将来のミラー/エクスポート機能に格下げします。

1. 調査概要

  • Research Question: 建設・土木中小（M365 中心）向け電帳法対応 SaaS の保存記録は、案 A = 顧客 SharePoint/OneDrive 保存（ベンダーはインデックスのみ）と案 B = 自社集約保存（freee/MF/弥生型）のどちらにすべきか（調査プロンプト）。認証（マルチテナント Entra ID 決定済）と取込（Graph API 決定済）はスコープ外。
  • 実行: 2026-06-04、scripts/run_deep_research.mjs で 3 モデル並列（コスト計 ~$5.8 = claude $1.65 / gemini $1.12 / openai ~$3.0 トークン換算）
  • 回収メモ: openai (o3) はランナーの 45 分上限を超過したが response はサーバ側で継続しており、response id 直接ポーリングで全文回収（112KB・3 本中最大）
  • 生結果: openai (o3) / gemini / claude
モデル性格判定
claudeJIIMA 認証リスト・FAQ の構造分析が深い。競合 8 社の保存モデルを認証台帳と突合案 B（強い確信・構造的ブロッカー提示）
openai最大分量。法的整理（通達 10-3(2)）と運用比較が網羅的。将来オプションへの目配りあり案 B（安全な既定。A は将来のオプション扱い）
geminiA/B の判定をせず「M365 上で実装するなら」の技術深掘り（Purview 保持ラベル・Sites.Selected・throttling 対処）判定なし（A の技術的実現性を補強する材料を提供）

2. 結論

案 B（自社集約ストレージ）を ADR-B の推奨として確定する。 判定を出した 2 モデルが一致し、Gemini の技術材料も結論を覆さない（§4）。顧客テナント保存（案 A）は「将来のミラー/エクスポート機能」として温存し、法的正本にはしない。

3. 設問別の突合

Q1. 競合の保存モデル（claude が最詳・openai 同旨）

  • 調査した JIIMA 認証済み SaaS（freee ファイルボックス / Money Forward クラウド Box / 弥生 / TOKIUM / バクラク / Bill One / 楽楽精算 / 建設特化 ANDPAD 含む）は全社がベンダー管理クラウド（国内 AWS 中心）に保存。
  • 顧客自身の M365 テナントに法的保存記録を置く JIIMA 認証製品は前例ゼロ（JIIMA サイト + 国税庁ミラーリストで確認）。
  • バクラクの「認定タイムスタンプ付与データはサービス上から削除できない仕様」が示すとおり、「システムによる訂正削除防止」はベンダーがストレージ層を握っているから主張できる。

Q2. 顧客テナント保存の法的可否（最重要論点）

  • 合法ではある: 取扱通達 10-3(2) の「サービス提供者との契約による訂正削除防止」経路で電帳法自体は充足可能（openai が整理）。
  • しかし JIIMA 認証と構造的に非互換: JIIMA FAQ は「ユーザー側の運用（事務処理規程等）に依存する製品」を認証対象外とする。顧客の Global Admin が記録を消せる・設定を変えられるテナント内保存は、製品単体の機能として法的要件充足を主張できず、認証パスがない（claude）。
  • JIIMA 段階取得を計画する本プロダクト（[[project_jtbd012_voucher_productization]]）にとって、認証パスの不在は実質的な K.O. 要因。

Q3. 顧客側の需要（claude・openai 一致）

  • 建設中小に「データは自社テナントに置きたい」という明示的需要のエビデンスは見つからない。
  • 建設業は IT リテラシーが国内最低層（中小機構: 社長の理解度が低い率 31.7% vs 全国平均 17.2%）。調達の決め手はコスト（52.9%）・同業の前例（30.7%）・ベンダーのセキュリティ認証（ISMS/P マーク）— いずれもベンダークラウド型に有利。

Q4. 運用トレードオフ（案 A の構造的脆弱性）

  • SharePoint/OneDrive のごみ箱保持は既定 93 日・M365 データ損失の 70% はエンドユーザー操作・Microsoft の SLA は可用性でありデータ完全性ではない（shared responsibility）→ 7 年保存の器として顧客テナントは構造的に脆弱。
  • Graph API のスロットリングはプラン課金で引き上げ不可。ベンダー側の運用負荷（顧客ごとの権限設定・バックアップ責任の曖昧化・eDiscovery 干渉・M365 解約時の引越し）が積み上がり、顧客工数 8 割減の絶対制約と矛盾する顧客側 IT 作業も発生する。

4. モデル間の対立点と決着

論点claudegemini決着
顧客テナントでの訂正削除防止Global Admin が消せるので不成立Purview 保持ラベルで 7〜10 年のシステムレベルロックが可能技術的にはロック可能だが、保持ポリシー自体が顧客テナントの管理権限下にあり「製品が独立に保証する」構造にならない → JIIMA 認証パス不在（Q2）は覆らない。さらに Purview の本格運用は E5 級ライセンス・顧客側設定を要し、工数 8 割減と非両立
Graph throttling引き上げ不可 = 構造的制約Retry-After + 指数バックオフ + Sites.Selected で設計対処可能取込側（A/B 共通）には Gemini の対処が有効。保存正本を顧客テナントに置く理由にはならない

Gemini も「JIIMA 認証取得が SaaS のデファクトとして定着していく」ことは認めており、3 モデル間に結論レベルの矛盾はない。

5. 判断材料の優先度

  • Must-have（これだけで決まる）: ①JIIMA 認証の前例ゼロ + FAQ のユーザー運用依存除外（Q2）②顧客工数 8 割減との矛盾（Q4 の顧客側設定要求）
  • Should-have（補強）: ③競合全社がベンダークラウド = 調達側の期待形成済み（Q1）④自社テナント需要のエビデンス不在（Q3）⑤93 日ごみ箱・shared responsibility（Q4）
  • Nice-to-have: ⑥将来の差別化オプションとして「顧客テナントへのミラー/エクスポート」（openai 提案）— 正本でなく複製なら認証問題を回避できる

6. ADR-B への含意

  1. **記録の正本 = 案 B（自社集約）**で起案する。却下済みの案 C（GAS 単体→後で載せ替え）に続き、案 A-M365 も「JIIMA 認証パス不在 + 工数 8 割減矛盾」で K.O. 構造。
  2. マルチテナント Entra ID 認証（決定済の固定制約）とは独立で両立 — サインインは顧客の M365、データは自社集約、取込は Graph API という分担。
  3. 営業上の説明: 「御社の M365 アカウントでそのまま使え、データは国内・認証取得済みの当社クラウドで法令準拠を自動化」（openai の推奨文言を流用可）。
  4. 将来オプション: 顧客テナントへのミラー/エクスポートは Phase 後期の付加価値機能として TODO に記録（正本は動かさない）。

参照

  • 生結果 3 本（上記リンク）と各レポート内の一次資料（国税庁 取扱通達 / JIIMA 認証リスト / 各社セキュリティホワイトペーパー / 中小機構調査）
  • 関連: JTBD-012 計画・ADR-B（記録の置き場所決定・本 synthesis が根拠）・ADR-0108（M365/Entra 顧客アクセス検討）