文具店が手書きの客注票を読み取り、問屋ごとの発注の一覧と入荷の連絡の台帳を作る

処理の起点を決める

毎日10時15分と14時15分と閉店の後に、Apps Script が動きます。 公式の説明では、時間主導型のトリガーは決まった時刻か決まった間隔で処理を動かせます。10時15分はA社の11時の締めに、14時15分はC社の15時の締めに、閉店の後は翌朝の発注に間に合わせるためです。 締めの前に45分あるので、店長が確認の一覧を見て、発注の画面に打ち込めます。

撮るのは、客注を受けた店員の仕事にします。 客注票を書き終え、お客様控えを渡したら、店控えをレジの横のスマートフォンで撮ります。撮った店控えは、これまでどおりレジの横の箱に入れます。 紙は、入荷して受け渡しが終わるまで元の記録として残します。

急ぎの取り寄せのために、スプレッドシートに「いま読む」のメニューを付けます。 締めの直前に入った客注を、次の時刻を待たずに読めます。処理の終わった画像は月ごとのフォルダへ移し、移すのは客注の表に書き終えたときだけにします。

入力データを集める

質を決めるのは、問屋の商品の一覧です。 一覧が無いと、読み取った品番が実在するかも、色の番号が合っているかも確かめられません。毎月届いた一覧を、届いた日に貼り替えます。 古い一覧のまま照らすと、廃番の品を発注の一覧に入れます。

書き方の一覧は、店員が使ってきた言い方を店長がまとめたものです。 「学校の〇〇ノート」「事務所の〇〇さんの替え芯」のように、得意先ごとに決まった品がある場合は、ここに書いておくと品番が一度で決まります。 増えるほど、生成AIに回る行が減ります。

生成AIに渡すのは、メーカー・品名・品番・色の欄の文字と、商品の一覧のうち同じメーカーの行だけです。 お客様の名前、電話番号、メールは渡しません。

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

Apps Script から、Document AI の REST の process のメソッドを呼びます。 公式の説明では、processors/PROCESSOR_ID:process に、rawDocument として画像を base64 にした内容と MIME タイプを付けて送ります。トークンは Apps Script の実行しているユーザーの OAuth のトークンを使います。

連絡の方法と前金の有無は、四角のチェック欄にします。 公式の説明では、チェックボックスは近くの文字をキーとするキーと値のペアとして取り出され、valueType で印の有無が示されます（filled_checkbox／unfilled_checkbox）。丸で囲む書き方は読めないので、四角に変えます。

品番の欄は、1マスに1文字の枠にします。 品番は英字と数字とハイフンが混ざり、「0」と「O」、「1」と「I」、「5」と「S」が読み違えやすい文字です。枠があると、文字の数で品番の形が合うかを確かめられます。

空いた欄は、空として扱います。 公式の説明では、Form Parser は値の入っていないキーと値のペアを確実には読めないとされています。色の欄が空のときは、色の指定が無いとは見なさず、「色の記載なし」として確認に回します。

AIへ渡す前に整形する

1. 1枚1ファイルの確認 … 公式のプロセッサ一覧では、Form Parser の同期の処理は1回15ページまでです。客注票は1枚1ファイルにします
2. 向きと傾きの確認 … 横向きや斜めの画像は、向きを直してから送ります
3. 品番のそろえ … 全角を半角に、ハイフンの種類を1つにそろえ、空白を除きます
4. 読み違えやすい文字の候補 … 品番に「0」「O」、「1」「I」などが入るときは、置き換えた形も作り、商品の一覧にあるものだけを候補に残します
5. 商品の一覧で照らす … 品番がそのまま、または4番の置き換えで1つだけ当たれば「決まった」。2つ以上か0なら生成AIに回します
6. 色の確かめ … 商品の一覧でその品番に色の違いがあるのに、色の番号も色の名前も書かれていなければ「色の記載なし」にします
7. 電話番号の確かめ … 数字の桁が電話番号の形に合うかを見ます。合わなければ「連絡先が読めない」にします

4番目で、読み違えの置き換えは商品の一覧で確かめられたものだけにします。 置き換えた形が一覧に無ければ、候補にしません。一覧に無い品番を作ると、問屋の発注の画面で「該当なし」になるか、似た品番の別の品が届きます。

6番目が、取り寄せでいちばん多い失敗を止める確かめです。 品番の頭の部分は合っていても、色の番号が無ければ品は決まっていません。色をいちばん売れる色に寄せることはしません。

AIに処理させる

品番の照らし合わせ、色の確かめ、入数と余り、問屋と締めの時刻、電話番号の確かめは、Apps Script の規則で行います。 生成AIには、商品の一覧で決まらなかった行について、メーカー・品名・色の書き方から候補を出す仕事だけを渡します。

3つ目は、店長がお客様に電話するときに使います。 「芯の太さが0.5か0.7か」が足りないと分かっていれば、電話で聞くことが1つに絞れます。 生成AIには、足りない項目の名前だけを返させ、どちらかに決めさせません。

2行目がいちばん起きやすい失敗です。 「〇〇 赤」と書かれた票で、一覧に「赤」と「ピンクレッド」があると、生成AIは名前の近い「赤」を matched にしがちです。 色の候補が2つ以上あれば、必ず candidates にさせます。

指示内容を固定する

あなたは文具店の取り寄せの補助です。
客注票に書かれた品の書き方を、問屋の商品の一覧の行に当ててください。

【渡すもの】
- 客注票のメーカー・品名・品番・色の欄の文字
- 商品の一覧のうち、同じメーカーの行（品番・品名・色の名前・色の番号）

