請求書処理に月300万かけてる場合じゃない——jina-ocr-v1×ローカルLLM×TabPFN-3.5で「月5万円AI自動化」のパーツが揃った

結論から言う。「紙の請求書を人が読む仕事」は、もう終わりにできる 請求書の仕分け、見積もりの比較、在庫データの集計——。 中小企業の現場で、いまだに人がExcelに手打ちしている作業がある。外注すれば月数十万。BPOに出せば年間300万超

By Kai

|

Related Articles

結論から言う。「紙の請求書を人が読む仕事」は、もう終わりにできる

請求書の仕分け、見積もりの比較、在庫データの集計——。
中小企業の現場で、いまだに人がExcelに手打ちしている作業がある。外注すれば月数十万。BPOに出せば年間300万超え。「うちの規模じゃAIなんて無理」と思っている経営者は多い。

だが、2025年6月時点で状況は変わった。
文書を読み取るOCR、処理を自動で回すエージェント、テーブルデータを分析するモデル——この3つのパーツがすべて「ほぼ無料〜月5万円以下」で手に入るようになった。

具体的には、Jina AIの文書パーサー「jina-ocr-v1」、オープンソースのローカルLLMエージェントハーネス、TabPFN-3.5(テーブルデータ基盤モデル)。この3つの組み合わせだ。

一つひとつ、何ができて、いくらかかって、現場で何が変わるのかを見ていく。

—

パーツ①:jina-ocr-v1——請求書を投げたら、構造化データが返ってくる

Jina AIが公開した「jina-ocr-v1」は、3.4Bパラメータの文書パーサーだ。

やることはシンプル。PDF、スキャン画像、請求書、表、グラフ——あらゆる文書を食わせると、クリーンなMarkdown形式で構造化して返す。エンドツーエンド。前処理不要。

ポイントは3つある。

1. 動作に必要なGPUが軽い。
デコーダー部分は570Mパラメータ。NVIDIA L4(クラウドで月1〜2万円程度)で動く。RTX 4060搭載の中古PCでも十分射程圏内だ。A100を月20万で借りる必要はない。

2. オープンウェイト公開。
モデルの重みが公開されている。つまり自社サーバーやローカルPCで動かせる。データを外部APIに送る必要がないから、取引先の請求書データが外に漏れる心配もない。これは中小企業にとって地味に大きい。

3. 出力がMarkdownだから、後工程と繋ぎやすい。
構造化されたMarkdownは、そのままLLMに渡せる。「この請求書の合計金額と支払期日を抜き出して」という指示が、そのまま通る。

ただし注意点もある。現時点では商業利用にはライセンス制限がある。研究・非商業利用は自由だが、本番業務に組み込む場合はJina AIへの確認が必要だ。ここは今後の動向を見る必要がある。

とはいえ、API経由で使う場合のコストは従来のOCRサービス(月額10〜50万円)と比べて桁が違う。仮にAPI利用でも、月間数千枚の請求書処理で数千円〜1万円程度に収まる計算だ。

—

パーツ②:ローカルLLMエージェントハーネス——「読んで、判断して、次の処理に回す」を自動化する

OCRで文書を読み取っただけでは、自動化は半分しか終わっていない。

「読み取った請求書の金額を会計ソフトに入力する」「見積もりを3社比較して一番安い業者をSlackに通知する」——こういう判断と実行のチェーンを組む必要がある。

ここで使うのが、オープンソースのエージェントハーネスだ。

エージェントハーネスとは何か。簡単に言えば、LLM(言語モデル)に「道具」を持たせて、自律的にタスクを実行させる枠組みのことだ。モデル単体では「テキストを生成する」だけだが、ハーネスを通すことで「ファイルを読む」「APIを叩く」「データベースに書き込む」といった実行能力を持つ。

2025年現在、選択肢は豊富にある。

  • Ollama + Open WebUI:ローカルLLMを動かす定番。コンテキストウィンドウの拡張も容易
  • LangGraph / CrewAI:複数エージェントの連携が得意
  • Smolagents(Hugging Face):軽量で、小規模タスクに向く

重要なのは、これらはすべて無料だということ。ソフトウェアのライセンス費用はゼロ。必要なのはモデルを動かすハードウェアのコストだけだ。

ローカルで動かすなら、Ollama上でQwen3やLlama 4 Scoutを走らせる構成が現実的だ。RTX 4060〜4070搭載のPC(中古で15〜20万円)があれば、8Bクラスのモデルは快適に動く。クラウドなら、Lambda LabsやVast.aiでGPUインスタンスを借りて月1〜3万円。

「OCRで読み取った請求書Markdown → LLMが金額・日付・取引先を抽出 → スプレッドシートに自動記入 → 異常値があればSlack通知」

この一連のフローが、人間の介在なしに回る。属人化していた経理担当者の「目検」が、再現可能な仕組みになる。

—

パーツ③:TabPFN-3.5——テーブルデータ分析を「秒」で終わらせる

3つ目のパーツは、少し毛色が違う。

