月末が近づくと、経理担当がメールを1件ずつ開いて、件名と添付ファイルを確認して、スプレッドシートの行を追加して、PDFをフォルダに移して、ファイル名を変えて、という作業を黙々とやっている。これが毎月のルーティンになっている会社が、わりとある。
請求書の枚数が少ないうちはまあいい。でも、取引先が増えてくると「月末に一人が丸一日これだけ」みたいな状況になる。しかも内容を確認した上で台帳に入れないといけないから、ずっと目を離せない。自動化とは遠い世界に見える作業の典型です。
ただ、この流れは切り分けると意外とシンプルです。
流れの全体像
やりたいことを分解すると、こうなります。
メール受信（請求書PDF添付）
↓ 自動で添付ファイルを取り出す
OCRで読み取る
↓ 請求元・金額・支払期限・請求書番号を抽出
Slackに投稿（「こういう請求書が来ました」）
↓ 担当者が内容を確認
問題なければ承認ボタンを押す
↓ 自動で管理シートに1行追記
↓ ファイルを命名規則でリネームしてドライブに保存
出口まで人が介在するのは「Slackで内容を確認して承認ボタンを押す」ところだけ。そこはむしろ人が見るべきで、勝手に台帳に入れてほしくない。確認ルートを残しながら、転記とファイル整理は機械に任せる、という設計です。
4つの部品
この仕組みは大きく4つの処理が組み合わさっています。
1. メール監視と添付ファイルの取り出し
特定のメールアドレスや件名パターンで請求書メールを検知して、添付のPDFを自動で取り出す処理です。Gmailを使っているなら、AIにこう頼むと仕組みを作れます。
Gmailで届いたメールのうち、件名に「請求書」か「invoice」が含まれるものを自動で検知して、添付ファイルを取り出してほしい。取り出したファイルは一時的に保存して、次の処理に渡す
2. OCRで必要な情報を抽出
取り出したPDFを、AIが読める形に変換して、必要な項目を抜き出します。
請求書PDFをOCRで読み取って、次の項目をJSON形式で返してほしい：請求元の会社名、請求金額（税抜・税込）、請求日、支払期限、請求書番号。読み取れない項目は「要確認」にして
ここが一番ハマりやすいところで、フォーマットがバラバラな請求書を読ませると精度が下がります。取引先のフォーマットが統一されている場合は精度が出やすく、手書きや独自フォーマットが多い場合は後述の「Slack確認」ステップが特に大事になります。
3. Slackに投稿して確認を取る
抽出した情報をSlackに投稿します。ここで「合ってそう」「金額が違う」をスレッドで修正できるようにしておくと、OCRミスが台帳に入るのを防げます。
抽出した請求書情報をSlackの指定チャンネルに投稿して。投稿フォーマットはこんな感じで：
【請求書受信】 請求元：○○ 請求金額：○○円（税込） 支払期限：○○ 請求書番号：○○
承認ボタンと、「修正する」ボタンをつけて。修正する場合はスレッドに正しい値を書いたら反映されるようにして
承認を取る人が決まっていれば、そのSlackユーザーへのメンション付きで投稿する設計にします。
4. シート追記とファイル保存
承認されたら自動で動く処理です。
Slackで承認されたら、管理スプレッドシートの末尾に1行追加して。列はA列から：受信日、請求元、金額（税抜）、金額（税込）、支払期限、請求書番号、担当者名。
同時に、添付ファイルを「YYYYMMDD_請求元名_金額.pdf」の形式でリネームして、Driveの「請求書管理」フォルダ配下の当年月フォルダに保存して
ファイル名の規則は会社によって違うので、ここは依頼時に実際の命名ルールをそのまま伝えるのが確実です。
OCRが読み間違えた場合
一番心配されるのがここです。OCRが金額を誤読して、そのまま台帳に入るケース。
設計で対処できる方法は2つあります。一つは前述のSlack確認ステップで、人が一度見てから台帳に入れる仕組みにすること。もう一つは、読み取り結果に「信頼度スコア」を持たせて、低い場合は承認を必須にして目立つ形で投稿すること。
OCRの読み取り精度が70%を下回った項目は「要確認」フラグを立てて、Slack投稿のときに赤字か絵文字で目立たせて。この場合は承認ボタンを押せないようにして、手動で値を入力してから確定できるようにして
完全に任せきりにするより、「怪しいときは止まる」設計の方が実運用に乗りやすいです。
注意しておくこと
よくある落とし穴を書いておきます。
まず、メールのどれが請求書かを判定するルールは最初に決めておく必要があります。件名で「請求書」を含むものを取る設計にすると、「請求書の件でご確認を」みたいな本文のみのメールも引っかかることがある。添付ファイルがあるかどうかの条件と組み合わせるのが無難です。
次に、Driveのフォルダ構造です。年月別に作るなら、フォルダがなければ自動作成する処理が要ります。最初にこれを忘れると「フォルダが見つかりません」でエラーになります。
もう一点、スプレッドシートの列順は初期設計で決めてしまった方が後が楽です。途中で列を追加すると、既存の書き込み処理がずれます。
どこから始めるか
3つの機能（メール受信、OCR読み取り、Slack承認フロー）がつながっているので、全部を一気に組もうとすると詰まりやすいです。
おすすめは、最初は「メール受信してSlackに転送するだけ」まで動かして、次に「OCRで読んで構造化した情報を投稿」、最後に「承認で台帳とDriveに流す」という順番で進めること。各ステップで想定通り動くか確認しながら積み上げていく方が、後で原因を追いやすいです。
これが効く状況
毎月の請求書枚数が10枚以下なら、正直なところ手でやっても大した時間ではありません。効くのは、月に30枚以上処理している、担当者が月末に他の仕事を圧迫されている、転記ミスが起きると後始末が大変、といったケースです。
逆に、請求書のフォーマットが取引先ごとにかなりバラバラで手書きも多い、という場合は、OCR精度の調整に時間がかかるので過度な期待は禁物です。「読み取れない時は止まって確認」という割り切りで組むのが現実的です。