紙の通帳問題
日本の中小企業が気づかぬうちに負担しているコスト

通帳パラドックス：2024年の会計ワークフローに残る1970年代の書類

日本は、物理的な銀行通帳が今なお大衆向け金融商品として残る、先進国で唯一の国です。MUFGやSMBCの支店に行けば、ATMが最新の取引を直接、綴じられた通帳に印字します。ドットマトリクス印字ヘッドで5つの列——日付（月日）、摘要コード（摘要）、引き出し金額（お支払金額）、入金金額（お預り金額）、残高（差引残高）——が並びます。この形式は、銀行の窓口係が手作業で残高を確認し、CSVエクスポートという概念すら存在しなかった時代に設計されました。それ以来、実質的に変わっていません。

しかし、日本の中小企業が使う会計ソフトウェア——70万以上の事業者が利用する弥生会計、クラウド会計市場のリーダーで45万の有料顧客を抱えるfreee、そして44万2千の有料事業者を持つマネーフォワード クラウド——は、根本的に異なる前提で動いています。取引データはデジタルで届くという前提です。CSVインポート、銀行API連携、自動仕訳ルール。通帳は、その前提のすべてを一度に覆します。

これは「デジタルリテラシー」の問題でも、「日本は遅れている」という決まり文句でもありません。書類形式のミスマッチです。金融活動を記録するインフラと、それを仕訳するインフラが、50年の隔たりを持ち、互いに連携する必要のなかった異なる業界によって構築され、その橋渡しを人間が読み取りと再入力で担わされているのです。

ゆうちょ銀行だけでも約1億2千万口座——国民一人あたりほぼ一つの割合——を保有しています。MUFG、SMBC、みずほを合わせれば、さらに数千万の口座があります。それらの口座のほとんどは、今でもデフォルトで紙の通帳を発行します。インターネットバンキングを利用している顧客でさえ、日常的な確認にはデジタル、確定記録には通帳と、両方を持つことがよくあります。青色申告を行う個人事業主にとって——所得税法第143条に基づき、適正な複式簿記と引き換えに65万円の特別控除が認められる——通帳の各ページのすべての取引は、仕訳帳の記録に遡れる必要があります。通帳は任意のものではありません。それは証拠書類なのです。

構造的な問題を率直に言えば、人間の窓口係が目視で残高を確認するために設計された書類が、機械可読な取引データフィード用に設計されたソフトウェアの主要なデータソースとして使われているのです。ミスマッチは完全であり、そのコストはすべてキーボードの前にいる人間にのしかかります。

本当の作業は入力ではなく「翻訳」にある

通帳のデータ入力の問題は、よく「入力に時間がかかりすぎる」と説明されます。しかし、この捉え方は間違っています。しかも、実際に労力がかかる部分を見えなくしてしまう形で間違っています。入力速度がボトルネックなのではありません。本当のボトルネックは、通帳の1行ごとに、キーを打つ前に一連の「頭の中での翻訳」が必要になるという点にあります。

通帳の1行を声に出して読んでみてください。いくつの判断が必要か数えてみましょう。

5つのフィールドを入力するのにかかる時間は数秒です。しかし、本当の時間がかかるのは上記の4つの判断であり、これらは入力速度に関係なく、すべての行で求められます。通帳のデータ入力を行う人は、単なるデータ入力係ではありません。銀行コードの略号、元号の計算、会計科目のロジックをリアルタイムで解釈する通訳者なのです——しかも、それらの翻訳レイヤーが存在する以前に設計された機械が印字した書類を相手に。

同じ構造的なギャップ——文書の形式と出力先のシステムが異なる言語で記述されており、人間が翻訳しなければならない——は、国境を越えて現れます。英国のフリーランサーは、銀行取引明細書や請求書をSA100フォームの各欄に変換する際にほぼ同じミスマッチに直面し、オーストラリアの給与計算チームは、PAYGサマリーが給与計算ソフトでネイティブに読み取れない形式で届くという問題に遭遇します。日本の通帳は、同じ構造的な摩擦を、日本独自の要素である「銀行ごとに異なる摘要コード体系」で何倍にも増幅させているのです。

なぜ銀行ごとに異なる言語を話すのか：誰も語らない「摘要コード問題」

