銀行明細を手入力なしできれいなスプレッドシートに変換する方法

経理担当者に月曜の朝はどんな様子かと尋ねれば、たいてい同じような決まりごとが返ってきます。PDF の銀行明細を山ほど開いて、ひたすら入力を始める。日付、摘要、金額、残高。一行また一行、一通また一通、一社また一社。十数件の口座を扱う事務所なら、毎月ほぼ丸一日が、PDF を作ったときにコンピューターがすでに一度読み取っている数字を、また打ち直す作業に費やされます。

もどかしいのは、量の多さではありません。そのデータは銀行が作った時点ですでに構造化されていたのに、ページレイアウトの中に押し込められてしまい、今度は人間が手作業でそれを逆算して取り出さなければならない——そこが問題なのです。

この記事では、そのデータを再び取り出す方法を順を追って説明します。手入力なしで、きれいな Excel・CSV・JSON へ。なぜ銀行明細は抽出が特に難しいのか、よくある手法それぞれのトレードオフ、そして Ztract を使った手順を一歩ずつ——うまくいかない場面と、そのときどうするかも含めて取り上げます。

銀行明細が見た目以上に手強い理由

請求書やレシートも厄介ですが、銀行明細は難易度がもう一段上です。理由はいくつかあります。

• 銀行ごとにレイアウトが違う。 標準というものがありません。Chase、HSBC、地元の信用組合、ネオバンク——それぞれが列、日付、繰越残高の並べ方をバラバラに決めています。ある銀行向けに作ったテンプレートは、次の銀行ではまったく役に立ちません。
• 表がページをまたぐ。 ひと月分が四〜五ページに及ぶこともあり、取引明細の表が途中で切れてページヘッダーの後に再開します。素朴な抽出では、続きの行を取りこぼすか、ヘッダーをデータとして重複させてしまうかのどちらかになります。
• PDF か、スキャンか、写真か。 オンラインバンキングからダウンロードした明細はテキストベースできれいです。同じ明細を支店でスキャンしたり、スマホで撮影したりすると画像になります——こうなると、何かを抽出する前に OCR が必要で、OCR はそれ自体の読み取り誤りを持ち込みます。
• 照合を壊す細かな落とし穴。 -1250.00 ではなく (1,250.00) と括弧で表された出金。3月6日とも6月3日とも取れる、あいまいな 03/06 という日付の書き方。数字にぴったりくっついた通貨記号。桁区切りのカンマ。どれも小さなことですが、読み違えればスプレッドシートを静かに汚していきます。

「銀行明細をただ抽出する」とうたう手法は、これらすべてに答えを用意していなければなりません。手作業のもどかしさの大半は、うまくいく場合ではなく、こうした例外ケースの長い裾野から生まれます。

よくある手法と、それぞれが行き詰まるところ

唯一の正解というツールはありません——処理量と、明細のばらつき具合によります。正直なところ、トレードオフはこうです。

手入力。 準備はゼロ、注意深くやれば精度は完璧、そしてまったく拡張できません。月に一通なら問題なし。事務所では論外です。

Excel / Google スプレッドシートの「インポート」。 銀行が CSV エクスポートを提供しているなら、それを使いましょう——もっともきれいな道で、そもそも抽出は不要です。問題は、実際に人が受け取る書類のほとんどが PDF だということ。PDF の表を Excel に貼り付けると、レイアウトが完璧に格子状に揃っていない限り、たちまち列がぐちゃぐちゃになります。

テンプレート方式のパーサー。 各項目がページのどこにあるかを、一度だけ定義します。すべての明細がまったく同じ見た目なら、速くて安上がりです。けれど銀行ごとに違うため、結局は銀行ごとにテンプレートを作って保守する羽目になり——銀行がレイアウトを少しいじった日には、また作り直しです。明細がよほど均一でない限り、初期設定のコストが時間の節約を食いつぶしてしまいます。

LLM ベースの抽出。 位置を指定する代わりに、欲しい項目を普通の言葉で説明すれば、エンジンが各レイアウトに合わせて適応します。これは「銀行ごとに違う」という問題に正面から対応でき、スキャンや変わった書式にもずっと寛容です。トレードオフは、出力を検証できるツールを選びたいという点。固定された座標ではなく、ページを読み取るモデルを信頼することになるからです。

Ztract はこの最後のカテゴリーに位置するので、具体的に手順を追ってみましょう。

手順：Ztract で銀行明細をスプレッドシートに

これが一連の流れです。一通の明細でも、五十通入ったフォルダでも、使う手順は同じです。

1. プロジェクトを作り、欲しいものを定義する

プロジェクトとは、関連する書類と、それに適用するスキーマをまとめておく入れ物にすぎません。銀行明細の場合、そのスキーマを定義する方法は三つあります。

• 既製の銀行明細スキーマから始めて調整する。これがいちばん手早いスタートです——取引日、摘要、出金・入金の金額、繰越残高をあらかじめ把握しています。