TabPFN-3.5は、テーブル形式のデータ(CSVやExcelの表)に対する予測・分類を行う基盤モデルだ。従来のTabPFN-3から大幅に改善され、標準的なテーブル予測ベンチマークで最先端の精度を叩き出している。

中小企業にとって何が嬉しいか。

1. 学習がほぼ不要。
通常の機械学習は、データを集めて、前処理して、モデルを選んで、ハイパーパラメータを調整して……という工程に数週間かかる。TabPFN-3.5はデータを渡すだけで予測が返ってくる。事前学習済みの基盤モデルだから、追加学習なしでそのまま使える。

2. 小さなデータでも精度が出る。
中小企業のデータは、大企業と比べて圧倒的に少ない。従来の機械学習では「データが足りなくて精度が出ない」が常だった。TabPFN-3.5は少量データでの汎化性能が高く、数百行のデータでも実用的な予測ができる。

3. 非i.i.d.データに強い。
時系列データ(月次売上、在庫推移)やリレーショナルデータ(顧客×商品の組み合わせ)など、現実の業務データは「きれいな独立同分布」ではない。TabPFN-3.5はここに明確な強みがある。

具体的な活用例を挙げる。

  • 在庫予測:過去の出荷データから来月の必要在庫を予測。過剰在庫による資金繰り悪化を防ぐ
  • 売上予測:季節変動を加味した月次売上予測。仕入れ判断の精度が上がる
  • 顧客離脱予測:取引頻度や金額の変化から、離脱リスクの高い顧客を特定

TabPFN-3.5自体はオープンソースで公開されており、利用料はゼロ。CPUでも動作するため、追加のGPUコストすら不要だ。

—

で、結局いくらかかるのか——月5万円以下の構成例

具体的なコスト試算を出す。

パーツ 構成 月額コスト
文書OCR jina-ocr-v1(API利用 or ローカル) 0〜10,000円
エージェント基盤 Ollama + Qwen3-8B(ローカルPC) 0円(電気代のみ)
エージェント基盤(クラウド) Vast.ai GPU インスタンス 10,000〜30,000円
テーブルデータ分析 TabPFN-3.5(ローカルCPU) 0円
その他 Slack通知、スプレッドシート連携 0〜5,000円
合計 10,000〜45,000円

ローカルPC構成なら月1万円以下。クラウドGPUを使っても月4.5万円。

1年前なら同じことをやろうとしたら、SaaS契約で月30〜50万円、SIerに頼めば初期構築だけで500万円は覚悟が必要だった。コストが1/10以下になった。これは「ちょっと安くなった」ではなく、構造的な変化だ。

—

「安くなった」の先に何が起きるか

コストが下がると、何が変わるか。

試行錯誤のコストが下がる。
月5万円なら、3ヶ月試して合わなければやめればいい。15万円の授業料だ。SIerに500万円払って「思ったのと違った」とは訳が違う。

属人化が解消される。
「経理のベテラン田中さんしか読めない請求書フォーマット」が、仕組みで処理できるようになる。田中さんが休んでも、辞めても、業務は止まらない。

中小企業が大企業と同じ武器を持てる。
これまでAI活用は「データもカネも人材もある大企業の特権」だった。だが、オープンソースとローカル実行の組み合わせで、その壁が崩れつつある。むしろ意思決定の速い中小企業のほうが、導入は早い。稟議に3ヶ月かかる大企業を横目に、来週から動ける。

—

注意点:銀の弾丸ではない

煽るだけでは無責任なので、現実的な注意点も書いておく。

1. jina-ocr-v1の商用ライセンスは要確認。
オープンウェイトだが、商業利用の条件は明確に確認すべきだ。API利用なら問題ないが、自社サーバーでの商用運用は現時点でグレーゾーンがある。

2. ハーネスの構築には最低限の技術力が要る。
Ollamaの導入やエージェントの設定は、ノーコードツールほど簡単ではない。Pythonの基礎知識がある人材が社内に1人は必要だ。いなければ、外部の技術者に初期構築だけ依頼するのが現実的(10〜30万円程度)。

3. 精度100%は期待しない。
OCRもLLMも間違える。最初は人間がチェックするフローを残し、徐々に自動化の範囲を広げるのが正解だ。

—

で、どうすればいいのか

まず、自社の「人が手で読んでいる紙の書類」を1つ選ぶ。請求書でも、発注書でも、検査報告書でもいい。

次に、jina-ocr-v1のAPIで10枚読み取らせてみる。出力されたMarkdownを見て、「これなら使える」と思えるかどうか。ここまでのコストはほぼゼロだ。

使えそうなら、Ollamaでローカルモデルを立てて、抽出→整形→記入の流れを組む。TabPFN-3.5は、溜まったデータが出てきた段階で載せればいい。

全部を一度にやろうとしない。1つの書類、10枚から始める。

パーツは揃った。あとは試すだけだ。

—

POPULAR ARTICLES

Related Articles

POPULAR ARTICLES

JP JA US EN