プロダクトが対応するまでの流れ ── 5 ステップの実装フロー

2026/05/01

プロダクトが対応するまでの流れ ── 5 ステップの実装フロー

ここからは具体的な実装フローです。SaaS プロダクトに電帳法対応機能を組み込む、という前提で書きます。各ステップで何を判断し、何を実装するか。設計判断のポイントを押さえておくと、要件の追加に備えやすくなります。

flowchart TD
    S1[Step 1: スコープ判定<br>自社プロダクトが扱うデータを<br>3 区分にマッピング] --> S2
    S2[Step 2: 真実性確保の方式選択<br>4 択から実装方式を決める] --> S3
    S3[Step 3: 可視性の実装<br>検索 3 項目 + ダウンロード提供] --> S4
    S4[Step 4: 規程・利用規約への反映<br>事務処理規程テンプレ提供 / 利用規約改定] --> S5
    S5[Step 5: JIIMA 認証検討<br>取得するか、独自に説明するか]

Step 1：スコープ判定

自社プロダクトが扱うデータを、第 3 章の区分判定フローに照らして仕分けます。

実例：請求書管理 SaaS の場合

プロダクト機能	扱うデータ	該当区分
請求書発行（自社控え保存）	自社が作成したデータ	① 電子帳簿等保存（任意）
請求書受領・取り込み（メール / API 経由）	取引先から電子授受したデータ	③ 電子取引データ保存（義務）
紙請求書のスキャン取り込み	紙書類をスキャンしたデータ	② スキャナ保存（任意）

機能単位で仕分けすると、どの機能を最優先で電帳法対応すべきか が見えてきます。③ の機能は法令義務なので最優先、① ② は任意なのでビジネス判断で決められます。

Step 2：真実性確保の方式選択

第 4 章で見た 4 択から、自社プロダクトの設計思想に合うものを選びます。SaaS プロダクトでよく採られる選択肢は次の 2 つです。

選択肢 A：タイムスタンプ方式（②）

TSA（時刻認証局）と契約し、ユーザーがアップロードしたデータに対してタイムスタンプトークンを付与
検証用の API も整備（一括検証要件）

[ユーザーアップロード] → [TSA にトークン要求] → [トークン付与] → [保存]

メリット：第三者性が高く、改ざん検知の仕組みとして説明しやすいデメリット：TSA との契約コスト、付与期間（おおむね 7 営業日以内）の運用設計が必要

選択肢 B：訂正削除履歴保存方式（③）

すべてのデータ操作に履歴を持たせる（イベントソーシング、または論理削除＋更新履歴テーブル）
ユーザーが UI から見えるのは最新版だが、内部的にはすべてのバージョンを保持

[ユーザーアップロード] → [v1 として保存]
[ユーザー編集]       → [v2 として保存（v1 は履歴に残る）]
[ユーザー削除]       → [削除フラグ + 削除イベントを履歴に保存]

メリット：実装がプロダクト本体で完結、ユーザー追加負担なしデメリット：データ量増加、履歴管理の正確性担保が責任になる

実務では 選択肢 B が主流です。クラウド SaaS の特性とも噛み合います。

Step 3：可視性の実装

検索機能を実装します。最低限必要なのは 取引年月日・取引金額・取引先 の 3 項目検索。

// 例: 検索インターフェース
interface TransactionSearchParams {
  // 必須3項目
  transactionDate?: { from?: Date; to?: Date };  // 範囲指定対応
  amount?: { min?: number; max?: number };       // 範囲指定対応
  counterparty?: string;                          // 取引先

  // 組合せ検索（AND）
  // → 上記を複数指定すれば AND 検索になる実装にする
}

ダウンロード提供機能は 必須レベルの機能 として作っておくべきです。これがあれば範囲指定・組合せ検索を作り込まなくてよくなり、実装コストが下がります。CSV / ZIP / JSON のいずれかで税務調査時に提供できる仕組みを作っておきましょう。

Step 4：規程・利用規約への反映

実装だけでは「対応」になりません。運用面の整備 も必須です。

事務処理規程テンプレートの提供：選択肢 A（タイムスタンプ方式）を採る場合、ユーザー側で事務処理規程を整備してもらう必要があるケースがあります。テンプレートを提供すると導入摩擦が下がります。
利用規約・プライバシーポリシーへの追記：訂正削除履歴を保存する旨、データのダウンロード提供機能がある旨を明記
ヘルプ記事の整備：検索方法、ダウンロード方法、税務調査時の対応手順を文書化

Step 5：JIIMA 認証の検討

JIIMA 認証は任意ですが、エンタープライズ顧客向けの説得力が大きく変わります。第 8 章で詳しく扱います。

まとめ

まず Step 1 で機能単位のスコープ判定。義務範囲（③）を最優先
Step 2 はクラウド SaaS なら訂正削除履歴方式（選択肢 B）が主流
Step 3 のダウンロード提供機能はどの規模を狙うにしても作っておく
Step 4 の運用整備（規程・規約・ヘルプ）まで含めて初めて「対応」と言える

次章では、ここまでの実装をどこまでやれば「対応済み」と説明できるか、対応レベル 0〜4 の自己診断軸 で整理します。