n8n × AI で請求書 OCR から仕訳起票までを自動化する｜経理部門が月20時間を取り戻す実装ガイド

なぜ請求書処理だけが、いまも人手で残っているのか

クラウド会計が普及してから10年以上が経ちますが、多くの中小企業では『紙やメール添付で届いた請求書を、人が目で見て、会計ソフトに転記する』という工程がいまだに残っています。なぜここだけ残るのか。理由はシンプルで、請求書はフォーマットが取引先ごとに違い、項目の場所も呼び方もバラバラだからです。

OCR だけでは不十分でした。値が取れても『これは消耗品費か事務用品費か、それとも雑費か』という勘定科目の判断は、過去の仕訳パターンと社内ルールを参照しないと決まりません。結果として『OCR で読んだ後に人が確認する』という二度手間が発生し、自動化のメリットが薄まっていたのが従来の限界です。

ここに 大規模言語モデル（LLM） の登場で潮目が変わりました。Claude や GPT は、勘定科目マスタと過去の仕訳例を渡せば、未知の取引先の請求書でも『おそらく消耗品費（信頼度0.93）』のような確率付きの分類を返してきます。OCR + LLM + 業務システム API を n8n でつなぐ ことで、受信から登録までを人手なしで通せる時代に入りました。

n8n × AI 請求書処理 全体アーキテクチャ

まず全体像から押さえます。本記事で扱う構成は、3つのレイヤー に分かれます。トリガー（どこから請求書が来るか）、n8n ワークフロー（自動化の中核）、外部システム（会計ソフトや通知先）です。

このアーキの肝は、n8n という1点に処理ロジックを集約している ことです。Gmail でも Drive でも Slack でも、入口が増えても処理本体は1つで済む。出口も同じで、freee に加えてマネーフォワードや kintone に書き分けたい場合、n8n の最後のノードを増やすだけで済みます。SaaS の組み合わせは年々変わるので、ハブ＆スポーク構造 にしておくことが長期運用の鍵になります。

4層の役割設計 — どこに何を任せるか

全体像の中の『n8n ワークフロー』を、さらに4つの層に分けて設計します。各層が独立した責務を持つことで、後から OCR エンジンや LLM を入れ替えてもワークフロー全体を作り直す必要がなくなります。

1. トリガー層 — Gmail webhook・Google Drive 変更検知・cron スケジュールなど『いつ動くか』を決める。請求書到着が即時のフロー（リアルタイム）と、毎朝9時にまとめて処理するバッチを 両方持つ のがおすすめ。
2. OCR層 — 画像 / PDF からテキスト座標とともに抽出する層。Mistral OCR・Gemini Vision・GPT-4o Vision のいずれかを使う。表組みや手書きへの強さで選択する。
3. 分類・抽出層 — OCR が吐いたテキストを 構造化データ に変換する LLM 層。勘定科目・税区分・仕訳項目を確定させる。Claude Opus 4.7 や GPT-5.5 の Structured Output 機能が使える。
4. 連携層 — 構造化データを freee / MF / kintone などの会計システムに POST する。エラーハンドリングとリトライ設計はここで行う。

OCR エンジンの選び方 — 何を基準に決めるか

OCR 層で何を使うかは、扱う請求書の性質で決まります。日本の中小企業で多いのは『PDF で送られてくる発行系』『紙をスキャンした手書き混在系』『楽天市場や Amazon の自動メール系』の3パターンです。

実運用上のコツは OCR を1つに絞らないこと です。n8n の分岐ノードで『PDF なら Mistral、画像なら Gemini、手書きなら GPT-4o』のように振り分けると、コストと精度のバランスが取れます。OCR の前段に簡単な判定ロジック（ファイル種別・ページ数・解像度）を1ノード挟むだけで、月額の API 費用が3〜4割変わるケースもあります。

勘定科目を AI に正しく分類させるプロンプト設計

OCR が読めても、それを正しい勘定科目に紐付けないと自動化は止まります。ここが従来 RPA 系ツールでは詰まっていたボトルネックで、LLM のプロンプト設計 が真価を発揮する領域です。

重要なのは Few-shot 例（過去仕訳のサンプル） の質です。汎用の請求書解説プロンプトを使うのではなく、自社の過去仕訳から代表的なパターンを20〜30件抽出して、prompt に埋め込みます。これだけで分類精度は8割から9割半ば以上に上がります。出力は必ず JSON で固定し、confidence フィールドも一緒に返させることで、次の HITL 分岐に使える設計にします。

{
  "vendor": "Amazon Japan G.K.",
  "invoice_date": "2026-05-10",
  "amount_total": 12800,
  "tax_rate": "10%",
  "qualified_invoice_no": "T1234567890123",
  "kanjo_kamoku": "消耗品費",
  "zeikubun": "課税仕入10%",
  "memo": "事務用品（USBハブ・ケーブル）",
  "confidence": 0.93,
  "reasoning": "取引先がAmazonであり、過去仕訳でも事務用品の購入は消耗品費に計上されている。"
}

freee / マネーフォワード / 弥生に書き込む実装ポイント

構造化データができれば、後は会計システムの API を叩くだけです。freee 会計 API を例にすると、POST /api/1/deals で取引登録、POST /api/1/journals で仕訳直接登録ができます。マネーフォワード・弥生・勘定奉行 でもほぼ同等の API があります。

{
  "company_id": 12345,
  "issue_date": "2026-05-10",
  "type": "expense",
  "partner_id": 67890,
  "details": [
    {
      "account_item_id": 520,
      "tax_code": 21,
      "amount": 12800,
      "description": "事務用品（USBハブ・ケーブル）"
    }
  ]
}