日本の通帳の摘要欄は、ページ上で最も情報量が多く、かつ最もわかりにくい項目です。これは取引の人間が読める説明文ではありません。銀行固有の省略コードであり、漢字、カタカナ、半角カタカナ、英数字が混在した形で、ATMのドットマトリクス印字ヘッドが印字する狭い欄に収まるよう、おおよそ12～16文字程度に切り詰められて印字されます。

MUFG銀行だけでも、参考資料に200種類以上の摘要コードが掲載されていますが、それでもよく使われるものだけです。同じ取引内容が、主要な通帳発行機関でどのように異なるかを、いくつか例示します。

これは単なる小さな不便さではありません。日常業務用にMUFG、税金積立用にゆうちょ銀行、給与用に地域の信用金庫——というように3つの通帳を管理している小規模事業主は、3つの異なる摘要コードの語彙に直面することになります。同じ経済事象が通帳ごとに異なる名前で表示され、それを統一的に解読する仕組みはありません。事業主は、無報酬の副業として暗号解読者にならざるを得ないのです。

Yahoo 知恵袋（日本最大のQ&Aフォーラム）で、現役の会計士が次のような質問を直接投げかけました。「顧客の通帳取引履歴をすべて手入力でExcelに打ち込まなければなりません。手作業に膨大な時間がかかっています。マネーフォワードやfreeeのような会計ソフトを使わずに、通帳の取引履歴をExcelに変換する方法はないでしょうか？」 最も支持された回答は現実的で、「顧客にネットバンキングに登録してもらい、データをダウンロードしてもらう」というものでした。2番目の回答は、より率直に実情を述べています。「OCRは存在しますが、読み取りエラーがないか確認する必要があります。その確認だけでかなりの時間がかかります。」

合計記帳：銀行の解決策が生み出すあなたの問題

日本の通帳システムには、記帳を怠ると不便さが構造的なペナルティに変わる機能が組み込まれています。それが合計記帳です。これは、勤勉な者には報い、忙しい者には機械的な無関心で罰を与えます。

MUFGでの仕組みは次の通りです。他のほとんどの日本の銀行も同様の仕組みを採用しています。ATMに行って通帳を更新していないため、口座内に取引が蓄積され、通帳に印字されないままになると、銀行は最終的にそれらを統合します。年に2回、5月と11月の第3土曜日に、MUFGは全口座をスキャンします。3月末または9月末時点で、未記帳の取引が一定数を超えている口座は、それらの取引が1行にまとめられます。合計記帳という1行に、取引件数とその合計純額だけが表示されます。個々の取引の日付、金額、摘要コードはすべて、通帳から永久に失われます。

通帳を主要な記録として頼っている人にとっての結果は次の通りです。

• 失われた取引を通帳から復元することはできません。 個々の行は紙の上に存在したことがありません。それらは未記帳の電子記録としてのみ存在し、統合処理によって上書きされました。
• 3月と9月はまさに、中小企業が四半期または半期の財務諸表を作成する時期です。 統合のトリガーは、事業主が最も詳細なデータを必要とするまさにその瞬間と一致します。
• 特定の取引に異議を唱えることが不可能になります。 20万円が6回の取引に分けて引き出され、それが統合された場合、どの引き出しがどれで、それぞれがいつ発生し、摘要コードが何だったのかを特定できません。税務調査において、これは記録の欠落となります。

MUFGのウェブサイト自身も、このシステムをほとんどおまけのように記載しています。「合計記帳を避けるため、定期的に通帳を記帳してください」という脚注に埋もれています。そのトーンは、毎週銀行に通って最新の取引を記帳する退職者を想定しています。レストランや工房、コンサルティング業を営み、せいぜい月に一度しか銀行に行けない中小企業の経営者にとって、合計記帳は時間に対する税金であり、悪化の一途をたどります。記帳を怠ればデータは永久に失われ、銀行に取引履歴の印刷を依頼する以外に帳簿の穴を埋める方法はありません。そして、その依頼には、ありがたいことに約1週間かかり、普通郵便で届きます。

