最新情報最終更新: 2026年7月20日／初出: 2026年7月20日

n8n × Ollama で請求書 PDF 月100件の手入力を確認だけに、機密を社外に出さない自社完結レシピ

業種中小企業経理・士業・製造業

ツールn8n

難易度★★★ 難

設定時間約 180 分

取引先の請求書を ChatGPT にドラッグして「読み取らせる」のは、便利だと分かっていても気が引ける。取引先名も金額も、守秘義務の対象だからです。n8n をセルフホストし、AI を Ollama でローカル実行すれば、請求書 PDF は 1 バイトも社外に出ません。

読了時間: 約 9 分／想定読者: 経理担当を置く中小企業・士業事務所／難易度: ★★★ (Docker とコマンドラインに触れた経験が前提、初回 3 時間)

構成: Local File Trigger → Extract from File → Information Extractor (Ollama) → Google スプレッドシート追記、の 5 ノードが骨格
費用: n8n Community Edition と Ollama はどちらもソフト代 ¥0。かかるのは既存 PC かサーバーの電気代と、初回 3 時間の構築工数
決め手: 請求書の中身が 自社ネットワークの外へ送信されない。守秘義務契約や下請法の観点で説明しやすい
前提: Local File Trigger は セルフホスト版 n8n 専用。n8n Cloud では使えません
落とし穴: テキスト PDF と「紙をスキャンした画像 PDF」で必要な部品が変わる。後者は画像対応モデルが要る
必須の検証: 精度は請求書の書式次第。自社の過去請求書 20 通で実測してから本番に載せる

編集長 Mira の見解

このレシピの価値は「速さ」ではなく 「持ち出さない」 ことにあります。Zapier や Make でも同じ流れは組めますし、そちらの方が構築は圧倒的に楽です。それでも n8n × Ollama を選ぶ理由は 1 つだけ、取引先名・単価・振込口座という交渉材料そのものを、外部の事業者に預けずに済むからです。逆に言えば、その 1 点に価値を感じない事業所には、この構成は割に合いません。判断基準はそこに絞ってください。

請求書だけがクラウド自動化に載せにくい理由

経費精算やフォーム集計の自動化は、クラウド型の自動化サービスで十分こなせます。編集部でも Zapier で領収書を経費データ化するレシピを紹介してきました。

一方、買掛の請求書は事情が違います。そこに載っているのは取引先の企業名、品目ごとの単価、支払サイト、振込口座。自社の原価構造がほぼそのまま読み取れる書類です。

どこまでデータが出ていくのかを、構成別に並べると差がはっきりします。

構成	PDF 本体の保管先	読み取り AI の実行場所	社外に出る情報	編集部の評価
Zapier / Make + クラウド AI	米国のサーバー	米国の AI 事業者	請求書の全文	構築は最速。守秘義務案件では説明が難しい
n8n Cloud + クラウド AI	n8n の欧州サーバー	AI 事業者	請求書の全文	保管地は選べるが、AI 側には渡る
n8n セルフホスト + クラウド AI	自社サーバー	AI 事業者	請求書の全文	半端。PDF は残るが中身は渡っている
n8n セルフホスト + Ollama	自社サーバー	自社サーバー	なし	構築は重い。守秘義務が重い業種なら見合う

判断の分かれ目は「顧問先や取引先に、書類の流れを聞かれたときに何と答えるか」です。次のセクションで、実際に組む流れの全体像を見ていきます。

全体フロー

請求書 PDF → スプレッドシート記帳の自動化フロー

📂

フォルダに保存

受領した請求書 PDF を監視フォルダへ置く (Local File Trigger)

→

📄

テキスト抽出

PDF から文字を取り出す (Extract from File)

→

🧠

項目を構造化

ローカル AI が請求元・日付・金額を抜き出す (Information Extractor)

→

✅

検算・仕分け

合計金額の整合を確認し、怪しい行に確認フラグを立てる (IF ノード)

→

📊

記帳

スプレッドシートに 1 行追記 (Google Sheets)

すべての処理が自社ネットワーク内で完結する。外部通信が発生するのは、記帳先に Google スプレッドシートを使う最終ステップのみ。

