Media > AI活用ユースケース > 営業 > 精肉の卸が飲食店から FAX で届く手書きの注文書を Google Document AI で読み取り、部位・重量・カットの指定を加工の指示書にする

精肉の卸が飲食店から FAX で届く手書きの注文書を Google Document AI で読み取り、部位・重量・カットの指定を加工の指示書にする

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

飲食店から FAX で届く手書きの注文書を読み取り、部位・形態・重量・枚数・カットの指定を注文の行にそろえます。翌朝の加工場で使う加工の指示書と、取引先ごとの受注の候補を作ります。

サマリー
生成AI
ChatGPT/Claude/Gemini
AIサービス
AWS Textract/Azure AI/Google Document AI
連携・自動化
Google Apps Script/Python
対象業界
商社/小売/飲食
対象部門
営業
対象業務
データ入力・転記/書類作成
主な課題
入力作業が多い/期限・対応漏れが起きる/確認ミスが多い
AIで行う処理
読み取り(OCR)
主な効果
入力漏れ削減/対応スピード向上/工数削減
導入難易度
★★☆☆☆
実装レベル
本格構成
費用感
API連携(中)
人間の確認
条件付き
現在工数
80h/月
AI導入後
24h/月
想定削減
70%
年間削減
672h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 営業事務の担当が朝5時に出て、夜のうちに届いた FAX の束を取る
  2. 1枚ずつ読み、販売管理のシステムに受注を打ち込む
  3. 読めない字、単位の無い数量、印字に無い品目があれば、付箋を貼って開店前の電話の対象にする
  4. 全部の注文書から、部位と形態ごとに数量とカットの指定を拾い、加工の指示書に書き直す
  5. 加工場が指示書で切り、店ごとに詰め、個体識別番号を書き込む
  6. 締め切りの後に届いた FAX は、営業の担当が店に電話して受けるかを決める
導入後(After)
  1. 自動複合機が受信した FAX を PDF にして、共有フォルダに受信の日時つきで保存する
  2. 自動10分ごとに Python の処理が動き、新しい PDF を Google Document AI の Form Parser に送る
  3. 自動Form Parser が、注文書の表、キーと値のペア、チェック欄、それぞれの信頼度を返す
  4. 自動読み取り結果を Claude API に渡し、注文の行(部位、規格、形態、厚み・1枚の重さ、数量、単位、カットの指定)にそろえる
  5. 自動Python の処理が、取引先の品目の一覧と照らし、単位の無い行・「いつもの」の行・締め切りの後の受信に印を付ける
  6. 自動印の無い行から受注の候補を作り、部位と形態ごとにまとめた加工の指示書の下書きを作る
  7. 人営業事務の担当が朝5時に、印の付いた行だけを FAX の画像と見比べ、必要な店に開店前に電話する
  8. 人営業事務の担当が受注の候補を確定し、加工の指示書を加工場に渡す
  9. 人加工場が指示書で切り、個体識別番号を指示書と送り状に書き込む
各工程の詳しい説明を読む
  1. 営業事務の担当が朝5時に出て、夜のうちに届いた FAX の束を取る
  2. 1枚ずつ読み、販売管理のシステムに受注を打ち込む
  3. 読めない字、単位の無い数量、印字に無い品目があれば、付箋を貼って開店前の電話の対象にする
  4. 全部の注文書から、部位と形態ごとに数量とカットの指定を拾い、加工の指示書に書き直す
  5. 加工場が指示書で切り、店ごとに詰め、個体識別番号を書き込む
  6. 締め切りの後に届いた FAX は、営業の担当が店に電話して受けるかを決める

(a)早朝に打ち込みが集中する。 加工が始まる6時までの1時間に、数十枚の FAX を読みます。読む、打つ、指示書に書き直す、の3つを同じ1時間でこなします。

(b)カットの指定を読み違える。 「2mm」と「2cm」、「180g」と「160g」、「脂3mm残し」と「脂取り」。FAX の手書きはつぶれやすく、厚みや重さの数字が崩れます。 読み違えた肉は、作り直すか、店に別の用途で引き取ってもらうことになります。

