「電子帳簿保存法に対応してください」という一文だけが案件の説明に書かれていると、何を作ればよいのか輪郭がつかみにくくなります。国税庁の一問一答を読むと、対応は検索・訂正防止・提示という3つの要件に分かれ、しかも提出への対応状況によって実装の重さそのものが変わる構造になっています。この記事では、資料に書かれている要件の内容と、それが設計のどこに落ちるのかを整理します。個々の案件が要件を満たすかどうかの判断は、クライアントと確認しながら詰めていく領域であり、この記事はその手前にある「資料は何を求めているか」を読み解く材料として使えます。

1. 「法対応」は3つの要件に分かれます

検索・訂正防止・提示という3つの柱

「電子帳簿保存法に対応してください」という依頼は、範囲がつかみにくく響きます。国税庁の一問一答を確認すると、電子取引の記録に必要な対応は、条件を指定して探し出せる検索の機能、訂正や削除の跡が残る、または防げる仕組み、そして求めに応じて記録を示せる提示という3つに分かれています¹。

3つを同時に、しかも同じ重さで満たそうとすると、設計は膨らみがちです。むしろ先に確かめるべきは、案件がこの3つのうちどこに重心を置いているかという点です。次の章から、それぞれの要件が設計のどこに接続するのかを順に見ていきます。

検索・訂正防止・提示は独立した要件ではなく、互いに影響し合う関係にあります。提示に応じられる運用を整えれば、確保が必要な検索機能の範囲は小さくなります。改ざん防止については、システムで残す方法と規程で縛る方法のどちらを取るかで、作るものと決めるものの比重が変わります。3つをそれぞれ別の作業として見積もるのではなく、どこか一つを強めることで他の負担がどう変わるのかという関係を踏まえて設計を組み立てると、後になって仕様が膨らむ事態を避けやすくなります。

図の作成：Remogu編集部。資料に示された要件の構造を整理したもので、統計データではありません

2. 検索は3つの機能に分解されています

検索の3要件が、そのまま設計要件になる理由

資料が示す検索の要件は、日付・金額・取引先を条件に指定できること、日付や金額を範囲で指定できること、複数の条件を組み合わせられることの3つです¹。この3つは抽象的な理念ではなく、検索フォームの入力項目と、それを支える索引の設計にそのまま対応します。範囲指定や組合せ条件は、単純な完全一致の検索とは異なるクエリ設計を求めるため、着手前にどこまでの検索を用意するかを確認しておくと、実装の手戻りを避けやすくなります。

要件	資料の内容	設計上の意味
日付・金額・取引先での検索	取引年月日その他の日付、取引金額、取引先を検索の条件として設定できること	検索フォームの入力項目として用意する対象
範囲指定	日付又は金額に係る記録項目は、その範囲を指定して条件を設定できること	期間や金額の範囲を扱うクエリの設計
組合せ条件	二以上の任意の記録項目を組み合わせて条件を設定できること	複数条件を組めるフォームと索引の設計

組合せ条件を扱う検索は、単一項目ごとのインデックスだけでは応答が遅くなりやすい部分です。取引先や日付のように組み合わせて使われやすい項目をあらかじめ想定し、複合インデックスや検索専用のテーブルを用意しておくと、データ量が増えた後の性能劣化を抑えやすくなります。範囲指定についても、日付型・金額型それぞれで境界値の扱いを揃えておくと、後からの仕様変更に強くなります。

検索の要件が固まったあとは、実際に条件を組み合わせて動かしてみる確認の工程も欠かせません。単体のテストでは通っても、大量データや複数条件を重ねたときに応答が遅れる、あるいは想定した組合せが漏れているといった問題は、実データに近い量で確認して初めて見えてくることが多いためです。

この3つの機能をどこまで自前で用意する必要があるかは、次の章で扱う提出への対応状況によって変わります。

3. 提出に応じられるかで、実装の重さが変わります

ダウンロードの求めに応じられれば、検索機能を絞れる

検索の3要件は、条件次第で軽くなります。税務職員による質問検査権に基づくダウンロードの求めに応じられるようにしている場合、範囲を指定する機能と、複数条件を組み合わせる機能の確保は不要になります²。

3つの機能をすべて実装することよりも、ダウンロードの求めに応じられる運用を整えることのほうが、実装コストを抑えられる場合があります。どちらの道を選ぶかは、案件の要件定義の段階でクライアントと確認する部分です。

ダウンロードの求めに応じられる運用を整える場合は、対象期間の切り出し方やデータの出力形式をどう用意するかという、検索機能とは別の検討が生じます。検索機能を軽くする代わりに、抽出と出力の仕組みをどこまで自動化するかが新たな論点になるため、どちらの負担を小さくしたいのかを案件の早い段階で整理しておくと選択がぶれにくくなります。

どちらの要件が適用されるかは、事業の状況によって年をまたいで変わることがあります。設計を一度決めて終わりにするのではなく、前提となる条件が変わったときに実装の重さを見直せる余地を残しておくことも、長く使われるシステムでは意味を持ちます。