このうち AI が担当するのは 03 だけです。02 の文字抽出は AI ではなく PDF の解析処理で、04 の検算は単純な計算式。AI に任せる範囲を狭く保つほど、結果は安定します。

用意するもの

ソフトウェアは 2 つ、どちらも無償で始められます。

n8n (Community Edition): 自社サーバーに立てる自動化基盤。導入手順は n8n セルフホスト移行ガイドで扱いました
Ollama: 大規模言語モデル (LLM) を手元の PC で動かすためのソフト。基本は Ollama の使い方まとめを参照

n8n が公式に配布している Self-hosted AI Starter Kit を使うと、n8n・Ollama・Qdrant・PostgreSQL が Docker Compose 一式で立ち上がります。ライセンスは Apache License 2.0 です[出典: n8n 公式 GitHub]。

git clone https://github.com/n8n-io/self-hosted-ai-starter-kit.git
cd self-hosted-ai-starter-kit
cp .env.example .env

# CPU のみの環境
docker compose --profile cpu up

# Nvidia GPU 搭載機
docker compose --profile gpu-nvidia up

# Mac / Apple Silicon (GPU 高速化は使えないため Ollama は母艦側で動かす)
docker compose up

起動後、n8n の画面は http://localhost:5678/ で開きます。

モデルの選び方

Ollama で動かすモデルは、扱う請求書の種類で変わります。画像対応の Qwen3-VL を例に、公開されているサイズを並べます。

モデル	ダウンロード容量	想定用途	編集部のおすすめ度
`qwen3-vl:2b`	1.9GB	動作確認・非力なミニ PC	△ 精度は期待しない
`qwen3-vl:4b`	3.3GB	テキスト PDF 中心の小規模事務所	○ 試す価値あり
`qwen3-vl:8b`	6.1GB	スキャン PDF も混じる標準構成	◎ 最初の候補
`qwen3-vl:30b` / `:32b`	20GB / 21GB	書式が乱れた請求書が多い場合	○ GPU 必須
`qwen3-vl:235b`	143GB	中小企業には非現実的	✕ 対象外

Qwen3-VL は文字と画像の両方を入力でき、複数言語の文字認識に対応すると公開情報に記載があります[出典: Ollama モデルライブラリ]。ただし 日本語の請求書での実精度は書式に強く依存します。数値は鵜呑みにせず、後述の検証ステップで自社の書類を通してください。

⚠️ 編集部の警告: 最新モデルがすぐ使えるとは限らない

画像を扱えるモデルは、Ollama 側の対応が文字生成部分より遅れることがあります。「モデルは取得できたのに画像を渡すとエラーになる」は珍しい話ではありません。導入前に Ollama のモデルページで、そのタグが画像入力に対応しているかを必ず確認してください。動くと決めつけて設計すると、構築の最後で作り直しになります。

ハードウェアは、画像対応モデルは文字専用モデルより多くのメモリを要求します。まずは手元の業務 PC で qwen3-vl:4b を試し、精度が足りなければ上のサイズへ、という順番が安全です。

次は、実際のノードを 1 つずつ組み立てていきます。

設定手順

n8n × Ollama 請求書ワークフローの構築手順 (初回約 3 時間)

STEP 1

Ollama を入れてモデルを取得

Ollama をインストールし、コマンドでモデルを取得します。ダウンロードに 10-30 分かかることがあります。

STEP 2

n8n を起動

Starter Kit か既存のセルフホスト環境で n8n を立ち上げ、http://localhost:5678/ にアクセスします。

STEP 3

Ollama の資格情報を登録

n8n の Credentials で Ollama を追加します。Base URL の初期値は http://localhost:11434 です。n8n と Ollama を別々のコンテナで動かしている場合は、この URL では届かないため、Ollama 側の待ち受け設定を調整する必要があります。

STEP 4

Local File Trigger でフォルダを監視

Trigger On を folder、Folder to Watch に請求書の保存先を指定し、ファイル追加を検知対象にします。このノードはセルフホスト版 n8n 専用で、n8n Cloud には存在しません。

STEP 5

Extract from File で PDF を文字に

Operation に Extract From PDF を選びます。Input Binary Field の初期値は data です。ここで文字が空で返ってきたら、そのファイルは画像 PDF なので STEP 6 の分岐が必要になります。

STEP 6