ゆうちょ銀行の処理方法はこれとは異なります。決まった日付での集約ではなく、通帳のページ制限に基づいています。標準的な通帳1冊には、銀行にもよりますが、おおよそ50～100行の取引明細が印字されます。ページがなくなると、ATMが自動的に新しい通帳を発行します。古い通帳の最終印字行と新しい通帳の最初の印字行の間の取引は、新しい通帳の最初のページにまとめて表示されます。その間の個々の取引は？紙の上からは消えます。新しい通帳は、繰り越された残高のみでスタートし、履歴はありません。

通帳は、人々が毎週銀行を訪れ、新しい行を一つずつ手作業で確認する世界のために設計されました。その世界では、合計記帳は合理的なスペース節約策です。しかし、通帳がデジタル会計ワークフローの元資料となる世界では、それはデータ破壊の仕組みです。ページ上にもう存在しないデータを自動化でどうにかすることはできません。

アプリだけではギャップを埋められない理由

日本の個人向け金融・会計アプリ——マネーフォワードME（利用者1,780万人）、Zaim、Moneytree、そしてビジネス向けのfreeeや弥生会計——は、いずれもAPI経由での銀行口座連携を提供しています。インターネットバンキングが有効になっている口座の場合、新しい取引は自動的にアプリに取り込まれます。毎月の支出を管理する家庭にとっては、これで将来の課題はほぼ解決します。

しかし、確定申告の準備をする個人事業主にとっては、全く不十分です。その理由は3つあります。

アプリは、最近の取引を表示し、分類を手伝うという点では優れています。しかし、1970年代の印刷文書と、構造化データを前提とする会計システムの橋渡しをするようには設計されていません。その橋渡しは今も人間が担っており、アプリは便利である一方で、両者の隔たりをユーザーに痛感させるだけにとどまっています。

エラーが連鎖する場所：残高の連鎖的誤差

個人事業主が扱う書類（請求書、領収書、発注書、納品書）の中で、通帳は決定的な点で異なります。それは、各行のデータが独立していないことです。各行の差引残高は、それ以前のすべての行が正しいことを前提としています。200行ある通帳の47行目で数字を1つ間違えると、47行目だけでなく、48行目から200行目までがすべて影響を受けます。エラーが発生した後に印字されるすべての残高が、実際の残高と一致しなくなります。

このため、他の書類にはない検証の負担が生じます。請求書の束なら、各請求書を独立して処理できます。23番目の請求書のエラーが24番目に影響することはありません。しかし通帳の場合、すべての行で残高を検証する（前回残高＋入金－出金＝今回残高を確認する）か、バッチ内のエラーが黙って連鎖するリスクを受け入れるかのどちらかです。多くの個人事業主は、店じまい後の深夜に作業する中で、リスクに気づかずに後者の選択をしています。

これは仮定の話ではありません。Yahoo 知恵袋では、あるユーザーが通帳データを手動でExcelに入力し、銀行取引明細と合計を照合する作業を報告していました。回答者はCSVダウンロードからOCRまで様々な解決策を提案しましたが、根本的な問題——たった1つのミスが最終的な合計が一致するまで検出されずに連鎖すること——は、この形式に内在するものとして認識されていました。ある回答者は、OCRを使っても「読み取りエラーをチェックする必要があり、そのチェックだけでかなりの時間がかかる」と指摘しています。通帳の場合、「チェック」とは数行を抜き打ちで確認することではありません。すべての行で残高の連鎖を検証することを意味します。

和暦問題：元号が変わるたびに年号がリセットされる

日本では、世界標準のグレゴリオ暦と、天皇の在位に基づく和暦の2つの暦が併用されています。通帳には和暦で日付が印字されます（例：令和6年3月15日）。弥生会計、freee、マネーフォワード クラウドといった会計ソフトはどちらの形式も受け付けますが、各日付がどの元号に属するかを指定しないと、相互に変換できません。そして元号が変わると、年号は1にリセットされます。

実務上の困難は、二重の暦体系が存在すること自体ではありません。問題は境界の年、つまり元号が年の途中で変わり、新旧両方の元号が同じグレゴリオ暦の年を指す年です。

3冊の通帳を管理し、青色申告を行う事業者にとって、元号問題は摘要コード問題と重なります。単に令和6年を2024年に変換するだけではありません。MUFGの通帳にある「振込TB1」が、ゆうちょ銀行の通帳にある「振込」と同じ入金かどうかを、片方の通帳が通帳繰越の直前、もう片方が直後に印字されたために元号表記が異なる月に、解読しながら処理しなければならないのです。

