はじめに
取り込んだFAX注文書のPDFを、いよいよAIで読み取ります。この工程のゴールは、人が見て理解できる注文書を、そのままシステムで扱えるデータ（JSON）に変換することです。
「読み取る」と一言で言っても、やってみると奥が深いんです。この記事では、LLM（Claude）に帳票を構造化させるためのプロンプト設計と、抜き出した結果をどう信頼できる形にするかの検証設計を解説します。
なぜLLMで抽出するのか
帳票は思ったより「バラバラ」
FAX注文書は取引先ごとに書式がまったく違います。表形式で整った注文書もあれば、便箋に手書きされたもの、既存の発注書に赤ペンで追記されたものまで。「品番」の呼び方ひとつとっても、商品コード・型番・アイテムNoと様々です。
こうした揺れを、位置ベースの従来型OCRで拾い切るのは大変です。取引先ごとにテンプレートを作り、書式が変わるたびに直す。これでは自動化のはずが、かえって手間が増えてしまいますよね。
「意味」で読めるという強み
LLMの強みは、レイアウトではなく意味で読める点です。「型番」と書いてあっても「商品コード」と書いてあっても、それが品番を指していると文脈から理解します。
帳票の座標を定義し、決まった位置の文字を読む。書式が変わると崩れる。
文書全体を読んで意味を理解し、必要な項目を判断して抜き出す。書式の揺れに強い。
だからこそ、書式の異なる多数の取引先を、一つの仕組みで受け止められます。
プロンプト設計の勘どころ
出力の「型」を固定する
AIに自由に書かせると、あるときは「数量: 10」、あるときは「10個です」と返してきて、後段の処理が困ります。そこで、抜き出してほしい項目と形式をプロンプトで明確に指定し、決まった構造のJSONだけを返すよう指示します。
品番・数量・取引先・希望納期といった項目名と、それぞれの型（文字列か数値か）をあらかじめ定義しておく。出力の型が固定されていれば、シートへの書き込み処理は安心してその形を前提にできます。
あなたは受注業務のアシスタントです。
以下のFAX注文書から、注文明細を抽出してください。
【抽出する項目】
- itemCode: 品番（文字列）
- quantity: 数量（数値）
- client: 取引先名（文字列）
- dueDate: 希望納期（YYYY-MM-DD、不明ならnull）
【ルール】
- 読み取れない項目はnullにする。推測で埋めないこと
- 明細が複数ある場合は配列で返す
- 指定したJSON以外の文章は出力しないこと
「わからない」と言わせる
一番やってはいけないのが、AIが空欄を「それっぽい値」で埋めてしまうことです。読み取れない数量を勝手に「1」としてしまえば、それは誤読よりたちが悪い。
だからプロンプトで「読み取れない項目は推測せずnullにする」と強く指示します。わからないことをわからないと言えるのは、業務でAIを使う上で欠かせない性質です。nullで返してくれれば、後段の検証で「要確認」に回せます。
明細の粒度をそろえる
1枚のFAXに複数の商品が並ぶことはよくあります。これを1件ずつの明細に分解し、配列として返させます。「1行＝1明細」の粒度をそろえておくと、そのまま受注シートの1行1行に対応づけられます。
ここが崩れると、2商品が1行に混ざったり、逆に1商品が2行に割れたりして、数量集計が狂います。地味ですが、粒度の指定は正確な受注データの土台になる部分です。
抽出結果を信頼できる形にする
機械的な検証を重ねる
LLMの出力をそのまま信じて書き込むのは危険です。抽出したJSONに対して、機械的なチェックを通してから確定させます。人が確認する前に、明らかなおかしさは自動で弾いておくわけです。
品番・数量が欠けていないか確認する
抽出した品番が実在するか商品マスタと突合する
数量が正の整数か、納期が妥当な日付かを確認する
引っかかった明細に印を付け、人の確認に回す
品番マスタとの照合が効く
検証の中でも特に効くのが、抽出した品番を商品マスタと突き合わせることです。存在しない品番なら、それは読み間違いか、廃番か、あるいは表記揺れ。いずれにせよ人の確認が必要なサインです。
「AIが読んだ品番」を「実在する品番」で裏取りする。この一手間で、誤読が誤出荷につながる前に食い止められます。マスタという確かな正解を持っていることが、AI活用の安全網になるんですよね。
AIの出力は「下書き」、確定は検証の後
LLMは強力ですが、その出力は最終確定ではなく下書きです。必須項目・マスタ照合・型チェックを通して初めて、業務に使えるデータになります。
確認しやすい形で人に渡す
検証を通しても、最後は人が目を通します。このとき、元のPDFと抽出結果を並べて見られるようにしておくと、確認が一気に楽になります。「この行、本当に数量10かな？」と思ったら、すぐ原本を確認できる。
AIに任せきりにせず、かといって全部を手作業に戻すのでもない。AIが下書きし、人が確認するこの分担が、速さと正確さを両立させる現実解だと感じています。
まとめ
LLMによる帳票の構造化データ抽出について解説しました。
- 意味で読む：レイアウトではなく文脈で理解するから、書式の揺れに強い
- 型を固定する：決まった構造のJSONを返させ、推測での穴埋めは禁止する
- 検証で裏取り：必須項目・品番マスタ照合・型チェックを通してから確定する
抽出はAI活用の心臓部ですが、その前後を支える仕組みがあって初めて業務に乗ります。取り込みの土台は「メール受信からの自動取込パイプライン設計」、書込先の振り分けと誤読対応は「取引先別ルート設定と誤読リカバリー運用」で解説しています。全体像は「FAX受注のAI-OCR自動取込」をご覧ください。