Information Extractor で項目を抜き出す

Text 欄に前ステップの出力を式で渡し、Schema Type で抽出したい項目を定義します。定義方法は「属性の説明から」「JSON の例から生成」「JSON Schema を直接書く」の 3 通り。下に Ollama Chat Model を接続して、使うモデルを指定します。

STEP 7

検算 IF と Google Sheets 追記

明細の合計と請求総額が一致するかを IF ノードで判定し、一致しない行には確認フラグを付けて Google Sheets の Append Row に流します。

STEP 8

過去請求書 20 通で精度を実測

本番投入の前に、書式の異なる過去の請求書を 20 通通し、項目ごとの正答率を数えます。ここを飛ばすと、間違った金額が静かに帳簿へ流れ込みます。

STEP 6 で Text 欄に渡す式は、Extract from File の出力を参照する形になります。n8n の式は二重の波括弧で囲む記法で、テキスト抽出の出力を指す場合は {{ $json.text }} のように書きます。

抽出スキーマの設計

Information Extractor に「何を抜くか」を伝えるのがスキーマです。欲張らず、転記ミスが起きやすい項目に絞るのがコツ。

項目名	型	説明の書き方	誤りやすさ
`issuer`	文字列	請求元の会社名。宛先ではなく発行元	中 (宛先と取り違える)
`invoiceDate`	文字列	請求日。西暦 YYYY-MM-DD 形式で	高 (和暦・発行日と支払期日の混同)
`dueDate`	文字列	支払期日。記載がなければ空	高
`totalIncludingTax`	数値	税込の請求総額。カンマと円記号は除く	低
`taxAmount`	数値	消費税額。複数税率なら合計	中
`registrationNumber`	文字列	インボイス登録番号 (T から始まる 14 桁)	中

💡 編集部のヒント: 日付は「必ず西暦の年月日で」と説明文に書く

抽出が最も崩れるのは日付です。和暦、月日だけの表記、スラッシュ区切りが混在するため、属性の説明文に「西暦 4 桁の年から始まる YYYY-MM-DD 形式で出力する」と明記するだけで揺れが目に見えて減ります。項目の型を細かく設計するより、説明文を丁寧に書くほうが効きます。

ここまでで流れは完成です。次に、実務で本当に使えるかを分けるポイントを見ます。

精度を担保する仕組み

AI の読み取りを「そのまま信じる」設計にすると、必ず事故が起きます。編集部が推奨するのは、AI の出力を 確認待ちの下書き として扱う組み方です。

具体的には次の 3 つを仕込みます。

機械で検算する: 明細合計と請求総額、税額と税率の整合を IF ノードで確認。ずれた行は確認フラグを立てる
確認列を用意する: スプレッドシートに「確認済」列を作り、担当者がチェックを入れるまで支払処理に回さない
原本へのリンクを残す: 記帳行に元 PDF のファイルパスを併記し、疑わしいときに 1 クリックで原本へ戻れるようにする

請求書月100件の処理工数 (編集部の試算)

導入前 (全件を手入力)

PDF を開いて内容確認 (1 通 2 分)
スプレッドシートへ転記 (1 通 3 分)
転記ミスの発見と修正 (月数件)
合計月約 8 時間

→

導入後 (AI 下書き + 人の確認)

フォルダに PDF を置く (1 通 5 秒)
自動生成された行を目視確認 (1 通 30 秒)
確認フラグが立った行だけ手直し
合計月約 1 時間

編集部のシミュレーション。実際の削減幅は請求書の書式のばらつきと確認の厳しさにより変動します。

⚠️ 編集部の警告: 会計ソフトへの直接連携は最後にする

「どうせなら会計ソフトへ直接登録したい」と考えたくなりますが、最初の数か月はスプレッドシートで止めてください。AI の読み取り誤りが仕訳データに直接入ると、修正の手間は転記ミスの比ではありません。運用が安定し、確認フラグの発生率が十分下がってから連携を検討する順序が安全です。クラウド会計と繋ぐ具体的な手順は請求書と会計ソフトの連携レシピで扱っています。

セキュリティ面でもう 1 点。Local File Trigger は、信頼できない利用者がいる環境での危険性を理由に、n8n のバージョン 2.0 では初期状態で無効化されています[出典: n8n 公式ドキュメント]。有効化する際は、n8n の管理画面に誰がログインできるかを併せて見直してください。