(c)単位の無い数量を、いつもの単位で埋める。 「挽き 10」を、この店はいつもkgだからと10kgで打つ。その日だけ10パックのつもりだった店には、違う量が届きます。 埋めたことは、誰の記録にも残りません。

(d)締め切りの後の FAX が埋もれる。 20時を過ぎて届いた FAX が、朝の束に混ざって普通に打たれる日もあれば、誰も気づかずに翌日まで置かれる日もあります。 店から「頼んだ肉が来ない」と電話が来て分かります。

  1. 【自動】 複合機が受信した FAX を PDF にして、共有フォルダに受信の日時つきで保存する
  2. 【自動】 10分ごとに Python の処理が動き、新しい PDF を Google Document AI の Form Parser に送る
  3. 【自動】 Form Parser が、注文書の表、キーと値のペア、チェック欄、それぞれの信頼度を返す
  4. 【自動】 読み取り結果を Claude API に渡し、注文の行(部位、規格、形態、厚み・1枚の重さ、数量、単位、カットの指定)にそろえる
  5. 【自動】 Python の処理が、取引先の品目の一覧と照らし、単位の無い行・「いつもの」の行・締め切りの後の受信に印を付ける
  6. 【自動】 印の無い行から受注の候補を作り、部位と形態ごとにまとめた加工の指示書の下書きを作る
  7. 【人】 営業事務の担当が朝5時に、印の付いた行だけを FAX の画像と見比べ、必要な店に開店前に電話する
  8. 【人】 営業事務の担当が受注の候補を確定し、加工の指示書を加工場に渡す
  9. 【人】 加工場が指示書で切り、個体識別番号を指示書と送り状に書き込む

7番目が、この設計の分かれ目です。 営業事務の担当が朝に見るのは、印の付いた行だけです。夜のうちに読み取りと並べ替えが終わっているので、朝の1時間は確認と電話に使えます。 全部の注文書を読み直す設計にすると、朝の打ち込みが見比べに置き換わるだけです。

6番目で加工の指示書を「下書き」にしているのも、意図してのことです。 指示書に載るのは印の無い行と、営業事務の担当が確かめた行だけです。確かめていない行を加工場に渡すと、切った後で取り消せません。 印の付いた行は、指示書の末尾に「確認中」として分けて載せ、確定してから切ってもらいます。

02今回想定するシステム構成

構成図
飲食店の FAX 注文書(自社の様式。品目を印字、数量とカットの指定を手書き)
   │  複合機が受信して PDF に
   ▼【トリガー】共有フォルダへの保存(10分ごとに確認)
Python(処理の起動・照合・並べ替え)
   ├──▶ 受信の日時と締め切り、取引先の判別
   ▼
Google Document AI(Form Parser)
   │   表・キーと値のペア・チェック欄と、信頼度を返す
   ▼
Claude API ── 注文の行にそろえる(部位・形態・厚み・重さ・数量・単位・指定)
   ▼
Python
   │   ① 取引先の品目の一覧と照らす
   │   ② 単位の無い行・「いつもの」・締め切り後に印
   │   ③ 部位と形態ごとにまとめる
   ▼
受注の候補と加工の指示書の下書き(確認待ち)
   ▼
【営業事務の担当が印の付いた行だけ確かめ、店に電話】
   ├──▶ 販売管理のシステム(受注の確定)
   └──▶ 加工の指示書(加工場。個体識別番号は加工場が書く)
役割想定する製品代替候補
OCRGoogle Document AI(Form Parser)Azure AI Document Intelligence(カスタム テンプレート モデル)。AWS Textract は日本語を読めないため対象外
生成AIClaude API(読み取り結果を注文の行にそろえる。構造化出力)Gemini API、OpenAI API
集計Python(照合、印、部位と形態ごとの並べ替え)Google Apps Script
保管共有フォルダ(FAX の PDF と読み取りの結果)Google ドライブ

販売管理のシステムと複合機は、新しく足すものではありません。 足すのは、取引先ごとの品目の一覧(印字した品目と、その店のふだんの規格・形態・単位)と、注文書の様式の小さな手直しです。

