FAXの注文書、Claudeは読めるのか

先日、別々のお客さんから同じ話を聞きました。

「基幹システムへの受注処理がアナログで時間がかかっているので、手間を軽減したい」
「AI-OCRの仕組みを入れているが思ったほどの精度が出ず、うまく活用できていない」

表現は違いますが、入口の悩みは同じ。
どちらもまだ想いを聞いただけですが、実際にできるのかどうかが気になりサンプルを作ってみました。

作ったもの

FAXの注文書PDFをフォルダに置くと、Claudeが内容を読み取り、
読み取った結果をCSVに変換するようなものを作ってみました。
できあがったCSVを基幹システムが取り込むことを想定して。

注文書の様式は8種類、30枚ほどサンプルを用意。

• 表形式の注文書

• 送信状つき

• 手書きのメモ

• 横型

• 表計算ソフトで作ったもの

• 定型用紙に手書き

• メールを印刷してFAXしたもの

• 明細が2ページにまたがるもの

実際のFAXで来そうなものを一通り用意しました。

処理の流れ

仕組みのフローは以下の図の通りです。

①所定フォルダにPDFを入れる

ここは実際の運用だと、複合機がFAXをデータとして受信した後に注文書として振り分けられたフォルダや、アナログで受信したFAXやメールに添付された注文書のデータを入れるフォルダ、のイメージです。

②ファイルが入ったことを検知する

①のフォルダにファイルが入ったかどうかを検知するための監視するスクリプトを動かしています。

③クラウドにPDFを送る

監視スクリプトがPDFが入ったことを検知したら、GitHubプライベートリポジトリにPDFを送り込みます。今回は、Web版のClaudeCodeで動かせるようにしているので、PDFの保存場所としてGitHubのプライベートリポジトリを使ってみました。

④ ルーティン機能を呼び出す

「APIトリガー」という機能を使ってWeb上の Claude Code のルーティン機能を動かします。監視スクリプトから、ルーティンにアクセスするためのURL、動かすための鍵にあたるAPIトークンを使って、ルーティン機能を起動します。
手順に何をやるのかの概要を書いています。
詳細な読み取りルールはスキルに記載していて、概要ではそちらを参照するようにと書いています。

⑤読み取りルールを確認

GitHubのリポジトリ内に保存している受注票読み取り用のスキルを参照します。

⑥PDFを読み取る

上記手順に従ってClaudeのモデルがPDFを読んでいきます。
PDFを画像として読み取り、ヘッダ項目、明細項目を判断します。
最初はモデルをOpus5.5で動かしていましたが、Sonnet5.5でも結果が変わらなかったので、コスト半分のSonnet5.5にしました。

⑦読み取り結果を返す

上記の結果はjson形式でGitHub上のresultフォルダに保存されていきます。

⑧CSV形式にする

新たなjsonがあればCSV形式に保存します。
CSVの形がぶれないように、CSVはPythonのプログラムで出力します。

⑨一時ファイルを削除

GitHub上にあるPDFやjsonは Claude Code で処理してもらうための一時ファイルなので、CSV受け取りと同時に消します。

⑩画面で結果を確認

Webの進捗画面で状況を確認します。
読み取り結果が100％一致していればそのままでいいですが、読み取り結果が100％じゃない場合は該当項目を目視で確認します。
左にPDF表示、右に読み取り結果のヘッダと明細の情報を表示、という形なので、見ながら比較できます。

読めるのか

30枚のうち15枚を流しました。
まず素直に読める6枚、次に判断が要る4枚、最後に読みにくい5枚です。

正解と項目ごとに比べて、538項目のうち537が一致。
3枚まとめて置いてから、CSVに書き終わるまで1分かかりません。

素直に読める6枚は全部一致。

判断が要る4枚も値は全部一致した上で、迷ったところに印が付きました。
「（株）サクラ商店」はマスタの「株式会社サクラ商店」に。
「国産大豆しょうゆ」は1Lか1.8Lか決められないので、候補を書いて要確認に。
「令和8年10月9日（木）」は2026年に直した上で、実際には9日は金曜なので要確認に。
「明日の朝に届けて」は受信日の翌日を納期に入れて、「相対表記から算出」と断り書き。

読みにくい5枚で、初めて一致しない項目が出ました。

数量欄の左側が黒くつぶれていて、その横に「4」と書いてある。
正解は「訂正前が読めず、書き直しが4」なので、4を採用してほしかった。
Claudeは数量を空欄にして、「黒いつぶれがあり判読困難（?4）」という要確認を付けました。
数字を入れずに、分からないので人に判断を委ねたという状態です。

もう1枚、金額が単価×数量と合わない発注書がありました。
値は全部正しく読めたのに、「不一致」の印が付かなかった。
ルールには書いてあるのに効かなかった例で、ここは直す余地があります。

15枚で、読み間違いはゼロ。
空欄にして人に回したのが1か所、印の付け忘れが1か所。
ただ、本物のFAXはもっと汚いし、癖もある。

読めない前提で作る

作っていて検討が必要だと思ったのは、読み間違えたときのこと。
最近のAIの読み取り精度はかなりよくなった。
でも絶対はない。読めなかった場合にどうするか。

• 自信がない項目は推測で埋めない。空欄にして「要確認」の印を付ける

• 商品名がマスタと一つに決まらないときも要確認。候補を理由に書く

• 二重線で訂正してある数字は、書き直した方を採用して要確認

• 1と7、3と8のように紛らわしい数字は、金額欄との掛け算で確かめる

• 備考欄の「午前中着希望」は要約せず原文どおり写す

要確認の行は止めずにCSVに流します。
印が付いているので、取り込む前に人がそこだけ見ればいい。
全部を目で確かめる今の仕事を、印の付いた行だけ確かめる仕事に変える。
それが自動化の落としどころだと思っています。

読み取り結果を画面でPDFと見比べて直すこともできます。
直した結果は、読み取ったときの値と別に残しておく。
どこで間違えやすいかの材料になるからです。

おわりに

お客さんには次の機会に「こんな感じで動きます」と見てもらうつもりです。
思いのほか短時間で作れたので、Claudeの実力を改めて感じました。
ちなみにFable5.1が壁打ち相手です。
また、AI-OCRの進化も実感できました。

あくまでも今回のデモプロは営業活動の一環です。
会社員だったら、取れるかどうかわからない仕事にリソースを注ぐのは、躊躇しがちだと思います。目の前の仕事をこなさないといけないし、上司の目も気になるし。企画として進めたければ説得する労力もいります。
私もそうでした。

ただ、個人事業主なのでやるかどうかは私の決断次第だし、AIが発達した今だからこそできる営業のやり方だと思っています。
SE上がりの私がこんなこと言うのもおかしな話ですが、Claude Code は強力な営業ツールです。

今日はここまで。