図の作成：Remogu編集部。資料に示された要件の緩和の段階を整理したもので、比率を表すものではありません

この段階のどこに立つかによって、見積もりに含める作業の中身は大きく変わります。要件定義の初期段階で立ち位置を確認しておくことが、後工程での認識のずれを防ぐ近道になります。

4. 規模によって要件が変わります

売上高や提示の運用によって、検索機能そのものが不要になる場合

要件はさらに緩む場合があります。判定期間の基準期間における売上高が5,000万円以下の事業者、または電磁的記録を出力した書面を取引年月日や取引先ごとに整理して提示・提出できるようにしている事業者については、検索機能の確保そのものが不要になります³。

この条件に該当するかどうかは事業者ごとの判断であり、クライアントと確認しながら要件の適用範囲を詰める領域です。設計側としては、検索機能を作り込む前提そのものが変わりうることを踏まえて、要件定義の初期にこの分岐を確認しておくと手戻りが小さくなります。

条件	緩和される内容
ダウンロードの求めに応じられるようにしている場合	範囲指定と組合せ条件の検索機能の確保が不要
基準期間における売上高が5,000万円以下の場合	検索機能の確保そのものが不要
出力書面を取引年月日・取引先ごとに整理して提示・提出できる場合	検索機能の確保そのものが不要

売上高基準に該当するかどうかは、経理や税務の担当と確認しながら詰めるものであり、設計側だけで判断できる分岐ではありません。要件定義の早い段階でこの確認を挟んでおくと、検索機能の実装範囲が後から変わる事態を避けやすくなります。出力書面による提示・提出の運用を選ぶ場合も、書面の整理方法自体が要件の一部になる点は押さえておきたいところです。

売上高による緩和と、出力書面の整理による緩和は、それぞれ別の条件です。片方に当てはまらないからといって、もう片方も同時に外れるとは限らないため、資料を確認するときはこの2つを一つの条件として混ぜずに、それぞれの成立要件を分けて確認しておくと読み違えにくくなります。

5. 改ざん防止は「システム」か「規程」かの2通り

システムで自動的に記録する方法

改ざん防止の一つは、訂正や削除を行った場合に、訂正前・削除前の記録事項と内容が、別の電磁的記録である履歴ファイルに自動的に記録されるシステムを使う方法です⁵。「自動的に記録される」が要点であり、手作業でログを残す運用とは区別されます。

この方法を選ぶ場合、誰が・いつ・どの記録を変更したかを追跡できるログ設計と、そのログ自体を書き換えられない形で保持する仕組みが、あわせて必要になります。履歴ファイルへの記録が確認できて初めて、改ざん防止の要件を満たす設計として成立します。

規程で運用を縛る方法

もう一つの方法は、正当な理由がない訂正及び削除の防止に関する事務処理の規程を定めて運用することです⁴。システムに手を入れずに整備できる点は選びやすさにつながりますが、どこまで整備すれば足りるかは事業規模等を踏まえて個々に検討する必要があります⁴。

方式	内容	整備・運用の考え方
システムで自動記録	訂正・削除前の記録事項と内容を、別の電磁的記録である履歴ファイルに自動的に記録	履歴データの保持と照会の機能が要件になる
規程で運用を縛る	正当な理由がない訂正及び削除の防止に関する事務処理の規程を定めて運用	整備範囲は事業規模等を踏まえて個々に検討する

2つの方式は、どちらか一方だけを選ばなければならないものではありません。既存のシステムに手を入れやすい案件であればシステム側の対応を厚くし、システムの変更が難しい案件であれば規程の整備を厚くするというように、案件の制約に合わせて重みづけを変える発想が実務的です。

図の作成：Remogu編集部。資料に示された改ざん防止の2つの方法を整理したもので、優劣を示すものではありません

規程で運用を縛る方法を選ぶ場合も、規程を定めるだけでなく、実際に守られているかを確認できる運用の仕組みをあわせて考えておくと、整備の実効性を保ちやすくなります。承認フローの記録や変更履歴の保持など、システム側でも規程の運用を支える工夫の余地があります。

規程を整えることよりも、その整備がどこまで実効性を持つかを検討することのほうが、資料が求めている姿勢に近いといえます。次の章では、この2つの方法とあわせて確認しておきたい時間の要件を見ていきます。

6. 時間の要件と、猶予措置の読み方

タイムスタンプは「速やかに」が原則

タイムスタンプの付与についても確認しておきたい要件があります。「速やかに」付与することとしている場合、やむを得ない事由によりおおむね7営業日以内に付与できない特別な事由があるときは、その事由が解消した後に直ちに付与すれば「速やかに」付与したものとして扱われます⁶。

この扱いはあくまで特別な事由がある場合のものであり、おおむね7営業日以内であればどのような状況でも受け入れられるという意味ではありません。設計としては、通常時の運用と、事由が生じたときの扱いを分けて用意しておくと、資料の趣旨に沿いやすくなります。

バッチ処理でタイムスタンプをまとめて付与する設計にしている場合、通常の運用枠に収まらない事由が生じたときに、再実行や遅延の扱いをどう記録として残すかも、あわせて設計しておきたい点です。通常時と例外時を同じ経路で処理してしまうと、あとから状況を追いにくくなります。