和暦はなくなりません。政府の書類、税務書類、銀行取引明細書はすべて和暦を使用しています。中小企業が使う会計ソフトはどちらの形式も受け付けます。しかし、その変換は依然として人間の手作業であり、変換のたびに年号の誤差が生じ、誤った課税年度に取引が計上されるリスクがあります。

解決の道は「速く打つこと」ではなく「翻訳層をなくすこと」

通帳ページと会計ソフトの間に手作業による翻訳層があるという構造的な問題に対して、「もっと速く入力する」とか「もっと良いアプリを使う」というのは解決策になりません。必要なのは、翻訳のステップを飛ばして通帳データを抽出する方法——つまり、通帳の5列フォーマットを読み取り、銀行固有の摘要略語を解読したり、元号を変換したり、残高を手作業で確認したりする必要なく、構造化データを直接生成する方法です。

この問題に適したアプローチはセマンティック抽出です。「日付」「摘要」「お引き出し金額」「お預かり金額」「差引残高」といった列の意味をツールに指定すると、固定テンプレートに合わせるのではなく、ドキュメントのレイアウトを理解して通帳ページを読み取り、各値を特定します。日本の通帳フォーマットは銀行間で標準化されているため（5列、同じ順序、同じ基本レイアウト）、セマンティックモデルはMUFG、ゆうちょ銀行、地域の信用金庫のページを同じ列定義で読み取ることができます。銀行ごとに変わるのは摘要コードだけですが、それらはツールがそのまま抽出するテキストであり、後でユーザーが分類すればよいのです。

これがカスタム列抽出の核となる考え方です。フィールドの周りにボックスを描いたり、銀行ごとに解析ルールを作成したりする代わりに、必要な列名を入力して通帳ページをアップロードします。AIが各ページを読み取り、表形式のレイアウトを理解して5列を特定し、トランザクションごとにスプレッドシートの行を生成します。計算列（例：「残高チェック（前回残高＋お預かり金額－お引き出し金額）」）を追加すれば、残高が合わない行をツールが自動的にフラグ付けするため、会計ソフトにデータを取り込む前にエラーが発生した箇所を正確に把握できます。

最初の通帳ページのアップロードからフォーマット済みスプレッドシートの取得までの、完全なステップバイステップの抽出ワークフローは、日本の通帳抽出ガイドに記載されています。また、複数年にわたる複数の通帳を処理する場合は、バッチ処理アプローチにより、異なる銀行のページを1つの支出台帳に統合し、すべての元号日付を変換し、すべての残高を1回の処理で検証します。これは、3冊の通帳×3年分＝280件の取引、1,400のデータポイントとなり、1ページずつの抽出では手作業による統合ステップが残ってしまう場合に重要です。

だからといって、通帳がなくなるわけではありません。日本の銀行インフラは、今後何年も通帳を発行し続けるでしょう。変わってくるのは、ATMの向こう側にいる人が、毎月、銀行コードの翻訳者と、増え続ける残高の監査人にならなければならないかどうかです。あるいは、抽出が数秒で完了し、人間の作業は、実際に人間の判断が必要な部分、つまり取引の分類と申告書の作成に移行するかどうかです。

よくある質問

毎月、机の上に積まれる通帳の束を次に目にしたとき——3冊の通帳、その間に約60行の新しい記帳、各行には5つの項目と4つの判断が含まれている——そこで実際に何が起きているのか、名前を付けてみる価値があります。それは「データ入力」でも「簿記」でもなく、昭和の時代から変わらない文書形式と、根本的に異なるロジックで動作する会計ソフトウェアの間での、リアルタイムの翻訳作業なのです。タイピングは仕事の中で最も小さな部分です。意味の解読——このコードは何を意味するのか、これは何年なのか、これはどの銀行の略称体系なのか——こそが時間を費やし、エラーが発生する箇所なのです。抽出が数秒で完了し、残された判断が数字をどう扱うかだけになったとき、あなたの通帳のページがどのように見えるかを、ぜひご自身の目で確かめてみてください。