土台になるのは、Document AI の Form Parser です。 キーと値のペア、表、チェック欄を OCR の文字とあわせて取り出す学習済みのプロセッサで、学習は要りません。 プロセッサの一覧では、推奨の版 pretrained-form-parser-v2.0-2022-11-10 が一般提供(GA)で、日本語(ja)に手書きの対応の印が付いています。 注文書の品目の行は表として、店名や納品の日時はキーと値のペアとして取れます。

表の形が、読み取りの質を決めます。 Form Parser の表の取り出しは、行や列をまたぐセルの無い、見た目が表らしい表を対象にし、返るセルの rowSpan と colSpan は常に1になるとされています。注文書の表に結合したセルがあれば、手直しで外します。

03どうやって実装するのか

Step1

処理の起点を決める

共有フォルダに FAX の PDF が保存されたことを、10分ごとに確かめて起点にします。 複合機は受信した FAX を PDF にして共有フォルダに保存する設定にし、ファイル名に受信の日時を入れます(保存の設定と名前の付け方は機種ごとに確かめます)。

受信の日時で、締め切りを判定します。 前日の20時より後に受信した FAX には after_cutoff の印を付け、翌朝の加工の指示書には載せず、営業の担当の判断待ちの一覧に入れます。 受けるかどうかは、加工場の空きと在庫を見て営業の担当が決めます。

夜のうちに読み取りを終わらせるのが目的です。 朝5時にまとめて処理すると、読み取りが終わるまで営業事務の担当が待つことになります。10分ごとに処理していけば、朝には全部の候補がそろっています。

Step2

入力データを集める

データ中身取得元
FAX の PDF取引先の店名と番号、納品の日と時間帯、品目の行(部位・規格・形態・厚み・1枚の重さ・数量・単位)、備考共有フォルダ
読み取り結果表のセル、キーと値のペア、チェック欄、信頼度Google Document AI
取引先の品目の一覧印字した品目の行、その店のふだんの規格・形態・単位、納品の時間帯、個体識別番号の伝達が要る店か自社で整える表
直近の注文店ごとの直近4回の注文の行販売管理のシステムから毎晩書き出す
形態とカットの言葉の一覧スライス・ステーキ・角切り・挽き・ブロック、筋引き・脂残し・真空の単位など加工場と決める一覧

質を決めるのは、取引先の品目の一覧です。 印字した行の品目は一覧から決まるので、店が書くのは数量と単位とカットの指定だけになります。 一覧に、その店のふだんの単位を持たせておけば、単位の無い行に「ふだんはkg」と参考として添えられます。添えるだけで、埋めはしません。

直近の注文は、「いつもの」の行の参考にします。 「ロース いつもの」と書かれた行には、直近4回のロースの注文を並べて営業事務の担当に見せます。4回とも同じなら確定しやすく、ばらばらなら店に電話します。

Step3

データの取得方法を決める

読み取りは、Python の処理から Form Parser のオンラインの処理を呼びます。注文書は1〜2ページなので、オンラインの処理(15ページまで)で足ります。 返った結果のうち、使うのは次のものです。

取るものどこから何に使うか
品目の表pages[].tables(見出しの行と本体の行)部位・形態・厚み・数量・単位の行
店名・納品の日時pages[].formFields(fieldName と fieldValue)取引先の判別、納品の予定
チェック欄表の中は ✓/☐ の文字、表の外は valueType の filled_checkbox/unfilled_checkbox真空の要否、個包装の要否
信頼度各要素の confidence確かめる行の選び出し
全文text と各要素の textAnchor備考の欄の拾い直し

取引先は、印字した店の番号で決めます。 手書きの店名で決めると、似た名前の店を取り違えます。注文書の右上に、店の番号を大きく印字しておきます。 番号の信頼度が低いときは、FAX の送信元の番号(複合機が記録するもの)と照らします。

Step4