💡 編集部のヒント: 記帳先も社内に置ける

Google スプレッドシートを使う限り、記帳データは Google 側に置かれます。請求書の中身まで完全に社内に留めたい場合は、Starter Kit に同梱されている PostgreSQL へ直接書き込むか、社内 NAS 上の表計算ファイルに追記する構成にします。この場合、外部通信はゼロになります。

同じ n8n を使った台帳管理の応用は n8n と Airtable の顧客管理レシピも参考になります。

コストの現実

ソフトウェア費用はかかりませんが、無料ではありません。時間とハードウェアが対価です。

項目	金額の目安	備考
n8n Community Edition	¥0	セルフホスト用。SSO や監査ログが必要なら有償版
Ollama およびモデル	¥0	オープンなライセンスのモデルを選ぶこと
サーバー / PC	既存機なら ¥0	常時稼働させるならミニ PC 増設も選択肢
電気代	月数百円程度	常時稼働の小型機を想定した編集部の概算
初回構築の工数	3 時間前後	Docker の経験がなければ 1 日は見込む
保守	年 2-4 時間	n8n とモデルの更新、動作確認

損益分岐は「手入力にかけている時間」次第です。月 100 件を手で打っているなら初月から回収できますが、月 10 件程度なら、素直に手入力するかクラウド型の自動化を選ぶほうが合理的です。

n8n を無料で試す → ※ PR・アフィリエイトリンクを含みます

よくある質問

Q. 紙で届いた請求書はどうなりますか?

編集部の答え: スキャンして PDF にした時点で「画像 PDF」になり、Extract from File では文字が取れません。画像対応のモデルに PDF のページ画像を渡す構成が必要です。まずは PDF で届く請求書だけを対象に始め、紙の分は後から足すのが現実的です。

Q. 顧問税理士に説明できますか?

編集部の答え: 「請求書の内容は自社サーバー内でのみ処理し、外部の事業者には送信していない」という説明が成立するのが、この構成の最大の利点です。ただし電子帳簿保存法の要件は別問題なので、原本 PDF の保存方法は必ず顧問税理士に確認してください。

Q. 精度はどれくらい出ますか?

編集部の答え: 請求書の書式次第としか言えません。定型フォーマットの取引先が多ければ実用域に入りますが、手書きや独自レイアウトが混じると落ちます。だからこそ STEP 8 の「過去 20 通での実測」を省略しないでください。他社の数値ではなく、自社の請求書での数値が唯一の判断材料です。

Q. n8n Cloud では組めませんか?

編集部の答え: フォルダ監視の Local File Trigger がセルフホスト版専用のため、そのままでは組めません。受信メールの添付ファイルを起点にすれば n8n Cloud でも近い形は作れますが、その場合 PDF は n8n のサーバーを経由します。「社外に出さない」が目的なら、セルフホストが前提になります。

出典・参考情報

n8n 公式 — https://n8n.io/
n8n Local File Trigger ノードドキュメント — https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.localfiletrigger/
n8n Extract from File ノードドキュメント — https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.extractfromfile/
n8n Information Extractor ノードドキュメント — https://docs.n8n.io/integrations/builtin/cluster-nodes/root-nodes/n8n-nodes-langchain.information-extractor/
n8n Ollama 資格情報ドキュメント — https://docs.n8n.io/integrations/builtin/credentials/ollama/
n8n Self-hosted AI Starter Kit — https://github.com/n8n-io/self-hosted-ai-starter-kit
Ollama 公式 — https://ollama.com/
Ollama モデルライブラリ Qwen3-VL — https://ollama.com/library/qwen3-vl

本記事の数値・事例のうち「編集部の試算」「編集部の概算」と明示された箇所は編集部による試算・推論です。実際の効果は請求書の書式や運用体制により変動します。ノードの仕様・料金は各社公式情報源を確認のうえご判断ください。

編集長 Mira ／ AI経営ラボ 本記事は 2026-07-20 時点の情報です。n8n / Ollama の仕様は更新が速いため、各社公式情報を最新でご確認ください。

n8n を無料で試す → ※ PR・アフィリエイトリンクを含みます