【Dify×n8n実践】請求書・領収書処理を完全自動化！PDF受領からAI仕訳推論・インボイス判定・会計SaaS登録までをノーコードで繋ぐ最強パイプライン

業務効率化

2026.09.06

この記事は約11分で読めます。

1. はじめに：経理の月末月初を地獄に変える「名ばかりペーパーレス」の罠
2. なぜ「Dify × n8n」の組み合わせが最強なのか？
3. 自動化パイプラインの全体アーキテクチャ
4. Dify側の実装：請求書解析＆仕訳推論ワークフローの構築
5. n8n側の実装：データ取得から会計SaaS連携・Slack通知まで
6. 実運用で失敗しないための「3つの鉄則」
7. おわりに：経理を「データ入力作業」から解放し、戦略財務へ

1. はじめに：経理の月末月初を地獄に変える「名ばかりペーパーレス」の罠

「取引先から毎日のようにメール添付やクラウドストレージ経由で請求書PDFが届く」「電子帳簿保存法やインボイス制度に対応するため、PDFファイルを開いて適格請求書発行事業者番号（T番号）を目視確認し、金額や税率を手作業で会計ソフトに入力している」

多くの企業の経理・総務部門において、書類の「電子化（PDF化）」は進みました。しかし、現場の実態は**「紙がPDFに置き換わっただけで、人間が画面を目視して会計システムへ手入力する作業は何も変わっていない」**という、いわば「名ばかりペーパーレス」の泥沼に陥っています。

既存のAI-OCRツールを導入した企業でも、以下のような壁にぶつかります。

OCRの誤読・フォーマット崩れ: レイアウトが会社ごとに異なるため、特定項目の読み取りに失敗する。
勘定科目や税区分の推論ができない: 「この品名ならどの勘定科目にすべきか」という社内ルールの判断は人間に丸投げ。
SaaS間の連携が分断されている: メール受領 → OCR → 会計ソフト → 承認通知の各ステップが繋がっておらず、結局経理担当者が手動でデータを橋渡ししている。

このボトルネックを根本から破壊するのが、「Dify（ディファイ） × n8n（エヌエイトエヌ）」の強力なタッグです。

Dify（AI/RAGエンジン）: マルチモーダルVisionモデルと構造化プロンプトにより、自由形式の請求書PDFから「インボイス番号」「明細」「税区分」「推奨勘定科目」を高精度に推論・JSON抽出。
n8n（自動化オーケストレーター）: メール受信やGoogle Drive保存をトリガーに、Dify APIを呼び出し、会計ソフト（freeeやマネーフォワード）への下書き登録からSlackでの承認通知までを全自動で配管。

本記事では、この**「請求書・領収書の全自動処理パイプライン」**の設計から、Difyのワークフロー構築、n8nのノード設定、プロンプト設計までを完全解説します。

2. なぜ「Dify × n8n」の組み合わせが最強なのか？

自動化を進める際、「n8n単体」や「Dify単体」ではなく、両者を組み合わせる（疎結合にする）ことに大きな技術的・運用のメリットがあります。

役割 / ツール	Dify（頭脳・AI層）	n8n（神経・連携層）
得意領域	・高度なプロンプト管理とLLMの切り替え・RAG（社内勘定科目ルールの参照）・Visionによる画像・PDFの柔軟な意味解釈	・Gmail, Drive, Slack, 会計SaaS等とのAPI連携・エラー時のリトライ、分岐、バッチ処理・Webhookやスケジュール実行などのトリガー制御
組み合わせるメリット	AIのプロンプト改善やモデル変更（GPT-4o ↔ Claude 3.5 Sonnet）をDify側だけで完結でき、n8n側の複雑な業務フローを壊さずに済む。

「データを受け渡し・外部ツールを動かすのはn8n」「文脈を読み解き・判断するのはDify」と役割を明確に分けることで、極めて堅牢でメンテナンス性の高いシステムが構築できます。

3. 自動化パイプラインの全体アーキテクチャ

今回構築する処理の流れは以下の通りです。

4. Dify側の実装：請求書解析＆仕訳推論ワークフローの構築

まずは、Dify上で「請求書PDFを受け取って構造化JSONを返す」ワークフロー（Workflow）を作成します。

Step 1: Difyで新規「ワークフロー」を作成

Difyの管理画面から「最初から作成」→「ワークフロー」を選択し、アプリ名を Invoice-Parser-Agent とします。

Step 2: 開始ノード（Start）の入力パラメータ設定

入力変数:
- invoice_file（ファイル形式: 画像/PDFを許可）
- sender_email（文字列形式: 送信元メールアドレス）

Step 3: LLMノードの配置とVision設定

モデル: gpt-4o（PDFや画像を高精度に読み取れるマルチモーダルモデルを選択）
System Prompt（プロンプト設計）:

textあなたは上場企業のベテラン経理担当者です。入力された請求書/領収書のファイルを精査し、日本の税法および適格請求書等保存方式（インボイス制度）に準拠した形式でデータを抽出・推論してください。【勘定科目の判定ルール】・サーバー代、SaaS利用料、クラウドサービス → 「通信費」または「支払手数料」・書籍、勉強会、有料記事 → 「図書研究費」・飲食代（社外との会食、人数5名以上） → 「接待交際費」・タクシー代、電車代、航空券 → 「旅費交通費」・PC周辺機器、事務用品（10万円未満） → 「消耗品費」【インボイスチェック】・登録番号（「T」から始まる13桁の半角数字）が記載されているかを確認・税率（10%対象 / 8%軽減税率対象）ごとに税抜金額・消費税額が正しく区分記載されているかを検証【出力フォーマット】必ず以下のJSONスキーマに厳格に従って出力してください。Markdownのコードブロックは不要です。