AIへ渡す前に整形する

  1. ファイル名の確認 … 受信の日時が入っているかを確かめ、締め切りの判定に使います
  2. ページの確認 … 2ページの注文書は1件として扱い、表の続きを1つにつなぎます
  3. 白紙・送り状だけの FAX の除外 … 文字がほとんど無いページや、「いつもお世話になっております」だけの送り状は、注文として扱わず記録だけ残します
  4. 同じ注文の二重の受信の確認 … 同じ店・同じ納品の日の注文書が2回届いたら、送り直しか追加の注文かを人に確かめます
  5. 様式の手直し:単位の欄 … 数量の欄の横に「kg」「枚」「本」「P」の4つのチェック欄を置き、単位を丸で書き込ませないようにします
  6. 様式の手直し:厚みと1枚の重さの欄 … 厚み(mm)と1枚の重さ(g)を別の欄にし、単位を印刷しておきます

5番目を最初にやってください。 単位が数量の横に手書きされていると、FAX でつぶれた「kg」と「枚」の区別がつきません。チェック欄にしておけば、単位が付いているかどうかを状態として読めます。 Form Parser はラジオボタンに対応しないので、丸で選ぶ形ではなく、4つの独立したチェック欄にします。

Step5

AIに処理させる

Form Parser にさせるのは、注文書の文字と表とチェック欄を読み取り、信頼度と一緒に返すことです。 Claude API にさせるのは、その結果を注文の行に写し替え、備考のカットの指定を決まった言葉に分けることだけです。

項目写し方判断できないときの扱い
部位・規格印字の品目はそのまま、手書きの品目は書かれたとおり一覧に無ければ unlisted
形態スライス・ステーキ・角切り・挽き・ブロックのいずれか当たらなければ原文のまま other
厚み・1枚の重さ書かれた数字を文字のまま、mm と g を分ける空欄なら null
数量と単位数量は文字のまま、単位はチェック欄の状態のまま単位が無い・2つ以上なら印
カットの指定備考を「筋引き」「脂○mm残し」「真空○kgずつ」などに分ける分けられなければ原文のまま
「いつもの」「いつもの」「前回と同じ」などの言葉を見つける見つけたら usual_ref を立てる
させないこと理由
単位の無い数量をふだんの単位で埋める違う量を切ることになる
「いつもの」を直近の注文で埋める店のいつものと記録の前回が同じとは限らない
厚みや重さの数字を、ふだんの値に寄せるその日だけの指定が消える
個体識別番号を書くことどの個体の肉を切るかは加工場が決める
価格を書くこと不定貫の品は切った後の重さで決まる

1行目と3行目がいちばん起きやすい失敗です。 生成AIに「注文をまとめて」と頼むと、単位の無い行に「kg」を補い、「18Og」のようにつぶれた数字を「180g」に寄せます。寄せた数字は正しいことも多いのですが、正しくなかった1行は、肉を切った後に分かります。

Step6

指示内容を固定する

あなたは精肉の卸で、飲食店から FAX で届いた注文書の読み取り結果を、
注文の行に写し替える担当です。渡された読み取り結果だけを見てください。

【写し方】
- 品目の表の1行を、注文の1行にしてください。印字の品目は品目の一覧の
  表記のまま、手書きの品目は書かれたとおりに写してください。
- 形態は slice / steak / cube / mince / block のいずれかにし、
  当たらなければ other にして原文を cut_text に写してください。
- 厚み(mm)と1枚の重さ(g)は、書かれた数字を文字のまま写してください。
  単位を変えたり、計算したりしないでください。
- 数量は文字のまま、単位は kg・枚・本・P の4つのチェック欄の状態を
  そのまま写してください。
- 備考の指定は、「筋引き」「脂○mm残し」「脂取り」「真空○kgずつ」
  「個包装」などの言葉に分け、分けた元の文字を quote に写してください。

【厳守事項】
- 単位のチェックが付いていない行に、単位を補わないでください。
- 「いつもの」「前回と同じ」「同上」と書かれた行は、usual_ref を true に
  し、中身を推し量って埋めないでください。
- つぶれて読めない数字を、ありそうな数字に直さないでください。
  読み取り結果の文字をそのまま写してください。
- 個体識別番号、価格、在庫の有無を書かないでください。
- 読み取り結果に無い品目を足さないでください。

