非構造化データはLLMと専用モデルのどちらで処理すべきか判断基準

非構造化データ処理でLLMと専用モデルのどちらを使うか迷う理由

紙の帳票や点検記録、請求書といった非構造化データは、処理する側がフォーマットを自由に決められないため、どの技術で読み取るべきか迷いやすいと私は考えています。

非構造化データとは、Excelのセルのようにあらかじめ項目が決まっていないデータのことです。手書きの点検記録、スキャンした請求書、写真で撮った領収書などがこれにあたります。LLM(大規模言語モデル)は文章やレイアウトの違いを柔軟に解釈できる一方、OCRや帳票特化の専用モデルは決まったフォーマットを高速かつ安定して読み取ることに強みがあります。どちらも「文字を読み取る」という点は共通していますが、得意な場面が異なるため、まず自分の業務がどちらの特性に合うかを整理しておく必要があります。この章では一旦、両者の役割の違いだけを押さえておき、具体的な判断軸は次の章で説明します。

判断基準は「精度・速度・コスト」のどれを優先するかで決まる

私は、用途が固定されていて処理件数が多いなら専用モデル、書式がバラバラで例外対応が必要ならLLM、という軸で判断しています。

LLM時代に非構造化データを構造化して扱う設計を考えるでは、LLMは汎用性が高い分、同じ入力でも出力が微妙に揺れることがあると指摘されています。またドキュメント自動化における大規模言語モデル（LLM）の力と限界 | Parseur®でも、定型帳票の大量処理では専用のドキュメント自動化の方が安定すると述べられています。どちらの記事も、LLMの柔軟さと専用モデルの安定性はトレードオフの関係にあるという点では一致しています。

この3つのうち、自分の業務で何を優先するかを先に決めておくと、ツール選びで迷いにくくなります。たとえば請求書のように発行元ごとにレイアウトが変わる書類は、LLMで一旦読み取ってから人が確認する流れの方が現実的です。逆に、同じ様式の点検票を毎週何百枚も処理するなら、専用モデルで速度を優先した方が向いています。精度・速度・コストの3つを同時に満たせる技術はまだ無いと考えておくと、選定の判断が早くなります。

自社で動かしているAI転記ツールの例：PDF・写真からExcelへ

私は実際に、請求書・領収書・名簿のPDFや写真から項目と明細を取り出し、CSVやTSVに変換する転記ツールを公開しており、読者の方も自分の帳票でそのまま試せます。

このツールはAI転記ツールとして公開しており、アップロードしたファイルは処理後に保存しない設計にしています。手順は次のとおりです。

1. 手元の請求書・領収書・名簿のPDFまたは写真を1枚用意する。複数ページのPDFでも処理できますが、最初は1件だけで試すと結果の確認がしやすいです。
2. ツールのページでファイルをアップロードする。ここで文字がかすれている、または斜めに傾いて撮影された写真だと項目の切り出しがずれることがあるため、できるだけ正面から撮った画像を使います。
3. AIが項目(発行日・金額・取引先名など)と明細行を抽出するのを待つ。手書きの数字や印影と重なった文字は読み取り精度が落ちやすい箇所なので、結果が出たら金額欄だけでも元の書類と見比べます。
4. 抽出結果をCSVまたはTSVとしてダウンロードし、ExcelやGoogleスプレッドシートに貼り付ける。列の区切りがずれている場合は、区切り文字の設定(カンマかタブか)を確認します。
5. 明細が複数行ある書類では、貼り付けた直後に行数を数えて元の書類と一致しているかを確認する。行が結合されて減っている場合は、該当の行だけ元の書類を見ながら手で直します。

実際に試すとつまずきやすいのは、レシートのように余白が少なく文字が密集した書類です。この場合は項目同士が結合して出てくることがあるため、結果を貼り付けた直後に明細の行数を数えて確認することをおすすめします。

点検記録のデータ化で実際に詰まった場所と人の確認が必要な理由

私は2026年7月に、手書きの点検記録を読み取って業務ツールへ登録する作業を週10時間の継続案件として受注しており、ここでは読み取りをAIに任せつつ、登録前の確認は人が行う設計にしています。

この案件はNDAのため業種は公開できません。読み取り自体はAIで十分な速度が出る一方、点検記録には現場ごとの略語や、枠からはみ出した手書きメモが含まれることがあり、これをそのまま自動登録すると誤った数値が業務ツールに入ってしまう恐れがありました。そのため、AIが読み取った内容を一旦画面に表示し、人が元の紙と見比べてから登録ボタンを押す、という一手間を挟む流れにしています。

このひと手間を省かずに残した理由は、点検記録が安全管理に直結するデータであり、読み取り精度を数字で示すよりも、誤登録が起きない運用の方が依頼者にとって価値が大きいと判断したためです。精度を追求してAIだけで完結させるより、人の目を一箇所に集約して確認する方が、結果として作業時間も安定します。週10時間という作業時間も、読み取りと確認の両方を含めた上で見積もっています。

補足：日本の現場でLLMと専用モデルを組み合わせる実際の構成

私は、インフラ保守や事務作業の現場ではLLM単体で完結させるより、定型処理と例外処理を分けて組み合わせる方が運用しやすいと感じています。

このサイト自体もその考え方で動いており、インフラにはCloudflare Pagesを使い、動く機能はPages Functions上に実装しています。具体的には、訪問者が入力した業務内容を入力・処理・出力・確認の4段階に切り分けて返す機能、PDFや写真を表データに変換する機能、登録済みの内容から問い合わせに答える機能の3つです。これらはリクエストが来た時だけ動く仕組みなので、例外的な入力にもLLMの解釈力で対応しやすい反面、常に同じ処理を繰り返すような定時のバッチ処理には向きません。

そこで定時に動かす処理は、WindowsのタスクスケジューラとPythonを組み合わせて別立てにしており、データの保存先はSupabaseにまとめています。つまり、人が都度話しかけるような柔軟な対応はLLM(Pages Functions)に任せ、決まった時刻に決まった処理を繰り返す部分は専用の定時スクリプトに任せるという役割分担です。これは帳票処理でも同じ考え方が使えると考えていて、例外対応が必要な部分と、毎回同じ手順で済む部分を先に分けておくと、どちらの技術を使うかで迷う場面が減ります。

まとめ：まず自分の業務をどちらで試すか

自分の業務がLLM向きか専用モデル向きかを判断するには、実際に手元の書類を1枚、公開されているツールに読み込ませてみるのが早い方法です。

レイアウトが毎回変わる請求書や領収書であれば、紹介したAI転記ツールで読み取り結果を自分の目で確認してみてください。逆に、同じ様式の帳票を大量かつ継続的に処理する必要がある場合は、専用モデルや定型処理のバッチ化を検討した方が、速度とコストの面で見合うことが多いです。判断に迷う場合は、精度を優先するなら専用モデル寄り、例外対応や解釈の柔軟さを優先するならLLM寄りという軸に沿って、まず小さく1件試すところから始めてみてください。