出典：国税庁「電子帳簿保存法一問一答【電子取引関係】」（2025年6月）をもとに作成

猶予措置は保存の免除ではない

令和6年1月1日以後の電子取引については、税務署長が相当の理由があると認め、税務調査等の際に電子データおよび出力書面の提示等に応じられる場合に限り、保存時に満たすべき要件を満たしていなくても保存が可能になる猶予措置があります⁷。

ここで見落としやすいのは、猶予措置が出力書面のみの保存を認めるものではないという点です。電子データそのものを保存し、求めがあれば提示・提出できる状態を保つことが前提になっており、要件の確認そのものを省いてよいという読み方はできません⁷。

猶予措置の適用を検討する場合も、案件としては電子データの保存先や提示までの導線を止めない設計が前提になります。書面だけを整えて満足する設計にならないよう、電子データの保存経路を要件の中心に置いておくことが大切です。

これまで見てきた検索・訂正防止・時間の3つの要件と、猶予措置は別の階層にある話です。猶予措置は要件を満たしていない場合の救済であり、要件そのものを置き換えるものではないため、設計の起点は引き続き検索・訂正防止・提示の3要件に置いておくのが安全です。

ここまでの内容は、資料に書かれている要件の輪郭を整理したものです。個々の案件がどこまで当てはまるかは、要件定義の場でクライアントと一つずつ確認しながら詰めていく作業になります。

7. よくある質問

電子帳簿保存法の対応を求める案件では、具体的に何を作ることが多いですか

案件によって範囲は異なりますが、検索の条件指定、訂正削除の履歴管理、提示や提出に応えるための出力といった機能が、要件定義の段階で話題に上がりやすい部分です。どこまでを自前で実装し、どこから運用でカバーするかは、クライアントと要件を確認しながら決める部分です。設計の初期段階でこれらの機能がどこまで必要かを整理しておくと、見積もりの精度も上がります。

猶予措置がある場合、対応を後回しにしてよいですか

猶予措置は、税務署長が相当の理由を認め、税務調査等で電子データと出力書面の提示等に応じられる場合の扱いです⁷。出力書面のみを保存する運用は認められておらず、電子データそのものを保存し提示できる状態を保つ必要があるため、要件の確認そのものを省ける措置ではありません。要件確認を後回しにするための措置ではなく、確認と並行して検討する前提の措置だと捉えておくと読み違えにくくなります。

改ざん防止の要件は、システムと規程のどちらを選べばよいですか

資料は、履歴を自動的に記録するシステムを使う方法⁵と、正当な理由がない訂正及び削除の防止に関する事務処理の規程を運用する方法⁴の両方を挙げています。どちらを選ぶか、どこまで整備するかは事業規模等を踏まえて個々に検討する部分であり、クライアントとの協議で詰めていく領域です。どちらか一方に決め切る前に、案件の規模や既存システムの構成を踏まえて比較する余地があります。

タイムスタンプの付与が7営業日を超えると、問題になりますか

おおむね7営業日以内という目安には、特別な事由がある場合の扱いが用意されています⁶。ただしこれは例外的な場合の扱いであり、通常時の運用として7営業日を超えてよいという意味ではありません。通常時と例外時の扱いを分けて設計しておくことが大切です。スケジュール設計の段階で、通常時の締切と例外時の扱いを別々の項目として明文化しておくと、運用時の判断がぶれません。

電子帳簿保存法に関わる案件は、リモートで進めやすいですか

要件の読み解きや設計の整理が中心になる工程が多く、対面での作業が前提になりにくい領域です。Remoguでは、案件の90%以上がフルリモート可能です⁸。ただし常駐の有無や協議の頻度は案件によって異なるため、条件は個々に確認する形になります。要件の読み解きに時間を割きたい工程ほど、リモートでの進行との相性は良い傾向があります。

検索の3要件は、すべての案件で実装する必要がありますか

案件によって異なります。ダウンロードの求めに応じられる運用を整えている場合は範囲指定と組合せの機能が不要になり²、売上高や出力書面の運用が条件に当てはまる場合は検索機能の確保そのものが不要になります³。着手前にどの条件に当てはまる案件なのかを確認しておくと、実装範囲の見通しが立てやすくなります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 国税庁「電子帳簿保存法一問一答」電子取引関係（2025年6月）
＊2 国税庁「電子帳簿保存法一問一答」電子取引関係（2025年6月）
＊3 国税庁「電子帳簿保存法一問一答」電子取引関係（2025年6月）
＊4 国税庁「電子帳簿保存法一問一答」電子取引関係（2025年6月）
＊5 国税庁「電子帳簿保存法一問一答」電子取引関係（2025年6月）
＊6 国税庁「電子帳簿保存法一問一答」電子取引関係（2025年6月）
＊7 国税庁「電子帳簿保存法一問一答」電子取引関係（2025年6月）
＊8 Remoguサイト公開情報（案件の90%以上がフルリモート可能）