【この店の品目の一覧】{customer_items}
【形態とカットの言葉の一覧】{cut_terms}
【読み取り結果】{form_parser_result}

「同上」を「いつもの」と同じに扱うのは、表の中でよく使われるからです。 「同上」は上の行と同じという意味ですが、上の行が読み違えられていれば、下の行も同じだけ違います。 自動で上の行を写さず、印を付けて人が見ます。

店の品目の一覧を渡すのは、表記をそろえるためだけです。 一覧には「ふだんの単位」も入っていますが、指示で埋めることを禁じているので、AIは参考として読むだけになります。

Step7

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 すべての欄を required にし、additionalProperties を false にします。値が無い欄は null を許す形にします。

{
  "customer_no": "C-0217",
  "received_at": "2026-10-21T19:42",
  "delivery": { "date": "2026-10-22", "slot": "10時まで" },
  "lines": [
    { "row": 1, "part": "肩ロース", "grade": "国産牛", "form": "slice",
      "thickness_mm": "2", "piece_g": null, "qty": "3",
      "unit": { "kg": "filled", "mai": "unfilled", "hon": "unfilled", "pack": "unfilled" },
      "cuts": [ { "term": "脂取り", "quote": "脂とって" } ],
      "usual_ref": false, "confidence_min": 0.91 },
    { "row": 2, "part": "サーロイン", "grade": "国産牛", "form": "steak",
      "thickness_mm": null, "piece_g": "180", "qty": "10",
      "unit": { "kg": "unfilled", "mai": "unfilled", "hon": "unfilled", "pack": "unfilled" },
      "cuts": [ { "term": "脂残し", "quote": "脂3mm残し" } ],
      "usual_ref": false, "confidence_min": 0.58 }
  ],
  "remarks": ""
}

1つ目の理由は、単位を4つのチェック欄の状態のまま持てることです。 上の例の2行目は、どの単位にも付いていません。「180g×10」ならおそらく10枚ですが、それを決めるのは規則と人で、AIではありません。 規則は unit_missing の印を付け、参考として「1枚の重さが書かれているので枚の可能性」と添えます。

2つ目は、confidence_min を行ごとに持たせ、確かめる行を規則で選べることです。 行の中でいちばん低い信頼度を入れておけば、厚みや重さの数字の1つだけが怪しい行も拾えます。

受け取った後に、Python の規則で印を付けます。

条件印
単位のチェックが0個、または2個以上unit_missing
usual_ref が trueusual_check(直近4回の注文を並べる)
confidence_min が決めた値より低いlow_confidence
品目が店の一覧に無い(unlisted)item_check
形態が steak で piece_g も thickness_mm も無いcut_spec_missing
数量が、その店の直近4回の最大の数倍を超えるqty_check
受信が締め切りの後after_cutoff(指示書に載せない)
個体識別番号の伝達が要る店の国産牛の行id_required(加工場への注記)

最後の行は、加工場への注記のためのものです。 指示書の該当の行に「個体識別番号を送り状に」と出すだけで、番号そのものは加工場が切った肉から書き込みます。

Step8

システムへ連携する

つなぎ先方式内容
共有フォルダPython の処理が10分ごとに確認新しい FAX の PDF
Google Document AIAPI 呼び出し(オンラインの処理)表、キーと値のペア、チェック欄、信頼度
Claude APIAPI 呼び出し(構造化出力)注文の行へのそろえ
取引先の品目の一覧・直近の注文表計算のファイルを読む照合と参考の表示
受注の候補・加工の指示書の下書き表計算への書き込み確認待ち
販売管理のシステム営業事務の担当が確定した受注を取り込む受注・出荷・請求

販売管理のシステムへは、この構成から書き込みません。 営業事務の担当が確定した受注を、取り込みの形で入れます。読み違えた行が、そのまま出荷と請求に進む経路を作らないためです。

Step9

人が確認する