実装時の落とし穴は3つあります。第一に 取引先マスタの突合 です。LLM は『Amazon Japan G.K.』と『AmazonJapan』を別取引先として返すことがあるので、n8n 側で正規化テーブルを持って ID 解決します。第二に 重複登録の防止 で、請求書番号や金額＋日付のハッシュをキーに冪等性を担保します。第三に エラー時のリトライ戦略 で、API のレート制限や一時的な401はリトライ、データ形式エラーは即座に HITL（人間レビュー）に回すべきです。

インボイス制度（適格請求書）チェックを組み込む

2023年10月のインボイス制度開始以降、適格請求書発行事業者の登録番号チェックが経理の新しい工数になっています。OCR で読み取った登録番号（T+13桁）を、国税庁の公表サイト API に問い合わせて、登録の有無・事業者名の一致を確認できます。

n8n の連携層に1ノード追加するだけで、未登録事業者からの請求を自動で検出し、Slack で経理担当にアラートを出せます。仕入税額控除のリスクを未然に防げるので、インボイス対応の中で最も投資対効果が高い自動化 の1つです。

HITL（人間レビュー）の境界をどこに引くか

AI に全部任せるのではなく、信頼度（confidence）に応じて人間が関わる範囲を制御する のが運用の肝です。これを Human-in-the-Loop（HITL）と呼びます。LLM の出力に含まれる confidence スコアを、3段階に分けて分岐します。

• confidence ≥ 0.90 → 自動承認：そのまま freee に登録。月次決算で経理が結果ログを目視確認するだけで足りる。
• 0.70 〜 0.89 → ボタン承認：経理担当の Slack に通知し、ワンクリックで承認 or 修正。決裁の負荷をほぼゼロにできる。
• < 0.70 → 上長レビュー：内容不明・初出取引先などは経理マネージャや CFO のレビューに回す。AI への再質問やヒアリングのテンプレも自動生成しておく。

この設計の重要な副産物が学習ループ です。人間が修正したケースを Few-shot プールに自動で還流させると、次の請求書からは同種の判断が confidence 高めで返ってきます。月単位で運用していると、3〜6ヶ月で初期の自動化率（仮に70%）が90%超まで上がる、というのが多くの導入企業に共通する経験則です。

導入の段階設計 — どこから着手するか

請求書 OCR から仕訳起票までの自動化は、いきなり全社展開を狙うとほぼ確実に失敗します。理由は、組織ごとに取引先パターンと勘定科目運用が違いすぎるためです。3 ヶ月単位の段階設計 で進めると、現場の納得感を保ちながら自動化率を伸ばせます。

1. 第 1 段階（着手 1〜4 週目） — 月の請求書件数が多いカテゴリを 1 つ選び、OCR 層と LLM 分類層をパイロット稼働させる。HITL を 100% 通す（自動承認は使わない）。狙いは精度測定とプロンプト調整。
2. 第 2 段階（5〜8 週目） — 自動承認の信頼度しきい値を 0.95 程度から開始。経理担当がボタン承認を行う中で Few-shot プールに学習データが溜まる。同時に freee / MF への自動登録を ON にする。
3. 第 3 段階（9〜12 週目） — しきい値を 0.90 まで下げ、自動承認の比率を引き上げる。並行してインボイス制度チェック・売掛金管理など隣接領域への横展開を始める。

重要なのは 第 1 段階を 4 週間より急がない ことです。LLM の精度は Few-shot プールの質に強く依存し、そのプールは現場の修正データが溜まるまで成熟しません。最初の 1 ヶ月は『投資』と割り切って、急いで自動承認を入れないでください。

典型的な失敗パターン

導入支援の現場で繰り返し見るアンチパターンを 3 つに整理しました。これを事前に知っているだけで、立ち上げの躓きを大幅に減らせます。

• プロンプト未調整のまま自動承認を ON — 汎用の請求書解説プロンプトのまま自動仕訳に流すと、勘定科目の誤りが月次決算で雪崩のように発覚する。Few-shot 例を 20 件以上揃えてから自動承認に入る。
• HITL の Slack ボタンを設計しない — 信頼度 0.70〜0.89 のレンジで AI が判断保留を返した時、経理担当が修正できる UI が無いと『AI に振り回されている感』だけが残る。Slack 上で 1 クリック確定できる導線を最初に作る。
• 取引先マスタの名寄せを後回し — 同じ取引先が複数表記（『Amazon Japan G.K.』『AmazonJapan』『Amazon』）で並ぶと、月次集計時に取引先別の合計が出せない。LLM 出力の取引先名は必ず正規化テーブルを通す。

投資回収と費用感の目安

クラウド版の自動化サービスではなく n8n セルフホストで構築する場合、ゼロから組み立てる工数は規模によって 40〜80 時間程度が一般的です。月額ランニングコストは VPS の数千円 + LLM API 利用料が中心で、件数規模にもよりますが 1〜2 万円程度に収まるケースが多いです。経理 1 名の人件費に換算すれば 半年程度で投資が回収できる水準 に入りますが、これは件数・複雑度・既存システムとの連携の程度で大きく変動します。

まとめ — 経理AXの最初の一歩として最適

請求書 OCR から仕訳起票までの自動化は、経理 AX を始める最初の打ち手として効果と費用対効果の両面で最も筋がいい 案件です。OCR と LLM が成熟したことで、ようやく『OCR で読んで人が確認』の二度手間を解消できる時代になりました。n8n のような自動化基盤を1つ持っておけば、請求書だけでなく経費精算・売上計上・入金消込まで横展開でき、経理部門のあり方そのものを再設計できます。

重要なのは『最初から100点を狙わない』ことです。confidence による HITL 分岐を組み込んで、人間と AI が学び合うループを作る。そこから少しずつ自動化率を上げていくのが、現場で定着する最短ルートです。