• 項目を普通の言葉で説明する。 たとえば、こんなふうに。

  「各明細について、口座名義人、口座番号、対象期間、期首残高、期末残高を抽出してください。次に各取引について、日付、摘要、金額（出金はマイナス）、繰越残高を抽出してください。」

  括弧の中の指示——「出金はマイナス」——に注目してください。このひと言が、(1,250.00) という括弧表記をきれいな -1250.00 に正規化する方法をエンジンに伝えます。これこそ、テンプレートパーサーを脱線させる類いの例外ケースそのものです。

• サンプルから推論する。 代表的な明細を一通投げ込めば、Ztract がそこからスキーマを提案します。ある銀行がどんな項目を含んでいるか、一通見るまで分からないときに便利です。

ここでの大きな利点は、同じスキーマが銀行をまたいで機能することです。位置ではなく、欲しいデータを説明しているので、これまで見たことのないレイアウトも同じように扱えます。

2. 明細をアップロードする

ファイルをドラッグして放り込むだけ——PDF、Word、Excel、スキャン、スマホの写真、一ファイルあたり 500 MB まで。テキストベースの PDF も画像ベースのスキャンも、どちらも使えます。スキャンはまず OCR にかけられるだけです。ひと月分の明細が別々のファイルになっていても、まとめてアップロードすれば、スキーマがそのすべてに適用されます。

3. 確認して修正する——ここがいちばん肝心

銀行明細がその評判を裏付けるのが、まさにこの工程。腰を据えて取り組む価値があります。Ztract は抽出した各値を、元のページ上の正確な位置に紐づけて表示します。結果の中の数字をクリックすると、それが明細のどこから来たのかがハイライトされます。

この左右並びの表示こそ、検証を速くしてくれるものです。すべての数字を原本と照らし合わせて再確認する代わりに、おかしく見えるものだけを拾い読みして——取引が違う日付に着地している、繰越残高の計算が合わない——ワンクリックで直します。そして、課金するのは抽出に対してだけなので、値の修正にはまったく費用がかかりません。 後からの編集作業は無料で、ページパックから差し引かれるのは抽出したページだけです。

複数ページにわたる明細では、ここがページの切れ目をまたいで表が正しくつながったかを確認する場所でもあります——続きの行がちゃんと通っているか、繰り返されたページヘッダーが幻の取引として紛れ込んでいないか。

4. エクスポートする

正しく見えたら、Excel・CSV・JSON へエクスポート——一通の明細でも、プロジェクト全体を一度にでも。そこからは、あなたの照合ワークフローへ、会計ソフトのインポートへ、あるいは数字が次に向かうべきどこへでも、そのまま流し込めます。

それでも人の目が必要な場面

うまくいかない場面を隠すより、難しいところを正直にお伝えします。注意したい状況がいくつかあります。

• 複数通貨の明細。 明細に複数の通貨が混在している場合は、取引ごとに通貨を取り込むようスキーマで明示し、確認の工程で合計を必ず見直してください。書類全体が単一通貨だと思い込まないこと。
• ひどく劣化したスキャン。 FAX で送って再スキャンした、印字の薄い明細は、OCR を含め誰にとっても読みづらいものです。元の書類があなたの目で判読できないなら、より念入りな検証を覚悟してください。同じ書類でも、きれいにスキャンし直すほうが、後からどれだけ修正するよりも勝ります。
• 結合された、あるいは不規則なセル。 摘要のセルを複数行にわたって結合する銀行や、ひとつの取引を見た目上二行に分ける銀行があります。確認の工程は、まさにこうしたものを捕まえる場所です。だからこそ私たちは、抽出を「投げっぱなし」にせず、この工程を素早くこなせるように作りました。

私たちが対応できるはずのレイアウトが誤って返ってきたら、ぜひ見せてください——サンプルを（必要なら匿名化して）support@ztract.com までメールいただければ、私たちが調べます。皆さんが送ってくださる書類こそ、エンジンが良くなっていく糧です。

機微な金融データについて

銀行明細は、書類の中でもとりわけ機微なものです。だからこそはっきりお伝えします。私たちは、アップロードされた書類でモデルを学習させることはありません——自社のエンジンも、私たちが経由する第三者の LLM もです。私たちが利用している商用 API は、送信されたデータでの学習を禁じており、私たちはその約束に依拠しています。明細を削除すると、稼働中のストレージからは即座に、バックアップからは 14 日以内に消去されます。詳しくはプライバシーポリシーとデータ処理契約をご覧ください。

ご自身の明細で試してみる

これが自分のワークフローに合うかどうかを知る最短の道は、本来なら手で打ち込むはずの明細で実際に動かしてみることです。新規アカウントには30 ページの無料枠があり、クレジットカードも不要——実際の明細を何通か最初から最後まで抽出し、出力がどれほどきれいかを確かめるのに十分です。

明細を大量に処理していて、何がうまくいって何がダメだったか率直なフィードバックを共有してもよいという方は、ぜひご連絡ください——私たちは早期ユーザーの導入を進めており、人々が実際に苦労している書類を軸に、次に作るものを形づくっています。銀行明細は、そのリストのかなり上位にあります。

銀行明細の抽出についてさらに詳しくは、銀行明細抽出のユースケースページをご覧ください。