営業事務の担当が朝5時に開くのは、印の付いた行だけです。 印の無い行は、店ごとに件数を流し見て確定します。

  1. after_cutoff を先に営業の担当に回す … 受けるかどうかを決めてもらい、受けるなら指示書に足します
  2. unit_missing と cut_spec_missing を画像で見る … FAX の画像で単位や重さが書かれていないかを確かめ、書かれていなければ開店前に店に電話します
  3. usual_check を直近の注文と見比べる … 4回とも同じなら確定し、ばらばらなら店に電話します
  4. low_confidence の数字を画像と見比べる … 厚みと重さの数字は、とくに丁寧に見ます
  5. 指示書を確定して加工場に渡す … 「確認中」の行が残っていれば、その行だけ後で足します

2番目と3番目の電話は、まとめてかけます。 1つの店で印が複数あれば、1回の電話で聞きます。電話の結果は、その行に「店に確認:○○さん、10枚」のように残します。

目標は、960枚をならして1枚1.5分です。 印の無い注文書は数秒で流し、印の付いた行に数分かけます。

Step10

例外に対処する

起きること対応
店の番号が読めないFAX の送信元の番号と照らす。照らせなければ人へ
自社の様式でない FAX(店の手書きのメモ)表が取れないので全文から拾い、全行を low_confidence で人へ
2ページの注文書の2枚目だけ届いた1枚目を待たず、届いた分だけ候補にし、店に確かめる
同じ店・同じ納品の日の注文書が2回送り直しか追加か。両方を並べて人が決める
「同上」が続くすべて usual_check。上の行が確定してから見る
品目が欠品している在庫の判断は営業の担当。この構成は欠品を判定しない
Claude API が拒否した・途中で切れたstop_reason が refusal や max_tokens なら JSON を使わず人へ
Form Parser が応答しないフォルダに残し、次の確認のときにやり直す
朝5時に処理が終わっていない FAX がある4時台に届いた分。その分だけ人が直接読む

2行目は、なくなりません。 様式を手元に切らした店は、白い紙に手書きして送ってきます。読めないことを前提に、人に回す道を最初から用意しておきます。 様式を切らした店には、翌日の納品に新しい様式を添えます。

Step11

記録を残す

  • FAX の PDF と、受信の日時と送信元の番号
  • Form Parser が返した JSON の全文と、プロセッサの版
  • Claude API に渡した読み取り結果と、返った JSON
  • 印と、営業事務の担当が直した記録(どの行を、何から何に直したか)
  • 店への電話の記録 … 何を聞き、誰が何と答えたか
  • 確定した受注と加工の指示書、加工場が書き込んだ個体識別番号

5つ目の電話の記録を残すのは、行き違いが起きたときのためです。 「10枚と言った」「10kgと言った」の行き違いは、誰がいつ聞いたかが残っていないと、どちらの言い分も確かめられません。

4つ目の直した記録は、様式と品目の一覧を直す材料になります。 同じ店で unit_missing が続くなら、その店に単位のチェックを付けてもらうよう頼みます。

04実装レベルの3段階

最小構成:コンソールで注文書を1枚ずつ読み、Claude の画面で行にそろえる / 読み取りの確かめ
半自動化:上記+共有フォルダを起点に読み取り、受注の候補の表に書く / 受注の打ち込みの置き換え
本格構成:上記+品目の一覧との照合、印、部位と形態ごとの加工の指示書の下書き / 受注と加工の指示の全体

最小構成では枚数がさばけません。 960枚には使えません。確かめるための段階です。 半自動化で、1枚5分が3分程度になります。 打ち込みは無くなりますが、加工の指示書への書き直しと、印の拾い出しが残ります。本格構成で1.5分になり、この段階が本記事の想定です。 差が大きいのは、部位ごとの並べ替えと、単位の無い行の拾い出しが、1枚ずつの手作業だからです。 段階を飛ばさないでください。 半自動化を1か月動かすと、unit_missing の多い店と、自社の様式でない FAX を送る店が先に分かります。様式の手直しを頼んでから並べ替えを足すほうが、加工場に渡す指示書の「確認中」が減ります。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
3 名
月間件数
960 件
1件あたり現在時間
5 分
1件あたり導入後時間
1.5 分
現在  960件 × 5分 ÷ 60 = 80 時間/月
導入後 960件 × 1.5分 ÷ 60 = 24 時間/月
月間削減時間
56h
削減率
70%
年間削減時間
672h
年間金額換算(時間単価2,400円)
161万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 飲食店を中心に数十から百店ほどの取引先を持ち、注文の多くが夜のうちに FAX で届く精肉の卸。早朝に営業事務の担当が FAX を読みながら受注を打ち込み、加工場向けの指示書を手で書き直している場合。カットの厚みや1枚の重さの指定を読み違えて、作り直しや返品が起きている場合。
向いていない
  1. 注文の大半が受発注のシステムや Web の注文の画面で届き、FAX がわずかな場合。取引先が数店で、営業の担当が電話で注文を聞いている場合。取引先の FAX の様式がばらばらで、自社の様式に寄せてもらう見込みが無い場合。取引先の店名や注文の量を国外のリージョンで処理することを、社内の決まりで認めていない場合。なお、肉の品質や等級の判断、個体識別番号の割り当て、価格の決定は、この構成では行いません。