出力JSONスキーマ:

json{  "vendor_name": "株式会社〇〇",  "invoice_number": "INV-2024-001",  "invoice_date": "2024-10-31",  "due_date": "2024-11-30",  "is_qualified_invoice": true,  "invoice_registration_number": "T1234567890123",  "total_amount": 110000,  "tax_amount_10_percent": 10000,  "tax_amount_8_percent": 0,  "suggested_account_title": "通信費",  "suggested_tax_category": "課税仕入 10%",  "description": "2024年10月度 クラウドサーバー利用料",  "validation_issues": []}

Step 4: 終了ノード（End）の設定

LLMノードの出力を result_json 変数として返し、ワークフローを「公開」します。 API設定から API Key（例: app-xxxxxxxxxxxx）を発行しておきます。

5. n8n側の実装：データ取得から会計SaaS連携・Slack通知まで

続いて、n8n側で全体のデータ連携パイプラインを組み上げます。

Step 1: Google Drive Trigger / Gmail Trigger

請求書PDFが届いたことを検知するノードです。

ノード名: Google Drive Trigger（または Gmail Trigger）
Trigger On: File Created
Folder: 経理部/受取請求書未処理
File Filter: mimeType = 'application/pdf'

Step 2: Dify APIを呼び出す（HTTP Requestノード）

取得したPDFファイルをDifyのワークフローAPIへ送信します。

ノード名: HTTP Request (Call Dify)
Method: POST
URL: https://api.dify.ai/v1/workflows/run（セルフホストの場合は自社URL）
Authentication: Header Auth (Authorization: Bearer {Dify_API_KEY})
Body Parameters (JSON):

json{  "inputs": {    "sender_email": "={{ $json.sender || 'unknown' }}"  },  "response_mode": "blocking",  "user": "n8n-system-user",  "files": [    {      "type": "document",      "transfer_method": "remote_url",      "url": "={{ $json.webContentLink }}"    }  ]}

Step 3: レスポンスのパースと不備チェック（Ifノード）

Difyから返ってきたJSONデータをパースし、エラーや不備があるかどうかで分岐します。

ノード名: If (Has Validation Issues?)
Condition: {{ $json.data.outputs.result_json.validation_issues.length }} > 0 または {{ $json.data.outputs.result_json.is_qualified_invoice }} === false

Step 4: 【正常系】freee / マネーフォワードAPIへの仕訳登録（HTTP Requestノード）

不備がない場合、会計ソフトのAPIを叩いて「未決済の取引（下書き）」を作成します。

ノード名: freee API (Create Deal)
Method: POST
URL: https://api.freee.co.jp/api/1/deals
Headers: Authorization: Bearer {FREEE_ACCESS_TOKEN}
Body (JSON):

json{  "company_id": 123456,  "issue_date": "={{ $json.data.outputs.result_json.invoice_date }}",  "due_date": "={{ $json.data.outputs.result_json.due_date }}",  "type": "expense",  "partner_name": "={{ $json.data.outputs.result_json.vendor_name }}",  "details": [    {      "tax_code": 21,      "account_item_name": "={{ $json.data.outputs.result_json.suggested_account_title }}",      "amount": "={{ $json.data.outputs.result_json.total_amount }}",      "description": "={{ $json.data.outputs.result_json.description }}"    }  ]}

Step 5: Slackリッチ通知（承認ボタン付き）

正常登録時は承認確認、不備がある場合は警告通知をSlackに投稿します。

ノード名: Slack
Channel: #finance-invoice-approval
Block Kit UI設定:

json[  {    "type": "header",    "text": {      "type": "plain_text",      "text": "📄 新規請求書のAI自動仕訳が完了しました"    }  },  {    "type": "section",    "fields": [      { "type": "mrkdwn", "text": "*取引先:*\n{{ $json.data.outputs.result_json.vendor_name }}" },      { "type": "mrkdwn", "text": "*請求金額:*\n¥{{ $json.data.outputs.result_json.total_amount.toLocaleString() }} (税込)" },      { "type": "mrkdwn", "text": "*推論勘定科目:*\n{{ $json.data.outputs.result_json.suggested_account_title }}" },      { "type": "mrkdwn", "text": "*インボイス登録番号:*\n{{ $json.data.outputs.result_json.invoice_registration_number || '記載なし(要確認)' }}" }    ]  },  {    "type": "actions",    "elements": [      {        "type": "button",        "text": { "type": "plain_text", "text": "✅ 会計ソフトで確認・承認" },        "url": "https://secure.freee.co.jp/deals",        "style": "primary"      }    ]  }]

6. 実運用で失敗しないための「3つの鉄則」

鉄則① 国税庁インボイスAPIとの二重照合

DifyのOCRでT番号（適格請求書発行事業者登録番号）が読み取れたとしても、それが「現在も有効な事業者か」「登録名義が取引先と一致しているか」は、n8nから国税庁の「適格請求書発行事業者公表システムWeb-API」を叩いて照合するステップを追加すると、税務調査対策が完璧になります。

鉄則② 社内特有の仕訳ルールはDifyの「ナレッジ（RAG）」に外出しする

「この取引先の請求書は、品名に関わらず〇〇プロジェクト原価に振り分ける」といった自社固有のローカルルールをプロンプトに全て書き込むと長くなりすぎます。 Difyの**ナレッジ機能（RAG）**に「自社勘定科目マニュアル.csv」や「取引先別仕訳辞書」をアップロードし、LLMに参照させる設計にすることで、ルールの変更や追加が誰でも簡単に管理できるようになります。