日本の通帳データをExcelに変換する方法
家計簿向け（2026年版ガイド）
総務省の2024年家計調査によると、日本の2人世帯の平均支出は月額¥300,243 — 年間約360万円が銀行口座を流れ、ATMで小さな通帳に1行ずつ印字されます。複式簿記と引き換えに65万円の控除を受けられる青色申告を利用する、400万人以上の個人事業主・フリーランサーにとって、それらの取引はすべて追跡可能でなければなりません。通帳は決定的な記録です。そして、ネットバンキング契約前の取引については、唯一の記録でもあります。通帳をスプレッドシートに変換することは任意ではなく、確定申告を完了するための前提条件です。
重要なポイント
- 通帳の残高は検証を確実にするためのもの — しかし、1つの桁の読み間違いが、それ以降のすべての残高を静かに狂わせます。
- 銀行取引明細書のエラーはその行に留まりますが、通帳のエラーは後続のすべての残高に波及します。各行の計算が、それ以前のすべての行が正しいことに依存しているからです。
- 変換中に各行の残高計算を検証する計算列を1つ追加すれば、データが会計ソフトに入る前にエラーが明らかになります。
日本の銀行通帳に含まれるもの — 各列が抽出に与える影響
日本の銀行通帳（通帳、tsūchō）は、世界的に見てもユニークな金融記録です。他の先進国では、この規模で物理的な通帳をまだ使用している国はありません。銀行が発行する印刷された冊子で、ATMでの入出金のたびに取引明細が1行ずつ追加されます。1取引につき1行、1行につき5列、各行に残高が表示されます。この形式は日本の金融機関全体で標準化されており、初めて見る人には抽出が簡単に解決できる問題のように見えます。しかし実際はもっと複雑です。
通帳の5列レイアウトは固定されています — 日付、摘要、払出、預入、残高 — しかし、それらの列の中身は、何十年にもわたる銀行慣行、機械印刷技術、規制の歴史を反映しており、一般的なOCRシステムが理解できるように作られたものではありません。
5つの標準列
- 月日 — 月と日。通常は和暦形式（令和6年またはR6）で表示されます。年の見出しはページごとに1回表示されます。和暦を西暦に変換するには、現在の元号を把握している必要があります — 平成30年（2018年）を令和6年（2024年）と誤認しないように。
- 摘要 — 取引の種類を示す簡潔なコード：振込、ATM、給与、利息、引落、手数料など。これらのコードは取引の分類における鍵ですが、狭い等幅の日本語文字で印刷されるため、標準的なOCRでは文字の結合や誤読が頻繁に発生します。
金額と残高の列
- お支払金額 — 口座から引き落とされる金額。右詰めでカンマ区切り（例：30,000）で印刷されます。狭い列でのカンマ区切り数字のOCR読み取りは既知の失敗ポイントです — カンマが1つ欠落すると、¥30,000が¥3,000になってしまいます。
- お預り金額 — 入金される金額。1つの取引は、この列または払出列のどちらかにのみ記録され、両方に記録されることはありません。この排他性が残高検証の基礎となります。
- 差引残高 — 取引後の残高。各行の後に印刷されます。この列により自己検証が可能になります：前回残高 + 預入 − 払出 = 現在残高。1つの誤読が連鎖的なエラーを引き起こします — 後続のすべての行の残高がずれてしまい、これは残高ずれとして知られる問題です。
通帳の物理的な形式は、全国銀行協会が定める基準に従っており、銀行間データ交換、ATM相互運用、および口座情報を格納する裏表紙の磁気ストライプの標準を定めています。ATMはこのストライプを読み取って口座を識別し、ドットマトリクスまたは感熱プリンターで取引明細を通帳ページに直接印刷します。つまり、手にしている通帳は組版された文書ではなく、プリンターの出力なのです。この違いは抽出において重要です。印刷品質はATMの機種、インクリボンの劣化、プリントヘッドの清掃状態によって異なります。同じ銀行の2冊の通帳でも、6か月間隔で異なるATMで印刷された場合、文字の濃さや位置のずれが顕著に異なることがあります。
中核となる抽出の原則：「日付」「摘要」「引き出し」「預け入れ」「残高」の5つの出力列を定義すると、AIはテンプレート上のピクセル座標を照合するのではなく、データが意味的に何を表すかを理解して各ページの各値を特定します。同じ列定義が、三菱UFJ、三井住友、みずほ、ゆうちょ銀行、および地域の信用金庫の通帳全体で機能するのは、AIがフィールドの意味を読み取るからです。ある通帳では「R6.7.15」、別の通帳では「2024-07-15」と印刷されていても、日付は日付なのです。
家計簿アプリに通帳を渡すだけでは不十分な理由
日本には、デジタルに精通した世帯の大半をカバーする3つの主要な家計簿アプリがあります。マネーフォワード ME（2,451以上の金融サービス連携）、Zaim（1,300以上の連携、1,200万ダウンロード）、Moneytree（2,387以上の連携）です。3つともAPI経由で日本の銀行口座に接続し、取引データを自動的に取得してカテゴリ別の支出レポートにまとめます。継続的で将来を見据えた支出管理には、これらはよく機能します。銀行APIが毎日新しい取引を供給するため、ユーザーが紙の通帳に触れる必要はありません。
ギャップは、登録前に起こったことです。銀行API接続は、承認した日からデータを取得します。通常、銀行によって異なりますが、過去90日から1年分です。2022年、2021年、2019年の取引 — 物理的な通帳の印刷ページにのみ存在する年 — はアプリに表示されません。暦年全体の事業関連取引を計上する必要がある青色申告のフリーランサーにとって、アプリは現在をカバーしますが、過去は紙のまま残ります。同様に、銀行から物理的な通帳を受け取り、毎月の記帳を税理士と共有する小規模事業主の場合、税理士は事業主のマネーフォワードアカウントにログインしません。税理士は通帳、またはそのスキャンから作業するのです。
アプリは日々の支出の可視化を解決します。しかし、5年分の紙の取引が1つのスプレッドシートになる必要がある年に一度の瞬間 — まさに通帳抽出の検索を促す瞬間 — は解決しません。
理解しておく価値のある第三の道があります。一部の銀行は現在デジタル通帳を提供しており、物理的な通帳を廃止し、ウェブベースの取引表示やダウンロード可能なCSVエクスポートを採用しています。全国銀行協会は、銀行のデジタル化の一環としてデジタル通帳を推進してきました。しかし、普及は不均一です。MUFGやSMBCなどの大手銀行は新規口座でデジタル通帳を提供していますが、多くの地方銀行や信用金庫は依然として物理的な通帳をデフォルトで発行しています。また、デジタル通帳にアクセスできる口座でも、エクスポート形式や日付範囲が会計ソフトの期待するものと異なることがよくあります。物理的な通帳は、その不便さにもかかわらず、最も共通した形式であり続けています。どの銀行も発行し、すべての取引が記載され、口座の全履歴をカバーします。
この最後の特性、つまり口座の全履歴をカバーすることこそが、通帳抽出が他国の銀行明細書抽出と根本的に異なる理由です。英国の銀行明細書や米国の月次明細書は、特定の期間の要約です。日本の通帳は元帳であり、最初の印刷ページから最後のページまでの継続的で累積的な記録です。以下に続く抽出ワークフローでは、その連続性が文書の最大の強みであると同時に、最も一般的なエラーモードの原因でもあります。
通帳抽出ワークフローの設定
通帳データの再入力に代わるワークフローは3つのステップで構成されます。最初のステップである列の定義は一度だけ行い、すべての通帳、すべての銀行、すべての税年度で再利用します。
出力する5つの列を定義 — 一度設定すれば、どの銀行でも使えます
スプレッドシートの列見出しとして表示したいフィールド名を、そのまま入力してください。通帳の抽出では、標準セットは次のとおりです: 日付、摘要、お支払金額、お預り金額、差引残高。これはカスタム列抽出です。出力スキーマを定義すると、AIが各通帳の印字フィールドを意味に基づいて列にマッピングします。三菱UFJの縦型レイアウト、三井住友の1取引2行形式、ゆうちょ銀行のコンパクトな印字スタイルでも、AIはフィールドの位置ではなく意味を読むため、同じ列名が機能します。会計目的でカテゴリ列を計算列として追加することもできます。たとえば、カテゴリ — AIが抽出中に評価するため、出力は分類済みで届きます。
すべての通帳ページを1つのバッチでアップロード
口座番号が記載された表紙と、磁気ストライプのある裏表紙を含め、すべての通帳の全ページをスキャンまたは撮影し、すべての画像を1つのアップロードにドロップしてください。バッチ処理はこれらを1つのジョブとして扱います。各ページは列スキーマを適用して個別に処理され、すべての結果が1つの統合スプレッドシートにマージされます。中程度の取引がある口座の典型的な例として、30ページに約280件の取引がある3年分の通帳は、1つのバッチで処理されます。ページは、ドキュメントスキャナでのスキャン、スマートフォンでの撮影、または通帳形式の取引明細を含むインターネットバンキングからのPDF書き出しのいずれでもかまいません。
Excelに書き出して会計ワークフローを開始
統合スプレッドシートをExcelファイルとしてダウンロードします。これで、取引ごとに1行、各フィールドがそれぞれの列に入った状態になります。このスプレッドシートは、弥生会計、freee、マネーフォワード クラウド会計、その他CSVインポートに対応する日本の会計ソフトにすぐにインポートできます — 次のセクションでそのパイプラインを説明します。さらに重要なのは、残高列が組み込みの監査証跡となることです。日付の降順で並べ替え、残高列をスキャンしてください。残高が前の行の残高に預入を加え引き出しを引いた値と一致しない行はフラグが立てられます — 抽出で誤読が検出されたため、280行を探し回るのではなく、1つのセルを修正するだけで済みます。
同じ列スキーマは、翌年も、異なる銀行の通帳でも、何年も前に解約したが記録の保持が義務付けられている口座でも機能します。通帳の形式 — 個々の銀行の設計ではなく、全国銀行協会の印字慣行によって定義されている — は変更されません。
ファイルは安全に処理され、保存されません。
和暦日付と摘要コードの処理
通帳データの抽出を他国の銀行文書より難しくしているのは、日本の文脈に特有の2つの側面です。どちらも一般的なAIの限界ではなく、日本の銀行業の発展の産物です。
和暦
通帳の取引日付は、日本の元号（令和（2019年開始）、平成（1989年〜2019年）、昭和（1926年〜1989年））で印刷されており、多くの場合、R、H、Sの略号とその元号内の年数で表されます。R6.7.15という日付は2024年7月15日（令和6年）を意味します。H30.3.31は2018年3月31日（平成30年）です。S62.1.10は1987年1月10日（昭和62年）です。西暦への変換には各元号の開始年を知る必要があります（令和＝2018＋n、平成＝1988＋n、昭和＝1925＋n）。また、ページの途中で新年が始まる境界も処理する必要があります。多くの通帳では、元号の年数はページ上部に一度だけ印刷され、以降の行には月日のみが記載されます。「7.15」を文脈なしに日付として読み取る生のOCR出力では、タイムラインに配置できない値になります。数ミリ上にある年号ヘッダーが、それが2023年7月なのか2024年7月なのかを決定するからです。
解決策は2パス抽出戦略です。最初のパスでは、ページから年号ヘッダーを読み取り、元号を特定します。2番目のパスでは、各取引日付を解析し、ヘッダーからの年号コンテキストを適用します。月が12から1に変わる年境界では、元号の年数が1つ増えます。これはまさに、テンプレートベースのOCRではできない構造化された推論です。個々のセルを読み取るだけで、ヘッダーとその依存行の関係を読み取らないからです。しかし、AIを活用した抽出は、文書を孤立したテキストボックスのグリッドとしてではなく、全体として理解することで処理します。
摘要
通帳の摘要欄には、日本人の読者には一目でわかるが、一般的なテキストパーサーには理解できない略号が使用されています。一般的な項目には、振込（銀行振込。顧客からの支払いか個人間の送金かは不明）、ATM（ATMでの引き出しまたは入金。どちらかは不明）、給与（給与の入金。個人にとって最も重要な収入項目）、利息（利息の支払い。通常は少額で、税務に関連）、引落（家賃、光熱費、保険などの自動引き落とし）、手数料（銀行手数料。通常110円〜550円で、事業用口座では控除対象）、カード（カード取引。デビットカードの支払いかクレジットカードの決済かは不明）などがあります。
「振込 50,000」と記載された通帳の行は、顧客からのフリーランスの支払いか、友人からの夕食代の返済の可能性があります。通帳は区別しません。区別するのは会計ソフトのカテゴリ割り当てです。抽出ではコードを忠実に取得する必要があり、カテゴリ分けのロジックは後段にあります。
一部の通帳には、欄外に手書きの注記が含まれていることもあります。印刷された取引の横にボールペンで「家賃」や「仕入」といったメモが書かれている場合です。これらの注記は会計上のカテゴリ分けに重要ですが、さらなる課題があります。筆跡の質はさまざまで、インクの色も異なり、印刷された罫線を横切ることもあります。抽出ツールが手書き文字認識をサポートしている場合（ビジョンモデルを活用した抽出のように）、これらの欄外のメモは、別途の手動参照ステップではなく、抽出データの一部になります。
弥生会計・freee・マネーフォワードへのデータ移行
抽出したExcelスプレッドシートは最終目的地ではありません。通帳と会計ソフトをつなぐ橋です。日本の会計ソフト市場は3つのプラットフォームが支配しており、個人事業主と中小企業の大半をカバーしています。
弥生会計。 市場リーダーであり、特に税理士の間で支持されています。スマート取引取込機能による取引データのCSVインポートに対応しています。仕訳帳を開き、インポートを選択し、CSVを選び、列を弥生の勘定科目フィールドにマッピングします。弥生は日付をyyyy-mm-dd形式で期待するため、抽出ステップでの和暦から西暦への変換はエクスポート前に行う必要があります。
freee会計。 クラウドネイティブでAPI連携に強みがあります。通帳取引データは、手動CSVアップロード（「ご自身で作成したCSV」形式を選択して列をマッピング）または銀行API経由で継続的にインポートできます。APIアクセス前の過去の通帳データについては、CSVインポートが唯一の方法です。freeeの自動登録ルールを設定して、通帳の摘要コードを認識し、適切な勘定科目を割り当てることができます。
マネーフォワード クラウド会計。 「他社ソフトデータの移行」機能からインポートし、中間CSV形式として弥生互換形式を選択します。マネーフォワードの強みは、通帳データ・クレジットカード明細・領収書スキャンを統合したダッシュボードです。抽出した通帳行は、孤立したスプレッドシートではなく、完全な財務状況の一部になります。
同じCSVインポートに対応する他の会計プラットフォームには、MJS（会計大将）、TKC（FX2/MXシリーズ）、OBC（勘定奉行）、ソリマチ（会計王）、EPSON（財務応援R4）、PCA（PCA会計）があります。抽出結果であるクリーンな5列のCSVは、通帳形式が銀行間で標準化されているため、すべてのプラットフォームで動作します。日付形式、金額列、摘要フィールドは、どの会計パッケージで受け取っても同じです。
インポート前に追加すべき計算列： 検証列「残高チェック（前残高＋入金−出金＝現在残高？ 'OK' : 'REVIEW'）」を定義し、抽出中に実行します。OKが並ぶ中にREVIEWフラグが1つあるだけで、どの行を再確認すべきかが正確にわかります。これがないと、エラーは会計ソフトにデータが入り、試算表が銀行明細と一致しない段階で表面化し、追跡がはるかに困難になります。
この検証ステップこそ、通帳の元帳形式が他の銀行書類より優れている点です。英国の銀行明細書やオーストラリアの支払い明細書には残高が記載されておらず、各行を外部ソースと照合する必要があります。通帳には検証機能が内蔵されています。すべての行で計算が一致するか、抽出が何かを誤読したかのどちらかです。中間はありません。計算列は、帳簿に入る前に不一致を表面化させます。
他国の給与関連書類とは異なり、同じ抽出ロジックが異なる税コードにも適用される点は、オーストラリアのPAYGワークフロー、英国のP60処理、カナダのT4スリップ抽出で見られます。しかし、通帳の自己検証構造により、照合は抽出時に行われ、別途の会計ステップとしては不要です。CSVが抽出ツールから出力される前に、データ品質の確認は完了しています。
よくある質問
AI抽出は、異なる銀行の通帳を同じバッチで処理できますか？
はい、可能です。これはテンプレートベースのOCRよりもセマンティック抽出を支持する最も強い根拠です。三菱UFJ銀行の通帳は、日付が左側にある単一行の取引形式で印刷されます。ゆうちょ銀行の通帳は、説明が折り返される2行形式をよく使用します。信用金庫の通帳は、わずかに異なるフォントサイズで印刷される場合があります。セマンティック抽出は各値の意味を読み取るため（位置ではなく）、3つの形式すべてを同じバッチでアップロードでき、一貫した列を持つ統合スプレッドシートが生成されます。三菱UFJ銀行のレイアウト用に設定されたテンプレートベースのツールはゆうちょ銀行では失敗し、一方の銀行用に再設定すると他方で機能しなくなります。
通帳の余白に手書きのメモがある場合はどうなりますか？
ビジョンモデル搭載の抽出は、印刷テキストと並んで手書きの注釈も読み取れます。取引行の横に書かれた家賃や仕入などの余白メモは、追加コンテキストとして取得されます。ただし、手書きの品質は大きく異なります。明確な漢字で書かれたボールペンの注釈は通常読み取れますが、印刷されたグリッド線を横切る斜めの薄い鉛筆書きは信頼性が低くなります。手書きメモが重要な会計情報を含む通帳の場合、抽出されたスプレッドシートは物理的な通帳を開いて確認する必要があります。ただし、AIが読み取れる注釈の大部分を処理するため、確認作業は行ごとの検証ではなく例外処理に限定されます。
和暦の変換はどのように機能しますか？年号ヘッダーが別のページにある場合はどうなりますか？
AIは各ページの年号ヘッダー（通常は令和6年やR6として上部に印刷）を読み取り、そのページのすべての取引に適用します。年号ヘッダーのないページ（続きページ）では、AIは前のページから年号コンテキストを引き継ぎます。ページの途中で年が変わる場合（12月31日→1月1日）、年号は加算されます。複数の元号にまたがる通帳（2018年〜2024年で平成30年から令和6年に移行する場合）では、AIはヘッダーが切り替わるページで元号の変更を検出します。抽出された出力は、会計ソフトウェアとの直接互換性のために西暦（yyyy-mm-dd）を使用します。
複数年にわたる通帳から特定の日付範囲のみを抽出できますか？
はい。対象の日付範囲をカバーするページのみをアップロードするか、通帳全体をアップロードして抽出後にExcelで日付範囲でフィルタリングするかのいずれかが可能です。後者の方が実際には速いことが多いです。通帳全体を一度スキャンしてすべての取引を1つのスプレッドシートに取得し、その後日付でフィルタリングします。約300件の取引がある3年分の通帳の場合、すべてを抽出してExcelでフィルタリングする方が、特定の12か月間のページだけを特定してスキャンするよりも時間がかかりません。特に、ページを素早くめくると日付ヘッダーが常に表示されるとは限らないためです。
残高照合が行単位で失敗した場合はどうなりますか？
残高照合の失敗（前回残高＋入金−出金≠現在残高）は、通常3つの原因のいずれかによるものです：(1) 金額の桁の読み間違い（¥30,000を¥3,000と読む）、(2) 入金額が出金欄に、またはその逆に入力されている（典型的なOCR列ずれ問題）、(3) 取引行のスキップ（OCRが1行見落とした）。抽出中に計算列を使って不一致をフラグ付けすれば、会計ソフトにインポートする前に対象行を修正できます。照合ステップがない場合、300行中47行目の1つの読み間違いで、それ以降の残高がすべてずれます。そして、その誤りは試算表が合わなくなるまで見えず、その時点で253行を逆に遡って原因を探すことになります。
抽出後も紙の通帳は保管する必要がありますか？
日本の電子帳簿保存法では、金融書類のスキャン保存は、解像度とタイムスタンプの要件を満たせば法的に有効な記録として認められます（2022年の改正で要件は大幅に緩和されました）。ただし、紙の通帳は依然として原本であり、国税庁は税務調査の際に原本の提示を求めることがあります。青色申告者のベストプラクティス：通帳をExcelに抽出して会計業務に使用する一方、紙の通帳は法定の7年間保存期間中保管してください。抽出は手入力のステップを置き換えるものであり、法的記録を置き換えるものではありません。
確定申告シーズンをデータ入力マラソンではなくルーティンに
日本の確定申告期限（所得税の確定申告は3月15日）は動きません。毎年、全国の個人事業主、フリーランサー、小規模事業主は同じ流れに直面します：通帳を集め、机の上に広げ、1行ずつ取引をスプレッドシートや会計ソフトに転記していく。通帳の5列形式は簡潔で美しく、手作業が簡単に感じられます。しかし27ページ目に達したとき、桁位置を間違えて入力した1つの数字が残高欄の残りを静かに狂わせ、5分で終わるはずの照合作業が2時間かかることになります。
ここで説明する抽出ワークフローは、その流れを根本から変えます。1月と2月を再入力に費やす代わりに、通帳ページのスキャンに1日、列の定義に数分、そして期限前の残りの時間を、青色申告の控除が本来報酬として設計されたことに使います：紙から再構築するのではなく、ビジネスの財務実績を分析することです。
同じ列スキーマは来年も使えます。通帳の形式は、全国銀行協会が定義し、銀行ATMが印刷し、全国のすべての金融機関で標準化されているもので、変わりません。毎年変わるのはページ数と3月15日の期限の近さだけです。再入力ステップをなくすことで、プレッシャーは照合にかかります。そして、各行に数学的な監査証跡を内蔵した文書にとって、照合こそ時間をかける価値のある部分なのです。