07最小構成で試す方法

  1. 先週届いた FAX の注文書から50枚を選ぶ(うち数枚は、読み違えて作り直した注文を入れる)
  2. Google Cloud のコンソールで Form Parser のプロセッサを作り、50枚を1枚ずつ読ませる
  3. 品目の表が行ごとに取れるか、厚みや重さの数字が崩れずに読めるかを、紙と並べて数える
  4. 読み取り結果を何枚か Claude の画面に貼り、第7章の指示で注文の行にそろえさせる
  5. 当時の受注と並べ、単位の無い行や「いつもの」の行がどう扱われたかを見る

50枚は必ずやってください。 プログラムを組む前に、「FAX でつぶれた手書きの数字と単位が、どこまで読めるのか」を確かめます。

出てきた内容判断
品目の表が行ごとに取れ、数字の大半が読めた共有フォルダと Python の処理の連携に進む
単位だけが読めない単位をチェック欄にする。構成は有効
当時の受注と、単位や数量が違う行が見つかった「いつもの」で埋めていた行が見えた

3行目は珍しくありません。 失敗ではなく、これまで朝の1時間で埋めていた行が見えたということです。 その行がどの店に多いかを見ると、様式の手直しを頼む店の順番が決まります。

08実装時につまずきやすいポイント

問題対策
単位の無い行がふだんの単位で埋まる単位をチェック欄にし、付いていない行は unit_missing で人へ
「いつもの」「同上」が前回の注文で埋まる埋めずに直近4回を並べ、人が決める
つぶれた厚みや重さの数字が、それらしい数字に寄せられる文字のまま写させ、行ごとの最低の信頼度で拾う
単位を丸で書き込ませて読めない4つの独立したチェック欄にする。Form Parser はラジオボタンに対応しない
結合したセルの表が崩れる結合の無い格子の表にする
締め切りの後の FAX が指示書に載る受信の日時で判定し、指示書に載せない
確かめていない行を加工場が切る「確認中」の行を指示書の末尾に分けて載せる
処理する地域に日本が無い第13章。社内の決まりに照らして先に決める

上の3行が、この構成の失敗のほとんどです。 どれも、書かれていないことを、店のいつもの注文で埋めるところから起きます。人が早朝の1時間でやっていた埋め方を、AIに速くやらせるだけでは、切り違いは減りません。

7行目も、早い時期に効いてきます。 加工場は6時に切り始めたいので、指示書に載っている行は全部切ってよいと受け取ります。 確かめていない行を同じ表に混ぜないことが、作り直しを防ぐいちばん確かな方法です。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 取引先の店名と番号、注文の品目と量、納品の日時、FAX の送信元の番号です。注文の量は、その店の客の入りや仕入れの条件をうかがわせる情報です。

  1. 処理する場所を確かめる … Form Parser の対応地域は us、eu、asia-southeast1 などで、日本は含まれていません。 取引先の注文を国外で処理してよいかを、社内の決まりと取引先との取り決めに照らして確かめます
  2. 生成AIに渡す範囲を絞る … Claude API に渡すのは、注文の行にそろえるのに要る読み取り結果と、その店の品目の一覧だけにします。ほかの店の注文や価格は渡しません
  3. 個体識別番号の扱いを加工場に残す … どの個体の肉を切ったかは加工場が決め、指示書と送り状に書き込みます。この構成は番号を推し量らず、注記を出すだけです
  4. 受注を自動で確定しない … 販売管理のシステムへの取り込みは人が行います
  5. FAX の保管の期間を決める … FAX の PDF と電話の記録は、受注の記録として残す期間を決めます

