結論：電子帳簿保存法の電子取引データ保存は、高価な専用システムを入れなくても「規則的なファイル名への正規化・索引簿の自動生成・保存漏れの定期点検」の3点をClaude Codeで仕組み化することで、国税庁が示す簡易な方法のまま運用に耐える形にできます。制度の要件（改ざん防止・検索性）は国税庁の一次情報で固定し、AIに任せるのはファイル整理と突合レポートの部分だけです。
- 要点1：電子取引データの保存ルールは3つ——①改ざん防止の措置、②ディスプレイ・プリンタ等の備付け、③「取引年月日・取引金額・取引先」の3項目で検索できること（国税庁「電子取引データ保存要件チェックシート」令和6年11月）
- 要点2：検索要件③は専用システムがなくても、「日付_金額_取引先」の規則的ファイル名か、表計算ソフトの索引簿で満たせると国税庁自身が案内している。つまりここは「ファイル整理の自動化」の問題であり、Claude Codeが最も得意な領域
- 要点3：実務で破綻するのはルールの理解ではなく運用の継続。メール添付・ECサイト・クラウド明細と入口が散らばるほど保存漏れと命名のばらつきが蓄積するので、点検を人の記憶ではなくコードに持たせる
対象読者：経理・総務部門とAI活用を進める開発者・PM・経営企画
今日やること：先月受け取った請求書・領収書のうち「紙で届いていないもの」を10件書き出し、いま何というファイル名でどこに保存されているかを確認する
先に断っておくと、本記事は複数の導入支援経験をもとに一般化した実装パターン解説です。記事中の工数・効果の数値はすべて想定モデルの試算であり、実測値ではありません。また、電子帳簿保存法の適用可否や自社の保存方法が要件を満たすかどうかの最終判断は、顧問税理士または所轄税務署に確認してください。本記事は「要件を満たすための作業をどう自動化するか」という実装側の話に絞ります。
経理向けのAI研修をやっていると、電子帳簿保存法の話は毎回といっていいほど出ます。興味深いのは、質問の中身が「制度がわからない」ではなくなってきたことです。「制度は概ね理解した。でもメールの添付、ECサイトの領収書、クレジットカードのWeb明細と入口がバラバラで、全部を決めた形で保存し続ける運用が回らない」——つまり困りごとが制度の理解から運用の継続に移っています。そしてこの「散らばったファイルを規則どおりに集め続ける」仕事は、まさにClaude Codeのようなコーディングエージェントの得意分野です。
先に制度の要件を固定する——電子取引データ保存の3つのルール
実装の前に、何を満たせばよいのかを国税庁の一次情報で固定します。ここが曖昧なまま作り始めると、便利だが要件を満たさないツールができあがります。
まず対象。電子帳簿保存法でいう「電子取引」とは、注文書・契約書・送り状・領収書・見積書・請求書などに相当する電子データを受領または交付する取引を指します（電子帳簿保存法2条五）。取引先からメールで受け取った請求書PDF、ECサイトで購入した物品の領収書、インターネット上でのみ確認できるクレジットカードやネットバンキング、水道光熱費の明細などが該当すると国税庁のチェックシートに明記されています。申告所得税・法人税の保存義務がある事業者は、これらを紙に印刷して保存するのではなく、電子データのまま保存する必要があります（電子帳簿保存法7条）。
原則的な保存ルールは次の3つです（国税庁パンフレット・令和6年11月版）。
- 改ざん防止のための措置——タイムスタンプ付与、訂正・削除の履歴が残るシステムでの授受・保存、または「改ざん防止のための事務処理規程」の策定・運用・備付けのいずれか。専用システムを導入しない場合は事務処理規程の方法があり、国税庁HPに規程のサンプルが掲載されています
- ディスプレイ・プリンタ等の備付け——税務調査等の際にデータを確認できるようにしておくこと。性能や台数の要件はありません
- 検索機能の確保——「取引年月日・取引金額・取引先」の3つの記録項目で検索できること。加えて、日付または金額の範囲指定検索と2項目以上の組合せ検索ができるか、税務調査等の際にデータのダウンロードの求めに応じられるようにしておくこと
重要な緩和が2つあります。第一に、基準期間（2年（期）前）の売上高が5,000万円以下の事業者等は、ダウンロードの求めに応じられるようにしていれば検索要件そのものが不要です。第二に、原則ルールへの対応が間に合わない場合の猶予措置があり、「相当の理由」（システム整備が間に合わない・人手不足・資金不足など。事前届出は不要）があり、かつ税務調査の際にデータのダウンロードと出力書面の提示・提出の両方に応じられるなら、データを消さずに保存しておくだけでよいとされています（施行規則4条3項）。
そして本記事の主役はルール③です。国税庁は検索要件を満たす簡易な方法として、次の2つを自ら例示しています。
- 方法ⅰ：索引簿方式——表計算ソフト等で「連番・日付・金額・取引先・備考」の索引簿を作り、索引簿で検索できるようにする
- 方法ⅱ：規則的ファイル名方式——「日付・金額・取引先」の順で表記した規則的なファイル名（例：
20240331_110000_株式会社霞商店.pdf）を付け、特定のフォルダに集約する
どちらも要するに「ファイルの命名と台帳づくり」です。ここを手作業でやるから続かないのであって、コードでやれば毎月の負担はほぼゼロにできます。
専用システムを入れても「保存漏れ」は残る——何をコードで守るのか
「電帳法対応のシステムを契約したから大丈夫」という会社でも、話を聞いていくと大体同じ穴が見つかります。システムが守ってくれるのはシステムに入れたデータだけだからです。
電子取引の入口は想像以上に散らばっています。経理宛のメール添付だけでなく、営業担当が個人のメールで受け取った見積書、総務がECサイトで買った備品の領収書、Web明細でしか発行されないクラウドサービスの請求、代表者のカード明細。導入支援の現場でこの「入口の棚卸し」をやると、経理部門が把握していなかった入口が必ずと言っていいほど出てきます。専用システムの契約有無にかかわらず、「入口の列挙」と「そこからの取りこぼし検知」は自社側の仕事として残るわけです。
そこで本記事では、Claude Codeで次の4層を組みます。専用システムを使っている会社なら第3層・第4層だけでも価値があります。
- 収集層——メールエクスポートやダウンロードフォルダなど、入口ごとの「未整理ファイル置き場」を1か所に決める
- 命名層——未整理ファイルを「日付_金額_取引先」の規則的ファイル名に正規化し、保存フォルダへ移す（国税庁の方法ⅱ）
- 索引層——保存フォルダから索引簿CSVを自動生成し、ファイルと索引簿の食い違いを突合する（国税庁の方法ⅰを機械生成で維持）
- 点検層——「未整理置き場に放置されているファイル」「命名規則違反」「索引簿とのズレ」を毎月レポートする
実装の全体像——リポジトリ構成とCLAUDE.md
プロジェクトは通常のコードリポジトリとして組みます。ポイントは、ルールをプロンプトに書くのではなく設定ファイルとコードに固定し、Claude Codeには「ルールの実装・改修・例外の整理」をやらせることです。
dencho-filing/
├── CLAUDE.md # プロジェクトの前提と禁止事項
├── config/
│ ├── rules.yaml # 命名規則・対象拡張子・保存先の定義
│ └── vendors.yaml # 取引先の正式名と表記ゆれ辞書
├── inbox/ # 入口ごとの未整理ファイル置き場
│ ├── mail_export/
│ └── downloads/
├── archive/ # 正規化済みファイルの保存先（年度/月別）
├── scripts/
│ ├── plan_rename.py # リネーム計画の生成（ドライラン専用）
│ ├── apply_rename.py # 計画CSVに基づくコピー実行
│ ├── build_index.py # 索引簿CSVの生成と突合
│ └── monthly_check.py # 月次点検レポート
└── reports/ # 点検レポートの出力先
CLAUDE.mdには、エージェントが暴走しないための禁止事項を最初に書きます。ファイル整理の自動化で一番怖いのは「元データの破壊」なので、そこを構造で防ぎます。
# CLAUDE.md（抜粋）
- inbox/ 配下の元ファイルを削除・上書き・移動してはならない。
正規化は必ず archive/ への「コピー」で行い、元ファイルは残す。
- リネームの実行は plan_rename.py が出力した計画CSVを人間が
確認した後のみ。計画の生成と実行を1ステップで行わない。
- 取引金額・取引先の抽出結果に確信が持てない場合は、
ファイル名に確定値を書かず review_needed/ に振り分ける。
- 不足している情報があれば、最初に質問してから作業を開始すること。
実装コード例1：ファイル名の正規化——「日付_金額_取引先」への変換
最初に作るのは、未整理ファイルからリネーム計画を作るスクリプトです。Claude Codeへの最初の依頼はこんな形になります。
inbox/mail_export/ 配下のPDFについて、ファイル名を
「YYYYMMDD_金額_取引先名.pdf」に正規化するリネーム計画を作りたい。
前提：
- 国税庁の例示（20240331_110000_株式会社霞商店.pdf）に合わせる。
金額は税込・円単位・カンマなし
- PDF本文から取引年月日・合計金額・発行元を抽出し、
計画CSV（元パス, 新ファイル名, 抽出根拠, 確信度）を出力する
- このステップではファイルを一切変更しない（ドライラン専用）
- 抽出に確信が持てない項目は空欄にし、confidence列を low にする
- 仮定した点は必ず「仮定」と明記してください
抽出部分の実装は環境に応じてpdfplumber等のライブラリを使いますが、骨格はシンプルです。重要なのは計画と実行の分離で、plan_rename.pyは計画CSVを吐くだけ、apply_rename.pyは人間が確認した計画CSVを読んでコピーするだけ、という役割の固定です。
# apply_rename.py（骨格）
# 計画CSVの各行を検証してから archive/ へコピーする。元ファイルは消さない
import csv, re, shutil, sys
from pathlib import Path
NAME_RE = re.compile(r"^\d{8}_\d+_[^/\\]+\.(pdf|xml|csv)$")
def main(plan_csv: str):
errors, done = [], 0
for row in csv.DictReader(open(plan_csv, encoding="utf-8")):
src = Path(row["src"])
new_name = row["new_name"]
if row["confidence"] != "high":
errors.append(f"低確信のためスキップ: {src}")
continue
if not NAME_RE.match(new_name):
errors.append(f"命名規則違反: {new_name}")
continue
ym = new_name[:6] # YYYYMM
dst = Path("archive") / ym / new_name
if dst.exists():
errors.append(f"重複あり要確認: {dst}")
continue
dst.parent.mkdir(parents=True, exist_ok=True)
shutil.copy2(src, dst) # move ではなく copy
done += 1
print(f"コピー完了 {done} 件 / 要確認 {len(errors)} 件")
for e in errors:
print(" -", e)
if __name__ == "__main__":
main(sys.argv[1])
低確信のファイルを無理に処理しないのが肝です。PDFの金額抽出は、値引き・源泉徴収・複数税率が絡むと合計欄の特定を誤ることがあります。誤った金額がファイル名に入ると「検索できるが間違った値で検索される」状態になり、漏れよりたちが悪い。だから確信が持てないものは人間の確認列に送る設計を最初から入れます。運用が回り始めると、review行きになるのは特定の取引先のフォーマットに偏ることが分かってくるので、その取引先専用の抽出ルールをClaude Codeに追加させて精度を上げていきます。
実装コード例2：索引簿の自動生成とファイルとの突合
規則的ファイル名が維持できていれば、索引簿はそこから機械的に導出できます。国税庁の例示にある「連番・日付・金額・取引先・備考」の列構成で、archive/を走査してCSVを再生成します。
# build_index.py（骨格）
# archive/ を走査して索引簿CSVを生成する。手入力の台帳を作らない
import csv, hashlib, re
from pathlib import Path
ROW_RE = re.compile(r"^(\d{8})_(\d+)_(.+)\.(pdf|xml|csv)$")
def sha256(p: Path) -> str:
return hashlib.sha256(p.read_bytes()).hexdigest()[:16]
rows, violations = [], []
for p in sorted(Path("archive").rglob("*")):
if not p.is_file():
continue
m = ROW_RE.match(p.name)
if not m:
violations.append(str(p)) # 命名規則違反＝検索要件を壊すファイル
continue
date, amount, vendor = m.group(1), m.group(2), m.group(3)
rows.append([len(rows) + 1, date, amount, vendor, "", str(p), sha256(p)])
with open("reports/index.csv", "w", newline="", encoding="utf-8-sig") as f:
w = csv.writer(f)
w.writerow(["連番", "取引年月日", "取引金額", "取引先", "備考",
"ファイルパス", "ハッシュ"])
w.writerows(rows)
print(f"索引簿 {len(rows)} 件 / 命名規則違反 {len(violations)} 件")
索引簿を「手で維持する台帳」ではなく「ファイル群から毎回生成するビュー」にするのがこの設計の中心です。手入力の台帳は必ずファイルとズレます。生成方式ならズレは原理的に起きず、突合すべきは「命名規則違反のファイル」だけに絞られます。ハッシュ列は法令上の要求ではありませんが、後から「このファイル、差し替わっていないか」を確認できる保険として付けています。
実装コード例3：保存漏れの定期点検——「入口」からの取りこぼし検知
命名と索引簿が整っても、そもそもinboxに入ってこなかったファイルは救えません。第4層の点検は「入口ごとの取りこぼし」を月次で洗い出します。Claude Codeへの依頼はこうです。
月次点検スクリプト monthly_check.py を作りたい。毎月1回実行して、
以下をMarkdownレポートとして reports/ に出力する。
1. inbox/ 配下に14日以上放置されているファイルの一覧
2. archive/ 直下・年度フォルダ直下など「月フォルダ以外」に
置かれた迷子ファイルの一覧
3. build_index.py が検出した命名規則違反の一覧
4. vendors.yaml に登録済みの取引先のうち、今月の索引簿に
1件も出てこない先の一覧（毎月請求が来るはずの先の抜け検知）
5. 前月比のファイル件数（急減していたら入口の取り込み失敗を疑う）
数字と判定根拠は、どのファイル・どの設定に基づくかを必ず添えてください。
特に効くのが4番です。保存漏れは「あるはずのものがない」という欠落なので、ファイル側をいくら眺めても見つかりません。「毎月来るはずの取引先リスト」という期待値sideを持って初めて検知できます。クラウドサービスのWeb明細のように、先方からプッシュされず自分で取りに行く必要がある取引はここで拾えるようになります。導入支援の現場でも、月次サブスクの明細が数か月分まるごと未保存だったのがこの突合で見つかる、というのが定番の初期検出です。
取引先名の表記ゆれ——検索要件を実質的に壊す最大の敵
運用してみると最初にぶつかるのが取引先名のゆれです。「株式会社霞商店」「(株)霞商店」「カスミ商店」「Kasumi Shoten Inc.」——同じ会社がファイル名上で4通りに散らばると、「取引先で検索できること」という要件は形式的には満たしていても、実務では検索に引っかからないファイルが生まれます。
対策はコード例1の段階でvendors.yamlに正規化辞書を持たせ、抽出した発行元名を必ず正式名に寄せてからファイル名に使うことです。
# vendors.yaml（抜粋）
- canonical: 株式会社霞商店
aliases: ["(株)霞商店", "カスミ商店", "Kasumi Shoten"]
expect_monthly: true # 毎月請求が来る先か（点検4で使用）
- canonical: 国税工務店株式会社
aliases: ["国税工務店(株)"]
expect_monthly: false
辞書の初期構築もClaude Codeにやらせます。依頼はこんな形です。
inbox/ 配下の全ファイルから発行元の名称候補を抽出し、
「同一取引先の可能性が高いグループ」にまとめて提示してほしい。
- 法人格の表記差（株式会社/(株)）、カナ/漢字、英語表記を
同一候補としてグルーピングする
- 確信が持てないペアは「要判断」として分けて出す
- 出力は vendors.yaml の下書き形式で。確定は私がやるので、
勝手に canonical を確定させないこと
ゼロから手で作ると数百件の取引先で心が折れますが、グルーピング済みの候補を確認するだけなら現実的な作業量に収まります。運用開始後に新しい表記ゆれが点検レポートに出たら、「この違反ファイル群を分析して、vendors.yamlへの追記案と、再発を防ぐ抽出ルールの修正案を出して。仮定した点は仮定と明記して」とClaude Codeに渡せば、辞書とコードの両方が育っていきます。
運用の3フェーズ——最初の1か月は「過去分の棚卸し」に使う
Phase 1（第1か月）：過去分の棚卸しとルール確定。直近1年分の電子取引データを入口ごとにかき集め、リネーム計画のドライランを回します。ここでの目的は整理を終わらせることではなく、「自社の電子取引の入口一覧」「取引先辞書の初版」「review行きになるファイルのパターン」を確定させることです。このタイミングで、改ざん防止措置として事務処理規程方式を採る場合は国税庁HPのサンプル規程を基に自社版を整え、内容の適否を税理士に確認しておきます。規程の文面調整の下書きはClaude Codeでも作れますが、正とするのは国税庁サンプルと専門家の確認です。
Phase 2（第2〜3か月）：月次運用の確立。命名層・索引層・点検層を月次で回し始めます。最初の2か月は点検レポートの「要確認」が多めに出ますが、その大半は辞書の未登録と特定フォーマットの抽出失敗なので、毎月潰していけば減っていきます。
Phase 3（第4か月以降）：手離れと変化点対応。定常運用はスクリプト実行だけになり、人間の関与は点検レポートの確認と、新しい取引先・新しい入口が増えたときの辞書更新に絞られます。制度改正があった場合のルール見直しはこのリポジトリのconfigを直すだけです。
想定モデルとして、月200件の電子取引がある会社を考えます（以下はすべて試算です）。手作業でファイル名を整え台帳に転記すると1件2〜3分、月に7〜10時間の作業です。仕組み化後は、点検レポートの確認と例外対応で月1〜2時間程度に収まる計算になります。ただし最大の効果は時間短縮そのものより、「保存できているかどうかを誰も断言できない状態」から「点検レポートが根拠付きで答えてくれる状態」への移行だと考えています。
【要注意】よくある失敗パターンと回避策
失敗1：計画と実行を分けず、いきなり一括リネームを走らせる
❌ 「inboxのファイルを全部規則名にリネームして」と依頼し、その場で実行させる
⭕ 計画CSVの生成（ドライラン）と、人間確認後のコピー実行を別ステップ・別スクリプトに分ける
元ファイル名には「どのメールの添付だったか」といった復元の手がかりが残っています。renameではなくcopyで正規化し、元ファイルを残す構造にしておけば、抽出ミスが後から見つかっても巻き戻せます。
失敗2：AIが抽出した金額をそのままファイル名に確定させる
❌ PDFから読んだ合計金額を無条件でファイル名に採用する
⭕ 確信度の低い抽出はreview行きにし、可能なら会計データなど別ソースとの突合で検算する
値引き・源泉徴収・複数税率の請求書は合計欄の特定を誤りやすい箇所です。間違った金額で「検索できてしまう」状態は、税務調査等の際にかえって説明コストを生みます。
失敗3：ファイル整理だけやって改ざん防止措置を忘れる
❌ 検索要件（ルール③）だけ整えて対応完了と考える
⭕ タイムスタンプ・訂正削除履歴の残るシステム・事務処理規程のいずれかを整え、規程方式なら国税庁サンプルを基に策定して備え付ける
本記事の仕組みが直接カバーするのは検索要件の部分です。改ざん防止措置（ルール①）は別途必要で、どの方式を採るかを含めて税理士に確認してください。
失敗4：担当者の個人フォルダで運用してしまう
❌ 経理担当者のローカルPCのフォルダ構成に依存した仕組みにする
⭕ 共有ストレージ上のリポジトリとして組み、設定・辞書・スクリプトをバージョン管理する
電子取引データの保存は担当者が変わっても続く義務です。属人化した仕組みは引き継ぎのたびに壊れます。configとスクリプトがgit管理されていれば、「なぜこのルールになっているか」の履歴ごと引き継げます。
よくある質問
Q. 電帳法対応の市販システムを使っていれば、この仕組みは不要ですか？
システムに全件が入っているなら命名層・索引層は不要です。ただし「システムに入れ忘れたファイルの検知」は別問題として残ります。入口の棚卸しと月次点検（本記事の第1層・第4層）は、専用システム利用の有無にかかわらず効きます。また、どの入口をシステムに接続済みかの管理も、vendors.yamlのような期待値リストがあると確認が速くなります。
Q. ファイル名の形式に法令上の決まりはありますか？
「この形式でなければならない」という指定があるわけではなく、「取引年月日・取引金額・取引先」の3項目で検索できる状態を作ることが要件です。国税庁のパンフレットが例示しているのが「日付・金額・取引先の順で表記したファイル名を特定フォルダに集約する方法」なので、本記事はその例示に合わせています。自社の形式が要件を満たすかは税理士または所轄税務署に確認してください。
Q. 売上高5,000万円以下なら何もしなくてよいのですか？
検索要件が不要になるだけで、保存義務そのものと改ざん防止措置・ダウンロードの求めへの対応は必要です。また、検索できない大量のファイルは税務調査等の際に自社が困ります。要件として免除されていても、規則的ファイル名の運用コストはコード化すればわずかなので、整えておく価値はあると考えています。
Q. 改ざん防止のための事務処理規程もClaude Codeで作れますか？
下書きの補助はできますが、正とすべきは国税庁HPに掲載されている規程サンプルです。実務としては、サンプルを自社の組織名・責任者・手順に合わせて修正し、その内容で運用できるかを確認する流れになります。Claude Codeが役立つのは、規程に書いた手順（保存先・命名・点検頻度）と実際のスクリプトの挙動が一致しているかの突合で、規程の法的な適否の判断は税理士・所轄税務署への確認が必要です。
Q. 過去分の未整理データはどこまで遡って整理すべきですか？
まず現在進行分の運用を確立し、過去分は保存義務期間を確認した上で優先順位を付けるのが現実的です。過去分の整理はまさに本記事のドライラン方式が向いている作業で、計画CSVを眺めるだけで「どの期間・どの入口に穴があるか」の全体像がつかめます。遡及対応の要否や範囲の判断は税理士に相談してください。
Q. 導入にはどれくらいの期間がかかりますか？
月200件規模の想定モデルの試算で、過去分の棚卸しとルール確定に1か月、月次運用の安定までに2〜3か月が目安です。最大の変数はコードの実装量ではなく、入口の数と取引先辞書の整備量です。逆に言えば、入口が少ない小規模事業者ほど立ち上がりは速くなります。
まとめ：今日から始める3つのアクション
- 今日やること：先月の電子取引を10件書き出し、入口（メール・EC・Web明細など）とその保存場所・ファイル名を確認する。バラバラなら、それがこのプロジェクトの出発点です
- 今週中：国税庁の「電子取引データ保存要件チェックシート」（令和6年11月）を自社に当てはめ、3つのルールのどこが埋まっていないかを特定する。埋まっていない箇所が改ざん防止措置なら規程サンプルの確認、検索要件なら本記事の実装に進みます
- 今月中：直近3か月分の未整理ファイルでリネーム計画のドライランを回し、計画CSVの精度と review 行きの件数を見る。ここの数字が、自社に必要な辞書整備とルール調整の規模感を教えてくれます
電子取引データの整理は、経費精算の規程照合や請求書の三様突合と同じ「ルールを設定ファイルに固定し、AIは正規化と例外の整理を担う」パターンのファイリング版です。すでに月次決算の残高照合を仕組み化している会社なら、その手前の証憑整理として自然につながります。
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』（SBクリエイティブ）。
参考・出典
- 国税庁「電子帳簿等保存制度特設サイト」（参照日: 2026-07-31）
- 国税庁「電子取引関係」（参照日: 2026-07-31）
- 国税庁「電子帳簿保存法対応！令和6年1月以降の電子取引データの保存方法について」（令和6年11月・PDF）（参照日: 2026-07-31）
- 国税庁「電子取引データ保存要件チェックシート」（令和6年11月・PDF）（参照日: 2026-07-31）
- 国税庁「電子帳簿保存法の概要」（参照日: 2026-07-31）
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
