代表事例　／　製造・卸　／　FAX で届く注文書

注文書を打ち込む仕事を、読み取った結果を確かめる仕事へ。

毎朝 4 社から、まったく違う書式の注文書が FAX で届きます。担当の方はそれを読み解いて、1 行ずつ手で入力していました。その作業を「AI が読んで、人が確かめる」形に置き換えた記録です。

作った過程は開発記録に 7 本公開しています。社名・地域・数量など、事業者が特定できる情報は伏せています。

01　困っていた仕事

4 社が、4 通りの書式で送ってくる

ある青果食品卸では、毎朝 FAX が届く。4 社の取引先から、それぞれまったく違う書式で。担当者は 4 種類の帳票を読み解いて、1 行ずつ手でシステムに入力する。これを毎日やっている。開発記録 35-1「FAX注文書4社4フォーマット——AI読取で手作業転記をなくす」より

A 社

月間カレンダー形式。縦が日付、横が商品。 1 枚に 1 か月分。セルに「8*30」のような式が書かれていることもある。

B 社

着日と納品日を手書きで指定するグリッド形式。文字の癖・インクの濃淡・紙の傾きが毎回違う。

C 社

3 店舗分が 1 枚に混在。印刷と手書きが入り交じっている。

D 社

JAN コード付きの印刷フォーム。数量欄に丸印を押す方式。人には直感的だが、機械には難しい。

「AI で読み取れないですか」と相談を受けたとき、「できます」ではなく「やってみます」と答えました。実際に試してみないと分からなかったからです。

02　実際に作った仕組み

読み取りを 100% にしようとしなかった

4 種類の帳票で 100% を目指すこと自体、現実的ではありません。大切なのは「全て正確に読める」ことではなく「手作業で打ち込むより楽になる」ことだと、設計を始めた段階で決めました。

帳票を送る
担当の方がブラウザから FAX の画像（JPG・PNG・PDF）を送ります。新しい機械は入れていません。既存のサーバーに相乗りさせています。
AI が注文の形に読み直す
文字を読むだけでなく、「縦が日付で横が商品だ」という表の構造ごと読み取ります。セルの計算式は計算した結果で返ってきます。
読み取り結果が一覧になる
行ごとに「どれくらい確からしいか」が付いて出ます。ここから先が、この仕組みのいちばん大事なところです。

03　人が確認する部分

「見る」と「直す」は、別の作業です

確認画面の社内デモ。要確認の行だけに絞り込んだ状態。
行ごとに読み取りの確からしさが色で付いている

確認画面の見本（社内デモ・合成データ）「要確認のみ表示」で絞り込んだところです。 公開記事をもとに再構成した操作デモです。 実際の顧客画面・運用実績ではありません（開発記録 35-4 の設計より）。取引先・商品・数量はすべて架空で、注文の確定・送信・保存は行いません。
実際に押して確かめられます → （絞り込み・まとめて確認・未確認のまま確定しようとすると止まる、まで動きます）

正しく読めているか見る作業は、目で追って進められます。間違いを直す作業は、元の帳票を見ながら集中する必要があります。毎日使う方にとって、操作の大半は前者です。ここを混ぜると、全件を 1 行ずつ確認することになり、疲れてしまいます。

色で伝える	行ごとの確からしさを、緑・橙・赤で表示します。緑が並んでいるところは目で流し、橙や赤が見えたら止まって確認する。色が「ここを見て」という合図になります。
要確認だけに絞る	ボタン一つで、確からしさが中・低の行だけを表示します。精度の高い帳票では絞り込む必要がありません。低い帳票では、直すべき行にすぐ到達できます。
確かな行はまとめて	緑の行をまとめて確認済みにして、残った橙・赤だけを手で見ます。この 2 段階が、確認作業の骨格です。
元の帳票を見ながら直す	別画面を開かず、一覧の中で直せるようにしました。別画面が開くと一覧が隠れ、元の帳票と見比べられなくなるからです。
見落としを止める	未確認の行が残ったまま確定しようとすると、件数を出して止めます。確かめていないデータが業務に流れ込まないための安全弁です。

担当者が安心して使える確認 UI があれば、AI の精度は「完璧」でなくていい。開発記録 35-4「確認画面のUX設計——信頼度・要確認フィルタ・一括OK」より

公開している開発記録 35-4 の実際のページ。確認画面の設計と、実装したコードが載っている

出典：この設計を公開している記事上のデモの元になった実装です。成果物の実画面ではありません。 なぜこう作ったのかを、そのまま読んでいただけます。開発記録 35-4 を開く

なぜ公開するか	「できます」と言うだけなら誰でも言えます。どう考えて、どこで詰まって、どう直したかまで出しておけば、ご依頼の前に確かめていただけます。
この案件の記録	7 本あります。設計・精度の実測・確認画面・本番環境まで、順に読めます。
載せていないもの	お客様の帳票と注文データが写る画面は載せていません。掲載には先方の許可が要ります。

04　どこが得意で、どこが苦手か

4 社の帳票で、実際に測りました

得意・不得意は帳票によってはっきり分かれました。測った結果が、確認画面の設計を決めています。

取引先	読み取り	出た誤り／どう手当てしたか
A 社（カレンダー）	よく読めた	数量の隣の「kg」「本」が抜けることがあった。「単位も必ず読み取ること」を指示に加えて解消。
B 社（手書き）	中くらい	商品名の誤字と、1 行の読み漏れ。取り扱い商品の一覧を渡して候補から選ばせると減った。なくなりはしない。
C 社（3 店舗混在）	中くらい	どの数値がどの店舗の分か、対応を取り違えた。帳票の構造を言葉で説明すると上がった。
D 社（丸印）	いちばん難しい	取引先名の認識漏れと、丸印の位置。枠線にかかると判断が難しい。ゼロにはならないので、確認画面で支えている。

この表は、実際の帳票で試した記録（開発記録 35-3）からそのまま起こしたものです。削減率や短縮時間は測っていないので書きません。

05　いまの段階

どこまで確認できていて、どこから先は確かめていないか

確認できている段階	実装と動作確認まで。実際の FAX 帳票を読み取り、確認画面で直して確定できるところまでを、本番環境で確認しています（2026 年 6 月時点の記録による）。
現場での利用	当社としては確認できていません。記録に残っているのは「次は担当の方に使っていただく段階」というところまでです。その後どこまで日々の業務で使われているかは、当社が確かめた記録がありません。「使われていない」という意味ではなく、確かめていないということです。
まだ言えないこと	作業時間がどれだけ変わったかは、測っていません。測る前に効果を書くことはしません。

35-1	FAX注文書4社4フォーマット——AI読取で手作業転記をなくす
35-2	FastAPI + PostgreSQLで読取結果を管理する設計
35-3	帳票を読む——4種の帳票と精度の違い
35-4	確認画面のUX設計——信頼度・要確認フィルタ・一括OK
35-5	複数画像対応——サムネイルストリップとモーダルナビ
36-1	HTTPS + Basic認証 + EC2相乗り——本番環境の構築
36-2	AI帳票読取の現実——なぜプロンプトより確認UIが重要か