誤りのリスクは、書かれていない単位や「いつもの」を埋めて違う量を切ることと、読み違えた厚みや重さで切ることの2つです。 前者は埋めない決まりと印で、後者は行ごとの信頼度と画像での確認で防ぎます。

10まず何から始めるか

1週目:注文書の様式を直す

数量の横に「kg」「枚」「本」「P」の4つのチェック欄を置き、厚み(mm)と1枚の重さ(g)を別の欄にします。店の番号を右上に大きく印字し、表の結合したセルを外します。

2週目:50枚で試す

先週の FAX の注文書を50枚、Form Parser に読ませます。厚みと重さの数字、単位のチェックが崩れずに読めるかを最優先で数えます。

3週目:取引先の品目の一覧を作る

注文の多い上位30店から、印字した品目、ふだんの規格・形態・単位、納品の時間帯、個体識別番号の伝達が要る店かを表にします。形態とカットの言葉の一覧を、加工場の担当と決めます。

4週目:共有フォルダから受注の候補までをつなぐ

Python の処理で、共有フォルダの確認、読み取り、行へのそろえ、受注の候補の表に書くところまで作ります。この時点では加工の指示書を作らず、営業事務の担当が候補を確かめる流れだけを動かします。

2か月目: 印と、部位と形態ごとの加工の指示書の下書きを足し、新しい様式を全店に配ります。3か月目以降: 1枚5分が何分になったかを実測し、作り直しの件数を前と比べます。朝5時に出た営業事務の担当が、FAX の束ではなく印の付いた行の一覧から1日を始められるようになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-28/最終更新:2026-10-28
確認した内容情報源確認日
Form Parser がキーと値のペア(チェック欄を含む)・表・一般的な項目を OCR の文字とあわせて取り出すこと。推奨の版 pretrained-form-parser-v2.0-2022-11-10 が一般提供(GA)であること。言語の表で日本語(ja)に手書きの対応の印が付いていること。オンラインの処理が15ページ、一括の処理が100ページまでであること。対応地域が asia-south1、asia-southeast1、australia-southeast1、eu、europe-west2、europe-west3、northamerica-northeast1、us で日本が含まれないことGoogle Cloud: Processor list2026-10-28
Form Parser が学習済みで学習させられないこと。チェック欄がラジオボタンに対応しないこと。値の空いたキーと値のペアを確実には取り出せないこと。表は行や列をまたぐセルの無い、見た目が表らしい表を対象にすることGoogle Cloud: Form Parser2026-10-28
Form Parser が formFields を返すこと。表の rowSpan と colSpan が常に1であること。表の中のチェック欄が ✓/☐ の文字で返り、表の外のチェック欄の valueType が filled_checkbox/unfilled_checkbox であることGoogle Cloud: Handle the processing response2026-10-28
構造化出力を output_config.format の json_schema で指定すること。required と additionalProperties: false が必要なこと。拒否は stop_reason: "refusal"、上限は max_tokens で返り、出力がスキーマに合わないことがあることClaude Docs: Structured outputs2026-10-28
「特定牛肉」が牛個体識別台帳に記録されている牛から得られた食用の牛の肉であること(省令で定める加工品などを除く)。販売業者が特定牛肉を販売するときに、肉や容器・包装・送り状、店舗の見やすい場所に個体識別番号を表示すること(第15条)。個体識別番号に代えて荷口番号を表示できることe-Gov 法令API: 牛の個体識別のための情報の管理及び伝達に関する特別措置法2026-10-28

個体識別番号の表示の方法と、取引先ごとに何を伝えるかは、所管の案内と自社の決まりで確かめてください。 本記事は上記の公開情報で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-2081)についてのご相談はこちらから。

AI活用について相談する
目次