【当て方】
- 品名と色の両方が、一覧の品名と色の名前（または色の番号）と
  同じ語で書かれていて、候補が1つなら status を matched に。
- 候補が2つ以上なら status を candidates にし、候補を最大3つ返す。
- 一覧に当たる行が無ければ status を not_found にする。
- 候補ごとに、根拠にした語を evidence にそのまま写す。

【足りない情報】
- 候補を1つに絞るのに足りない項目を missing に入れる。
  color（色）、tip_size（芯・ペン先の太さ）、size（サイズ）、
  other のどれか。

【厳守事項】
- 一覧に無い品番を返さない。品番を作らない。
- 色が書かれていなければ、色を決めない。よく売れる色に寄せない。
- 「赤」と「ピンクレッド」のように名前の近い色を同じものとして扱わない。
- 数量、価格、問屋について何も書かない。
- 読めない文字は「?」のまま残す。

【客注票の欄】{order_fields}
【商品の一覧（同じメーカー）】{catalog_rows}

「名前の近い色を同じものとして扱わない」を明記しないと、色の近い品を matched にします。 文具の色の名前は、メーカーごとに細かく分かれています。近い色を寄せるのは、お客様が見て「違う」と言う品を頼むことです。

構造化出力で、答えの形を固定します。 公式の説明では、Claude API の構造化出力は output_config.format に type: "json_schema" でスキーマを渡し、オブジェクトには additionalProperties: false が要ります。status と missing の値は enum で決まった値に限ります。候補の数の上限は、スキーマではなく Apps Script の側で確かめます。 公式の説明では、配列の minItems は0か1しか使えません。

出力形式を固定する

{
  "status": "candidates",
  "candidates": [
    { "code": "XX-500-R", "name": "〇〇 ゲルボールペン 0.5", "color": "赤",
      "evidence": "〇〇の0.5 赤" },
    { "code": "XX-500-PR", "name": "〇〇 ゲルボールペン 0.5", "color": "ピンクレッド",
      "evidence": "〇〇の0.5 赤" }
  ],
  "missing": ["color"]
}

Apps Script は、この JSON と規則の結果から、客注の表の1行を作り、そこから2つの表を作ります。

発注の一覧は、締めの時刻ごとに区切って出します。 店長が締めの前に見る画面は、たとえば次のようになります。

【A社 11:00 締め】 10月29日
XX-500-B  〇〇 ゲルボールペン 0.5 黒   客注 3本（2件）  入数 10 → 発注 10・余り 7 ※要判断
YY-B5-30  △△ ノート B5 30枚 青        客注 5冊（1件）  入数 5  → 発注 5
【C社 15:00 締め】
ZZ-F-A4   □□ フラットファイル A4 赤    客注 20冊（1件） 入数 10 → 発注 20
確認待ち：品番未定 2件（色の記載なし 1、候補2つ 1）／連絡先が読めない 1件

同じ品番の客注は、締めごとに足して1行にします。 2件の客注で3本なら、余りは入数との差で1回だけ出ます。余りを店の在庫にするか、次の客注を待つかは、店長が決めます。

システムへ連携する

問屋の発注の画面には、仕組みから打ち込みません。 問屋の画面に自動で打ち込む仕組みは、画面が変わると止まり、誤った品番を確認無しに頼む経路にもなります。 発注の一覧を見ながら人が打ち込み、打ち込んだ行に印を付けます。

入荷の連絡も、人が行います。 入荷の連絡の台帳に入荷の日を入れると、その行が「連絡待ち」になります。電話かメールかは、お客様が選んだ方法のとおりにします。 入荷した後の連絡漏れと引き取り漏れを追う仕組みを足すなら、UC-0797 の形が使えます。

人が確認する

1. 品番の決まらない行を先に見る … 候補から選べるなら選び、選べなければ店控えを見てお客様に電話します。電話で聞く項目は、missing に出たものだけにします
2. 色の記載が無い行を見る … 必ずお客様に確かめます。店員の記憶で決めません
3. 余りの出る行を見る … 店の在庫にするか、次の客注を待つか、お客様に入数で買っていただけるかを決めます
4. 連絡先の読めない行を見る … 店控えの画像を見て、読めなければ受けた店員に聞きます
5. 締めに間に合わない行を見る … 受け渡しの希望の日に間に合わない目安が出たら、お客様に日にちを伝え直します

選んだ候補と、電話で確かめたことは、客注の表の行に残します。 同じ言い方が何度も出るなら、書き方の一覧に足して、次から一度で決まるようにします。

目標は、300件をならして1件2分です。 品番の決まった行を発注の画面に打ち込む時間と、確認の一覧の行を見る時間を合わせた値です。

例外に対処する

5行目は、撮り直しのときに起きます。 1枚目がぼけていたので撮り直し、両方が受付のフォルダに残ると、同じ取り寄せが2つ頼まれます。 取り寄せの品は返せないことが多いので、自動では足さずに止めます。

記録を残す

• 客注票の画像と、撮った日時・撮った店員
• Document AI が返した JSON の全文と、使ったプロセッサの版
• 照らし合わせに使った商品の一覧の月と、生成AIの候補
• 店長が選んだ候補と、お客様に確かめたこと
• 発注した日・問屋・締め、入荷の日、連絡した日、受け渡しの日

3つ目で商品の一覧の月を残すのは、品番と色が毎月変わるからです。 届いた品が違ったとき、当時の一覧で正しく照らしていたかを後から確かめられます。